[PATCH] radeon: Make PM info available to all, not just debug users

[Jerome Glisse]

On Mon, Jun 4, 2012 at 2:18 PM, Jerome Glisse <j.glisse at gmail.com> wrote:
> On Mon, Jun 4, 2012 at 1:54 PM, Martin Peres <martin.peres at free.fr> wrote:
>> Answers inlined.
>>
>> Le 04/06/2012 19:19, Jerome Glisse a écrit :
>>
>>>
>>> My point is that there is no way for power management to find an API
>>> that fits all GPU. If i were to do it now, i would have one ioctl
>>> version for r3xx, one for r5xx, one for r6xx/r7xx, one for r8xx, one
>>> for r9xx, ... yes there would be some common fields accross them.
>>
>> Right, but would the userspace care for so much information?
>
> I think it might, think about newer GPU where we could let user do a
> custom profile to restrict the GPU into some range of power
> consumption/temperature/fan speed .... What kind of information i
> would want to expose would be highly GPU family related.
>
>> As a user, I would rather want a slider that would range from
>> agressive power management to full performance.
>> Then, it would be cool for tweakers to have a way to set everything
>> they want. But if the interface cannot be common, that's not that
>> important.
>>
>>> That being said i think one file might fit all GPU is the power
>>> profile one accepting something : performance, normal, energy I am
>>> pretty sure all GPU have and will continue to have&  use power
>>> profile.
>>
>> We agree on that.
>>
>>> But when it comes to reporting information and making custom
>>> profile i would use an ioctl because on that side i see way too many
>>> difference accross gpu from same company but from different
>>> generation, so i wouldn't even want to try to bolt something accross
>>> GPU from different company. Also think to IGP, where memory clock
>>> doesn't make sense and where even voltage might not make sense as the
>>> GPU might be so entangle with the CPU that it would be linked with CPU
>>> powerstate.
>>
>> Fair-enough. I'll need to study AMD hw more then. It is perfectly doable
>> and straight forward on nvidia, even on IGP.
>>
>>>
>>> Also when i was refering to shutting down things, i think for instance
>>> that some custom profile/powersaving might want to disable shader
>>> engine (way more radical than clock gatting). Also think to case of
>>> single card multi GPU, people might want to have both GPU working with
>>> same profile like when in performance mode, or power down one of the
>>> GPU.
>>
>> Exactly my point, but we seem to disagree on who should do this.
>>
>> I guess my point makes sense only when put this way, the driver
>> is responsible for lowering power consumption whenever it has the
>> opportunity to do so (and that means being really opportunistic).
>>
>> Your point makes sense when thinking the kernel should be doing
>> as little as possible.
>
> No, my point make sense for the case where the kernel is doing a lot
> of thing too. We want agressive kernel power management where
> downclock the GPU even if the user is not asking for it.
>
> Still user might want to create custom profile to limit the range of
> what the kernel can do, like for instance force the kernel to never go
> above some clock/voltage, or below some level. The way i see user
> input is more as guideline to the kernel side rather than as strict
> rules.
>
>> To be honest, I'm working towards really opportunistic
>> reclocking using a general-purpose engine on newer GPUs.
>> This would save a lot of energy on the typical browsing scenario.
>
> We also want to go that way on AMD GPU.
>
>> This is why I'm concerned about exposing too much to the userspace,
>> the current state is so volatile that it doesn't even make sense to mention
>> it in same cases.
>
> User might want to know in which range is the GPU frequency, or limit
> the power usage of its GPU, ...
>
>>>
>>> So as i said in previous mail, my perfect solution is ioctl and let
>>> the driver dev do some kind of plugin for gnome-control-center
>>> (similar to what compiz effect plugin was from design pov) where
>>> driver dev can put a gui that reflect best what is available for each
>>> specific case.
>>
>> Yeah, I get your point as a kernel dev, but I pitty the userspace dev that
>> will need to figure out how to use all these ioctls and configuration
>> options.
>
> My point there is that we do the userspace bit, i would like to come
> up with some kind of module that thing like gnome-control-center can
> use or kde equivalent or anyother desktop environment.
>
>> What about having a simple common API (sysfs, preferably) that allow to
>> change
>> the performance profile and leave the rest to drivers?
>>
>> Would that be acceptable?
>> Cheers,
>> Martin
>
> I think a powerprofile file is acceptable, i am not sure if it should
> be discrete like performance/normal/battery/low or something more like
> a scale 0-10 with 10 being full power and 0 being the lowest power the
> GPU can do. I am more incline to the word solution for which we can
> gave clear definition like :
>
> low : power mode is only able to meet the need of one light graphical
> application (like video playback) expect some sluggishness in
> rendering when switching between application.
> battery: save as much power and reduce GPU speed while still allowing
> fast desktop reactivity
> ...
>
> Cheers,
> Jerome

Maybe i should stress that i believe that driver can't efficiently do
quick reclocking when it comes to GPU. My understanding is that newer
GPU wether AMD or NVidia use some kind of controller that use a small
firmware to control power adjustment base on GPU usage on the flight.
Those firmware use driver input to determine range of operation
(max/min voltage/frequency/fan speed/...) What i want to allow is for
userspace to customize and know about those range of operations. A
power profile is just a set of range (a range might be a single value
on some less adjustable GPU) for each of the adjustable parameters.

Cheers,
Jerome