Vulkan: Glitching and laggy UI on Wayland

[Lexpeartha]

---

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

---

Godot version

stable 4.0 (although present in last rc)

System information

Fedora Linux 37 (Workstation Edition)

Issue description

Here's a video of me opening and closing some nodes for reference

This bug appeared in the last RC, and is still there in stable.
This glitchy effect is not just affecting node trees, but all the other "toggleable" menus and such, like directories, properties and etc.

Steps to reproduce

Not sure how to reproduce this, but here are more info about my PC which might help track it down

CPU: AMD Ryzen™ 5 4600H with Radeon™ Graphics × 12
GPU: NVIDIA GeForce GTX 1650 Ti

I'm running Wayland, with nvidia driver version being 525.89.02-1.fc37

Minimal reproduction project

Bug is not specific to a project

[Calinou]

• Related to Keyboard input ignored in some editor fields using a Wayland session (DisplayServer regression) #57288.

Can you reproduce this on a X11 session? NVIDIA + Wayland is notoriously buggy, so I recommend sticking to X11 when possible.

Also, can you reproduce this after enabling Single Window Mode then restarting the editor? Can you reproduce this after switching the rendering method to Compatibility in the top-right corner?

[Lexpeartha]

@Calinou Done with reproductions you mentioned:

While staying on Wayland, enabling Single Window Mode and restarting the editor still behaved the same. When I changed to Compatibility it worked fine however.

After testing it on X11, it seems there are no such glitches under any combination of these settings, so I guess you're right

[Mihuy1]

I also have this on wayland but it does go away on x11. But because I really don't want to use x11 I will just use godot on windows for now

[Calinou]

This bug appeared in the last RC, and is still there in stable.

If you can compile the engine from source, you could look into bisecting the regression to greatly speed up troubleshooting.

• 4.0.rc5's commit hash (good) is 0cd148313213e2923004be65bafd6a3781c917ec.
• 4.0.stable's commit hash (bad) is 4.0.stable.

[Mathias9807]

I think I have the same issue. Selecting different entries in the node tree or almost any other UI list causes the UI to flash like in the video. Also on Fedora 37 with wayland on an NVIDIA laptop. I tried bisecting the issue and ended up way further back on b42bbca.

Does that make any sense? Reverting that commit seems to fix the flashing in the scene's node tree but doesn't do anything on other UI elements (For example the settings dialog where it still happens). However it's been difficult to test this as the issue stops occurring consistently whenever I try to reproduce it. I might've gotten something wrong

[Lexpeartha]

Also now that I've come around to use latest version more 4.0.2 seems to do that a lot less, definitely less noticeable than in the video (but I've updated OS version, kernel version and nvidia drivers in the meantime so maybe it had something to do with that?)

[CBerry22]

I'm still getting this in 4.0.2 really bad.
Same as OP, Single window mode doesn't help, but compatibility mode fixes it.

I'm on arch (btw) with latest nvidia drivers running hyprland compositor.

Only seems to effect the 2D UI, 3D seems to run smooth. I'll stick to Windows for the time being.

[lonegamedev]

Also getting this on 4.0.2, nvidia. Single window mode did nothing.
No issues on X.
The main issue is stuttering in most editor UI elements. The worst is code editor.
Typing code in slow-mo lmao.

[ivakam]

I'm also getting the same input lag on nvidia + wayland (GNOME, Arch-based) on 4.0.3. X11 works fine, issue is immediately obvious on switch to wayland.

[sourcelocation]

@Calinou experiencing this issue on amd gpu too, it's not just nvidia

[tdaven]

Would be curious to know what Xwayland version is being used since it seems to work fine on regular Xorg and just fail under Xwayland.

$ Xwayland -version
The X.Org Foundation Xwayland Version 22.1.9 (12201009)
X Protocol Version 11, Revision 0
Build ID: xorg-x11-server-Xwayland 22.1.9-2.fc38

