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

Compat: remove adapter.featureLevel; add "core-features-and-limits" #5036

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

Merged
merged 2 commits into from
Feb 19, 2025

Conversation

kainino0x
Copy link
Contributor

@kainino0x kainino0x commented Jan 7, 2025

Stacked on #5056. You can ignore first commit for a cleaner diff.
The text here also assumes that no Compat features exist, which is not actually true until #5055 lands.

This PR applies the combination of choices the WG decided to move forward with on 2025-01-29, the main change being "webgpu-core" (which this PR was for originally, before updating it to account for the other stuff).

As discussed:

  • Removes adapter.featureLevel
  • Does not provide anything for Compat features (but includes notes on how they could be added later)
  • Adds "webgpu-core" feature (up for bikeshedding)

Original PR summary

This is a proposal.

This is separate from, but not in conflict with, adding features that lift each of the Compat restrictions (PR #5018). I think it is valuable either way. It provides several things:

  • Ability to check if an unnamed feature is available: adapter.features.has('specific-compat-feature') || adapter.features.has('webgpu-core'). This helps if we need to add a feature later and older browsers don't know that feature yet. Otherwise, the only way to deal with this is to call requestAdapter twice (first with core, then fallback to compat)[1].
  • Ability to check if a device was created with all core capabilities.
  • Along with this reduces the amount of API warts.

[1]: I think avoiding this is a design goal, but I'm not sure we ever decided that for sure. Would be good to resolve.

See #5037 for some extra discussion of removing adapter.featureLevel.

Issue: #4266, #4987
(Partially subsumes old PR #4898, subsumes #5037)

@kainino0x kainino0x added the compat WebGPU Compatibility Mode label Jan 7, 2025
kainino0x added a commit to kainino0x/gpuweb that referenced this pull request Jan 7, 2025
Copy link
Contributor

github-actions bot commented Jan 10, 2025

Previews, as seen when this build job started (c543748):
WebGPU webgpu.idl | Explainer | Correspondence Reference
WGSL grammar.js | wgsl.lalr.txt

@Kangz
Copy link
Contributor

Kangz commented Jan 27, 2025

GPU Web WG 2025-01-22 Atlantic-time
  • JB: How does this relate to How to add features and limits for Compat after Core ships? #4987? Do we still want this if we pick that?
  • KN: This lets you ask for a compat adapter, look at its feature, decide that if you’re missing something, to then ask for core.
    • So this, if you ask for compat, can give you a core-compatible adapter back if you ask for this feature, but without this feature, it wouldn't be possible to lift all compat limitations.
  • BJ: What’s the benefit of this vs asking for core first, else asking for compat? It feels like thtt’s the same functionality, just asking in reverse?
  • KN: That would work, but:
    • If it’s a feature that you want, you can check if the [compat] device if it has it.
    • Avoids having to call requestAdapter twice, and the associated logic of picking features and limits etc.
  • KN: It’s not a huge advantage, but it does help a little.
  • BJ: So si this at device-creation?
  • KN: Yes
  • BJ: And that would remove the compat validation [on the resulting device?]?
  • KN: Right.
  • BJ: And if compat not implemented, if you just call requestAdapter with no args or with compat, you get the same thing?

@kainino0x kainino0x marked this pull request as draft January 29, 2025 22:18
@kainino0x kainino0x added this to the Milestone 1 milestone Jan 29, 2025
@kainino0x kainino0x force-pushed the compat-upgradeable-to-core branch 3 times, most recently from 5c05ede to d77d783 Compare January 30, 2025 03:05
@kainino0x kainino0x changed the title Compat: add "webgpu-core" feature so Compat adapters can be Core-capable Compat: remove adapter.featureLevel; add "webgpu-core" Jan 30, 2025
@kainino0x kainino0x force-pushed the compat-upgradeable-to-core branch from d77d783 to 239113a Compare January 30, 2025 23:02
@kainino0x kainino0x marked this pull request as ready for review January 30, 2025 23:03
Copy link
Contributor

@greggman greggman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@kainino0x kainino0x force-pushed the compat-upgradeable-to-core branch from 239113a to b630b51 Compare January 30, 2025 23:11
@kainino0x
Copy link
Contributor Author

Oops, forgot to rebase over #5056 first. Done. PTAL! (also cc @mwyrzykowski since I can't re-request you)

@greggman greggman force-pushed the compat-upgradeable-to-core branch from b630b51 to c543748 Compare February 5, 2025 22:50
@greggman
Copy link
Contributor

greggman commented Feb 5, 2025

@mwyrzykowski @jimblandy ok to merge?

Copy link
Contributor

@jimblandy jimblandy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is approved, on the understanding that this PR is simply noting that we are still bikeshedding the name, and a later PR will actually record the result of that bikeshedding.

@kainino0x kainino0x self-assigned this Feb 19, 2025
@kainino0x
Copy link
Contributor Author

As agreed in the meeting, picked the name "core-features-and-limits". Applied that; landing the PR.

@kainino0x kainino0x changed the title Compat: remove adapter.featureLevel; add "webgpu-core" Compat: remove adapter.featureLevel; add "core-features-and-limits" Feb 19, 2025
@kainino0x kainino0x merged commit 9ba16d7 into gpuweb:main Feb 19, 2025
4 checks passed
@kainino0x kainino0x deleted the compat-upgradeable-to-core branch February 19, 2025 19:08
copybara-service bot pushed a commit to google/dawn that referenced this pull request Mar 1, 2025
Reflecting gpuweb/gpuweb#5036

Bug: 395855517
Change-Id: I09ec62db124cb20496594b6b76ca4c931596256e
Reviewed-on: https://dawn-review.googlesource.com/c/dawn/+/226954
Reviewed-by: Kai Ninomiya <kainino@chromium.org>
Commit-Queue: Shrek Shao <shrekshao@google.com>
Auto-Submit: Shrek Shao <shrekshao@google.com>
Reviewed-by: Gregg Tavares <gman@google.com>
@Kangz
Copy link
Contributor

Kangz commented Mar 5, 2025

GPU Web WG 2025-02-19 Atlantic-time
  • JB: want to make progress, doesn't commit us to anything. Mike and I both approved this PR at this point. Want to discuss the actual names.
  • KN: if people want to land this with the TODO we can do it. We want to start implementing it.
  • JB: Moz's first choice is "core-features-and-limits" - precise, but verbose.
  • KR: do you really want to write that in every WebGPU app?
  • JB: mostly for apps, not really demos.
  • KN: you really only write this if you care about supporting both Compat and Core.
  • CW: what's nice is it's forward-thinking - we will want to say "features and limits" in the future.
  • CW: OK, let's go with this.
  • KN: SGTM.

aarongable pushed a commit to chromium/chromium that referenced this pull request Mar 10, 2025
Reflecting gpuweb/gpuweb#5036

Bug: 395855517
Change-Id: I7d9164a6a0825c2636195dce32e41da61b839136
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6307124
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Shrek Shao <shrekshao@google.com>
Cr-Commit-Position: refs/heads/main@{#1430440}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compat WebGPU Compatibility Mode proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants