gpu outputs slave and cache flushing

gpu outputs slave and cache flushing

[Dave Airlie]

Hey,

so I put a patch into intel driver a while ago to avoid doing a bo
flush using map/unmap for output slave device if the kernel has vmap
flushing

However on reflection I realised this only works for CPU accessing
devices like UDL but doesn't work for GPU accessing devices like
nouveau/radeon,

Going forward I'm sure we'll eventually get GPU sync via Maarten's
patches but I'm thinking I should revert this change in the intel
driver for now,
so reverse optimus can work properly

Anyone got any ideas for a better plan going forward, maybe a stop gap
before Maartens patches.

Dave.

Re: [Intel-gfx] gpu outputs slave and cache flushing

[Chris Wilson]

On Tue, Jul 30, 2013 at 03:04:22PM +1000, Dave Airlie wrote:
> Hey,
> 
> so I put a patch into intel driver a while ago to avoid doing a bo
> flush using map/unmap for output slave device if the kernel has vmap
> flushing
> 
> However on reflection I realised this only works for CPU accessing
> devices like UDL but doesn't work for GPU accessing devices like
> nouveau/radeon,
> 
> Going forward I'm sure we'll eventually get GPU sync via Maarten's
> patches but I'm thinking I should revert this change in the intel
> driver for now,
> so reverse optimus can work properly
> 
> Anyone got any ideas for a better plan going forward, maybe a stop gap
> before Maartens patches.

I don't think it is possible to w/a this in userspace, so let's blame
Daniel^WBen for this mess and cheer on our knight in shining armour.
Go Maarten! But we need to be sure there is a similar synchronisation
point for CPU access to a foriegn dma-buf.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: gpu outputs slave and cache flushing

[Maarten Lankhorst]

Op 30-07-13 10:13, Chris Wilson schreef:
> On Tue, Jul 30, 2013 at 03:04:22PM +1000, Dave Airlie wrote:
>> Hey,
>>
>> so I put a patch into intel driver a while ago to avoid doing a bo
>> flush using map/unmap for output slave device if the kernel has vmap
>> flushing
>>
>> However on reflection I realised this only works for CPU accessing
>> devices like UDL but doesn't work for GPU accessing devices like
>> nouveau/radeon,
>>
>> Going forward I'm sure we'll eventually get GPU sync via Maarten's
>> patches but I'm thinking I should revert this change in the intel
>> driver for now,
>> so reverse optimus can work properly
>>
>> Anyone got any ideas for a better plan going forward, maybe a stop gap
>> before Maartens patches.
> I don't think it is possible to w/a this in userspace, so let's blame
> Daniel^WBen for this mess and cheer on our knight in shining armour.
> Go Maarten! But we need to be sure there is a similar synchronisation
> point for CPU access to a foriegn dma-buf.
> -Chris
>
It's complicated, and probably best suited to discuss at linux plumbers. :)
It probably won't work without changing how the dma-buf locking is done,
and for intel also depends on proper ww_mutex support.
I think using reservation objects and fences in intel is the right way to go,
and would allow for a less invasive integration of synchronization.

In my experimental tree I used a hack in the execbuffer before to reserve all
bo's, but the approach I took was rather hacky, and only applied to dma-bufs.
Correct handling is probably better done by someone who understands i915 better than me.

~Maarten

Re: gpu outputs slave and cache flushing

[Daniel Vetter]

On Tue, Jul 30, 2013 at 09:13:48AM +0100, Chris Wilson wrote:
> On Tue, Jul 30, 2013 at 03:04:22PM +1000, Dave Airlie wrote:
> > Hey,
> > 
> > so I put a patch into intel driver a while ago to avoid doing a bo
> > flush using map/unmap for output slave device if the kernel has vmap
> > flushing
> > 
> > However on reflection I realised this only works for CPU accessing
> > devices like UDL but doesn't work for GPU accessing devices like
> > nouveau/radeon,
> > 
> > Going forward I'm sure we'll eventually get GPU sync via Maarten's
> > patches but I'm thinking I should revert this change in the intel
> > driver for now,
> > so reverse optimus can work properly
> > 
> > Anyone got any ideas for a better plan going forward, maybe a stop gap
> > before Maartens patches.
> 
> I don't think it is possible to w/a this in userspace, so let's blame
> Daniel^WBen for this mess and cheer on our knight in shining armour.
> Go Maarten! But we need to be sure there is a similar synchronisation
> point for CPU access to a foriegn dma-buf.

Yeah, as long as we haven't thought all prime drivers and dma_buf how to
sync access (and flush caches if required) userspace needs to manually
flush stuff. I don't see a way around this :(

On the plus side our QA has started another try at running with nouveau
(last time around was just too much fallout from nouveau) to run our neat
seat of prime tests. So investing into a few good tests there should pay
of nicely.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch