Nouveau - Jan 2010 - [Discussion] User controls for PowerManagement

With some progress in PowerManagement support (there's a patch nearly done
for
reading the P-tables, written mostly by xexaxo, derived from thunderbirds
nvclock, with 0x40 adjustments from myself) in my opinion it's time to think
about the user aspect of this.
My personal idea for GPU scaling was similar to that of CPU scaling in
appearance eventually. When you look at the cpufreq-applet for Gnome, you see
the choice between every supported CPU speed, and an option for Automatic
scaling. To make an application like this possible nouveau needs to communicate
with users.
I was thinking a procfs or sysfs node for outputting a readable table with
possible modes like:

03: CPU=135MHz,Shdr=135MHz,Mem=135MHz,Vlt=0.8V,Fan=80%;
...

the node name would be something like pm_supported. Another node named
pm_current could output the current mode (for instance 03), and be writable to
set the desired mode. Mode numbers will be the identifier given by
pm_supported, found in the powermode table. A third node would then be required
to set auto scaling on or off (called pm_auto ?). All those nodes could
eventually be placed in a separate subdirectory (pm?)

1. joi pointed out that procfs is deprecated, and I should use sysfs instead.
There are two reasons to use procfs:
- DRM has a pointer to the right DRM subfolder (/proc/drm/<card number>)
which
can be obtained by drm_device.control->proc_root. Ofcourse, if there's
something similar for sysfs available, then there's no problem. Otherwise
procfs simply saves a lot of hassle as long as DRM still promotes procfs to the
device drivers.
- sysfs was designed for "one value per node". The output of the
pm_supported
node would be an entire table. Is this on par with the design of sysfs?
So: procfs or sysfs?

2. It sounds sensible to me to have one scaling algorithm (whatever that may
become... first things first). When you can scale you can have the maximum
performance as soon as you need it... so the aim should be maximum powersaving
at all time, without sacrificing on performance. Agreed, or should there be
several "auto" modes for different situations?

RSpliet

How about taking inspiration from the cpufreq sysfs interface?

There are sysfs objects for drm cards at /sys/class/drm/card<number>.
Mine, for instance, is at /sys/class/drm/card0, which links to
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0.

A simple scaling approach could just look at the time of the last
pushbuffer submission on any non-Xserver channel (adding a flag for
the DDX, or possibly direct rendered desktop applications to specify
on channel creation). If it's more than N milliseconds ago, turn on
power saving, otherwise disable it, possibly with several time
thresholds for several modes. Of course, it shoud not be implemented
literally this way, but rather by using timers appropriately.

Adding dri-devel@ to CC.

On Thu,  7 Jan 2010 22:44:24 +0100
r.spliet at umail.leidenuniv.nl wrote:
> With some progress in PowerManagement support (there's a patch
> nearly done for reading the P-tables, written mostly by xexaxo,
> derived from thunderbirds nvclock, with 0x40 adjustments from
> myself) in my opinion it's time to think about the user aspect of
> this. My personal idea for GPU scaling was similar to that of CPU
> scaling in appearance eventually. When you look at the
> cpufreq-applet for Gnome, you see the choice between every
> supported CPU speed, and an option for Automatic scaling. To make
> an application like this possible nouveau needs to communicate
> with users. I was thinking a procfs or sysfs node for outputting
> a readable table with possible modes like:
> 
> 03: CPU=135MHz,Shdr=135MHz,Mem=135MHz,Vlt=0.8V,Fan=80%;
> ...
> 
> the node name would be something like pm_supported. Another node
> named pm_current could output the current mode (for instance 03),
> and be writable to set the desired mode. Mode numbers will be the
> identifier given by pm_supported, found in the powermode table. A
> third node would then be required to set auto scaling on or off
> (called pm_auto ?). All those nodes could eventually be placed in
> a separate subdirectory (pm?)
> 
> 1. joi pointed out that procfs is deprecated, and I should use
> sysfs instead. There are two reasons to use procfs:
> - DRM has a pointer to the right DRM subfolder (/proc/drm/<card
> number>) which can be obtained by drm_device.control->proc_root.
> number>Ofcourse, if there's
> something similar for sysfs available, then there's no problem.
> Otherwise procfs simply saves a lot of hassle as long as DRM
> still promotes procfs to the device drivers.
> - sysfs was designed for "one value per node". The output of the
> pm_supported node would be an entire table. Is this on par with
> the design of sysfs? So: procfs or sysfs?
> 
> 2. It sounds sensible to me to have one scaling algorithm
> (whatever that may become... first things first). When you can
> scale you can have the maximum performance as soon as you need
> it... so the aim should be maximum powersaving at all time,
> without sacrificing on performance. Agreed, or should there be
> several "auto" modes for different situations?
I recall someone (you?) saying this is only for testing for
now, and the proper user interface can be done later. In
any case, I'd like to suggest discussing it on dri-devel@,
since there are other drivers wanting to expose similar
features.

Hopefully people working on power management interfaces
on intel and radeon can comment on this, like is there
an agreed user interface design yet.

btw. I think max powersaving and no performance loss are
mutually exclusive, since changing power modes is not
free nor instantenous. Or is it? How much of the card
you need to stop to change clocks and volts? Do you
need to sync to vblank to prevent visual glitches?

-- 
Pekka Paalanen
http://www.iki.fi/pq/

> The general opinion appears to be "communicating the least
possible". In
> my opinion this means we shouldn't communicate shader speeds, voltages 
> and fan speeds. Assuming each GPU clock speed is unique (eg. not 2 equal 
> GPU speeds with different memory clock speeds) we could even suffice 
> with just the GPU speed (like scaling_available_frequencies in CPUFreq). 
> This can be done, as said, like cpufreq in sysfs. When GPU is not 
> unique, it's also possible to communicate those separated by a slash 
> ("135/150") or anything. Any other thoughts on this, either from
Nouveau
> or Radeon/Intel developers?
W.r.t showing the current state, I don't have much opinion.  But w.r.t
what can be changed via sysfs, I agree there should just be very few
settings: performance and powersave (where I'd expect powersave to use
an ondemand strategy since it's usually the most efficient power-wise,
tho if needed we could have an extra one for "ondemand").


        Stefan