Page 2 of 9 FirstFirst 1234 ... LastLast
Results 11 to 20 of 81

Thread: Radeon DRM: Dynamic Power Management Updates

  1. #11
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    642

    Thumbs up

    @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 !

  2. #12
    Join Date
    Dec 2007
    Posts
    2,402

    Default

    Quote Originally Posted by Ericg View Post
    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.

    Quote Originally Posted by Ericg View Post
    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.

  3. #13
    Join Date
    Mar 2010
    Posts
    25

    Default

    Quote Originally Posted by kernelOfTruth View Post
    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.

  4. #14
    Join Date
    Dec 2007
    Posts
    2,402

    Default

    Quote Originally Posted by kernelOfTruth View Post
    @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.

  5. #15
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,920

    Default

    Quote Originally Posted by agd5f View Post
    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.

  6. #16
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,920

    Default

    Quote Originally Posted by agd5f View Post
    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!

  7. #17
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    642

    Default

    Quote Originally Posted by mudig View Post
    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.
    Quote Originally Posted by agd5f View Post
    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 !
    Last edited by kernelOfTruth; 07-06-2013 at 02:53 PM.

  8. #18
    Join Date
    Oct 2011
    Location
    Rural Alberta, Canada
    Posts
    1,050

    Default

    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.

  9. #19
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,543

    Default

    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.

  10. #20
    Join Date
    Dec 2012
    Posts
    168

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •