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.
Remove `PartialEq` derivations from various Naga IR types on which
equality doesn't really make sense. In some cases, derive only in
`cfg(test)` builds, so tests can check for expected output.
In the GLSL front end, use `append` to add new constants, not
`fetch_or_append`, since the latter requires `PartialEq` yet GLSL
doesn't permit duplicate declarations anyway.
Add the following flags to `wgpu_types::Features`:
- `SHADER_INT64_ATOMIC_ALL_OPS` enables all atomic operations on `atomic<i64>` and
`atomic<u64>` values.
- `SHADER_INT64_ATOMIC_MIN_MAX` is a subset of the above, enabling only
`AtomicFunction::Min` and `AtomicFunction::Max` operations on `atomic<i64>` and
`atomic<u64>` values in the `Storage` address space. These are the only 64-bit
atomic operations available on Metal as of 3.1.
Add corresponding flags to `naga::valid::Capabilities`. These are supported by the
WGSL front end, and all Naga backends.
Platform support:
- On Direct3d 12, in `D3D12_FEATURE_DATA_D3D12_OPTIONS9`, if
`AtomicInt64OnTypedResourceSupported` and `AtomicInt64OnGroupSharedSupported` are
both available, then both wgpu features described above are available.
- On Metal, `SHADER_INT64_ATOMIC_MIN_MAX` is available on Apple9 hardware, and on
hardware that advertises both Apple8 and Mac2 support. This also requires Metal
Shading Language 2.4 or later. Metal does not yet support the more general
`SHADER_INT64_ATOMIC_ALL_OPS`.
- On Vulkan, if the `VK_KHR_shader_atomic_int64` extension is available with both the
`shader_buffer_int64_atomics` and `shader_shared_int64_atomics` features, then both
wgpu features described above are available.
Since `BlockContext::resolve_pointer_type` never returns an error,
change its result type from a `Result` to a `&TypeInner`. Adjust
callers accordingly.
Remove calls (well, there's only one) to `resolve_pointer_type`
entirely when the caller does not need the value, since
`resolve_pointer_type` is now infallible and has no side effects.
Remove `valid::expression::ExpressionError::DoesntExist`. This error is reported
when expression validation encounters an invalid `Handle<Expression>`, but we
have already verified that the module is free of invalid handles in
`Validator::validate_module_handles`, so this condition should never arise.
Fix links in documentation for types defined using the `bitflags!` macro.
As described in [bitflags#407], for some reason, `cargo doc` doesn't
check for broken links in documentation for types or members defined
using `bitflags::bitflags!`.
[bitflags#407]: https://github.com/bitflags/bitflags/issues/407
This proves a flag in msl::PipelineOptions that attempts to write all
Metal vertex entry points to use a vertex pulling technique. It does
this by:
1) Forcing the _buffer_sizes structure to be generated for all vertex
entry points. The structure has additional buffer_size members that
contain the byte sizes of the vertex buffers.
2) Adding new args to vertex entry points for the vertex id and/or
the instance id and for the bound buffers. If there is an existing
@builtin(vertex_index) or @builtin(instance_index) param, then no
duplicate arg is created.
3) Adding code at the beginning of the function for vertex entry points
to compare the vertex id or instance id against the lengths of all the
bound buffers, and force an early-exit if the bounds are violated.
4) Extracting the raw bytes from the vertex buffer(s) and unpacking
those bytes into the bound attributes with the expected types.
5) Replacing the varyings input and instead using the unpacked
attributes to fill any structs-as-args that are rebuilt in the entry
point.
A new naga test is added which exercises this flag and demonstrates the
effect of the transform. The msl generated by this test passes
validation.
Eventually this transformation will be the default, always-on behavior
for Metal pipelines, though the flag may remain so that naga
translation tests can be run with and without the tranformation.
Add tests to ensure that validation checks that `CallResult` and
`AtomicResult` expressions actually have their values provided by
`Call` and `Atomic` statements, and not `Emit` statements.
Validate that `CallResult` and `AtomicResult` expressions actually
have their values provided by `Call` and `Atomic` statements, and not
`Emit` statements.
Fixes#5740.
This comment had become misplaced - it belongs on
`lookup_sampled_image` - but also, that table is no longer "storing
flags on how they are used". So the name of the field and type are
probably documentation enough.
* Avoid introducing spurious features for optional dependencies
If a feature depends on an optional dependency without using the dep:
prefix, a feature with the same name as the optional dependency is
introduced. This feature almost certainly won't have any effect when
enabled other than increasing compile times and polutes the feature list
shown by cargo add. Consistently use dep: for all optional dependencies
to avoid this problem.
* Add changelog entry
