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-4446117.... 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:
- 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.
- 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.