[Discussion] User controls for PowerManagement

[Discussion] User controls for PowerManagement

[r.spliet-+WoPDYjVzZevezkx17PYy4RWq/SkRNHw]

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

Re: [Discussion] User controls for PowerManagement

[Luca Barbieri]

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.

Re: [Discussion] User controls for PowerManagement

[Pekka Paalanen]

Adding dri-devel@ to CC.

On Thu,  7 Jan 2010 22:44:24 +0100
r.spliet-+WoPDYjVzZevezkx17PYy4RWq/SkRNHw@public.gmane.org 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/

Re: [Discussion] User controls for PowerManagement

[Alexey Dobriyan]

On Sun, Jan 10, 2010 at 12:33:40PM +0200, Pekka Paalanen wrote:
> Adding dri-devel@ to CC.
> 
> On Thu,  7 Jan 2010 22:44:24 +0100
> r.spliet-+WoPDYjVzZevezkx17PYy4RWq/SkRNHw@public.gmane.org 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%;

Ick!

> > 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.

/proc is not deprecated per se, you simply shouldn't expose everything
you know to userspace, because it will be impossible to remove later.

In fact you can expose nothing, just implement gpu-ondemand and
gpu-performance and that would be it.

Re: [Discussion] User controls for PowerManagement

[Pekka Paalanen]

On Sun, 10 Jan 2010 12:43:02 +0200
Alexey Dobriyan <adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> > On Thu,  7 Jan 2010 22:44:24 +0100
> > r.spliet-+WoPDYjVzZevezkx17PYy4RWq/SkRNHw@public.gmane.org wrote:
> > 
> > > 1. joi pointed out that procfs is deprecated, and I should use
> > > sysfs instead.
> 
> /proc is not deprecated per se, you simply shouldn't expose
> everything you know to userspace, because it will be impossible
> to remove later.

I think adding "random crap" to procfs is frowned upon nowadays,
that's probably what he meant. Attributes should be in sysfs.
What to expose is another question, you are right.

If the interface is just temporary, it should probably go into
debugfs. That way one can have the code in the kernel proper,
not fear about freezing it, and prevent people from finding it
by accident. And it should be guarded by an "EXPERIMENTAL, DANGEROUS"
Kconfig option in any case.

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

Re: [Nouveau] [Discussion] User controls for PowerManagement

[Roy Spliet]

On 10-01-10 12:15, Pekka Paalanen wrote:
> On Sun, 10 Jan 2010 12:43:02 +0200
> Alexey Dobriyan<adobriyan@gmail.com>  wrote:
>
>    
>>> On Thu,  7 Jan 2010 22:44:24 +0100
>>> r.spliet@umail.leidenuniv.nl wrote:
>>>
>>>        
>>>> 1. joi pointed out that procfs is deprecated, and I should use
>>>> sysfs instead.
>>>>          
>> /proc is not deprecated per se, you simply shouldn't expose
>> everything you know to userspace, because it will be impossible
>> to remove later.
>>      
> I think adding "random crap" to procfs is frowned upon nowadays,
> that's probably what he meant. Attributes should be in sysfs.
> What to expose is another question, you are right.
>
> If the interface is just temporary, it should probably go into
> debugfs. That way one can have the code in the kernel proper,
> not fear about freezing it, and prevent people from finding it
> by accident. And it should be guarded by an "EXPERIMENTAL, DANGEROUS"
> Kconfig option in any case.
>
>    
I'm thinking long term right now for this discussion, probably for the 
short run only some debugfs interfaces are needed. For now I'll do some 
work in Debugfs.

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?

On Sun, Jan 10, 2010 at 12:33:40PM +0200, Pekka Paalanen wrote:
"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?"

