On 2024-02-23 09:11, Michel Dänzer wrote: > On 2024-02-23 08:06, Christian König wrote: >> >> So rejecting things during CS and atomic commit is the best thing we can do. > > It's problematic for a Wayland compositor: > > The CS ioctl failing is awkward. With GL, I'm pretty sure it means the > compositor would have to destroy the context and create a new one. Not sure > about Vulkan, but I suspect it's painful there as well. > > Similarly for the KMS atomic commit ioctl. The compositor can't know why > exactly it failed, all it gets is an error code. > > And there's no other way for the compositor to detect when both things can > actually work concurrently. > > Together, this means the compositor always has to assume the worst case, and > do workarounds such as using the scanout GPU to copy from the scanout buffer > to another buffer for access from another GPU. Even when direct access from > the other GPU would actually work fine.
It's worse for Xwayland: It can't know if/when the Wayland compositor uses a buffer for scanout. It would have to assume the worst case whenever a buffer is owned by the compositor. Except Xwayland can't know which GPU a buffer is originally from. So it can't know when the workaround is actually needed, or which GPU it has to use for the workaround. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
