More Radeon Power Management Improvements

[piete]

If I wanted low profile to be used by default on boot, what would be the preferred location to set it?

In Arch Linux I did the following:

http://wiki.archlinux.org/index.php/Ati#Early_KMS_start

and added line

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

in file

/etc/rc.local

I don't know if the first step has any effect other than getting the right resolution earlier, but it's still nicer that way. And I use the kernel from

http://gtklocker.tiven.org/radeon-repo/x86_64/

[agd5f]

Oh, thank you. This key information hasn't spread far enough, AFAICS.

FYI, some power consumptions tests (KMS, Xorg with radeon driver from yesterdays git snapshot, one head enabled, no relevant CPU load):

default: ~144W
auto: 127..132W
high: 137..141W
mid: 128..131W
low: 100..103W (pretty close to normal idle state with fglrx)
low (with both heads enabled): 118..121W (also close to fglrx w/ multihead)

My naive conclusion is that "auto" mode is not aggressive enough or doesn't get enough information to control efficiently. But I am sure you know better.

As noted in the page I linked, "auto" only lowers the clock when on battery and when the screen is blanked. To dynamically raise and lower the clocks, you can enable the dynpm method, but you will likely experience problems until that is sorted out better.

[tormod]

default: ~144W
auto: 127..132W
high: 137..141W
mid: 128..131W
low: 100..103W (pretty close to normal idle state with fglrx)
low (with both heads enabled): 118..121W (also close to fglrx w/ multihead)

My naive conclusion is that "auto" mode is not aggressive enough or doesn't get enough information to control efficiently. But I am sure you know better.

My understanding is that auto switches only between high and mid (as long as the screen is on at least) so when in your case the auto rate is the same as the mid rate that sounds like as good as it gets. It will not switch to low because low is not working so well for everybody ATM.

[dmfr]

My understanding is that auto switches only between high and mid (as long as the screen is on at least) so when in your case the auto rate is the same as the mid rate that sounds like as good as it gets. It will not switch to low because low is not working so well for everybody ATM.

Not sure auto even switches anything when AC is on.
Here with 2.6.35rc4 + drm-radeon-testing, GPU is running at full blast as long as power is plugged.

On the other hand, "dynpm" was working really great with 2.6.34 mainline and was very efficient but now there's noticeable flickering / micro-freezes on every state change, maybe due to additional memory reclock and/or voltage tweaking...

[agd5f]

"auto" only changes the clocks when switching from battery to ac and vice versa (mid <-> high) and when the monitors blank (low).

[dmfr]

"auto" only changes the clocks when switching from battery to ac and vice versa (mid <-> high) and when the monitors blank (low).

OK for the battery/ac switch. However, closing the lid doesn't seem to change the clocks (checking through ssh).

Besides, "dynpm" still introduces lots of flicker and micro-freezes, but doesn't always bring the clocks up when needed (HD playback, thus jerky). glxgears alone seems to trigger reclocking.
Is dynpm still regarded as experimental by now ?

[agd5f]

OK for the battery/ac switch. However, closing the lid doesn't seem to change the clocks (checking through ssh).

It will if your desktop environment blanks the screen when you close the lid. The dpms reclocking happens when all the monitors are in the dpms off state. It also depends on what power states are specified in your bios. Some cards only have one or two states for example.

Besides, "dynpm" still introduces lots of flicker and micro-freezes, but doesn't always bring the clocks up when needed (HD playback, thus jerky). glxgears alone seems to trigger reclocking.
Is dynpm still regarded as experimental by now ?

The engines have to be idle and the CPU cannot be accessing vram when changing the clocks. To avoid flicker, you need to change the clocks during the vblank period (this is nearly impossible with dualhead as the vblanks may never line up). Changing the clocks requires a certain amount of time depending on how long it takes the plls to lock. As such, if the reclock gets scheduled too close to the end or outside the vblank period, you need to reschedule it. It's even harder with two clocks (engine and memory). They should be scheduled separately to make sure they can be done in the vblank period; right now they are not.

The pm code has to take the cp lock, wait for the engines to be idle, turn off the crtc mem requests, and unmap all vram mmaps when it's going to reclock. When this happens, new command buffers cannot be sent to the GPU; that's what causes the stalls. The flickering is caused by overrunning the vblank period during the reclock.

Deciding when to dynamically reclock is also tough. Right now we just look at the number of queued command buffers, but ideally, you'd have some intelligence as to what operations are happening and how much bandwidth you'd need from memory and the engine to complete the requested command buffer smoothly. If you miss the vblank window, you need to reschedule the reclock which means the clocks may be running slower than you'd ideally want.

Unfortunately, it's very complex to get right.

[dmfr]

Thanks a lot for the detailed explanation, though a bit off my knowledge.

That may explain why dynpm was smooth when the engine clock alone was tweaked.
For now i'll stick to profile=auto.

[RealNC]

Uhm, since you're AMD/ATI, don't you have info about how fglrx solves this?

[agd5f]

Yes, piles and piles of code that touches just about everything.