GTK 4.14 Adding Graphics Offloading Capabilities Under Wayland

[oiaohm]

There's no way to ensure the Xv overlay contents are always consistent with the rest of the output. E.g. when Alt-tabbing the overlay contents might need to be visible multiple times with different scaling, the overlay doesn't support translucency, ... Xv overlays are just fundamentally incompatible with compositing, which is why most Xorg drivers only support textured Xv anymore, which can't provide the same benefits as Wayland sub-surfaces.

These are fundamental problems when using overlays. How does Wayland handle this?

The answer for most of what MrCooper said is Wayland protocol does not handle this but instead it the black magic of dmabuf and the GPU drivers and GPU hardware.. Wayland defines that your surfaces will be filehandles. Yes DMABUF can be a file handle.

https://docs.kernel.org/driver-api/dma-buf.html

DMABUF structure stores where to find a buffer sync information.

DMABUF is very different to the SHM system. With DMABUF application can have told a GPU to fill a buffer with something the GPU has not done that yet but the application can send the filehandle of DMABUF of where that generation form the GPU will be in future to the Wayland compositor and due to sync information on the DMABUF will not display that output until the GPU generates it.

Anything based around DMABUF can maintain correct sync with each other very simply because it part of DMABUF todo that.

Allow tearing under Wayland is not turn vsync on or off. It simple we will tell the GPU to ignore the sync information on the buffer and just render what is currently done.

This explains why Nvidia total lack of DMABUF support at first and then not completely implemented or optimized DMABUF support causes Wayland compositors major performance problems and issues.

[MrCooper]

These are fundamental problems when using overlays. How does Wayland handle this?

At the protocol level, via atomic surface state commits, which can include (so-called synchronized) sub-surfaces as well as the toplevel surface. This allows the client to ensure that all (sub-)surfaces which make up what the user calls a window always have mutually consistent state.

In terms of using an overlay for a (sub-)surface, Wayland compositors handle this by using the atomic KMS API, which allows changing the state of the primary and overlay planes atomically, which again allows the compositor to ensure that all planes always have mutually consistent state.

Note, in both cases the state includes the currently visible contents of each (sub-)surface / plane.