# Radeon (in-kernel) low power settings -- what bad can happen

## mbar

This page says:

http://www.x.org/wiki/radeonBuildHowTo#Changepower-managementmethod

 *Quote:*   

> The "profile" method exposes 4 profiles that can be selected from: 1. "default" 2. "auto" 3. "low" 4. "high" In the meantime there has been a 5th "mid" profile introduced (see [2]).
> 
> How to get/select the PM profile method?
> 
> cat /sys/class/drm/card0/device/power_profile
> ...

 

Does anybody know what bad things can happen?

I'm asking because I have a Dell laptop with Radeon HD5xxx and under 2.6.37-rc8 kernel there are some specks flying on my display.

----------

## dE_logics

Ok, ATI still has issues with newer cards.

----------

## Logicien

Hi, is your display good when you do not use dynmic GPU cloking and use the default profile?

In my modest opinion, scaling the CPU and/or the GPU with multimedia have to be done with advise. I was using Conservative scaling policy for the CPU until I had trouble to view Flash sequences on Youtube and until Compiz stop to work by cause of it's libdecor library segfault. Ondemand scaling policy could have been better, but have not yet been tested by me.

Since that, I use Performance scaling policy and it is better. Youtube sequences work well and Compiz is stable. So, I am not gone start to use dynamic GPU clocking until I will be ready to make tests or stop consumate multimedia. I sense that the troubles I had arrived when the processor change it's speed. This is possible because the graphic memory was share with the system one on most of the laptops I had.

I think dynamic GPU clocking can cause problems if the graphic card is heavily sollicitated during the GPU change it's speed. Low GPU clock could private the graphic card form the power it need.

----------

## Sadako

Logicien; the "performance" governor just runs at the highest available frequency, so you may as well just disabled frequency scaling altogether if using that...

CPU frequency scaling is quite stable on modern hardware these days, and yes, ondemand would be a much better choice on such hardware, conservative was for older hardware which couldn't change the frequency as fast as ondemand requires.

To the OP; as Logicien asked, do you only see these artifacts with GPU scaling enabled or set to the "low" profile?

Unfortunatly with the open radeon drivers, I don;t think the support for HD5000 series and above isn't quite "there yet"...

edit; reading up from the link the OP provided, I came across this; *Quote:*   

> * "auto" selects between "mid" and "high" power states based on the whether the system is on battery power or not. The "low" power state are selected when the monitors are in the dpms off state. 
> 
> * "low" forces the gpu to be in the low power state all the time. Note that "low" can cause display problems on some laptops; this is why auto does not use "low" when displays are active.

 So low isn't really intended for use if the GPU is active or connected to a display at all, auto seems like the best choice if battery life is your goal.

----------

## Logicien

I just come to change Performance to Ondemand policy scaling and Compiz stop working not long after with those kernel messages

```
compiz[24116]: segfault at 7fb1efb4d480 ip 00007fb1efb4d480 sp 00007fff60ff0c58 error 14 in libworkarounds.so[7fb1ef99d000+200000]

compiz[24246]: segfault at 99 ip 00007fd857b3e249 sp 00007fff78de12c0 error 4 in libc-2.12.2.so[7fd857ac8000+153000]
```

So the reliability of frequency scaling is one thing, but the fact that CPUs and/or GPUs change speed on the fly can make the whole system unstable. Me, I notice instablilty only with multimedia. My Radeon RS780MN use 256 mo of share memory of the system. So, only when temperature can become critical I will be force to use frequency scaling. I use ArchLinux and Debian.

----------

## Sadako

 *Logicien wrote:*   

