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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
