Rebase ms80 branch on wgpu v27.0.4 #1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Also provide a default initialization if the trace does not contain one.
gfx-rs#7822) * [naga wgsl-in wgsl-out] WGSL support for texture_external texture type Make wgsl-in correctly parse `texture_external` texture declarations, and allow such textures to be used in `textureDimensions()`, `textureSampleBaseClampToEdge()`, and `textureLoad()` function calls. In IR these are represented by the `ImageClass::External` image class, which is a 2D, non-multisampled, non-mipmapped, float-sampled image. Adds a new Capability `TEXTURE_EXTERNAL` and ensure validation rejects shaders containing external textures if this capability flag is not set. This capability is enabled for validation by wgpu devices which support the `TEXTURE_EXTERNAL` feature (currently only when using the noop backend), and by the Naga CLI when validating-only or when outputting WGSL. The WGSL backend can of course emit `ImageClass::External` images directly as `texture_external` textures. Other backends are, for now, unimplemented. Lastly, we add a snapshot test covering all the valid uses of a texture_external texture. These are: - As a global variable declaration - As an argument to the built-in functions `textureDimensions()`, `textureSampleBaseClampToEdge()`, and `textureLoad()` - As an argument to user-defined function declarations and calls. We keep these in their own test so that we can control which targets to run them against (currently WGSL and IR). When external textures are supported by all Naga backends we can, if so inclined, integrate these with existing texture tests. * fixup! [naga wgsl-in wgsl-out] WGSL support for texture_external texture type * fixup! [naga wgsl-in wgsl-out] WGSL support for texture_external texture type --------- Co-authored-by: Jim Blandy <jimb@red-bean.com>
`ExternalTexture` will form the basis of wgpu's implementation of
WebGPU's `GPUExternalTexture`. [1]
The application will be responsible for creating `Texture`(s) and
`TextureView`(s) from the external texture source and managing their
lifecycle. It may have a single RGBA texture, or it may have multiple
textures for separate Y and Cb/Cr planes. It can then create an external
texture by calling `create_external_texture()`, providing the texture
views and a descriptor. The descriptor provides the following required
information:
* Whether the texture data is RGBA, or multiplanar or interleaved
YCbCr.
* The purpoted size of the external texture, which may not match the
actual size of the underlying textures.
* A matrix for converting from YCbCr to RGBA, if required.
* A transform to apply to texture sample coordinates, allowing for
rotation and crop rects.
The external texture stores a reference to the provided texture views,
and additionally owns a `Buffer`. This buffer holds data of the type
`ExternalTextureParams`, and will be provided as a uniform buffer to
shaders containing external textures. This contains information that
will be required by the shaders to handle external textures correctly.
Note that attempting to create an external texture will fail unless the
`Feature::EXTERNAL_TEXTURE` feature is enabled, which as of yet is not
supported by any HAL backends.
Additionally add the relevant API to wgpu, implemented for the
wgpu-core backend. The web and custom backends are unimplemented.
[1] https://www.w3.org/TR/webgpu/#gpuexternaltexture
In upcoming patches, wgpu will allowing the creation of bind groups with either `TextureView`s or `ExternalTexture`s bound to a `BindingType::ExternalTexture` bind group layout entry. Wgpu-hal and the Naga-generated shaders must be able to handle both of these cases. For external textures they will be provided a uniform buffer containing the external texture's `ExternalTextureParams`. For the texture view case, we must therefore provide the same. To do this, we create a single buffer per device which can be shared between all texture views. We initialize it with the required values in Device::late_init_resources_with_queue(). We know that texture views must have a single RGBA plane, with no rotation or crop-rect. The only thing that can vary between them is their size. We will therefore use the value of [0, 0] in the params buffer to indicate to the shader that it should query the actual texture's size rather than using the value provided in the buffer.
Adds a `BindingResource` variant for external textures. In core's create_bind_group() implementation, allow binding either external textures or texture views to `BindingType::ExternalTexture` layout entries. In either case, provide HAL with a `hal::ExternalTextureBinding`, consisting of 3 `hal::TextureBinding`s and a `hal::BufferBinding`. In the texture view case we use the device's default params buffer for the buffer. When there are fewer than 3 planes we can simply repeat an existing plane multiple times - the contents of the params buffer will ensure the shader only accesses the correct number of planes anyway. Track the view or external texture in `BindGroupStates` to ensure they remain alive whilst required. And finally, add the corresponding API to wgpu, with an implementation for the wgpu-core backend.
Adds validation tests using the noop backend covering creation of external textures, and creation of bind groups containing external textures.
* Additional validation of buffer-texture copies Fixes gfx-rs#7936, but leaves a TODO for gfx-rs#7947 * Skip tests failing on dx12 * Update comments and change unwrap_or to expect
Co-authored-by: Andy Leiserson <aleiserson@mozilla.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This fixes a regression introduced by gfx-rs#7935.
* Restore allowance of unaligned buffer-texture copies This fixes a regression introduced by gfx-rs#7948. However, it makes it possible to reach a panic in initialize_buffer_memory if the copy requires initializing a region of memory that is not 4B aligned. * Fix CopyT2T of multi-layer depth/stencil textures * Adjust test list
During wgsl lowering, if we encounter an external texture type then generate the `ExternalTextureParams` struct. This will be required by most Naga backends to implement external textures. This type is not actually used by wgsl-in or the IR. However, generating it in Naga IR ensures tricky details such as member alignment are handled for us. wgsl-out must ensure it does *not* generate code for this type, as it handles external textures natively.
…ture Adds new `NameKey` variants `ExternalTextureGlobalVariable` and `ExternalTextureFunctionArgument`, like their non-external-texture cousins but additionally keyed by either being a specific plane index or params buffer. For each external texture global variable or function argument reserve additional names for 3 planes and the params buffer. For Naga backends which must represent external textures as multiple variables/arguments, this will allow them to uniquely name each one.
This adds HLSL backend support for `ImageClass::External` (ie WGSL's `external_texture` texture type). For each external texture global variable in the IR, we declare 3 `Texture2D` globals as well as a `cbuffer` for the params. The additional bindings required by these are found in the newly added `external_texture_binding_map`. Unique names for each can be obtained using `NameKey::ExternalTextureGlobalVariable`. For functions that contain ImageQuery::Size, ImageLoad, or ImageSample expressions for external textures, ensure we have generated wrapper functions for those expressions. When emitting code for the expressions themselves, simply insert a call to the wrapper function. For size queries, we return the value provided in the params struct. If that value is [0, 0] then we query the size of the plane 0 texture and return that. For load and sample, we sample the textures based on the number of planes specified in the params struct. If there is more than one plane we additionally perform YUV to RGB conversion using the provided matrix. Unfortunately HLSL does not allow structs to contain textures, meaning we are unable to wrap the 3 textures and params struct variables in a single variable that can be passed around. For our wrapper functions we therefore ensure they take the three textures and the params as consecutive arguments. Likewise, when declaring user-defined functions with external texture arguments, we expand the single external texture argument into 4 consecutive arguments. (Using NameKey::ExternalTextureFunctionArgument to ensure unique names for each.) Thankfully external textures can only be used as either global variables or function arguments. This means we only have to handle the `Expression::GlobalVariable` and `Expression::FunctionArgument` cases of `write_expr()`. Since in both cases we know the external texture can only be an argument to either a user-defined function or one of our wrapper functions, we can simply emit the names of the variables for each three textures and the params struct in a comma-separated list.
…ternal textures For simplicity's sake our initial implementation of external textures will not support binding arrays of external textures. We should therefore reject any shaders which use them during validation. Their implementation will be tracked in gfx-rs#8027. naga/src/valid/type.rs JJ: JJ: Lines starting with "JJ:" (like this one) will be removed.
…texture_to_buffer` (gfx-rs#8029)
Co-authored-by: Connor Fitzgerald <connorwadefitzgerald@gmail.com>
…restrictedBufferTextureCopyPitchSupported`
The encoder will be open if `CommandEncoder::as_hal_mut` has been used.
…, lowercase `naga`
Bounds like `<=5.0` should never be used unless necessary to avoid bugs, because it will cause a build failure if another package has a requirement like `~5.1.0` or `>=5.1.0`. Upper bounds should always cut at a major version boundary, not before it.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.