On linux, running a vulkan app (presenting to the screen) with VK_PRESENT_MODE_FIFO_KHR (the default, for vsync’d display) causes massive stuttering across the system when moving or resizing other application windows on the system. Switching the vulkan application’s presentation mode to VK_PRESENT_MODE_IMMEDIATE_KHR fixes the issue entirely; however, I am developing a desktop tool (not a game), so the tearing introduced by immediate mode (no vsync) is not desirable. This issue does not happen on windows.
Encountered on a RTX 3090, running both the latest 470 driver as well as 465 with Gnome on X11. Gnome is a compositing window manager, which I suspect might be relevant, but I haven’t tested with other window managers.
The easiest way to reproduce this is with the vkcube app included in the Vulkan SDK. Run vkcube with “vkcube --present_mode 2” (FIFO / vsync mode), and try to move or resize another window on the system. Moving the other window will be extremely slow and stuttery - essentially rendering the desktop unusable. Next run vkcube with “vkcube --present_mode 0” (immediate / no vsync mode). The vkcube demo will run much much faster (uncapped FPS - ironically more total GPU usage), but observe that moving other windows on the system is now completely smooth with no issues.
Digging deeper, the issue appears to be that the rest of the system becomes very stuttery when the vulkan app is waiting on the vsync blank. The faster the vulkan app is, the more time is spent waiting and the less responsive moving / resizing other windows becomes. Since vkcube is a very lightweight workload, the issue is particularly visible, although even a heavier vulkan app still makes the desktop environment stutter and lag when moving windows / resizing, just to a lesser extent.
An interesting observation I made is that when moving / resizing other windows, the CPU usage of the vulkan app increases to 100%. Profiling indicates that tons of time is being spent in a poll wait call to the kernel - it seems like the nvidia driver is waking up the vulkan app to do some synchronization every time any other window on the system moves or is resized, introducing tons of overhead.
An important note is that none of this happens when only OpenGL based applications are displaying windows on the system. An easy way to verify this is with the Dear ImGUI example applications: imgui/examples at master · ocornut/imgui · GitHub. Running example_glfw_opengl3 does not exhibit the issue, while example_glfw_vulkan does. Additionally, example_glfw_vulkan seems to have at least 1 or 2 more frames of input lag than the opengl backend, despite both backends using VSync. To observe, try dragging around the internal ImGui widgets in the demo, on vulkan, the dragged window will lag noticeably farther behind the cursor than in opengl. All this together makes me conclude that the PRESENT_MODE_FIFO_KHR / Vsync implementation on linux for vulkan is extremely non optimal and broken right now, and the lack of issue with OpenGL indicates to me that it doesn’t need to be.
I’ve found people on reddit complaining of the exactly same issue so I don’t think this is isolated to my machine:
Seems like similar symptoms to this issue: Hangs/Freezes when Vulkan v-sync (VK_PRESENT_MODE_FIFO_KHR) is enabled
However, this is happening on a system WITHOUT optimus / prime, just a normal desktop with a single dedicated GPU, and definitely hasn’t been fixed in latest drivers.