AMD R600 Gallium3D Optimizing Back-End Merged

[curaga]

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.

[brent]

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.

[Drago]

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.

[curaga]

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)

[schmidtbag]

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).

[brent]

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.

[Azultra]

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.

[gururise]

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.

[curaga]

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.

[curaga]

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.