Results 1 to 10 of 18

Thread: AMD R600g LLVM Back-End Is Working A Bit Better

Hybrid View

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

    Default AMD R600g LLVM Back-End Is Working A Bit Better

    Phoronix: AMD R600g LLVM Back-End Is Working A Bit Better

    The R600g LLVM shader compiler back-end that's primarily intended for the Radeon Gallium3D compute support is now working a bit better for graphics support compared to when it was first committed...

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

  2. #2
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    505

    Default

    I believe when VLIW packetizer is finished, the performance will be greatly enhanced.

  3. #3
    Join Date
    Jan 2007
    Posts
    459

    Default

    "
    Granted, the tests were just measuring the in-game frame-rates and not the shader compiler time"
    it seems a little pointless to not have/provide a benchmark result for shader compiler time/speed in this case or how is anyone expected to estimate how many CPU cycles have now been saved for use elsewhere in the system! etc.

  4. #4
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,034

    Default

    The shader compile time is uninteresting, the speed of the outputted shader is not. Michael benched the right thing.

    It really does not matter if a game takes 0.3s more or less to load.

  5. #5
    Join Date
    Nov 2008
    Location
    Madison, WI, USA
    Posts
    862

    Default

    Quote Originally Posted by curaga View Post
    The shader compile time is uninteresting, the speed of the outputted shader is not. Michael benched the right thing.

    It really does not matter if a game takes 0.3s more or less to load.
    Wasn't Valve reportedly having issues with recompile times of dynamic/changing shaders during game run-time? /nitpick

  6. #6
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,034

    Default

    That should be a) threaded b) cached and c) the complaint was about fglrx, IIRC, not mesa.

  7. #7
    Join Date
    Feb 2008
    Posts
    88

    Default

    Quote Originally Posted by Veerappan View Post
    Wasn't Valve reportedly having issues with recompile times of dynamic/changing shaders during game run-time? /nitpick
    Actually Xonotic/Nexuiz has problems with compile times. Whenever a new material/effect/whatever comination is encountered rendering will have to wait for a split second for the shader to compile. This is noticable especially in the first few seconds on a new map.

  8. #8
    Join Date
    Jan 2007
    Posts
    459

    Default

    Quote Originally Posted by curaga View Post
    The shader compile time is uninteresting, the speed of the outputted shader is not. Michael benched the right thing.

    It really does not matter if a game takes 0.3s more or less to load.
    OC i agree that it makes no difference at all that a game takes a few micro seconds more to load or not
    but in this case the code is primarily for Gallium3D compute support and all those saved microseconds per routine cycle do add up and so output speed and cycles saved is interesting overall (at least to me) as an initial estimate.

Posting Permissions

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