AMD Graphics Driver In Linux 6.5 Improves Power Management, Adds CP Shadow Buffer

[Termy]

On RDNA2, 2 monitors (2* 1440p) I have between 7 and 11W (idle - all open stack):

It's not like that is a new or unknown issue. It even still is present on Windows afaik.
I've also got two (almost identical) 1440p monitors and am getting 40w idle draw, no matter what refresh rate (60, 90, 120, 144) i set on those. Had this issue with my 5700xt as well as with my current 6900xt. Tried to play with the manually created settings, but had no luck at all unfortunately...
Really hope FAMS will solve that issue for good finally.

[Grinness]

It's not like that is a new or unknown issue. It even still is present on Windows afaik.
I've also got two (almost identical) 1440p monitors and am getting 40w idle draw, no matter what refresh rate (60, 90, 120, 144) i set on those. Had this issue with my 5700xt as well as with my current 6900xt. Tried to play with the manually created settings, but had no luck at all unfortunately...
Really hope FAMS will solve that issue for good finally.

I am not arguing that there are no issues, I was wondering what card is pulling 100W on idle ...
(Fortunately) my experience on 2 different AMD GPUs and 2 different CPUs (Intel & AMD) is very good
... and obviously any further improvement is welcome

Cheers.

[horstderheld]

100W sounds a bit much, even with the MCLK stuck it should be around 40W. Here is the bug, it's a problem with all rdna2 GPUs https://gitlab.freedesktop.org/drm/amd/-/issues/1403

[Termy]

I was wondering what card is pulling 100W on idle ...

Yeah, i agree that that sounds a bit much. I think the 5700xt was at around 50w, the 6900xt is around 40w. And as that's just a result of the memory clocking at maximum that should basically be the same for all cards/setups i guess

[Grinness]

100W sounds a bit much, even with the MCLK stuck it should be around 40W. Here is the bug, it's a problem with all rdna2 GPUs https://gitlab.freedesktop.org/drm/amd/-/issues/1403

