Page 3 of 3 FirstFirst 123
Results 21 to 28 of 28

Thread: AMD Fusion On Gallium3D Leaves A Lot To Be Desired

  1. #21
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,516

    Default

    The 2x difference doesn't surprise me, although some of the 10x differences do since IIRC the corresponding number on discrete GPUs is more like 3-5x than 10x. THe difference may be memory bandwidth sensitivity (optimizing to reduce bandwidth consumption is one of the more complex aspects of driver optimization) or just that the default clock state for APUs is even lower than I remembered.

    As others have said it would be good to keep in mind which performance features in the HW are enabled and which are still being worked on. Looks like the article ran with driver defaults - Michael is that correct ? Any idea what clocks were being used (ie what the VBIOS power state called for) ?

    Testing with defaults (ie ignoring some WIP improvements which are still off by deafult) seems reasonable to me as long as you aren't drawing "it's gonna be years" conclusions from the results.

  2. #22
    Join Date
    May 2007
    Posts
    233

    Default

    Quote Originally Posted by curaga View Post
    @glisse

    Do you mean TGSI or r600 asm?

    My GSOC shader (TGSI) was 20% faster when hand-optimized compared to Mesa's GLSL compiler. But that's only at TGSI level, I believe it would be much faster if properly compiled (maybe wrong word) down to r600g asm instead of the simple replacement that I understand is the current status.
    I mean at r600 asm level. What was your shader ? My experiment showed allmost no win but i didn't do big shader (even doom3 don't have that big shader).

  3. #23
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by Drago View Post
    Don't be so sure. Tom Stellar is integrating LLVM backend for r600g as we speak, and once it is done, and LLVM->VLIW packetizer is finished(it is started), we can all enjoy faster shaders both graphics and compute. 3-4 years is awfully pesimistic.
    if 3-4 years are pessimistic then 1-2 years are optimistic

    well yes right in the moment they finish this i buy a new graphic card with GCN architecture just to make sure the driver is alpha/beta again. LOL

  4. #24
    Join Date
    Oct 2011
    Location
    Rural Alberta, Canada
    Posts
    1,044

    Default

    Quote Originally Posted by darkbasic View Post
    glisse it's because nouveau is faster than radeon: considering nouveau isn't backed by nvidia and there isn't any documentation that's quite strange and peoples started searching for a culprit.
    Where is it shown the nouveau would be faster? I have had the impression that, when they both work, they are about the same.

  5. #25
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,199

    Default

    Quote Originally Posted by bridgman View Post
    As others have said it would be good to keep in mind which performance features in the HW are enabled and which are still being worked on. Looks like the article ran with driver defaults - Michael is that correct ? Any idea what clocks were being used (ie what the VBIOS power state called for) ?
    Bridgman, AFAIK checking the Radeon clocks still requires a debug feature (DEBUGFS), even though it is a decidedly non-debug operation. Could you lobby on making a stable interface for it in /sys, so all users will have access to the clocks without requiring the enabling of debug features?

    What was your shader ? My experiment showed allmost no win but i didn't do big shader (even doom3 don't have that big shader).
    MLAA. The hand-optimized TGSI can be found in any current Mesa. And yes, it's a big shader (three passes, the second pass is the biggest).

  6. #26
    Join Date
    Nov 2009
    Location
    Italy
    Posts
    971

    Default

    Quote Originally Posted by curaga View Post
    Bridgman, AFAIK checking the Radeon clocks still requires a debug feature (DEBUGFS), even though it is a decidedly non-debug operation. Could you lobby on making a stable interface for it in /sys, so all users will have access to the clocks without requiring the enabling of debug features?
    +1

    (stupid character limit)
    ## VGA ##
    AMD: X1950XTX, HD3870, HD5870
    Intel: GMA45, HD3000 (Core i5 2500K)

  7. #27
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    532

    Default

    Quote Originally Posted by darkbasic View Post
    +1
    Even better, if the interface is GPU vendor neutral. This way the user-space app would be simple, and will GPU neutral also.

  8. #28

    Default

    So we all agree that the very poor benchmarks were due to the clocks being low by default on Fusion?

    Then what's left to be desired is proper 'idiot proof' dynamic power management, enabled by default, so phoronix won't draw the wrong conclusions after benchmarking

Posting Permissions

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