grow a plant, hug your dog, lift heavy, eat healthy, be a nerd, play a game and help each other out
Huh interesting. Are these displays all the exact same model?
There’s a relatively new feature in the amd gfx display abstraction layer called freesync power optimisation. This feature leverages panel VRR to help mclk idle low at the desktop. This was introduced for single display use with RDNA 2, and expanded to dual display along with RDNA3s MALL advancements. I’m not sure if this is expanded further with RDNA 4 but I can try to find out.
This isn’t true for Vega 10 and 20 due to their use of HBM2. In general what you’re describing is a comparative weakness of GDDR as a technology. I don’t think there’s anything to suggest there’s an inherent issue with idle power on older gen asics at >60 Hz save from the typical limitations with VBI compatibility in an array of panels or display bandwidth thresholds. In the case of VBI compact issues, modifying EDIDs can indeed help.
That’s kind of curious. I don’t think 3D_FULLSCREEN should inherently determine idle mclk behaviour in and of itself. Is this just a single 1440p display at 120Hz? Is VRR enabled?
huh, I generally expect Vega10 based GPUs to idle at ~3W TGP (not inclusive of other board power losses like VRM). Can you tell us what you display setup is? Can you get a reading of your idle mclk using something like CoreCtrl?
video playback will likely kick the asic out of idle. What’s your power use at true desktop idle?
Generally speaking, vega 10 (56, 64) and 20 (radeon vii) are able to achieve decently low desktop idle with varied display configs due to the memory technology they employ.
Can you tell us which distro and display config this is with?
I’m also in 3D_FULLSCREEN on NV21XT but my idle mclk is 96 MHz. TGP (not to be confused with TBP which is only communicated on RDNA 3 and up) is 6 watts at idle with my browsers open. GNOME 47 + Wayland, 2560 x 1440 @ 180Hz + 1920 x 1080 @ 60Hz, VRR enabled on both displays. This is with Fedora 41, kernel 6.13.6-200.fc41.x86_64
For context, the GPU index (0,1,2 etc) will depend on the number of video adapters you have in the system. If you have a CPU with integrated graphics, there’s a chance this will be registered as 0000 whereas the dGPU will be 0001.
OLED is practically contingent on HDR colour space for optimal experience. You wouldn’t want to limit yourself to SDR on that type of display.
I’ve had situations like this with my notebook where it would appear to do nothing from the GUI when clicked. It was because I didn’t have power connected, and I think gnome software has since been updated to reflect this.
Assuming you were connected to power, I’m not sure but it may be worth reporting as a bug to gnome-software?
FWIW, your UEFI is generally likely to reset with significant hardware changes (system memory, CPU). It’s generally fine with video card, disk and power supply swaps so long as it doesn’t boot into a stop code as a result.
Which index were these disks arranged in? Windows will install its bootloader on 0 regardless of where you physically install the OS.
I like to keep OS disks self contained, and tend to completely remove other connected disks when conducting a new install. This is a must for Windows, I’ve not had a Linux distro place it’s bootloader in anything other than the OS destination.
I see. You can temporarily edit your grub before the OS loads. This should afford you the opportunity to boot into the system without EDID modifications, though im not sure if your modified EDID will still load under this scenario. If so, you may need to switch into a CLI session to undo your changes.
I’m sorry to hear that. Does this system only have access to this single display? Did you use a kernel command to modify your EDID? If so, are you able to temporarily modify your grub before booting into the OS?
Archwiki references a [@<refresh>] (presumably denoted as [@144] for something like 144Hz) property, hopefully that’s all you should need to define, though I’m not sure if you’ll need to manually recalculate vertical and horz timings or something.
Maybe this can help fill in any gaps
You want to look into modifying your display EDID.
I don’t believe there’s a GUI for this on Linux but this post referencing the Archwiki might come in handy
https://foosel.net/til/how-to-override-the-edid-data-of-a-monitor-under-linux/
they’re trying to ensure an acceptable UX with their browser.
I suppose the root of the issue is developers specifically targeting and testing on chrome.
I don’t understand how this would make Firefox look bad unless you’re pointing at the dire browser share situation.
it do be that way :(
Their latest microcode update from 7 days ago was declared as final. Time will tell about the efficacy of the most recent fixes.
Unfortunately it may only be available via board partners as beta BIOS updates at present.
Isn’t this the kernel driver included by default?
I don’t believe FPO was expanded to >2 displays, though having identical panels would eliminate VBI complexities. Will be interested in understanding how this behaves with rdna 4.