Announcement

Collapse
No announcement yet.

SNA Continues To Be Far Better Than UXA, GLAMOR

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

  • SNA Continues To Be Far Better Than UXA, GLAMOR

    Phoronix: SNA Continues To Be Far Better Than UXA, GLAMOR

    Intel's Chris Wilson has shared new performance data of UXA vs. GLAMOR vs. his prized SNA acceleration architecture for Intel 2D acceleration on the Linux desktop. To no incredible surprise, SNA is far better than UXA and GLAMOR for an Intel Iris Pro 5200 graphics processor...

    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
    Slow

    Why is GLAMOR so slow? Lack of optimization?

    Comment


    • #3
      Originally posted by wpoely86 View Post
      Why is GLAMOR so slow? Lack of optimization?
      Because it runs on top of OpenGL and OpenGL is not meant to decode video. It's a hack by AMD because they don't want to expose the real thing(TM) in their GPUs because of patent issues.
      Last edited by wargames; 01 October 2013, 01:00 PM.

      Comment


      • #4
        Originally posted by wargames View Post
        Because it runs on top of OpenGL and OpenGL is not meant to decode video. It's a hack by AMD because they don't want to expose the real thing(TM) in their GPUs because of patent issues.
        Expect that is used for cairo-image here. Something which OpenGL should be able to do very well?

        Comment


        • #5
          Wayland will be big performance regression if Wayland applications won't be able to use SNA. I guess it is intentional to force people to buy faster computers.

          Comment


          • #6
            Originally posted by JS987 View Post
            Wayland will be big performance regression if Wayland applications won't be able to use SNA. I guess it is intentional to force people to buy faster computers.
            SNA-enabled driver lives in Xorg and is optimized around the X protocol, I think it's mostly XRender, maybe more. It runs in the server process. The performance might not directly translate to client-side rendering, but still probably be fast.
            For now, X apps running on wayland will use it on Intel hardware because Xorg intel driver is Wayland-aware. Wayland will benefit from it when SNA stuff is ported and tuned to be e.g. a Cairo backend (insert your own graphics library). I think something like that will come as Wayland gets its share of desktops (and, since it's not limited only to what can pass through XRender, even more stuff could be accelerated).

            Of course, deep device-specific optimization like this is of course faster than hw-independent approach like GLAMOR, unless someone figures out how to do something similar in OpenGL (designing specific extensions etc.).

            At least this is my understanding. X/Wayland/driver devs certainly know more about this stuff.

            Comment


            • #7
              Originally posted by wargames View Post
              It's a hack by AMD because they don't want to expose the real thing(TM) in their GPUs because of patent issues.
              Hack by AMD? You do realize GLAMOR is an Intel project?

              Comment


              • #8
                Originally posted by JS987 View Post
                Wayland will be big performance regression if Wayland applications won't be able to use SNA. I guess it is intentional to force people to buy faster computers.
                Ideally, only a few applications would use XWayland on a Wayland powered desktop.

                Since you don't rely on X compositing for moving windows, ... performance of the DDX matters less.

                For games, the performance to copy buffers by the DDX is important. I've not compared copy performance of SNA vs Glamor, but since we manipulate GL buffers, I assume Glamor shouldn't perform worse.

                Last discussions were about having only one Wayland DDX and integrate XWayland code to the DDX (and not in X). That way the DDX can do clever things around the buffers sent to Wayland, and avoid as much as possible copies and tearings.
                Last edited by mannerov; 01 October 2013, 03:49 PM. Reason: grammar mistake

                Comment


                • #9
                  Originally posted by fuzz View Post
                  Hack by AMD? You do realize GLAMOR is an Intel project?
                  Clearly he doesn't, but I bet his ignorance is laughing at him in chorus.

                  Comment


                  • #10
                    Originally posted by Marc Driftmeyer View Post
                    Clearly he doesn't, but I bet his ignorance is laughing at him in chorus.
                    LOL, I was absolutely wrong!

                    Comment

                    Working...
                    X