|Summary:||Please add an option to override number of backuffers in Vulkan drivers with environment variable|
|Status:||RESOLVED MOVED||QA Contact:|
|Priority:||not set||CC:||airlied, chadversary, jason, tempel.julian|
|i915 platform:||i915 features:|
Description Shmerl 2019-09-08 16:18:58 UTC
There are cases when too few backuffers can cause Wayland compositors to lock framerate to refresh rate of the monitor (for example in XWayland case), no matter if vsync is on or off in the application settings. See: https://gitlab.freedesktop.org/xorg/xserver/issues/20 While in case of dxvk, there is an option to increase number of backuffers to mitigate that, when dealing with some native or even Wine based Vulkan applications, there might be no easy way to do it. Adding an option to radv, similar how it now allows overriding present mode with MESA_VK_WSI_PRESENT_MODE can help such cases.
Comment 1 Bas Nieuwenhuizen 2019-09-08 19:30:28 UTC
Request is for radv, but I think this is just as much about the other drivers, since this is pretty much horizontal code.
Comment 2 tempel.julian 2019-09-08 20:26:56 UTC
Thanks for opening the ticket. As a side note: When forcing MESA_VK_WSI_PRESENT_MODE=mailbox to workaround this, this actually crashes Doom on Plasma Wayland.
Comment 3 tempel.julian 2019-09-09 11:33:11 UTC
I wonder if it wouldn't make sense to always use/enforce a backbuffer queue length of 3 by default. If one enables vsync, having the frametime consistently jump between full refresh rate and divisors of it is usually highly undesirable. And if input/output latency is an issue, one doesn't enable vsync.
Comment 4 GitLab Migration User 2019-09-18 18:13:19 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/184.