Bindless Texture Array Update Pattern

[RobertMtx]

I'm wondering what the best approach would be for updating bindless textures through the SRB SetArray() function, such as in a situation where there are already an unknown number of textures binded, and we are now needing to bind different textures?

If I have 20+ pipeline states, and they all share the same texture array bindings, then I need to iterate all of my pipeline states and update all of these bindings each time a new object is added or removed from the scene that uses different textures - is that right? One improvement would be to wait until something is about to render before doing the GPU updates, in case many objects are removed/added before the next render takes place.

Anyway, if I have a lot of textures in my array, and I add, say, 8 more, what would be the best way to update these in the array? Would it be better to iterate the entire array and update the exact entries that changed? Or would it make more sense to find the full range of modified slots, and do one single update, even if many textures in that range didn't change? Or would it be better to just update the entire array, regardless of how many textures changed?

Unfortunately, I'm not sure how much processing is involved with changing a single texture binding within the array. On top of that, some GPU data doesn't like to mix new data with old data, preferring us to "discard" the old stuff. If this is one of those cases, it may make more sense to just send the entire array at once? Any advice on this would be really appreciated!

Edit: Right after posting, I went into the source code and notice that SetArray() just calls BindResource() for each individual element of the array, so that pretty much answers my question. Anyway, I would still appreciate any information/advice on how to manage bindless textures. I've looked into D3D12 info, but most of the advice for that won't directly work with Diligent. For example, I'm not sure how large to set my texture array in HLSL.

[TheMostDiligent]

If I have 20+ pipeline states, and they all share the same texture array bindings, then I need to iterate all of my pipeline states and update all of these bindings each time a new object is added or removed from the scene that uses different textures - is that right?

You likely need to use a pipeline resource signature that defines a resource layout that can be shared between multiple pipelines. This way all your 20 PSOs will be able to use the same SRB and you will only need to update one SRB. Take a look at Tutorial 22.

Anyway, if I have a lot of textures in my array, and I add, say, 8 more, what would be the best way to update these in the array?

Just update the entries that have changed.

Unfortunately, I'm not sure how much processing is involved with changing a single texture binding within the array.

This largely depends on how you use your array which is reflected in the type of the variable:

• Dynamic variables are updated every time you commit an SRB even if the bindings have not actually changed (unless you use the DYNAMIC_RESOURCES_INTACT flag). They are the most expensive and there is an overhead at every commit SRB call
• Static variables can only be bound once directly to signature or PSO and may not be changed - there is no overhead when binding them
• Mutable variables can be set once in one instance of an SRB. If you want to change any, you need to create a new SRB and bind all mutable variables. You can also use the SET_SHADER_RESOURCE_FLAG_ALLOW_OVERWRITE if you can guarantee that you don't overwrite the resources that are currently in use by the GPU.

There are many options that depend on what you need.

For example, I'm not sure how large to set my texture array in HLSL.

If you are using DX12/Vulkan, the array may be pretty large. Updating the entire SRB will be expensive if you have a lot of textures, so you will likely need to use the SET_SHADER_RESOURCE_FLAG_ALLOW_OVERWRITE flag to update only few textures without affecting others

[RobertMtx]

If I have 20+ pipeline states, and they all share the same texture array bindings, then I need to iterate all of my pipeline states and update all of these bindings each time a new object is added or removed from the scene that uses different textures - is that right?

You likely need to use a pipeline resource signature that defines a resource layout that can be shared between multiple pipelines. This way all your 20 PSOs will be able to use the same SRB and you will only need to update one SRB. Take a look at Tutorial 22.

I was really hoping something like this was possible. Thanks for pointing that out. I probably would have had to restructure half my setup after discovering it was possible to share variables like that in the future.

Anyway, if I have a lot of textures in my array, and I add, say, 8 more, what would be the best way to update these in the array?

Just update the entries that have changed.

A feature request would be the capability to send one element at a time to a shader array. Or rather, allow the caller to send one element to a slot index of a shader array. Something like this:

virtual void DILIGENT_CALL_TYPE ShaderVariableBase::SetArrayElement(IDeviceObject* object,
                                        Uint32                    array_index,
                                        SET_SHADER_RESOURCE_FLAGS Flags) override final
{
    // ... error checking ...
    static_cast<ThisImplType*>(this)->BindResource(BindResourceInfo{array_index, object, Flags});
}

Not really a big deal, though. Thank you for the help!

[TheMostDiligent]

A feature request would be the capability to send one element at a time to a shader array.

You can already do this with SetArray method. Not sure why you need another function. You can also easily write your own function SetShaderVariableArrayElement(Variable, Object, Index, Flags) if you don't like the syntax.

[RobertMtx]

Yeah, its not a big deal in my case, now that I understand how it works. It's just easy to mistakenly assume that a function like this wouldn't or shouldn't be called once per element.

[TheMostDiligent]

If you can set multiple elements, you should. The implementation may be optimized later to better handle setting multiple elements.