ATI - GL_CLIP_DISTANCE0 - Bug

[rombust]

For reference to anyone else with the same problem:

The following works on NVIDIA but not on "ATI Radeon HD 4800 Series"

In the application:

	glDisable(GL_CLIP_DISTANCE0);
	glDisable(GL_CLIP_DISTANCE1);
	<-- Note Disable clip!

In the GLSL vertex shader:

	gl_ClipDistance[0] = -1000;"
	gl_ClipDistance[1] = -1000;"

The gl_ClipDistance is used, although disabled in the application via glDisable(GL_CLIP_DISTANCEi)

[Hongwei Li]

So how about when clipping is enabled in the CPU code?

[magnus n]

In the code posted by rombust the gl_ClipDistance variables are set to some value that will effectively discard the primitive.

When GL_CLIP_DISTANCE0 or GL_CLIP_DISTANCE1 is enabled then both NVIDIA and AMD correctly renders nothing.

If you disable the clip distances using glDisable, the AMD driver still renders nothing while the NVIDIA driver renders the primitive.

[Hongwei Li]

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.

[kRogue]

just my 2 cents..

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:

Values written into gl_ClipDistance for planes that are not enabled have no effect.

[McNopper]

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.

[kyle_]

I love redundant state in GL. It's just sooooo good.

[l_belev]

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.

[kyle_]

Lets face it. GL stopped being elegant some time ago, and there is no coming back.

This would simplify stuff to 'statically used - feature enabled', and be user business to fill the variable appropriately.

Perf. impact would probably be negligible, as DX10 does it that way (if im not mistaken, don't know DX10 all that well).

[l_belev]

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.