Re: [PATCH 00/12] misc/syncobj: add /dev/syncobj device

["Christian König" <christian.koenig@amd.com>]

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
>>> <christian.koenig@amd.com> 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.