Announcement

Collapse
No announcement yet.

2013: A Good Year For Open-Source AMD?

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

  • #61
    Originally posted by bridgman View Post
    Nope. Same goes for all of the programming info... the best we can do is give rough estimates and confidence levels in cases where we have a specific list of tasks to complete before we can release, but this is more like UVD where we don't know what the outcome will be until the last minute.

    As soon as we get to the point where the remaining issues can be discussed in public, we release
    Thanks for answering.

    Btw, IIRC, you stated some years ago that R&D is trying to disentangle the problematic parts (DRM, etc.) as much as possible from the rest of the ASIC,
    but it will take some generations to take off. Is this something we will profit soon or has this strategy been dropped?

    Comment


    • #62
      Originally posted by entropy View Post
      Btw, IIRC, you stated some years ago that R&D is trying to disentangle the problematic parts (DRM, etc.) as much as possible from the rest of the ASIC, but it will take some generations to take off. Is this something we will profit soon or has this strategy been dropped?
      The strategy has not been dropped, but the HW development pipe is pretty long and we're not redesigning blocks *just* for this.

      I expect the first change will become visible over the next 12-15 months, although I'm not sure we'll be able to tell you what specific changes we made. If all goes well you will see more HW info released and think "finally, what took them so long ?"

      Comment


      • #63
        Originally posted by bridgman View Post
        PM basically works by changing clocks and voltages to make power/performance tradeoffs that match the user's needs.

        For r600 and earlier the driver code set clocks and voltages directly. On most of the more recent hardware generations the driver can still set clocks and voltages directly but each generation has different hardware blocks added which can set those clocks and voltages automatically with guidance from the driver. So far we have not been allowed to release info for those additional HW blocks, although as with UVD we have been working internally to change that. The difference is that we started internal discussions about PM a couple of years ago, concluded that we were not going to get quick approval, and that's why the current PM code was developed.
        I think many people (like me) who say they would like better power management aren't even talking about automatically adjusting power levels to "match the user's needs". It's still that on "low" power level my HD 6550M drains more power than catalyst by default. (Last time I tried "low" it sometimes crashed so I used "mid" since then which seems to be exactly the same but at least appeared to be more stable).

        What I personally think should be the priority in power management is bringing the card down to the minimum power drain possible for the "low" profile.

        Code:
         % sudo su -c "echo low > /sys/class/drm/card0/device/power_profile"
         % cat /sys/kernel/debug/dri/0/radeon_pm_info
        default engine clock: 600000 kHz
        current engine clock: 299970 kHz
        default memory clock: 800000 kHz
        current memory clock: 299950 kHz
        voltage: 900 mV
        PCIE lanes: 16
         % sudo su -c "echo mid > /sys/class/drm/card0/device/power_profile"
         % cat /sys/kernel/debug/dri/0/radeon_pm_info
        default engine clock: 600000 kHz
        current engine clock: 299970 kHz
        default memory clock: 800000 kHz
        current memory clock: 299950 kHz
        voltage: 900 mV
        PCIE lanes: 16
        Last edited by ChrisXY; 05-25-2012, 12:04 PM.

        Comment


        • #64
          Originally posted by ChrisXY View Post
          I think many people (like me) who say they would like better power management aren't even talking about automatically adjusting power levels to "match the user's needs". It's still that on "low" power level my HD 6550M drains more power than catalyst by default. (Last time I tried "low" it sometimes crashed so I used "mid" since then which seems to be exactly the same but at least appeared to be more stable).

          What I personally think should be the priority in power management is bringing the card down to the minimum power drain possible for the "low" profile.

          Code:
           % sudo su -c "echo low > /sys/class/drm/card0/device/power_profile"
           % cat /sys/kernel/debug/dri/0/radeon_pm_info
          default engine clock: 600000 kHz
          current engine clock: 299970 kHz
          default memory clock: 800000 kHz
          current memory clock: 299950 kHz
          voltage: 900 mV
          PCIE lanes: 16
           % sudo su -c "echo mid > /sys/class/drm/card0/device/power_profile"
           % cat /sys/kernel/debug/dri/0/radeon_pm_info
          default engine clock: 600000 kHz
          current engine clock: 299970 kHz
          default memory clock: 800000 kHz
          current memory clock: 299950 kHz
          voltage: 900 mV
          PCIE lanes: 16
          Yeah I suspect there are block on the gpu that fglrx powers off dynamically to get even lower than the min one.

          I'm not sure, if anyone was going to work on power saving I'd recommend the nouveau approach and reverse engineer fglrx rather than talking to AMD, and definitely try not be covered by an NDA.

          While improving the current code might be worth it for a while, its suboptimal in the long term, and reverse engineering fglrx would probably produce a much more useful benefit.

          Dave.

          Comment


          • #65
            @bridgman


            is there still work being done for the UVD ???

            Comment


            • #66
              Originally posted by DanL View Post
              Actually, it was brought up years ago: http://phoronix.com/forums/showthrea...3-Ban-Qaridium
              Watching him debate with bridgman and display mastery of the below techniques is entertaining once you get used to it. Q is just a part of the Phoronix scenery, like the beer references that some people can't stand.

              Ignore List doesn't really work for more advanced trolls, especially those who post at the rate of Q and are skilled at threadjacking.
              well the clue is to call a opponent with dissenting opinions a "Contrarian Troll" is the first step to be the Contrarian Troll LOL

              this is what your "text" includes ...........

              what have you to say in your defense?

              Comment


              • #67
                Originally posted by 89c51 View Post
                @bridgman
                is there still work being done for the UVD ???
                Yes, although we're not at the point where I can say anything more encouraging than before about chances of exposing the HW.

                Comment


                • #68
                  Originally posted by Qaridarium View Post
                  well the clue is to call a opponent with dissenting opinions a "Contrarian Troll" is the first step to be the Contrarian Troll
                  ...
                  Accusing the accusers. When confronted with their trolling, trolls immediately respond that it is the accusers who are trolls.
                  You made my day. Thanks.

                  Comment


                  • #69
                    Just to add some common decency and politeness to this thread: I wish to offer my thanks to bridgman, agd5f, airlie, and everyone else who is working on improving these drivers. If it was not for your hard work we would not have anything to talk about here at all, and everyone should be grateful. I at least appreciate your efforts.

                    Now, was that so hard everyone?

                    Comment


                    • #70
                      Can you share with us _why_ this turns out to be problematic?
                      I think it's obvious for the UVD blocks - but for the PM bits?
                      Originally posted by bridgman View Post
                      Nope. Same goes for all of the programming info...

                      Comment


                      • #71
                        @bridgman
                        is there still work being done for the UVD ???
                        Originally posted by bridgman View Post
                        Yes, although we're not at the point where I can say anything more encouraging than before about chances of exposing the HW.
                        What about the video encoder that the new chips have?

                        I'm not particularly in a hurry to get support for it, I'm just wondering if it's a minefield of patents/lawyers as well, or if you think that would be easier than decoding through UVD.

                        Comment


                        • #72
                          Originally posted by DanL View Post
                          ...


                          You made my day. Thanks.
                          "Laugh over loud"

                          sure no problem I'm always happy if i can give a helping hand.

                          you are the second in this week

                          the other one:
                          droste:"Insulting people and getting personal does _not_ mean you're rhetorically gifted. (You used stratagem 20)"

                          Qaridarium:"if you are right here and i'm just using the "The Art of Being Right" then this is the voucher for it that I can see someone doing the same because the same is the same and a dog recognizes a different dog when he barks. "

                          droste: "stratagem 26, but you got me there ;-) you won this time :-P"

                          full text here: http://phoronix.com/forums/showthrea...ng-Close/page3

                          Comment


                          • #73
                            Originally posted by airlied View Post
                            Yeah I suspect there are block on the gpu that fglrx powers off dynamically to get even lower than the min one.

                            I'm not sure, if anyone was going to work on power saving I'd recommend the nouveau approach and reverse engineer fglrx rather than talking to AMD, and definitely try not be covered by an NDA.

                            While improving the current code might be worth it for a while, its suboptimal in the long term, and reverse engineering fglrx would probably produce a much more useful benefit.

                            Dave.
                            If reverse engineering the FGLRX is more useful than using specs from AMD then the hole support from AMD is a lie?

                            or maybe i didn't understand you here.

                            Comment


                            • #74
                              Originally posted by Qaridarium View Post
                              If reverse engineering the FGLRX is more useful than using specs from AMD then the hole support from AMD is a lie?

                              or maybe i didn't understand you here.
                              yeah you didn't understand because I never said it in a general way. We just know in some cases that fglrx uses the hw in ways that the docs don't/won't cover, e.g. UVD. In most cases this isn't true, and its fine to never RE fglrx, because the docs are fine.

                              So really in most cases I wouldn't dream of RE'ing fglrx since we have good enough docs/access to engineers.

                              Comment


                              • #75
                                Originally posted by bridgman View Post
                                Don't think we were talking about turning UVD off -- I was talking about decoding video with it.
                                Of course I meant "UVD and other unused blocks on the card", but didn't quite phrase that right.

                                Comment

                                Working...
                                X