This commit is almost entirely code motion. The only meaningful
changes should be:
- changes to imports
- changes to visibility
- changes to use visible associated constructor functions instead of
trying to construct values directly using now-invisible fields
- moving the crate-level "Arena" docs into the `arena` module
In preparation for making `Handle` fields private to another module,
have the `Iterator` implementation for `arena::Range` call
`Handle::new` to construct the handle being produced, rather than
building it using a struct literal.
Use the associated function `Range::from_index_range` to construct the
return value of `Arena::range_from`, rather than constructing the
`Range` directly, in preparation for those fields becoming private.
We are using `program_cache.try_lock()` when creting pipelines which is covered by a guard gotten from `context.lock()`. For the `.try_lock()` to always succeed we need to make sure that the other lock acquisitions are also covered by a `context.lock()`.
The `wgpu_examples::hello_compute::tests::multithreaded_compute` test has been failing intermittently in CI due to this.
* Add an optional system for counting and reporting internal resources and events
* Count API objects in wgpu-hal
* Expose internal counters in wgpu-core and wgpu.
Change `naga::proc::constant_evaluator::ExpressionKindTracker::inner`
from a `Vec` to a `HandleVec`, for better type-checking and more
convenient indexing. Change uses accordingly.
To support atomic instructions in the SPIR-V front end, observe which
global variables the input accesses using atomic instructions, and
adjust their types from ordinary scalars to atomic values.
See comments in `naga::front::atomic_upgrade`.
Introduce a new type, `HandleVec<T, U>`, which is basically a
`Vec<U>`, except that it's indexed by values of type `Handle<T>`. This
gives us a more strictly typed way to build tables of data parallel to
some other `Arena`.
Change `naga:🔙:pipeline_constants` to use `HandleVec` instead of
`Vec`. This removes many calls to `Handle::index`, and makes the types
more informative.
In `naga:🔙:spv`, change `Writer` and `BlockContext` to use
`HandleVec` instead of `Vec` for various handle-indexed tables.
When the appropriate features are enabled, manually implement
`serde::Serialize` and `serde::Deserialize`, such that the serialized
form of `NonMaxU32::new(n).unwrap()` is the same as that of `n`.
This eliminates the last trace of 1-based indices from Naga's snapshot
tests, and aligns `std::fmt::Debug` with the serialized form.
Remove the phrase "zero-based" from comments and function names. Now
that there is no mix of zero-based and one-based indices, there's no
need to call out the distinction.
Define a new type, `NonMaxU32`, that can represent any `u32` value
except `u32::MAX`, defined such that `Option<NonMaxU32>` is still a
32-bit value.
Change `Handle` to use `NonMaxU32`. Adjust all code that works
directly with handle indices to assume zero-based indices, not
one-based indices.
This replaces all uses of `Handle::index` for generating identifiers
in `naga:🔙:msl` with uses of `Handle::write_prefixed`.
There are still some uses of `Handle::index` remaining.
Make the HLSL backend more like other backends by using `back::Baked`
to generate names for baked expression identifiers. This removes the
final uses of `Handle::index` from the HLSL backend.
This is separated out from the previous commit because it changes lots
of snapshot tests, whereas the previous commit has no effect on Naga's
output.
Introduce a newtype `naga:🔙:Baked` that wraps a
`Handle<Expression>` and formats with `std::fmt::Display` as a baked
expression identifier. Use this in all backends for generating baked
identifiers.
Delete `BAKE_PREFIX`, as it's no longer used outside of `Baked`'s
`Display` implementation.
This is a step towards making `Handle::index` less prominent in the
code base.
