In a GLSL shader that I’m working on, I’m currently using a pair of nested for-loops.
Both loops have a fixed–indeed, hard-coded–loop-count.
Conversely, the loop-index is used within the loop for certain calculations.
I’ve seen some mentions online, and seem to have some vague memory, that loops might be unwise in shaders–perhaps unsupported in some contexts? However, what I have is unclear to me. And so I thus ask:
Are loops such as I’ve described a potential problem in a GLSL shader? Might they simply not work, or malfunction, on some machines? Or slow down significantly on some machines? Or some other untoward thing?
Note that loop unrolling requires a compile-time constant to be used as loop bound.
I don’t know what the hw requirements are for non-constant loop counters. I don’t have time right now to look into it, perhaps try the GLSL spec or the OpenGL wiki.
At the very least, for non-unrolled loops, the usual caveats of branching apply, ie. all shader invocations in an “invocation group” (a block of pixels/vertices that is processed simultaneously) will run as long as the longest invocation in that group, which is guaranteed to never be a problem if the loop bound is a uniform variable.