Really? Business or pleasure? That’s some sweet hardware.
Anyway, good luck …and may der Schwartz be with you .
I get some warnings like this:
Validation warning! - Sampler value <sampler name> has not been set in fragment shader
Makes no sense to me, or this poster. You don’t set them in the fragment shader (assuming set means to “bind a texture” to it). And you can’t “set” them (as in write values to them in the fragment shader). Guess you need to hit up ATI devrel for their secret decoder ring.
With other shaders, I get this:
Validation failed! - Different sampler types for same sample texture unit in fragment shader
Who knows, but could be because you dynamically set the sampler type (uniform sampler2D, uniform sampler3D, etc.) of a sampler uniform, and you’ve got multiple references (e.g. overloaded functions) in the shader that dynamically match and are compiled in based on the type. All the ones with non-matching types don’t match and are compiled out. Only the one that type-matches is compiled in. If this is your case, then AFAIK this is perfectly valid, shouldn’t even be a warning, and you prob should file a bug report on the ATI driver for even mentioning it. Might double-check the GLSL spec first though…
Now what would be bad is if multiple references of that sampler, typed differently, were pulled into the compiled shader. That’d be a bug on your part.
Finally, one of the shaders causes the driver to crash in glCompileShader. And it’s a huge shader.
If you’re on Linux, valgrind to the rescue! Otherwise fork over bucks for a decent memory profiler on your chosen OS.
For valgrind, just pipe the output to a file, then post-run, just search down from the top for the word “Invalid”. That usually points directly to the problem. Make sure the memory problem isn’t in your code.
To report ATI bugs, see this post. Goes without saying that a small repro test is much more likely to get fixed than a general description.