Announcement

Collapse
No announcement yet.

Radeon DPM Support Should Now Be In Good Shape

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

  • #21
    Originally posted by Death Knight View Post
    I think DPM doesn't work well.
    Just look GPU clock 10 times per seccond and divide by ten
    After using computer for a while
    Power state of my GPU HD6850 is like that:

    P0: 703 Seconds
    P1: 119 Seconds
    P2: 9372 Seconds !!!

    Means more than %90 of the time, my GPU is in High power state.

    Indeed with latest Mesa and sitting on Idle state on my GTK3 desktop Power State switching P0 to P2 without apparent reason.

    I watch with my GPU with readeontop and don't see any bottleneck on my GPU. There are no use but power state jumps to P2.

    I think power switching algorithm need some tune up.

    Edit: You can inspect your GPU power states with this Python script
    Code:
    #!/usr/bin/env python
    import time
    a=[0,0,0]
    while 1:
       time.sleep(0.1)
       state=open('/sys/kernel/debug/dri/0/radeon_pm_info').read()
       x=int(state[state.find('power level')+12])
       if x >=0 and x <=2:
          a[x]+=1
       else:
          print state
       print "P0:",a[0]/10 ,"P1:", a[1]/10, "P2:", a[2]/10
    i noticed too that my 7770 Ghz edition jump to highest values at most minimal load and go back to minimal directly but i can wait for later revision, im happy enough it reclocks

    Comment


    • #22
      Wow. Just wow.
      I installed the OSS driver+the whole shebang (mesa devel, kernel 3.11, libdrm, ati drv 7.10 or whatever the latest it is) for UVD and dpm on a A8-5500 APU (7560D IGP). Took me a while, especially after the installation, to actually get the system to use these libs.

      Code:
      $ glxinfo | grep OpenGL
      OpenGL vendor string: X.Org
      OpenGL renderer string: Gallium 0.4 on AMD ARUBA
      OpenGL version string: 3.0 Mesa 9.3.0-devel (git-bff0d87)
      OpenGL shading language version string: 1.30
      Having played with and on it, i have to say that the radeon OSS drivers really kick ass. Really.

      Some specifics:
      - The idle temperature is 2 or 3 degrees higher than with fglrx which is very acceptable.

      The following were features that werent working before:

      - dpm clocking works perfectly - it clocks up and down when its neded, doesnt stay up needlessly. This is true for both the uvd and gpu clock speeds (monitor it by /sys/kernel/debug/dri/0/radeon_pm_info).

      - the CPU speed adjusts as it should - previously, despite the governor demanding higher clock speeds, reflected in /proc/cpuinfo, the ACTUAL speed was the LOWEST possible (measured with cpufreq-aperf). Took me an eternity to compile the kernel on it and i didnt know why is that hellishly slow initially when cpuinfo reported 3.2 GHz speeds (which is misleading because that is the requested, highest possible p-state, and seems like the old radeon driver is picky about stuff ike that and didnt allow it). It took me some time to figure out how to actually crank up the speeds.
      Also, it seems that Turbo Core is working aswell (3.488 GHz was the maximum recorded with fglrx aswell) - cpufreq-aperf reports the following with 1 thread loaded:

      Code:
      CPU	Average freq(KHz)	Time in C0	Time in Cx	C0 percentage
      000	1376000			00 sec 103 ms	00 sec 896 ms	10
      001	1376000			00 sec 086 ms	00 sec 913 ms	08
      002	3488000			00 sec 015 ms	00 sec 984 ms	01
      003	3488000			00 sec 998 ms	00 sec 001 ms	99
      Interesting that 2 cores are up to speed in reality (cpuinfo shows only 1 at the nominal 3.2 GHz) - probably because of the modular design.

      - the dynamic voltage adjusting onn the APU is working correctly (it goes down to 0.9v and up until 1.34 or so, like with fglrx). Previously it stayed at 1.34 or 1.44 permanently, causing +10-12 C temperatures.
      -vdpau decoding works (has some kinks in xbmc - namely if i switched from windowed to fullscreen or vice versa, screen went black, had to kill it from tty1, but mplayer was good so far).

      And the thing that blew me away the most is:
      TF2 is actually plays SMOOTHER than with fglrx (i mean plays perfectly, including less loading times). Never expected this.
      OTOH DoD (Day of Defeat, on hl1 engine) is actually SLOWER THAN TF2 on Source engine. Weird.

      Also, i played around in the browser (Seamonkey, uses Firefox' engine) with the WebGl (OpenGL rendered DIRECTLY by the browser) demos over here:
      Since 2009, coders have created thousands of amazing experiments using Chrome, Android, AI, WebVR, AR and more. We're showcasing projects here, along with helpful tools and resources, to inspire others to create new experiments.


      To my surprise, the demos worked well, i tried the flight sim, the car visualizer, the sphere in the water, the pearl boy - all worked without a hitch.

      I use Debian Testing 64-bit, Xfce 4.10 (no compositing). Until now i used exclusively fglrx.

      I planned only a test with these new features but i think i'll stick around a bit more...

      Awesome work, devs.
      Last edited by gradinaruvasile; 03 August 2013, 05:53 PM.

      Comment


      • #23
        On my Radeon HD 6870 it doesn't seem to work atm. Then again, I've heard so many good opinions about DPM that I'm really looking forward to it.
        This is what will make me switch to the OS drivers. For gaming (which I rarely do nowadays) I've got my PS3 and soon a PS4.

        Comment


        • #24
          Originally posted by Alderon View Post
          On my Radeon HD 6870 it doesn't seem to work atm. Then again, I've heard so many good opinions about DPM that I'm really looking forward to it.
          This is what will make me switch to the OS drivers. For gaming (which I rarely do nowadays) I've got my PS3 and soon a PS4.
          You need the correct kernel and firmware but I can confirm it works on my 6870. One issue I had though is some strange color distortion that frankly scared the crap out of me (which occurred while I was away from my computer) so for the time being I'm waiting on the 3.11 kernel to stabilize before I try enabling dpm again but before that it worked great.

          Comment


          • #25
            Yes, I'm using that exact firmware from the before mentioned download link (BARTS_smc). I even tried linux-firmware-git.
            When did you try out that feaure? Because I've read that it worked before for some hd 6870 users but it is now broken, could be a regression.

            Comment


            • #26
              Any idea of when we will be able to change the value of these power modes?

              I need to use a specific clock ratio of 0.57 (969Mhz Core / 1700Mhz Memory) for my array of Radeon 7970. OpenCL work but that reclocking is the only missing thing that prevent me switching (so i'm stuck with Crapalyst 13.1 patched for kernel 3.10, Newer drivers crash from time to time...)

              Comment


              • #27
                Originally posted by cynical View Post
                You need the correct kernel and firmware but I can confirm it works on my 6870. One issue I had though is some strange color distortion that frankly scared the crap out of me (which occurred while I was away from my computer) so for the time being I'm waiting on the 3.11 kernel to stabilize before I try enabling dpm again but before that it worked great.
                Hmm yes, I'm using linux-mainline (3.11rc3) and downloaded the firmware, but also tried linux-firmware-git which provides all the latest firmware on Arch Linux.
                I'm assuming that it's a regression as I've heard from some people that dpm worked for them before but now doesn't anymore.

                Comment


                • #28
                  Originally posted by Alderon View Post
                  Hmm yes, I'm using linux-mainline (3.11rc3) and downloaded the firmware, but also tried linux-firmware-git which provides all the latest firmware on Arch Linux.
                  I'm assuming that it's a regression as I've heard from some people that dpm worked for them before but now doesn't anymore.
                  my 6850 works fine with dpm, currenly with
                  Linux Saturn 3.11.0-rc4 #1 SMP PREEMPT Mon Aug 5 01:36:06

                  03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Barts PRO [Radeon HD 6850]
                  03:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Barts HDMI Audio [Radeon HD 6800 Series]

                  Comment


                  • #29
                    Works for me too. Debian Testing 64-bit, kernel 3.11.0-rc4, A8-5500/HD 7560D, mesa, xf86-ati from git (libdrm is at the newest release version).

                    The thing that bothers me is the fact that if i turn off the video output (dpms), after a few hours of idleness the computer freezes totally. I made a script that simulates mouse movement with xdotool every half hour (only if the monitor is off) to wake up the monitor (it turns off after 4 minutes) - since i put that in crontab, i havent had any freezes. Turning off dpms altogether too helps.

                    PS.
                    1. Making use of the dpm feature requires more than just the kernel and compiled mesa/etc - you have to make absolutely sure the new libs are actually used. Even after an update you have to recheck (ldd /usr/bin/glxinfo), maybe ldconfig decides to do a stunt and puts back some old libs...

                    2. I have seen some weird boot up behavior, such as the APU being powered with its maximum voltage until i did a dpms cycle (off/on) or i changed to another vt and back (which i suppose does something similar). After that the voltage regulation kicked in as it should.

                    Comment


                    • #30
                      Originally posted by gradinaruvasile View Post
                      Works for me too. Debian Testing 64-bit, kernel 3.11.0-rc4, A8-5500/HD 7560D, mesa, xf86-ati from git (libdrm is at the newest release version).

                      The thing that bothers me is the fact that if i turn off the video output (dpms), after a few hours of idleness the computer freezes totally. I made a script that simulates mouse movement with xdotool every half hour (only if the monitor is off) to wake up the monitor (it turns off after 4 minutes) - since i put that in crontab, i havent had any freezes. Turning off dpms altogether too helps.

                      PS.
                      1. Making use of the dpm feature requires more than just the kernel and compiled mesa/etc - you have to make absolutely sure the new libs are actually used. Even after an update you have to recheck (ldd /usr/bin/glxinfo), maybe ldconfig decides to do a stunt and puts back some old libs...

                      2. I have seen some weird boot up behavior, such as the APU being powered with its maximum voltage until i did a dpms cycle (off/on) or i changed to another vt and back (which i suppose does something similar). After that the voltage regulation kicked in as it should.
                      That's interesting. I've also been experiencing hard locks very randomly (every few days) ever since using DPM/mesa-git/mainline/etc, but I wasn't sure what was causing it. In my case, it usually happens while I'm using the computer and I'm forced to reset my computer manually. I've since enabled the magic sysrq key in hopes that I can get a kernel log of it the next time it happens.

                      Comment

                      Working...
                      X