Ensure safety of indirect dispatch

[teoxoy]

Ensure safety of indirect dispatch by injecting a compute shader that validates the content of the indirect buffer.

Part of #2431.

Depends on #6318.

[cwfitzgerald]

See Atomic issue and other small nits

EDIT from @ErichDonGubler: added a link for atomic issue

Addressed comments

[teoxoy]

I don't know why github it not letting me "rebase and merge":

Via the CLI is also not working.

gh pr merge 5714 -r -R gfx-rs/wgpu
GraphQL: This branch can't be rebased (mergePullRequest)

[teoxoy]

I will just squash and merge, losing 6619f3a is not the end of the world.

[schell]

I'm tracking trunk in my project and just hit a panic in these changes:

thread 'test::unlit_textured_cube_material' panicked at /Users/schell/.cargo/git/checkouts/wgpu-53e70f8674b08dd4/59f56e0/wgpu-core/src/indirect_validation.rs:288:58:
called `Option::unwrap()` on a `None` value

I'm guessing it's this binding binding_size on line 276 in the file mentioned:

        let binding_size = calculate_src_buffer_binding_size(buffer_size, limits);

being used on line 288:

                size: Some(NonZeroU64::new(binding_size).unwrap()),

...so for some reason in my case binding_size is 0. Maybe the buffer passed is 0? 🤷

[vntec]

Any plans to allow opting out of this? Maybe by disabling a flag called "extensive validation" or something like that?
Don't get me wrong, I generally support the idea of more security checks like this (especially for WebGPU), but I feel like injecting a compute dispatch before every single indirect call could be a bit too intrusive for some release builds.

If that's not planned, I'd at least suggest adding an appropriate label to the compute pass? I was initially very confused about an unnamed dispatch showing up in RenderDoc :D.

[JMS55]

I actually checked my renderer, and wasn't seeing any indirect validation dispatches after upgrading to wgpu 23. Not sure why.

[vntec]

I actually checked my renderer, and wasn't seeing any indirect validation dispatches after upgrading to wgpu 23. Not sure why.

That's odd. I definitely encountered these. After upgrading, my renderer stopped working and I noticed that I had been exceeding the 65k max_compute_workgroups_per_dimension limit quite frequently, which went unnoticed since my Vulkan driver supports 2 billion workgroups in the x-dimension.

So the feature is definitely useful for development and debugging, but I'd appreciate the option to disable it for some release builds. The performance impact seems quite small, but it may add up for indirect-heavy applications on low-end hardware.

[teoxoy]

We will probably add a flag to disable this, see #6567. Though, the num_workgroups builtin won't work on D3D12 (#5730) without this.

[vntec]

That's great to hear, thanks!