Quote Originally Posted by yotambien View Post
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.