Disallow mixing command encoding APIs

[andyleiserson]

Follow-up to #8220. @Vecvec pointed out that the behavior when mixing calls to the two APIs was changed by that PR. Since we don't have any tests for behavior when mixing the APIs, and don't know of use cases, it seems simplest to disallow it entirely.

Testing
Adds wgpu-validation tests.

Squash or Rebase? Squash

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.
• Adds a CHANGELOG.md entry.

[cwfitzgerald]

Nice, thanks for the tests! This honestly makes things a lot less complicated with encoding.

[andyleiserson]

I think that raw encoding may be broken since the encode-on-finish changes and fixed by this change, because of the assertion I added in CommandEncoderStatus::finish that the encoder has not yet been opened. That is the case for wgpu encoding, but not for raw encoding. Possibly we want to backport some form of this:

https://github.com/gfx-rs/wgpu/pull/8373/files#diff-1fe34f06c0c0bd67a41a9cb8aa26cae0a2a4b58028ce5e064abb6f8ad23b84cfR367-R371

CC @Vecvec

[Vecvec]

Possibly we want to backport some form of this

I think that that probably should be backported (especially since it is fairly early in the release cycle).

Should I also review this?

[andyleiserson]

@Vecvec

Should I also review this?

If you have a minute to study whether the doc comment changes I made on mark_acceleration_structure_built makes sense, that would be useful. Other than that, I don't think you need to review the rest of it, IMO it pretty straightforwardly does what the title says. If you have test cases for raw encoding that I could use to check whether it is working on the v27 branch and on trunk, that would be useful.

[Vecvec]

It definitely is broken on v27, it hits assertion failed: !inner.encoder.is_open in my tests.