Posted on 26/01/2017 by Gustavo Padovan
In the last two articles we talked about how Explicit Fencing can help the graphics pipeline in general and what happened on the effort to upstream the Android Sync Framework. Now on the third and final post of this series we will go through the Explicit Fencing implementation on DRM and other elements of the graphics stack.
The DRM implementation lays down on top of two kernel infrastructures, struct dma_fence, which represents the fence and struct sync file that provides the file descriptors to be shared with userspace (as it was discussed in the previous articles). With fencing the display infrastructure needs to wait for a signal on that fence before displaying the buffer on the screen. On a Explicit Fencing implementation that fence is sent from userspace to the kernel. The display infrastructure also sends back to userspace a fence, encapsulated in a struct sync_file, that will be signalled when the buffer is scanned out on the screen. The same process happens on the rendering side.
It is mandatory to use of Atomic Modesetting and here is not plan to support legacy APIs. The fence that DRM will wait on needs to be passed via the IN_FENCE_FD property for each DRM plane, that means it will receive one sync_file fd containing one or more dma_fence per plane. Remember that in DRM a plane directly relates to a framebuffer so one can also say that there is one sync_file per framebuffer.
On the other hand for the fences created by the kernel that are sent back to userspace the OUT_FENCE_PTR property is used. It is a DRM CRTC property because we only create one dma_fence per CRTC as all the buffers on it will be scanned out at the same time. The kernel sends this fence back to userspace by writing the fd number to the pointer provided in the OUT_FENCE_PTR property. Note that, unlike from what Android did, when the fence signals it means the previous buffer – the buffer removed from the screen – is free for reuse. On Android when the signal was raised it meant the current buffer was freed. However, the Android folks have patched SurfaceFlinger already to support the Mainline semantics when using Explicit Fencing!
Nonetheless, that is only one side of the equation and to have the full graphics pipeline running with Explicit Fencing we need to support it on the rendering side as well. As every rendering driver has its own userspace API we need to add Explicit Fencing support to every single driver there. The freedreno driver already has its Explicit Fencing support mainline and there is work in progress to add support to i915 and virtio_gpu.
On the userspace side Mesa already has support for the EGL_ANDROID_native_fence_sync needed to use Explicit Fencing on Android. Libdrm incorporated the headers to access the sync file IOCTL wrappers. On Android, libsync now has support for both the old Android Sync and Mainline Sinc File APIs. And finally, on drm_hwcomposer, patches to use Atomic Modesetting and Explicit Fencing are available but they are not upstream yet.
Validation tests for both Sync Files and fences on the Atomic API were written and added to IGT.
Earlier this month, Olivier Crête, Nicolas Dufresne, George Kiagiadakis & I attended the GStreamer Spring Hackfest in Lund, Sweden. Hosted…
A few months ago, Robert Foss wrote a blog post about virtualizing GPU Access. Here's a look at some of the major improvements that have…
Generously hosted by Axis in the beautiful Lund, Sweden, the annual spring hackfest is an occasion for the community to get together to…
The i.MX 6 platform has for the past few years enjoyed a large effort to add upstream support to Linux and surrounding projects. The newly…
Following on from part 1 in the series, part 2 covers more developments in low-level graphics, including support for buffer modifiers in…
The latest enhancements to the DRM subsystem have made mainline Linux much more attractive, making drivers easier to write, applications…