Scissor test: before or after ??!

The pixel processing pipeline described in the DirectX documentation is abstract/conceptual.

An actual hardware implementation of that pipeline on a specific manufacturer's GPU can, and often will, be different to that abstraction.

The only requirement for the hardware manufacturer is that the pipeline produces the same results, at the same stages.


One GPU may scissor before the shader; another GPU may scissor after the shader; another GPU may not actually support scissoring at all and achieve the effect some other way; another may change how/where it performs scissoring depending on what other states are set (e.g. alpha test, stencil, etc).

All that /really/ matters is if the device caps say the device supports scissoring, and you set a scissor region, you get a scissored output.

The same applies to most other things in the pipeline - alpha test and scissor test happen before Z test in the conceptual model, but most modern GPUs have some form of hierarchical Z rejection that can happen before even the pixel shader.


Beware: GPU specific 'optimisation' advice from one manufacturer can often conflict with what's best for another manufacturer's GPU, or even previous generations of their own GPUs - when you average the advice over the years from all the manufacturers, funnily enough you end up with something remarkably similar to the conceptual pipeline in the documentation [wink]

Damned.

Here is my problem:
I'm realizing a dynamic lightning system that perform a pass per light (it will remind you a certain game).
The idea (that was this game philosophy too) is that a light may just lit a little part of an object and of the screen - the large rest part of the screen being just lit by the ambient pass. It limit the area of expensive blinn shader. But you know that, this is well known - I hope^^.

So for me, there is two solutions:

1) a scissor test.
2) a viewport change (complicated way, and what about this change impact on the performance ?).

"I just don't know what to do..." (hum.. its a music lyrics that stay in my head..)

Quote:

Beware: GPU specific 'optimisation' advice from one manufacturer can often conflict with what's best for another manufacturer's GPU, or even previous generations of their own GPUs - when you average the advice over the years from all the manufacturers, funnily enough you end up with something remarkably similar to the conceptual pipeline in the documentation

^^ Haha, I like this explaination. That's exactly what i'm looking for, when that becomes complicated. So thank you for it.

Hey. I just did the test with a scissor rect. No doubt that it is perform before the pixel shader on my 6600. (All my tests are fully benchmarked:)

I will perform this test on a X700, and on a geforce FX too, pretty soon, and post here the results.
I feel that on this cards the scissor test will be well implemented. Because that's a shader consideration. Geforce 2 for exemple, may have this scissor test where it will (almost).

EDIT: Orthographe...

[Edited by - Woodchuck on October 26, 2006 2:53:55 AM]

I'll finaly use user-defined clip planes... =)

I'm a bit confused - scissor rectangles have been used to limit fill rate consumption for shadow volumes, but I'm not aware of them having been used to limit the application of expensive pixel shaders. Z Pre-pass and front-to-back ordering is more common for that sort of thing.

Are you trying save fill, or avoid expensive fragments?

...oops, forgot to login-in.

Quote:

Original post by Anonymous Poster Quote: Original post by JasonBlochowiak Are you trying save fill, or avoid expensive fragments? Take the example of an omni light that lit a part of a wall. The omni have an attenuation, then the most part of the wall will be "black". The blinn shader is very expensive then you have a real performance win to limit the action of the shader to the light radius.

Ok, I could see that would save PS ops, but is the extra setup and overhead really a win?

Quote:

Original post by JasonBlochowiak Quote: Original post by Anonymous Poster Quote: Original post by JasonBlochowiak Are you trying save fill, or avoid expensive fragments? Take the example of an omni light that lit a part of a wall. The omni have an attenuation, then the most part of the wall will be "black". The blinn shader is very expensive then you have a real performance win to limit the action of the shader to the light radius. Ok, I could see that would save PS ops, but is the extra setup and overhead really a win?

Completely (I did the test). The condition is that the mesh must be "low poly". Like Doom3, for not quote it =)

[Edited by - Woodchuck on November 1, 2006 4:10:59 AM]

How do you performe Z-Scissoring in DirectX?