I’m a 7900 launch day customer who’s been on Linux the whole time.
AMD still has not fixed the vram getting stuck at 96 or 456mhz (low power states) since day one.
It’s an issue that only happens on uncommon screen setups, but every time I want to play a game I have to start the game and then replug my monitor, or change it’s resolution to something else and back again. Every time.
This has been a reported bug ok the 6000 series cards, on launch. And they’ve still not fixed it.
You kind of alluded to part of it there; it’s not so much a bug in sw/fw as it is a hardware limitation at both the adapter and display side. The variables for displays are vertical blanking intervals (and differences between panels), as well as total display bandwidth.
with RDNA2, a feature was implemented in DAL to leverage VRR in order to allow a single connected display system to achieve a lower mclk, and thus lower idle power draw. With RDNA3, hardware changes (MALL specifically) broadened this capability two concurrent displays. Even then, it’s not bulletproof.
The display eng team has more or less exhaustively worked towards this over the course of RDNA3’s lifespan; their work is applicable to both Windows and Linux.
Literally anything I’ve had that was “uncommon” has had this issue.
These setups have worked fine:
Single, dual, and triple 1080p and 1440p, regardless of Hz.
Single 4k, also regardless of Hz.
All these setup my MCLK gets stuck in 96MHz or 456MHz and needs a reconnect or resolution/refresh rate change to “unstick” so I can get higher MCLK and actually play games.
Dual and Triple 4k, regardless of Hz.
Dual/triple 4K with vertical 1080, regardless of Hz.
Dual/triple 4k with dual vertical 1080, regardless of Hz.
It’s strange that you say that they’ve worked specifically to get LOWER MCLK rates for single/dual displays, when my issue is specifically that my MCLK is stuck at low MCLK with “uncommon” display setups? Almost sounds like you’re saying they’ve specifically worked to make my issue even worse lmao.
Oh sorry, I misunderstood, so you actually get locked into a low mclk under specific display configurations? I’ve genuinely never heard of or personally experienced that across a breadth of hw and sw configs.
I’m wondering if it could be worth probing the power play sysfs interface or hwmon the next time this happens to try and understand what’s happening there.
Do you use client apps to interact with tuning settings like LACT? Can you link me to an existing bug report so I can follow up with engineering?
So I never personally raised a bug report, but this issue was the one I saw when I first got the gpu: https://gitlab.freedesktop.org/drm/amd/-/issues/2460
Exact same issue I’ve always had, MCLK gets stuck at 96MHz and refuses to budge, but since it was relatively easily solved with a quick script that just changes one of my monitors between 60hz and 59.97hz I just accepted that 3 second operation as part of what I had to do to play games lol.
I can replicate the issue, though right now I’ve got the opposite issue since getting a 4K144Hz monitor that ends with the MCLK being stuck at maximum at all times, which tbh I’m fine with as I don’t care about the efficiency, I need the heating in this -30c weather anyway.
I’m a 7900 launch day customer who’s been on Linux the whole time.
AMD still has not fixed the vram getting stuck at 96 or 456mhz (low power states) since day one. It’s an issue that only happens on uncommon screen setups, but every time I want to play a game I have to start the game and then replug my monitor, or change it’s resolution to something else and back again. Every time.
This has been a reported bug ok the 6000 series cards, on launch. And they’ve still not fixed it.
Can you elaborate on your display config?
You kind of alluded to part of it there; it’s not so much a bug in sw/fw as it is a hardware limitation at both the adapter and display side. The variables for displays are vertical blanking intervals (and differences between panels), as well as total display bandwidth.
with RDNA2, a feature was implemented in DAL to leverage VRR in order to allow a single connected display system to achieve a lower mclk, and thus lower idle power draw. With RDNA3, hardware changes (MALL specifically) broadened this capability two concurrent displays. Even then, it’s not bulletproof.
The display eng team has more or less exhaustively worked towards this over the course of RDNA3’s lifespan; their work is applicable to both Windows and Linux.
Literally anything I’ve had that was “uncommon” has had this issue.
These setups have worked fine: Single, dual, and triple 1080p and 1440p, regardless of Hz. Single 4k, also regardless of Hz.
All these setup my MCLK gets stuck in 96MHz or 456MHz and needs a reconnect or resolution/refresh rate change to “unstick” so I can get higher MCLK and actually play games. Dual and Triple 4k, regardless of Hz. Dual/triple 4K with vertical 1080, regardless of Hz. Dual/triple 4k with dual vertical 1080, regardless of Hz.
It’s strange that you say that they’ve worked specifically to get LOWER MCLK rates for single/dual displays, when my issue is specifically that my MCLK is stuck at low MCLK with “uncommon” display setups? Almost sounds like you’re saying they’ve specifically worked to make my issue even worse lmao.
And ofc the issue is nonexistent on windows.
Oh sorry, I misunderstood, so you actually get locked into a low mclk under specific display configurations? I’ve genuinely never heard of or personally experienced that across a breadth of hw and sw configs.
I’m wondering if it could be worth probing the power play sysfs interface or hwmon the next time this happens to try and understand what’s happening there.
Do you use client apps to interact with tuning settings like LACT? Can you link me to an existing bug report so I can follow up with engineering?
So I never personally raised a bug report, but this issue was the one I saw when I first got the gpu: https://gitlab.freedesktop.org/drm/amd/-/issues/2460 Exact same issue I’ve always had, MCLK gets stuck at 96MHz and refuses to budge, but since it was relatively easily solved with a quick script that just changes one of my monitors between 60hz and 59.97hz I just accepted that 3 second operation as part of what I had to do to play games lol.
There’s also a level1techs thread with people with similar issues here: https://forum.level1techs.com/t/linux-really-sucks-right-now/223700 And also this Bazzite issue: https://github.com/ublue-os/bazzite/issues/1070
I can replicate the issue, though right now I’ve got the opposite issue since getting a 4K144Hz monitor that ends with the MCLK being stuck at maximum at all times, which tbh I’m fine with as I don’t care about the efficiency, I need the heating in this -30c weather anyway.
Thanks for these, I’ll discuss with the DAL team when I get the chance