unbound sampler declaration andd GLSL shader code

[fred_em]

The type doesn't matter.

Ok on that part. int or vec3, who cares, they're both uniform values. Fine.

Because GLSL assumes (and GPUs implement) a SIMD architecture, a conditional is typically executed by executing both branches but ignoring state changes in whichever branch wasn't selected by the condition. But if a non-selected branch results in an error, it can still effect the overall execution of the shader.

GPUs do not have a branch prediction unit, do they? Therefore they don't speculatively execute the code of the wrong branch.
Even if my condition is "if (gl_FragCoord.x > 10000)" which is not a dynamic-uniform (as you said), I don't see any reason why the GPU would choose to evaluate the wrong block of code. On a CPU it's because of the branch prediction unit (or maybe because of out-of-order execution), but on a GPU, I don't get it.

[fred_em]

I found with the AMD drivers, if I left a samplerBuffer unbound it would crash even if I didn't sample from it.

I can't find anywhere on the web a paragraph that says that shader samplers MUST be bound.

EDIT: I only found your post here: http://www.opengl.org/discussion_boa...=1#post1223479

[tonyo_au]

I have been using dynamic subroutines to choose whether to load the fragment colour from different sources including a uniform, texture, multiple textures etc. If I am, for example, loading from a uniform, I do not bind a texture and I have had no problems with either the AMD nor nVidia drivers. One of my subroutines even has if tests inside it where some paths will load a texture and other won't.

[fred_em]

You are right, shader subroutines are a more appropriate way of instructing the driver which block of code is or is not used at runtime, and therefore the driver might not complain about unbound samplers if it knows the block of code does not access the (unbound) samplers.
Still, I would appreciate if the GL spec specified that unbound samplers are indeed valid or not, and under which conditions/circumstances.

[thokra]

I found with the AMD drivers, if I left a samplerBuffer unbound it would crash even if I didn't sample from it.

Are you absolutely sure that the sampler wasn't active? Otherwise I would suggest that this is a driver bug because active samplers should be properly detected at link time.

fred_em: is there any chance you can factor your shader into two separate shaders? don't underestimate the fact that you do additional function calls with subroutines.

[tonyo_au]

thorka is right to suggest separate subroutines where practical. My benchmarking (while not as scientific as I might like) showed dynamic subroutines do not come for free. I only use them in shaders that have a lot of branching options that the user can change at their whim and so in the program logic it is easier to dynamically create the shader.

[thokra]

thorka is right to suggest separate subroutines where practical

Separate shaders.

[tonyo_au]

sorry

[malexander]

Are you absolutely sure that the sampler wasn't active? Otherwise I would suggest that this is a driver bug because active samplers should be properly detected at link time.

It was the same situation as fred_em originally posted - a texelFetch() in a conditional clause that was never taken due to a uniform-valued condition (if(uniform_val == 0) texelFetch()). The sampleBuffer without a corresponding TBO bound crashed, likely due to predicated execution of the fetch/assignment. I was suggesting that leaving a unbound texture unit for an active sampler is not terribly safe.

[thokra]

I was suggesting that leaving a unbound texture unit for an active sampler is not terribly safe

Although quite easily deducible that this is undefined behavior, the GL/GLSL specs actually don't seem to state as much and certainly don't warn of potential program termination. The question is, is this worth being mentioned in the spec?