Image atomics support

[atlv24]

Connections
Broken off from #5537

Description
Adds image atomics to Vulkan, DirectX, and Metal backends.

Testing
naga snapshot tests and runtime tests are included

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy. If applicable, add:
  • --target wasm32-unknown-unknown
  • --target wasm32-unknown-emscripten
• Run cargo xtask test to run tests.
• Add change to CHANGELOG.md. See simple instructions inside file.

[atlv24]

I don't know what this is for, but if I don't remove it then naga glsl snapshot fails

[jimblandy]

I started reviewing with the Naga IR, and found something that should be addressed.

[jimblandy]

@atlv24 I appreciate the docs!

[jimblandy]

Some more requests.

[atlv24]

@jimblandy what did you force push may i ask? and thanks for the review!

[jimblandy]

@jimblandy what did you force push may i ask? and thanks for the review!

Just changing // to /// to make something a doc comment in the IR, in naga/src/lib.rs.

I always feel bad asking people to change stuff like that because it's trivial, so I just fix it myself, amend to keep the PR review a single commit, and force push. If you'd rather I not amend, that's fine. (And if you'd rather I make lots of minor change requests, I could do that too, but...)

[atlv24]

nah its fine, was just curious. i can't see the diff and visual inspection yielded nothing

[jimblandy]

In Validator::validate_entry_point, we have the following code:

let allowed_usage = match var.space {
    ...
    crate::AddressSpace::Private | crate::AddressSpace::WorkGroup => GlobalUse::all(),
    ...
};

By adding ATOMIC to GlobalUse, this became incorrect: atomic accesses to Private address space variables isn't permitted.

I think using atomics in local variables is already covered by Validator::validate_local_var, but validate_entry_point should still not say strange things.

[jimblandy]

@atlv24 If it's ok, since I've requested some non-trivial changes, rather than finishing this review, I'm going to go review some other, simpler PRs first, and then come back to this one once you've got it revised.

[atlv24]

@jimblandy thats fine. I am unsure how to remove the sample expression handle from the naga ir, because of the way spir-v wants to write cached expressions. before i added that field, i had tried for quite a while and not found a way to generate it on the fly once, so i settled on the dumb and simple solution.

[jimblandy]

@atlv24 If you call back::spv::Writer::get_constant_null, that should give you a SPIR-V id whose value is zero that you can use as the MS operand. That takes an argument that is a SPIR-V type id, which I think you can get from Writer::get_uint_type_id. Or, if it's easier, you could try Write::get_constant_scalar, something like here.

[atlv24]

@jimblandy resolved all feedback

[cwfitzgerald]

Self requesting to look at wgpu api side.