mach: linux/vulkan needs frame rate limiter to avoid severe issues with some distro+WM+nvidia combinations

[slimsag]

We've had two reports of this type of behavior on (Linux, Vulkan, X11, NVIDIA, and less common distros), where we request no vsync (I believe?) and instead of the frame rate being smoothed, instead e.g. 60 frames are rendered in a burst almost instantaneously, then a vulkan swapchain call pauses for an entire second rendering nothing, then another burst, and so on:

KZUTLez.mp4

All instances appear to be solved by adding a frame rate limiter, e.g. opening any example application and adding std.time.sleep(16 * std.time.ns_per_ms); to the top of pub fn update

The reports:

• adayoldbagel on Discord:
  • Distro: Arch
  • X11/Wayland: X11
  • Window manager: bspwm, no desktop environment
  • Vulkan driver: proprietary nvidia 515.57
  • GPU: discrete RTX 2070 SUPER
  • Using GPU_BACKEND=opengl works around the issue? Yes
  • Using frame rate limiter solves the issue? Yes
• boopinski on Discord:
  • Distro: lubuntu
  • X11/Wayland: X11
  • Window manager: LXDE
  • Vulkan driver: proprietary nvidia 510.73.05
  • GPU: GTX 750 Ti
  • Using GPU_BACKEND=opengl works around the issue? Yes
  • Using frame rate limiter solves the issue? Yes
• bitflip on Zig Discord:
  • xwayland + sway
  • Disabling vsync fixed the issue
  • Facing it in their own GLX usage (not webgpu/Mach)

I've found that all example programs using vulkan tie up a CPU core to 100% and lock me out of all input for 10 or more seconds per frame. I've tracked the behaviour down to the Swapchain.getCurrentTextureView() call. It seems to just hang for ages

[slimsag]

decision: before imposing a frame rate limiter on all our Linux users by default, we're going to wait and see if anyone can reproduce this behavior again. If you can, please do comment.

Our hope/belief is that (a) some Dawn changes or (b) the multi-threaded rendering support we added (always on) may have resolved the poor vsync behavior.

[drunderscore]

I've been able to re-produce this behavior (on 9250310) -- using the textured cube example and "Getting started", though I assume every mach causes this. Speed up and slow-down of the cube spinning, framerate goes between 22, 61, 181, etc. My window manager and entire system become quite unresponsive, and switching window focus is very slow and makes it worse, causing all windows to become unresponsive.

I attempted to record this, but quickly realized it's actually pretty difficult because my encoder quickly fails when trying to do so, and OBS will stop recording if the encoder gets too far behind. A CPU encoder might work if I try it later.

I tried setting MACH_GPU_BACKEND=opengl to see if that fixes it, but that causes a panic:

nfo(mach): found Vulkan backend on Discrete GPU adapter: NVIDIA GeForce RTX 2070 SUPER, NVIDIA: 525.116.04 525.116.4.0

info(mach): gamemode: activated
error(mach): mach: device lost: CreateSwapChain failed with VK_ERROR_NATIVE_WINDOW_IN_USE_KHR
 - While handling unexpected error type Internal when allowed errors are (Validation|DeviceLost).
    at CheckVkSuccessImpl (/home/runner/work/mach-gpu-dawn/mach-gpu-dawn/libs/dawn/src/dawn/native/vulkan/VulkanError.cpp:88)
    at Initialize (/home/runner/work/mach-gpu-dawn/mach-gpu-dawn/libs/dawn/src/dawn/native/vulkan/SwapChainVk.cpp:344)
    at Create (/home/runner/work/mach-gpu-dawn/mach-gpu-dawn/libs/dawn/src/dawn/native/vulkan/SwapChainVk.cpp:250)
    at CreateSwapChain (/home/runner/work/mach-gpu-dawn/mach-gpu-dawn/libs/dawn/src/dawn/native/Device.cpp:1779)

thread 584035 panic: mach: device lost
/home/james/mach-core/src/platform/native/Core.zig:128:5: 0xc49d9b in deviceLostCallback (textured-cube)
    @panic("mach: device lost");
    ^
???:?:?: 0x60719e in ??? (???)
???:?:?: 0x61c419 in ??? (???)
???:?:?: 0x623c1a in ??? (???)
Unwind error at address `:0x623c1a` (error.UnimplementedUserOpcode), trace may be incomplete

/home/james/zig-linux-x86_64-0.12.0-dev.1092+68ed78775/lib/std/Thread.zig:412:13: 0xccb721 in callFn__anon_43598 (textured-cube)
            @call(.auto, f, args);
            ^
/home/james/zig-linux-x86_64-0.12.0-dev.1092+68ed78775/lib/std/Thread.zig:685:30: 0xc681c2 in entryFn (textured-cube)
                return callFn(f, args_ptr.*);
                             ^
???:?:?: 0x7efcb63ac9ea in ??? (libc.so.6)

I can supply much more information here, or create a new issue, just let me know what's most important and where I should put it.