the KMS drm driver is important in two ways :
1. As you say, it provides the "hook" into all 3D engine use, both from the OpenGL driver (the obvious user of the 3D engine) and the X driver (which uses the 3D engine for EXA and Xv as well). It also provides access to display / modesetting info in the same driver, ie it brings all of the required information together in one place.
2. Some of the registers which control GPIO and I2C lines for reading and writing fan/temp controllers and voltage control are also used by modesetting for reading EDID information, so modesetting and power management need to be in the same driver. Unfortunately that needs to be the drm driver, since changing clocks on the fly requires that the driver also block any use of drawing engines, which can only be done in the drm driver (since direct rendered 3D doesn't go through the userspace X driver).
The problem with doing dynamic PM in the userspace driver is that the userspace driver can't block drawing calls from 3D. Bad things can happen if the drawing engine is running at the same time you are reprogramming the clock generator for the engine. Doing dynamic PM in the drm means that drawing operations can be temporarily stopped and the drawing engine quiesced before changing the clock.
Last edited by bridgman; 09-12-2009 at 05:04 PM.
What I have in mind is not dynamic PM from userspace, but static instead. The user would set a request that from now on, he wants maximum performance, as he (or she) is going to play a game. Then, the PM AI would make decisions which would offer best performance, but not the best power saving. And if the user sets request for maximum power saving, the PM AI should make decisions which would offer the least performance, but best power saving. And finally, the user would have the option to set a request for smart power saving, which would then do what you've told - it would make smart decisions which will optimize the ratio between performance and power saving based on some data it collects. This third part would be the most difficult to make as it requires relatively complex AI algorithms, but even first two parts will make a lot of people happy (including me ).
Just to make myself clear: I would like to have the famous aticonfig --set-powerstate feature in the radeon driver: when I issued "aticonfig --set-powerstate=1", I got 3 hours of battery life with awful graphics performance (but good enough to do some simple jobs), and when I issued "aticonfig --set-powerstate=3", I got less than 1 hour of battery life, but I could play nexuiz with high details in high resolution without any problems. This is what I find very useful, and it doesn't look like it requires any complex AI PM algorithms.
What do you think about creating something like /sys/class/gpu/ with engine_clock, memory_clock and voltage? Example:?Code:$ cat /sys/class/gpu/engine_clock management: auto 300000 KHz $ echo maximum > /sys/class/gpu/engine_clock $ cat /sys/class/gpu/engine_clock management: static 680000 KHz $ echo minimum > /sys/class/gpu/engine_clock $ cat /sys/class/gpu/engine_clock management: static 110000 KHz $ echo 50000 > /sys/class/gpu/engine_clock $ cat /sys/class/gpu/engine_clock management: static 110000 KHz $ echo 250000 > /sys/class/gpu/engine_clock $ cat /sys/class/gpu/engine_clock management: static 250000 KHz $ echo auto > /sys/class/gpu/engine_clock $ cat /sys/class/gpu/engine_clock management: auto 320000 KHz