Announcement

Collapse
No announcement yet.

SNA Sandy Bridge Is Quick To Beat UXA Too

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

  • 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
    GtkPerf seam to favour UXA on Gen5/6. Bug or feature ?

    Comment


    • #3
      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, 02:07 PM.

      Comment


      • #4
        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.

        Comment


        • #5
          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?

          Comment


          • #6
            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.

            Comment


            • #7
              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.

              Comment


              • #8
                Originally posted by liam View Post
                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.
                I don't think you're supposed to use QPainter at all anymore in Qt5. They want you to use QML on top of an OpenGL scene graph instead.

                Comment


                • #9
                  Originally posted by smitty3268 View Post
                  I don't think you're supposed to use QPainter at all anymore in Qt5. They want you to use QML on top of an OpenGL scene graph instead.
                  Exactly. Morons from Nokia/Digia/whatever want force QML crap after crippling Widgets.

                  Comment


                  • #10
                    Originally posted by JS987 View Post
                    Exactly. Morons from Nokia/Digia/whatever want force QML crap after crippling Widgets.
                    "QML Crap" ? Its even easier to create user-interfaces, they automatically scale to smaller displays, you can do everything you could with QtWidgets, its automatically hardware accelerated, platform independent because its written in javascript, and carries ZERO legacy cruft.

                    Comment


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

                      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.

                      Comment


                      • #12
                        Originally posted by Ericg View Post
                        "QML Crap" ? Its even easier to create user-interfaces, they automatically scale to smaller displays, you can do everything you could with QtWidgets, its automatically hardware accelerated, platform independent because its written in javascript, and carries ZERO legacy cruft.
                        QML is optimized for small touch screens, not for desktop applications.
                        It isn't hard to create GUI for desktop application in Qt Designer.
                        Qt4 and GTK are also hardware accelerated.
                        Javascript is one of worst programming languages.
                        It isn't possible to write QML applications in C++11, which is best programming language for desktop applications.

                        Comment


                        • #13
                          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.

                          Comment


                          • #14
                            Originally posted by JS987 View Post
                            It isn't hard to create GUI for desktop application in Qt Designer.
                            Javascript is one of worst programming languages.
                            It isn't possible to write QML applications in C++11, which is best programming language for desktop applications.
                            Really? I assumed you could just use the Designer to auto-generate the QML side of things for the UI, and stick in whatever C++ you wanted.

                            Javascript is a great scripting language, but i agree it's not what you should be coding application logic in. It seems ideal for scripting UI's though.

                            Qt4 and GTK are also hardware accelerated.
                            Qt4's "hardware acceleration" was pretty infamous for being deceleration, at least on Linux.

                            Remember all the stuff about how you could force apps to use the raster backend to speed things up? And on Windows, they always used the raster backend. I don't know about OSX.
                            Last edited by smitty3268; 02-27-2013, 09:29 PM.

                            Comment


                            • #15
                              Originally posted by JS987 View Post
                              QML is optimized for small touch screens, not for desktop applications.
                              It isn't hard to create GUI for desktop application in Qt Designer.
                              Qt4 and GTK are also hardware accelerated.
                              Javascript is one of worst programming languages.
                              It isn't possible to write QML applications in C++11, which is best programming language for desktop applications.
                              Its optimized for anything. You can have them be really complicated and big for desktop apps, or really minimal for mobile apps.

                              Its not HARD, youre right. Its just easier in QML. Literally like 10 lines of code.

                              Qt4 and GTK are HORRIBLY accelerated, very inconsistent cuz of legacy code paths

                              Javascript is a fine language for really... its also platform agnostic, which is a keypart for QML's work (availability to mobile, on platforms OTHER than the one it was dev'ed on.)

                              You can use C++ with QML, its just not the preferred language. But you can do. QML's backends are all C++ based, you just dont normally interact with those.

                              Comment

                              Working...
                              X