Radeon DRM: Dynamic Power Management Updates

[kernelOfTruth]

@agd5f:

I'm probably again using an outdated kernel (from 4th of july) but I used dynpm for a whole day and it was annoying loud, producing lots of warmth & eating energy - thus money

dynpm in that state may be perfectly suitable for gamers but for e.g. "normal" research work & while it's warm outside - it's not

it's simply too loud and disturbing concentration, furthermore energy is pretty expensive here and my appartment gets warm very fast while the gpu runs as a heater

might the fact that I'm using compiz-fusion play a role in this ?

the gpu is also running a full speed/clocking pretty high even when working on a console window in X with compositing activated



don't get me wrong: this is not to directly criticize your work - which I heavly appreciate - but to point out that under these consequences it's not suitable for all:

e.g. when using the windows 7/8 catalyst driver it's significantly more silent and only clocks up that much when running games and putting full load on the gpu


fglrx back then when I used it (last year) also was way more silent - it was noticably louder than under windows but it was still tolerable


hope there's changes - otherwise - unfortunately the only option I had would be to use static "low" performance profile



thanks for your hard work !

[agd5f]

Are we gonna have to go through this whole legal-disaster again for future radeon cards? Or now that UVD and DPM are out there and AMD knows they are targeting open source with future products, will those two things also just now be worked as hardware-enablement happens?

We shouldn't have the same level of hurdles for future asics. The IP review process was mainly targeted at assessing the risk of exposing the high level IP, e.g., UVD in general or DPM in general.

Also, just for pure curiosity's sake... What were the radeon devs doing wrong when it came to dynpm? It was a longstanding and well known issue that Dynpm couldn't complete the reclocking during vsync and therefore would flicker, and (atleast according to the arch wiki: ) also wouldn't work with multiple outputs active. How come? I'm assuming that now the correct implementation is out there in the wild that there's no legal issue preventing the devs from talking about the existing DynPM code. Were they just trying to do too much during vsync? Was Vsync not actually where the reclocking was supposed to happen? What was it?

DPM uses special hardware on the GPU that was designed to synchronize with properly with other hardware blocks if programmed properly. With the previous dynpm code, the driver was responsible for trying to manage that itself. The previous code could probably have been better tuned (e.g., to split state changes up across multiple vblanks if necessary, etc.), but there wasn't much motivation since the hardware has specific capabilities to handled this for you.

[mudig]

I'm probably again using an outdated kernel (from 4th of july) but I used dynpm for a whole day and it was annoying loud, producing lots of warmth & eating energy - thus money

Umm, are you sure you're actually using the new DPM code (kernel parameter radeon.dpm=1)? dynpm is the old and useless way of doing things, dpm is the new awesome one.

[agd5f]

@agd5f:

I'm probably again using an outdated kernel (from 4th of july) but I used dynpm for a whole day and it was annoying loud, producing lots of warmth & eating energy - thus money

dynpm in that state may be perfectly suitable for gamers but for e.g. "normal" research work & while it's warm outside - it's not

it's simply too loud and disturbing concentration, furthermore energy is pretty expensive here and my appartment gets warm very fast while the gpu runs as a heater

might the fact that I'm using compiz-fusion play a role in this ?

the gpu is also running a full speed/clocking pretty high even when working on a console window in X with compositing activated

don't get me wrong: this is not to directly criticize your work - which I heavly appreciate - but to point out that under these consequences it's not suitable for all:

e.g. when using the windows 7/8 catalyst driver it's significantly more silent and only clocks up that much when running games and putting full load on the gpu

fglrx back then when I used it (last year) also was way more silent - it was noticably louder than under windows but it was still tolerable

hope there's changes - otherwise - unfortunately the only option I had would be to use static "low" performance profile

thanks for your hard work !

I think you may be using the old dynpm code. To enable the new DPM code, set the radeon dpm module parameter to 1. E.g., add radeon.dpm=1 to the kernel command line in grub.

[Ericg]

I think you may be using the old dynpm code. To enable the new DPM code, set the radeon dpm module parameter to 1. E.g., add radeon.dpm=1 to the kernel command line in grub.

Will radeon.dpm=1 automatically block the old power_profile, and power_method parameters? For example if you had /sys/class/drm/card0/device/power_method set to 'dynpm' and radeon.dpm=1 set on the kernel line, is dpm set to override dynpm, and only allow dynpm to work if instead radeon.dpm=0 is set? If not, it'd probably be a good idea, just as a precaution.

[Ericg]

We shouldn't have the same level of hurdles for future asics. The IP review process was mainly targeted at assessing the risk of exposing the high level IP, e.g., UVD in general or DPM in general.

DPM uses special hardware on the GPU that was designed to synchronize with properly with other hardware blocks if programmed properly. With the previous dynpm code, the driver was responsible for trying to manage that itself. The previous code could probably have been better tuned (e.g., to split state changes up across multiple vblanks if necessary, etc.), but there wasn't much motivation since the hardware has specific capabilities to handled this for you.

Awesome Thanks for the updates and info. Again, work is much appreciated and wish ya the best!

[kernelOfTruth]

Umm, are you sure you're actually using the new DPM code (kernel parameter radeon.dpm=1)? dynpm is the old and useless way of doing things, dpm is the new awesome one.

I think you may be using the old dynpm code. To enable the new DPM code, set the radeon dpm module parameter to 1. E.g., add radeon.dpm=1 to the kernel command line in grub.

I double-checked my grub.conf

and the (now removed) line indeed was radeon.dpm=1

not sure what I did wrong


guess I'll give it another try in a few days

http://cgit.freedesktop.org/~agd5f/l...=drm-next-3.11 so the branch drm-next-3.11 is the recommended kernel right now ?


the thing is: I used drm-next-3.11 and before that afaik drm-next-3.11-wip mentioned in http://lists.freedesktop.org/archive...ne/040436.html which gave me much more silent and cooler operation (almost perfect)

the only issue was that suspend-to-ram wasn't working but due to the fact that it's wip it's no issue right now


thanks !

[Hamish Wilson]

Will this support also come to older graphics cards, those that were released before the R600 series? My desktop computers are going to love this, but both of my laptops either have R200 or R500 cards in them and they need this dynamic power management support far more. The old static PM was actually more than acceptable on my desktop, but the laptops need all the heat and power saving they can get. Still, congratulations on defying so many expectations by coming this far.

[bridgman]

AFAIK the rv610/630 and rs780 were the first with any kind of DPM hardware, so older chips (r600 and earlier) rely on the driver for all power management.

[mannerov]

For laptops, does the zerocore technology rely on this hardware power gestion? (In other words, is zerocore supported by the new power management?)