You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Descriptor sets have vexed me at every step of development. They're new and different and they have a lot of rules which aren't all that obvious. This document will hopefully lay out everything in one convenient place that I - and also you - can refer to
First, let's talk about what we're trying to do
Use Case
Most renderers need some way for shaders to access resources like textures, buffers, etc. For the Vulkan API, this way is the almighty descriptor set. Descriptors, as I understand them, are essentially a pointer to a resource. You update your descriptor sets with your resources, then you bind the descriptor sets to your command buffer, then shaders involved in subsequent drawcalls can look at the descriptors to know what resources they should actually read from. I'm not entirely sure why there's this indirection - and in fact, on AMD GPUs descriptor sets are actually just pointers - but the indirection exists, and we all have to find a way to deal with it
A good way to think about a buffer or an image descriptor is to imagine it as a
very fat pointer. This is, in fact, not too far removed from reality, as we
shall see.
Taking a peek at radv, we find the uniform buffer and storage buffer descriptors
to be a 4-word tuple, where the first two words make up the address, followed by
length in bytes for bounds checking and an extra word, which holds format
information and bounds checking behavior [^1].
Similarly, the sampled image descriptor is a 16-word tuple containing an