pouët.net

We're making a 4k the rwwtt way, like we've been doing since 2007, but recently we started getting strange results with ATI's GLSL compiler... Some calculations were simply plain wrong, and now the compiler simply fucks up and won't work... Here's something from the output window just after calling glCompileShader in the Release configuration, without CRT, without anything fancy like stdio or iostream, just like a 4k is configured for crinkler, but with debug information and without crinkler:

and/or

Checking the shader info log reveals something more strange yet:

WAT?
Which errors? It doesn't say. We're not allocating any memory, we're not even filling our sound buffer (yet). A memory corruption from our side is out of the question, so we guess that it's ATI's compiler that is really screwing up.

And we're guessing that it doesn't like if he can't predict how often a loop (a big loop) will iterate. Does ANYBODY have any suggestion on what we should look for, any hints? We'd rather not share our shader code since we'd be giving away our intro before releasing it at Evoke.

Many thanks!

...oh and please, don't even begin with "ATI's GLSL compiler sucks". I know that. Yet knowing that won't help us any further.

Not much you can do as it sounds like driver issue. Runs out of some preallocated memory or something like that.

Split to the shader into multiple smaller shaders - create a separate one for each part or something..

Or if you really want to use the way you do you need to wait for driver patch..? Try to remove stuff until it works and send the working and broken shader to ATI/AMD and ask them to fix it.

Reminds me of one Samsung Galaxy which failed to compile more than 128 lines long shaders with one version drivers

Perhaps ARB_debug_output could help in any way?

kbi: gDEBugger uses that kind of thing. There's no debug output generated :(

Try pushing the shader body through ATI's off-line compiler and see if it goes nuts as well. If not, maybe you could try making an ATI-only version which woulld feed the driver with shader asembly that the tool outputs?

Do you have a minimal shader to reproduce the problem? ATI only problem? Spec correct shader?
#version 420? Too high register pressure? Did you try to play with the optimize(off) pragma?

(on a side not: i never did similar tricks, it's just an idea top off my head, so it might be totally useless)

ah, yes! try adding the #pragma debug(on) and #pragma optimize(off) too, could give you some clues or even help working around this shit.

Does digestionproblems cause exceptions? 'cause then I think your problem is quite self explanatory:

Sorry - I have nothing of actual relevance to add, I just found it hysterically funny :)

0xbaadf00d refers to uninitialized heap-allocated memory. How about 0xdeadbeef?

#version 420, #pragma debug(on) and #pragma optimize(off) all didn't change anything.

@kbi: Don't know ATI's offline compiler, where is it/how do I use it?
@las: The problems started to occurr when the shader started to get big. How do I determine if it's Spec correct (any tools for that)? How do I see the register pressure?

Try this: http://developer.amd.com/tools/shader/pages/default.aspx

OK, the GPU ShaderAnalyzer outputs following after compiling my shader:

I recall revival having some issues that got fixed by something that to me sounded like "responding to events during .. blah blah ... something something". Made our intro crash on some ATI cards until he fixed it.

xTr1m: looks like an ugly bug in the compiler to me, then :( Sorry for not being able to help you more.

this is a shoot in the dark, but can your shader-code fail to work if you try to access memory that has been allocated but not initialized?

BTW. Just spotted you're using varyings which have been deprecated for some time now. Try using output variables. So for the piece of code visible on the screenshot this would be:

out vec4 v;
out vec2 m;

It just might be that this is the reason for which the Compiler dies.

It is not me who's trying that... it's the ATI GLSL compiler. I'm afraid that it's really a bug there and there's little that I can do about it.

@kbi: Thanks! It saved some bytes, but the error remains.

xTr1m: I've had similar strange compiler behavior before. Thinks to look out for:
strange characters (accidentally pressed some accented char), unterminated comments and generally extremely weird syntax errors (if you have a buggy tool that modifies shader code, there's no end of ways to confuse the compiler).

Of course those should all result in errors on Nvidia too. So I suggest the blaat technique: just write "blaat;" in you shader code, and see if the compiler returns "unknown identifier:blaat" before dying. If so, start moving it around to see exactly which line causes the compiler to die.

If the compiler dies without returning any error, you'll have to cut code until the shader compiles again, then re-add until you've narrowed down which line is the culprit.

Fun fact: ATI doesn't like "max(0,vec3(...))" but is perfectly happy with "max(vec3(...),0)"

Seven: That's because they follow the standard instead of just randomly accepting broken code.

I've had a similar bug with a shader terminated with "#endif\0".
Check that your directives are followed by new-lines.

What kusma said + NV does the same.

Las: strange, I had that code running fine on my NVidia laptop (drivers updated yesterday) and the NVidia compo machine ran it as well, only the AMD one barked on it.

Kusma: point taken, it was just unexpected.

When coding with OSX, non-braking spaces are always problematic, not sure if on Win32 it is even possible to output as difficult character to debug: " " <- thats the character in there between quotes.

Currently I've seen almost every compile to break when encountering those.