| Summary: | GLFW KWin Wayland limiting FPS to monitor refresh rate | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | ElectricLizard <r.zotschannel> |
| Component: | compositing | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED DOWNSTREAM | ||
| Severity: | wishlist | CC: | xaver.hugl |
| Priority: | NOR | Keywords: | wayland-only |
| Version First Reported In: | 5.27.8 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | All | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
attachment-1515010-0.html
attachment-2189654-0.html |
||
|
Description
ElectricLizard
2023-09-23 19:55:08 UTC
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 :) |