Hi I’m studying Vulkan API, specifically on VkDescriptorPoolsize.
To be obvious for my question, I need to explain the basics of VkDescriptorPool.
According to my study, we have to create VkDescriptorPool and then,
we can allocate VkDescriptorSets from the pool.
when creating VkDescriptorPool, we have to insert two data : VkDescriptorPoolSize, maxSets.
the maxSets is the easy one, because it specifies how many descriptorSets we can allocate from the pool.
the problem is VkDescriptorPoolSize. We have to specify the count and the type of Descriptors in VkDescriptorPoolSize, which will be used across all VkDescriptorSets from the pool.
Is my explanation correct? If so, my real question is…
when I specify less count than what I will use,
omit types that I will use in the VkDescriptorPoolSize,
I’ve not met any error message.
I even tried to set 0 count for VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER and
skip the VK_DESCRIPTOR_TYPE_COMBIEND_IMAGE_SAMPLER in VkDescriptorPoolSize.
But I didn’t meet any error message.
In addition, the application does the same thing, regardless of the VkDescriptorPoolSize.
(I just used the Willems offscreen Example.)
Finally I’m here with my questions :
Why does not Vulkan tell me any errors? (I’m also using LunarG Validatoin Check)
What’s the overhead if I specify less/more count in VkDescriptorPoolSize than what I will use ?
What’s the overhead if i skip some descriptor type in VkDescriptorPoolSize?
Because it is not invalid. It is not a logical error.
There might be a warning, but that is a matter of taste whether to issue one.
Implementation dependent. You can use pAllocator to sate your curiosity about what it does with the host memory. Assumably if you specify more, you waste some insignificant amount of memory but possibly help the pool defragment. If you specify less I would not expect any special overhead, except that your pool may fail and you might be forced to create a second one at inconvenient time.
Also unspecified, except that it “may fail” to allocate. Assumably if it succeed there’s no extra overhead, except that your pool may fail to allocate anything from that point forward.
I disagree. It is certainly not “invalid” in the sense of Valid Usage rules. But the specification allows the implementation to impose strict pool requirements as it sees fit. So a good validation layer ought to consider exceeding those limits to be an error.
Remember: one of the points of the validation layers is to help users debug problems that cause an error on one platform but not another. For the validation layers to ignore it when users exceed these limits when other implementations may enforce those limits seems to be counter-productive towards those ends.
Do note though this does violate a VU in core 1.0, and the validation for that seem to be implemented (and error should be given).
Of course, I do not endorse exceeding the limits. Lying to Vulkan about what you gonna need is a bad idea; and all just to save few bytes. But this is how the API was designed in 1.1 (or maintenance extension). Who am I to tell you not to shoot yourself in the foot? Maybe there is a person who is only slowed down by said foot, and shooting it off is an improvement…
I am not sure that is strictly true. They are simply there as a checker for the api contract; as a replacement for OpenGL runtime checking.
But there are other layer that are supposed to fill that role, such as the VK_LAYER_LUNARG_assistant_layer or VK_LAYER_LUNARG_device_simulation.
As a consequence,
exceeding the limits of VkDescriptorPoolSize is not invalid in the valid usage.
That’s the reason why Vulkan does not tell an error to me.
after this time, I will be careful of the pool size,
because it may cause a fail for my application.
However, I have a thing that I did not write on the post.
when I specify less maxSets in the VkDescrpitorPoolSize, the validation error was sent to me in allocating descriptor sets.
When I specify less descriptor count and omit descriptor type in the VkDescriptorPoolsize, the validation error was not sent to me.
According to the specification, Now I know the allocation ‘may’ fail due to lack of the space. But the inconsistency made me confused and write this post in the previous week. Anyway, As the allocation ‘may’ fail due to lack of the space, I think talking about this more is not valid.