Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.
Sign up to join this community
Why are there VSSetConstantBuffers(), GSSetConstantBuffers(), PSSetConstantBuffers() (and so on) instead of just one SetConstantBuffers() for all shaders?
Should I have completely separate constant buffers for every shader type or should I use different functions (e.g. VSSet.../PSSet...) to set the same constant buffer when it holds data used in multiple shader types (such as light position or transform matrices)?
Because the alternative is worse.
There's a set-constant-buffer function for each major shader type because it is often desirable to have a completely different set of constants for each (and also, because one does not necessarily utilize every type of shader in all scenarios).
It's usually the case that each stage of the shader pipeline does a drastically different operation. The vertex shader transforms geometry from model space to clip space, the geometry shader manipulates or produces new vertex or adjacency information, the fragment shader makes color determinations, and so on. Because of the wildly different intents of each shader type, one will usually have very different constant inputs.
It would not make sense (and would be drastically limiting) to homogenize the interface such that you could have only a single constant buffer for every stage of the shader pipeline.
In your case, if you happen to be able to usefully use the same constant buffer for all shader stages, then its fine to set that buffer to each stage using the appropriate method. As your usages of each shader stage become more advanced, the likelihood that you'll want exactly the same data across every stage will decrease.
StartSlot argument work? Do I have to use a different one for every constant buffer? Are there separate slots for different shader types (vs/ps/etc)?
\$\endgroup\$
In systems that manage distinct shader types, as opposed to those with uber-shaders, it's extremely helpful to be able to segregate the constant buffers for the different shader types - consider cases where the vertex shader, and it's associated constant buffer remain fixed - however the pixel shader definition alternates between a pure material based shader, a pure texture based shader, and a texture and material based shader - if this were conflated with the vertex shader constant buffer, then you could end up doubling the number (ok 2n - 1 for the purists :-) of constant buffer definitions for no good reason, not to mention requiring that some constant buffer information would be updated when it didn't actually need to be
