UltraShadow only on NV35

[Reverend]

I'm sorry if this has been revealed here before.

So... I asked NVIDIA why the depth bound checks ("UltraShadow") is only available in the NV35 and not across the entire NV3x line. The way I worded my question was such that I felt that perhaps it could even be done on non-NVIDIA hardware.

It is most definitely in HW.

The chips have early culling units and in the raster operations have this extra state (the z near and z far values) in order to do the check. The test occurs between the depth value of the pixel and the specified depth bounds.
It is not based upon the fragment geometry. This requires specialized hardware. If it can't store those values and perform the test i.e. eliminate fragments based on the test results, then it won't work...

The ability to do this is not in the legacy hardware because it wasn't invented at the time.

I have not asked them follow-up questions based on their answer above.

 

[cho]

and will be in nv36, nv4x

 

[overclocked]

It seem´s like a easy thing to implent in logic so why did they not do it for the whole NV3xx line!?

 

[RussSchultz]

because it wasn't invented at the time.

 

[Hyp-X]

It shouldn't be to hard to implement it in software if you have a spare bit in stencil.
It won't be as fast as the fully hardware solution, but I it should still provide a speedup.

 

[Xmas]

It shouldn't be to hard to implement it in software if you have a spare bit in stencil.
It won't be as fast as the fully hardware solution, but I it should still provide a speedup.

Please, give us an explanation how that should work. I can't see neither how it's supposed to work nor how it should save bandwidth and/or fillrate compared to the usual shadow volume rendering.

 

[Hyp-X]

Ultrashadow throws away pixels it destZ < minZ or destZ > maxZ.
My idea is to use two stencil pass to mark the pixels with destZ < minZ or destZ > maxZ and during shadow volume pass reject based on that value.
Shadow volume passes do not normally reject by stencil so you get that for "free".

It would save fillrate since stencil reject can be done on high level, and for those pixels with out of range Z values it saves bandwidth since they are not updated (this is exacly as with Ultrashadow).

The cost is to draw two screen space quads to mark pixels, and of course there can be hardware implementation disadvantages.

 

[AndrewM]

The cost is to draw two screen space quads to mark pixels, and of course there can be hardware implementation disadvantages.

That's what costs fill rate my friend.

 

[Tonyo]

Ultrashadow throws away pixels it destZ < minZ or destZ > maxZ.
My idea is to use two stencil pass to mark the pixels with destZ < minZ or destZ > maxZ and during shadow volume pass reject based on that value.
Shadow volume passes do not normally reject by stencil so you get that for "free".

What "ultrashadow" gives you is just scissoring on depth. You can achieve the same and at a better discard rate (polygon level) using zfar-znear clipping.
Even better, because "ultra shadow" is scissoring only on depth, if you use user clipplanes you can match exactly your desired bounding region (which is something you cannot do with "ultrashadow").

There's a caveat with this, though, and it's that OpenGL invariance is not guaranteed on clipped geometry. Depending on your scenario you could fall into z-fighting issues if using clipping (polygon level test) instead of a fragment level test.

 

[Xmas]

What "ultrashadow" gives you is just scissoring on depth. You can achieve the same and at a better discard rate (polygon level) using zfar-znear clipping.
Even better, because "ultra shadow" is scissoring only on depth, if you use user clipplanes you can match exactly your desired bounding region (which is something you cannot do with "ultrashadow").

There's a caveat with this, though, and it's that OpenGL invariance is not guaranteed on clipped geometry. Depending on your scenario you could fall into z-fighting issues if using clipping (polygon level test) instead of a fragment level test.

Ultrashadow cannot be replaced with clipping planes, because it operates on destination Z, not depth of the currently rendered polygon.

Hyp-X,
I don't think your suggestion would be very effective, besides the problems of taking one bit from stencil.

 

[Hyp-X]

What "ultrashadow" gives you is just scissoring on depth. You can achieve the same and at a better discard rate (polygon level) using zfar-znear clipping.
Even better, because "ultra shadow" is scissoring only on depth, if you use user clipplanes you can match exactly your desired bounding region (which is something you cannot do with "ultrashadow").

No, you appearently didn't get what ultra "ultra shadow" is.

It discards fragments based on the destination-Z (the Z value that is already in the depth buffer), not the fragment's Z-value.

Ps.: Using clip-planes without caping produces artifacts...

 

[Hyp-X]

The cost is to draw two screen space quads to mark pixels, and of course there can be hardware implementation disadvantages.

That's what costs fill rate my friend.

Assuming you mean the first part of the sentence...
The screens space quads shouldn't have to be full screen, it should only cover the area the light can affect. It might turn out the fill rate it saves is much more than the fill rate it cost.

 

[AndrewM]

It might turn out the fill rate it saves is much more than the fill rate it cost.

I highly doubt it. You're doing MORE work rather than less.