🔒 Locked

Shaders and Constant Buffer behavior?

Started by trick Apr 12, 2012 at 12:24 AM 2 replies 2.2k views

Original Post

Apr 12, 2012 at 12:24 AM

When setting constant buffers to a shader, does DirectX assignn it to the specific shader that is currently loaded, and remember it is for that shader? Or does it keep the same buffer applied through shader changes, and the buffer must be changed as well?

As an example, say I have two different vertex shaders, and each has it's own constant buffer, like the simplified snippet below.


 ID3D11Device* Device;
 ID3D11DeviceContext* DevCon;
 ID3D11VertexShader* Shader1;
 ID3D11VertexShader* Shader2;
 ID3D11Buffer* CBuff1;
 ID3D11Buffer* CBuff2;
 //initialization code
 
 //Render Routine
 DevCon->VSSetShader(Shader1, NULL, 0);
 DevCon->VSSetConstantBuffers(0, 1, CBuff1);
 //Draw stuff with shader1
 DevCon->VSSetShader(Shader2, NULL, 0);
 DevCon->VSSetConstantBuffers(0, 1, CBuff2);
 //Draw stuff with shader2

Now, if I then swap back to Shader1...


 DevCon->VSSetShader(Shader1, NULL, 0);

Does DirectX remember to use CBuff1, or do I need to reset it as well?

21st Century Moose

Apr 12, 2012 at 12:44 AM

It'll keep the currently set cbuffer until you change it yourself.

Hornsj3

Apr 12, 2012 at 1:06 AM

To expand the answer above, I believe it works this way: (I'm 4 months into DirectX, so take this for what it is worth).

There are a number of constant buffer registers, to which you can bind constant buffers. These registers need to be bound for each shader stage explicitly.

What this means is that you bind the constant buffers to the shader stages, not the particular shader. You can bind one shader to the pixel stage, bind the constant buffer to a constant buffer register, draw, and then bind another shader to the pixel shader. If you don't explicitly change what is bound to a constant buffer register, it will remain bound.

I hope that is clear.

NightCreature83

Apr 12, 2012 at 10:37 AM

Any renderstates stay set untill you explicitly set a new one. The fastest instruction is always the one you don't have to execute, and thats exactly how the DX runtime operates

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.