Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualHodgman

Posted 23 March 2013 - 10:53 PM

1) Are your binding commands immutable?
2) My difficult is managing the binding commands. Say I have 2 drawables with different materials, each material have different shaders with different cbuffers layout (consider different slots usage only..).
2.a) bind view projection cbuffer (needs current shader slot info)
2.b) bind textures (needs its shader slot info)
3) I cant hold binding commands for none of these groups (except the material group), because they change depending on the current shader/material bound.

 
1) Yes.


2) I choose to simply be explicit with my cbuffer slot assignments. e.g. across different shaders that will be used in the same stage in the same way (e.g. opaque/gbuffer rendering), I'll choose to assign their camera cbuffer always to slot #1. I do this by defining the camera cbuffer in a header (which contains the register HLSL keyword), which is included into the various shaders.


2.a) If you've got the ability to enforce that every 'camera' cbuffer contains the same layout across shaders, then you've also got the ability to enforce the same register numbering scheme across shaders.
2.b) The textures that need to be bound and the shader that will be used by a material are both known at data-build-time, so assuming that the material is immutable, then there's no issue there.

[edit] if it's a runtime generated texture, (for post processing, or a deferred shadow mask in a forward renderer, etc), then I do the same thing as (2.a) -- I enforce that every shader specifies this texture binding on the same slot/register number, so that the same binding command can be used across shaders [/edit]


3) If I were to support that case, then the cbuffer binding command would contain a string and a cbuffer data pointer, and the string would be converted to a slot# at draw-time. This is pretty inefficient though, so I don't do this and instead do the above.


#1Hodgman

Posted 22 March 2013 - 11:14 PM

1) Are your binding commands immutable?
2) My difficult is managing the binding commands. Say I have 2 drawables with different materials, each material have different shaders with different cbuffers layout (consider different slots usage only..).
2.a) bind view projection cbuffer (needs current shader slot info)
2.b) bind textures (needs its shader slot info)
3) I cant hold binding commands for none of these groups (except the material group), because they change depending on the current shader/material bound.

 
1) Yes.
2) I choose to simply be explicit with my cbuffer slot assignments. e.g. across different shaders that will be used in the same stage in the same way (e.g. opaque/gbuffer rendering), I'll choose to assign their camera cbuffer always to slot #1. I do this by defining the camera cbuffer in a header (which contains the register HLSL keyword), which is included into the various shaders.
2.a) If you've got the ability to enforce that every 'camera' cbuffer contains the same layout across shaders, then you've also got the ability to enforce the same register numbering scheme across shaders.
2.b) The textures that need to be bound and the shader that will be used by a material are both known at data-build-time, so assuming that the material is immutable, then there's no issue there.
3) If I were to support that case, then the cbuffer binding command would contain a string and a cbuffer data pointer, and the string would be converted to a slot# at draw-time. This is pretty inefficient though, so I don't do this and instead do the above.

PARTNERS