On Mon, May 18, 2026 at 2:41 PM Christian König christian.koenig@amd.com wrote:
On 5/18/26 14:02, Julian Orth wrote:
On Mon, May 18, 2026 at 1:58 PM Christian König christian.koenig@amd.com wrote:
On 5/16/26 13:06, Julian Orth wrote:
This series adds a new device /dev/syncobj that can be used to create and manipulate DRM syncobjs. Previously, these operations required the use of a DRM device and the device needed to support the DRIVER_SYNCOBJ and DRIVER_SYNCOBJ_TIMELINE features.
There are several issues with the existing API:
- Syncobjs are the only explicit sync mechanism available on wayland. Most compositors do not use GPU waits. Instead, they use the DRM_IOCTL_SYNCOBJ_EVENTFD ioctl to perform a CPU wait. Being tied to DRM devices means that compositors cannot consistently offer this feature even though no device-specific logic is involved.
Well the drm_syncobj is a container for device specific dma fences.
Not necessarily. The DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL ioctl attaches some kind of dummy fence that is already signaled. I don't believe this is device specific. That is also the path that llvmpipe would use.
Yeah I feared that.
This is the wait before signal path and if I'm not completely mistaken that one is not supported by a lot of compositors.
I believe this is supported by all compositors.
The last time I looked for GPU support the compositor needs to spawn a separate thread for each client to support this approach.
It could be that we have eventfd integration for that as well now, but in that case you could give the compositor an eventfd instead of a drm_syncobj fd in the first place.
Yes, all compositors use the DRM_IOCTL_SYNCOBJ_EVENTFD ioctl to wait async for the timeline point to materialize and/or be signaled. The wayland protocol was the motivation for that ioctl.
So as far as I can see using drm_syncobj for software rendering really doesn't make sense, eventfd is a much better fit for that use case.
Using eventfd has some disadvantages:
- We've just added syncobj support to vulkan: https://github.com/KhronosGroup/Vulkan-Docs/issues/2473#issuecomment-4446117.... For eventfd we would not only have to add yet another extension, that would realistically only be exposed by llvmpipe, but also every compositor and every client would have to support both extensions. - Similarly, a new wayland protocol would need to be designed to support sync over eventfd. - Eventfd does not support timeline semantics. Meaning that you would have to send two eventfds over the wire for each commit, one for the acquire point and one for the release point. Whereas with syncobj you only need to send two integers per commit.
I don't see the advantage when drm_syncobj already does everything we need.
You seem to believe that compositors would not be ready for this and from that perspective I can understand your apprehension. But I can assure you that compositors are already fully set up to support all of the usecases I've described: The wayland protocol requires the compositor to support wait before signal.
Regards, Christian.
What could be possible instead is to pass an eventfd into Wayland, but that is something userspace needs to decide.
- llvmpipe currently cannot offer syncobj interop because it does not have access to a DRM device. This means that applications using llvmpipe cannot present images before they have finished rendering, despite llvmpipe using threaded rendering.
Yeah, but that is completely intentional. You *CAN'T* use a dma_fence as completion event for llvmpipe rendering. See the kernel documentation on that.
What could be possible is to use the drm_syncobjs functionality to wait before signal, but that has different semantics.
Regards, Christian.
- Clients that do not use the Vulkan WSI need to manually probe /dev/dri for devices that support the syncobj ioctls in order to use the wayland syncobj protocol.
- Similarly, clients that want to use screen capture have no equivalent to the WSI and are therefore forced into that path.
- Having to keep a DRM device open has potentially negative interactions with GPU hotplug.
- Having to translate between syncobj FDs and handles is troublesome in the compositor usecase since syncobjs come and go frequently and need to be cleaned up when clients disconnect.
/dev/syncobj solves these issues by providing all syncobj ioctls under a consistent path that is not tied to any DRM device. It also operates directly on file descriptors instead of syncobj handles.
The series starts with a number of small refactorings in drm_syncobj.c to make its functionality available outside of the file and without the need for drm_file/handle pairs.
The last commit adds the /dev/syncobj module. I've added it as a misc device but maybe this should instead live somewhere under gpu/drm.
An application using the new interface can be found at [1].
Julian Orth (12): drm/syncobj: add drm_syncobj_from_fd drm/syncobj: add drm_syncobj_fence_lookup drm/syncobj: make drm_syncobj_array_wait_timeout public drm/syncobj: add drm_syncobj_register_eventfd drm/syncobj: have transfer functions accept drm_syncobj directly drm/syncobj: add drm_syncobj_transfer drm/syncobj: add drm_syncobj_timeline_signal drm/syncobj: add drm_syncobj_query drm/syncobj: fix resource leak in drm_syncobj_import_sync_file_fence drm/syncobj: add drm_syncobj_import_sync_file drm/syncobj: add drm_syncobj_export_sync_file misc/syncobj: add new device
Documentation/userspace-api/ioctl/ioctl-number.rst | 1 + drivers/gpu/drm/drm_syncobj.c | 374 ++++++++++++++----- drivers/misc/Kconfig | 10 + drivers/misc/Makefile | 1 + drivers/misc/syncobj.c | 404 +++++++++++++++++++++ include/drm/drm_syncobj.h | 21 ++ include/uapi/linux/syncobj.h | 75 ++++ 7 files changed, 795 insertions(+), 91 deletions(-)
base-commit: 6916d5703ddf9a38f1f6c2cc793381a24ee914c6 change-id: 20260516-jorth-syncobj-d4d374c8c61b
Best regards,
Julian Orth ju.orth@gmail.com