* 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>
If it is undefined behaviour for loops to be infinite, then, when
encountering an infinite loop, downstream compilers are able to make
certain optimizations that may be unsafe. For example, omitting bounds
checks. To prevent this, we must ensure that any loops emitted by our
backends are provably bounded. We already do this for both the MSL and
HLSL backends. This patch makes us do so for SPIRV as well.
The construct used is the same as for HLSL and MSL backends: use a
vec2<u32> to emulate a 64-bit counter, which is incremented every
iteration and breaks after 2^64 iterations.
While the implementation is fairly verbose for the SPIRV backend, the
logic is simple enough. The one point of note is that SPIRV requires
`OpVariable` instructions with a `Function` storage class to be
located at the start of the first block of the function. We therefore
remember the IDs generated for each loop counter variable in a
function whilst generating the function body's code. The instructions
to declare these variables are then emitted in `Function::to_words()`
prior to emitting the function's body.
As this may negatively impact shader performance, this workaround can
be disabled using the same mechanism as for other backends: eg calling
Device::create_shader_module_trusted() and setting the
ShaderRuntimeChecks::force_loop_bounding flag to false.
Introduce the `AbstractRule` enum to control the behavior of
`Lowerer::type_and_init`. This is slightly clearer than
`allow_abstract: bool`, but more wordy.
Define `TypeInner::is_abstract`, and let it take a type arena so that
it can properly handle abstract arrays. Use this in compaction and in
the WGSL front end's conversion code to recognize abstract types.
Instead allow the const to be converted and 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.
A consequence of this is that abstract types may now find their way to
the validation stage, which we don't want. We therefore additionally
now ensure that the compact pass removes global constants of abstract
types. This will have no *functional* effect on shaders generated by
the backends, as the expressions belonging to the abstract consts in
the IR will not actually be used, as any usage in the input shader
will have been const-evaluated away. Certain unused const declarations
will now be removed, however, as can be seen by the effect on the
snapshot outputs.
It must call ConstantEvaluator::check_and_get() to possibly retrieve
the constant expression from a separate arena, like is currently done
when evaluating `As` expressions for non-array casts.
