On 5/19/26 17:31, Xaver Hugl wrote:
Am Di., 19. Mai 2026 um 15:29 Uhr schrieb Christian König christian.koenig@amd.com:
- 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.
FWIW udmabuf is also under /dev directly, but I don't think any compositor developer would complain about a different path. What are the rules for that? Could this simply be put in /dev/dri/syncobj?
The syncobj are actually the DRM specific way of doing things. The general kernel wide way is to use sync files (see drivers/dma-buf/sync_file.c).
But there has already been tons of problems with those sync files. E.g. they doesn't support your use case at all since they don't have wait before submit behavior.
So there are already ways to do this, but the Linux kernel so far told everybody that this is forbidden. The DRM syncobj wait before signal functionality is much better, but then basically the second try to do this.
The part where we get this independent of attached hardware is quite important for us though, since we can't just ignore explicit sync once the device we previously imported the syncobj into is disconnected.
Can you elaborate more on this?
Buffers can be from any device or allocated in system memory and access should be synchronized properly in all cases.
How exactly it's made available isn't all that critical.
- 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.
Could you expand on why it's needed? For compositors, the handle is just an intermediary thing when translating between file descriptors.
Well what we could do is to add an IOCTL to directly attach an syncobj file descriptor to an eventfd.
FTR for me at least, this part would be merely nice to have, since it slightly reduces the amount of ioctls a compositor needs to call, but it's not important.
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.
That simply makes vgem unsuitable for solving the problems we face in compositors.
Thinking more about it vgem also has the same issues as sync file mentioned above. So that is really also not doable.
Maybe Simona or David have another idea.
Regards, Christian.
- Xaver
On 5/19/26 18:00, Christian König wrote:
On 5/19/26 17:31, Xaver Hugl wrote:
Am Di., 19. Mai 2026 um 15:29 Uhr schrieb Christian König christian.koenig@amd.com:
- 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.
FWIW udmabuf is also under /dev directly, but I don't think any compositor developer would complain about a different path. What are the rules for that? Could this simply be put in /dev/dri/syncobj?
The syncobj are actually the DRM specific way of doing things. The general kernel wide way is to use sync files (see drivers/dma-buf/sync_file.c).
But there has already been tons of problems with those sync files. E.g. they doesn't support your use case at all since they don't have wait before submit behavior.
So there are already ways to do this, but the Linux kernel so far told everybody that this is forbidden. The DRM syncobj wait before signal functionality is much better, but then basically the second try to do this.
I'm not quite sure what you're getting at here, just to be clear though:
While the syncobj Wayland protocol extension supports wait-before-submit behaviour at the Wayland protocol level, it doesn't need or cause wait-before-submit behaviour for DMA fences in the kernel. The usual rules apply to fences attached to syncobj timeline points. The wait-before-submit behaviour at the Wayland protocol level comes from allowing submit before a fence is attached to the acquire timeline point.
(It took me a while to realize this distinction, before which I mistakenly thought the kernel's DMA fence rules would prohibit wait-before-submit behaviour at the Wayland protocol level as well)
On 5/20/26 10:13, Michel Dänzer wrote:
On 5/19/26 18:00, Christian König wrote:
On 5/19/26 17:31, Xaver Hugl wrote:
Am Di., 19. Mai 2026 um 15:29 Uhr schrieb Christian König christian.koenig@amd.com:
- 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.
FWIW udmabuf is also under /dev directly, but I don't think any compositor developer would complain about a different path. What are the rules for that? Could this simply be put in /dev/dri/syncobj?
The syncobj are actually the DRM specific way of doing things. The general kernel wide way is to use sync files (see drivers/dma-buf/sync_file.c).
But there has already been tons of problems with those sync files. E.g. they doesn't support your use case at all since they don't have wait before submit behavior.
So there are already ways to do this, but the Linux kernel so far told everybody that this is forbidden. The DRM syncobj wait before signal functionality is much better, but then basically the second try to do this.
I'm not quite sure what you're getting at here, just to be clear though:
While the syncobj Wayland protocol extension supports wait-before-submit behaviour at the Wayland protocol level, it doesn't need or cause wait-before-submit behaviour for DMA fences in the kernel. The usual rules apply to fences attached to syncobj timeline points. The wait-before-submit behaviour at the Wayland protocol level comes from allowing submit before a fence is attached to the acquire timeline point.
Yeah I know. I'm one of the people who came up with the idea of doing wait before signal this way in the drm_syncobj.
What I wanted to say is that a lot of people used the dma_fence to implement wait before signal before and got a bloody nose from that.
(It took me a while to realize this distinction, before which I mistakenly thought the kernel's DMA fence rules would prohibit wait-before-submit behaviour at the Wayland protocol level as well)
This is what surprised me.
The drm_syncobj implementation solved the wait before signal for the kernel, but my last feedback was that we basically just moved the issue to userspace and Wayland compositors would have quite some overhead to implement it correctly.
That compositors now use eventfd to simplify that was news to me but makes totally sense in hindsight.
But anyway, we need to somehow simplify the drm_syncobj -> eventfd usage in the compositor. That requirement is perfectly justified and avoiding importing the drm_syncobj fd into any DRM driver should actually be really easy to implement.
Regards, Christian.
On Wed, May 20, 2026 at 1:21 PM Christian König christian.koenig@amd.com wrote:
On 5/20/26 10:13, Michel Dänzer wrote:
On 5/19/26 18:00, Christian König wrote:
On 5/19/26 17:31, Xaver Hugl wrote:
Am Di., 19. Mai 2026 um 15:29 Uhr schrieb Christian König christian.koenig@amd.com:
- 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.
FWIW udmabuf is also under /dev directly, but I don't think any compositor developer would complain about a different path. What are the rules for that? Could this simply be put in /dev/dri/syncobj?
The syncobj are actually the DRM specific way of doing things. The general kernel wide way is to use sync files (see drivers/dma-buf/sync_file.c).
But there has already been tons of problems with those sync files. E.g. they doesn't support your use case at all since they don't have wait before submit behavior.
So there are already ways to do this, but the Linux kernel so far told everybody that this is forbidden. The DRM syncobj wait before signal functionality is much better, but then basically the second try to do this.
I'm not quite sure what you're getting at here, just to be clear though:
While the syncobj Wayland protocol extension supports wait-before-submit behaviour at the Wayland protocol level, it doesn't need or cause wait-before-submit behaviour for DMA fences in the kernel. The usual rules apply to fences attached to syncobj timeline points. The wait-before-submit behaviour at the Wayland protocol level comes from allowing submit before a fence is attached to the acquire timeline point.
Yeah I know. I'm one of the people who came up with the idea of doing wait before signal this way in the drm_syncobj.
What I wanted to say is that a lot of people used the dma_fence to implement wait before signal before and got a bloody nose from that.
(It took me a while to realize this distinction, before which I mistakenly thought the kernel's DMA fence rules would prohibit wait-before-submit behaviour at the Wayland protocol level as well)
This is what surprised me.
The drm_syncobj implementation solved the wait before signal for the kernel, but my last feedback was that we basically just moved the issue to userspace and Wayland compositors would have quite some overhead to implement it correctly.
That compositors now use eventfd to simplify that was news to me but makes totally sense in hindsight.
But anyway, we need to somehow simplify the drm_syncobj -> eventfd usage in the compositor.
That is not the only usage in the compositor. Compositors use all of the following operations on syncobjs:
- creating syncobjs - waiting for points synchronously - signaling points without a sync file - querying points - transferring sync files between points - exporting sync files - importing sync files
Which you can see by looking at the userspace code linked in the cover letter. Bypassing the handle in one ioctl would gain compositors nothing since they would still have to convert to handles and manage their lifetime for all other ioctls.
That requirement is perfectly justified and avoiding importing the drm_syncobj fd into any DRM driver should actually be really easy to implement.
That is what this series does.
Regards, Christian.
linaro-mm-sig@lists.linaro.org
-
Christian König -
Julian Orth -
Michel Dänzer