More ATI Radeon KMS Power Management Fun

[agd5f]

Well, you mean having a non-sysfs power management interface like all the other sub-systems. So you would have a generalized DRM interface which generates proper sysfs entries on Linux and whatever are the proper interfaces on other kernels (window,MacOS,*BSD...).
I don't know, but does the DRM power management driver interface allow proper use of pm.h? Personnally, I doubt it. And imagining code that will cleanly fit all the other kernels power management interface at the same time... sorry I don't buy it: it will be kludgy naughty code. I don't even think it will fit the "quality requiered" to get into *BSD kernels.

For me it's masochistic and a dangerous path.

Let me add a layer on top of it: a generalized instrumentation framework for performance measurements that will fit the native instrumentation interfaces of all kernels?

All that kernel abstraction stuff seems quite unreasonable, but I think you got my point.

Right now there is no exposed interface to the radeon pm stuff. It's all handled transparently within the driver. Eventually we may expose knobs which will require an interface, but as of yet, we don't.

pm.h basically defines the interface for suspend/hibernate/resume variants which are already hooked by the drm. There's nothing in there to handle arbitrary device power states. I'm not even sure how you could in a generic manner. Consider power states for a NIC vs a GPU vs. mouse, etc. Some asics may have hw controlled clock gating. Others might manually adjust clocks or turn off power to certain blocks. There are also device specific requirements like making sure there is enough memory bandwidth before downclocking vram or not putting a PHY in a low power state while a NIC is transmitting.

What interface would you propose that could handle arbitrary device power states with all sorts of device specific requirements? What common kernel pm interface would you recommend? I don't see one.

[sylware]

Right now there is no exposed interface to the radeon pm stuff. It's all handled transparently within the driver. Eventually we may expose knobs which will require an interface, but as of yet, we don't.

pm.h basically defines the interface for suspend/hibernate/resume variants which are already hooked by the drm. There's nothing in there to handle arbitrary device power states. I'm not even sure how you could in a generic manner. Consider power states for a NIC vs a GPU vs. mouse, etc. Some asics may have hw controlled clock gating. Others might manually adjust clocks or turn off power to certain blocks. There are also device specific requirements like making sure there is enough memory bandwidth before downclocking vram or not putting a PHY in a low power state while a NIC is transmitting.

What interface would you propose that could handle arbitrary device power states with all sorts of device specific requirements? What common kernel pm interface would you recommend? I don't see one.

pm.h defines calbacks for the Linux major power management state machine. It would have to be implemented by the driver itself, DRM or not. And, we agree a generalized interface would be insane, that was my point.
But... then you tell me the minor power management state machines are coded internally in the driver.
The end result will be:
- the major state machine not optimally dealed with because of the DRM kernel abstraction: you need a DRM major state machine that maps as good as it can to *all* kernels.
- the minor state machines, are coupled with the major state machine... and I would not be surprised if they are exceptions in those machines based on the underlying kernel specific major state machine. Additonnaly, user level nobs would have to be coded internally for each kernel.

And that story will map for all the other kernel services!

Ok, I stop there, but do not be surprised if a few people do not agree with that approach. And I don't even talk about the licensing issue. I wish you luck on that road... if one day I have brain time to join seriously AMD GPU driver coding, that will be on a parallel twin road.

[bridgman]

sylware, I'm not sure what you are recommending here. If the Linux power management system doesn't handle arbitrary device power states, doesn't that essentially require the kind of split implementation agd5f was describing ?

[Loris]

sylware, you know this radeon DRM module is the Linux, and just Linux, one, right?
Probably I just misunderstood your posts, sorry if that's the case.

[agd5f]

pm.h defines calbacks for the Linux major power management state machine. It would have to be implemented by the driver itself, DRM or not. And, we agree a generalized interface would be insane, that was my point.
But... then you tell me the minor power management state machines are coded internally in the driver.
The end result will be:
- the major state machine not optimally dealed with because of the DRM kernel abstraction: you need a DRM major state machine that maps as good as it can to *all* kernels.
- the minor state machines, are coupled with the major state machine... and I would not be surprised if they are exceptions in those machines based on the underlying kernel specific major state machine. Additonnaly, user level nobs would have to be coded internally for each kernel.

And that story will map for all the other kernel services!

You're not making sense. The interface in pm.h doesn't apply to any of the pm state in question. How would I use it for that?

The driver handles it's internal state properly so that it will do the right thing when the higher level s/r routines are called.

Why would the kernel version matter other than for distros that may patch in/out functionality? The radeon drm lives in the kernel and it's tied to the interfaces in the kernel.

???

[icek]

Will these patches land in 2.6.34 rc2 ?

[dfx.]

i pretty sure the man trying to ask you to provide some graphic happiness, you spoiling us with, to all free and non-free kernels out there simultaneously

well, you know all this crazy talk about porting KMS\TTM stuff onto *BSD and Gallium on Windows(tm)...

ah, those *BSD\Windows(r) people... never willing to just admit that GNU/Linux has dominated servers and is on the way to "desktop" and to accept its power and love of the brotherh^Wcommunity

Will these patches land in 2.6.34 rc2 ?

i kinda second on that - is there a way to make use of those patches over then compiling specific branch from some git ?

this is burning question for me since i've decided to order R770 card as a replacement for my old (and sold) nvidia's 7800gtx.
it will come after a week and i'm afraid to burn it to crisps since damn thing gives away up to 250 watts ! 0_o

[Wielkie G]

it will come after a week and i'm afraid to burn it to crisps since damn thing gives away up to 250 watts ! 0_o

Don't worry - 250W is not GPU power consumption (in fact it's very hard to detect it). This is power consumption of the whole testing system for sure. It was using i7, so it bumped wattage "a bit"

To find out the power consumption of cards, look at TDPs, for example on Wikipedia.

[dfx.]

oh... looks like i've read it inattentively but i thought its "135.5W TDP" will somehow double with a help of hot memory...

but it's still scary to use it knowing that it will run at full power all the time (and i never switch off this PC) and, from what i understand from here, there is still big difference with my old NV7800GTX

[bugmenot]

Any chance of getting patches for 2.6.33?