This is a useful shortcut for tests and example code, allowing it to
create a noop device without needing to deal with nonexistent
fallibility and asynchrony.
This will help users determine whether the problem is:
* a backend is not statically enabled
* a backend is not dynamically enabled
* no drivers or physical adapters are present for that backend
(further distinction would be useful here)
* no adapters met the required criteria
There are deficiencies in the reporting of WebGPU vs. WebGL support.
Those would best be fixed by also fixing the mutual exclusion of those
backends.
Makes the dual source implementation in wgpu WebGPU spec compliant.
Furthermore, makes the dual source blending extension available when targeting WebGPU.
This allows abstract-typed expressions to be used for some or all of
the switch selector and case selectors. If these are all not
convertible to the same concrete scalar integer type we return an
error. If all the selector expressions are abstract then they are
concretized to i32.
The note previously provided by the relevant error message, suggesting
adding or removing the `u` suffix from case values, has been
removed. While useful for simple literal values, it was comically
incorrect for more complex case expressions. The error message should
still be useful enough to allow the user to easily identify the
problem.
When the user provides values for a module's overrides, rather than
replacing override-sized array types with ordinary array types (which
could require adjusting type handles throughout the module), instead
edit all overrides to have initializers that are fully-evaluated
constant expressions. Then, change all backends to handle
override-sized arrays by retrieving their overrides' values.
For arrays whose sizes are override expressions, not simple references
to a specific override's value, let front ends built array types that
refer to anonymous overrides whose initializers are the necessary
expression.
This means that all arrays whose sizes are override expressions are
references to some `Override`. Remove `naga::PendingArraySize`, and
let `ArraySize::Pending` hold a `Handle<Override>` in all cases.
Expand `tests/gpu-tests/shader/array_size_overrides.rs` to include the
test case that motivated this approach.
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.
* 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>
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.
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.
* Link to where it is used and how to check support.
* Link from `Auto*` to the variants they refer to.
* Organize mode information into lists.
* Document which value is the default value.
* Various wording changes.
I mostly did not touch the descriptions of the individual modes.
I think that they could use some explanation of jargon (what is a
“presentation engine”, really?) but I am not the person to write that.
This allows using `StagingBelt` for copying to textures or any other
operation where copying to an existing buffer is not the desired outcome.
One unfortunate feature of the API is that `allocate()` returns the entire
buffer and an offset, so applications could accidentally touch parts of
the belt buffer outside the intended allocation. It might make more sense
to return `wgpu::BufferSlice`, but that struct cannot be used in
operations like `copy_buffer_to_texture` and does not have getters, so it
is not currently suitable for that purpose.
I also moved `Exclusive` into a module so that its unsafe-to-access field
is properly private, and made various improvements to the `StagingBelt`
documentation, such as acknowledging that `write_buffer_with()` exists.
This allows users to skip creation of `BufferSlice` if they have no use
for it, and brings `wgpu` closer to the WebGPU API without removing any
Rust convenience. New functions:
* `BufferSlice::slice()`
* `Buffer::map_async()`
* `Buffer::get_mapped_range()`
* `Buffer::get_mapped_range_mut()`
* `Buffer::get_mapped_range()`
According to winit docs, pre_present_notify() should be called right
before calling present().
This actually prevents some issues on Wayland, like freezing the whole
application when the window is not visible (ask me how I know).
* move tests into conditionally compiled mod and place them at the end. add some whitespace for readability
* allow creation of `Features` from `FeaturesWGPU` & `FeaturesWebGPU`
When lowering a return statement, call expression_for_abstract()
rather than expression() to avoid concretizing the return value. Then,
if the function has a return type, call try_automatic_conversions() to
attempt to convert our return value to the correct type.
This has the unfortunate side effect that some errors that would have
been caught by the validator are instead encountered as conversion
errors by the parser. This may result in a slightly less descriptive
error message in some cases. (See the change to the invalid_functions()
test, for example.)