Interesting, thanks for the link.
However not all RDNA2 seems to suffer from the problem, my rx6800 with 2 output (DP monitor and HDMI TV, both at 1400p , 60Hz (average GPU 6W):

 > cat /sys/class/drm/card0/device/pp_dpm_mclk                                                                                                                                                                                                                                                          
0: 96Mhz *
1: 456Mhz
2: 673Mhz
3: 1000Mhz

sudo cat /sys/kernel/debug/dri/0/amdgpu_pm_info

FX Clocks and Power:
        96 MHz (MCLK)
        0 MHz (SCLK)
        1825 MHz (PSTATE_SCLK)
        1000 MHz (PSTATE_MCLK)
        6 mV (VDDGFX)
        6.0 W (average GPU)

GPU Temperature: 43 C
GPU Load: 0 %
MEM Load: 2 %

SMC Feature Mask: 0x00003343a36b6df9
VCN: Disabled

Clock Gating Flags Mask: 0xb8198a0d
        Graphics Fine Grain Clock Gating: On
        Graphics Medium Grain Clock Gating: On
        Graphics Medium Grain memory Light Sleep: Off
        Graphics Coarse Grain Clock Gating: On
        Graphics Coarse Grain memory Light Sleep: On
        Graphics Coarse Grain Tree Shader Clock Gating: Off
        Graphics Coarse Grain Tree Shader Light Sleep: Off
        Graphics Command Processor Light Sleep: Off
        Graphics Run List Controller Light Sleep: Off
        Graphics 3D Coarse Grain Clock Gating: On
        Graphics 3D Coarse Grain memory Light Sleep: Off
        Memory Controller Light Sleep: Off
        Memory Controller Medium Grain Clock Gating: On
        System Direct Memory Access Light Sleep: Off
        System Direct Memory Access Medium Grain Clock Gating: On
        Bus Interface Medium Grain Clock Gating: On
        Bus Interface Light Sleep: Off
        Unified Video Decoder Medium Grain Clock Gating: Off
        Video Compression Engine Medium Grain Clock Gating: Off
        Host Data Path Light Sleep: On
        Host Data Path Medium Grain Clock Gating: On
        Digital Right Management Medium Grain Clock Gating: Off
        Digital Right Management Light Sleep: Off
        Rom Medium Grain Clock Gating: Off
        Data Fabric Medium Grain Clock Gating: Off
        VCN Medium Grain Clock Gating: Off
        Host Data Path Deep Sleep: Off
        Host Data Path Shutdown: Off
        Interrupt Handler Clock Gating: On
        JPEG Medium Grain Clock Gating: Off
        Repeater Fine Grain Clock Gating: Off
        Perfmon Clock Gating: Off
        Address Translation Hub Medium Grain Clock Gating: On
        Address Translation Hub Light Sleep: On

Again on Arch, with latest kernel, mesa, KDE, Wayland

[Grinness]

However, if I push the TV to its native resolution (2160p) while monitor is at 1440p -- both at 60Hz, I do get higher power consumption on idle (34W):

> cat /sys/class/drm/card0/device/pp_dpm_mclk                                                                                                                                                                                                                                                        
0: 96Mhz
1: 456Mhz
2: 673Mhz
3: 1000Mhz *
 
 > sudo cat /sys/kernel/debug/dri/0/amdgpu_pm_info                                                                                                                                                                                                                                                    
GFX Clocks and Power:
        1000 MHz (MCLK)
        0 MHz (SCLK)
        1825 MHz (PSTATE_SCLK)
        1000 MHz (PSTATE_MCLK)
        6 mV (VDDGFX)
        34.0 W (average GPU)

GPU Temperature: 49 C
GPU Load: 0 %
MEM Load: 0 %

SMC Feature Mask: 0x00003343a36b6df9
VCN: Disabled

Clock Gating Flags Mask: 0xb8198a0d
        Graphics Fine Grain Clock Gating: On
        Graphics Medium Grain Clock Gating: On
        Graphics Medium Grain memory Light Sleep: Off
        Graphics Coarse Grain Clock Gating: On
        Graphics Coarse Grain memory Light Sleep: On
        Graphics Coarse Grain Tree Shader Clock Gating: Off
        Graphics Coarse Grain Tree Shader Light Sleep: Off
        Graphics Command Processor Light Sleep: Off
        Graphics Run List Controller Light Sleep: Off
        Graphics 3D Coarse Grain Clock Gating: On
        Graphics 3D Coarse Grain memory Light Sleep: Off
        Memory Controller Light Sleep: Off
        Memory Controller Medium Grain Clock Gating: On
        System Direct Memory Access Light Sleep: Off
        System Direct Memory Access Medium Grain Clock Gating: On
        Bus Interface Medium Grain Clock Gating: On
        Bus Interface Light Sleep: Off
        Unified Video Decoder Medium Grain Clock Gating: Off
        Video Compression Engine Medium Grain Clock Gating: Off
        Host Data Path Light Sleep: On
        Host Data Path Medium Grain Clock Gating: On
        Digital Right Management Medium Grain Clock Gating: Off
        Digital Right Management Light Sleep: Off
        Rom Medium Grain Clock Gating: Off
        Data Fabric Medium Grain Clock Gating: Off
        VCN Medium Grain Clock Gating: Off
        Host Data Path Deep Sleep: Off
        Host Data Path Shutdown: Off
        Interrupt Handler Clock Gating: On
        JPEG Medium Grain Clock Gating: Off
        Repeater Fine Grain Clock Gating: Off
        Perfmon Clock Gating: Off
        Address Translation Hub Medium Grain Clock Gating: On
        Address Translation Hub Light Sleep: On​

[aufkrawall]

It's not like that is a new or unknown issue. It even still is present on Windows afaik.

Though the Windows driver can clock down VRAM despite low vertical vblank timing (e.g. 1440p 165Hz) with the help of VRR. The Linux driver apparently is still missing this feature.

[agd5f]

This is not board dependent, it's monitor dependent. The driver needs to be able to find conditions where they can reclock memory when the display hardware is not actively pulling data from memory (e.g., during a blanking period) to avoid display disruption when the reclock happens. The length of those periods also matters as there is a certain latency for memory reclocking as well. E.g., monitors with very short blanking periods may not be long enough to complete a reclock.

Though the Windows driver can clock down VRAM despite low vertical vblank timing (e.g. 1440p 165Hz) with the help of VRR. The Linux driver apparently is still missing this feature.

They are being enabled on Linux as well. There are two features, FAMS and SubVP. FAMS uses VRR to adjust the blanking period to make enough space for a memory relock. SubVP involves using a special cache to avoid needing to access memory during the reclock period. For more information, you can see more details in Aurobindo's replies on this bug report:

https://gitlab.freedesktop.org/drm/amd/-/issues/2315