Bug 52345 - KMS Power Management have no effect
Summary: KMS Power Management have no effect
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: XOrg git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
Depends on:
Reported: 2012-07-21 16:30 UTC by Amadeus
Modified: 2019-11-19 08:28 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

dmesg with drm.debug=6 (114.55 KB, text/plain)
2012-07-22 22:05 UTC, Amadeus
no flags Details
xorg log with drm.debug=6 (48.33 KB, text/x-log)
2012-07-22 22:06 UTC, Amadeus
no flags Details

Description Amadeus 2012-07-21 16:30:56 UTC

OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD SUMO2
OpenGL version string: 2.1 Mesa 8.0.3
OpenGL shading language version string: 1.20

AMD A4-3400 APU with Radeon(tm) HD Graphics
Fedora 17 64bit
Linux amd 3.4.5-2.fc17.x86_64 #1 SMP Mon Jul 16 20:52:08 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

According to


echo profile > /sys/class/drm/card0/device/power_method
echo high >  /sys/class/drm/card0/device/power_profile

put the GPU in high performance mode and

echo profile > /sys/class/drm/card0/device/power_method
echo low >  /sys/class/drm/card0/device/power_profile

in low performance mode.

glxgears gives 60 FPS in both cases, which leads me to beleive that power management does work.
Comment 1 Matt Turner 2012-07-21 16:43:06 UTC
(In reply to comment #0)
> glxgears gives 60 FPS in both cases, which leads me to beleive that power
> management does work.

Does your glxgears print this?

> Running synchronized to the vertical refresh.  The framerate should be
> approximately the same as the monitor refresh rate.
Comment 2 Amadeus 2012-07-21 16:54:21 UTC
Yes it does.
Comment 3 Matt Turner 2012-07-21 17:39:50 UTC
(In reply to comment #2)
> Yes it does.

So... vsync is making glxgears run at 60 FPS no matter what..
Comment 4 Amadeus 2012-07-21 19:13:08 UTC
I see.

If I do

glxgears -geometry 1600x1024+0+0

then I get 40 FPS in both cases instead of 60fps. It takes ~3% CPU.

If I start a 3D game in Wine, it feels the same (very slow).
Comment 5 Sven Arvidsson 2012-07-22 20:26:38 UTC
There should be a way to check the engine clock to see if it's running at full speed:

# cat /sys/kernel/debug/dri/0/radeon_pm_info

You'll need debugfs mounted first.

There was some talk on Phoronix about another APU running with very low clocks, could be something similar here perhaps?
Comment 6 Amadeus 2012-07-22 21:13:23 UTC
Very interesting thread. It seams to be the same problem I have.

Regardless of the power settings I never get a higher engine clock than ~75kHz.

[root@amd ~]# cat /sys/kernel/debug/dri/0/radeon_pm_info
default engine clock: 200000 kHz
current engine clock: 73950 kHz
default memory clock: 533000 kHz
Comment 7 Grigori Goronzy 2012-07-22 21:46:19 UTC
You might have the same problem as me, see http://lists.freedesktop.org/archives/dri-devel/2012-July/025159.html

First, the engine clock readout seems to be completely bogus on APUs, disregard it.

Second, the power management functions limit the maximum engine clock to the default engine clock. On most standalone GPUs, the default clock seems to be equivalent to the maximum p-state's clock, so that is fine. Not so much on the APUs!

I'm interested in what the AtomBIOS PowerPlay table looks like on your device. Can you boot with drm.debug=6 in the kernel command line and tell me what it says in the log?
Comment 8 Amadeus 2012-07-22 22:05:25 UTC
Created attachment 64512 [details]
dmesg with drm.debug=6
Comment 9 Amadeus 2012-07-22 22:06:18 UTC
Created attachment 64513 [details]
xorg log with drm.debug=6
Comment 10 Amadeus 2012-07-22 22:08:06 UTC
Very interesting!

What can you gather from the attached logs where I have booted with drm.debug=6 ?
Comment 11 Grigori Goronzy 2012-07-22 22:18:02 UTC
Not much, actually, the table looks very similar to AMD PALM / Radeon 6320 on my netbook. The GPU part of Zacate and Llano is probably very similar, except for clocks and number of shader cores. And that means you suffer from the same issues.

IMHO the sanity check that limits the clock should be removed altogether, as it doesn't make much sense. If you fancy recompiling the kernel, just comment this out from radeon_pm.c:

189                 if (sclk > rdev->pm.default_sclk)
190                         sclk = rdev->pm.default_sclk;

This should get clock switching going.
Comment 12 Martin Peres 2019-11-19 08:28:11 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/284.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.