[regression] Bad performances with radeonsi probably due to zero VRAM usage
- Check if a new version of Mesa is available which might have fixed the problem.
- If you can, check if the latest development version (git main) works better.
I have the very recent Mesa 21.0.3 and it was like that for a while so I doubt the development one would have fixed it.
- Check if your bug has already been reported here.
I checked with the "zero", "vram", "radeon", "(un)used" and the radeonsi gitlab tag but I didn't find any that looked similar to mine.
inxi -GSC -xx:
System: Host: toolbox Kernel: 5.11.16-300.fc34.x86_64 x86_64 bits: 64 compiler: gcc v: 2.35.1-41.fc34 Desktop: GNOME tk: GTK 3.24.29 wm: gnome-shell dm: N/A Distro: Fedora release 34 (Thirty Four) CPU: Info: Quad Core model: AMD A8-7410 APU with AMD Radeon R5 Graphics bits: 64 type: MCP arch: Puma rev: 1 cache: L2: 2 MiB flags: avx lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 17567 Speed: 998 MHz min/max: 1000/2200 MHz boost: enabled Core speeds (MHz): 1: 998 2: 998 3: 998 4: 998 Graphics: Device-1: AMD Mullins [Radeon R4/R5 Graphics] driver: radeon v: kernel bus-ID: 00:01.0 chip-ID: 1002:9851 Device-2: AMD Jet PRO [Radeon R5 M230 / R7 M260DX / Radeon 520 Mobile] driver: radeon v: kernel bus-ID: 01:00.0 chip-ID: 1002:6665 Display: wayland server: X.Org 22.214.171.124 compositor: gnome-shell driver: loaded: ati,radeon unloaded: fbdev,modesetting,vesa resolution: 1600x900~60Hz s-dpi: 96 OpenGL: renderer: AMD KABINI (DRM 2.50.0 5.11.16-300.fc34.x86_64 LLVM 12.0.0) v: 4.5 Mesa 21.0.3 direct render: Yes
(so I have an integrated GPU and a dedicated one, but they are both affected by this performance issue and lack of VRAM usage)
Describe the issue
When using a game that uses 3D in a non trivial way, the game has pretty bad performances. With games like FlightGear, Veloren, Minetest, Godot and Minecraft I don't manage to go over 30fps, with usually around 20fps for most games but it goes as low as 5-10fps for FlightGear or Veloren even with the lowest/cheapest settings. I can easily reproduce this issue at any time, with both my integrated GPU and the dedicated one (which are not the same obviously, but probably part of the same "series" or something like that?).
Some time ago I tried debugging the issue with various tools and by testing things, but I didn't find anything at first so I didn't open an issue because I had no idea if it was just my GPUs who were both slow, or a driver/Mesa issue.
But I thought again about it recently and had an other look, and it seems like I might have found what the problem is. So basically I was looking at the
glxinfo -B output and noticed that the available/free video memory was always the same as the total dedicated video memory that my GPU had, although I had FlightGear running. I found it strange so I ran radeontop, which gave the same results: no VRAM is actually used.
Here's the part of the
glxinfo -B of the integrated GPU:
Memory info (GL_NVX_gpu_memory_info): Dedicated video memory: 1024 MB Total available memory: 3067 MB Currently available dedicated video memory: 1024 MB
As far as I remember it was pretty much always slow like thisthis, going as far as Fedora 33 release date (end of october 2020) and probably Fedora 32 too (6 months before 33). I don't know if it was a problem previous to Fedora 32 because I only used GUI apps, where it's not noticeable at all, but I wouldn't be surprised if it was the case before Fedora 32 too.
So unfortunately I don't think I can give a time where it regressed… :(
Log files as attachment
I looked at the dmesg but I didn't see any error logs related to the GPU. There was only the GPU initialization logs, so nothing unusual.
Anyway, gl-logs.txt is the logs of running with
LIBGL_DEBUG=true, for extra informations.
Screenshots/video files (if applicable)
Here's screenshots of various programs launched with
Any extra information would be greatly appreciated
I'm happy to compile and test any patched Mesa that should fix the issue, since with meson it's a breeze :)
Please let me know if you need more information, like an