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.

[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]

Alright, we're getting close on the wgpu side.

I think we need some wgpu runtime tests of specifically the validation of:

• Texture Usages
• Wgpu Features

To ensure that they are correctly validated out when the features aren't enabled.

[teoxoy]

Besides the few comments I left, the naga side of this looks good to me.

[teoxoy]

A design question that shouldn't block this PR is: Is it necessary to have an atomic access and atomic binding type? It seems to me that the atomic functionality works on read_write storage textures as long as the format supports atomic ops.

[atlv24]

Its needed because Metal needs atomic usage to be marked as a texture usage, and if we dont have the shader specify that a texture will be used atomically then we dont have a way to validate metal usage

[cwfitzgerald]

Alright, approving wgpu side.

I've also done a review of the naga side and I had a few comments, but everything looks fine @teoxoy can you just make sure that I didn't miss anything, then we can get this in.

[teoxoy]

LGTM

The concern was addressed.

[teoxoy]

Its needed because Metal needs atomic usage to be marked as a texture usage, and if we dont have the shader specify that a texture will be used atomically then we dont have a way to validate metal usage

Could you point out where metal requires this? For texture access I only see:

enum class access { sample, read, write, read_write };