Announcement

Collapse
No announcement yet.

Intel Ivy Bridge: UXA vs. SNA - Updated Benchmarks

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

  • Intel Ivy Bridge: UXA vs. SNA - Updated Benchmarks

    Phoronix: Intel Ivy Bridge: UXA vs. SNA - Updated Benchmarks

    With the testing of the very latest Intel X.Org graphics driver, the SNA 2D acceleration back-end for the Ivy Bridge graphics is now the clear-cut winner for the Linux desktop over using the default UXA back-end...

    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
    I think two simple things would make tests easier to digest:

    1. always show things in a way more is better. For instance, if something is measured in seconds to completion, show it as a frequency (1 / time-to-completion )
    2. Once a battery of tests are performed, each configuration gets a geometric average of all measurements, so you get one global number for each configuration

    Optionally, one could add one final plot where all averages are normalized to the slowest. Tom's hardware show their reviews like that, and it's pretty awesome.

    Back to Intel, I am so glad to see full open source support. My next desktop rig will be Intel (for the first time, ever)

    Cheers!

    Comment


    • #3
      Originally posted by mendieta View Post
      1. always show things in a way more is better. For instance, if something is measured in seconds to completion, show it as a frequency (1 / time-to-completion )
      Agreed, that would make reading easier.

      Originally posted by mendieta View Post
      Back to Intel, I am so glad to see full open source support. My next desktop rig will be Intel (for the first time, ever)
      Same here, just too bad that there are only integrated variants of this great product :/ .

      Comment


      • #4
        I would be interested in a benchmark comparing SNA and the GLAMOR library. I always wondered how much of a benefit doing 2D over opengl brings to the table as opposed to the techniques used by SNA.

        Comment


        • #5
          Originally posted by jrdls View Post
          I would be interested in a benchmark comparing SNA and the GLAMOR library. I always wondered how much of a benefit doing 2D over opengl brings to the table as opposed to the techniques used by SNA.
          Very little. Last I checked, GLAMOR was slower than UXA. It's meant to be hardware-independent, and it's better than whatever people used on radeon before, but it's not particularly aimed at better performance.

          Comment


          • #6
            Originally posted by GreatEmerald View Post
            Very little. Last I checked, GLAMOR was slower than UXA. It's meant to be hardware-independent, and it's better than whatever people used on radeon before, but it's not particularly aimed at better performance.
            Give it a little of time. AMD folks are now busy with bringing radeonSI up to pair with r600g. GLAMOUR will stay with their driver for quite a long time, they will tweak it eventually.

            Comment


            • #7
              Originally posted by Rexilion View Post
              Agreed, that would make reading easier.
              Same here, just too bad that there are only integrated variants of this great product :/ .
              I do wonder what a separate intel GPU freed from the space and heat concerns of a CPU die could do. (Compete with a three year old mid-range nvidia card, I guess - but with much nicer drivers.)

              Moving it off to PCIe instead of on-die would require changing some assumptions in the driver, though; especially GPGPU would have to readjust. Sharing the memory controller with the CPU is so much nicer than having to shuffle things over a comparatively slow PCIe connection, but OTOH you can use different RAM tech (GDDR5 has higher latency but more bandwidth than DDR3, I believe?)

              Comment


              • #8
                Originally posted by mendieta View Post
                1. always show things in a way more is better. For instance, if something is measured in seconds to completion, show it as a frequency (1 / time-to-completion )
                Showing completion time as frequency would be really annoying. Frequency tends to mean that something is repeating, which is not what's going on in the tests here.

                Comment


                • #9
                  Originally posted by kigurai View Post
                  Showing completion time as frequency would be really annoying. Frequency tends to mean that something is repeating, which is not what's going on in the tests here.
                  Agreed, but that does not make frequency inferior as a method to display everything as 'more is better'.

                  Comment


                  • #10
                    Originally posted by kigurai View Post
                    Showing completion time as frequency would be really annoying. Frequency tends to mean that something is repeating, which is not what's going on in the tests here.
                    How about normalizing it so the fastest (or slowest, or alphabetically first, or whatever) is at 1, and the others shows how much faster/slower they are (defined e.g. as "how many times could they do this in the time the reference needed to do it once")? It should be fairly easy to read - "2" means it is twice as fast/uses half the time.

                    Alternatively each test could have a canonical reference (sort of like 1 VAX MIPS being defined as the benchmark result of a VAX 11/780), but I'm not sure if that would be useful or messy.

                    Comment

                    Working...
                    X