Instead allow the const to be converted each time it is const
evaluated as part of another expression. This allows an abstract const
to be used as a different type depending on the context.
As a result, abstract types may now find their way in to the IR, which
we don't want. This occurs because the compact pass treats named
expressions as used, mostly so that our snapshot tests are more
useful, and therefore does not remove them. To prevent this, we avoid
adding abstract-typed local consts to the named expressions list. This
will have no functional effect on any shaders produced by the
backends, but some unused local const declarations will no longer be
present.
Naga currently trips up on shaders containing a bitshift where the
left operand is an AbstractInt and the right operand is *not* a const
expression. This is due to the fact that resulting type of
`AbstractInt << u32` is abstract, and we are unable to evaluate it
away during const evaluation. This results in abstract-typed
expressions in our IR, which causes various issues.
For other binary operations, the type of the left and right operands
would be related, therefore the presence of a concrete right operand
would tell us which type to convert the left operand to. But for shift
operations the right operand's scalar type is always a u32, and does
not influence the left operand's type.
Luckily the WGSL spec[1] tells us how to avoid this problem:
6.1.3. Overload Resolution
2. Eliminate any candidate where one of its subexpressions resolves
to an abstract type after feasible automatic conversions, but
another of the candidate’s subexpressions is not a
const-expression.
This, for example, specifies we eliminate the `AbstractInt << u32:
AbstractInt` overload candidate, leaving `i32 << u32: i32` as the
remaining candidate with the lowest conversion rank. The equivalent
also applies for right-bitshifts, and for `vecN<AbstractInt>`
operands.
[1] https://www.w3.org/TR/WGSL/#overload-resolution-section
Move `back::wgsl::address_space_str` to `common::wgsl`, so that the
front end can use it too. This commit is code motion and `use`
adjustment only; there should be no change in behavior.
Replace `naga::back::wgsl::writer::image_dimension_str` with a
`ToWgsl` implementation for `ImageDimension` in `common::wgsl`. Use
this where needed in the WGSL backend.
Replace `naga::back::wgsl::writer::scalar_kind_str` with a `TryToWgsl`
implementation for `Scalar` in `common::wgsl`. Use this where needed
in the WGSL backend.
Move `back::vector_size_str` to `common`, so that front ends can use
it too. This commit is code motion and `use` adjustment only, there
should be no change in behavior.
Define new traits in `common::wgsl`, `ToWgsl` and `TryToWgsl`, for
getting the WGSL representation of some Naga IR types as `&'static
str` values:
- `MathFunction`
- `BuiltIn`
- `Interpolation`
- `Sampling`
- `StorageFormat`
Use these functions in the WGSL backend, taking advantage of
`TryToWgsl` to consolidate error reporting.
Introduce a new variant of `naga::back::wgsl::Error`, `Unsupported`,
and let it subsume `UnsupportedMathFunction` and various uses of
`Custom`.
Introduce a helper function, `Error::unsupported`, for building these
errors.
This entirely consists of conditionally replacing `Mutex` with `RefCell`,
then making sure that this doesn’t accidentally happen if we are also
exposing `Send + Sync`.
When an entry point's return type is anonymous, have
`naga::proc::Namer` assign it a name based on its shader stage.
Remove bespoke logic for this from the WGSL backend.
Fixes#7263.
* Add basic drm support to vulkan backend
* Move vulkan drm implementation to its own module
* Properly feature gate drm support and add safety docs
* Disable drm on wasm targets
* Remove old fixme comment from vulkan drm backend
* Move cfg check inside drm module
* Use expect instead of allow for create_surface_from_drm
* Document that drm is not available on apple platforms
* Initial(untested commit), vulkan and gles only supported
* Maybe fixed compiles for metal and dx12
* Hopefully fixed compiles for other backends and updated to functional(?) vulkan thing
* Fixed the clippy warning
* Fixed silly documentation mistake
* Fixed issue with multiview feature
* Dummy commit for dummy CI
The CI pooped itself, hopefully this fixes that. Will probably be undone either way.
* Re trigger CI checks, to avoid #7126
* Changes based on code review
* Fixed clippy warning, broken cargo.lock
* Unfucked cargo.lock for real this time
* Switched match to if-let in accordance with review
* Updated changelog
* Fix CI error
Done from web out of impatience
* CI is very angry 😡
Made CI less angry by fixing formatting(hopefully). This commit was also done from GitHub web.
* Removed comment in following request
* Update wgpu-hal/src/vulkan/adapter.rs
---------
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
Parsing currently fails for shaders that attempt to dynamically index
an abstract-typed array (or vector, etc), like so:
var x = array(1, 2, 3)[i];
This is caused by attempting to concretize the Expression::Access
expression, which the ConstantEvaluator fails to do so due to the
presence of a non-constant expression.
To solve this, this patch concretizes the base type *prior* to
indexing it (for non-constant indices), meaning the constant evaluator
never sees any non-constant expressions. This matches the WGSL
specification:
When an abstract array value e is indexed by an expression that is
not a const-expression, then the array is concretized before the
index is applied.
(Similar applies for both vectors and matrices, too.)
This may be somewhat non-optimal in that if there are multiple
accesses of the same abstract expression, we will produce duplicated
concretized versions of that expression. This seems unlikely to be a
major issue in practice, and we can always improve this if and when we
encounter a real issue caused by it.
Suggest checking that PRs assert that insertions into sets or maps
expected to be adding new values didn't actually just replace some
existing value.
Bug #7048 and its several duplicates would have been caught sooner if
the insertion of the new spill temporary into the `spilled_composites`
table had asserted that there was no existing spill variable for that
expression.
When spilling arrays and matrices so that we can access them with an
index computed at runtime, if we need to spill the same expression again,
don't wipe out our record of the temporary variable we used the first
time. Just re-use it.
Fixes#7048.
This allows `wgpu-hal` to be used in `no_std` environments, except that
currently, only the `noop` backend supports `no_std`.
In the future, `cfg(all(gles, webgl))` should also be `no_std`, but that
requires further work.
Co-Authored_by: Kevin Reid <kpreid@switchb.org>
Weaken our dependence on the `once_cell` crate by using functionality
from `std` instead that was upstreamed from `once_cell`, this time with
what's available in Rust 1.80+.
It's not yet possible to eliminate this dependency entirely, but do what
we can for now.
This was previously an `allow`-by-default warning in Clippy's `pedantic`
group, but with Rust 1.83 it was promoted to a `warn`-by-default member
of its `complexity` group.
Co-Authored-By: Kevin Reid <kpreid@switchb.org>
