This is to preserve the current behavior as tested by the `SAMPLER_CREATION_FAILURE` test.
This is not spec compliant but it's unclear what we should do instead. I opened https://github.com/gpuweb/gpuweb/issues/5142 to figure out what we should do.
This removes the possibility of deadlocks happening since `release_gpu_resources` tries to lock resources (trackers, snatchable_lock, pending_writes, life_tracker) while they might be already locked; `handle_hal_error` is called in lots of places.
Removing the call only delays destruction since `release_gpu_resources` is still called in `maintain`.
The D3D12 API doesn't guarantee that it returns `E_OUTOFMEMORY` in high memory pressure situations; drivers/kernel will happily start swapping objects that were in VRAM to RAM and then RAM to DISK, slowing down the system to a crawl if done in a loop.
In `naga::valid::expression::validate_expression`, use a let-else
statement so that the outermost control flow follows the success path,
and errors are close to the conditions that trigger them.
Properly apply WGSL's automatic conversions to the arguments
to texture sampling functions.
Introduce helper function `Lowerer::expression_with_leaf_scalar`.
Although this can't affect behavior, use
`Lowerer::expression_for_abstract` for the `image` and `sampler`
arguments, simply because we want to move away from
`Lower::expression`'s automatic concretization, and move towards
having callers say explicitly what sort of conversions they need.
Although this can't affect behavior, use
`Lowerer::expression_with_leaf_scalar` for the `offset` argument, so
that the code spells out that this requires an `i32` value, rather
than depending on blind concretization giving it that.
Continue to use `Lowerer::expression` for `gather` and `array_index`,
since those happen to behave correctly with blind concretization, and
can be cleaned up later.
Fixes#7427.
Change `naga::front::wgsl::lower` to `use` `ir` and `proc`,
and then qualify identifiers with that instead of `crate`.
This is strictly fiddling with `use` directives and name
qualification, with the concomitant formatting changes; there should
be no change to the module's behavior or meaning.
