[Linaro-mm-sig] [RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices

[Erik Gilling]

On Fri, Jun 8, 2012 at 2:42 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
>> I think this is an approach worth investigating.  I'd like a way to
>> either opt out of implicit sync or have a way to check if a dma-buf
>> has an attached fence and detach it.  Actually, that could work really
>> well. Consider:
>>
>> * Each dma_buf has a single fence "slot"
>> * on submission
>>    * the driver will extract the fence from the dma_buf and queue a wait on it.
>>    * the driver will replace that fence with it's own complettion
>> fence before the job submission ioctl returns.
>
> This is pretty much what I've had in mind with the extension that we
> probably need both a read and a write fence - in a lot of cases multiple
> people want to use a buffer for reads (e.g. when decoding video streams
> the decode needs it as a reference frame wheras later stages use it
> read-only, too).

I actually hit "send" instead of "save draft" on this before talking
this over with some co-workers.  We came up with the same issues.  I'm
actually less concerned about the specifics as long as we have a way
to attach and detach the fences.

>> * dma_buf will have two userspace ioctls:
>>    * DETACH: will return the fence as an FD to userspace and clear the
>> fence slot in the dma_buf
>>    * ATTACH: takes a fence FD from userspace and attaches it to the
>> dma_buf fence slot.  Returns an error if the fence slot is non-empty.
>
> I am not yet sold on explicit fences, especially for cross-device sync. I
> do see uses for explicit fences that can be accessed from userspace for
> individual drivers - otherwise tricks like suballocation are a bit hard to
> pull off. But for cross-device buffer sharing I don't quite see the point,
> especially since the current Linux userspace graphics stack manages to do
> so without (e.g. DRI2 is all implicit sync'ed).

The current linux graphics stack does not allow synchronization
between the GPU and a camera/video decoder.  When we've seen people
try to support this behind the scenes, they get it wrong and introduce
bugs that can take weeks to track down.  As stated in the previous
email, one of our goals is to centrally manage synchronization so that
it's easer for people bringing up a platform to get it right.

> btw, I'll try to stitch together a more elaborate discussion over the w/e,
> I have a few more pet-peeves with your actual implementation ;-)

Happy to hear feedback on the specifics.

-Erik