naga doesn't have a `serde` feature, instead having separate
`serialize` and `deserialize` features, so things that want to
modify the serde handling must check for either of those, not
for `serde` itself.
* Allow unconsumed inputs in fragment shaders by removing them from vertex
outputs when generating HLSL.
Fixes https://github.com/gfx-rs/wgpu/issues/3748
* Add naga:🔙:hlsl::FragmentEntryPoint for providing information
about the fragment entry point when generating vertex entry points via
naga:🔙:hlsl::Writer::write. Vertex outputs not consumed by the
fragment entry point are omitted in the final output struct.
* Add naga snapshot test for this new feature,
* Remove Features::SHADER_UNUSED_VERTEX_OUTPUT,
StageError::InputNotConsumed, and associated validation logic.
* Make wgpu dx12 backend pass fragment shader info when generating
vertex HLSL.
* Add wgpu regression test for allowing unconsumed inputs.
* Address review
* Add note that nesting structs for the inter-stage interface can't
happen.
* Remove new TODO notes (some addressed and some transferred to an issue
https://github.com/gfx-rs/wgpu/issues/5577)
* Changed issue that regression test refers to 3748 -> 5553
* Add debug_assert that binding.is_some() in hlsl writer
* Fix typos caught in CI
Also, fix compiling snapshot test when hlsl-out feature is not enabled.
Add `HandleSet` methods `new`, `clear`, `clear_for_arena`, and
`remove`.
Change the type of `naga::valid::Validator::valid_expression_set` from
`BitSet` to `HandleSet`. Adjust uses.
Change `HandleSet::insert` to return `true` if the handle was not
already in the set.
Change uses in `naga::compact` which were taking advantage of the
prior return type of `()` to avoid needing to use semicolons in
`match` arms.
Change `naga::proc::index::find_checked_indexes` to return a
`HandleSet<Expression>`, rather than an untyped `BitSet`.
Fix uses in the Metal Shading Language backend.
Change the `std::fmt::Debug` impl for `naga::arena::Range` to print a
start-inclusive, end-exclusive range.
- This is more consistent with Rust's `std::ops::Range`.
- This is consistent with the serialization form used in snapshots,
which simply uses the serialization of `std::ops::Range`.
- It is not consistent with Naga's constructor function
`Range::new_from_bounds`, which takes an inclusive end value, or
with `Range::first_and_last`, which returns an inclusive end value.
Both of these need to represent ranges' end points as `Handle`s, but
exclusive end values might not be valid `Handle` values. I think
this divergence is tolerable.
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.
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
