Linux 5.19 Advances In Quest To Improve Explicit Synchronization For Graphics
Former Intel Vulkan graphics driver developer Jason Ekstrand who joined Collabora earlier this year to continue working on the upstream Linux graphics stack has been working a lot over the past number of months on improving the explicit synchronization model for Linux after years of the Linux desktop being focused on implicit synchronization.
In a new blog post, Ekstrand summarizes the implicit/explicit synchronization issue at length for those interested in all of the technical details on the challenges that have been there, how Vulkan and modern graphics/compute APIs force explicit synchronization, and the new interfaces coming in Linux 5.19 to help move Linux in the right direction.
Some of Jason's key comments include:
So how do we tie implicit and explicit sync together? Let userspace extract and set fences itself, of course! The new API, which should be in Linux 5.19, adds two new ioctls on dma-buf file descriptors which allow userspace to extract and insert fences directly. In userspace, these dma fences are represented by sync files. A sync file wraps a dma fence which turns it into a file descriptor that can be passed around by userspace and waited on via poll(). The first ioctl extracts all of the fences from a dma-buf's reservation object and returns them to userspace as a single sync file. It takes a flags parameter which lets you specify whether you expect to read the data in the dma-buf, write it, or both. If you specify read-only, the returned sync file will only contain write fences but if you specify write or read-write, the returned sync file will wait on all implicit sync fences currently in the reservation object. The second ioctl allows userspace to add a sync file to the reservation object. It also takes read/write flags to allow you to control whether the newly added fence is considered a write fence or only a read fence.
...
This solution allows us to roll out better explicit synchronization support to users seamlessly. Vulkan drivers seamlessly work with compositors which only understand implicit synchronizaiton and, if Wayland compositors pick up sufficient explicit synchronization support, we can transition to that once the compositors are ready. We could have driven this from the Wayland side first and rolled out explicit synchronization support to a bunch of Wayland compositors and said you need a new Wayland compositor if you want to get the fastest possible Vulkan experience. However, that would have been a lot more work. It would have involved a bunch of protocol, adding sync file support to KMS, and touching every Wayland compositor we collectively care about. It would also have been much harder to get 100% transitioned to explicit synchronization because you can only use explicit synchronization without stalling if every component in the entire display path supports it. Likely, had we taken that path, some configurations would be stuck with the old hacky solutions forever and we would never be able to delete that code from Mesa.
Update: This work didn't land in Linux 5.19 but will be in 5.20.
33 Comments
