-
Notifications
You must be signed in to change notification settings - Fork 346
[main branch] Specify Compatibility Mode #5402
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Give definitions for the "core" and "compatibility" featureLevels, as
well as "Core-defaulting" and "Compatibility-defaulting" Adapters
(language largely taken from the compat proposal).
Define CSS for "Compatibility Mode" exceptions: a cyan-ish box, similar
to the "Valid Usage" styling.
As an example, add restriction 2 ("Color blending state may not differ
between color attachments in a `GPUFragmentState`.") from the compat
proposal in that style.
Co-authored-by: Kai Ninomiya <kainino@chromium.org>
Co-authored-by: Kai Ninomiya <kainino1@gmail.com>
Prohibit copyTextureToBuffer from compressed textures. Prohibit copyTextureToTexture where either source or destination is a compressed format. (copyBufferToTexture copies are ok.) This is restriction #3 from the compat proposal.
`GPUTextureViewDescriptor.dimension` must not be `"cube-array"` in Compatibility Mode (issue #4 from the compatibility-mode proposal).
Merge from 'main' at 20b5f62
At bind group creation time, validate that texture views contain all array layers (view.baseArrayLayer == 0, view.arrayLayerCount == texture.depthOrArrayLayers). This is [restriction #6](https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md#6-array-texture-views-used-in-bind-groups-must-consist-of-the-entire-array-that-is-basearraylayer-must-be-zero-and-arraylayercount-must-be-equal-to-the-size-of-the-texture-array) from the compatibility-mode proposal.
Prevent the use of rg32float, rg32sint, and rg32unit as STORAGE_BINDING in Compatibility Mode. Remove the line about createShaderModule() validation, since it's unnecessary. This is [restriction #8](https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md#8-disallow-two-component-rg-texture-formats-in-storage-texture-bindings) in the Compatibility Mode proposal. --------- Co-authored-by: Kai Ninomiya <kainino1@gmail.com>
During encoder bind group validation, validate that all `GPUTextureViews` in all bind groups containing a reference to the same `GPUTexture` must have matching `baseMipLevel`, `mipLevelCount`, and `aspect`. This validation represents [restriction #5](https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md#5-views-of-the-same-texture-used-in-a-single-draw-may-not-differ-in-aspect-or-mip-levels) in the Compatibility Mode proposal. --------- Co-authored-by: Kai Ninomiya <kainino1@gmail.com> Co-authored-by: Kai Ninomiya <kainino@chromium.org>
GPUDepthStencilState.depthBiasClamp must be zero in Compat mode. This represents [restriction 9](https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md#9-depth-bias-clamp-must-be-zero) from the Compatibility Mode proposal.
Source and destination `sampleCount` must be 1. This is [issue #12](https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md#12-disallow-copying-multisample-textures) in the Compatibility Mode proposal. --------- Co-authored-by: Kai Ninomiya <kainino1@gmail.com>
Add the Compatibility Mode limits to the limits table. Increase the `colspan` of the full-width rows to match the new column count (4 -> 5). Implement the Compat validation of maxVertexAttributes, in which `vertex_index` and `instance_index` each consume a slot. This represents [restriction 10](https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md#10-lower-limits) from the compatibility-mode proposal. --------- Co-authored-by: Mehmet Oguz Derin <mehmetoguzderin@mehmetoguzderin.com>
All members of viewFormats must be equal to the texture's format. This is achieved by changing the definition of "texture view format compatible" to be strict equality in Compatibility mode. This corresponds to [restriction 13](https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md#13-disallow-texture-format-reinterpretation) in the compatibility-mode proposal. --------- Co-authored-by: Kai Ninomiya <kainino@chromium.org>
Sync compat feature branch for CI
This represents restriction [23](https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md#23-disallow-all-multisampled-integer-textures) in the compatibility-mode proposal.
- bgra8unorm-srgb - multisampled r32float and rgba16float. This represents issues [15](https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md#15-disallow-bgra8unorm-srgb-textures) and [22](https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md#22-disallow-multisampled-rgba16float-and-r32float-textures) in the proposal doc.
Also modify the proposal doc to validate this at pipeline creation, not shader module creation. This represents issue [7](https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md#7-disallow-sample_mask-and-sample_index-builtins-in-wgsl) in the proposal doc. --------- Co-authored-by: Kai Ninomiya <kainino1@gmail.com>
Add `textureBindingViewDimension` to `GPUTexture` and `GPUTextureDescriptor`. Implement the defaulting algorithm for `GPUTextureDescriptor.textureBindingViewDimension`. Implement Compat-specific validation in `createBindGroup()` validation. --------- Co-authored-by: Kai Ninomiya <kainino1@gmail.com> Co-authored-by: Kai Ninomiya <kainino@chromium.org>
In Compatibility Mode, disallow interpolation type "linear", and interpolation sampling "sample" and "first". When interpolation type is "flat", allow only interpolation sampling "either". This represents restrictions [11](https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md#11-disallow-linear-and-sample-interpolation-options) and [17](https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md#17-disallow-interpolationflat-and-interpolationflat-first) in the compatibility-mode proposal. --------- Co-authored-by: Kai Ninomiya <kainino1@gmail.com>
Implement the depth texture restictions for Compatibility Mode: - no `textureLoad()` of depth textures - only comparison samplers with depth textures in texturing functions This represents restrictions [16](https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md#16-disallow-textureload-with-texture_depth-textures) and [20](https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md#20-disallow-using-a-depth-texture-with-a-non-comparison-sampler) from the compatibility-mode proposal.
2D textures must have a single layer. Cube textures must have 6 layers. This represents issue [14](https://github.com/SenorBlanco/gpuweb/blob/featurebranch-compat/proposals/compatibility-mode.md#14-require-depthorarraylayers-to-be-compatible-with-texturebindingviewdimension-in-createtexture) in the compatibility-mode proposal.
Implement new storage buffer and texture limits.
Implement the new limits:
- maxStorageBuffersInVertexStage
- maxStorageBuffersInFragmentStage
- maxStorageTexturesInVertexStage
- maxStorageTexturesInFragmentStage
This represents restrictions
[18]https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md#18-introduce-new-maxstoragebuffersinvertexstage-and-maxstoragetexturesinvertexstage-limits
and
[19]https://github.com/gpuweb/gpuweb/blob/main/proposals/compatibility-mode.md#19-introduce-new-maxstoragebuffersinfragmentstage-and-maxstoragetexturesinfragmentstage-limits
in the compatibility-mode proposal.
Limit maximum texture/sampler combinations
This represents restriction
[11](https://github.com/SenorBlanco/gpuweb/blob/featurebranch-compat/proposals/compatibility-mode.md#21-limit-the-number-of-texturesampler-combinations-in-a-stage)
in the compatibility-mode proposal.
Following up on #5361, this PR adds `swizzle` to the texture views match algorithm for compatibility mode.
Define an internal slot on the adapter for "default feature level". Use it to store the requested feature level (if supported). Use it to determine whether an adapter is "Core-defaulting" or "Compatibility-defaulting". Set the "core-featres-and-limits" feature in the device as appropriate. --------- Co-authored-by: Kai Ninomiya <kainino1@gmail.com>
|
I did a pass over all changes and how they map to the compat proposal, everything looks to be in; nice work! 🎉 |
maxCombinationsPerStage is no longer used (issue 22).
Merge branch 'main' into featurebranch-compat
This started with addressing François's editorial comment to define "Compatibility Mode", but I determined that most of the references to "Compatibility Mode" should actually be more descriptive and point more precisely to relevant definitions, and that the definitions of the feature level strings should be more comprehensive. Also removed definitions of "Core-defaulting" and "Compatibility-defaulting" in favor of direct links (but kept those phrases in the prose as they're useful for understanding). Additionally I noticed that were missing text to make `"core-features-and-limits"` increase the limits, and text to explicitly say we set the default limits depending on feature level. Fixed those. Issue: gpuweb#5402 (review)
This started with addressing François's editorial comment to define "Compatibility Mode", but I determined that most of the references to "Compatibility Mode" should actually be more descriptive and point more precisely to relevant definitions, and that the definitions of the feature level strings should be more comprehensive. Also removed definitions of "Core-defaulting" and "Compatibility-defaulting" in favor of direct links (but kept those phrases in the prose as they're useful for understanding). Additionally I noticed that were missing text to make `"core-features-and-limits"` increase the limits, and text to explicitly say we set the default limits depending on feature level. Fixed those. Issue: gpuweb#5402 (review)
This started with addressing François's editorial comment to define "Compatibility Mode", but I determined that most of the references to "Compatibility Mode" should actually be more descriptive and point more precisely to relevant definitions, and that the definitions of the feature level strings should be more comprehensive. Also removed definitions of "Core-defaulting" and "Compatibility-defaulting" in favor of direct links (but kept those phrases in the prose as they're useful for understanding). Additionally I noticed that were missing text to make `"core-features-and-limits"` increase the limits, and text to explicitly say we set the default limits depending on feature level. Fixed those. Issue: gpuweb#5402 (review)
This started with addressing François's editorial comment to define "Compatibility Mode", but I determined that most of the references to "Compatibility Mode" should actually be more descriptive and point more precisely to relevant definitions, and that the definitions of the feature level strings should be more comprehensive. Also removed definitions of "Core-defaulting" and "Compatibility-defaulting" in favor of direct links (but kept those phrases in the prose as they're useful for understanding). Additionally I noticed that were missing text to make `"core-features-and-limits"` increase the limits, and text to explicitly say we set the default limits depending on feature level. Fixed those. Issue: gpuweb#5402 (review)
GPU Web WG 2025-11-05 Atlantic-time
|
When descriptor.textureBindingViewDimension is not provided, set the texture's textureBindingViewDimension to the defaults, not the descriptor's textureBindingViewDimension. Add a Note: to explain that the validation of the textureBindingViewDimension in the descriptor is not applied to the defaulted value (which is ok). --------- Co-authored-by: Kai Ninomiya <kainino1@gmail.com>
This started with addressing François's editorial comment to define "Compatibility Mode", but I determined that most of the references to "Compatibility Mode" should actually be more descriptive and point more precisely to relevant definitions, and that the definitions of the feature level strings should be more comprehensive. Also removed definitions of "Core-defaulting" and "Compatibility-defaulting" in favor of direct links (but kept those phrases in the prose as they're useful for understanding). Additionally I noticed that were missing text to make `"core-features-and-limits"` increase the limits, and text to explicitly say we set the default limits depending on feature level. Fixed those. Issue: #5402 (review)
kainino0x
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Editor stamp of approval
|
I thought I did this as a merge commit, but apparently not? |
) Relanding #5402 as a merge commit. I accidentally landed it as a squash commit the first time (somehow) but I want to preserve the branch history. --------- Co-authored-by: Stephen White <senorblanco@chromium.org> Co-authored-by: Mehmet Oguz Derin <mehmetoguzderin@mehmetoguzderin.com> Co-authored-by: François Beaufort <beaufortfrancois@gmail.com>
|
Fixed in #5447. |
|
And deleted the |
Land Compatibility Mode specification changes.