early fragment kill / stencil buffer & fragment shader

[Bregosch]

Hi,

I'd like to know if it is possible to perform an "early fragment kill". By that I mean that when the stencil buffer "discards" a pixel the pixel shader MUST NOT process it anymore.

Currently, if the stencil buffer discards a pixel, the pixel shader regardlessly processes the pixel...

Any ideas on this topic? Perhaps there's even a flag for exactly this?

Thanks,
Thomas

[pocketmoon]

Originally posted by Bregosch:
Hi,

I'd like to know if it is possible to perform an "early fragment kill". By that I mean that when the stencil buffer "discards" a pixel the pixel shader MUST NOT process it anymore.

Currently, if the stencil buffer discards a pixel, the pixel shader regardlessly processes the pixel...

Any ideas on this topic? Perhaps there's even a flag for exactly this?

Thanks,
Thomas

Not an answer but I would love to see access to the (current) stencil value in fragment shaders.

[Bregosch]

Yes that would (almost) be sufficient! But still not the fastest way to solve this problem...

Anyone here with the solution? Anyone?

[zeckensack]

Current graphics chips already do this. It's called early-Z rejection, or something close to that. Methinks it works for stenciling too, but not for all combinations of render state.

But note that it's still possible not to see a gain. The problem is that a discarded pixel leaves behind an empty fragment pipe which needs to be filled again - think 'branch misprediction penalty', and you're close.

[Bregosch]

But how can I make use of this feature? I mean, is this early rejection through the stencil buffer automatically active on the NV30 (my developing environment)?

I think you're right with the low (or even none) performance gain. But speed isn't that critical for my app, I just wish to use the stencil buffer to mask out pixels completely, with no shader processing.

[pbrown]

Apologies for being away from this board for so long.

"Early fragment kill" (which has many marketing names) works automatically, and is initated by the driver whenever possible. Some such algorithms kill with 100% accuracy; others may fail to kill fragments that will be killed at the end -- these are always backed up by a normal "late fragment kill". There is generally no guarantee that any given fragment would be killed before it's shaded, and other than by measuring performance, there's no way for you to tell. Fragment programs have no side effects....

zeckensack is right that is sometimes leave bubbles in the pipeline (when a long string of fragments are being killed one after another). But if you are running a long, complicated shader, things tend to back up anyways.

All you have to do to use this feature is to turn on GL_STENCIL_TEST and/or GL_DEPTH_TEST as appropriate and let us do the rest.

Note that a depth-replacing fragment program (one that writes result.depth on ARB_f_p or o[DEPR] on NV_f_p) limits the applicability of any early depth test operations, since you have to run most (if not all) of the fragment program to have a depth value to test.

[Bregosch]

Thank you all very much for your answers!!

I guess I know now how to proceed. I use a texture in my shader to look up which fragment should be processed and which shouldn't. And then I kill the unwanted ones Works fine!