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

Is this solved already? I’m having the exact same issue with a simple demo app that uses Vulkan as it’s rendering API. The window is created using GLFW, the present mode is FIFO, but dragging it makes is VERY sluggish and unresponsive. On a Windows machine with a simple integrated Intel GPU it works just fine. On Linux (X11) with a RTX 3070 it’s unusable.

No, it’s not solved. Your best option would be to switch to IMMEDIATE present mode and then toggle force full compositing pipeline in nvidia-settings. The same issue doesn’t occur in Wayland, so I suspect it will not be fixed on X11 at this point. Unfortunately nvidia + wayland is still borderline unusable for a variety of other reasons.

I can confirm that this problem is present in driver version 525.60.11. (RTX 3060 Ti).
Running vkcube causes massive lag when moving windows (exception is running vkcube with --present_mode 0).
I first noticed this problem in Warzone2100 (game) when using Vulkan backend, in OpenGL everything works perfectly even with VSync enabled. The windows games running under wine with dxvk are working fine though.

I checked if Warzone2100/Vulkan backend works in mesa drivers on Intel GPU, no such problem with VSync enabled.

This issue is present in the driver 525.85.05

Still happening in just released 535.54.03.

NVidia driver 535.86.05. This issue is NOT fixed.

Can confirm, this issue is present since a long time now.

Driver: 545.29.06
OS: openSUSE Aeon
Gnome 45.3 / X11

vkcube --present_mode 2

vkcube --present_mode 0

VK_PRESENT_MODE_FIFO_RELAXED_KHR and VK_PRESENT_MODE_MAILBOX_KHR seem not to be supported by the vulkan driver at all. At least vk did not launched with these present modes.

I’d also like to note that this issue is also present with XWayland, which is where I started noticing it in resent driver releases as well wasn’t always the case but I don’t know for sure which driver version made it also broken for XWayland.
But those make only other XWayland clients lag and stutter. Native Wayland clients are not affected.

Side note: I left Gnome / X11 because of this issue but since it’s now crawling into Wayland / XWayland I thought it’s time to report.

nvidia-bug-report.log.gz (907.5 KB)

I did some further testing with Wayland and XWayland and came up with this issue being present independent of the Graphics API and the display server and seems to be a regression with the nvidia driver handling VSync in general.

Tested VKCube and GLXGears as XWayland clients as well as GZDoom as a native Wayland client with VSync enabled and disabled.
In all cases with VSync enabled there is a noticeable performance regression at random times and semi periodic.

I made a few more videos to better visualize the issue:

XWayland VSync enabled:

XWayland VSync disabled:

GZDoom native wayland vsync enabled.
Around 1:06 it randomly starts happening:

GZDoom native Wayland vsync disabled.
There are some minor hiccups but not notable without the overlay though.

nvidia-bug-report.log.gz (658.7 KB)

Driver: 545.29.06
Gnome: 45.3
Kernel: 6.6.11
OS: openSUSE Aeon

All in all this issue seems to be more imminent on X11 / XWayland then native Wayland

550.40.07 issue still relevant:

OpenGL apps seems to be less affected by this issue but also cause similar symptoms still.

nvidia-bug-report.log.gz (1.3 MB)

Under XWayland it gotten at least better (nearly fixed)