-
Notifications
You must be signed in to change notification settings - Fork 345
Description
Consider an implementation of WebGPU which is streaming commands one-by-one to the backend API. Imagine the implementation encounters a program like this:
let commandEncoder = device.createCommandEncoder();
let computePass = commandEncoder.beginComputePass();
populateIndirectBuffer(computePass, indirectBuffer);
computePass.endPass();
let renderPass = commandEncoder.beginRenderPass(renderPassDescriptor);
renderPass.setStuff(...);
renderPass.drawIndirect(indirectBuffer, 0);
renderPass.endPass();
commandEncoder.finish();
If the implementation is streaming commands one-by-one to the backend API, by the time it hits the dispatchIndirect() call, there's no place for it to insert the compute shader for the validation checks.
- It has already been demonstrated how silently splitting passes is harmful, so we shouldn't split the render pass to insert the validation compute shader just before the
drawIndirect()call. - We can't insert the validation compute shader between the two passes, because we've lost our opportunity - we've already recorded the subsequent commands. We're streaming directly to the platform API; we can't back up and rewind.
- We can't insert the validation compute shader before the entire command buffer (or "command encoder" in WebGPU parlance) because that's too early - the indirect buffer hasn't been populated yet, so there's nothing that can be validated at that point.
I believe we already have requirements saying that an indirect buffer cannot be populated in the same pass that it is consumed. We should strengthen this requirement to say that an indirect buffer cannot be populated in the same command buffer ("command encoder") that it is consumed. That way, validation on any indirect buffers can be done by inserting a command buffer just before the current command buffer is submitted.