I can't tell for now, the main reason I started this "discussion" is to 
work towards a unified way of scaling (not just for nouveau, but also 
radeon and intel), so that we can hook nouveau up as soon as everything 
is figured out, without having to wait for these design choices. As for 
the clock changing. I personally expect switching modes wouldn't cost 
too much, and more important, It shouldn't occur a lot. You can never 
tell with 100% accuracy when the power is needed (I tried predicting the 
future, but I didn't get much further than predicting my dinner), so 
trying to change the clock frequency lots of times in one second will 
help nobody. What I meant with that paragraph however is that I don't 
think it's useful to design several algorithms (in nouveau) for 
different situations. It's either manually choosing a clock (as user) or 
let "some" algorithm choose based on the load or the size of the working 
queue (... and the temperature of the card). Agreed? Was this what you 
meant with GPU-ondemand (automated scaling) and GPU-performance (fixed 
user-defined speed)?


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
--

Re: [Discussion] User controls for PowerManagement

[Roy Spliet]

On 10-01-10 12:15, Pekka Paalanen wrote:
> On Sun, 10 Jan 2010 12:43:02 +0200
> Alexey Dobriyan<adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>  wrote:
>
>
>>> On Thu,  7 Jan 2010 22:44:24 +0100
>>> r.spliet-+WoPDYjVzZevezkx17PYy4RWq/SkRNHw@public.gmane.org wrote:
>>>
>>>
>>>> 1. joi pointed out that procfs is deprecated, and I should use
>>>> sysfs instead.
>>>>
>> /proc is not deprecated per se, you simply shouldn't expose
>> everything you know to userspace, because it will be impossible
>> to remove later.
>>
> I think adding "random crap" to procfs is frowned upon nowadays,
> that's probably what he meant. Attributes should be in sysfs.
> What to expose is another question, you are right.
>
> If the interface is just temporary, it should probably go into
> debugfs. That way one can have the code in the kernel proper,
> not fear about freezing it, and prevent people from finding it
> by accident. And it should be guarded by an "EXPERIMENTAL, DANGEROUS"
> Kconfig option in any case.
>
>
I'm thinking long term right now for this discussion, probably for the 
short run only some debugfs interfaces are needed. For now I'll do some 
work in Debugfs.

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?

On Sun, Jan 10, 2010 at 12:33:40PM +0200, Pekka Paalanen wrote:
 > "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?"

I can't tell for now, the main reason I started this "discussion" is to 
work towards a unified way of scaling (not just for nouveau, but also 
radeon and intel), so that we can hook nouveau up as soon as everything 
is figured out, without having to wait for these design choices. As for 
the clock changing. I personally expect switching modes wouldn't cost 
too much, and more important, It shouldn't occur a lot. You can never 
tell with 100% accuracy when the power is needed (I tried predicting the 
future, but I didn't get much further than predicting my dinner), so 
trying to change the clock frequency lots of times in one second will 
help nobody. What I meant with that paragraph however is that I don't 
think it's useful to design several algorithms (in nouveau) for 
different situations. It's either manually choosing a clock (as user) or 
let "some" algorithm choose based on the load or the size of the working 
queue (... and the temperature of the card). Agreed? Was this what you 
meant with GPU-ondemand (automated scaling) and GPU-performance (fixed 
user-defined speed)?

RSpliet

Re: [Discussion] User controls for PowerManagement

[Stefan Monnier]

> 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

Re: [Discussion] User controls for PowerManagement

[Matthew Garrett]

The real question is what you want to be controlling. The two factors 
that we can actually influence are voltage and frequency - and on some 
cards we're limited to frequency. Everything else is then constrained by 
that choice. So the only thing that it makes sense to expose to 
userspace here is the frequency. As others have suggested, policy is 
probably best described in terms of either performance (fixed maximum 
frequency) or powersave (ondemand frequency shifting).

That's not to say that there aren't other constraints people may want to 
impose, but they're orthogonal. A user may want to stop their GPU from 
running at more than a certain temperature. That can be achieved by 
leaving this interface as is, but hooking it into the kernel thermal 
zone code. The user can then set a temperature limit and the kernel will 
automatically slow the chip down whenever it gets near that temperature. 
Since this is effectively a proxy for fan speed, that also gets catered 
for.

So I think a general policy knob (like scaling_cur_governor in cpufreq) 
ought to be sufficient here, possibly along with an indication of the 
instantaneous frequency because some people seem to like that kind of 
thing. Anything else sounds like overengineering.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org