There is an argument to be made about GPU performance as well. Making them (and the pools they are allocated from) opaque was necessary to hide these differences. GPUs reference resources in a variety of ways, including (for example) storing descriptors in fixed registers rather than in memory. There is a good reason for the opaque model inherited from older APIs. Tooling developers have an easier time since everything is observed on the CPU timeline and everyone is happy … except of course, developers chasing peak performance. The driver is free to do whatever it wants with those descriptors. When descriptors are bound to the command buffer, the driver will somehow ensure that shaders can access them. Updating a descriptor is an API call, and we allocate them from an opaque descriptor pool. What is a descriptor really? In baseline Vulkan, the concept is completely abstracted away.
To understand where we’re going with descriptors going forward, we need to understand how we got here.
Delete VkDescriptorPool and VkDescriptorSet from the API, and have fun! Rethinking how we see descriptors Tl dr version for the busy graphics programmer: Descriptor sets are now backed by VkBuffer objects where you memcpy in descriptors. We’ve just released an extension that I think will completely change how engines approach descriptors going forward.