I do not see an issue if I pass --disable-vsync to the editor. Tested with the following launch options:

bin/godot.linuxbsd.editor.x86_64 --display-driver x11 --rendering-driver vulkan --rendering-method forward_plus --disable-vsync

[CzechBlueBear]

I believe this is https://gitlab.freedesktop.org/xorg/xserver/-/issues/1317

If it is the case, it should react on setting XWAYLAND_NO_GLAMOR=1 in /etc/environment. Sadly, on my machine this makes all X11 applications unbearably slow (like, snail-slow - we are speaking about 3-10 fps).

The problem should disappear, or become much rarer, when Godot has native Wayland support (the race condition is still there but gets triggered much less).

[Riteo]

@CzechBlueBear

The problem should disappear, or become much rarer, when Godot has native Wayland support (the race condition is still there but gets triggered much less).

Note that there's already a backend in the works: #57025

[orowith2os]

This problem will also be fixed, or so I hope (and presume) when explicit sync support finally lands.

[TDuffinNTU]

^ Brilliant news. Did notice this happening with the latest version and it was quite jarring but not unusable - Just a lengthy delay on most UI actions. Thankfully I still swap between both window sessions on KDE but look forward to this being addressed

[ElectricMolasses]

No idea if this will help anyone while we're waiting for the native PR, but if I run in it hyprland as a floating window rather than a tiled window, and keep it under what seems to be approx 1920x1080 resolution, all of these issues go away for me. As soon as I tile it, at seemingly any size, or expand the window on one of my larger monitors it becomes slow and delayed again.

[Lexpeartha]

After testing the new Godot 4.3-dev3 release, all problems seem to be gone - most likely due to Wayland support 👍🏽

[akien-mga]

Note that Wayland support is opt-in currently, so if you didn't enable it manually, it would still be using Xwayland. If that's your case and the bug is fixed anyway, then it was fixed by another change impacting X11.

[Lexpeartha]

False alarm 😅

After working a bit more with editor it seems that there are still traces of this issue as it can be seen here.
It's still better than it used to be, and it appears less frequently but it is still an issue.

Def needs more testing

Edit: just tested this a bit more in dev3 - issue is present both with XWayland and Wayland as driver server although XWayland handles this better and is barely noticeable in comparison

[pgrwe]

I am using a NVIDIA card (1660ti, 550 drivers) and I am still seeing this issue on KDE Plasma 6.1 wayland sessions,
Arch Linux, latest kernel (6.9.5).
Issue appears when using native wayland backend and xwayland. Works fine on x11. Likely a NVIDIA issue.

Has anybody with an AMD/Intel GPU has this issue occur?

[Riteo]

@payl-ampa I heard that the latest 555 drivers should have explicit sync, which is supported by plasma 6.1. Perhaps you could give that a shot if they've been packaged on Arch.

Regarding the AMD/Intel thing, I daily drove the backend ever since its inception (:P) and I don't think I've ever seen a fault like that. From my untrained eye, it feels like the frame order is messed up. Perhaps it's related to triple-buffering, supposing it's enabled?

[pgrwe]

@Riteo upgrading to 555 made the editor ran much smoother...when I was able to actually get the editor to run. It seems like its using my iGPU instead of my dGPU. Same warning about DRI_PRIME on an AMD card here.

I tried forcing to render with the dGPU as documented in PRIME, the icon at the top bar would appear with the wayland logo but no window would appear. It also seemed like OpenGL 3.3 was being forced, but when I tried running through vulkan the editor immediately crashed.

I don't know what is causing this, but sometimes when I run godot it just works... (running on wayland, no noticeable editor glitches or lag, runs on the correct GPU)

Regardless, probably going to stick to x11 till things get more stable

[Riteo]

Same warning about DRI_PRIME on an AMD card

Yeah those are generic and a byproduct of the hack we use for dGPU detection on Linux. Weird though that it selected the iGPU still, oh well...

