Sharing global resource signatures

[RobertMtx]

I'm in the middle of setting up some global resource signatures that will be used by nearly all of the renderers in my engine, but I'm a little confused about the PipelineResourceSignatureDesc::BindingIndex.

My current plan was to split resources up based on required access. Currently, there are only three signatures, but that will probably become more complex in the future. Hopefully not by much.

• TextureArray - for dynamic texture lookups - nearly everything will use this
• Scene - for 3D camera data - everything except 2D elements will use this
• World - for gameplay entities - worldly objects and characters will render with this

So in this case, I could set BindingIndex=0/1/2. But what if an object needs the texture array and world signatures, but not the scene signature? WIll Diligent Engine need to create some type of wasteful placeholder at index 1 for those objects? Or will it even accept the setup with something missing there?

Also, I'm not sure if I should be setting things up like this, or if I should be creating a single resource signature that includes all needed resources for each possible scenario. With only a few signatures, it would be easy to pre-combine these into a couple specific signatures:

• TextureArray+Scene+World
• TextureArray+Scene
• TextureArray+World
• Scene+World

Would it be better to define very specific signatures for every case like this? Or a completely different method would be to just throw everything into one signature and let everything use it? Sorry if I'm asking dumb questions. This will probably all make more sense once I've learned more about these systems.

Thanks for any advice

[TheMostDiligent]

Currently, there are only three signatures, but that will probably become more complex in the future. Hopefully not by much.

You can generally have as many signatures as possible. However, your pipelines should not use more than 3 signatures simultaneously. This will be less performant and may not even be supported on lower-end hardware.

WIll Diligent Engine need to create some type of wasteful placeholder at index 1 for those objects?

No. You can use a pipeline with signatures in slot 0 and slot 2, and no signature in slot 1.

Signatures are designed to make Pipeline SRBs compatible with each other. Ideally, all your pipelines use the same signature so that all your resources are shared. The more sharing you can implement, the less resource switches will be necessary, which is better.

[TheMostDiligent]

So if I share my texture array through multiple signatures, I will have to update the texture assignments...

Think of SRB as an array of pointers to resources (which it actually is). If you change a binding in the SRB, this change will be visible for all pipelines that use this SRB.
Note that DYNAMIC variables have higher overhead than STATIC/MUTABLE. You should prefer the latter when possible. If you use DYNAMIC variables, there is no point in heaving them in separate signatures - you can simply change them before each draw call if necessary.

Is that also the case for sharing between multiple shader types?

You can make the same resource visible in multiple stages by specifying multiple shader types. You can then bind this variable by specifying any shader stage - it will be automatically visible to other shader stages.
https://github.com/DiligentGraphics/DiligentCore/blob/master/Graphics/GraphicsEngine/interface/PipelineResourceSignature.h#L143-L144

[RobertMtx]

So if I share my texture array through multiple signatures, I will have to update the texture assignments...

Think of SRB as an array of pointers to resources (which it actually is). If you change a binding in the SRB, this change will be visible for all pipelines that use this SRB.

I completely understand this statement, but want to make sure I'm not missing your point. Did you mean that my statement was correct, and that having two resource signatures linked to the same texture array will mean having two SRBs, both of which need updated when textures change? Or did you mean there is a way to link one texture array to both resource signatures through one SRB? I'm assuming you meant the former, but want to be sure.

You can make the same resource visible in multiple stages by specifying multiple shader types. You can then bind this variable by specifying any shader stage - it will be automatically visible to other shader stages.

I was hoping that was the case. Do we still have to call SRB->GetVariable()->Set(SHADER_TYPE_VERTEX,...) for each of the shader types? I wasn't sure about this, but after combing through nearly every sample project, I noticed these two lines in tutorial 8:

m_SRB[i]->GetVariableByName(SHADER_TYPE_DOMAIN, "g_HeightMap")->Set(m_HeightMapSRV);
m_SRB[i]->GetVariableByName(SHADER_TYPE_HULL,   "g_HeightMap")->Set(m_HeightMapSRV);

I haven't fully explored that tutorial, but it looks like the height map is a texture. Was this a specific case? It's possible I'm missing something obvious.

[TheMostDiligent]

Did you mean that my statement was correct, and that having two resource signatures linked to the same texture array will mean having two SRBs, both of which need updated when textures change?

If you have two separate SRB, you will have to change the binding in each SRB if you want this change to be visible to the pipeline that uses this SRB. Again, SRB is an array of pointers. Two SRBs are two separate and independent arrays. Changes two one are not reflected in any way on any other SRB.

Do we still have to call SRB->GetVariable()->Set(SHADER_TYPE_VERTEX,...) for each of the shader types?

You call Set for any shader stage and this will bind it for all stages that are shared with this stage.

but after combing through nearly every sample project, I noticed these two lines in tutorial 8

Yes, this needs to be updated. The tutorial was released before the shader stage sharing was implemented.

[RobertMtx]

Understood. That's great that we don't need to call Set() for every shader type.

I'm going to try using a single global resource signature for all PSOs, for now. I can always consider alternatives once I get further along. I believe nearly everything in the engine will end up using the same texture array. It seems to me that it would only make sense to have 2+ signatures if I end up splitting the texture array into 2+ different arrays, such as one for 2D drawing, and one for 3D rendering. Right now, they all use a single const-sized array, which pushes the oldest textures out when new textures are needed and it runs out of slots. If I split it up, it would end up making the prioritize-by-age mechanic less impactful (there could be many 2D images hanging around while the 3D textures fight for space).

Thanks much for all of the information and help.

[TheMostDiligent]

Note that a PSO does not have to use all resources in a signature (which is the whole point of having signatures). E.g. you may define a signature that defines two resources, A and B, and then define two pipelines, where one uses only resource A, and another one - only resource B.