Page 1 of 2 12 LastLast
Results 1 to 10 of 35

Thread: Radeon Gardenshed DRM + Gallium3D Benchmarks

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    14,225

    Default Radeon Gardenshed DRM + Gallium3D Benchmarks

    Phoronix: Radeon Gardenshed DRM + Gallium3D Benchmarks

    It has been about a month since we last delivered ATI/AMD Radeon Linux benchmarks comparing the performance of the open-source driver against the high-performance proprietary driver. Since that point there's been various improvements to the Mesa/Gallium3D driver and there's also been the merge of the latest Radeon DRM code for the next kernel, which will likely be called the Linux 3.0 kernel, but in the DRM pull request was referred to as Gardenshed. Here are these benchmarks on several different Radeon graphics cards.

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

  2. #2
    Join Date
    Feb 2011
    Posts
    55

    Default

    Just a thought, but wouldn't a comparative of Gallium r600 at 1 month intervals (ie compare todays gallium with last month's, march's ...) be far more interesting than this "Oh, one month on, we still haven't closed that order of magnitude gap....."

    David

  3. #3
    Join Date
    Aug 2008
    Posts
    219

    Default

    ^^ Or how about a graph of geometric means over time to get an overall feel of how open source and proprietary graphics drivers are progressing?

  4. #4
    Join Date
    Nov 2009
    Posts
    12

    Default

    looks like there's some serious bottlenecks... fps hardly drops between a low and a high resolution... but catalyst reacts as supposed, there's a real difference when you higher the resolution
    Does anybody have some clues about the features needed to unleash the power of those cards ? I mean, even if the performances was 50% lower than the catalyst ones and you can observe the drop of fps between resolution, you could say that everything is in order, and that there's some optimizations missing, but those benchmarks feel strange...

    Anyway, I really appreciate all the works around r300G, r600g and nouveau ! keep up the good work, guys !

  5. #5
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,773

    Default

    Here's an idea of what to test next (if it was already done, then please ignore )

    Open Source Radeon vs Nouveau performance compared to their blob counterparts. Radeon, which is supported as Open Source by AMD and has access to hardware specs, vs Nouveau which is not supported by NVidia and needs to reverse-engineer a black box. Did OSS Radeon do a better job at coming close to 100% performance while having access to specs? Did Nouveau do a better job? And if Nouveau is the winner, what's the conclusion? Not having specs and support leads to better drivers? If both are on-par, what does that mean? Specs and support doesn't help? It got wasted? If Radeon wins, does that mean that Nouveau is probably never going to become a true replacement for the blob?
    Last edited by RealNC; 05-27-2011 at 09:21 AM.

  6. #6
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,380

    Default

    Quote Originally Posted by RealNC View Post
    Open Source Radeon vs Nouveau performance compared to their blob counterparts. Radeon, which is supported as Open Source by AMD and has access to hardware specs, vs Nouveau which is not supported by NVidia and needs to reverse-engineer a black box. Did OSS Radeon do a better job at coming close to 100% performance while having access to specs? Did Nouveau do a better job? And if Nouveau is the winner, what's the conclusion? Not having specs and support leads to better drivers?
    Similar studies have been done before and the conclusion is always the same. Having a higher percentage of the developers dress in black leads to better drivers.

    Given the relatively high performance of the r300g stack it seems like better questions would be :

    - what performance-related features are enabled in r600g relative to r300g at this time ?
    - are there differences in hardware architecture between the pre-r600 and 600+ generations which could require design changes between r300g and r600g, were those changes made, and were they correct in hindsight ?
    - what other design changes were made between r300g and r600g ?

    My 10,000 foot impression of the answers is :

    - programming some of the performance-related features is a lot trickier in r600+ hardware than in earlier hardware and as a consequence a number of those features are enabled in r300g but not yet enabled in r600g

    - r600+ hardware has a larger number of registers and different grouping of registers so a different approach to state management was taken in r600g relative to r300g; in hindsight the mapping of registers to state changes is more complex than first expected so more work on state management is probably needed

    - the shader compiler for r600+ started off as more of a 1:1 IR-to-hardware translator than a real compiler, although recent work may have improved that a lot (haven't had time to look)
    Last edited by bridgman; 05-27-2011 at 09:43 AM.

  7. #7
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,968

    Default

    Wasn't catalyst faster than r600 with drawing off?

  8. #8
    Join Date
    Apr 2010
    Posts
    1,946

    Default

    There is definately bottleneck somewhere!
    This bottleneck is related to screen resolution, as opensource driver does not reduce the fps on par to closed source.

    Maybe some huge data copy function/s that is unoptimized or unaccelerated? Maybe closed source copies data in single SIMD every frame, but opensource calls on demand?

    Do amd developers have some profiling software, some software to monitor cpu load, memory bus, pcie bus, gpu load, gpu memory controller load, disk io, software io(like kernel ring 0/1 changes per (milli)second, time percentage and overall the cpu spends - in kernel, driver or elsewhere or idles)?

  9. #9
    Join Date
    Nov 2009
    Posts
    12

    Default

    Quote Originally Posted by bridgman View Post
    - what performance-related features are enabled in r600g relative to r300g at this time ?
    - what different design decisions were made between r300g and r600g ?
    - are there differences in hardware architecture between the pre-r600 and 600+ generations which could require different design decisions, and were those decisions made ?
    well, that's what i meant (sort of)... maybe i should dress in black to see if my questions would be sharper

    I hope you didn't take my post as an offense of any kind, but i'm really interested in those low-level subjects, i just don't have the skills to help

    Be sure, i'm thankful for your work and your insightful posts on this forum

  10. #10
    Join Date
    Jan 2007
    Posts
    17

    Default OT - 4770 performance?

    Quote Originally Posted by bridgman View Post
    Similar studies have been done before and the conclusion is always the same. Having a higher percentage of the developers dress in black leads to better drivers.

    snip!

    - the shader compiler for r600+ started off as more of a 1:1 IR-to-hardware translator than a real compiler, although recent work may have improved that a lot (haven't had time to look)
    About two years ago I bought a Sapphire 4770, it looked really good on paper (still does) but the stock Fedora sw doesn't impress me particularly, are you able to say what is the state of open drivers for this card?

    Dave

    ps will dress in black if it helps...

Posting Permissions

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