@nicebyte
@valpackettVal Packett 🧉 For one thing, a lot of that bindful hardware was still very relevant 10 years ago when Vulkan was being designed and running on current hardware was a design goal. Sure, that might not have mattered as much for AMD or Nvidia but we weren't going to just leave Intel and the entire mobile space behind.
(And even for AMD and Nvidia, they were both just barely phasing out support for that hardware. Fermi and R600 both went EOL/legacy around the time of the Vulkan launch. Neither of those could do bindless.)
The second problem is that we didn't really understand what we were designing to. The mobile bindless designs didn't exist yet or were very early prototypes back then. The DX12 model existed in theory but we (the industry) had zero experience with it in production. About the only next-gen thing we did have was console APIs and those were AMD-only. Vulkan 1.0 was a generalization of those APIs.
The third thing is that we didn't know how to make it fast. Descriptor sets let you hide everything, giving the driver developers a lot of options when it comes to how we optimize and try to make descriptors fast. We've learned a lot in the last 10 years about what matters for speed and what doesn't. If we had designed something without that knowledge, we probably would have screwed it up worse. Descriptor sets were a safe bet.
Forth, descriptor heaps build on a lot of API concepts we didn't have back in Vulkan 1.0 like buffer device address and untyped pointers. Could we have built something like heaps without those concepts? Yes. But it wouldn't be nearly as clean as the API we ended up with.
And even today, we're not rolling out heaps everywhere. It'll be ubiquitous on desktop soon enough but there are mobile/embedded parts that are still very relevant but which can't do heaps. Do you need to care about those for your next AAA game? Probably not but part of Vulkan's promise is to be cross-platform and that means not leaving half of the industry in the cold.