Multi draw support when using RenderMeshIndirect

The new RenderMeshIndirect mentions SV_DrawId for multi-draw support. However, i have been unable to read out this shader semantic at all. I cant find much information on this either, how can i get the draw id in dx11 or 12?

There is no SV_DrawID in D3D11/D3D12. I think this is some cross reference from gl_DrawId and its multi-draw rendering. Corresponding functionality exists in D3D12 by using indirect drawing. But approach taken by D3D API will get correct data in buffers based on resurce views used during ID3D12CommandSignature creation. So it is mystery how to correctly use InitIndirectDrawArgs(drawId) function in shader with non-zero drawId parameter.

I think i did figure it out. Im implementing this tutorial in Unity:

In the case of doing gpu driven rendering, and culling in a compute shader. The compute shader passes data to the vertex shader, e.g. the visible indices. It also needs to know the drawID.

We can therefore also pass along the drawid. If you get your vertex data by using the instanceId, you can make another structuredbuffer with drawids.
Here on page 23 this is mentioned.


Intresting. @TJHeuvel-net thanks for links. Did you manage to implement this with RenderMeshIndirect ?

No, sadly.

DirectX11 has DrawIndexedInstancedIndirect, as you can see this is only for a single draw command. When you call RenderMeshIndirect in dx11 with a count of 4 Unity will simply do 4 of these draw commands. Thats a limitation by the API, not much they can do there.

What they do offer is a draw-id for those draw commands, they fill in that data for us. If you follow what they do in UnityIndirect.cginc you can read out that variable, its called *unity_BaseCommandID*. I'd highly recommend seeing what happens using something like RenderDoc or PIX.

The sad part is that DirectX12 does support this construction of a single API call for ExecuteIndirect that contains multiple draw commands, see the count arguments. This isnt exposed by Unity though, for compatability(?) with dx11 they still do the same workaround. That wouldnt even be necessary in the future, lets hope they update their apis!