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

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

On 5/19/26 15:19, Julian Orth wrote:
> On Tue, May 19, 2026 at 10:18 AM Christian König
> <christian.koenig@amd.com> wrote:
>>
>> On 5/18/26 14:58, Julian Orth wrote:
>>> On Mon, May 18, 2026 at 2:41 PM Christian König
>>> <christian.koenig@amd.com> 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.