search

godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
90.93k stars 21.15k forks source link

Vulkan: Glitching and laggy UI on Wayland #74168

Open Lexpeartha opened 1 year ago

Lexpeartha commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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.

Mathias9807 commented 1 year ago

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

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

tdaven commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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

TDuffinNTU commented 1 year ago

^ 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 commented 11 months ago

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 commented 9 months ago

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

akien-mga commented 9 months ago

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 commented 9 months ago

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.

Tested both with Wayland and X11 Display Server, couldn't notice the difference in terms of this issue. During last few releases it has been better and better, but occasionally still appears in 4.2.1 - while in 4.3 from my testing it doesn't appear to be the case. Whatever fixed it was probably one of 4.3's changes.

All in all, issue has been fixed and it's happy day for Wayland users ❤️

Lexpeartha commented 8 months ago

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 commented 4 months ago

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 commented 4 months ago

@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 commented 4 months ago

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

image

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.

image

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)

image

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

Riteo commented 4 months ago

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 commented 4 months ago

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

See https://github.com/godotengine/godot/issues/84137.

pgrwe commented 4 months ago

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

pgrwe commented 4 months ago

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 commented 4 months ago

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 commented 3 months ago

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 commented 2 months ago

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

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 commented 2 months ago

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

https://github.com/user-attachments/assets/2aa3b9ee-c6a4-465c-a5fd-6838a74ca506

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 12f39befa973ddafdfe1fef10887887b6b2442f6.

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 commented 2 months ago

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.

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.