Adds a new feature flag, `EXTERNAL_TEXTURE`, indicating device support
for our implementation of WebGPU's `GPUExternalTexture` [1] which will
land in upcoming patches. Conceptually this would make more sense as a
downlevel flag, as it is a core part of the WebGPU spec which we do not
yet support. We do not want, however, to cause applications to reject
adapters because we have not finished implementing this, so for now we
are making it an opt-in feature.
As an initial step towards supporting this feature, this patch adds a
new `BindingType` corresponding to WebGPU's
`GPUExternalTextureBindingLayout` [2]. This binding type dictates that
when creating a bind group the corresponding entry must be either an
external texture or a texture view with certain additional requirements
[3].
As of yet wgpu has no concept of an external texture (that will follow
in later patches) but for now this patch ensures that texture views
corresponding to an external texture binding type are validated
correctly. Note that as the feature flag is not yet supported on any
real backends, bind group layout creation will fail before getting the
chance to attempt to create a bind group. But in the added tests using
the noop backend we can see this validation taking place.
[1] https://www.w3.org/TR/webgpu/#gpuexternaltexture
[1] https://www.w3.org/TR/webgpu/#dictdef-gpuexternaltexturebindinglayout
[2] https://gpuweb.github.io/gpuweb/#bind-group-creation
With the only caveat that device creation will now panic if the `wgsl` feature is not enabled, `InstanceFlags::VALIDATION_INDIRECT_CALL` is set and the device supports `DownlevelFlags::INDIRECT_EXECUTION`.
* Added “upward” links from `VertexAttribute` and `VertexBufferLayout`
to the places they are used.
* Documented the exact expected inputs of `vertex_attr_array!` and hid
the internal implementation.
* Added doc-test examples for:
* `VertexBufferLayout`, demonstrating how to construct a
`VertexBufferLayout` that corresponds to a `struct`.
* `vertex_attr_array!`, demonstrating exactly what the output of the
macro is.
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.
This allows `wgpu` to not unconditionally depend on `std::path::Path`.
It’s also, in my opinion, more user-friendly, because the feature which
most users will not use (and is not currently functional) is now a
defaultable struct field instead of a required parameter.
The disadvantage is that `wgpu-types` now has to know about tracing.
Makes the dual source implementation in wgpu WebGPU spec compliant.
Furthermore, makes the dual source blending extension available when targeting WebGPU.
* 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>
* 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.
