[991060]

Hi all:
I was told that user defined clip plane is disabled when using programmable pipeline in OpenGL, and my experiment also proved it. Now the question is how to emulate the clip effect. For now, I just evaluate the plane equation in pixel shader and output 0 if a pixel fails it. But it's far from a robust solution because it's quite possible that those clipped pixel is in front of the good pixel so that the latter is also clipped(because of z-buffering). Does anyone have a better method?

[Rodéric]

Using OpenGL Shader Language, clipping is done after Vertex Shader is applied, you need to fill a "special" register (don't remember the name, gl_ClipVertex most probably).

For the ASM Like interface (http://oss.sgi.com/projects/ogl-samp...ex_program.txt)
issue 20 talks about it, you can use the position invariant" option to get them in if you want, or just move to the nifty GLSlang !

Never faced the problem, but it seems like you are indeed forced to take care/handle it in the fragment program on the ASM like interface (if not using the option).

[991060]

Thanks for the info, I'm using Cg ATM. Gotta take a look at the spec of GLSL.

[Infinisearch]

I don't know about OGL but in DX pixel shaders i remember there being an PS instruction called texkill that was described as "being able to be used for arbitrary clip planes in the rasterizer". You might want to look into that.

[Humus]

It's much better to use real clip planes than emulating them with texkill. Texkill won't save any fillrate, unlike user clip planes that clips the actual geometry and therefore reduces the workload on the fragment shader a lot (assuming you're clipping away a lot).

[DemoCoder]

This brings up the question, was the "texkill" instruction in DX8 a real instruction, or was it just syntactic sugar for reusing alpha test hw, e.g. alpha = min(u,v,w)+bias, set up alpha test.

[Humus]

It's a real instruction. You can still use alpha testing to kill fragments that survived texkill.

[ehart]

Yes, like Hummus says, it is indeed an instruction. I have one correction for the above discussion though. Texkill does offer a fill-rate benefit over alpha test in that it allows a pixel shader to terminate immediately. In practice, this doesn't show up today, as all pixel engines are pipelined SIMD machines. You should however prefer texkill when it is reasonable, as it can be more efficient if/when the underlying computation model changes.

One other advantage clip planes have is that they antialias with multisampling. This is a non-insignificant quality issue.

-Evan

[Chalnoth]

Can you "draw" a quad in the z-buffer that would emulate the clip plane? This clearly won't work for all cases, but I suppose it depends upon what you want to do.

[ehart]

The quad thing won't work most of the time. If the only issue is shaders, you can draw the object once without shaders and the clip plane on. Then use a depth function of EQUAL, but this requires that the transform match what you can do in fixed function.

-Evan

[Simon F]

Originally Posted by ehart

Yes, like Hummus says, it is indeed an instruction. I have one correction for the above discussion though. Texkill does offer a fill-rate benefit over alpha test in that it allows a pixel shader to terminate immediately.

But it probably doesn't allow the HW to use early Z type tests so it would still be more costly than real clipping.

[Infinisearch]

@ the OP when you said that you were going to evaluate the plane equation in the pixel shader and output 0 if it failed it, what exactly did you mean by outputing 0? I'm still studying vertex shaders, i just started reading up on pixel shaders and haven't touched CG, HLSL, or GLSL. So when I thought about it I realized that i assumed that you meant outputing the pixel shader without moving anything into the 'output' register, is that what you meant or did what you say amount to a 'texkill' or some other way of killing the fragment?

@ Anyone - When you use texkill does it discard the z-write also? I'm assuming it does but its not explictly stated in the SDK.

[Simon F]

Originally Posted by Infinisearch

@ Anyone - When you use texkill does it discard the z-write also? I'm assuming it does

I believe that is the case.

[991060]

Originally Posted by Infinisearch

@ the OP when you said that you were going to evaluate the plane equation in the pixel shader and output 0 if it failed it, what exactly did you mean by outputing 0? I'm still studying vertex shaders, i just started reading up on pixel shaders and haven't touched CG, HLSL, or GLSL. So when I thought about it I realized that i assumed that you meant outputing the pixel shader without moving anything into the 'output' register, is that what you meant or did what you say amount to a 'texkill' or some other way of killing the fragment?

@ Anyone - When you use texkill does it discard the z-write also? I'm assuming it does but its not explictly stated in the SDK.

By outputing 0, I mean output float4(0,0,0,0) if the pixel fails the evaluation, it can be any color, depending on what color you use for the framebuffer clear. You can output 0 but you can't output nothing coz it's illegal, runtime will throw an error.

[991060]

Originally Posted by ehart

The quad thing won't work most of the time. If the only issue is shaders, you can draw the object once without shaders and the clip plane on. Then use a depth function of EQUAL, but this requires that the transform match what you can do in fixed function.

-Evan

Bingo, this is what I should've thought out, thanks for the tips. :P

[Mintmaster]

Originally Posted by ehart

Yes, like Hummus says, it is indeed an instruction. I have one correction for the above discussion though. Texkill does offer a fill-rate benefit over alpha test in that it allows a pixel shader to terminate immediately. In practice, this doesn't show up today, as all pixel engines are pipelined SIMD machines. You should however prefer texkill when it is reasonable, as it can be more efficient if/when the underlying computation model changes.

One other advantage clip planes have is that they antialias with multisampling. This is a non-insignificant quality issue.

-Evan

Originally Posted by Simon F

But it probably doesn't allow the HW to use early Z type tests so it would still be more costly than real clipping.

Just pointing out some info from ATI's developer site:

Texture instructions

Texture instructions are the pixel shader instructions that fetch texture such as TEXLD, kill pixel processing – TEXKILL, and TEXDEPTH for 1.4 pixel shaders outputs depth values. When it comes to texture instructions there are few things to be aware of. First, TEXKILL instruction does not interrupt pixel shader processing and provides pixel culling only after shader was completely executed. Thus positioning of the TEXKILL instruction in the shader does not make any difference and it is wrong to rely on early abortion of pixel shader execution.

In general TEXKILL and TEXDEPTH (or equivalent depth output in 2.0 pixel shaders with oDepth) should be used very carefully because they interfere with HYPER Z operation, and if possible should be avoided.

ehart, it's questionable that future architectures could actually quit early, but I suppose it's possible. Simon F is right, though, about it interfering with high speed HSR.

[ehart]

Mint,

I am aware of that info on TEXKILL. I wrote the OpenGL version of that document.

As far as the Z optimizations go, the biggest thing to remember is that they are just that, optimizations. You should take advantage of them whenever it is appropriate. Sometimes it just isn't, and that is why the driver can turn them off.

To clarify what I was saying about TEXKILL, if you are going to kill pixels anyway, you should kill them as far up the pipeline as possible. This means using TEXKILL where appropriate. (early depth test and HiZ are clearly higher still) I can't absolutely say it will increase performance in the future, but I can say that there are good reasons it should.

-Evan