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

[Alexia-AT-Digitecnology]

Bugsquad edit: This issue has been confirmed several times already. No need to confirm it further.

Workaround: Enable Single Window Mode in the Editor Settings, or use the --single-window command line argument and open a project directly by specifying the path to its project.godot file.

If you can't get to the checkbox, open $HOME/.config/godot/editor_settings-4.tres and add this line:

interface/editor/single_window_mode = true

---

Godot version: v4.0 Git commit f10c381

OS: Archlinux latest (NVIDIA GTX 1060, 64 GB RAM, Intel Core i7)

Issue description: When initialize godot UI modals remains unresponsive

Steps to reproduce:

• Compile godot
• Open godot
• Create a new project
• Specify directory
• UI remains unresponsive
  

Bugsquad edit (keywords for easier searching): crash, crashing, freeze, freezing
Windows counterpart of this issue: #45325

[Riteo]

Maybe related to #41574?

[Alexia-AT-Digitecnology]

Yeah, its related with that @Riteo. It's the same bug.

[akien-mga]

That's not i3wm like in #41574, is this KDE Plasma?

[akien-mga]

For the reference, I don't get this issue with a build from the current master branch on Mageia 8 with KDE Plasma 5 / KWin running on X11.

[Riteo]

@akien-mga what version of the NVidia driver do you have installed?

[akien-mga]

I'm #TeamAMD :)

Dual graphics Intel HD 630 / AMD Radeon RX Vega M both running on Mesa 20.1.6.

[Riteo]

@DavidNexuss could replicate this issue on all the WMs he tried.
They also run Arch Linux with an NVIDIA card, so, I believe that this may be a duplicate of #41574.

[pouleyKetchoupp]

@Riteo I can't reproduce it with the recommended nvidia drivers (version 440) on Ubuntu 20.04.1 with Gnome or KDE (but I can reproduce it when using i3). I tried to install nvidia drivers version 450.66 but it caused all application windows to be either black or full of graphical glitches so it doesn't seem compatible with my configuration.

I'll try and see if I can install Arch Linux separately to reproduce the issue.

[seadra]

I can confirm this issue exists on Arch Linux + NVidia + KDE. Godot 4 is unusable due to this issue at the moment.

The issue persists with --single-window, so it doesn't appear to be tied to multiple windows.

[Riteo]

@seadra did you start godot with only --single-window? IIRC after opening a project from the project manager, the editor is started without that flag.

[seadra]

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

This is indeed an issue related to multiple windows.

[pouleyKetchoupp]

I'd like to confirm this issue is similar to #41574. Could someone run these tests on ArchLinux with an nvidia card:

1. Simple vulkan test
   -Install vulkan-tools
   -Run vkcube
   -Does it freeze when you focus in and out of the window?

2. Disable PRIME synchronization
   -Create file /etc/modprobe.d/nvidia-graphics-drivers.conf
   -Add line options nvidia-drm modeset=0
   -Run sudo update-initramfs -u
   -Reboot
   -Check if the problem persists in Godot (multi-window mode) and vkcube

[seadra]

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).

[pouleyKetchoupp]

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).

[Riteo]

@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.

[pouleyKetchoupp]

@Riteo Could you please try and run nvidia-bug-report.sh with 450.66 drivers enabled and provide me with the generated nvidia-bug-report.log.gz file when you have some time?
Instructions are here: https://forums.developer.nvidia.com/t/if-you-have-a-problem-please-read-this-first/27131

I'm opening a ticket on the nvidia developer forum and it could help to provide more information. Unfortunately I still have issues with these drivers and they don't work at all for me :/

[pouleyKetchoupp]

I've opened the ticket upstream:
https://forums.developer.nvidia.com/t/x-server-freeze-when-creating-window-or-switching-focus-regression-from-450-66/155150

[Riteo]

@insomniacUNDERSCORElemon mhh, that sounds weird, very weird. I'll investigate

[insomniacUNDERSCORElemon]

@Riteo I just found that I can easily re-create a crash in the project manager when trying to create a new project, but I still haven't seen a crash in the editor itself.

So there might be some difference there.

[Riteo]

