Sign in to follow this  
Tispe

Setup for tbuffer?

Recommended Posts

Tispe    1468

Hi

 

I want to try out using a tbuffer to store an array of matrices and I have a few questions.

 

1. C++ Code

CComPtr<ID3D11ShaderResourceView> pShaderResourceView{ nullptr };
CComPtr<ID3D11Buffer> pBuffer{ nullptr };

D3D11_SUBRESOURCE_DATA sd;
ZeroMemory(&sd, sizeof(sd));
sd.pSysMem = pDataSrc;

D3D11_BUFFER_DESC bd;
ZeroMemory(&bd, sizeof(bd));
bd.ByteWidth = NumFloats * sizeof(float);
bd.Usage = D3D11_USAGE_DEFAULT;
bd.BindFlags = D3D11_BIND_SHADER_RESOURCE;

D3D11_SHADER_RESOURCE_VIEW_DESC rd;				//Can use nullptr instead?
ZeroMemory(&rd, sizeof(rd));
rd.Format = DXGI_FORMAT_R32G32B32A32_FLOAT;
rd.ViewDimension = D3D11_SRV_DIMENSION_BUFFER;
rd.Buffer.FirstElement = 0;
rd.Buffer.NumElements = NumFloats;

m_pDevice->CreateBuffer(&bd,&sd ,&pBuffer);
m_pDevice->CreateShaderResourceView(pBuffer, &rd, &pShaderResourceView); 

The documentation says:

 

ID3D11Device::CreateShaderResourceView method

[...]
pDesc [in]
Type: const D3D11_SHADER_RESOURCE_VIEW_DESC*
Pointer to a shader-resource view description (see D3D11_SHADER_RESOURCE_VIEW_DESC). Set this parameter to NULL to create a view that accesses the entire resource (using the format the resource was created with).

 

For a tbuffer, can I just ignore the D3D11_SHADER_RESOURCE_VIEW_DESC and pass a nullptr instead?

 

 

2. HLSL

cbuffer ModelConstantBuffer : register(b0)
{
	float4 sunlightvector;
	float4 sunlightcolor;
	float4 ambientlightcolor;
	float4 cameraposition;
};

cbuffer InstanceIndices : register(b1)
{
	uint4 InstIdxArray[4096];
};

tbuffer WorldViewProj : register(t2)
{
	float4x4 MVP;
};

tbuffer World : register(t3)
{
	float4x4 Model;
};

Texture2D Texture;
SamplerState ss;

When setting a regular texture with PSSetShaderResources(0, 1, &pShaderResourceView); which of the (t#) regisers gets bound to the ID3D11ShaderResourceView (0 right) ? Which one does Texture2D Texture use, should I  use : register(t#) on the sampler also?  

 

When setting a tbuffer with VSSetShaderResources(0, 1, &pShaderResourceView); does that use the same (t#) registers as in the PS method? If I have both shaders in HLSL in the same .hlsl source file how do I seperate the registers?

 

 

3.

Are (b#) and (t#) separate within the same shader, so I can use both (b0) and (t0)? As above, when I move over from VS to PS, what happens to (t#) and (b#) registers? If (t1) is set with VSSetShaderResources, can (t1) be read from the pixel shader without a PSSetShaderResources call?

 

Cheers

 

Share this post


Link to post
Share on other sites
Hodgman    51328

1. Yes.
 
2. Yes, PSSetShaderResources( N, ... ) binds a view object to register tN for the pixel shader.
I would highly recommend using manual register allocation for everything. At the moment, 'Texture' is probably assigned to t4, and 'ss' is probably assigned to s0, but you'd have to use the shader reflection API to find out for sure. IMHO it's much easier if you just add ": register(t4)" and ": register(s0)" the the shader source yourself.
 
Each 'stage' (VS/PS/etc) has their own resource slots/registers.
If you write:
PSSetShaderResources(0, 1, &a);
VSSetShaderResources(0, 1, &a);
PSSetShaderResources(1, 1, &b);
Then both the vertex shader and pixel shader will have 'a' bound to t0, but only the pixel shader will have 'b' bound to t1.
 
or if you write:
PSSetShaderResources(0, 1, &a);
VSSetShaderResources(0, 1, &b);
Then the pixel shader will have 'a' bound in t0, but the vertex shader will have 'b' bound in t0.
 
3. Yes, they're separate. t# is for textures/tbuffers. b# is for cbuffers. You can have a cbuffer in b0 and a texture in t0.
VSSet* only affects the vertex-shader's bindings. If the pixel-shader needs to use that resource, you also need a PSSet call.
 
If this helps, some psuedo code for how the bindings might look inside the API:
 

struct ShaderBindings
{
  ShaderResourceView* t[16];//textures and tbuffers
  Buffer* b[16];//constant buffers
  SamplerState* s[16];//samplers
};
struct PipelineBindings
{
  ShaderBindings vs;
  ShaderBindings ps;
...
};

p.s. And yes, the MSDN could explain this a lot better than it currently does...

Edited by Hodgman

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this