Add ExternalTexture BindingType behind new Feature flag #7732
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
jamienicol
force-pushed
the
external-texture-binding-type
branch
from
53b96c7 to
06a6824
Compare
jamienicol
force-pushed
the
external-texture-binding-type
branch
5 times, most recently
from
5a37c32 to
4644ee9
Compare
jamienicol
changed the title
jamienicol
force-pushed
the
external-texture-binding-type
branch
3 times, most recently
from
86c41a1 to
1eddf23
Compare
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
jamienicol
force-pushed
the
external-texture-binding-type
branch
from
1eddf23 to
895bfc4
Compare
There was a problem hiding this comment.
Looks like @jimblandy is ramping up on review now, so I won't drive a full review myself, but I'll comment on some things I noticed before I left on vacation and now.
| /// ``` | ||
| /// | ||
| /// Corresponds to [WebGPU `GPUExternalTextureBindingLayout`]( | ||
| /// https://gpuweb.github.io/gpuweb/#dictdef-gpuexternaltexturebindinglayout). |
There was a problem hiding this comment.
suggestion: Maybe a reference to Features::EXTERNAL_TEXTURE would be good here?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Connections
Part of #4386
No dependencies
Description
Adds a new feature flag,
EXTERNAL_TEXTURE, indicating device supportfor our implementation of WebGPU's
GPUExternalTexture[1] which willland 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
BindingTypecorresponding to WebGPU'sGPUExternalTextureBindingLayout[2]. This binding type dictates thatwhen 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
Testing
Added validation test. Enabling CTS tests will follow (need some deno_webgpu changes)
Squash or Rebase?
Don't mind
Checklist
cargo fmt.taplo format.cargo clippy --tests. If applicable, add:--target wasm32-unknown-unknowncargo xtask testto run tests.CHANGELOG.mdentry.