Announcement

Collapse
No announcement yet.

Radeon DRM: Dynamic Power Management Updates

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

  • Radeon DRM: Dynamic Power Management Updates

    Phoronix: Radeon DRM: Dynamic Power Management Updates

    The DRM pull request has yet to be submitted for the Linux 3.11 kernel and already there is another revision to the Radeon DRM kernel driver to be submitted. This latest Radeon DRM work provides additional dynamic power management fixes and some new sysfs features...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Alex, two questions for ya. One related to this and one general radeon question.

    Related question: I know an AMD dev made a comment at one point that said that catalyst PM code was larger than all of Mesa totalled....lovely. What's the hopes for this code drop? I'm not really expecting almost identical power usage between radeon and catalyst after 3.11, but in your tests is it comparable at least? Not trying to bash the work, even if all this did was automatically jump between 'low' 'medium' 'high' power profiles based upon load that would still be an improvement over the status quo, so its definitely appreciated. I'm just curious what you, as the developer, would say the impact in comparison to Catalyst.

    Radeon question: So 3.10 bring us UVD, 3.11 brings us DPM, Crossfire would probably require a big rework kernel side and user-side (as far as Kernel, Mesa, and X) to make work so that really just leaves one thing in my head.... How's HDMI audio coming along? Its been disabled by default since like 3.0 or 3.2, Michael did an article about how one of the devs made Radeon do the exact same steps (as far as registers go) that catalyst does and that it worked out all the problems he was having on his test machines... did those patches ever get merged? Whats the big blocker-bug for hdmi audio enabled by default?
    All opinions are my own not those of my employer if you know who they are.

    Comment


    • #3
      The RV770 improvement works for me. Thanks, Alex Deucher.

      As a bonus, fan speed seems to be proportional to load in the 3d_perf state - old code/firmware had it at max all the time.

      Comment


      • #4
        Anyone know if this fixes the flickering and UVD problems on RV730?

        Comment


        • #5
          Originally posted by tball View Post
          Anyone know if this fixes the flickering and UVD problems on RV730?
          It cann't.

          First is realated to tear-free rendering (which require replacing X.org..), second is related to UVD code itself. So you will have flickering GPU with UVD problems, but which consume less power and which fan work lighter.
          (Did you reported your bugs? Not about flickering unless its whole screen flickering, but about UVD?)

          Comment


          • #6
            Originally posted by przemoli View Post
            It cann't.

            First is realated to tear-free rendering (which require replacing X.org..), second is related to UVD code itself. So you will have flickering GPU with UVD problems, but which consume less power and which fan work lighter.
            (Did you reported your bugs? Not about flickering unless its whole screen flickering, but about UVD?)
            I don't know if you are refering to tearing, but this is not tearing. It is related to the new dpm code (I think). The flickering is coming and going, and consists of the whole screen jumping up and down.

            I don't mind the UVD problems, since it is very experimental code. But the flickering renders my desktop hard to look at for too long.

            Comment


            • #7
              Originally posted by tball View Post
              I don't know if you are refering to tearing, but this is not tearing. It is related to the new dpm code (I think). The flickering is coming and going, and consists of the whole screen jumping up and down.

              I don't mind the UVD problems, since it is very experimental code. But the flickering renders my desktop hard to look at for too long.
              Hey, I know this problem. It was the same a few years back. Had to disable dynpm :s

              Comment


              • #8
                For Zacate CPUs I think this 3.11er patches are not extremly important so I go a bit OT but still kind of related:

                I read on the comments of the radeon driver that also the apus would start after boot at their minimal frequency, I think you propable only meant the gpu part, but also memory frequency was talked about. So I thought maybe that could be here a problem why I think here my gnome is a bit slower in arch here (was the same with ubuntu) as on the pc of my dad with fedora.

                So I looked into it... on my zacate machine the memory frequency is fix on 1333mhz thats normal.

                Then I thought lets test the cpus how they react to stress ^^ so I installed a cpuburn programm startet two of em... because I have two cores both take 60-70% load... so more than 1 core should be used.

                But when I then look at cpuinfo I see one core at 1600mhz and one at only 800mhz.

                Ok thought maybe I did something wrong in some powersettings or something or my thinkpad is here special so I did the same test on my also zacate htpc with fedora on it.
                So here the same.

                So I can say that at least for kernel 3.10 this seems to be a general reality.

                So my question is this behaviour that only one core gets clocked from 800 to 1600mhz normla for zacate? Or is that a bug in the 3.10er kernel or what?


                (Sorry for to much So... ^^)

                Comment


                • #9
                  Originally posted by Ericg View Post
                  Alex, two questions for ya. One related to this and one general radeon question.

                  Related question: I know an AMD dev made a comment at one point that said that catalyst PM code was larger than all of Mesa totalled....lovely. What's the hopes for this code drop? I'm not really expecting almost identical power usage between radeon and catalyst after 3.11, but in your tests is it comparable at least? Not trying to bash the work, even if all this did was automatically jump between 'low' 'medium' 'high' power profiles based upon load that would still be an improvement over the status quo, so its definitely appreciated. I'm just curious what you, as the developer, would say the impact in comparison to Catalyst.
                  Have you seen the size of the dpm patch set It should come pretty close to the closed driver savings-wise. It is pretty much on par feature-wise.

                  Originally posted by Ericg View Post
                  Radeon question: So 3.10 bring us UVD, 3.11 brings us DPM, Crossfire would probably require a big rework kernel side and user-side (as far as Kernel, Mesa, and X) to make work so that really just leaves one thing in my head.... How's HDMI audio coming along? Its been disabled by default since like 3.0 or 3.2, Michael did an article about how one of the devs made Radeon do the exact same steps (as far as registers go) that catalyst does and that it worked out all the problems he was having on his test machines... did those patches ever get merged? Whats the big blocker-bug for hdmi audio enabled by default?
                  There were a number of monitors that would display blank screens with hdmi audio enabled by default. We fixed a number of bugs in the hdmi packet generation in the last couple of kernels so if all goes well in this cycle we can probably enable it.

                  Comment


                  • #10
                    Originally posted by agd5f View Post
                    Have you seen the size of the dpm patch set It should come pretty close to the closed driver savings-wise. It is pretty much on par feature-wise.
                    I saw the mailing list messages and glanced at your branches, but no, I hadn't seriously delved into your work-- kernel coding is a bit beyond me haha.

                    Originally posted by agd5f View Post
                    There were a number of monitors that would display blank screens with hdmi audio enabled by default. We fixed a number of bugs in the hdmi packet generation in the last couple of kernels so if all goes well in this cycle we can probably enable it.
                    Lovely glad to hear both of those bits of information. Once hdmi is enabled by default that'll basically takes care of all the big features as far as I'm concerned with Radeon. Though you devs may know of a few other features that need to handled. The work is much appreciated Alex, please send my thanks and regards along to anyone else who worked on DPM and UVD

                    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?

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

                    Comment

                    Working...
                    X