Hi Out of interest will this allow tear free with PRIME?
Thanks Mike On Tue, 26 Apr 2016, 12:33 a.m. Gustavo Padovan, <gustavo at padovan.org> wrote: > From: Gustavo Padovan <gustavo.padovan at collabora.co.uk> > > Hi, > > Currently the Linux Kernel only have an implicit fencing mechanism > where the fence are attached directly to buffers and userspace is unaware > of > what is happening. On the other hand explicit fencing which is not > supported > yet by Linux but it expose fences to the userspace to handle fencing > between > producer/consumer explicitely. > > For that we use the Android Sync Framework[1], a explicit fencing mechanism > that help the userspace handles fences directly. It has the concept of > sync_file (called sync_fence in Android) that expose the driver's fences to > userspace via file descriptors. File descriptors are useful because we can > pass > them around between process. > > The Sync Framework is currently in the staging tree and on the process to > be de-staged[2]. > > With explicit fencing we have a global mechanism that optimizes the flow of > buffers between consumers and producers, avoid a lot of waiting. So instead > of waiting for a buffer to be processed by the GPU before sending it to DRM > in an Atomic IOCTL we can get a sync_file fd from the GPU driver at the > moment > we submit the buffer processing. The compositor then passes these fds to > DRM in > a atomic commit request, that will not be displayed until the fences > signal, > i.e, the GPU finished processing the buffer and it is ready to display. In > DRM > the fences we wait on before displaying a buffer are called in-fences. > > Vice-versa, we have out-fences, to sychronize the return of buffers to GPU > (producer) to be processed again. When DRM receives an atomic request with > a > special flag set it generates one fence per-crtc and attach it to a > per-crtc > sync_file. It then returns the array of sync_file fds to userspace as an > atomic_ioctl out arg. With the fences available userspace can forward these > fences to the GPU, where it will wait the fence to signal before starting > to > process on buffer again. > > Explicit fencing with Sync Framework allows buffer suballocation. Userspace > get a large buffer and divides it into small ones and submit requests to > process them, each subbuffer gets and sync_file fd and can be processed in > parallel. This is not even possible with implicit fencing. > > While these are out-fences in DRM (the consumer) they become in-fences once > they get to the GPU (the producer). > > DRM explicit fences are opt-in, as the default will still be implicit > fencing. > To enable explicit in-fences one just need to pass a sync_file fd in the > FENCE_FD plane property. *In-fences are per-plane*, i.e., per framebuffer. > > For out-fences, just enabling DRM_MODE_ATOMIC_OUT_FENCE flag is enough. > *Out-fences are per-crtc*. > > In-fences > --------- > > In the first discussions on #dri-devel on IRC we decided to hide the Sync > Framework from DRM drivers to reduce complexity, so as soon we get the fd > via FENCE_FD plane property we convert the sync_file fd to a struct fence. > However a sync_file might contain more than one fence, so we created the > fence_collection concept. struct fence_collection is a subclass of struct > fence and stores a group of fences that needs to be waited together, in > other words, all the fences in the sync_file. > > Then we just use the already in place fence support to wait on those > fences. > Once the producer calls fence_signal() for all fences on wait we can > proceed > with the atomic commit and display the framebuffers. DRM drivers only > needs to > be converted to struct fence to make use of this feature. > > Out-fences > ---------- > > Passing the DRM_MODE_ATOMIC_OUT_FENCE flag to an atomic request enables > out-fences. The kernel then creates a fence, attach it to a sync_file and > install this file on a unused fd for each crtc. Userspace get the fence > back > as an array of per-crtc sync_file fds. > > DRM core use the already in place drm_event infrastructure to help signal > fences, we've added a fence pointer to struct drm_pending_event. If the > atomic > update received requested an PAGE_FLIP_EVENT we just use the same > drm_pending_event and set our fence there, otherwise we just create an > event > with a NULL file_priv to set our fence. On vblank we just call > fence_signal() > to signal that the buffer related to this fence is *now* on the screen. > Note that this is exactly the opposite behaviour from Android, where the > fences > are signaled when they are not on display anymore, so free to be reused. > > No changes are required to DRM drivers to have out-fences support, apart > from > atomic support of course. > > Kernel tree > ----------- > > For those who want all patches on this RFC are in my tree. The tree > includes > all sync frameworks patches needed at the moment: > > > https://git.kernel.org/cgit/linux/kernel/git/padovan/linux.git/log/?h=fences > > I also hacked some poor some fake fences support to modetest here: > > https://git.collabora.com/cgit/user/padovan/libdrm.git/log/?h=atomic > > > v2 changes > ---------- > > The changes from RFC v1 to RFC v2 are in the patches description. > > TODO > ---- > > * upstream Android Sync ABI changes > * de-stage Android Sync Framework > * Upstream sync selftests (Emilio Lopez) > * create tests for DRM fences > > Regards, > > Gustavo > --- > > [1] https://source.android.com/devices/graphics/implement.html#vsync > [2] > https://git.kernel.org/cgit/linux/kernel/git/padovan/linux.git/log/?h=sync > > Gustavo Padovan (8): > dma-buf/fence: add fence_collection fences > Documentation: add fence-collection to kernel DocBook > dma-buf/sync_file: add sync_file_fences_get() > drm/fence: allow fence waiting to be interrupted by userspace > drm/fence: add in-fences support > drm/fence: add fence to drm_pending_event > drm/fence: add fence timeline to drm_crtc > drm/fence: add out-fences support > > Documentation/DocBook/device-drivers.tmpl | 2 + > drivers/dma-buf/Makefile | 2 +- > drivers/dma-buf/fence-collection.c | 159 ++++++++++++++++++++++++ > drivers/dma-buf/fence.c | 2 +- > drivers/dma-buf/sync_file.c | 60 +++++++++ > drivers/gpu/drm/Kconfig | 1 + > drivers/gpu/drm/drm_atomic.c | 196 > ++++++++++++++++++++++++++++-- > drivers/gpu/drm/drm_atomic_helper.c | 24 +++- > drivers/gpu/drm/drm_crtc.c | 36 ++++++ > drivers/gpu/drm/drm_fops.c | 8 +- > include/drm/drmP.h | 2 + > include/drm/drm_atomic_helper.h | 4 +- > include/drm/drm_crtc.h | 30 +++++ > include/linux/fence-collection.h | 73 +++++++++++ > include/linux/fence.h | 9 ++ > include/linux/sync_file.h | 3 + > include/uapi/drm/drm_mode.h | 11 +- > 17 files changed, 600 insertions(+), 22 deletions(-) > create mode 100644 drivers/dma-buf/fence-collection.c > create mode 100644 include/linux/fence-collection.h > > -- > 2.5.5 > > _______________________________________________ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/356c86d0/attachment-0001.html>
