godot: GUI unresponsive on Godot 4 (regression from the NVIDIA Linux 450.66 driver and later)

@mrezai

Since the unoptimized version is slower, I run release_debug version with valgrind to slow down it in runtime and as a result issue doesn’t happen anymore! From all of these can we conclude that at least in some situations, we get this issue because of the synchronization problem in Godot code itself?

Well, we already know that it’s a synchronization issue of some sort, since the UI gets stuck on some Vulkan function binded to some related semaphore(see https://github.com/godotengine/godot/issues/41574#issuecomment-683549656). It’s interesting though that by having a slower framerate it doesn’t freeze, and I can confirm that by putting a big enough delay right before all drawing code indeed avoids all the freezes. AFAICT since the editor doesn’t do any frame limiting, it uses the GPU’s frame synchronization fully, and for whatever reason(never used Vulkan, but to me it feels like the fence is never actually updated, and the X server eventually times out or something) the end of a frame draw is never signaled.

EDIT: Welp, looks like i was close, as right after I replicated this bug I came to read my X log and guess what I found: [ 3553.500] (WW) NVIDIA: Wait for channel idle timed out.

EDIT2: It was actually a semaphore, and not a fence.

After discussing with @AndreaCatania in his Godex Discord server, we found a workaround. This is what Andrea gave me and it works for me:

bin/godot --path path/to/project -e --single-window

I’ve been having the same problem with my GTX 1070, driver is 450.66-0ubuntu0.20.04.1.

Workaround because nobody has mentioned it yet: Enable “Single window mode” and it seems to work fine. If you can’t get to the checkbox, open editor_settings-4.tres and add this line:

interface/editor/single_window_mode = true

I can confirm that vkcube indeed freezes momentarily, by simply moving the mouse in and out of the program window (not using PRIME, screen is directly hooked to NVIDIA card).

This seems to still be an issue on the latest 460.23.03 nvidia driver on Ubuntu 20.04LTS. It still crashes without interface/editor/single_window_mode = true.

There is this black background and every Mesh I add is 100% black before I adding light. Not sure if that is by design since in 3.X it does not work like this.

The default environment hasn’t been readded yet, that’s why everything is black by default.

Issue persists in the current release 455.23.04

Indeed! The problem disappears when editing a project directly with -e (and --single-window)!

This is indeed an issue related to multiple windows.

@pouleyKetchoupp Yes. It’s 100% reproducible with this build and these steps on the first attempt. Btw I also have Ryzen 5 2600

Oh sorry @pouleyKetchoupp I completely forgot to answer! Like @insomniacUNDERSCORElemon I haven’t got any iGPU since I run a ryzen 2600 and I can replicate this on the latest arch linux version too running version 465.31 of the drivers. Is that nightly build any special from a fresh compilation of HEAD? I can confirm though that it happens in a consistent way by doing things like scrolling or in general updating very quickly a sub-window. I don’t know if the freeze depends on a continuous fast update or just a very well timed out one though. If you’re contacting nvidia I collected some detailed data using their debug tool some time ago, that may be useful to them. Also I found out some time later that the X server timed out after the freeze and I can confirm that it still happens, maybe they could use it as a starting point for finding out the cause of the issue.

@pouleyKetchoupp

1. it’s happening for me with that linked build.
2. You can get it to happen even faster with the about menu in the project manager (bottom-right corner). Scrolling with the mousewheel works too, but seems to be linked to scrolling quickly (scrolling slowly only seems to trigger a freeze w/dragging the mouse for whatever reason, mouse polling maybe? Similarly clicking on the scrollbar can cause a freeze if you use an autoclicker). Better via project manager as well, as it’s multi-window by default unless you launch with a flag to disable that (not a project setting you can forget is the wrong value).

From what I’m seeing it is instant and consistent, at least triggered this way and from color/text boxes. I’ve tested it quite a few times, but I can’t exactly test too much as it freezes my system for a second time when killing the process (xkill leaves them behind, taking up resources).

Thought I might as well chime in with what I found so far, since everything in this issue happened to me. This seems to be an issue for me with everything that uses vulkan on my system, including Retroarch, Dolphin Emulator, etc. @TCROC 's fix does work for me, so big thanks for that, but I’ve also noticed that this freezing only tends to happen when invoking certain animations; such as highlighting text, and scrolling with the scrollbar too fast.

My System: Linux 5.12.9-arch1-1, Arch Linux + KDE Plasma 5.21.5 GPU: NVidia GTX 1080 w/ NVidia 465.31-7 Drivers

@TCROC I’m not sure. This issue actually started in #41574, where --single-window and it’s repercussions in the project manager were discussed, but then branched here.

It sometimes happens on Windows 10 too (and when Single Window Mode is disabled).

Any idea about what is going on with the FPS?

I can reproduce the issue when moving the window, but I don’t think it’s so critical for now. You generally don’t move windows around all the time, especially game windows 🙂

I’m also still experiencing this in 59b30e1d23d096f5faa36d2faaa07792eba4fd81: Arch Linux, running nVidia 455.45.01 on GTX 1660 Ti

Single window mode resolved the issue for me.

Thanks both of you! I’ve updated the ticket upstream.

Ok, done. What I did and what happened:

• Start the X server with the flag -logverbose 6
• Run Godot
• Open a project with a window in it
• The new window got created where i put my mouse. It didn’t freeze, so I unfocused it and it froze for a few seconds.
• Once unfrozen, waited a bit and it froze again for a few seconds.
• Killed it from another terminal, froze again.
• Dumped everything right away, here’s the file: nvidia-bug-report.log.gz

@pouleyKetchoupp I too tought about making a ticket, but didn’t because I thought that without a minimal Vulkan repo project we wouldn’t get that far. I’ll run that script as soon as I downgrade to 450.66! I tried to run the latest 455.23 beta and the issue persists, though there might be some fix that might be useful to you, since it mentions PRIME synchronization. Here’s the changelog just for reference:

    Added support for the following GPUs:
        GeForce RTX 3080
        GeForce RTX 3090
        GeForce MX450
    Fixed a bug that prevented 8K displays from being used in portrait orientation on Pascal and earlier GPUs.
    Fixed a bug which caused excessive CPU usage in Vulkan applications which create a large number of VkFence objects. This was particularly prevalent in the Steam Play title Red Dead Redemption 2.
    Added support for a new device-local VkMemoryType which is host-coherent and host-visible. This may result in improved performance in some applications. Applications which are known to benefit from this new VkMemoryType include: DXVK Title DiRT Rally 2.0, Steam Play Title DOOM: Eternal, and DXVK title World of Warcraft.
    Fixed a bug that caused WebKit-based applications to crash when running on Wayland.
    Fixed a bug that led to display corruption at some resolutions when using an NVIDIA-driven display as a PRIME Display Offload sink.
    Fixed a bug in a SPIR-V optimization that may cause conditional blocks to not execute.
    Fixed a bug where calls to vkGetRandROutputDisplayEXT with unexpected inputs would generate X11 protocol errors. (https://bugs.winehq.org/show_bug.cgi?id=49407)
    Fixed a small memory leak during exit of the NVIDIA EGL driver.
    Implemented support for the NVIDIA NGX Updater. See the "NGX" chapter in the README for information on how to configure this feature.
    Removed support for the SLI modes "SFR", "AFR", and "AA".  SLI Mosaic, Base Mosaic, GL_NV_gpu_multicast, and GLX_NV_multigpu_context are still supported.
    Updated Base Mosaic support on GeForce to allow a maximum of five simultaneous displays, rather than three.
    Fixed several synchronization bugs that could momentarily lock up the X server when moving/resizing/focusing OpenGL and Vulkan windows when PRIME Sync was enabled.
    Added NVIDIA VDPAU driver support for decoding VP9 10- and 12-bit bitstreams. Note that VDPAU's presentation pipeline and OpenGL-VDPAU interop does not support 10- and 12-bit video surfaces yet. See the "VDPAU Support" appendix in the README for supported decoder profiles.
    Fixed a bug that could cause dual-link DVI to be driven over a connector that only supports single-link DVI, when "NoMaxPClkCheck" is specified in the "ModeValidation" X configuration option.  Note this fix may cause behavioral changes for configurations using this option.
    Fixed a regression that allowed displays to enter DPMS mode even when DPMS is disabled in the X server settings.
    Updated nvidia-settings to allow continued interaction with other pages and help content while editing application profiles.

Edit: Made the comment a little bit clearer on what I was talking about.

@pouleyKetchoupp in my case, after rolling back to 450.57 vkcube still freezes briefly after focusing and unfocusing its window, but Godot 4.0 doesn’t freeze the X11 server.

Thanks @seadra, that confirms a general issue with the nvidia drivers and not just in godot. In your case it might work better by switching the drivers version to 450.57 (apart from the workaround with --single-window).