I'm moving some code from the CPU to GPU and needed to render to a 3D texture. I figured I'd use the geometry shader to generate the trianges and just use a simple vertex shader to pass vertex id's on to the geometry shader. Something like this for the vertex shader:

uint vs_main (uint id : SV_VertexID) : VERTEX_ID {
	return id;
	}

That way I don't actually need a vertex buffer.

Now I'd like to be able to specify a range of z slices to render (start at slice 5, render to slice 10). I could pass the start value in a constant buffer but ID3D11DeviceContext::Draw() has the StartVertexLocation parameter. I was wondering, but couldn't find any definitive, on how the StartVertexLocation interacted with SV_VertexID.

Any ideas? Comments? Suggestions?

That was my original thought, but http://www.altdevblogaday.com/2011/08/08/interesting-vertex-shader-trick/ seems to state otherwise. I read somewhere (I forget where and can't seem to find it again) that DrawInstanced() (or perhaps DrawIndexed() I don't remember exactly) could be used instead, but again the MSDN docs aren't clear, and they didn't elaborate.

So it does, I must admit I didn't try it, but I can't understand why it would be anything other than additive. That said, since he's gone to the effort of writing an article on it, assume he's right until I've had a go at testing it myself.

EDIT: As expected, he was right in that regard. The sample applies to the 'startInstanceLocation' on DrawInstanced too, so you can't hijack that either.

I think you're just going to have to spend a couple of minutes adding a constant buffer I'm afraid. There's no need to use a Geometry Shader though. Depending on what you're doing in the pixel shader, you may find it'd be easier and faster to bind your 3D texture as a UAV on the pixel shader and have it calculate/export the values for all N slices you're interested in rather than using the geometry shader's SV_RenderTargetArrayIndex functionality, producing N quads and running the pixel shader a factor of N more times. This way any shared calculations between the N sheets only need to be calculated once.

The code is being moved from the CPU to the GPU and right now it just generates 3d terrain from a function thats just a a bunch of noise functions, so there's really no inter-pixel sharing needed. Any function that needed to share data could easily be reworked as a gather operation, I can't think of any place where I'd need an explicit scatter operation, so I don't NEED a UAV. My thoughts were that a UAV would have worse cache performance, and might need to use sychronization primitives, than just using two 3D textures and 'ping-ponging' back and forth where needed.

Do you have experience with UAV's? Is the performance better than I've been lead to expect?