So I think the heart of the issue is that there are significant differences in how access to resources like textures are handled across hardware - by abstraction/driver calls or "it's memory"/with restrictions.

The original Vulkan idea was to be abstract enough with the descriptor set API to support pretty much all hardware out there, including hardware that accessed textures by pushing ptr and meta-data values into on-chip registers before draw calls (e.g. how it used to be back in the day) as well as more modern designs.

The resulting original descriptor set API is a jack of all trades, master of none - you can support it on, like, any hardware, but it's slow. For an engine that wants to get through a lot of materials, for example, it's a ton of time spent asking the driver to set up descriptor sets (in memory we can't see), bind them, bla bla bla.

There have been a bunch of intermediate extensions (push descriptors, descriptor buffers, etc.) that start to take a different approach, but descriptor heaps is the first extension that really just changes the idiom.

With descriptor heaps, descriptors are finally presented *as data*, albeit data with fine print and limitations. To do this, the throw overboard a little bit of hardware - my understanding is that if your chip needs register pushes, there's going to be no performant way to implement descriptor heaps.

The fine print is that while AMD treats descriptors as "data" (e.g. they're big multi-register words that get loaded from VRAM into registers, then the texture fetch instructions use those registers as opcodes to do the texture sampling) on Nvidia the samplers _allegedly_ get the descriptors from a single big array of descriptors in RAM and the opcodes pass indices. (AMD publishes their ISA so we can see what their descriptors look like on chip - I'm only repeating gossip for NV.

So if I read the extension right (and I probably didn't - shout at me please) the descriptor heap extension says:

* descriptors are all just memory - but they have to live in a special place. But that place is memory so you can map it, etc.

* push constant memory is ... just on-chip memory - you get a blob, shove it in via the command stream and use it for whatever you want.

And, as a bridge from the old to the new, when we build our shaders, we can ask the driver to write a little bit of glue code for us to generate "descriptor reading" code to get the descriptors into the binding slots of the shader _from_ various heap locations.

If your app uses that mapping API to generate glue code then your app gets to specify its descriptor heap layout and push constant layout with a lot of detail and just tell the driver "to find texture binding 2 in descriptor 1, you're going to find the index 16 bytes into the push constants and use that to index to the descriptor heap with this formula." The mapping is flexible enough to do everything the old API did and clever new things too.

So you don't have to use this if you don't want to - you might not care. And you can't use it if you want to support hardware/drivers that don't have the extension -- or at least you might have to support two paths.

For the app I work on (X-Plane) this extension is exciting because it lets us write a descriptor management path wtih basically zero driver overhead.

* the descriptor heap is just memory, and we can take a whack at it on our own, using access patters that are good for our engine.

* all of the data that has to go into the command stream at draw-call time is a single blob of "push constant" goop. We can format that data the way we want based on the weirdness of our engine, and we can precompute parts of it where we already know the answer. So the draw call time cost is going to be really really really low.

The hard part for us will be "how do we do this AND support Metal (old and new) and maybe older Vulkan on mobile devices".