这是indexloc提供的服务,不要输入任何密码
Skip to content

Conversation

@SenorBlanco
Copy link
Contributor

Land Compatibility Mode specification changes.

SenorBlanco and others added 27 commits June 4, 2025 11:36
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).
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
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.
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.
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>
@SenorBlanco SenorBlanco changed the title Featurebranch compat Implement Compatibility Mode Oct 20, 2025
@SenorBlanco SenorBlanco changed the title Implement Compatibility Mode Specify Compatibility Mode Oct 20, 2025
@SenorBlanco SenorBlanco requested a review from kainino0x October 20, 2025 21:44
@jimblandy jimblandy removed this from WGSL Oct 29, 2025
@teoxoy
Copy link
Member

teoxoy commented Nov 3, 2025

I did a pass over all changes and how they map to the compat proposal, everything looks to be in; nice work! 🎉

@kainino0x kainino0x added this to the Milestone 2 milestone Nov 3, 2025
maxCombinationsPerStage is no longer used (issue 22).
kainino0x added a commit to kainino0x/gpuweb that referenced this pull request Nov 17, 2025
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)
kainino0x added a commit to kainino0x/gpuweb that referenced this pull request Nov 17, 2025
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)
kainino0x added a commit to kainino0x/gpuweb that referenced this pull request Nov 17, 2025
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)
kainino0x added a commit to kainino0x/gpuweb that referenced this pull request Nov 17, 2025
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)
@Kangz
Copy link
Contributor

Kangz commented Nov 18, 2025

GPU Web WG 2025-11-05 Atlantic-time
  • CW: any
  • JB: Teo had one point about derivatives, but other than that, he looked it over and says everything looks great
    • Are "Fine" derivatives guaranteed to actually be fine? #4325
  • CF: think we should expect fine, and if we can't provide it, warn
  • SW: Intel Mac doesn't support fine in core
  • KN: Mike told us if you use the fine derivatives in Mac Intel Metal, you'll get coarse. Metal doesn't have coarse/fine derivatives. All variants have the same impl. Coarse are always allowed to be fine, unfortunately. Will never be fixed.
  • CW: that sounds like a bug but we feel we can emulate these with quad shuffles
  • KN: yes, think we can make core give you fine derivatives when you ask for fine. So I think it's fine to disallow fine derivatives in Compat.
  • CF: emulating on top of subgroup ops sounds not possible unless all Mac impls require subgroup ops. These might not exist.
  • KN: sounds like they always exist on those Macs.
  • CW: so full subgroup quad shuffle on macOS requires MSL 2.1 (James Price?). Supported in macOS 10.15 which is MSL 2.2. Worst case we can say it's a driver bug.
  • SW: should we raise an error in Compat if you try to use fine derivatives?
  • KN: think so.
  • CW: yes.
  • SW: will put up a PR for that. We want to do this before merge?
  • CW: think so. This is the biggest issue remaining. Can we have agreement to merge after this is fixed and we fix editorial issues?
  • TT: sounds fine.
  • CW: and Mike was happy with this as well. Awesome!

SenorBlanco and others added 2 commits November 18, 2025 16:08
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)
Copy link
Contributor

@kainino0x kainino0x left a 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

@kainino0x kainino0x merged commit 8f4ff8c into main Nov 19, 2025
4 checks passed
@kainino0x
Copy link
Contributor

I thought I did this as a merge commit, but apparently not?
I'm going to force push to fix this. Sorry if this causes anyone issues.

kainino0x added a commit that referenced this pull request Nov 19, 2025
)

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>
@kainino0x
Copy link
Contributor

Fixed in #5447.

@kainino0x kainino0x deleted the featurebranch-compat branch November 19, 2025 21:30
@kainino0x
Copy link
Contributor

And deleted the featurebranch-compat branch now that its history is in main.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

api WebGPU API compat WebGPU Compatibility Mode

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants