tests i can use before fragment program

[Hampel]

An rough front-to-back rendering order of your objects could also help a little bit without the need to add the additional z-only pass...

@dorbie: what hardware/driver/vendor has problems with GL_EQUAL and early z-reject? And what about GL_LEQUAL?

[jwatte]

I'm not dorbie, but I'm assuming you meant to ask me: LEQUAL is fine on all hardware. We're told that EQUAL reduces acceleration on at least the Radeons (I forget about the others).

[harsman]

It's a hardware issue. You can't do early out without (ab)using early z and stencil testing on anything except the GeForce 6800 series.

[Humus]

Originally posted by zed:
from looking at the spec it seems perpixel fragment programs come before alpha,stencil,depth,scissor test etc.
basically since my fragment programs are pretty expensive (less than 5fps for a 640x480 window) im wondering if theres anyway i can bypass the fragment test if a certain condition is met, eg only perform on pixels whose screenalpha's are greater than 0.5.

though i believe what i want aint possible
so my next best bet is to discard the fragment as soon as possible in the shader
whats the best way of doing this

FWIW i would assume this would be, stuck right at the start of the shader
if ( a > b )
discard;

BUT on my gffx5200 66.00drivers runs a lot slower than
if ( a < b )
{
..
..
}

cheers zed

First, one thing to note regarding the < and > operators. Try to avoid using >, use >= instead whenever possible. Same with <=, avoid it and use < instead whenever possible. This is because < maps directly to SLT and >= maps to SGE (which is essentially just SLT with reversed operands). Other comparisons require more instructions.

Regarding early-outing from a fragment shader, take a look at this demo:
http://www.humus.ca/?page=3D&id=50

Basically, I draw the compare function to alpha in a first pass, and use alpha testing to set stencil to 1 for selected pixels. In the next pass early stencil rejection throws away the fragments, which saves loads of fragment processing.

In this case I'm using the light radius as the determining factor, anything outside the light radius will be rejected, but you can use any rejection critera.

[zed]

cheers humus, yeah from further research it seems if (..) statements (unless they are constant bool's) are useless on gffx's for early out. im gonna have to implement something like u suggest on your site involving extra passes

>>if possible "discard" as much as you can in the vertex program.>>

oh yeah to clarify this aint possible is it? ie it doesnt matter what happens in the vertex program the result will always get passed to the pixel shader

[V-man]

From the documents, it says that discard is for fragment shaders only. The compiler should flag an error if you use in a vertex shader.

I don't see how a video card would handle a "discard" on the vertex processor anyway.
It would be like killing a polygon and any polygon that is sharing that vertex.

[Humus]

Ah, something for future hardware. Discard on vertices to perform polygon reduction in realtime.