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
Adds a new flag to the IR indicating when image sample coordinates are
to be clamped. Adds wgsl-in support for parsing and lowering to
IR. Validation ensures this flag is only used when sampling a 2D
non-arrayed sampled texture, without offset, gather, or depth
comparison. This matches the WGSL requirements, with the exception of
supporting `texture_external` textures, which will follow in a later
patch.
SPIRV, HLSL, and Metal backends are supported so far, with GLSL left
for a follow up. (In GLSL the texture will simply be sampled without
the coordinates being clamped.)
It may seem unfortunate to have to handle this separately for each
backend, and indeed it would have been possible to implement this simply
in the WGSL frontend. However, future patches will add support for using
textureSampleBaseClampToEdge() with external textures, which will
actually have to be handled by each backend. This patch is laying the
groundwork for that.
Limit to the `sampled_1d_coords` subtests for now as otherwise the tests
take a very long time to execute, and there are also some failures with
certain texture formats that are used in higher dimensions.
In the SPIR-V front end, when generating Naga IR `Struct` types to
represent a SPIR-V entry point's `Output` variables, instead of saying
"0xFFFF, // shouldn't matter", follow the usual rules in assigning
struct member offsets and computing an overall
size (`TypeInner::Struct::span`) for the resulting struct type.
Some versions of WARP return an allocation info with SizeInBytes == 0
for very large allocations. Proceeding to attempt to allocate a zero-
sized resource results in a device lost error. It's preferable to
instead return an out of memory error.
Git for Windows adds an extra suffix to the version string. This is a
follow up to #7800 that ensures we parse such git versions correctly
rather than returning an error.
