On Mon, May 18, 2026 at 1:58 PM Christian König <[email protected]> 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. > > 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]> > > >
