Hi,
Some time ago I asked about the validation step which was auto-injected by wgpu (for the sake of browsers security or stability if I recall) before each indirect dispatch, and was messing with bindings (lots of unnecessary bind calls).
As I recall I was told this would be made optional in a later version (it's mandatory in 24.x). Reading the latest docs in 26.x, I think this is what InstanceFlag::VALIDATION_INDIRECT_CALL corresponds to?
The problem is that there's a section in that doc saying that on the D3D12 backend, disabling this flag makes @builtin(instance_index) not work. I checked the WGSL spec, I didn't see anything that would allow a compliant implementation to choose not to take first_instance into account.
So my understanding is that you have to choose between enabling a debug feature which adds extra dispatches and unnecessary bindings (and so impacts performance), and being able to use the first_instance feature (or re-implementing it yourself). Is that correct, or am I misunderstanding something? Can someone explain what's going on here and why only D3D12 has this issue?
Thanks!
Hi,
Some time ago I asked about the validation step which was auto-injected by
wgpu(for the sake of browsers security or stability if I recall) before each indirect dispatch, and was messing with bindings (lots of unnecessary bind calls).As I recall I was told this would be made optional in a later version (it's mandatory in 24.x). Reading the latest docs in 26.x, I think this is what
InstanceFlag::VALIDATION_INDIRECT_CALLcorresponds to?The problem is that there's a section in that doc saying that on the D3D12 backend, disabling this flag makes
@builtin(instance_index)not work. I checked the WGSL spec, I didn't see anything that would allow a compliant implementation to choose not to takefirst_instanceinto account.So my understanding is that you have to choose between enabling a debug feature which adds extra dispatches and unnecessary bindings (and so impacts performance), and being able to use the
first_instancefeature (or re-implementing it yourself). Is that correct, or am I misunderstanding something? Can someone explain what's going on here and why only D3D12 has this issue?Thanks!