Announcement

Collapse
No announcement yet.

Ubuntu 12.10 Looks To Use Intel SNA Acceleration

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

  • Ubuntu 12.10 Looks To Use Intel SNA Acceleration

    Phoronix: Ubuntu 12.10 Looks To Use Intel SNA Acceleration

    Ubuntu developers are looking at enabling support for Intel SNA acceleration within the open-source graphics driver for the Ubuntu 12.10 release...

    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 know SNA stands for Sandy Bridge Architecture.

    But could it be used with Radeon and Nouveau too?

    Comment


    • #3
      Typo, just not -> not just

      Comment


      • #4
        Originally posted by uid313 View Post
        I know SNA stands for Sandy Bridge Architecture.

        But could it be used with Radeon and Nouveau too?
        To cut a long story short: no, what is required most for the EXA drivers is an investment of engineering time to ensure that the drivers do not fallback (gradient shaders, trapezoid shders, handling over-sized destinations and sources, can mix core drawing operations with render, etc). To do so the EXA midlayer needs significant restructuring, in my opinion - I could not do the fallback prevention from within the UXA/EXA private interface and so tried with SNA to create a higher level private interface with the core code being a set of helpers for pixmap management and for exploiting alternative functional units within the hardware to avoid fallbacks when the 3D pipeline could not handle the render operation. (Though, from a purists point of view, there is still far too much midlayer in SNA.) The majority of the code is then written with initimate knowledge of both the Intel hardware and kernel driver, that code is itself not transferrable to other drivers, and given the limitations of the hardware it is likely that the other drivers would want to take a completely different approach for their GPUs. Once again, it is an issue of resources - there simply aren't enough developers working on the drivers and those that are are busy with OpenGL, which leads to interim solutions like glamor or st/xa where you try to write a common acceleration block which is then translated by the existing 3D drivers. Which still leaves you with the challenge of how to extend those interfaces to efficiently handle operations that are not directly implementable in the GL pipeline and for optimising those pipelines to handle the immediate mode rendering of X (which is a completely different kettle of fish than your typical game).

        Comment


        • #5
          SNA is not some magical invention of Intel, it's just bringing to the Intel driver the EXACT same way of doing 2D acceleration that radeon (at least r600 and newer, r300 still uses the dedicated 2D hardware) and noveau use.

          Comment


          • #6
            Originally posted by Ansla View Post
            SNA is not some magical invention of Intel, it's just bringing to the Intel driver the EXACT same way of doing 2D acceleration that radeon (at least r600 and newer, r300 still uses the dedicated 2D hardware) and noveau use.
            Nope. UXA is the replica of doing 2D acceleration the same as radeon and nouveau, since it is just EXA with the pixmap migration taken out. I took a different approach, started from the shadow buffer and added cairo-drm, trying to build the foundations of a driver that played to the strengths of the hardware.

            Comment


            • #7
              I was referring to the fact that SNA uses the 3D engine for the 2D acceleration instead of the dedicated 2D engine. From what I know this was the big difference between SNA and UXA. You say there are other features of it that would make sense for the rest of the drivers?

              Comment


              • #8
                Originally posted by Ansla View Post
                I was referring to the fact that SNA uses the 3D engine for the 2D acceleration instead of the dedicated 2D engine. From what I know this was the big difference between SNA and UXA. You say there are other features of it that would make sense for the rest of the drivers?
                That's almost exactly backwards. The big thing with the transition from XAA to EXA and then UXA was the removal of the acceleration of core drawing commands using the BLT. The BLT is the dedicated 2D unit that still exists on IvyBridge for the purpose of bitwise transfers and is still much faster and more importantly lower power and lower latency than the 3D engine. However using the BLT has hidden costs which became a major performance penalty on SandyBridge and the key element of SNA is that it incorporates that into its state tracker (ok, having a state tracker is another major difference from UXA!) and has routines for doing everything on either engine where possible and uses whichever the heuristics suggest is most appropriate. This is contrast to nouveau and radeon which bail to CPU rendering when it has no easy method for performing the operation on the 3D hardware. That is just a lack of development. If the motivation was there, most 3D pipelines could implement enough of XAA to be useful even on a modern desktop, and Render fallbacks could be virtually eliminated as well.

                One of the areas where I'm looking for further development for SNA is to extend the Render protocol to improve the offload of the immediate mode path rendering (i.e. Cairo and other users of Render), along with any future directions toward retained paths. nvidia have expressed a similar interest since they already have a path offload engine inside their libGL (NV_path extension) and would like to utilise that from their 2D drivers as well. That would be beneficial to EXA if they also extended their interfaces to handle paths, which is likely to have knock-on effects with them finally implementing some form of trapezoidal acceleration...

                Comment


                • #9
                  I just saw this article and enabled xorg-edgers in precise to have a look, but it doesn't look like SNA was enabled.

                  xserver-xorg-video-intel (2:2.19.0+git20120613.0db789e1-0ubuntu0sarvatt~precise) precise; urgency=low

                  * Checkout from git 20120613 (master branch) up to commit
                  0db789e180b6b01fb8aff547879387058f52a0b9
                  * Only added debian/ tree from origin/ubuntu
                  * hook: Drop 101_copy-fb.patch (testing)
                  * Note: SNA is now disabled due to long-standing incompatibilities
                  with unity.
                  * hooks: build-dep on libxcb-util0-dev | libxcb-aux0-dev to ease
                  backporting.

                  -- Robert Hooker <[email protected]> Wed, 13 Jun 2012 11:29:52 -0400
                  OTOH that changelog message seems to have been reused unchanged since at least May, so I guess I'll have to try it and see if SNA is mentioned in the startup logs: https://launchpad.net/~xorg-edgers/+...filter=quantal

                  Comment


                  • #10
                    Now (with a newer xorg-edgers) I can enable it:

                    Code:
                    cat /etc/X11/xorg.conf.d/20-sna.conf 
                    Section "Device"
                    # Identifier not significant
                        Identifier "Integrated intel graphics"
                        Driver "intel"
                        Option "AccelMethod" "SNA"
                    EndSection

                    Comment

                    Working...
                    X