Hi,
On Tue, 20 Apr 2021 at 20:03, Bas Nieuwenhuizen <bas@xxxxxxxxxxxxxxxxxxx> wrote:
It's a jarring transition. If you take a very narrow view and say 'it's all GPU work in shared buffers so it should all work the same', then client<->winsys looks the same as client<->client gbuffer. But this is a trap.I think this is where I think we have have a serious gap of what a winsys or a compositor is. Like if you have only a single wayland server running on a physical machine this is easy. But add a VR compositor, an intermediate compositor (say gamescope), Xwayland and some containers/VM, some video capture (or, gasp, a browser that doubles as compositor) and this story gets seriously complicated. Like who are you protecting from who? at what point is something client<->winsys vs. client<->client?
As I've said upthread, the line is _seriously_ blurred, and is only getting less clear. Right now, DRI3 cannot even accept a dma_fence, let alone a drm_syncobj, let alone a memory fence.
Crossing those boundaries is hard, and requires as much thinking as typing. That's a good thing.
Conflating every synchronisation desire into a single userspace-visible primitive makes this harder, because it treats game threads the same as other game threads the same as VR compositors the same as embedding browsers the same as compositors etc. Drawing very clear lines between game threads and the external world, with explicit weakening as necessary, makes those jarring transitions of privilege and expectation clear and explicit. Which is a good thing, since we're trying to move away from magic and implicit.
Cheers,
Daniel
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
