If it did, NVIDIA wouldn’t have needed to make an extension to add it, would they
Notably, Vulkan has no concept of converting resources into GPU addresses, without which there’s no way to have GPU operations which can change state (unless it’s an offset from an address provided by a descriptor). This is why NVIDIA’s extension goes in a different direction (making it explicit that the GPU is reading the buffer data and writing to a command buffer, rather than implying that the GPU command processor can read this stuff directly), but effectively provides similar behavior.
The ExecuteIndirect method essentially is capable of executing a list of commands such as changing vertex buffers, index buffers and draw calls all as a command buffer that can be executed with a single call from the CPU
Has your engine crossed a threshold of bazillion drawcalls Vulkan allows you already? Even if ExecuteIndirect is somewhat more efficient than multiple host-side "Bind->DrawIndirect"s, will it a be dealbreaker? Binding will require pretty much the same amount of driver-side work and is still undesireable, albeit ExecuteIndirect hides it from a programmer.
It’s not about the number of drawcalls. The purpose of indirect operations is to remove the GPU->CPU->GPU synchronization that would otherwise be needed for those operations. Removing that synchronization means that the GPU can generate work for itself, without direct CPU intervention, thus allowing you to offload what would otherwise be CPU work to it.
This also means that you can do things on the GPU which generate further GPU work, but are are highly parallel tasks that CPUs would be unsuited to.
Gosh, I’ve gravely misunderstood the purpose of this function. It lets a command processor to avoid useless job decoding a lot of Draw(0 triangles) and Dispatch(0 workitems) calls, while I assumed it to be something else entirely.
