[Bug 99967] RX 480 sclk clock speed lowers when under load

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99967

            Bug ID: 99967
           Summary: RX 480 sclk clock speed lowers when under load
           Product: DRI
           Version: unspecified
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: DRM/AMDgpu
          Assignee: dri-devel at lists.freedesktop.org
          Reporter: haagch at frickel.club

Created attachment 129917
  --> https://bugs.freedesktop.org/attachment.cgi?id=129917&action=edit
screenshot with echo manual > power_dpm_force_performance_level

My GPU is the factory overclocked XFX Radeon RX 480 XXX OC, this might have
something to do with it.

I noticed this on agd5d/drm-next-4.12-wip and found similar behavior on 4.10,
4.9 and 4.8.

It's even affected even with echo manual >
/sys/class/drm/card0/device/power_dpm_force_performance_level

I've made a screenshot of radeon-profile on linux 4.8.14 and annotated it.

Steps I took:
echo manual > /sys/class/drm/card0/device/power_dpm_force_performance_level
echo 7 > /sys/class/drm/card0/device/pp_dpm_sclk
then started unigine-heaven, closed it, waited a couple of seconds, started
furmark, closed it, waited a couple of seconds and then ran another echo 7 >
/sys/class/drm/card0/device/pp_dpm_sclk

When the GPU is "relatively" idle (just displaying the desktop with a browser,
etc.) this doesn't happen. I can echo any number in
/sys/class/drm/card0/device/pp_dpm_sclk and it sticks.
But when I start applications that put some stress on the GPU, the sclk clock
lowers - and stays on a lower level even when the load is gone, until another
number is echo'ed into /sys/class/drm/card0/device/pp_dpm_sclk

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170226/2c26ba94/attachment.html>