Go to bottom

ATI, glCompileShader and raymarching uber-shader

category: code [glöplog]
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:
First-chance exception at 0x69A280AA (atioglxx.dll) in 4k_Release.exe: 0xC0000005: Access violation reading location 0x00000000.

First-chance exception at 0xBAADF00D in 4k_Release.exe: 0xC0000005: Access violation executing location 0xBAADF00D.

Checking the shader info log reveals something more strange yet:
Fragment shader failed to compile with the following errors:

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.
added on the 2012-08-03 12:01:27 by xTr1m xTr1m
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
added on the 2012-08-03 12:16:22 by rale rale
Perhaps ARB_debug_output could help in any way?
added on the 2012-08-03 13:36:04 by kbi kbi
kbi: gDEBugger uses that kind of thing. There's no debug output generated :(
added on the 2012-08-03 13:41:20 by xTr1m xTr1m
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?
added on the 2012-08-03 14:10:31 by kbi kbi
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?

added on the 2012-08-03 14:10:52 by las las
(on a side not: i never did similar tricks, it's just an idea top off my head, so it might be totally useless)
added on the 2012-08-03 14:11:23 by kbi kbi
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.
added on the 2012-08-03 14:12:24 by kbi kbi
Does digestionproblems cause exceptions? 'cause then I think your problem is quite self explanatory:
First-chance exception at 0xBAADF00D

Sorry - I have nothing of actual relevance to add, I just found it hysterically funny :)
added on the 2012-08-03 14:16:54 by Punqtured Punqtured
0xbaadf00d refers to uninitialized heap-allocated memory. How about 0xdeadbeef?
added on the 2012-08-03 14:19:12 by kbi kbi
#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?
added on the 2012-08-03 14:27:39 by xTr1m xTr1m
Try this: http://developer.amd.com/tools/shader/pages/default.aspx
added on the 2012-08-03 14:39:32 by kbi kbi
OK, the GPU ShaderAnalyzer outputs following after compiling my shader:
BB Image
added on the 2012-08-03 14:54:27 by xTr1m xTr1m
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.
added on the 2012-08-03 14:54:57 by Punqtured Punqtured
xTr1m: looks like an ugly bug in the compiler to me, then :( Sorry for not being able to help you more.
added on the 2012-08-03 15:16:35 by kbi kbi
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?
added on the 2012-08-03 15:26:39 by rudi rudi
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.
added on the 2012-08-03 15:35:33 by kbi kbi
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.
added on the 2012-08-03 15:36:27 by xTr1m xTr1m
@kbi: Thanks! It saved some bytes, but the error remains.
added on the 2012-08-03 15:44:05 by xTr1m xTr1m
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)"
added on the 2012-08-03 16:03:05 by Seven Seven
Seven: That's because they follow the standard instead of just randomly accepting broken code.
added on the 2012-08-03 16:17:13 by kusma kusma
I've had a similar bug with a shader terminated with "#endif\0".
Check that your directives are followed by new-lines.
added on the 2012-08-03 16:19:11 by ponce ponce
What kusma said + NV does the same.
added on the 2012-08-03 16:32:52 by las las
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.
added on the 2012-08-03 16:38:47 by Seven Seven
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.
added on the 2012-08-03 17:24:01 by jalava jalava


Go to top