On 5/18/26 16:59, Michel Dänzer wrote: > On 5/18/26 14:41, Christian König wrote: >> On 5/18/26 14:02, Julian Orth wrote: >>> On Mon, May 18, 2026 at 1:58 PM Christian König >>> <[email protected]> wrote: >>>> On 5/16/26 13:06, Julian Orth wrote: >>>>> This series adds a new device /dev/syncobj that can be used to create >>>>> and manipulate DRM syncobjs. Previously, these operations required the >>>>> use of a DRM device and the device needed to support the DRIVER_SYNCOBJ >>>>> and DRIVER_SYNCOBJ_TIMELINE features. >>>>> >>>>> There are several issues with the existing API: >>>>> >>>>> - Syncobjs are the only explicit sync mechanism available on wayland. >>>>> Most compositors do not use GPU waits. Instead, they use the >>>>> DRM_IOCTL_SYNCOBJ_EVENTFD ioctl to perform a CPU wait. Being tied to >>>>> DRM devices means that compositors cannot consistently offer this >>>>> feature even though no device-specific logic is involved. >>>> >>>> Well the drm_syncobj is a container for device specific dma fences. >>> >>> Not necessarily. The DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL ioctl attaches >>> some kind of dummy fence that is already signaled. I don't believe >>> this is device specific. That is also the path that llvmpipe would >>> use. >> >> Yeah I feared that. >> >> This is the wait before signal path and if I'm not completely mistaken that >> one is not supported by a lot of compositors. > > Where did you get that impression from?
Kernel space seems to not handle that support very well. We added the flag at some point for drivers, but only a fraction actually implemented it. I wasn't aware that the general eventfd implementation can handle it, but yeah when compositors use that one then that actually makes sense. > It's arguably the main point of the syncobj Wayland protocol extension, which > is supported by all major compositors (except Weston, where it's still a > pending MR). > > >> 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. > > I agree with Julian's rebuttal to that. That eventfd is missing the timeline functionality is a pretty good argument, but I'm still not sure if that justifies the extra kernel complexity. Regards, Christian.
