Do we and why do we need to arrange descriptor sets/slots in an ascending order of update frequency in vulkan

I've read some information about grouping of the descriptor sets according to update frequency in vulkan. That makes sense when updating the descriptor sets we can directly update the whole group with the same update frequency, it is surely good for performance.

I've also read some recommendations about the orders of different descriptor sets/slots in shader, they all recommend that the sets updated more frequently should be arranged more behind(i.e. in my opinion, with larger set id), but I can't fully understand that and I didn't find any useful information through google why should we follow that order.

The order goes like this:
> The descriptor set number 0 will be used for engine-global resources, and bound once per frame. The descriptor set number 1 will be used for per-pass resources, and bound once per pass. The descriptor set number 2 will be used for material resources, and the number 3 will be used for per-object resources. This way, the inner render loops will only be binding descriptor sets 2 and 3, and performance will be high.

Take the above quote from vkguide.dev as an example, I think the total binding times is the same if we use 0 for per-object resources and 3 for per frame resouces.

Would anyone please share me some useful tips around this question? Thanks in advance.

I think this is an understanding about the vulkan mechanism, the only thing I tried is to find useful information about this and none of the answer I found fully satisfied me currently.

> I think the total binding times is the same if we use 0 for per-object resources and 3 for per frame resouces.

What do you mean by "total binding times"? If you mean how many calls you make to vkCmdBindDescriptorSets, then yes, the number of such calls would be roughly equivalent. If however you're talking about the actual time it takes to execute those calls, that's a different matter.

The point of ordering descriptor sets by binding frequency is so that you don't have to bind as many sets.

Let's take the example from the site you linked to. You're rendering two objects. These objects are in the same pass and use the same material, but they have different per-object properties. And when I say "different", I don't mean that they just use different resources. I mean that the structure of the resources are different. One of them might have 2 2D textures, and the other might use 1 cubemap texture.

The point being that these two objects have different descriptor set layouts for set 3, but use the same layouts for sets 0, 1, and 2.

So you bind sets 0, 1, and 2. Then you bind set 3 and render one object, then bind set 3 again and render the other object.

Now, let's reverse the set order. So 0 is per-object, 1 is per-material, etc.

You start by binding sets 0, 1, 2, and 3. Why? Because you cannot bind to 1, 2, or 3 unless something was previously bound (within this command buffer) to 0. You can see this in the section on pipeline layout compatibility in the descriptor set section. Since we haven't started rendering anything yet, nothing is in set 0, so our first descriptor set binding command must bind something to it.

So then we render the first object. Now we want to bind a different set 0. However, we again run afoul of the aforementioned section.

Because the new descriptor set uses a different, incompatible layout from the previous one, binding just set 0 will "disturb" all of the sets above it. Thus sets 1, 2, and 3 become invalid.

Therefore, we must also re-bind sets 1, 2, and 3, despite using the same descriptors. And that's going to take longer because you're binding a bunch more stuff. And the implementation is going to have to redistribute how those descriptors are assigned to the resources for the pipeline.

That is, even though our two objects technically use the same layouts in sets 1, 2, and 3, Vulkan does not consider these sets to be compatible because they use different layouts for set 0. In our original version, binding to just set 3 works because Vulkan starts layout compatibility from set 0. The two layouts use the same layout for sets 0, 1, and 2, and only differ at set 3. Therefore, you can change just set 3 and the other sets remain fine.

Think of the sets within a pipeline layout like a stack of objects. You can easily change the top object on the stack without disturbing the ones under it. But changing the bottom item requires removing all of the ones above it.