On Tue, May 19, 2026 at 10:18 AM Christian König <[email protected]> wrote: > > 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.
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.
