RandR 1.3 additions?
jbarnes at virtuousgeek.org
Tue Jul 17 08:05:30 PDT 2007
> > I think we could save lot power by downclocking gpu & ram anytimes
> > there is not much activity on screen this why i have though about
> > damage extension to provide information on how much the screen
> > change. If there is only the cursor or slow refresh things you
> > don't want to have gpu going at 400Mhz, 200MHz should be more than
> > enough. The things is that i would like to avoid using a daemon
> > which query damage extension in order to set gpu clock. I guess it
> > would require to add some new extension which report to a daemon
> > anytime there is a major change in graphics activity, we might also
> > want to avoid downclocking and upclocking the gpu every second.
> > Anyway i guess for a first step providing infrastructure to change
> > GPU clock and VRAM clock (or any other power saving things the card
> > can offer) would be the first step. Then we could think to add more
> > cleverness either by adding new things to damage or by adding a new
> > extension which can take advantage of damage information. Btw i
> > don't know much about damage extension so maybe i am wrong when
> > thinking that it could provide usefull information on how much
> > graphics activity we got.
> This is starting to move into the chips control domain. Many newer
> GPUs already scale their clocks, voltage, etc. or toggle special
> power modes automatically without user space intervention.
Right, the chips will do much of this automatically, and in many other
cases the driver should be automatically taking advantage of power
saving features if possible (disabling parts of the chip, going into
appropriate PCI Dn states, etc.). But I see Jerome's point: some
features just have a performance slider, e.g. clock speed. Allowing
clients to tweak that value might be a good idea since inferring
performance requirements from the client load isn't really possible
(i.e. the user may *want* slow performance to save power, even though
the GPU is working flat out).
It would help if we could come up with a list of such tunables and
figure out which ones should be handled automatically vs. exported to
More information about the xorg