It also seemed like OpenGL 3.3 was being forced, but when I tried running through vulkan the editor immediately crashed.

The project manager uses OpenGL by default unless --rendering-driver is passed, so nothing wrong here.

I don't know what is causing this, but sometimes when I run godot it just works... (running on wayland, no noticeable editor glitches or lag, runs on the correct GPU)

I wonder if the aforementioned PRIME detection is messing up something; perhaps selecting the iGPU with the __GLX_VENDOR_NAME makes everything panic. Also, the wiki entry you linked describes some other methods, such as also setting DRI_PRIME or running everything through prime-run (offered by nvidia-prime), which should set the relevant properties automatically. Could you try doing that?

[Calinou]

From my untrained eye, it feels like the frame order is messed up.

See #84137.

[pgrwe]

I wonder if the aforementioned PRIME detection is messing up something; perhaps selecting the iGPU with the __GLX_VENDOR_NAME makes everything panic. Also, the wiki entry you linked describes some other methods, such as also setting DRI_PRIME or running everything through prime-run (offered by nvidia-prime), which should set the relevant properties automatically. Could you try doing that?

Tried setting DRI_PRIME to 1 and using prime-run when opening up godot and experienced the same issue from earlier, the icon in the task bar appears but no window does:

{DRI_PRIME example)

[pgrwe]

Update: Nvidia stable 555 drivers appeared to have fixed many issues related to this, I still need to stay on 4.2 for jolt, but in a month or two most of these problems may be sorted out.

[Lexpeartha]

I'm using Nvidia v555 drivers, and while it irons out 90% of bigger problems - it's still noticeable if you look for it. That's why I got mistaken earlier.

So no, it doesn't fix it completely but it gets better!

[eobet]

I don't know which driver I'm on, since I just use the System Update app provided by Nobara (pretty new to Linux).

But, using "prefer Wayland" in rc2 and panning a visual shader graph, I feel that it's at most 15fps... it's super noticeable while not toggling the Wayland option the editor experience is smooth.

Looking around in the 3D viewport is not as bad, but still bad.

[bemug]

I have this exact same issue as described. I did some testing.
Using latest Arch with an AMD card and sway.

• It was working fine with 4.2 and old Arch (while it was a bit laggy ?). Edit : It was not.
• I have the DRI_PRIME warning, setting it does nothing.
• Forcing xwayland does nothing.
• Switching to compatibility renderer fixes the issue.
• Switching Godot to fullscreen fixes the issue. You read that correctly.
• Edit: Disabling VSYNC does nothing.

The fullscreen part makes me think it might be related to hardware acceleration.
If you have anything to try I can run some tests.

[bemug]

Here is a showcase of Godot jittering (without update_continuously) so you can have a look :

2024-08-22.15-40-14.mp4

I took the time to bisect from 4.2 all the way up to 4.3. It leads me to this commit as the first bad commit 12f39be.

From this commit, editor settings path changed. I navigated through ~/.config/godot/ and ran diff editor_settings-4.3.tres editor_settings-4.tres.
I noticed in 4.2 I had interface/editor/update_continuously = true, but not in 4.3.

Enabling update_continuously in 4.3 fixed the issue.

Is this expected behavior ?

Edit : I disabled update_continuously in 4.2 and got the issue too.

[oeramo]

Enabling update_continuously in 4.3 fixed the issue.

In my case, enabling update_continuously doesn't have any effect.

This is a fresh install of Godot 4.3.stable, and the option wasn't in the editor_settings-4.3.tres file, so I added it to the last line. I can also confirm that the issue disappears when the window is in fullscreen mode.

• Arch Linux
• Kernel 6.10.7
• Swaywm 1.9
• AMD RX 6750 XT
• Mesa 24.2.1

On my laptop running Arch Linux and Hyprland on an integrated Radeon 760M, I have never experienced the issue in either fullscreen, tiled or floating mode.