Re: gpu outputs slave and cache flushing

[Maarten Lankhorst <maarten.lankhorst@canonical.com>]

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