Results 1 to 10 of 22

Thread: SNA Sandy Bridge Is Quick To Beat UXA Too

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    15,091

    Default SNA Sandy Bridge Is Quick To Beat UXA Too

    Phoronix: SNA Sandy Bridge Is Quick To Beat UXA Too

    There were huge SNA performance gains on Ironlake over UXA in the most recent testing that happened last night. Curious to see how the SNA 2D acceleration architecture is working for Sandy Bridge graphics hardware, for which it was originally intended, here are some new benchmarks...

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

  2. #2
    Join Date
    Sep 2010
    Posts
    701

    Default

    GtkPerf seam to favour UXA on Gen5/6. Bug or feature ?

  3. #3
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    1,052

    Default

    Ivy Bridge here, but perhaps it's similar enough.

    Quote Originally Posted by przemoli View Post
    GtkPerf seam to favour UXA on Gen5/6. Bug or feature ?
    With git master and sna gtkperf was 3.x seconds two days ago (before http://www.phoronix.com/scan.php?pag...tem&px=MTMxMjU), but now it's 6+ seconds with kwin opengl compositing. It's probably only temporary.

  4. #4

    Default

    Quote Originally Posted by ChrisXY View Post
    Ivy Bridge here, but perhaps it's similar enough.


    With git master and sna gtkperf was 3.x seconds two days ago (before http://www.phoronix.com/scan.php?pag...tem&px=MTMxMjU), but now it's 6+ seconds with kwin opengl compositing. It's probably only temporary.
    Really? That's quite unexpected, and hopefully a clue as to what is going on there. In the past, I've found that those two particular gtkperf subtests are ratelimited by the gtkperf process itself and that process was being inexplicably throttled - but I have never encountered an effect as severe as reported earlier for ILK. Again, hopefully the magnified effect will make it easier to spot the cause.

  5. #5
    Join Date
    Jan 2009
    Posts
    1,435

    Default

    I'm curious why QT has been affected less than cairo with the transition.
    I would imagine that ickle has a nice test suite and uses that a basis (the test suite being heavy with cairo), perhaps, along with general architectural improvements. However, I wonder if the qt 2d library (sorry, I forgot what it's called) has been designed to be less sensitive to driver issues (i.e., targets the minimum features one should expect from any driver). Since qT has a cairo backend (perhaps not well maintained, but should still be present), I wonder how that could fare.
    Something I just noticed is that gtk doesn't seem to have a testing suite. There looks like there is an abandoned one in sourceforge (that is the one michael uses), but not an official one. How sad is that? This is very similar to the general problems with gnome testing (although that is at least being addressed somewhat with complete unit testing and sanity checks). I suppose the problem is lack of manpower and interest. Similar to the documentation crisis
    Last edited by liam; 02-27-2013 at 02:07 PM.

  6. #6
    Join Date
    Sep 2012
    Posts
    358

    Default

    Quote Originally Posted by liam View Post
    I'm curious why QT has been affected less than cairo with the transition.
    I would imagine that ickle has a nice test suite and uses that a basis (the test suite being heavy with cairo), perhaps, along with general architectural improvements. However, I wonder if the qt 2d library (sorry, I forgot what it's called) has been designed to be less sensitive to driver issues (i.e., targets the minimum features one should expect from any driver). Since qT has a cairo backend (perhaps not well maintained, but should still be present), I wonder how that could fare.
    Qt doesn't have cairo backend, but cairo has Qt backend.
    Qt4 has native (X11), raster and opengl backend.
    Qt5 has only raster backend.

  7. #7
    Join Date
    Jan 2009
    Posts
    1,435

    Default

    Quote Originally Posted by JS987 View Post
    Qt doesn't have cairo backend, but cairo has Qt backend.
    Qt4 has native (X11), raster and opengl backend.
    Qt5 has only raster backend.
    Gah! You're right. I reversed ends
    Are you sure qt5 dropped the opengl backend?

  8. #8
    Join Date
    Sep 2012
    Posts
    358

    Default

    Quote Originally Posted by liam View Post
    Gah! You're right. I reversed ends
    Are you sure qt5 dropped the opengl backend?
    Qt5 has limited opengl backend, but QPainter can't use it.
    http://blog.qt.digia.com/blog/2012/04/03/qt-5-alpha/
    The QWidget based stack continues to work as in Qt 4.x, based on QPainter. QPainter does however support less backends than it used to. It is now limited to SW rasterization (Raster backend) for drawing to the screen, pixmaps and images, an OpenGL backend for GL surfaces and a backend for PDF generation and printing. The platform dependent backends using X11 or CoreGraphics are gone.

  9. #9
    Join Date
    Jan 2009
    Posts
    1,435

    Default

    Quote Originally Posted by JS987 View Post
    Qt5 has limited opengl backend, but QPainter can't use it.
    http://blog.qt.digia.com/blog/2012/04/03/qt-5-alpha/
    What's going on? Are they having development issues? Dropping those backends, like Coregraphics, seems like it would make it harder to target specific platforms natively.

Posting Permissions

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