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.
What about using VGEM for this?
Regards, Christian.
Regards, Christian.