The short of it is that VRR, or so it seems, leads to vram speed issues which leads to system (and game) freezes and slowdowns. When the issue hits a GPU’s memory will be locked to 96 mhz. Turning off VRR will make it go up to 1000 mhz but then you will be without VRR AND the speed will be constantly at 1000. You can reproduce this issue at certain vram speeds. I don’t know if it’s distributions specific or what but the problem has been around for longer than a year. Last kernel that seemed not to be plagued by this issue, that I have tested, was 6.11.5. And searches give results dating as far back as 6.4. Who is responsible for this issue so it can be reported? Because right now Linux sucks so badly that I wonder why I am still using it, seemingly few in community who even cares about this issue that is so damn frustrating and bad.
I also believe this issue, posted here on Level1, is likely related as well:
EDIT:
I am aware one can simply downgrade to a kernel that doesn’t have this issue but what’s point of a rolling release then? It would be like brushing the dust under a carpet - it still keeps coming back.
Anecdotally, I can’t repro this behavior on Nobara (KDE + Wayland + Adaptive Sync set to Automatic in the display settings UI and cross-confirmed via the monitor’s onscreen UI to be working) on kernel 6.11.9. GPU is a 7900XT. It’s sitting at 1.25 GHz idle per KDE’s System Monitor, and scaling up to 2.5 GHz when loaded up.
Uncertain if it’s an Arch-specific issue, desktop/window manager specific issue, display server specific issues, or maybe I’m testing it wrong.
Thanks for trying. I am experiencing this on Tumbleweed and on kernel; 6.11.8, 6.12.6 and 6.12.8. I am just amazed at how such a system breaking problem have lingered on. Try with 6.11.8 or/and with vram speed changes, it’s not core clock that is the problem. When I tried for 6.11.8 I was able to reproduce the problem, system black screen, without fail at 682 mhz for vram. With 6.12.6/6.12.8 the problem may have shifted i.e 682 mhz may now be fine but some other frequency may have become problematic.
Result is that GPU vram hits 96 mhz and stuck there and that lowers fps to 30 and less. And everytime I turn VRR off and back on it won’t be long before the issue happens again. The fps and stuck at 96 mhz aside, you also have the binary you’re running freezing up. Then you have to shut down the game and relaunch it.
I switched to X11 because I am guessing the issue also ties into Wayland.
Ah, good catch, I’d misconfigured my system monitor panel. Yeah, VRAM speed is locked at 1.25GHz while loaded, and when idling it drops to ~456MHz. But the VRAM speed doesn’t get stuck down there, at least on my box. I don’t have anything installed to adjust GPU or VRAM clocks, though - just running it as-is.
Rolled back to kernel 6.11.8 to check, and it’s the same behavior as I was seeing on 6.11.9, drops to 456 and scales up as needed. Running a wayland session for KDE in both cases.
Took a look at what Nobara claims to tweak and tune, and while it does enable amdgpu for certain older cards, that wouldn’t apply here. I didn’t see anything else called out that they’re doing differently. But their kernels are custom patched with a bunch of different things for compatibility with various gamer laptops, so maybe it’s something snuck in that way? Speculating, though, haven’t dug into it to check (and not sure I’d be able to suss that out with my current skillset anyway).
So… not sure why it’s different on yours. Possible variable on monitor refresh rate? I’ve been running mine on 120hz (despite them being capable of 165 and 240hz respectively) because it knocked down the GPU’s idle power draw by ~30W. But when I’d flipped it back to 240hz briefly on kernel 6.11.9, I didn’t see any changes in the VRAM frequency scaling behavior.
It could be a Tumbleweed specific issue but I have tried so many things:
Set desktop refresh rate to same as game; this seemed to help but did not entirely resolve the issue. Help in that there was less chance of alt tabbing would freeze a game
I shutdown CoreCtrl (overclock/undervolt software for AMD GPUs) and tried to see if that might have been the issue. It was not.
For kernel 6.11.8 without fail setting vram speed to 682 mhz, among other frequencies, would give a black screen similar to when you alt tab between a game and desktop.
I found out 6.11.5, which I booted with, did not give a issue when I set the vram speed to 682. Unfortunately Tumbleweed has rolled on so far I can no longer go back, nor find the kernel in Tumbleweed snapshot history. I upgraded to 6.12.6 quickly, hoping that would solve the issue.
I went back to X11 but it feels so sluggish compared to Wayland that I decided to stick with Wayland again.
I have not touched kernel or graphics packages ever since OS install, it’s whatever Tumbleweed has provided me with.
I tried different refresh rates (120 hz); but I dont believe changing these values fixes the issue. It may just delay it for a time or two.
The issue is more prone to happening at lower monitor refresh rates. For instance I was able to make black screen happen in a game, without alt tabing, by simply setting in-game fps cap to 48. Lower fps means lower vram speed and while 682 mhz (x2 on Windows) was one of the problematic frequencies, I can’t reproduce it with 6.12.8, there was others as well.
Softwares on Linux to control maximum memory are LACT and CoreCtrl. I ran memtest_vulkan with and without adaptive sync enabled (via display) and the issue of system black screen freeze happens regardless if VRR is on or not. 674 mhz works fine but 682 will freeze. What makes me think VRR plays a role is that disabling (and enabling) VRR will make vram speed always go back to normal mhz after its get stuck at 96 mhz.
You need to set a fixed mhz vram speed otherwise tests like Furmark and memtest_vulkan will run at maximum (1000 mhz) - that doesn’t lead to black freeze.
EDIT:
My gpu has a boost clock of 2581 according to TechPowerUp BUT when I check global profile of CoreCtrl the maximum is set to 2609 and a while ago, while troubleshooting (kernel 6.11.8) I could swear the default value was 2614! Someone mentioned CoreCtrl only exposes what is in the kernel.
Randomly barging in to say that I haven’t had this issue because I have multiple monitors. But that explains why memory clock is locked at 1100 on my 7900xt I suppose? Is windows better at power savings in this certain scenario?
I don’t think so. The GPU under normal operation will fluctuate between 96 and 456 mhz (desktop browsing). It’s under heavy graphical load (games and benchmarks) that it will and should boost to maximum vram speed.
With only one monitor(4k one) in linux 6.12.8-arch1-1/hyprland VRR on I do 456MHz on gpu mem clock in idle.
And as soon as I turn on a monitor without VRR support and a different refresh rate it goes back up to 1249MHz
Ya really got me testing my shit now. I turned off the overclock setting(138 to 120Hz) on my LG gaymer monitor ( LG Electronics LG ULTRAGEAR+ 209NTLE6N416) and VRR seems a bit more reliable(less trigger happy to jump from 40Hz to 138Hz) with slightly less flickering and if I veer my focus off of it for >3 seconds it actually drops to 96Mhz. Having all 3 monitors in is the same tho.
so under heavy Hertz or multiple monitors it seems rather normal. What isn’t normal is dipping to 96MHz in any capacity when it isn’t supposed to. What’s your monitor configuration?
I did some tests and even without VRR enabled for display I still got black screen freezes
When it drops to 96 mhz it will stay there, it’s not a normal fluctuations of speed because of work load (idle or not). And when you disabled VRR it gets stuck at 900-1000 mhz. My setup is a single monitor 180 hz. Again if you encounter this issue it will get stuck at 96 hz.
Funny enough I thought it may be because I recently connected a second monitor, temporarily though, and also thought the cable or ports may be bad. So I disconnected power from my monitor, and the display port, and reconnect to see if that would have an effect.
I don’t think so. The second monitor, high refresh rate, I hooked up had a screen issue. But I reflected on how long I have seen the instance of this issue, without being aware of what caused it, and it was long before I connected this second monitor. So that eliminates the notion that hooking up second monitor (one 180z, other 165 hz) somehow started this issue. It seems to me a AMD VRR issue related to Wayland.
Could be that, but I haven’t ever experienced it, and I’ve been AMD and wayland for years. I wonder if it could be a displayport/HDMI issue, since I use both. You seem like you’d only use displayport
I use only DP for time being yes. I am going to try with 144 hz and 165 hz and see if those refresh rates “fix” the problem. Could be that 120 and 180 hz cause issues for some reason.
I noticed when vram speed gets stuck at 96 mhz (resulting in 30 fps and lower) the display refresh rate (it’s OSD) shows 70 (its set to 144 hz on desktop and games).
