Forgot to mention that this is printed on the terminal:

EE r600_shader.c:141 r600_pipe_shader_create - translation from TGSI failed !

The shader translation is failed because of too many temps used. They could be optimized away in theory, but this shader also uses indirect addressing, and some optimization passes in mesa are disabled due to this.
 
The shader also contains alternative code that afaics does the same calculations without indirect addressing, you may check if it helps by adding the line:

#define WORKAROUND 1

in the beginning of the ./CoreBreach.app/Resources/postprocessing.frag

hello 
i am the game developer.

the workaround for disabling indirect addressing is automatically applied if linking the shader fails because of the indirect adressing. e.g. this happens on the geforce 7100 under windows. 

if you let linking fail instead of crashing, the same code path will be used here.

i don't want to make disable indirect addressing by default since i guess it will be slower on recent hardware.


i'm not sure whats with the talk about too many temps. this crash occurs on 5770 / 5670 which are very capable cards. with the proprietary nvidia/ati drivers this shader works fine even back to ancient hardware under windows/mac/linux e.g. Radeon 2400 or GeForce 7300.

(In reply to comment #3)
> hello 
> i am the game developer.
> 
> the workaround for disabling indirect addressing is automatically applied if
> linking the shader fails because of the indirect adressing. e.g. this happens
> on the geforce 7100 under windows. 
> 
> if you let linking fail instead of crashing, the same code path will be used
> here.

Yes, the crash needs to be fixed, of course, but I'm afraid that just fixing it won't make everything work as expected, because it happens too late. I'll check this.

> 
> i'm not sure whats with the talk about too many temps. this crash occurs on
> 5770 / 5670 which are very capable cards. with the proprietary nvidia/ati
> drivers this shader works fine even back to ancient hardware under
> windows/mac/linux e.g. Radeon 2400 or GeForce 7300.

The shader code with mesa is not as heavily optimized as with the proprietary drivers. There are some optimization passes that do not support indirect addressing currently, so they are disabled in this case, that's why this shader breaks the limits. 
 
> i don't want to make disable indirect addressing by default since i guess it
> will be slower on recent hardware.
> 

I'm not sure that it will be slower. Code optimization with indirect addressing is much harder, so I guess almost every compiler will produce more efficient code without indirect addressing (at least in this case). It's definitely true for mesa at the moment. Also I did a quick comparison of the generated code for this shader with AMD GPU Shader Analyzer (that is, code generated by the AMD's proprietary driver), here are some of the results for the HD5770:

w/o WORKAROUND:  2864 MPixels/sec
with WORKAROUND: 3629 MPixels/sec

I'm not an expert in shaders performance, but afaics many apps are trying to avoid the indirect addressing, e.g. Unigine Heaven IIRR doesn't use it at all.

thanks, you are right, the indirect addressing is slower after all (full benchmark on Radeon 5770, Radeon 2600 and GeForce 9600M). the difference  is actually small on the 5770 but up to 100% on the other cards:

http://imageshack.us/f/13/bildschirmfoto20111201u.png/

i'll disable the indirect addressing unconditionally and will have a look if everything work fine now with the r600 driver or if there are remaining problems.

of course this bug should be fixed nevertheless ;-)

This is no longer a problem with Mesa 9.2 and CoreBreach 1.1.5, not sure if it was fixed in the driver or the game but no reason to keep the bug open.