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. 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]. > > [1]: https://github.com/mahkoh/jay/pull/947 > > --- > 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 <[email protected]> >
