Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 09 Jul 2013
Offline Last Active Sep 10 2013 02:46 PM

Posts I've Made

In Topic: Compute Shader execution time

01 August 2013 - 06:52 AM

Have you tried using Intel GPA? I've had good Compute Shader dispatch time measurement using that tool (it does not require an Intel GPU for most functionality).

In Topic: SV_VertexID and ID3D11DeviceContext::Draw()/StartVertexLocation

28 July 2013 - 08:37 PM

The vertex ID is actually a running count of the vertices generated on the GPU, so it doesn't matter what you pass as the offset - it just starts at zero and counts upward.


Except in the case of indexed draw calls though, where it's the index from the index buffer (more sure about this one than the last post smile.png)

In Topic: SV_VertexID and ID3D11DeviceContext::Draw()/StartVertexLocation

28 July 2013 - 07:56 PM

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. smile.png


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.

In Topic: SV_VertexID and ID3D11DeviceContext::Draw()/StartVertexLocation

28 July 2013 - 05:12 PM

It's just an addition.


Draw(3, 0); // SV_VertexID (0, 1 and 2)

Draw(5, 2); // SV_VertexID (2, 3, 4, 5 and 6)

In Topic: CPU GPU (compute shader) parallelism

28 July 2013 - 08:26 AM

You don't have anything to worry about if I'm understanding you right.


Setting/unsetting shader resources, constant buffers, calling Dispatch etc are instructions that the GPU will execute sequentially at some point in the future, only overlapping work where it's valid to do so. Even if the CPU were allowed to run 50 frames ahead (it isn't) you're still just building up a buffer of commands that the GPU will execute in order without skipping any of them. The CPU is only allowed to get 1-3 frames ahead of the GPU before DirectX will block you from adding any more commands to allow the GPU to catch up. It doesn't do this because it's possible that the GPU will end up running multiple frames in parallel but because it would introduce unnecessary latency whereby the time between the CPU issuing the commands and the GPU actually executing them gets higher and higher.


Even if the GPU has got 3 frames worth of commands ready and waiting to go, it'll will run them sequentially and not skip any frames.