Hello! I'm the member of Vulkan Mod (by xCollateral) for Minecraft Java Edition development team. We worked on implementing native Wayland support for Minecraft. Minecraft Java Edition uses GLFW library for creating windows, and this works perfectly. However, Kwin is the only one Wayland compositor that limiting FPS to monitor refresh rate with RenderFrameQueue 2. There a way to unlock FPS by setting RenderFrameQueue higher than 2, however, this causes game instance to race with compositor causing flickering/tearing/twitching visual artifacts, so RenderFrameQueue 2 is the way to go on Wayland. Testing showed that Wayland compositors like Mutter, Hyprland, Sway is not limiting FPS while working as intended with RFQ 2 and the KWin is only Wayland compositor that limits FPS to monitor refresh rate with RFQ set to 2. Is this behaviour intended? Will it change with Plasma 6? In addition first person shooter XONOTIC repeats absolute same behavior with GLX mode only on KDE Plasma. KDE Plasma known as ultimate DE for gaming, and this behaviour is drawback for native Wayland gaming.
With Mailbox on Wayland (with any compositor), you need four buffers / swapchain images to never block. The worst case is with direct scanout: - one for being currently used for scanout by the kernel (held for one frame at a time) - one for being queued for the next refresh period (held for anywhere from 1ms to a whole frame, depends on the compositor and the system) - one for being held by the compositor as pending for your wl_surface - one for rendering (which gets swapped with ^ when you call vkQueuePresentKHR) If we change KWin to release buffers used for compositing earlier, you'd still be broken when direct scanout is in use, even if things seem fine without it. With that in mind, I don't think this behavior should be changed, as it helps catch issues like this earlier. > There a way to unlock FPS by setting RenderFrameQueue higher than 2, however, this causes game instance to race with compositor causing flickering/tearing/twitching visual artifacts What GPU and driver are you using for testing?
Created attachment 161834 [details] attachment-1515010-0.html Hello! Thank you for your response! Personally I'am testing on RADV Tonga (Radeon R9 380). Experience the same on each RADV driver. I've been informed (almost 5min ago) from other testers with Nvidia GPU on proprietary driver that they can set any RFQ value on KWin Wayland and it's not having any visual artifacts. We would be grateful for any information why this happens on RADV with GLFW on any Wayland compositor! нд, 24 вер. 2023 р. о 00:42 Zamundaaa <bugzilla_noreply@kde.org> пише: > https://bugs.kde.org/show_bug.cgi?id=474816 > > Zamundaaa <xaver.hugl@gmail.com> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > CC| |xaver.hugl@gmail.com > > --- Comment #1 from Zamundaaa <xaver.hugl@gmail.com> --- > With Mailbox on Wayland (with any compositor), you need four buffers / > swapchain images to never block. The worst case is with direct scanout: > - one for being currently used for scanout by the kernel (held for one > frame at > a time) > - one for being queued for the next refresh period (held for anywhere from > 1ms > to a whole frame, depends on the compositor and the system) > - one for being held by the compositor as pending for your wl_surface > - one for rendering (which gets swapped with ^ when you call > vkQueuePresentKHR) > > If we change KWin to release buffers used for compositing earlier, you'd > still > be broken when direct scanout is in use, even if things seem fine without > it. > With that in mind, I don't think this behavior should be changed, as it > helps > catch issues like this earlier. > > > There a way to unlock FPS by setting RenderFrameQueue higher than 2, > however, this causes game instance to race with compositor causing > flickering/tearing/twitching visual artifacts > > What GPU and driver are you using for testing? > > -- > You are receiving this mail because: > You reported the bug.
Most likely you have some synchronization bug in your code that doesn't manifest as a visible result with the NVidia driver (for example they have some workarounds for synchronization issues with the NVidia driver on Wayland, which might mask the problem) . It's also possible that there's some bug in Radv. If you think that's the case (for example if the issue doesn't happen on Intel), you can make a bug report for radv at https://gitlab.freedesktop.org/mesa/mesa/-/issues
Created attachment 161956 [details] attachment-2189654-0.html I want to thank you for your help! Your information helped narrow the problem a lot. All problems resolved. There was no such thing as a Mesa or GLFW bug. Problem resolved with setting Image count to 4. Now the instance can run with any Render Frame Queue value set without issues. Hope this thread will help other OpenGL/Vulkan developers who want to create native Wayland games. нд, 24 вер. 2023 р. о 02:24 Zamundaaa <bugzilla_noreply@kde.org> пише: > https://bugs.kde.org/show_bug.cgi?id=474816 > > Zamundaaa <xaver.hugl@gmail.com> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Resolution|--- |DOWNSTREAM > Status|REPORTED |RESOLVED > > --- Comment #3 from Zamundaaa <xaver.hugl@gmail.com> --- > Most likely you have some synchronization bug in your code that doesn't > manifest as a visible result with the NVidia driver (for example they have > some > workarounds for synchronization issues with the NVidia driver on Wayland, > which > might mask the problem) . > It's also possible that there's some bug in Radv. If you think that's the > case > (for example if the issue doesn't happen on Intel), you can make a bug > report > for radv at https://gitlab.freedesktop.org/mesa/mesa/-/issues > > -- > You are receiving this mail because: > You reported the bug.
Thanks for following up on this :)