Announcement

Collapse
No announcement yet.

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

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

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


            • #51
              Originally posted by bridgman View Post
              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.
              May depend on the per operation overhead as well.


              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.
              IME it also depends a lot on the client; with some clients resizing is super-snappy for me with compiz, with others it's sluggish. I suspect some clients do a lot of unnecessary redraws on resizing.


              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.
              Another problem right now is that the EXA core never even calls the driver Composite hooks for gradients (or solid pictures), because so far no driver could handle them.


              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
              Yeah, it could be that easy if the RENDER rasterization rules matched those of hardware / 3D APIs... alas, unfortunately they don't.

              Also, again there are no EXA driver interfaces for trapezoids yet.

              Comment

              Working...
              X