Page 5 of 6 FirstFirst ... 3456 LastLast
Results 41 to 50 of 51

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

  1. #41
    Join Date
    Aug 2008
    Location
    Tokyo, Japan
    Posts
    37

    Default

    Quote 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).

  2. #42
    Join Date
    Jan 2008
    Posts
    206

    Default

    Quote 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

  3. #43
    Join Date
    Aug 2008
    Location
    Tokyo, Japan
    Posts
    37

    Default

    Quote 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.

  4. #44
    Join Date
    Jan 2008
    Posts
    206

    Default

    Quote 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

  5. #45
    Join Date
    Jan 2009
    Posts
    10

    Default

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

    ech0s7

  6. #46

    Default

    Quote 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

  7. #47
    Join Date
    Jan 2008
    Posts
    206

    Default

    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.

  8. #48
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    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 at 12:10 PM.

  9. #49
    Join Date
    Jan 2008
    Posts
    206

    Default

    Quote 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

  10. #50
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    Quote 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.

    Quote 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.

    Quote 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 at 01:27 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •