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

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

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.

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.

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.

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].
>>>
>>> [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>
>>>
>>