AMD R600g LLVM Back-End Is Working A Bit Better

[popper]

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.

[curaga]

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

[Veerappan]

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

[curaga]

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.

[popper]

"

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.

[Drago]

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

[phoronix]

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