Vulkan App with VK_PRESENT_MODE_FIFO_KHR (VSync) causes desktop stuttering across entire system when moving or resizing *any* window. (Linux/X11)

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.

I say - this is “application problem” not X11 or Vulkan
Application should track and stop rendering when its resized or moved on screen.

Vulkan samples do not do that, but application like DXVK doing it as I saw (also stop rendering of presentation when window not visible etc

also as I notced this is only on Nvidia, AMD or Intel do not have this problem in Linux X11 with Vulkan window.

You’re misunderstanding the problem I’m describing here.

First, I disagree that an application should stop rendering when a window is moved on screen. Moving windows while rendering inside of them works perfectly fine, the contents continue to be updated.

More importantly: this issue occurs when you move any windows in the desktop environment, not just the vulkan application. The only requirement is that the vulkan application has to be running in some window, somewhere. In this context your suggestion of tracking in the application does not make sense.

I do agree with you that this is an Nvidia specific bug, it doesn’t happen when I test with an integrated intel GPU on X11.

look like you do not know how Wayland works - in Wayland application have to “do everything” include stop self rendering when moved.

More importantly: this issue occurs when you move any windows in the desktop environment, not just the vulkan application

I know, it it major bug that exist since first Vulkan beta drivers