https://bugs.freedesktop.org/show_bug.cgi?id=106428
Bug ID: 106428 Summary: reported VDDGFX GPU voltage jumps above set limits in pp_od_clk_voltage when UVD is used for VAAPI/VDPAU Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: tempel.julian@gmail.com
I adjusted my pstates in "/sys/class/drm/card0/device/pp_od_clk_voltage" that the GPU voltage should never be above 900 mV:
(...) 5: 1126Mhz 880 mV 6: 1180Mhz 890 mV 7: 1209Mhz 900 mV
And in normal 3D applications "watch -n 0.5 cat /sys/kernel/debug/dri/0/amdgpu_pm_info" accordingly never reports more than 900 mV for VDDGFX.
But when I play a video in mpv with VAAPI/VDPAU, reported VDDGFX often jumps to 1100 mV, which clearly is undesired behavior. It sticks again to normal 900 mV as soon as I disable hardware decoding.
Now the question is, if the reported voltage is correct (then adjusting pp_od_clk_voltage has a bug) or if the real voltage is just reported wrong (than information in amdgpu_pm_info would be wrong).
Happens with both 4.17rc2 and drm-next-4.18-wip. GPU is RX 560.
https://bugs.freedesktop.org/show_bug.cgi?id=106428
--- Comment #1 from tempel.julian@gmail.com --- I did some more tests and now I'm very sure that the voltage is just reported wrong when using UVD, and not being actually that high. I also jumps to reported 1.1V without any pstate adjustments or overclock, while the ASIC's default maximum voltage is actually 0.986V. Maybe the UVD got its own voltage of 1.1V, and that is sporadically reported instead of the core GPU voltage when UVD is used? Anyway, not really important since it's just a little glitch and not a real problem. :)
https://bugs.freedesktop.org/show_bug.cgi?id=106428
tempel.julian@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTABUG Status|NEW |RESOLVED
--- Comment #2 from tempel.julian@gmail.com --- Closing, since it's harmless and the Windows driver shows the same behavior.
dri-devel@lists.freedesktop.org