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

Thread: Shader Optimization Back-End Might Go In For R600g

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

    Default Shader Optimization Back-End Might Go In For R600g

    Phoronix: Shader Optimization Back-End Might Go In For R600g

    For many months there has been a "shader optimization" branch of Mesa/R600g that sought to rather noticeably boost the performance of the AMD R600 Gallium3D driver. While this work by Vadim Girlin didn't look like it would be merged, after being revived and cleaned-up, it might reach mainline Mesa/Gallium3D as a new performance-boosting option...

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

  2. #2
    Join Date
    Oct 2008
    Posts
    3,076

    Default For those too lazy to look up the link

    It probably won't make much of a difference on Quake3, but here are some results:

    Oh, and in case it wasn't clear from Michael's article, this code runs on the hardware instructions, which means it can be run after getting the output of either the old compiler backend or the new llvm one. It doesn't care about that.

    Quote Originally Posted by vadim
    Below are some quick benchmarks for shader performance and compilation
    time, to demonstrate that currently r600-sb might provide better
    performance for users, at least in some cases.

    As an example of the shaders with good optimization opportunities I used
    the application that computes and renders atmospheric scattering
    effects, it was mentioned in the previous thread:
    http://lists.freedesktop.org/archive...ry/034682.html

    Here are current results for that app (Main.noprecompute, frames per
    second) with default backend, default backend + r600-sb, and llvm backend:
    def def+sb llvm
    240 590 248

    Another quick benchmark is an OpenCL kernel performance with bfgminer
    (megahash/s):
    llvm llvm+sb
    68 87

    One more benchmark is for compilation speed/overhead - I used two piglit
    tests, first compiles a lot of shaders (IIRC more than thousand), second
    compiles a few huge shaders. Result is a test run time in seconds, this
    includes not only the compilation time but anyway shows the difference:
    def def+sb llvm
    tfb max-varyings 10 14 53
    fp-long-alu 0.17 0.38 0.68

    This is especially important for GL apps, because longer compilation
    time results in the more significant freezes in the games etc. As for
    the quality of the compiled code in this test, of course generally llvm
    backend is already able to produce better code in some cases, but e.g.
    for the longest shader from the fp-long-alu test both backends optimize
    it to the two alu instructions.

    Of course this branch won't magically make all applications faster, many
    older apps are not really limited by the shader performance at all, but
    I think it might improve performance for many relatively modern
    applications/engines, e.g. for the applications based on the Unigine and
    Source engines.

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

    Default

    Please merge, and make it the default for 9.2. The lack of an optimizing r600 backend for all this time has been a huge bottleneck, the elephant in the room.

  4. #4
    Join Date
    Nov 2011
    Posts
    267

    Default

    I'd be interested to see 3-way benchmarks for this (r600g with or without r600-sb, fglrx). Not necessarily a full benchmark, just Unigine, a couple older games, and perhaps an opencl benchmark, if there is one already.

    It's sounding like it brings r600g close to Catalyst in terms of performance.

  5. #5
    Join Date
    May 2011
    Posts
    54

    Default

    WOW! Now I can use High shaders for StarCraft2 under Wine. r600-sb very cool! Need merge now and enable by default.

  6. #6
    Join Date
    Feb 2011
    Location
    Ukraine
    Posts
    132

    Default

    Quote Originally Posted by Ibidem View Post
    I'd be interested to see 3-way benchmarks for this (r600g with or without r600-sb, fglrx). Not necessarily a full benchmark, just Unigine, a couple older games, and perhaps an opencl benchmark, if there is one already.

    It's sounding like it brings r600g close to Catalyst in terms of performance.
    unigine 3.0
    r600 - 558
    r600-sb - 784
    windows 7 - 789

  7. #7
    Join Date
    Jan 2013
    Posts
    971

    Default

    Quote Originally Posted by pontostroy View Post
    unigine 3.0
    r600 - 558
    r600-sb - 784
    windows 7 - 789
    WOW! Respect!!

  8. #8
    Join Date
    Oct 2008
    Posts
    3,076

    Default That's awesome

    Quote Originally Posted by Pontostroy View Post
    unigine 3.0
    r600 - 558
    r600-sb - 784
    windows 7 - 789
    What card?

  9. #9
    Join Date
    Feb 2011
    Location
    Ukraine
    Posts
    132

    Default

    Quote Originally Posted by smitty3268 View Post
    What card?
    hd6770
    heave 3.0 1920x1080 opengl

  10. #10
    Join Date
    Nov 2012
    Posts
    140

    Default

    Quote Originally Posted by Pontostroy View Post
    unigine 3.0
    r600 - 558
    r600-sb - 784
    windows 7 - 789
    What about heat production?

Posting Permissions

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