On 5/18/26 14:58, Julian Orth wrote: > On Mon, May 18, 2026 at 2:41 PM Christian König > <[email protected]> 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.
