In #955 (scenario 5), it was recorded that we decided not to generate validation errors when draw calls go out of bounds on indirect buffers.

However, in #980 we (accidentally, I think) ended up speccing that it does. Editors should revisit to resolve this.

As an analogy to index-buffer-OOB behavior, it makes sense that no validation error would be raised here:

• drawIndexed could produce a validation error on index-buffer-OOB, but would be inconsistent with drawIndexedIndirect. Consistency also allows implementations to upgrade drawIndexed to drawIndexedIndirect if they want to.
• drawIndirect/drawIndexedIndirect could produce a validation error on indirect-buffer-OOB, but would (probably) be inconsistent with drawIndirectCount/drawIndexedIndirectCount (which we don't have, but exist in Vulkan). Consistency also allows implementations to upgrade to the drawIndirectCount versions.

Note, looking into vkCmdDrawIndirectCount/vkCmdDrawIndexedIndirectCount, I noticed that Vulkan's maxDrawCount behavior is (somewhat peculiarly) actually safe, which would make it possible to check for indirect-buffer-OOB at validation time even for these calls. However, I don't know if this extends to Metal indirect command buffers, for example.

maxDrawCount specifies the maximum number of draws that will be executed. The actual number of executed draw calls is the minimum of the count specified in countBuffer and maxDrawCount.

Note there is no equivalent dispatchIndirectCount. (I guess you would need indirect command buffers (VK_NV_device_generated_commands?) to achieve that.)