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 >> <[email protected]>: >>>> 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. >> 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) -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
