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(-)
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.
- 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.
- 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>
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> >
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. > > 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> > > >
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> >>> >>
On 5/18/26 14:41, Christian König 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. Where did you get that impression from? It's arguably the main point of the syncobj Wayland protocol extension, which is supported by all major compositors (except Weston, where it's still a pending MR). > 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. I agree with Julian's rebuttal to that. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
On 5/18/26 16:59, Michel Dänzer wrote: > On 5/18/26 14:41, Christian König 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. > > Where did you get that impression from? Kernel space seems to not handle that support very well. We added the flag at some point for drivers, but only a fraction actually implemented it. I wasn't aware that the general eventfd implementation can handle it, but yeah when compositors use that one then that actually makes sense. > It's arguably the main point of the syncobj Wayland protocol extension, which is supported by all major compositors (except Weston, where it's still a pending MR). > > >> 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. > > I agree with Julian's rebuttal to that. That eventfd is missing the timeline functionality is a pretty good argument, but I'm still not sure if that justifies the extra kernel complexity. Regards, Christian.
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-4446117280. 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]. > >>> > >>> [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> > >>> > >> >
On 5/18/26 14:58, Julian Orth wrote: > On Mon, May 18, 2026 at 2:41 PM Christian König > <christian.koenig@amd.com> wrote: ... >> 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-4446117280. > 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. Yeah that's much better than I thought it would be. And that eventfds don't support timeline points is indeed a pretty good argument. But I still don't see much justification for creating a /dev/syncobj device, this is clearly something DRM specific. What about using VGEM for this? Regards, Christian. > >> >> Regards, >> Christian.
On Tue, May 19, 2026 at 10:18 AM Christian König <christian.koenig@amd.com> wrote: > > On 5/18/26 14:58, Julian Orth wrote: > > On Mon, May 18, 2026 at 2:41 PM Christian König > > <christian.koenig@amd.com> wrote: > ... > >> 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-4446117280. > > 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. > Yeah that's much better than I thought it would be. > > And that eventfds don't support timeline points is indeed a pretty good argument. > > But I still don't see much justification for creating a /dev/syncobj device, this is clearly something DRM specific. The justification is given in the cover letter. To repeat them briefly: 1. This series makes the ability to manipulate syncobjs available independently of attached hardware. 2. It makes it available under a consistent path /dev/syncobj. 3. It removes the need to translate between syncobjs fds and handles. > > What about using VGEM for this? If the vgem render node were made available unconditionally under, say, /dev/vgem and DRIVER_SYNCOBJ_TIMELINE were added to the driver, then maybe that could solve points 1 and 2 above. But it would not solve point 3 and it sounds like a hack to me to have a render node available outside of /dev/dri. > > Regards, > Christian. > > > > >> > >> Regards, > >> Christian.
On 5/19/26 15:19, Julian Orth wrote: > On Tue, May 19, 2026 at 10:18 AM Christian König > <christian.koenig@amd.com> wrote: >> >> On 5/18/26 14:58, Julian Orth wrote: >>> On Mon, May 18, 2026 at 2:41 PM Christian König >>> <christian.koenig@amd.com> wrote: >> ... >>>> 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-4446117280. >>> 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. >> Yeah that's much better than I thought it would be. >> >> And that eventfds don't support timeline points is indeed a pretty good argument. >> >> But I still don't see much justification for creating a /dev/syncobj device, this is clearly something DRM specific. > > The justification is given in the cover letter. To repeat them briefly: > > 1. This series makes the ability to manipulate syncobjs available > independently of attached hardware. > 2. It makes it available under a consistent path /dev/syncobj. Exactly that is a big no-go. This has to be under /dev/dri. > 3. It removes the need to translate between syncobjs fds and handles. That's a pretty big no-go as well. The differentiation between FDs and handles is completely intentional. > >> >> What about using VGEM for this? > > If the vgem render node were made available unconditionally under, Software rendering is a complete corner case, I don't think that this will be enabled by default. Regards, Christian. > say, /dev/vgem and DRIVER_SYNCOBJ_TIMELINE were added to the driver, > then maybe that could solve points 1 and 2 above. > > But it would not solve point 3 and it sounds like a hack to me to have > a render node available outside of /dev/dri. > >> >> Regards, >> Christian. >> >>> >>>> >>>> Regards, >>>> Christian.
Am Di., 19. Mai 2026 um 15:29 Uhr schrieb Christian König <christian.koenig@amd.com>: > > 1. This series makes the ability to manipulate syncobjs available > > independently of attached hardware. > > 2. It makes it available under a consistent path /dev/syncobj. > > Exactly that is a big no-go. This has to be under /dev/dri. FWIW udmabuf is also under /dev directly, but I don't think any compositor developer would complain about a different path. What are the rules for that? Could this simply be put in /dev/dri/syncobj? The part where we get this independent of attached hardware is quite important for us though, since we can't just ignore explicit sync once the device we previously imported the syncobj into is disconnected. Buffers can be from any device or allocated in system memory and access should be synchronized properly in all cases. How exactly it's made available isn't all that critical. > > 3. It removes the need to translate between syncobjs fds and handles. > > That's a pretty big no-go as well. The differentiation between FDs and handles is completely intentional. Could you expand on why it's needed? For compositors, the handle is just an intermediary thing when translating between file descriptors. FTR for me at least, this part would be merely nice to have, since it slightly reduces the amount of ioctls a compositor needs to call, but it's not important. > >> What about using VGEM for this? > > > > If the vgem render node were made available unconditionally under, > > Software rendering is a complete corner case, I don't think that this will be enabled by default. That simply makes vgem unsuitable for solving the problems we face in compositors. - Xaver
On 5/19/26 17:31, Xaver Hugl wrote: > Am Di., 19. Mai 2026 um 15:29 Uhr schrieb Christian König > <christian.koenig@amd.com>: >>> 1. This series makes the ability to manipulate syncobjs available >>> independently of attached hardware. >>> 2. It makes it available under a consistent path /dev/syncobj. >> >> Exactly that is a big no-go. This has to be under /dev/dri. > FWIW udmabuf is also under /dev directly, but I don't think any > compositor developer would complain about a different path. > What are the rules for that? Could this simply be put in /dev/dri/syncobj? The syncobj are actually the DRM specific way of doing things. The general kernel wide way is to use sync files (see drivers/dma-buf/sync_file.c). But there has already been tons of problems with those sync files. E.g. they doesn't support your use case at all since they don't have wait before submit behavior. So there are already ways to do this, but the Linux kernel so far told everybody that this is forbidden. The DRM syncobj wait before signal functionality is much better, but then basically the second try to do this. > The part where we get this independent of attached hardware is quite > important for us though, since we can't just ignore explicit sync once > the device we previously imported the syncobj into is disconnected. Can you elaborate more on this? > Buffers can be from any device or allocated in system memory and > access should be synchronized properly in all cases. > > How exactly it's made available isn't all that critical. > >>> 3. It removes the need to translate between syncobjs fds and handles. >> >> That's a pretty big no-go as well. The differentiation between FDs and handles is completely intentional. > Could you expand on why it's needed? For compositors, the handle is > just an intermediary thing when translating between file descriptors. Well what we could do is to add an IOCTL to directly attach an syncobj file descriptor to an eventfd. > FTR for me at least, this part would be merely nice to have, since it > slightly reduces the amount of ioctls a compositor needs to call, but > it's not important. > >>>> What about using VGEM for this? >>> >>> If the vgem render node were made available unconditionally under, >> >> Software rendering is a complete corner case, I don't think that this will be enabled by default. > That simply makes vgem unsuitable for solving the problems we face in > compositors. Thinking more about it vgem also has the same issues as sync file mentioned above. So that is really also not doable. Maybe Simona or David have another idea. Regards, Christian. > > - Xaver
On 5/19/26 18:00, Christian König wrote: > On 5/19/26 17:31, Xaver Hugl wrote: >> Am Di., 19. Mai 2026 um 15:29 Uhr schrieb Christian König >> <christian.koenig@amd.com>: >>>> 1. This series makes the ability to manipulate syncobjs available >>>> independently of attached hardware. >>>> 2. It makes it available under a consistent path /dev/syncobj. >>> >>> Exactly that is a big no-go. This has to be under /dev/dri. >> FWIW udmabuf is also under /dev directly, but I don't think any >> compositor developer would complain about a different path. >> What are the rules for that? Could this simply be put in /dev/dri/syncobj? > > The syncobj are actually the DRM specific way of doing things. The general kernel wide way is to use sync files (see drivers/dma-buf/sync_file.c). > > But there has already been tons of problems with those sync files. E.g. they doesn't support your use case at all since they don't have wait before submit behavior. > > So there are already ways to do this, but the Linux kernel so far told everybody that this is forbidden. The DRM syncobj wait before signal functionality is much better, but then basically the second try to do this. I'm not quite sure what you're getting at here, just to be clear though: While the syncobj Wayland protocol extension supports wait-before-submit behaviour at the Wayland protocol level, it doesn't need or cause wait-before-submit behaviour for DMA fences in the kernel. The usual rules apply to fences attached to syncobj timeline points. The wait-before-submit behaviour at the Wayland protocol level comes from allowing submit before a fence is attached to the acquire timeline point. (It took me a while to realize this distinction, before which I mistakenly thought the kernel's DMA fence rules would prohibit wait-before-submit behaviour at the Wayland protocol level as well) -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
On 5/20/26 10:13, Michel Dänzer wrote: > On 5/19/26 18:00, Christian König wrote: >> On 5/19/26 17:31, Xaver Hugl wrote: >>> Am Di., 19. Mai 2026 um 15:29 Uhr schrieb Christian König >>> <christian.koenig@amd.com>: >>>>> 1. This series makes the ability to manipulate syncobjs available >>>>> independently of attached hardware. >>>>> 2. It makes it available under a consistent path /dev/syncobj. >>>> >>>> Exactly that is a big no-go. This has to be under /dev/dri. >>> FWIW udmabuf is also under /dev directly, but I don't think any >>> compositor developer would complain about a different path. >>> What are the rules for that? Could this simply be put in /dev/dri/syncobj? >> >> The syncobj are actually the DRM specific way of doing things. The general kernel wide way is to use sync files (see drivers/dma-buf/sync_file.c). >> >> But there has already been tons of problems with those sync files. E.g. they doesn't support your use case at all since they don't have wait before submit behavior. >> >> So there are already ways to do this, but the Linux kernel so far told everybody that this is forbidden. The DRM syncobj wait before signal functionality is much better, but then basically the second try to do this. > > I'm not quite sure what you're getting at here, just to be clear though: > > While the syncobj Wayland protocol extension supports wait-before-submit behaviour at the Wayland protocol level, it doesn't need or cause wait-before-submit behaviour for DMA fences in the kernel. The usual rules apply to fences attached to syncobj timeline points. The wait-before-submit behaviour at the Wayland protocol level comes from allowing submit before a fence is attached to the acquire timeline point. Yeah I know. I'm one of the people who came up with the idea of doing wait before signal this way in the drm_syncobj. What I wanted to say is that a lot of people used the dma_fence to implement wait before signal before and got a bloody nose from that. > (It took me a while to realize this distinction, before which I mistakenly thought the kernel's DMA fence rules would prohibit wait-before-submit behaviour at the Wayland protocol level as well) This is what surprised me. The drm_syncobj implementation solved the wait before signal for the kernel, but my last feedback was that we basically just moved the issue to userspace and Wayland compositors would have quite some overhead to implement it correctly. That compositors now use eventfd to simplify that was news to me but makes totally sense in hindsight. But anyway, we need to somehow simplify the drm_syncobj -> eventfd usage in the compositor. That requirement is perfectly justified and avoiding importing the drm_syncobj fd into any DRM driver should actually be really easy to implement. Regards, Christian.
On Wed, May 20, 2026 at 1:21 PM Christian König <christian.koenig@amd.com> wrote: > > On 5/20/26 10:13, Michel Dänzer wrote: > > On 5/19/26 18:00, Christian König wrote: > >> On 5/19/26 17:31, Xaver Hugl wrote: > >>> Am Di., 19. Mai 2026 um 15:29 Uhr schrieb Christian König > >>> <christian.koenig@amd.com>: > >>>>> 1. This series makes the ability to manipulate syncobjs available > >>>>> independently of attached hardware. > >>>>> 2. It makes it available under a consistent path /dev/syncobj. > >>>> > >>>> Exactly that is a big no-go. This has to be under /dev/dri. > >>> FWIW udmabuf is also under /dev directly, but I don't think any > >>> compositor developer would complain about a different path. > >>> What are the rules for that? Could this simply be put in /dev/dri/syncobj? > >> > >> The syncobj are actually the DRM specific way of doing things. The general kernel wide way is to use sync files (see drivers/dma-buf/sync_file.c). > >> > >> But there has already been tons of problems with those sync files. E.g. they doesn't support your use case at all since they don't have wait before submit behavior. > >> > >> So there are already ways to do this, but the Linux kernel so far told everybody that this is forbidden. The DRM syncobj wait before signal functionality is much better, but then basically the second try to do this. > > > > I'm not quite sure what you're getting at here, just to be clear though: > > > > While the syncobj Wayland protocol extension supports wait-before-submit behaviour at the Wayland protocol level, it doesn't need or cause wait-before-submit behaviour for DMA fences in the kernel. The usual rules apply to fences attached to syncobj timeline points. The wait-before-submit behaviour at the Wayland protocol level comes from allowing submit before a fence is attached to the acquire timeline point. > > Yeah I know. I'm one of the people who came up with the idea of doing wait before signal this way in the drm_syncobj. > > What I wanted to say is that a lot of people used the dma_fence to implement wait before signal before and got a bloody nose from that. > > > (It took me a while to realize this distinction, before which I mistakenly thought the kernel's DMA fence rules would prohibit wait-before-submit behaviour at the Wayland protocol level as well) > > This is what surprised me. > > The drm_syncobj implementation solved the wait before signal for the kernel, but my last feedback was that we basically just moved the issue to userspace and Wayland compositors would have quite some overhead to implement it correctly. > > That compositors now use eventfd to simplify that was news to me but makes totally sense in hindsight. > > But anyway, we need to somehow simplify the drm_syncobj -> eventfd usage in the compositor. That is not the only usage in the compositor. Compositors use all of the following operations on syncobjs: - creating syncobjs - waiting for points synchronously - signaling points without a sync file - querying points - transferring sync files between points - exporting sync files - importing sync files Which you can see by looking at the userspace code linked in the cover letter. Bypassing the handle in one ioctl would gain compositors nothing since they would still have to convert to handles and manage their lifetime for all other ioctls. > That requirement is perfectly justified and avoiding importing the drm_syncobj fd into any DRM driver should actually be really easy to implement. That is what this series does. > > Regards, > Christian.
> > The part where we get this independent of attached hardware is quite > > important for us though, since we can't just ignore explicit sync once > > the device we previously imported the syncobj into is disconnected. > > Can you elaborate more on this? In Wayland, the client is allowed to attach dmabuf and syncobj independently, they don't have to be from the same device (and the compositor wouldn't be able to verify the opposite anyways). The compositor will usually import both into the same drm device, but especially with compositors that render on multiple devices, that's not necessarily the case either. If for example we had a system with one internal GPU and one external GPU, the client renders on the internal GPU and the compositor uses the external one. Now when the user yanks the USB C cable, afaiu - the buffers from the client stay valid - the syncobj stays valid on the client side - the syncobj becomes invalid on the compositor side "invalid" there means either - the acquire point of the client is marked as signaled, before rendering on the client side is completed - the acquire point of the client is never signaled. Since the compositor waits for the acquire point, the Wayland surface is stuck forever Afaik the latter is currently the case. The former wouldn't be much better though, not when it's preventable. This is admittedly an edge case, but GPU hotunplug is something we try to support as well as possible in Plasma, and all the edge cases cause a lot of problems in combination and are a lot of headaches to handle (or really work around) in the compositor. Another edge case is when the client asks the compositor to import the syncobj, which can fail when a hotunplug is in process, and ends up disconnecting the client for no fault of either client or compositor. > >>> 3. It removes the need to translate between syncobjs fds and handles. > >> > >> That's a pretty big no-go as well. The differentiation between FDs and handles is completely intentional. > > Could you expand on why it's needed? For compositors, the handle is > > just an intermediary thing when translating between file descriptors. > > Well what we could do is to add an IOCTL to directly attach an syncobj file descriptor to an eventfd. That would be nice. - Xaver
On 5/19/26 19:08, Xaver Hugl wrote: >>> The part where we get this independent of attached hardware is quite >>> important for us though, since we can't just ignore explicit sync once >>> the device we previously imported the syncobj into is disconnected. >> >> Can you elaborate more on this? > > In Wayland, the client is allowed to attach dmabuf and syncobj > independently, they don't have to be from the same device (and the > compositor wouldn't be able to verify the opposite anyways). The > compositor will usually import both into the same drm device, but > especially with compositors that render on multiple devices, that's > not necessarily the case either. > > If for example we had a system with one internal GPU and one external > GPU, the client renders on the internal GPU and the compositor uses > the external one. Now when the user yanks the USB C cable, afaiu Well I would say the other way around is a pretty common use case. In other words the compositors uses the internal GPU for composing and displaying the picture. And the client uses the external GPU for fast rendering. > - the buffers from the client stay valid Buffers from the hot plugged GPU don't stay valid. Accessing CPU mappings either result in a SIGBUS or are redirected to a dummy page. DMA operations to hot plugged buffers from other GPUs (or rather more general other devices) are waited on before the underlying resource is removed (e.g. system memory or PCIe address space or whatever is backing that). But no new DMA operations are usually permitted to start. > - the syncobj stays valid on the client side > - the syncobj becomes invalid on the compositor side Nope that's not correct. The syncobj itself stays valid even if you completely hot plug the device. It can just be that the fences inside the syncobj are terminated with an error. > "invalid" there means either > - the acquire point of the client is marked as signaled, before > rendering on the client side is completed > - the acquire point of the client is never signaled. Since the > compositor waits for the acquire point, the Wayland surface is stuck > forever Both of those would be a *massive* violation of documented kernel rules for hot-plugging which could lead to random data corruption and/or deadlocks. If you see any HW driver showing behavior like that please open up a bug report and ping the relevant maintainers immediately. When a hotplug happens all operations of the device should return an -ENODEV error, even when exposed to other devices/application through syncobj or syncfile. One problem is that only syncfile allows for querying such error codes at the moment, we have patches pending to add that to syncobj as well but we lack a compositor with support for that as userspace client. > Afaik the latter is currently the case. The former wouldn't be much > better though, not when it's preventable. > > This is admittedly an edge case, but GPU hotunplug is something we try > to support as well as possible in Plasma, and all the edge cases cause > a lot of problems in combination and are a lot of headaches to handle > (or really work around) in the compositor. Well exactly that design is used in the Tesla 3 infotainment system for example. So GPU hotplug is actually a pretty common use case. > Another edge case is when the client asks the compositor to import the > syncobj, which can fail when a hotunplug is in process, and ends up > disconnecting the client for no fault of either client or compositor. Well the question here is if the device the compositor is using or the client is using is gone? If the client device is hot removed the compositor should be perfectly capable to import the syncobj. If the compositor device is gone then you don't have a device to display anything any more, so generating the next frame doesn't seem to make sense either. What could be is that you want the compositor to be kept alive even when the display device is gone to switch over to vkms or whatever so that a VNC session or other remote desktop still works. >>>>> 3. It removes the need to translate between syncobjs fds and handles. >>>> >>>> That's a pretty big no-go as well. The differentiation between FDs and handles is completely intentional. >>> Could you expand on why it's needed? For compositors, the handle is >>> just an intermediary thing when translating between file descriptors. >> >> Well what we could do is to add an IOCTL to directly attach an syncobj file descriptor to an eventfd. > That would be nice. Take a look at drm_syncobj_file_fops and how drm_syncobj_add_eventfd() is used. Adding that functionality shouldn't be more than a typing exercise. Do I see it right that this would already solve most problems in the compositor side? Regards, Christian. > > - Xaver
Am Mi., 20. Mai 2026 um 10:08 Uhr schrieb Christian König <christian.koenig@amd.com>: > Well I would say the other way around is a pretty common use case. > > In other words the compositors uses the internal GPU for composing and displaying the picture. And the client uses the external GPU for fast rendering. Sure, but that's not what I'm talking about. > > - the buffers from the client stay valid > > Buffers from the hot plugged GPU don't stay valid. Accessing CPU mappings either result in a SIGBUS or are redirected to a dummy page. Again, not what I wrote about. The buffers are on the integrated GPU. > > - the syncobj stays valid on the client side > > - the syncobj becomes invalid on the compositor side > > Nope that's not correct. The syncobj itself stays valid even if you completely hot plug the device. > > It can just be that the fences inside the syncobj are terminated with an error. What about eventfd created for a point on the syncobj? Another (future) problem with hotplugs will be if the sync file hasn't materialized for the timeline point when the device is hotunplugged, since there can't be an error on the fence if there isn't one. Or could userspace somehow set an 'artificial' fence with an error in that case? > > "invalid" there means either > > - the acquire point of the client is marked as signaled, before > > rendering on the client side is completed > > - the acquire point of the client is never signaled. Since the > > compositor waits for the acquire point, the Wayland surface is stuck > > forever > > Both of those would be a *massive* violation of documented kernel rules for hot-plugging which could lead to random data corruption and/or deadlocks. > > If you see any HW driver showing behavior like that please open up a bug report and ping the relevant maintainers immediately. If there are no error codes with syncobj yet, then to userspace, the latter behavior is exactly what we get, isn't it? > When a hotplug happens all operations of the device should return an -ENODEV error, even when exposed to other devices/application through syncobj or syncfile. Okay, that at least gives us a way to fail imports somewhat gracefully. Normally, failing to import a syncobj is a fatal error in the Wayland protocol. > One problem is that only syncfile allows for querying such error codes at the moment, we have patches pending to add that to syncobj as well but we lack a compositor with support for that as userspace client. As long as the error case can be detected with an eventfd, implementing that in KWin shouldn't be a challenge. > Well the question here is if the device the compositor is using or the client is using is gone? > > If the client device is hot removed the compositor should be perfectly capable to import the syncobj. > > If the compositor device is gone then you don't have a device to display anything any more, so generating the next frame doesn't seem to make sense either. > > What could be is that you want the compositor to be kept alive even when the display device is gone to switch over to vkms or whatever so that a VNC session or other remote desktop still works. There are two GPUs in the example I gave. The compositor can use both for rendering (in cosmic-comp's case) or switch between them (what I'm trying to do with KWin), or use one device for rendering, and another for importing the syncobj. > >>>>> 3. It removes the need to translate between syncobjs fds and handles. > >>>> > >>>> That's a pretty big no-go as well. The differentiation between FDs and handles is completely intentional. > >>> Could you expand on why it's needed? For compositors, the handle is > >>> just an intermediary thing when translating between file descriptors. > >> > >> Well what we could do is to add an IOCTL to directly attach an syncobj file descriptor to an eventfd. > > That would be nice. > > Take a look at drm_syncobj_file_fops and how drm_syncobj_add_eventfd() is used. Adding that functionality shouldn't be more than a typing exercise. Yeah, this patchset already adds that functionality (on the new device). > Do I see it right that this would already solve most problems in the compositor side? Skipping the syncobj handle step would only reduce the amounts of ioctls the compositor does, but afaict it wouldn't solve any compositor problems. At least not as long as it's still tied to a drm device. For device hotplugs, the only new thing we need for correctly handling syncobj is a way to receive errors on the eventfd. A device-independent way to create and use syncobj would still be useful to us though, both to simplify the compositor and to improve the software rendering use cases. - Xaver
On 5/20/26 14:33, Xaver Hugl wrote: > Am Mi., 20. Mai 2026 um 10:08 Uhr schrieb Christian König > <christian.koenig@amd.com>: >> Well I would say the other way around is a pretty common use case. >> >> In other words the compositors uses the internal GPU for composing and displaying the picture. And the client uses the external GPU for fast rendering. > Sure, but that's not what I'm talking about. Yeah sorry for that, I wasn't sure if I misunderstood your use case because it's usually the other way around. >>> - the buffers from the client stay valid >> >> Buffers from the hot plugged GPU don't stay valid. Accessing CPU mappings either result in a SIGBUS or are redirected to a dummy page. > Again, not what I wrote about. The buffers are on the integrated GPU. General rule of thumb is that as long as the exporter stays around the buffers stay around as well. >>> - the syncobj stays valid on the client side >>> - the syncobj becomes invalid on the compositor side >> >> Nope that's not correct. The syncobj itself stays valid even if you completely hot plug the device. >> >> It can just be that the fences inside the syncobj are terminated with an error. > What about eventfd created for a point on the syncobj? The eventfd unfortunately doesn't has error handling as far as I know, so when a fence signals with an error condition then the eventfd you only sees that it is signaled. > Another (future) problem with hotplugs will be if the sync file hasn't > materialized for the timeline point when the device is hotunplugged, > since there can't be an error on the fence if there isn't one. Or > could userspace somehow set an 'artificial' fence with an error in > that case? In general the answer is yes, userspace needs to take care of inserting fences when wait before signal is used and the work can not be submitted to the HW for some reason. Currently we only have an IOCTL to insert the signaled dummy fence at some timeline sequence, but it should be trivial as well to insert a signaled fence with an error code. But the compositor needs to be able to handle that case anyway, because it can be that a malicious or just buggy client just never inserts the fence. So that a device is hot plugged is not different to just a client not inserting the fence in the first place. >>> "invalid" there means either >>> - the acquire point of the client is marked as signaled, before >>> rendering on the client side is completed >>> - the acquire point of the client is never signaled. Since the >>> compositor waits for the acquire point, the Wayland surface is stuck >>> forever >> >> Both of those would be a *massive* violation of documented kernel rules for hot-plugging which could lead to random data corruption and/or deadlocks. >> >> If you see any HW driver showing behavior like that please open up a bug report and ping the relevant maintainers immediately. > If there are no error codes with syncobj yet, then to userspace, the > latter behavior is exactly what we get, isn't it? No, from userspace side you just see a signaled fence. It's just that you need to export the timeline point of the syncobj to a syncfile and then you can call the QUERY IOCTL on the syncfile to see the error code. >> When a hotplug happens all operations of the device should return an -ENODEV error, even when exposed to other devices/application through syncobj or syncfile. > Okay, that at least gives us a way to fail imports somewhat > gracefully. Normally, failing to import a syncobj is a fatal error in > the Wayland protocol. So the task at hand would be to avoid importing the syncobj into a driver. That should be relatively trivial. The only real problem I see is if you want to create a syncobj without having any device whatsoever. >> One problem is that only syncfile allows for querying such error codes at the moment, we have patches pending to add that to syncobj as well but we lack a compositor with support for that as userspace client. > As long as the error case can be detected with an eventfd, Yeah that's the problem. The eventfd only tells you if the operation is completed (or at least has materialized). To query the error you would need to ask the underlying syncobj or syncfile directly. > implementing that in KWin shouldn't be a challenge. > >> Well the question here is if the device the compositor is using or the client is using is gone? >> >> If the client device is hot removed the compositor should be perfectly capable to import the syncobj. >> >> If the compositor device is gone then you don't have a device to display anything any more, so generating the next frame doesn't seem to make sense either. >> >> What could be is that you want the compositor to be kept alive even when the display device is gone to switch over to vkms or whatever so that a VNC session or other remote desktop still works. > There are two GPUs in the example I gave. The compositor can use both > for rendering (in cosmic-comp's case) or switch between them (what I'm > trying to do with KWin), or use one device for rendering, and another > for importing the syncobj. Ah! I think I got the problem now. You basically want to avoid importing the syncobj because when the wrong device goes away you are busted. The reason we didn't considered having the IOCTLs on the FD is because if you don't import them and instead keep them around you can run out file descriptors quite quickly. When you have an use case where you receive an FD from the client and do a one shot conversion to an eventfd that will probably work, but for keeping them in the long run you need some kind of container for the syncobjs, don't you? >>>>>>> 3. It removes the need to translate between syncobjs fds and handles. >>>>>> >>>>>> That's a pretty big no-go as well. The differentiation between FDs and handles is completely intentional. >>>>> Could you expand on why it's needed? For compositors, the handle is >>>>> just an intermediary thing when translating between file descriptors. >>>> >>>> Well what we could do is to add an IOCTL to directly attach an syncobj file descriptor to an eventfd. >>> That would be nice. >> >> Take a look at drm_syncobj_file_fops and how drm_syncobj_add_eventfd() is used. Adding that functionality shouldn't be more than a typing exercise. > Yeah, this patchset already adds that functionality (on the new device). > >> Do I see it right that this would already solve most problems in the compositor side? > Skipping the syncobj handle step would only reduce the amounts of > ioctls the compositor does, but afaict it wouldn't solve any > compositor problems. At least not as long as it's still tied to a drm > device. Yeah, you need something like a syncobj container or dummy DRM device. > For device hotplugs, the only new thing we need for correctly handling > syncobj is a way to receive errors on the eventfd. I need to look into the eventfd code, could be that this is somehow possible but it's clearly not something I used before. > A device-independent way to create and use syncobj would still be > useful to us though, both to simplify the compositor and to improve > the software rendering use cases. Yeah not sure how to cleanly do that. We could have a dummy /dev/dri/rendersync or something like that, but that would be quite a hack. At least I understand the requirement now. Thanks, Christian. > > - Xaver
> In general the answer is yes, userspace needs to take care of inserting fences when wait before signal is used and the work can not be submitted to the HW for some reason. > > Currently we only have an IOCTL to insert the signaled dummy fence at some timeline sequence, but it should be trivial as well to insert a signaled fence with an error code. > > But the compositor needs to be able to handle that case anyway, because it can be that a malicious or just buggy client just never inserts the fence. > > So that a device is hot plugged is not different to just a client not inserting the fence in the first place. A buggy client can always freeze its own surface, it doesn't need handling beyond cleaning up properly when the client disconnects. The hotplug case is different, since currently a well-behaved client can only attempt to signal the point in the syncobj... but the drm device is gone, so the ioctl will fail and the client's surface is frozen, even though it did everything right. So afaict, whatever new ioctl is added for this will need to be independent of the drm device, or be special cased not to fail when the device is removed. > >> One problem is that only syncfile allows for querying such error codes at the moment, we have patches pending to add that to syncobj as well but we lack a compositor with support for that as userspace client. > > As long as the error case can be detected with an eventfd, > > Yeah that's the problem. The eventfd only tells you if the operation is completed (or at least has materialized). > > To query the error you would need to ask the underlying syncobj or syncfile directly. Issuing an additional ioctl after the eventfd fired for this rare case wouldn't be particularly nice, but also not difficult. If we'd get that with the eventfd directly, that would be much better though. > Ah! I think I got the problem now. You basically want to avoid importing the syncobj because when the wrong device goes away you are busted. Exactly. > The reason we didn't considered having the IOCTLs on the FD is because if you don't import them and instead keep them around you can run out file descriptors quite quickly. > > When you have an use case where you receive an FD from the client and do a one shot conversion to an eventfd that will probably work, but for keeping them in the long run you need some kind of container for the syncobjs, don't you? Compositors always run with vastly increased fd limits since they have to handle a lot of fds for dmabufs alone, so keeping the fd around wouldn't be an issue for us. > > A device-independent way to create and use syncobj would still be > > useful to us though, both to simplify the compositor and to improve > > the software rendering use cases. > > Yeah not sure how to cleanly do that. We could have a dummy /dev/dri/rendersync or something like that, but that would be quite a hack. I think for userspace it would be less of a hack than searching for a random drm node that can import it. I'd gladly take another solution as well though, if there is one. - Xaver
© 2016 - 2026 Red Hat, Inc.