ATI Kernel Power Management Moves A Bit More

[agd5f]

I can't say I fully understood you, but I take it that there are some technical drawbacks with using rovclock. The point is that if ForceLowPowerMode is just halving the clocks, that's a bit conservative, isn't it? This is, I use rovclock to set the core and memory frequencies to the values reported by fglrx in its lowest power settings, and those are 1/4 and 1/3 their original values, respectively.

The problem is rovclock isn't necessary setting the clocks to what you think it is. It only works if your current clock happens to use a post divider (post_div) of 1. If not, your clocks will be 2, 4, or 8x slower than rovclock reports.

The output frequencies of the plls used for the engine and memory are calculated from the following formula:

output frequency = ((reference clock * fb_div) / ref_div) / post_div;

As you can see the post divider dividers the clock down by 1, 2, 4, or 8, depending on what it's set to. If you don't take it into account, your output frequencies will be wrong. This is why rovclock shows the same clock as before even when the driver has set the engine clock to half of the default value. Also, the engine and memory plls share the same ref_div, so you have to take that into account when setting the clocks.

You can adjust the ForceLowPowerMode driver option to set values lower than 1/2 by changing it in he driver. That's just what a conservative value that I picked as a stop gab until the dynamic kms pm code was finished. The new dynamic pm code in kms does a much better job.

[yotambien]

I see. KMS is the final solution to power saving then. Personally I'm not extremely bothered about the power drain, but the noise from the fan kills me and my concentration--aside from the fact that my partner doesn't appreciate it all too much when I work until late : )

Thanks!

[RussDill]

I'll be interested to see how the DRM ends up communicating with the hwmon components as I'm not sure how this is supposed to be done in-kernel.

[yotambien]

I'm curious about how dynamic power adjustments will be supposed to work. Is this anything like CPU frequency scaling, where changes are applied extremely fast depending on the load? It seems that all these engine and memory reclockings, pci lane adjustments, perhaps future voltage changes and what not are cumbersome operations (no technical reason to think so, but the glitches I see when I adjust the clocks never fail to give me bad vibrations).

Many OpenGL applications do not need to use all the power available from the GPU. Imagine a molecular (or any other kind of) viewer; the user will touch it at discrete intervals, rotate a couple of things, zoom here, move there and so on. As long as the displayed scene is fluid you don't need to go over the top with the GPU. I guess the same thinking applies to composite desktops, where moving a window shouldn't need to put the card on a higher power state, increasing the heat produced and ultimately (gasp!) kicking the fan in.

I'm sure this has been thought through; what behaviour should we expect? Will there be an option to force everything down irrespective of the load?

[darkbasic]

I guess the same thinking applies to composite desktops, where moving a window shouldn't need to put the card on a higher power state

Indeed it doesn't. FPS are fixed in compositing and so only a small amount of power is used and it shouldn't put the gpu on a higher power state.