Announcement

Collapse
No announcement yet.

AMD Catalyst vs. X.Org Radeon Driver 2D Performance

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

  • #41
    Originally posted by Linuxhippy View Post
    In fact it was often suggested to merge UXA back into EXA again, to not have so much duplicated code.
    There's nothing to merge back really; UXA just deletes the code from the EXA core which would be inactive anyway if the EXA driver allocated pixmap memory itself (which has been possibe since before UXA).

    Comment


    • #42
      Originally posted by MrCooper View Post
      There's nothing to merge back really; UXA just deletes the code from the EXA core which would be inactive anyway if the EXA driver allocated pixmap memory itself (which has been possibe since before UXA).
      So UXA consists of a lot of EXA code minus the whole dirty region handling and other stuff. What I ment with "merge" is that EXA should be made more flexible, making all the unescessary stuff optional.

      I wonder, was the new "xf86-video-radeonhd:r6xx-r7xx-support" branch used for the benchmark? Because only this supports RENDER accaleration, however its rather untested unstable and incomplete.

      - Clemens

      Comment


      • #43
        Originally posted by Linuxhippy View Post
        What I ment with "merge" is that EXA should be made more flexible, making all the unescessary stuff optional.
        But it already is. There has been some talk about using function wrappers rather than inline branches, but I haven't seen any patches yet.

        There are also academic problems with the EXA driver interface for pixmap memory allocation, but I think it would have been better to fix those than to duplicate the code...

        I wonder, was the new "xf86-video-radeonhd:r6xx-r7xx-support" branch used for the benchmark? Because only this supports RENDER accaleration, [...]
        The X1800XT mentioned in the article is an R520, which has been well supported for a while.

        Comment


        • #44
          Originally posted by MrCooper View Post
          The X1800XT mentioned in the article is an R520, which has been well supported for a while.
          Ah right, I mixed that up with the R700 performance comparison.
          From what I understand that comparison compares how fast the drivers can up/download as well as pixman performance

          - Clemens

          Comment


          • #45
            if you would see my comparison test, this is the link: http://www.ech0s7.netsons.org/index.php/archives/31

            ech0s7

            Comment


            • #46
              Originally posted by ech0s7 View Post
              if you would see my comparison test, this is the link: http://www.ech0s7.netsons.org/index.php/archives/31

              ech0s7
              Should have used the Phoronix Test Suite! :P
              Michael Larabel
              http://www.michaellarabel.com/

              Comment


              • #47
                I am quite interested how RadeonHD will do once their r660-r700 accaleration branch is ready.
                For now both Catalyst as well as RadeonHD are mostly software-only on R600+.

                @Michael: Any plans to do a 2D comparison between NVidia / ATI / Intel?
                By the way some JXRenderMark tests are not really real-world, so I recommend limiting to: rects, rectscomposition, putcomposition, all the different blits, texturepaint and gradientpaint.

                Comment


                • #48
                  2D on the open source drivers will kick ass. That's a technical term

                  Seriously, the only thing we are not sure about yet is copying to an overlapping area with the 3D engine. The old 2D engine was very "sequential" in its processing so you always knew the exact sequence of reads and writes (that really matters when copying with overlapping source and destination areas), but the 3D engine does so much in parallel that right now we are forcing line-at-a-time copies (which are slow) to ensure the scroll operation does not over-write content accidentally.

                  A number of potential optimizations have already been identified (most of them are pretty obvious), but I don't know if we will be able to match the performance of the old 2D acceleration block in all scenarios.

                  Copying to an overlapping area is primarily an issue when scrolling without a compositor, so hopefully it will become a non-issue for real-world experience as the use of compositing desktop managers become more common. I don't know how much this particular operation is reflected in benchmarks, however.
                  Last edited by bridgman; 01-30-2009, 12:10 PM.

                  Comment


                  • #49
                    Originally posted by bridgman View Post
                    2D on the open source drivers will kick ass. That's a technical term
                    Yes, seems to become a really cool EXA driver. Hopefully the improvements will find their way into Catalyst.

                    Seriously, the only thing we are not sure about yet is copying to an overlapping area with the 3D engine.
                    Whats about allocating a temporary copy-pixmap?

                    Copying to an overlapping area is primarily an issue when scrolling without a compositor, so hopefull as the use of compositing desktop managers become more common. I don't know how much this particular operation is reflected in benchmarks, however.y it will become a non-issue for real-world experience
                    Well, window-resize performance is quite bad when an composition manager is enabled (both, xrender or opengl based), thats the main reason I don't use one.


                    Do you think there is any chance for accalerated gradient support?
                    Both, gradients as well as trapezoids for geometry are heavily used in modern UI toolkits/themes, but both currently cause fallbacks and migration/copying all over the place.
                    I guess trapezoids are quite hard to implement, but gradients should be really simple as shaders.

                    Would be great to see radeonhd implementing features nobody else has, instead of celebrate reaching a state where intel has been two years ago

                    - Clemens

                    Comment


                    • #50
                      Originally posted by Linuxhippy View Post
                      Whats about allocating a temporary copy-pixmap?
                      I think we'll end up having to do that when the offset between src and dest is very small (eg a few lines). For larger offsets, I *think* it would be faster to copy N lines at a time.

                      Originally posted by Linuxhippy View Post
                      Well, window-resize performance is quite bad when an composition manager is enabled (both, xrender or opengl based), thats the main reason I don't use one.
                      Yeah, I'm not sure we clearly understand where the bottleneck is on resize. I'm starting to think that it might be the compositing loop redrawing the new window to the front buffer, not the driver actually resizing the window. I find resizing to be un-noticeably fast on my system but I'm running an RV570 and a quad-core CPU; need to re-test on some slower hardware.

                      Originally posted by Linuxhippy View Post
                      Do you think there is any chance for accalerated gradient support? Both, gradients as well as trapezoids for geometry are heavily used in modern UI toolkits/themes, but both currently cause fallbacks and migration/copying all over the place. I guess trapezoids are quite hard to implement, but gradients should be really simple as shaders.
                      I need to learn more about gradients; right now I don't understand why we even need shaders. It seems like we should be able to draw triangles and let the interpolators do all the work; maybe there's an edge matching problem or something. All I can say right now is that it seems like we should be able to do something, but I haven't talked to the devs about the problems yet.

                      Trapezoids seem like they should be easy to break down to triangles as well and I know both hardware and software folks have worked very hard to make all the edges match in OpenGL; again, this is spoken with the clarity of ignorance
                      Last edited by bridgman; 01-31-2009, 01:27 AM.

                      Comment

                      Working...
                      X