Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 29

Thread: AMD R600 Gallium3D Optimizing Back-End Merged

  1. #11
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,071

    Default

    Quote Originally Posted by Ericg View Post
    They have said before that this code is just a stop-gap measure. They know its not the longterm solution. But the longterm (LLVM) solution is better than the current solution, BUT this solution is better than the longterm one right now. Its being merged knowing full well that it will be bin'ed once LLVM is optimized and under better handling.
    I thought it wasn't agreed on that LLVM was the best longterm solution (for current cards) either.

  2. #12
    Join Date
    Jan 2010
    Posts
    364

    Default

    Quote Originally Posted by curaga View Post
    I thought it wasn't agreed on that LLVM was the best longterm solution (for current cards) either.
    Yeah, I don't think there's a hard agreement about that. LLVM seems to have trouble with VLIW architectures. And as Vadim pointed out, another problem is the complexity of LLVM. Code generation is bad in many cases, but it's hard to figure out what goes wrong and why. This is much easier with a small, dedicated codebase like r600-sb.

  3. #13
    Join Date
    Aug 2009
    Location
    Russe, Bulgaria
    Posts
    507

    Default

    Michael, when you test r600-sb, make sure you include Heaven and Doom3 on higher quality settings. Pixel fill-rate is directly dependent on Frag shader optimizations.
    It is pity you will have redone AMD part of 15-way comparison again.

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

    Default

    LLVM's latency is another point against it - it takes much longer to compile a shader using llvm than the current compiler. A long pause in the middle of a level isn't nice.

    (bad game design not to load all shaders at load time, but many games do so)

  5. #15
    Join Date
    Dec 2010
    Location
    MA, USA
    Posts
    1,272

    Default

    Quote Originally Posted by Drago View Post
    Michael, when you test r600-sb, make sure you include Heaven and Doom3 on higher quality settings. Pixel fill-rate is directly dependent on Frag shader optimizations.
    It is pity you will have redone AMD part of 15-way comparison again.
    I get the impression that there isn't a moment when Michael isn't benchmarking something. By the time he completes something, another new version of something gets released so I'd imagine it gets pretty hard to keep up (though, I figure most of it is just waiting around).

  6. #16
    Join Date
    Jan 2010
    Posts
    364

    Default

    I've done some ad-hoc comparisons with WebGL demos from the "chrome experiments" site, and R600_DEBUG=sb gives me a solid 50-60% FPS boost with demos that use heavy-weight shaders (blur, raytracing, etc.). Very nice. The Unity dash blur also seems to be noticeably faster.

    Looking at the statistics (R600_DEBUG=sb,sbstat) this does not surprise - r600-sb optimizations in many cases brutally reduce the length of the shader program, the number of GPRs used and the number of ALU operations. I haven't noticed any bugs yet.
    Last edited by brent; 05-01-2013 at 10:24 AM.

  7. #17
    Join Date
    Feb 2009
    Location
    France
    Posts
    35

    Default

    Quote Originally Posted by pingufunkybeat View Post
    This is the patchset which brings Unigine Heaven to Windows 7 performance.

    Things just keep getting better and better!

    And to think that OpenCL is making progress and that the PM code has already been written and is awaiting release.... W00t w00t!
    THIS. IS. AMAZING!

    Congrats AMD and every developer involved!

    The PM is really one big cons of the FOSS driver atm, let's hope it turns out as good as fglrx so I and many people can say a final goodbye to closed drivers.
    Last edited by Azultra; 05-01-2013 at 12:20 PM.

  8. #18
    Join Date
    Dec 2008
    Location
    San Bernardino, CA
    Posts
    232

    Default

    Looks more likely I'll switch back to the OSS drivers for my 4670 card. Waiting for the benchmarks from Michael to make my decision.

    Now we just need better opengl compliance and power managements and then the OSS drivers will be able to replace fglrx for the majority of users.

  9. #19
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,071

    Default

    Hit a few snags trying to build it, so no test results from me today.

    @gururise

    The difference for your 4670 is 3.1 vs 3.3, or mainly geometry shaders - hardly an often used feature.

  10. #20
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,071

    Default

    Wow, Vadim replied in less than an hour, fast customer service that

    It built now, but the results are pretty bad on my RV710 (HD 4350).

    glxgears has wrong output:

    Also some of my private apps regressed badly, 28 -> 7 fps, visual errors, and a pegged cpu core.

Posting Permissions

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