> I just come to change Performance to Ondemand policy scaling and Compiz stop working not long after with those kernel messages
> 
> ```
> compiz[24116]: segfault at 7fb1efb4d480 ip 00007fb1efb4d480 sp 00007fff60ff0c58 error 14 in libworkarounds.so[7fb1ef99d000+200000]
> 
> ...

 That's somewhat abnormal, usually if CPU freq scaling causes issues it's major kernel space problems...

A wild guess, but I'd say your CPU is switching to too low a voltage at lower frequencies, which would make this a hardware or at the very least a bios/firmware problem.

If interested in testing this out, I'd recommend setting the userspace governer, then running gimps or maybe even just memtester at each CPU freq available to you.

----------

## Logicien

My memory have been tested with Memtest before, no error have been found. About Compiz segfault, I miss that the Radeon module tell before that that the GPU lockup and display a call trace.

What I am testing now, is the Powersave policy scaling on AC to see if Compiz crash because of CPU frequency changes and/or because of missing highest CPU frequency. I use powernow-k8 frequency module for AMD Athlon(tm) Processor TF-20. I have only to frequencys, 800 MHz and 1600 MHz. Laptop-mode and Cpufreqd or else powersaving daemon are not running.

----------

## Logicien

It really look like my cheap laptop, eMachines E627 with AMD/ATI RS780MN chipset, using Radeon Xorg driver for 3D acceleration with Compiz-Fusion, accept both Performance and Powersave governors or any fixed frequency. Changing frequency on the fly cause trouble here to the graphic card who lock on heavy load and make Compiz make segfaults. So mbar, you have my experience has reference not for GPU but CPU frequency scaling.

----------

## mbar

Yep, thanks for all replays.

Sadly I had to switch back to fglrx driver, I got scared by that screen corruption -- I'll try "radeon" again in a few months.

----------

## Logicien

mbar,

if you read the

```
man radeon
```

you will see

```
Option "ClockGating" "boolean"

              Enable  dynamic  clock  gating.  This can help reduce heat and increase battery life by reducing power usage.  Some users report reduced 3D performance with this enabled.  The default is off.
```

So it is a good reason to not set dynamic clock on kernel side and Xorg user side for performances. It is a good reason only if you need to reduce video card heat and want to economise power.

About the Ondemand governor, I try to fix the Compiz crashes by setting a shorter time between each kernel check for cpu usage change and by decreasing the percentage of the CPU load to switch to the maximum frequency. It look promissing, no Compiz crash with Ondemand govervor since:

```
echo 2000000 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate

echo 40             > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
```

----------

## mbar

Sadly, ClockGating doesn't work with my mobile Radeon. Verified by monitoryng GPU temperature.

Maybe in some future driver version.

----------

## Logicien

You have three options that can help to reduce the card heat:

```
Option "ClockGating" "on"

Option "DynamicPM" "on"

Option "ForceLowPowerMode" "on"
```

You can check if the Xorg radeon driver accept them or not by

```
grep -i  -e ClockGating -e  DynamicPM -e  ForceLowPowerMode /var/log/Xorg.0.log
```

If you see the radeon driver say "is not used", it's because the option is rejected.

To reduce heat of the card, I would try the kernel radeon module option dynclks who can be activate via the sysfs as you start the post or via /etc/modprobe.d/modprobe.conf:

```
options radeon dynclks=1 modeset=1
```

This method can be usefull if you include modprobe.conf with the radeon module in an initrd or load the module from the realroot filesystem. There's a third method, via kernel boot parameter:

```
radeon.dynclks=1 radeon.modeset=1
```

This is the earliest way to use dynamic clock. This is the method if the radeon drm support is compile in the kernel, but I think it can work to if it is compile in module. I added the modeset option with.

----------

## mbar

 *Logicien wrote:*   

> There's a third method, via kernel boot parameter:
> 
> ```
> radeon.dynclks=1 radeon.modeset=1
> ```
> ...

 

And this is exactly what I tried, it worked to some extent (but the temperature was still somewhat higher than in fglrx) but under .37-rc8 there was minimal, almost invisible screen corruption -- but it scared me and I went back to fglrx.

----------

## Logicien

If your back to fglrx, this can be useless from the "man radeon":

```
Option "DisplayPriority" "string"

              Used to prevent flickering or tearing problem caused by display buffer underflow.

              AUTO   -- Driver calculated (default).

              BIOS   -- Remain unchanged from BIOS setting.

                        Use this if the calculation is not correct

                        for your card.

              HIGH   -- Force to the highest priority.

                        Use this if you have problem with above options.

                        This may affect performance slightly.

              The default value is AUTO.
```

and

```
Option "EXAVSync" "boolean"

              This option attempts to avoid tearing by stalling the engine until the display controller has passed the destination region.  It reduces tearing at the cost of performance and

              has been known to cause instability on some chips.  The default is off
```

----------

## mbar

 *mbar wrote:*   

> I'm asking because I have a Dell laptop with Radeon HD5xxx and under 2.6.37-rc8 kernel there are some specks flying on my display.

 

I'm using zen kernel version .36-zen3+ now and the specks are gone. Unfortunately, they are present under .37-gentoo  :Rolling Eyes: 

----------

## mbar

 *mbar wrote:*   

> I'm using zen kernel version .36-zen3+ now and the specks are gone. 

 

...and those fokkers are back in .37-zen0+, wtf  :Rolling Eyes: 

----------