@insomniacUNDERSCORElemon I still haven't found the occasion to test, but wait a second, you said that it's slugghish? Like, is the editor very slow? I think I know why it doesn't crash.

[insomniacUNDERSCORElemon]

@Riteo it was sluggish in the GCC version too (the one that did crash with sub-windows in the editor) so that's a shared thing with the Clang version. I mean it could be related, but I would assume it isn't.

[Riteo]

@insomniacUNDERSCORElemon maybe you're compiling it in debug mode? Anyways if it goes slow, it might not crash because the FPS are just low enough to not mess up the driver's synchronization (see this comment and my response)

[insomniacUNDERSCORElemon]

@Riteo I didn't change the target. To be specific I am not aware of FPS, the sluggishness I'm experiencing is a delay when selecting nodes. Also seemingly any menu item (project or editor settings) that has color boxes in it. Which might even be the reason for the sluggishness w/node switching since they all have a color box (AFAICT) even if it's just modulation.

I couldn't find an FPS meter for the editor in 2D, trying to go to 3D immediately caused a freeze.

I'm now noticing freezing with the project/editor settings as well when typing something into the filter box. I've also seen 2 outright crashes due to the editor settings window. Even in the setting windows it's not a guaranteed thing and still less frequent than it was with GCC, so maybe it is related to FPS (the more complicated submenus not causing crashes)?

EDIT: Yeah I think it's the color boxes thing, because with literal nodes (Node node) switching is instant. A viewport window node doesn't switch as fast for me (not as slow as other nodes either), so possibly there's a bit more to this (even if color boxes are the biggest issue).

[Riteo]

@insomniacUNDERSCORElemon if you didn't specify the target then it chose the default, which is debug. That's probably why it's slow. Anyways, there's clearly something wrong with the drivers so I don't think that there's a way to get around it without fixing them, which we can't do now unless either nvidia magically released their source code or actually cared for their user bug reports a little more, which I don't think they never will. Our only hope at this point is reduz and his more direct contacts with various vendors including nvidia.

[insomniacUNDERSCORElemon]

Alright, I just tested it with the release_debug target and the result is that 1. Crashing is as frequent as it was with GCC debug. 2. The sluggishness of switching nodes/colorboxes is gone/not noticable (even when crashing is present).

Seems faster than GCC debug was, but maybe that's coincidence (newer master branch). Seems usable with multi-window-mode turned off.

In case anyone gets the idea, an external framelimit doesn't seem to prevent the crashing. At least for me, libstrangle seems to do nothing and mangohud seems to make stability significantly worse. I also tried disabling v-sync (for testing with 240 FPS on w/60Hz display) in addition to the framelimit.

[Calinou]

I also tried disabling v-sync (for testing with 240 FPS on w/60Hz display) in addition to the framelimit.

Disabling V-Sync currently has no effect with the Vulkan renderer.

[carterisonline]

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

[pouleyKetchoupp]

I've tried to reproduce this issue with no luck so far.
System: Arch Linux (kernel version 5.12.10-arch1-1)
NVidia card: GeForce 940M (drivers version 465.31)
Tested on Gnome 40.2.0 and KDE Plasma 5.22.1

@carterisonline Do you have a laptop optimus system or just a desktop Nvidia card? I had problems with Vulkan on my system (it was failing to run using the correct GPU) so I've followed this step:
https://wiki.archlinux.org/title/NVIDIA_Optimus#Use_NVIDIA_graphics_only
It's not ideal for battery usage, but things generally work much better with this configuration.

[Riteo]

@pouleyKetchoupp yep, I can still replicate this bug on 6955316. Had some big trouble doing it though. I had to compile it to release_debug and from the project manager I clicked on "About" and scrolled as fast as I could. Same old stacktrace coming from the drivers:

