Announcement

Collapse
No announcement yet.

The Performance-Per-Watt, Efficiency Of GPUs On Open-Source Drivers

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

  • #11
    Originally posted by Calinou View Post
    Interesting benchmark.

    How about a comparison with the proprietary drivers (probably just to cry a little)?
    As said already, the proprietary tests are coming in later articles.
    Michael Larabel
    http://www.michaellarabel.com/

    Comment


    • #12
      Originally posted by droidhacker View Post
      dpm won't make much difference when your objective is to test the "full out" performance, since it will automatically scale up to full power.
      I wouldn't be so sure about this. DPM also uses power gating or clock gating to power down blocks that might not be used by typical graphics loads, or which are not fully loaded all the time. In addition, DPM also is used for adaptive clocking (powertune and turbo modes). Maybe some of the AMD devs can comment.

      Comment


      • #13
        Originally posted by brent View Post
        I wouldn't be so sure about this. DPM also uses power gating or clock gating to power down blocks that might not be used by typical graphics loads, or which are not fully loaded all the time. In addition, DPM also is used for adaptive clocking (powertune and turbo modes). Maybe some of the AMD devs can comment.
        Also "as fast as the driver can feed the hardware with commands, geometry and textures" isn't necessarily the same as "as fast as the hardware can run", although for 260X there probably isn't a huge difference.

        Comment


        • #14
          Originally posted by MannerMan View Post
          True that. Guess idle power-usage would be more interesting with/without DPM.
          i think that would be why CPU workload was included. however... i MIGHT be interesting to have everything in one graph, like with columns of different thickness overlaying or whatever having different colours like

          ____________________
          ============-----|
          =======--------------|
          ___________________ |

          _______________
          ========-----|
          ====------------|
          ______________ |




          so one can see many results to compare and to see total and relative stuff at once (like fps - thick bar - and CPU usage and power consumption - smaller bars) - while consumton per frame would be the most important.
          it would very much show overhead too. so one could see the relation of these too. throughout the drivers GPUs and maybe different systems too.

          i wanted to to have then overlayed with colours anyway... just a possibility.
          Last edited by jakubo; 06-05-2014, 02:09 PM.

          Comment


          • #15
            wth... that not what i was referring to..?!
            i meant that the GPU power consumption would be vaguely described by the total consumption - cpu consumption (workload)

            Comment


            • #16
              Looks like r600 still has the edge in raw power

              That Radeon HD 6770 was defeated only by 3 larger GCN cards, yet was middle of the road for loaded power use and idled as low as most of the discrete cards. The highest performance in the entire test was a larger r600 card, the HD6870. Given how good the RadeonSI driver has become when the right firmware is used, I wonder if r600 is just plain a better architecture for how Mesa as a whole works. This tells me to sit on my HD6750 unless Kdenlive comes out with a version of the new GPU-accelerated Movit version that supports using hardware encoding for raw speed.

              Comment


              • #17
                Originally posted by Luke View Post
                That Radeon HD 6770 was defeated only by 3 larger GCN cards, yet was middle of the road for loaded power use and idled as low as most of the discrete cards. The highest performance in the entire test was a larger r600 card, the HD6870. Given how good the RadeonSI driver has become when the right firmware is used, I wonder if r600 is just plain a better architecture for how Mesa as a whole works. This tells me to sit on my HD6750 unless Kdenlive comes out with a version of the new GPU-accelerated Movit version that supports using hardware encoding for raw speed.
                I think there are a couple of messages here, but none of them are "r600 is a better architecture for Mesa" AFAIK:

                1. Shader compilers take a long time to optimize, and when you change shader architecture as drastically as we did between VLIW and GCN you're pretty much starting from scratch - this gives the later VLIW parts a chance to shine for a while

                2. The nature of the other remaining optimization opportunities (primarily making best use of available memory & bandwidth) is going to favor mid-range parts, since both low-end and high-end parts tend to be relatively more memory-limited

                3. Things work better when DPM is enabled

                Comment


                • #18
                  Originally posted by bridgman View Post
                  I think there are a couple of messages here, but none of them are "r600 is a better architecture for Mesa" AFAIK:

                  1. Shader compilers take a long time to optimize, and when you change shader architecture as drastically as we did between VLIW and GCN you're pretty much starting from scratch - this gives the later VLIW parts a chance to shine for a while

                  2. The nature of the other remaining optimization opportunities (primarily making best use of available memory & bandwidth) is going to favor mid-range parts, since both low-end and high-end parts tend to be relatively more memory-limited

                  3. Things work better when DPM is enabled
                  Also LLVM sucks.

                  Comment


                  • #19
                    Nice roundup, Michael, though including the new firmware for the 260 would've been nice.
                    Can we still expect to see article about the power draw of your tegra k1 board?

                    Comment


                    • #20
                      Originally posted by liam View Post
                      Nice roundup, Michael, though including the new firmware for the 260 would've been nice.
                      Can we still expect to see article about the power draw of your tegra k1 board?
                      Yes, that's still coming but I only have one WattsUp USB meter and it's been busy now for the past ~2 weeks with this graphics card testing (still doing the proprietary driver tests. etc).
                      Michael Larabel
                      http://www.michaellarabel.com/

                      Comment

                      Working...
                      X