What is the purpose of the maximum number of sets in a Vulkan descriptor set pool?

user_3536729 0
Viewed 764

In the VkDescriptorPoolCreateInfo structure we specify the maxSets field that configures the maximum number of descriptors sets that can be allocated from a given pool. But what exactly is this maximum setting doing under the hood (if anything)?

For example, we could create a simple application with a pool containing (say) three combined image samplers and three uniform buffers, with the intention of creating three descriptor sets (sampler and UBO) for a triple-buffered strategy.

But the application could theoretically allocate anywhere between zero and six sets from this pool depending on the layout of the allocated descriptor sets and what we configure maxSets to be. i.e. the pool does not know what layouts will be requested, only the available number of each resource type.

So is maxSets a hint to the hardware? Or is there some other reason? I have looked through the documentation but cannot find anything other than this line in the spec:

maxSets is the maximum number of descriptor sets that can be allocated from the pool.

Or is it used by Vulkan to double-check that the application does not allocate more sets than the configured pool size? To continue the example we could configure maxSets to four (valid if not logical) but if we try to allocate a fourth descriptor set from the pool the allocation will fail anyway because the pool is exhausted, so why configure a property that is the responsibility of the application?

vulkan
1 Answers

The point of having limits on a pool is to be able to pre-allocate the resources needed for doing something or failing that, at least have a fixed limit for the number of allocations that the user will allocate from it. The goal is that, at some point, the system will no longer have to runtime allocate resources when you request resources from the pool.

Individual descriptors take up some form of resource, whether CPU, GPU, or both. But bundling them into descriptor sets can also takes up resources, depending on the implementation. As such, if an implementation can pre-allocate some number of set resources, that would be good for minimizing runtime allocations.

Now, it might have made more sense to define a descriptor pool by providing a number of descriptor layouts and saying that you're only going to allocate some number of sets of each particular layout. But that would be a very constrained descriptor pool model.

So the current interface makes for a compromise between such a strict model and a model that only looks at descriptors rather than sets.

user_7340690
Related