Announcement

Collapse
No announcement yet.

Radeon DRM: Dynamic Power Management Updates

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    @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 !

    Comment


    • #12
      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.

      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.

      Comment


      • #13
        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.

        Comment


        • #14
          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.

          Comment


          • #15
            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.
            All opinions are my own not those of my employer if you know who they are.

            Comment


            • #16
              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!
              All opinions are my own not those of my employer if you know who they are.

              Comment


              • #17
                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.
                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; 06 July 2013, 01:53 PM.

                Comment


                • #18
                  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.

                  Comment


                  • #19
                    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.
                    Test signature

                    Comment


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

                      Comment

                      Working...
                      X