Wayland: High GPU usage #103019
Operating system: Arch Linux, Kernel 6.0, KDE Plasma 5.26.4 (Wayland session)
Graphics card: AMD RX 6700 XT, AMDGPU driver (Mesa 22.2.3)
Short description of error
When using Blender 3.4.0 in the Wayland session, very high GPU usage is observed when doing simple tasks such as just moving the viewport camera; even in an empty scene.
On my desktop, this doesn't affect performance in the scenes I have on hand.
On my laptop equipped with a Ryzen 5 5600H (RX Vega integrated graphics), Blender 3.3.1 under xwayland works for simple modeling tasks just fine, with no perceived hitches.
When using 3.4.0 on that laptop (i.e. Wayland mode), Blender is very stuttery even when moving the viewport in an empty scene.
Exact steps for others to reproduce the error
- Make sure your desktop environment uses Wayland.
- Open an empty or very simple scene in Blender 3.4.0, make sure it's not in xwayland mode.
Move the viewport or objects in the scene and observe the GPU utilization on your machine.
In this video I demonstrate the performance on both my desktop computer and laptop, in that order. On each machine, I show off Blender 3.4.0 (Wayland) first, then 3.3.1 (Xwayland).
00:00 - Blender 3.4.0
00:18 - Blender 3.3.1
00:30 - Blender 3.4.0
00:40 - Blender 3.3.1
Changed status from 'Needs Triage' to: 'Needs User Info'
Note that I'm running a fairly similar system and can't redo this:
**System Information** Operating system: Linux-6.0.11-arch1-1-x86_64-with-glibc2.36 64 Bits Graphics card: AMD Radeon RX 5700 XT (navi10, LLVM 14.0.6, DRM 3.48, 6.0.11-arch1-1) AMD 4.6 (Core Profile) Mesa 22.2.3
Could you please test the following:
- Force running 3.4 with
WAYLAND_DISPLAYto an empty string:
- Try another compositor (gnome-shell / sway for example).
@ridge Any update here? Otherwise I have to close this report.
I'll have to give it a shot with a different compositor later (putting it on my planner to have it done by the weekend), but I did try it with forced Xwayland and find that GPU usage is drastically lower on 3.4, than it is in native Wayland mode (basically, it remains the same as initially reported).
However, and not sure if this is because of running on Plasma 5.27 beta + Mesa 22.3.3, it's at least not laggy anymore when moving a cube around in an empty scene on the laptop.
Nevertheless, I'll make a bootable media and try this with Gnome sometime this weekend. Thank you for your patience.
@ridge thanks for looking into this, please try this with a recent daily build as well, since there have been some fixes relating to Wayland and CPU/GPU usage that could relate to this report.
%%%Hi there, I've yet to get Blender working properly in a GNOME session, but I'm still working on it; none of the live sessions I tried over the weekend with GNOME as the compositor would start Blender in Wayland (they all just used xwayland no matter what), so I think I just have to bite the bullet and dual-boot temporarily (would rather avoid having to install a second DE on my primary installations), but I did go ahead and try 3.4.1 (official 20th of December release), 3.4.1 v34.ef9ca44dee7f and 3.5.0 master.68625431d5d0, and could reproduce the issue on all three of them, in the same Plasma environment as before.
I'll see if I have time to get GNOME (or any another compositor) to cooperate tomorrow.%%%
@ridge it's likely they're using Xwayland because libdecor is not found. This is only the case for GNOME (KDE or other compositors don't have this requirement).
I managed to try out the aforementioned versions in GNOME and can still reproduce the issue, I ran them in a Fedora live environment with radeontop for monitoring, and found that when wiggling the default cube around in an empty scene, the GPU utilisation was:
If there's anything else I can test to help out, I'd be very happy to do so.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?