So, apparently, the ATI drivers aren’t inlining functions before checking for variable indices.
However, 3DLab’s ShaderGen produces code that does send light source indices as parameters to functions. Needless to say, ShaderGen produces code that does not compile with my ATI drivers.
Can anyone shed some light into this problem? Is ATI not confirming to the standard or is ShaderGen producing code that yields unspecified results on some cards?
The drivers just don’t like it.
Are you running this on Linux?
I just tested on Windows (catalyst 5.9) and it gives the same message.
It has nothing to do with standards. Either it is supported or not. I think ATI’s an use the address register for this but they haven’t coded the support in their drivers.
Write
static vec4 GetLightPos(int i)
instead of
vec4 GetLightPos(int i)
Using static won’t work, it is a reserved keyword and should cause the shader not to compile.
If this is not part of the OGSL standard, wouldn’t it be a bad idea to write code that uses it at all? In that case, shouldn’t 3DLabs ShaderGen be producing code that can run on all cards?
If this is not part of the OGSL standard, wouldn’t it be a bad idea to write code that uses it at all?
Correct, writing code that is not part of the standard may result in broken shaders and most likely will break portability.
In that case, shouldn’t 3DLabs ShaderGen be producing code that can run on all cards? GLSL ShaderGen generates shaders that follow the OpenGL Shading Language Specification. GLSL Is still a fairly new language, and not all implementations handle all of the language elements used in GLSL ShaderGen .
The tool is written to create portable GLSL code that strictly follows the specification, therefore it should run on all hardware advertising support for the OpenGL Shading Language. We only have control over our implementation, it is impossible to guarantee GLSL ShaderGen will run on every vendor’s hardware since we have no control over their implementation.
GLSL ShaderGen does have an editable text box, if you need to make changes to the generated shaders on the fly you may do so by editing the fragment and vertex shaders within the text box. Press compile and then link and you’ll have the edited shader applied.
We also provide tools to help in the creation of portable shaders, even if you’re using a a compiler that does not adhere to the specification. These tools are GLSL Validate and GLSL Parser Test . GLSL Validate uses a strict compiler to parse your shader and gives specific error messages if the shader doesn’t adhere to the spec. GLSL Parser Test runs a group of shaders through the compiler on your machine and gives a detailed report on the compiler’s specification compliance.
Thanks for the post, 3DlabsDevRel. Those tools will come in handy for me.
I just upgraded to the latest ATI drivers (Catalyst 5.10) and it seems that the problem persists. I wonder if anyone from ATI could tell us if the problem is being adressed.
The problem boils down to that you just can’t access the gl_LightSource array in any semi-dynamic way. It’s a simple compiler/parser internal state error as it actually works for the very first compilation in a context. (I have provided them a simple test case compiling the same simple program twice)
Since you seem to be calling the function with a constant parameter anyways, have you tried declaring GetLightPos() to take a const int instead? It might hint the compiler into not being such a jerk
I tried “const int” to a function and then “const gl_LightSourceParameters” but none of them worked (although the later gave a different (ati only) error message).
So the pretty ugly multiline #define AddLight(i) has to stay
Using custom uniforms instead isn’t really viable for the general case here as it requires quite some structure around the shader setup. (especially as I assume only actually used elements/members are handled when using the standard array).
Which makes me wonder why didn’t the GLSL spec force uniforms (like gl_LightSource[]) to be const? I think that would make the language more strict and clearer.