This may be applicable to non-DirectX pipelines, but I'm working with HLSL and DirectX 11. And this is a "curiosity" question.
I have a stream-out (geometry) shader which, if the vertex passes a depth texture sampling test (i.e., it's visible), outputs position, color and vertex ID (the ID is passed in from the vertex shader). The SO buffer gets just the vertex id (forming a "list" of visible vertices). The pixel shader input is just the position and color.
As I only need to determine the list of visible vertices occasionally, I create a "regular" GS from the same file, and bind that shader (rather than the SO shader and SO buffer target) most of the time.
When the "regular" GS is bound, the vertex id isn't used later in the pipeline. What looks like a very small overhead for using the "regular" GS is the pass-through of the vertex ID, so (for now) I'm just curious:
Where in the pipeline downstream of the GS is that extraneous data (the vertex ID) no longer "passed" along. Anyone know?
The reason I'm asking is to know, in future, what penalty (if any) there may be in streaming larger amounts of data (perhaps for debugging?) from the GS that's not used when the SO shader and SO targets aren't bound.
For the curious - a more detailed description of the data flow -
A pointlist of {Position, Color} from the vertex buffer to the VS (which also has SV_VertexID in the signature).
The VS outputs (and GS inputs) { Position, Color, vertex id }
In the GS, if the vertex position passes a depth sample (i.e., it's visible), the GS creates a billboarded quad (~4x4 pixels) to display just the vertex, and outputs 4 structs of { Position, Color, vertex id } as a TriangleStream. If the SO shader is bound (rather than the "regular" GS), the vertex id is streamed to the SO buffer (which gets processed later.)
>>> [ Where in this part of the pipeline is the vertex id no longer passed? ] <<<
The pixel shader input is { Position, Color } and simply outputs the color.