On 5/19/26 15:19, Julian Orth wrote: > 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.
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.
