Hmm, it is a rare case, but in my opinion, I think that GL state change at CPU side should have higher priority over shader code. I will talk to AMD shader team about this problem.
I can imagine such a system where clip planes can be enabled and disabled by a user to look at different cut-aways of a model. The clipping planes might be displayed and moveable by an app and toggled on and off applied to a model.
The current ATI behavior leaves the planes always applied. From the specification:
I just programmed an example, which is setting gl_ClipDistance[0] in the vertex shader and disabling it with glDisable(GL_CLIP_DISTANCE0) in the main code. With the AMD Catalyst 12.1, the clip distance is still used. So I can confirm that this is a bug.
I dislike redundant things too but the GL_CLIP_DISTANCE states are not one of them. They let you use the same shader with or without clipping.
Also all shader outputs have undefined values if they are used afterwards but the shader does not write them.
It wouldn’t be very elegant if clip distances are exception from this and writing/not writing in them implicitly enables/disables clipping.
While i am not against the idea to be able to switch clipping on/off from within the shader alone, i’m certainly against doing it in this particular way.
Instead it could be some pragma or such.
Output variable that is not being written to should remain with undefined value.
Yeah. That would be good enough (its also what im saying, you would get undefined result when you statically use the variable but don’t actually write to it).
Also note, how GL actually works that way in some cases - gl_FragDepth kinda works like that.
You are right for gl_FragDepth it’s an exception from the undefined “rule”.
So it appears we already have exceptions anyway. Well, in that case… i cancel my objections
In the mentioned example, I still write to the clip distance. But by disabling the clipping, I would expect - as written in the specs - that no clipping is done.