Announcement

Collapse
No announcement yet.

AMD Has Massive Radeon Patch Set - Power Management!

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

  • Latest kernel didn't fix UVD, booting soft lockup and 3D performance (doesn't get faster/louder in games) for my HD 6870.

    Comment


    • Originally posted by pali View Post
      Here is some more info with enabled dpm

      dpm performance mode:
      Code:
      glxgears --> 616 FPS (with Option SwapbuffersWait off)
      $ cat /sys/class/drm/card0/device/power_method 
      dpm
      $ cat /sys/class/drm/card0/device/power_dpm_state 
      performance
      dpm battery mode:
      Code:
      glxgears --> 590 FPS (with Option SwapbuffersWait off)
      $ cat /sys/class/drm/card0/device/power_method 
      dpm
      $ cat /sys/class/drm/card0/device/power_dpm_state 
      battery
      So when dpm is enabled performance is definitly worse.

      @agd5f: Do you know what to do? How to increase performance with enabled dpm? I'd like to see same performace with dpm as "default" profile has.

      If you need additional info or tests, let me know what is needed.
      Glxgears is a light 3D benchmark. So light, many claim it only measures CPU overhead of the driver, so the values are not directly comparable. But increase in glxgears frames on same machine is a good thing.
      You may be hitting ondemand powerstate bug, thread is found in this section of forum, but only if you use non-Intel CPU. Intel CPUs use pstate driver, so its completely different and more efficient.
      To overcome this, you can play with:
      echo 150 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
      which will increase CPU polling time, if frequency went up. Default is 1.
      the cpu will stay longer in performance state and less frequent polls in power state rob less of CPU raw performance.
      but on mobile platform it could be advantageous to keep the value lower or even default, as it will result in faster downclock time and less battery usage. However, if your mobile platform is loaded, more frequent polls will rob its performance and will rob more battery. Think of it as a warden, that can mess too much in manufacturing process, robbing its efficiency; but if there is nothing to do, more frequent checks will result in faster downclock.

      echo 35 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
      which will make CPU enter full clocking, if the load of more that 35% is detected. Default is 95%, which guarantees sluggish desktop. Personally recommended values 25-40%.

      You can then set these variables in /etc/sysfs.conf (create it, if absent), the following way:
      devices/system/cpu/cpu0/cpufreq/scaling_governor = ondemand
      devices/system/cpu/cpu1/cpufreq/scaling_governor = ondemand
      devices/system/cpu/cpufreq/ondemand/sampling_down_factor = 150
      devices/system/cpu/cpufreq/ondemand/up_threshold = 35
      or load your settings in any autostart script.

      If you have mobile platform, governor "conservative" may be more advantageous, as it increases clocks step-wise; "ondemand" will fire top clock when reaching barrier, instead.
      Last edited by brosis; 07-02-2013, 11:21 AM.

      Comment


      • Originally posted by brosis View Post
        Intel CPUs use pstate driver
        From what I read [1] [2], this pstate driver only supports sandy bridge and more recent processors.

        [1] http://www.phoronix.com/scan.php?pag...tem&px=MTI5Mzc
        [2] http://lkml.indiana.edu/hypermail/li...2.1/03328.html
        Last edited by stqn; 07-02-2013, 11:52 AM.

        Comment


        • Just to note, I have Intel Sandy Bridge processor.

          Comment


          • Things seem to be working generally well for me on 2 of the 3 cards I've got installed at the moment (my 6850 lacks a computer to install it in):

            Cedar (Radeon 5400): Both the graphics chip and UVD reclocking seems be to functioning well... with a dual-monitor setup. Kernel = drm-next from Ubuntu mainline ppa as of 20130702 (firmware from people.fd.o)

            A6-3500 (APU): I haven't checked clock speeds using the new debugfs code, but the machine is working well with radeon.dpm=1 radeon.audio=1 and VDPAU/UVD being used. This is using the WIP-3 (or maybe -5) branch.

            HD7850: Reclocking seems to be working just fine for the gpu/memory, but anything that has to do with UVD is causing screen corruption the moment that the UVD clock is increased. And then when you stop using UVD, the system hangs. This is using the WIP-3 or WIP-5 branch code. I'll have to retest with some newer stuff later.

            Comment


            • Code:
              [email protected]# cat /sys/kernel/debug/dri/0/radeon_pm_info
              uvd    vclk: 0 dclk: 0
              power level 0    sclk: 10000 mclk: 30000 vddc: 950 vddci: 950
              [email protected]# cat /sys/kernel/debug/dri/0/radeon_pm_info
              uvd    vclk: 0 dclk: 0
              power level 2    sclk: 79000 mclk: 100000 vddc: 1150 vddci: 1100
              All works after last update!!!

              Comment


              • Great news!

                This is great news! I am glad that AMD has decided that providing a proper open source driver is important. Thank you developers! Now, time to go do some testing....

                Comment


                • Originally posted by sandy8925 View Post
                  This is great news! I am glad that AMD has decided that providing a proper open source driver is important. Thank you developers! Now, time to go do some testing....
                  They decided that it was important a long time ago, the code was written a while ago but it needed to go through their review process.

                  Comment


                  • Originally posted by agd5f View Post
                    I pushed some updated patches to my drm-next-3.11 branch that should fix the outstanding issue with NI asics and also adds a debugfs interface for tracking the current power state.
                    radeon_dpm_info shows that the driver indeed switches between power levels under even the slightest load, but the power levels within a state are all the same on my card (RV770).

                    Comment


                    • Just updated to latest drm-next kernel (07/2) (from ubuntu ppa) and everything is working just fine including being able to see radeon_pm_info.

                      Code:
                      [email protected]:~$ sudo cat /sys/kernel/debug/dri/0/radeon_pm_info
                      uvd    vclk: 0 dclk: 0
                      power level 0    sclk: 15700 mclk: 20000 vddc: 900 vddci: 0
                      As soon as I refreshed I checked the radeon_pm_info again and it changed just fine:

                      Code:
                      [email protected]:~$ sudo cat /sys/kernel/debug/dri/0/radeon_pm_info
                      uvd    vclk: 0 dclk: 0
                      power level 2    sclk: 75000 mclk: 80000 vddc: 1120 vddci: 0
                      Last edited by Bushido_root; 07-03-2013, 12:32 PM.

                      Comment

                      Working...
                      X