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
