Bring immediate in line with webgpu spec

[atlv24]

Connections
ticks boxes in #8556

Description
Brings immediate validation in line with webgpu spec. Bitmask of immediate slots required for a pipeline, tracks slot writing, removes auto-zeroing, and infers immediate_size for auto pipline layouts

Testing
Theres some tests on the slot bitmask algorithm and some validation tests for set_immediates behavior

Squash or Rebase?

Either, commits are clean

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy --tests. If applicable, add:
  • --target wasm32-unknown-unknown
• Run cargo xtask test to run tests.
• If this contains user-facing changes, add a CHANGELOG.md entry.

[teoxoy]

We should probably use a u64 for the bitmask to support at most 256bytes given that's the most almost all Vulkan devices support (https://vulkan.gpuinfo.org/displaydevicelimit.php?name=maxPushConstantsSize&platform=all). We also need to cap the max_immediate_size returned by adapters to 256 (in adjust_raw_limits).

[jimblandy]

I don't think this should block landing this, but:

The way this determines immediate_slots_required is not per spec. You need to look at the entry point(s) the pipeline uses, and see which specific fields of the var<immediate> type those entry points and their callees actually touch.

Getting this right will require a new bitmask field in naga::valid::FunctionInfo that gets populated probably by FunctionInfo::process_expression and process_block, and then consulted by wgpu_core.

[Vecvec]

Does this PR fix #4682 (which IIRC is the reason for this)?

[cwfitzgerald]

Thanks for this!

A few miscellaneous comments. I think unless you feel really strongly, we should do the move to naga's FunctionInfo first, as it will need to be done no matter what once we hook up the CTS, and means you won't need to churn on this code for the stuff that is going to be replaced anyway.

[cwfitzgerald]

We should document what this is and that it's a bitflags and not a count.

[cwfitzgerald]

suggestion(optional): Might consider putting this in a wrapper type so you can easily define helper methods on it (and added type safety)

[cwfitzgerald]

This error isn't really going to be very actionable for users. Once we determine we're in the error state, we should build a vector of byte ranges that aren't specified, will be much better UX.