View Shader DirectX resources in shaders

Question

I'm a little confused right now and want to ask you all to help me sort out a few ideas.

In an HLSL shader (for example, to calculate a shader), I can declare StructuredBuffer sb, right? Should I bind it to a register, for example: register (t0)?

From the application side, I can call CSSetShaderResources (...). First argument (StartSlot), does it have anything to do with the small number behind the "t" in the register declaration?

If I set StartSlot as 0 (for example), and I set the second argument as 2. Do I tell the API that I will bind two Shader Resource Views, one in register (t0) and the other in register (t1)?

If I declare Texture2D tex [10]: register (t0), I can set it by calling CSSetShaderResources (0, 10, ...). Does this mean that the registers (t0 ~ t9) are exhausted?

Sorry for such a "quick fire" of questions, but I'm just very confused, and some of my tests seem to give positive results ...

Any help would be appreciated.

Answer 1

So give the answer in the order:

Yes, you can, of course, declare StructuredBuffer in a computational shader (in fact, you can declare it for any type of shader).

If you are not using an effects environment (methods), you need to declare a register, so the shader will know where to read your data (using the effects structure, it just does it under the hood, but you can still declare it explicitly).

CSSetShaderResources reports to associate N resources with an initial slot, so your description of using 0.2 is correct.

For an array of textures, I had to run PIX to test it, but it really is as you said.

Texture2D tex[10] : register(t0); 

This will mean that each texture index will be assigned a slot starting with the register you specified, so you need to call CSSetShaderResources (0,10, srvarray) to set them.

Answer 2

Very cool explanation! I was also embarrassed, and after your questions and explanations this is clear to me!

But I found a good example for this publication that I want to share. It seems to start a slot counter for each type of SetShaderResources. All shaders (VS, HS, DS, PS) have their own counter. Here is the code from the NVidia example:

Shaderclass Code:

 pd3dDeviceContext->HSSetShaderResources( 0, 2, Resources ); pd3dDeviceContext->HSSetShaderResources( 8, 1, &m_pRegularWatertightTexSRV ); pd3dDeviceContext->HSSetShaderResources( 9, 1, &m_pQuadWatertightTexSRV ); pd3dDeviceContext->HSSetShaderResources( 2, 1, &pHeightMapTextureSRV ); pd3dDeviceContext->DSSetShaderResources( 2, 1, &pHeightMapTextureSRV ); pd3dDeviceContext->PSSetShaderResources( 2, 1, &pHeightMapTextureSRV ); pd3dDeviceContext->PSSetShaderResources( 10, 1, &pNormalMapTextureSRV ); pd3dDeviceContext->PSSetShaderResources( 3, 1, &pTexRenderRV11 ); 

The first contains two resources, so the next slot (line 4) should add 2 for the initial slot (0 + 2 = 2). Each SetShaderResources should start at 0, but you can do it in different places in your code, so there are no 0 slots for DS and PS. Several times, if you delete a row, it still works, but the data is delayed. Now you see the first four in HLSL on the lines t0, t1, t8 and t9, another register was linked somewhere else.

HLSL Code:

 Texture2D<float> GregoryStencil : register( t0 ); Texture2D<uint> Index : register( t1 ); Texture2D<float> g_txHeight : register( t2 ); Texture2D<float> g_depth : register( t3 ); Texture2D g_FloorTexture : register( t4 ); Texture2D<float3> regularPatchControlPoints : register( t5 ); Texture2D<float3> gregoryPatchControlPoints : register( t6 ); Texture2D<float4> g_floorHeight : register( t7 ); Texture2D<float2> RegularWatertightUVs : register( t8 ); Texture2D<float2> QuadWatertightUVs : register( t9 ); Texture2D<float3> g_txNormal : register( t10 );