Re: [PATCH 00/12] misc/syncobj: add /dev/syncobj device

["Christian König" <christian.koenig@amd.com>]

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 <ju.orth@gmail.com>
>