Re: [RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices

[Pauli <pauli.nieminen@linux.intel.com>]

On 25/05/12 14:08, Tom Cooksey wrote:
> Hi All,
>
> I realise it's been a while since this was last discussed, however I'd like
> to bring up kernel-side synchronization again. By kernel-side
> synchronization, I mean allowing multiple drivers/devices wanting to access
> the same buffer to do so without bouncing up to userspace to resolve
> dependencies such as "the display controller can't start scanning out a
> buffer until the GPU has finished rendering into it". As such, this is
> really just an optimization which reduces latency between E.g. The GPU
> finishing a rendering job and that buffer being scanned out. I appreciate
> this particular example is already solved on desktop graphics cards as the
> display controller and 3D core are both controlled by the same driver, so no
> "generic" mechanism is needed. However on ARM SoCs, the 3D core (like an ARM
> Mali) and display controller tend to be driven by separate drivers, so some
> mechanism is needed to allow both drivers to synchronize their access to
> buffers.
>
> There are multiple ways synchronization can be achieved, fences/sync objects
> is one common approach, however we're presenting a different approach.
> Personally, I quite like fence sync objects, however we believe it requires
> a lot of userspace interfaces to be changed to pass around sync object
> handles. Our hope is that the kds approach will require less effort to make
> use of as no existing userspace interfaces need to be changed. E.g. To use
> explicit fences, the struct drm_mode_crtc_page_flip would need a new members
> to pass in the handle(s) of sync object(s) which the flip depends on (I.e.
> don't flip until these fences fire). The additional benefit of our approach
> is that it prevents userspace specifying dependency loops which can cause a
> deadlock (see kds.txt for an explanation of what I mean here).

It is easy to cause cyclic dependencies with implicit fences unless you 
are very sure that client can only cause linear implicit dependencies. 
But clients already have synchronization dependencies with userspace. 
That makes implicit synchronization possibly cause unexpected deadlocks.

Explicit synchronization is easier to debug because developer using 
explicit synchronization can track the dependencies in userspace. But of 
course that makes userspace API harder to use than API using implicitly 
synchronization.

But implicit synchronization can avoid client deadlock issues. Providing 
if client may never block "fence" from triggering in finite time when it 
is granted access. The page flip can be synchronized in that manner if 
client can't block HW from processing queued rendering.

You were talking about adding new parameter to page flip ioctl. I fail 
to see need for it because page flip already has fb object as parameter 
that should map to the implicit synchronization fence through dma_buf.

> I have waited until now to bring this up again because I am now able to
> share the code I was trying (and failing I think) to explain previously. The
> code has now been released under the GPLv2 from ARM Mali's developer portal,
> however I've attempted to turn that into a patch to allow it to be discussed
> on this list. Please find the patch inline below.
>
> While KDS defines a very generic mechanism, I am proposing that this code or
> at least the concepts be merged with the existing dma_buf code, so a the
> struct kds_resource members get moved to struct dma_buf, kds_* functions get
> renamed to dma_buf_* functions, etc. So I guess what I'm saying is please
> don't review the actual code just yet, only the concepts the code describes,
> where kds_resource == dma_duf.

But the documented functionality sounds very much deadlock prone. If 
userspace gets exclusive access and needs to wait for implicit access 
synchronization.

app A has access to buffer X
app B requests exclusive access to buffer X and blocks waiting for access
app A makes synchronous IPC call to app B

I didn't read the actual code at all to figure out if that is possible 
scenario. But it sounds like possible scenario based on documentation 
talking EGL depending on exclusive access.

>
> Cheers,
>
> Tom
>

Pauli