AMD Has Massive Radeon Patch Set - Power Management!

[d2kx]

Latest kernel didn't fix UVD, booting soft lockup and 3D performance (doesn't get faster/louder in games) for my HD 6870.

[brosis]

Here is some more info with enabled dpm

dpm performance mode:

glxgears --> 616 FPS (with Option SwapbuffersWait off)
$ cat /sys/class/drm/card0/device/power_method 
dpm
$ cat /sys/class/drm/card0/device/power_dpm_state 
performance

dpm battery mode:

glxgears --> 590 FPS (with Option SwapbuffersWait off)
$ cat /sys/class/drm/card0/device/power_method 
dpm
$ cat /sys/class/drm/card0/device/power_dpm_state 
battery

So when dpm is enabled performance is definitly worse.

@agd5f: Do you know what to do? How to increase performance with enabled dpm? I'd like to see same performace with dpm as "default" profile has.

If you need additional info or tests, let me know what is needed.

Glxgears is a light 3D benchmark. So light, many claim it only measures CPU overhead of the driver, so the values are not directly comparable. But increase in glxgears frames on same machine is a good thing.
You may be hitting ondemand powerstate bug, thread is found in this section of forum, but only if you use non-Intel CPU. Intel CPUs use pstate driver, so its completely different and more efficient.
To overcome this, you can play with:
echo 150 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
which will increase CPU polling time, if frequency went up. Default is 1.
the cpu will stay longer in performance state and less frequent polls in power state rob less of CPU raw performance.
but on mobile platform it could be advantageous to keep the value lower or even default, as it will result in faster downclock time and less battery usage. However, if your mobile platform is loaded, more frequent polls will rob its performance and will rob more battery. Think of it as a warden, that can mess too much in manufacturing process, robbing its efficiency; but if there is nothing to do, more frequent checks will result in faster downclock.

echo 35 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
which will make CPU enter full clocking, if the load of more that 35% is detected. Default is 95%, which guarantees sluggish desktop. Personally recommended values 25-40%.

You can then set these variables in /etc/sysfs.conf (create it, if absent), the following way:
devices/system/cpu/cpu0/cpufreq/scaling_governor = ondemand
devices/system/cpu/cpu1/cpufreq/scaling_governor = ondemand
devices/system/cpu/cpufreq/ondemand/sampling_down_factor = 150
devices/system/cpu/cpufreq/ondemand/up_threshold = 35
or load your settings in any autostart script.

If you have mobile platform, governor "conservative" may be more advantageous, as it increases clocks step-wise; "ondemand" will fire top clock when reaching barrier, instead.

[stqn]

Intel CPUs use pstate driver

From what I read [1] [2], this pstate driver only supports sandy bridge and more recent processors.

[1] http://www.phoronix.com/scan.php?pag...tem&px=MTI5Mzc
[2] http://lkml.indiana.edu/hypermail/li...2.1/03328.html

[pali]

Just to note, I have Intel Sandy Bridge processor.

[Veerappan]

Things seem to be working generally well for me on 2 of the 3 cards I've got installed at the moment (my 6850 lacks a computer to install it in):

Cedar (Radeon 5400): Both the graphics chip and UVD reclocking seems be to functioning well... with a dual-monitor setup. Kernel = drm-next from Ubuntu mainline ppa as of 20130702 (firmware from people.fd.o)

A6-3500 (APU): I haven't checked clock speeds using the new debugfs code, but the machine is working well with radeon.dpm=1 radeon.audio=1 and VDPAU/UVD being used. This is using the WIP-3 (or maybe -5) branch.

HD7850: Reclocking seems to be working just fine for the gpu/memory, but anything that has to do with UVD is causing screen corruption the moment that the UVD clock is increased. And then when you stop using UVD, the system hangs. This is using the WIP-3 or WIP-5 branch code. I'll have to retest with some newer stuff later.

[commiethebeastie]

root@un# cat /sys/kernel/debug/dri/0/radeon_pm_info
uvd    vclk: 0 dclk: 0
power level 0    sclk: 10000 mclk: 30000 vddc: 950 vddci: 950
root@un# cat /sys/kernel/debug/dri/0/radeon_pm_info
uvd    vclk: 0 dclk: 0
power level 2    sclk: 79000 mclk: 100000 vddc: 1150 vddci: 1100

All works after last update!!!

[Guest]

Great news!

This is great news! I am glad that AMD has decided that providing a proper open source driver is important. Thank you developers! Now, time to go do some testing....

[archibald]

This is great news! I am glad that AMD has decided that providing a proper open source driver is important. Thank you developers! Now, time to go do some testing....

They decided that it was important a long time ago, the code was written a while ago but it needed to go through their review process.

[Xipeos]

I pushed some updated patches to my drm-next-3.11 branch that should fix the outstanding issue with NI asics and also adds a debugfs interface for tracking the current power state.

radeon_dpm_info shows that the driver indeed switches between power levels under even the slightest load, but the power levels within a state are all the same on my card (RV770).

[Bushido_root]

Just updated to latest drm-next kernel (07/2) (from ubuntu ppa) and everything is working just fine including being able to see radeon_pm_info.

x@Akaigo-Arc:~$ sudo cat /sys/kernel/debug/dri/0/radeon_pm_info
uvd    vclk: 0 dclk: 0
[B]power level 0    sclk: 15700 mclk: 20000 vddc: 900[/B] vddci: 0

As soon as I refreshed I checked the radeon_pm_info again and it changed just fine:

x@Akaigo-Arc:~$ sudo cat /sys/kernel/debug/dri/0/radeon_pm_info
uvd    vclk: 0 dclk: 0
[B]power level 2    sclk: 75000 mclk: 80000 vddc: 1120[/B] vddci: 0