[1] /usr/lib/libc.so.6(+0x3cda0) [0x7f3859fbeda0] (??:0)
[2] /usr/lib/libGLX_nvidia.so.0(+0x4d686) [0x7f3858a36686] (??:0)
[3] /usr/lib/libnvidia-glcore.so.465.31(+0xe6c949) [0x7f38576f8949] (??:0)
[4] /usr/lib/libnvidia-glcore.so.465.31(+0x10e54fb) [0x7f38579714fb] (??:0)
[5] /usr/lib/libnvidia-glcore.so.465.31(+0x10e752e) [0x7f385797352e] (??:0)
[6] /usr/lib/libnvidia-glcore.so.465.31(+0x10de0c4) [0x7f385796a0c4] (??:0)
[7] /usr/lib/libnvidia-glcore.so.465.31(+0x11b65e3) [0x7f3857a425e3] (??:0)
[8] /usr/lib/libGLX_nvidia.so.0(+0x9359f) [0x7f3858a7c59f] (??:0)
[9] bin/godot.linuxbsd.opt.tools.64() [0x15cf79b] (/home/riteo/srg/godot/drivers/vulkan/vulkan_context.cpp:1927)
[10] bin/godot.linuxbsd.opt.tools.64() [0x158b93f] (/home/riteo/srg/godot/drivers/vulkan/rendering_device_vulkan.cpp:7669)
[11] bin/godot.linuxbsd.opt.tools.64() [0x304abd2] (/home/riteo/srg/godot/./core/templates/list.h:185)
[12] bin/godot.linuxbsd.opt.tools.64() [0x844f79] (/home/riteo/srg/godot/main/main.cpp:2511)
[13] bin/godot.linuxbsd.opt.tools.64() [0x81e419] (/home/riteo/srg/godot/platform/linuxbsd/os_linuxbsd.cpp:278)
[14] bin/godot.linuxbsd.opt.tools.64() [0x812682] (/home/riteo/srg/godot/platform/linuxbsd/godot_linuxbsd.cpp:58)
[15] /usr/lib/libc.so.6(__libc_start_main+0xd5) [0x7f3859fa9b25] (??:0)
[16] bin/godot.linuxbsd.opt.tools.64() [0x81cf0e] (??:?)

[pouleyKetchoupp]

@Riteo Thanks for info! Are you able to reproduce it consistently now or is it completely random? Also please share some details about your system and nvidia driver version.

[insomniacUNDERSCORElemon]

@pouleyKetchoupp I can consistently reproduce w/d36b220, GCC (Or Clang), target=release_debug, 5.12.9-arch1-1 (Arch Linux+XFCE+no compositor), 1050 Ti w/driver v 465.31. CPU is a Ryzen 2700, so there isn't a 2nd GPU for any confusion here.

The fastest way is to open any color picker and click+drag (although in debug_release+single window mode this seems to be broken anyways, as in dragging does not continue changing color. And GCC debug seems to have it working but not crashing from that. Crashing aside, different bug?).

A different way is by highlighting text in the search bar in the project or editor settings windows. I can also confirm it happens when scrolling the about page.

In the past I've also have had random freezing (and sometimes even crashing) with debug versions as I've commented here before. But as said in the past this is a very performance-dependent thing.

[john-sevsk]

For me It freezes only after moving cursor while holding mouse button inside text fields and scroll bars but not after selecting text only with keyboard or scrolling with mouse wheel.

Arch Linux 5.12.10-arch1-1
NVIDIA GeForce GTX 1070
NVIDIA Driver Version: 465.31
X.Org X Server 1.20.11
KDE Plasma: 5.22.1

[pouleyKetchoupp]

Thanks all for the replies and reproduction steps!

There are two last things that I would like to confirm before we can contact Nvidia support with more information:

1. Are you able to reproduce the issue with Calinou's nightly build?

Link:
https://archive.hugo.pro/builds/godot/master/editor/godot-linux-nightly-x86_64.zip

2. From what I understand, the easiest and most consistent reproduction steps are:
   -Open any project or start a new one
   -Open menu Help > About Godot
   -Scroll up and down by clicking the slider with left mouse button and dragging until it freezes

Is that accurate? Are you always able to reproduce the issue on the first attempt, and if not how long does it take?

[insomniacUNDERSCORElemon]

@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).

[Riteo]

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.

[john-sevsk]

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

[pouleyKetchoupp]

If you can reproduce this bug, please test this tentative fix from @reduz and let us know if it helps with the freeze when scrolling and the other random freezes related to NVidia GPU:
#49973