This is, in some way, a binding promise, it cannot just decide otherwise all of a sudden. You most probably validated your program after compiling and linking, and you most probably queried the shader info log, and OpenGL kept telling you that everything was fine. Now, if you supply a silly number in an uniform, and the HAL thus has to produce new code and runs against this limit, what can OpenGL do? If you supply a too big constant, it will give you a "too many instructions" compiler error when you build the shader. While technically possible to do it with non-constants anyway, the implementation would have to recompile the shader every time you change that uniform, and it might run against the maximum instruction count if you're just allowed to supply any haphazard number. And, this explains why it has difficulties doing so with non-constants. What really happens on pre-SM3 hardware is that the HAL inside your OpenGL implementation will completely unroll your loop, so there is actually no jump any more. GLSL can be confusing insofar as for() suggests to you that there must be conditional branching, even when there isn't because the hardware is unable to do it at all (which applies to if() in the same way). I know this might be a silly question, but I am a beginner and I cannot find a reason why this shouldn't work.
for (int i = 0 i = uNumLights)Īren't these equivalent? Should the latter work in older versions GLSL? And if so, isn't this more efficient and easy to implement than other techniques that I have read about, like using a different version of the shader for different number of lights? For example the following code would not work in shader versions older than 3.0. I have learned that in shader versions lower than 3.0 you cannot use uniform variables in the condition of a loop.
#VIDEO CARD DOES NOT SUPPORT SHADER MODEL 3.0 HOW TO#
Currently I am learning how to create shaders in GLSL for a game engine I am working on, and I have a question regarding the language which puzzles me.