Vulkan's `VK_EXT_memory_budget` extension doesn't cover query sets, so
`wgpu_hal::vulkan::Device::error_if_would_oom_on_resource_allocation`'s
tactic doesn't work to anticipate OOM errors from the Vulkan driver
when creating query sets.
Without these checks, `wgpu_gpu::oom::query_set_oom_test` actually
consumes a significant amount of memory and attracts the attention of
the system's OOM killer. While it does get killed, the situation tends
to adversely affect the stability of the rest of the system, and thus
is not a friendly thing for a test run to do (#7817).
This change can be reverted once a suitable accounting method for
query sets has been implemented on Vulkan.
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
This will make it easier for contributors to understand the file layout,
at the cost of said layout containing several more nested directories.
I will personally appreciate not having to remember to look for
`root.rs` instead of `main.rs`.
I also renamed the test targets so that they do not *all* share the
superfluous suffix “-test” (test targets live in a different namespace
than other target types and packages, so the name can presume that it
is always known that they are tests).
The Naga snapshot data sets `naga/tests/{in,out}` have been left in
their original positions.
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.
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.
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.
