Announcement

Collapse
No announcement yet.

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

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

  • phoronix
    started a topic AMD Catalyst vs. X.Org Radeon Driver 2D Performance

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

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

    One of the common complaints about the ATI Catalyst Linux driver is slow 2D performance, but is this really the case? Does AMD's binary-only Linux driver have 2D performance issues that could actually make it run slower than the open-source driver developed by the X.Org community through specifications released by AMD? In this article we have run a total of 28 benchmarks looking squarely at the 2D performance between the Catalyst (fglrx) driver and the xf86-video-ati (Radeon) drivers on Ubuntu Linux.

    http://www.phoronix.com/vr.php?view=13388

  • MrCooper
    replied
    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.

    Leave a comment:


  • bridgman
    replied
    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, 02:27 AM.

    Leave a comment:


  • Linuxhippy
    replied
    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

    Leave a comment:


  • bridgman
    replied
    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, 01:10 PM.

    Leave a comment:


  • Linuxhippy
    replied
    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.

    Leave a comment:


  • Michael
    replied
    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

    Leave a comment:


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

    ech0s7

    Leave a comment:


  • Linuxhippy
    replied
    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

    Leave a comment:


  • MrCooper
    replied
    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.

    Leave a comment:

Working...
X