Prevent loop unwinding in fragment shader

Question

I'm writing a fragment shader for WebGL(GLSL ES 1.0) using the latest version of Chrome(and Firefox), and I wrote an iterative algorithm.

So first of all, I found out the hard way that the length of the loop is quite restricted (doc says it must be guessable at compile-time, which means it must be a constant or very close).

In addition, I must write a (for, since it's the only one which must be implemented according to the standard) loop that's potentially long but that breaks almost every time before the end.

Now, I've noticed that if I set a higher maximum number the compilation and linking of the shader takes alot more time. So, unless I'm wrong, the compiler does loop unwinding.

I'm not sure if anything can be done, but I've tried a few things and the compiler seems also to inline functions, even when called in loops.

I don't feel like it's normal for a shader to take a whole minute to compile for just about a hundred iterations of a loop. Or am I doing the wrong thing? Is a hundred iterations in a fragment shader way too much for a GPU? Because it seems to run just fine after it has compiled.

Answer 1

This is one of the unfortunate realities of GLSL. It would be great if we could do an offline compile and send in bytecode, or if we had the ability to specify flags at compile time or so on, but that's just not how the spec works. You are entirely at the mercy of the driver manufacturer. If NVIDIA/ATI thinks loop unrolling is good for you, your loop is gonna get unrolled.

I do question what it is that you are doing that requires so much looping, though. Shaders are not really the right place to be doing super complex looping or branching calculations. You'll certainly take a performance hit for it. If you're not worried about realtime performance, then perhaps a large compile hit at the start of your program isn't so bad. If you are concerned about the rendering speed of your app then you likely need to re-evaluate your shaders complexity.

Answer 2

You mention the shader taking more than a minute to compile a loop with a maximum of only about 100 iterations, and this makes me think your problem could be related to ANGLE.

ANGLE is a piece of software embedded in WebGL-capable browsers on the Windows OS, that takes your GLSL shader and translates it at runtime into a Direct3D HLSL shader. The thinking is that most Windows machines have newer Direct3D drivers compared to their OpenGL drivers, so the default behavior is to convert everything to D3D. In my experience this can be slow, particularly with long loops as you describe, although it's needed by many Windows users, particularly ones with Intel-based graphics.

If you're running Windows and you have good-quality OpenGL drivers, such as reasonably new ones from nVidia or AMD, you can try disabling ANGLE to see if it fixes your problem. On Google Chrome this is done by editing your Chrome icon to add --use-gl=desktop as a command-line parameter (in the 'target' field of the icon) and restart the browser. For Firefox, you can visit about:config and type webgl into the search box, and look for webgl.prefer-native-gl and set that to true.

Try your shader again with ANGLE disabled, and compile times may be improved. Keep in mind this is only a Windows issue, so editing these settings on other platforms has no effect, but I believe all other platforms all use native OpenGL directly.

Answer 3

Sadly AMD might not support this, but I think NVidia has a nice pragma unroll directive. For people who are having the opposite problem, you'd invoke it as "#pragma optionNV (unroll all)" in GLSL, but I think the following will prevent unrolling. I quote DenisR's 2008 post on the NVidia forums:

By default, the compiler unrolls small loops with a known trip count. The #pragma unroll directive however can be used to control unrolling of any given loop. It must be placed immediately before the loop and only applies to that loop. It is optionally followed by a number that specifies how many times the loop must be unrolled.

For example, in this code sample:

#pragma unroll 5

for (int i = 0; i < n; ++i)

the loop will be unrolled 5 times. It is up to the programmer to make sure that unrolling will not affect the correctness of the program (which it might, in the above example, if n is smaller than 5).

#pragma unroll 1 

will prevent the compiler from ever unrolling a loop.

If no number is specified after #pragma unroll, the loop is completely unrolled if its trip count is constant, otherwise it is not unrolled at all.

So I would imagine that

#pragma optionNV (unroll 1)

MIGHT work in GLSL (and WebGL?). (For example, StackOverflow question selective-nvidia-pragma-optionnvunroll-all seems to imply this may work in GLSL, at least under some platforms.)

There seems to be an implication that in recent years, AMD might support an unrolling pragma (maybe not in GLSL though), but I'm not familiar and haven't tried it: unroll loops in an AMD OpenCL kernel

( If using GLSL via WebGL in Chrome/Firefox, or even other scenarios, keep in mind that GLSL compilation may be piped through ANGLE, which might render to an HLSL backend on Windows, maybe. I have a very limited understanding of this and don't wish to spread information, so definitely don't quote that; I just felt it was necessary to share what information I had gathered on this problem so far, and will gladly edit this answer (or people should feel free to edit this answer) as more confirmed information becomes available. )