Announcement

Collapse
No announcement yet.

Radeon Driver Power Management Has Room For Improvement

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

  • #31
    Originally posted by HokTar View Post
    While this is true - assuming that the mentioned "pm logic" is documented (which I admittedly don't know) - it still feels that not working on this is pretty much defeating the whole effort. I mean, all right task #1 is enabling chips. I think no one ever questioned that. But what is #2?
    Task #2 is stability, ie trying to make the HW/SW combination not crash. Task #3 is supporting other driver developers (#2 and #3 are probably same priority really).

    Between #1, 2 and 3 all the time is used up. You are making reasonable proposals for what we do with all the leftover time but there isn't any leftover time.

    Originally posted by HokTar View Post
    So I guess after enabling basic functionality - which seemed more or less straightforward for the past few generations due to small/moderate changes
    This is the first problem with your argument. The fact that the changes are relatively small doesn't mean they are quick or easy, and you've probably figured out that we have larger changes coming down the pipe.

    Originally posted by HokTar View Post
    - in my opinion the next vital thing would be pm. Especially in the era of mobile devices and the Fusion APU which is best known for its low consumption. So burning power unnecessarily with the APUs seem to defeat the whole purpose and should be a key focus for AMD. Hence Average Linux Joe buys a new machine, installs $HISFAVOURITEDISTRO and he doesn't care anymore 'cause desktop effects work and there's plenty of battery time remaining.
    OK, so let's just be clear. Improving PM is more important than making the chip work reliably in the first place and allowing other developers to work effectively ? Those are the choices.

    Originally posted by HokTar View Post
    Well, I'm just an outsider so what do I know about AMD's aims and goals but I think I heard somewhere that it was to give good out-of-the-box experience for Linux users. However, halving the battery life out-of-the-box will not please many users... so what I described still makes sense to me. Please point out my mistakes and misunderstandings if you have time. Thanks!
    I guess there are two key points here. One is that you are starting with the (invalid) assumption that Alex has lots of time left over and has been spending it on things you consider less important than power management. You look at the changes for new GPU support, see that they are relatively small, and assume the work was fast and easy. Not so.

    The second key point is that some things can only be done by AMD employees, while others can be done by any developer. Unless/until we are keeping up with things that only AMD folks can do, it doesn't seem to make sense to slow *everything* and *everybody* down to work on something that other community developers could do just as easily.

    You are probably also making the assumption that getting power management working the way you want would be fast and easy. That`s probably wrong too

    Good questions though.
    Last edited by bridgman; 29 June 2011, 12:05 AM.
    Test signature

    Comment


    • #32
      Originally posted by bridgman View Post
      Task #2 is stability, ie trying to make the HW/SW combination not crash. Task #3 is supporting other driver developers (#2 and #3 are probably same priority really).
      Good points, forgot about those (well, I implicitly assumed that if a chip is working it means working stable). Alex indeed answers all radeon related letters on mesa-dev, etc.

      Originally posted by bridgman View Post
      Between #1, 2 and 3 all the time is used up. You are making reasonable proposals for what we do with all the leftover time but there isn't any leftover time.
      Well, I can see that. This is exactly the reason I mentioned your new recruits.



      Originally posted by bridgman View Post
      This is the first problem with your argument. The fact that the changes are relatively small doesn't mean they are quick or easy, and you've probably figured out that we have larger changes coming down the pipe.
      The small changes can be tricky and cumbersome, so I tried not to underestimate them. Hearing from bigger changes is always fascinating!


      Originally posted by bridgman View Post
      OK, so let's just be clear. Improving PM is more important than making the chip work reliably in the first place and allowing other developers to work effectively ? Those are the choices.
      I never said or implied this.


      Originally posted by bridgman View Post
      I guess there are two key points here. One is that you are starting with the (invalid) assumption that Alex has lots of time left over and has been spending it on things you consider less important than power management. You look at the changes for new GPU support, see that they are relatively small, and assume the work was fast and easy. Not so.
      See above -- I didn't imply that Alex wasn't working his ass off and that the changes were trivial.
      However, it seemed that Dave Airlie was asked/hired/whatever to bring up cayman support. This suggests that Alex was working on something else which is not yet visible for normal people.

      Originally posted by bridgman View Post
      The second key point is that some things can only be done by AMD employees, while others can be done by any developer. Unless/until we are keeping up with things that only AMD folks can do, it doesn't seem to make sense to slow *everything* and *everybody* down to work on something that other community developers could do just as easily.
      Again, this is not what I meant. However, you are implying that pm is easy yet I remember how much Alex and if memory serves Rafal Milecki struggled to get to a somewhat working state.

      Originally posted by bridgman View Post
      You are probably also making the assumption that getting power management working the way you want would be fast and easy. That`s probably wrong too
      I know that it's not. Otherwise it would have been done ages ago, wouldn't it?

      Originally posted by bridgman View Post
      Good questions though.
      Thank you for your time and answers, it made things clearer. Can we expect some update in the foreseeable future on who you hired and/or when they are supposed to start and/or what you have in mind as for their first tasks?

      Comment


      • #33
        Originally posted by whitecat View Post
        How do you see this ?
        /sys/kernel/debug/dri/0/radeon_pm_info

        You need debugfs mounted.

        HTH

        Comment


        • #34
          Originally posted by Welsh Dwarf View Post
          /sys/kernel/debug/dri/0/radeon_pm_info

          You need debugfs mounted.

          HTH
          Thx.
          What stands for 0 and 64 ?

          Comment


          • #35
            dynclks

            I don't recall seeing any mention of using dynclks being enabled?

            On my system it doesn't seem to be possible to enable at runtime (only during kernel boot radeon.dynclks=1).

            $ cat /sys/module/radeon/parameters/dynclks
            1

            Comment


            • #36
              Originally posted by Death Knight View Post
              And its really weird that why GPU low is consumes higher than fglrx in idle state.
              I think it's needed to be top priority thing since all open source stack users just wasting their electricity and I guess it's simple to fix than trying to put better 3D stuff.
              I do agree, having at least a working low profile is a must. For some cards it does work as well as catalyst, for others it simply doesn't work
              Even dynpm does work very well on my HD3870 with linux-3.0.0-rc5 (except a bit of flickering) but it seems I'm lucky. Wondering if/when dynpm will be the default
              ## VGA ##
              AMD: X1950XTX, HD3870, HD5870
              Intel: GMA45, HD3000 (Core i5 2500K)

              Comment


              • #37
                Originally posted by darkbasic View Post
                Even dynpm does work very well on my HD3870 with linux-3.0.0-rc5 (except a bit of flickering) but it seems I'm lucky.
                What's the vendor of your card?
                Maybe the level of support is due to the BIOS provided by the vendors.

                Comment


                • #38
                  Originally posted by whitecat View Post
                  What's the vendor of your card?
                  Uhm... I don't remember. I will check.
                  ## VGA ##
                  AMD: X1950XTX, HD3870, HD5870
                  Intel: GMA45, HD3000 (Core i5 2500K)

                  Comment


                  • #39
                    Fixing dynpm?

                    Originally posted by darkbasic View Post
                    Even dynpm does work very well on my HD3870 with linux-3.0.0-rc5 (except a bit of flickering) but it seems I'm lucky. Wondering if/when dynpm will be the default
                    I have been playing a little with the power management code and dynpm and the impression I currently have is that it is possible to make it work very well. The simplest fix would be to add some more user configuration options so that users could optionally enable some lower power states too.

                    The only problem is the flicker. I have no idea how to get rid of it. Are there any ideas or documentation? I personally will not be using dynpm until there is a way to get rid of the flicker.

                    Comment


                    • #40
                      Originally posted by whitecat View Post
                      Thx.
                      What stands for 0 and 64 ?
                      Frankly, I don't really know. I'll have to refer this one to the radeon gods on mount mesa

                      Comment

                      Working...
                      X