Jump to content
  • Advertisement
Sign in to follow this  

Setup for tbuffer?

This topic is 1233 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts



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 };

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

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

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]
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?




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?




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?




Share this post

Link to post
Share on other sites

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
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!