https://bugs.kde.org/show_bug.cgi?id=450914
--- Comment #27 from Zamundaaa <xaver.h...@gmail.com> --- > Firstly, I noticed that, unfortunately, direct scan-out for Xwayland > applications doesn't work at all with our driver right now. This is an issue > on our end, we're allocating compressed buffers which aren't eligible for > scan-out. It should be pretty easy to fix, but that will need to be in an > upcoming driver release There's also https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/818 to resolve that properly, so that Xwayland clients can make use of dmabuf feedback indirectly. With that it should be possible to use compressed buffers where beneficial without sacrificing direct scanout. > I still question why Kwin is holding on to both buffers for the entire frame > if it's not doing direct scan-out I looked at where buffers are referenced and unreferenced, and surface pixmaps are only updated when KWin is actually painting. So it only releases a buffer that was used for compositing right before the next frame is rendered. This can be fixed but I don't think there's a real upside to it - because of direct scanout, you need at least 3 buffers for fifo and 4 for mailbox anyways. > Now, once we do fix the compressed buffer thing enabling direct scan-out, > maybe we will need to add a third swapchain image anyway 3 buffers isn't enough. In the time between the compositor submitting the next frame to drm and the associated page flip, one buffer is used for direct scanout and another is imported and locked for the next frame. If you commit a new buffer in that time the compositor can't release either buffer yet, so it keeps all 3 buffers locked until the page flip happens. This problem is made a lot worse by most compositors needing to do compositing in the middle of a refresh cycle (on weak hardware even earlier) to reliably ensure no frames get dropped, so you'd potentially block for quite some time with only 3 buffers in the client. To solve this problem there's effectively two options: The drm API could gain support for mailbox natively. The compositor could then replace the pending frame with the new buffer, and release the old one immediately without waiting for any page flips. This API is wanted a lot but not too likely to happen in the very near future. The other option is that the client allocates 4 buffers instead of 3. Also see https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15786 for some more discussions about this. > That's assuming that Kwin's page flips will still be synchronized to the > display refresh rate, which I believe is the case (correct me if I'm wrong). That is correct for all compositors that I know of. Currently there is nothing else one can do with atomic modesetting, and falling back to legacy is not really an option. > But is that really the solution users want? Sure, it would technically let > the game run at an uncapped refresh rate, but as I understand it the main > reason people want to run games that way is to minimize input latency, and > they're willing to accept possible tearing as a trade-off (e.g. competitive > gamers and whatnot). So would it maybe make more sense to have Kwin do > tearing flips instead for direct scan-out applications? Absolutely not. Not all gamers want tearing and mailbox still presents a (small) latency advantage vs FIFO. We also really do not want to restrict direct scanout to games. > In *that* case I think 2 swapchain buffers on the driver side would still be > fine, right? yes but also no. The problem is that the compositor will not necessarily actually do tearing when the client wants it (if the window isn't focused, if the user disabled it, the buffer format / modifier isn't usable for tearing or whatever) so you must allocate sufficient buffers for mailbox or you risk stalling the application. -- You are receiving this mail because: You are watching all bug changes.
