Page 1 of 2 12 LastLast
Results 1 to 10 of 20

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

  1. #1
    Join Date
    Jan 2007
    Posts
    13,429

    Default 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...

    http://www.phoronix.com/vr.php?view=MTM4MTI

  2. #2
    Join Date
    Apr 2009
    Posts
    491

    Default

    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!

  3. #3
    Join Date
    Dec 2012
    Posts
    404

    Default

    Quote 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.

    Quote 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 :/ .

  4. #4
    Join Date
    Jun 2012
    Posts
    15

    Default

    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.

  5. #5
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,399

    Default

    Quote 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.

  6. #6
    Join Date
    Sep 2010
    Posts
    564

    Default

    Quote 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.

  7. #7
    Join Date
    Oct 2010
    Posts
    85

    Default

    Quote 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?)

  8. #8
    Join Date
    Nov 2012
    Posts
    192

    Default

    Quote 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.

  9. #9
    Join Date
    Dec 2012
    Posts
    404

    Default

    Quote 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'.

  10. #10
    Join Date
    Oct 2010
    Posts
    85

    Default

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •