Intent to Ship: WebGPU

4,851 views
Skip to first unread message

Corentin Wallez

unread,
Dec 14, 2022, 12:02:51 PM12/14/22
to blink-dev

Hey Blink API owners,


WebGPU has been in development for almost six years but we now feel that it is ready to ship with both the implementation and the specification in good shape. We are targeting shipping in M113 though there's still some work to do, so this is an aspirational milestone and could slip one or two milestones.

The Origin Trial for WebGPU expires starting in M110 so we will also have a separate intent to extend the experiment to cover until M114 to try and have continuity of the availability (with one more release instead of M113 in the case that shipping slips one release).

Details are below:

Contact emails

cwa...@chromium.orgbcla...@google.comkai...@chromium.org

Explainer

https://gpuweb.github.io/gpuweb/explainer

Specification

https://gpuweb.github.io/gpuweb

Design docs


https://gpuweb.github.io/gpuweb
https://gpuweb.github.io/gpuweb/wgsl
https://gpuweb.github.io/gpuweb/explainer

Summary

The WebGPU API is the successor to the WebGL and WebGL 2 graphics APIs for the Web. It provides modern features such as “GPU compute” as well as lower overhead access to GPU hardware and better, more predictable performance. WebGPU is being developed by the “GPU for the Web” W3C community group.



Blink component

Blink>WebGPU

Search tags

gpuwebgl

TAG review

https://github.com/w3ctag/design-reviews/issues/626

TAG review status

Issues addressed

Risks



Interoperability and Compatibility

With positive signals (and at least WIP implementations) from all browsers and few unresolved issues in the spec repo, the compatibility risk is low and mostly if other implementers find bugs in the spec as they flesh out their WebGPU implementation.



Gecko: Positive (https://mozilla.github.io/standards-positions/#webgpu) Development is also ongoing, see: https://hg.mozilla.org/mozilla-central/file/tip/dom/webgpu

WebKit: In development (https://github.com/WebKit/WebKit/tree/main/Source/WebGPU/WebGPU) Standard position issue: https://github.com/WebKit/standards-positions/issues/107

Web developers: Strongly positive (https://doc.babylonjs.com/extensions/webgpu) Significant interest and positive feedback from the many early adopters (Babylon.js, Earth, TF.js, sokol-gfx, and many many others).

Other signals:

Activation

WebGPU is not polyfillable on existing APIs and requires hardware support on the system. (software fallback is not implemented yet).



Security

See detailed security explainer: https://gpuweb.github.io/gpuweb/#malicious-use



WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?



Debuggability

Warnings and errors are exposed via dev tools. Specialized tools can be built directly in JavaScript, integrated in applications or as devtools extensions.



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No

This feature will not be available on: - Windows 7 and 8 since they don't have D3D12. Support will be extended to these versions of Windows after the first version of WebGPU is shipped. (though they get software fallback) - Android because adding Android support is a lot of engineering that we're scheduling to happen after the release of WebGPU on desktop. - Non-ChromeOS Linux due to dependencies on other reworks of the graphics stack there. (though it will get software fallback) - Other devices that don't support D3D12/Metal/Vulkan or don't have a GPU with good enough minimum specifications.(maybe) The goal is that WebGPU will eventually be supported in hardware on the vast majority of systems on all Blink OSes and have software fallback on the others. In the short-term developers are expected to feature detect whether WebGPU is supported by checking if `navigator.gpu` exists and if `navigator.gpu.requestAdapter` resolves with a non-null GPUAdapter. If WebGPU is not supported then falling back to WebGL or another experience is appropriate. Long-term developers should be able to expect that WebGPU is close to universally available (similar to WebGL 2 today).



Is this feature fully tested by web-platform-tests?

Yes

The WebGPU Conformance Test Suite is being built at https://github.com/gpuweb/cts and can be integrated as a subdirectory of WPT. Coverage is still incomplete due to the complexity of the API but progressing quickly. We expect to ship with coverage holes, but with most important and risky aspects of interoperability well tested.

DevTrial instructions

https://github.com/gpuweb/gpuweb/wiki/Implementation-Status#chromium-chrome-edge-etc

Flag name

--enable-unsafe-webgpu

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1156646

Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1156661

Sample links


https://github.com/austinEng/webgpu-samples

Estimated milestones

OriginTrial desktop last109
OriginTrial desktop first94


Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

Some issues are still open for discussion on the WebGPU and WGSL specification. They will all be solved by the time we ship WebGPU although new issues can appear in the meantime: we definitely expect to have minor spec bugs after shipping WebGPU but the overwhelming majority of the spec should see no behavioral changes.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6213121689518080

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/forum
Intent to Experiment: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/K4_egTNAvTs
Intent to Extend Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGdfWNMtD9aCpKFbC9HqHMaeSX_840ayvXcjFX2xMUt_MEN_XQ%40mail.gmail.com

Rick Byers

unread,
Dec 21, 2022, 11:14:37 AM12/21/22
to Corentin Wallez, blink-dev
Hi Corentin,
It's exciting to see WebGPU close to shipping! Clearly the broad support across browser vendors and web developers means it's just a matter of when, not if, WebGPU will ship. The primary job of API owners in this case is to help ensure that the design and implementation have crossed a threshold of maturity and stability such that a fully interoperable implementation across browsers is the likely outcome, and that that interoperability is not determined unreasonably by concerns over compatibility with existing content.

For a feature as broad and complex as WebGPU, evaluating the level of maturity is obviously quite complex (especially for someone with little context like myself). Mostly I think we need to lean on the judgments of experts like yourself, and (if they're willing) those working on other implementations. To do that, I'd ask that you publish more of your work showing how you've evaluated that stability and why you feel the bar has been (or will soon be) crossed. In particular:
  • Skimming the detailed explainer, I see there is at least one section still marked "API in flux". Can you characterize the precise API surface area covered by this I2S and whether it includes areas such as Image, video and canvas input whose API design is "still in flux"? 
  • Looking through the list of 313 open spec issues it's hard for me to get a sense of which, if any, represent likely future compat issues. Has the group done a bug triage pass to mark bugs whose decisions are important to resolve prior to the first shipping implementation? Going through the labels briefly, I wasn't able to easily differentiate what seems like minor editorial issues and future enhancements from those with potential compat implications, except perhaps through subtraction (but that leaves 161 issues still).
  • Thanks for the extra comments on conformance testing in Chrome Status:
      • "The WebGPU Conformance Test Suite is being built at https://github.com/gpuweb/cts and can be integrated as a subdirectory of WPT. Coverage is still incomplete due to the complexity of the API but progressing quickly. We expect to ship with coverage holes, but with most important and risky aspects of interoperability well tested."
      • Are there implementation conformance reports published anywhere for the different implementations for us to review? 
      • I'm supportive of this nuanced position in general - for a complex feature like this, it likely won't make sense to aim for 100% coverage and test passing prior to shipping. But of course the devil is in the details of "most important and risky aspects". The key question on my mind is how much of a burden would we be placing on other implementations if we were to ship with any given leverage of test coverage. I.e. what's the risk that we're offloading work onto Gecko or WebKit engineers where, to get a compatible implementation in practice, they would have to go well beyond getting the test suite passing and a set of samples working. The easiest way to address that question may be for those other implementers to chime in here with their judgement, but failing (or in addition to) that an analysis by you and your team about the state of test coverage and some quantification of the level of risk would be helpful.
    • In addition, since the WebGPU CTS is not yet integrated into WPT, can you describe the level of regression (and future failure) detection that's in place in chromium? I.e. are we running this CTS on the CQ such that regressions will not be able to land? If another implementor submits a new test or test update what process exists to flag newly failing tests in chromium?
    Thanks,
       Rick


    --
    You received this message because you are subscribed to the Google Groups "blink-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
    To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGdfWNOERFV9DFZERpsP2T75g%3DF%2BwFquV1Oxdiea%2BvP4kKg4cw%40mail.gmail.com.

    Corentin Wallez

    unread,
    Dec 21, 2022, 12:10:10 PM12/21/22
    to Rick Byers, blink-dev, Kai Ninomiya, Brandon Jones
    Thank you Rick for the feedback, I'll try to answer the various questions you have inline but I'm sure more will come up! I'll be OOO shortly, so CCing a couple folks explicitly for future questions.

    On Wed, Dec 21, 2022 at 5:14 PM Rick Byers <rby...@chromium.org> wrote:
    Hi Corentin,
    It's exciting to see WebGPU close to shipping! Clearly the broad support across browser vendors and web developers means it's just a matter of when, not if, WebGPU will ship. The primary job of API owners in this case is to help ensure that the design and implementation have crossed a threshold of maturity and stability such that a fully interoperable implementation across browsers is the likely outcome, and that that interoperability is not determined unreasonably by concerns over compatibility with existing content.

    For a feature as broad and complex as WebGPU, evaluating the level of maturity is obviously quite complex (especially for someone with little context like myself). Mostly I think we need to lean on the judgments of experts like yourself, and (if they're willing) those working on other implementations. To do that, I'd ask that you publish more of your work showing how you've evaluated that stability and why you feel the bar has been (or will soon be) crossed. In particular:
    • Skimming the detailed explainer, I see there is at least one section still marked "API in flux". Can you characterize the precise API surface area covered by this I2S and whether it includes areas such as Image, video and canvas input whose API design is "still in flux"? 
    The explainer should be updated, this API went through many revisions but is no longer in flux. What is in the explainer describes the current shape of the API so we could polish the explainer and remove the issues. The area covered by the I2S is everything that's inside the current WebGPU and WGSL specifications (with potential exceptions of the few already defined "optional features" that are not required to be supported by implementations). I filed an issue to fix up the explainer.
    • Looking through the list of 313 open spec issues it's hard for me to get a sense of which, if any, represent likely future compat issues. Has the group done a bug triage pass to mark bugs whose decisions are important to resolve prior to the first shipping implementation? Going through the labels briefly, I wasn't able to easily differentiate what seems like minor editorial issues and future enhancements from those with potential compat implications, except perhaps through subtraction (but that leaves 161 issues still).
    There are a LOT of issues in the spec repo but a large number of them are feature requests or investigations for features that will be considered only for after the first release of WebGPU. This I2S covers all issues in the "V1" milestone. In general to track progress of consensus we remove:
    • editorial issues that are not things the group needs to take decisions on, and tracks spec writing
    • meta issues that are used for more process-ey things
    The list of items to discuss for V1 without these currently has 14 items, with only a couple that we expect to still have any contentious discussions on. (compared to the 411 close V1 non-editorial issues, this is VERY small).
    • Thanks for the extra comments on conformance testing in Chrome Status:
      • "The WebGPU Conformance Test Suite is being built at https://github.com/gpuweb/cts and can be integrated as a subdirectory of WPT. Coverage is still incomplete due to the complexity of the API but progressing quickly. We expect to ship with coverage holes, but with most important and risky aspects of interoperability well tested."
      • Are there implementation conformance reports published anywhere for the different implementations for us to review? 
      • I'm supportive of this nuanced position in general - for a complex feature like this, it likely won't make sense to aim for 100% coverage and test passing prior to shipping. But of course the devil is in the details of "most important and risky aspects". The key question on my mind is how much of a burden would we be placing on other implementations if we were to ship with any given leverage of test coverage. I.e. what's the risk that we're offloading work onto Gecko or WebKit engineers where, to get a compatible implementation in practice, they would have to go well beyond getting the test suite passing and a set of samples working. The easiest way to address that question may be for those other implementers to chime in here with their judgement, but failing (or in addition to) that an analysis by you and your team about the state of test coverage and some quantification of the level of risk would be helpful.
    • Chromium runs the CTS on CQ (more one that below) and has the only conformance report published that I know of, in its expectation file. It has many entries but 1) we will triage and fix most of the fixable ones by shipment and 2) it is small compared to the massive amount of tests in this WebGPU CTS.
    • WebKit ran the CTS in the past and caught bugs (both theirs and the CTS) with it, but that was more than a year ago before they nuked and restarted their WebGPU implementation (which is still in early stages).
    • Firefox is not running the CTS at the moment and is focused on other things in the short term, but Mozilla engineers shared they would be looking at integrating the CTS shortly (and fixing issues found). Their implementation of the core WebGPU libraries (Dawn/Tint equivalent) is only slightly behind Chromium and the spec, but are already massively used as graphics middleware in the Rust ecosystem. Their integration in Firefox is more in progress but already usable to run some content (but needs more work on security for example)
    I would also love for other implementers to chime in on the level of risk they see. Subjectively we have found that while there are many subtle bugs at the intersection of multiple features of WebGPU, things work surprisingly well together once tested in isolation. We see bugs coming from developers experimenting with WebGPU but relatively few of them would have been caught by the CTS (and sometimes they are just very weird driver bugs). Interoperability is already surprisingly good between Firefox and Chromium's implementations, with some extremely advanced use cases like vello running correctly on both implementations with the same code. The goal is definitely not to offload compatibility work on other implementations: Chromium contributors built the vast majority of the CTS, but we will keep expanding it after V1, and help address any bugs raised by other implementers (and fix Chromium if needed too). Do you have additional ideas on how this risk could be mitigated?
    • In addition, since the WebGPU CTS is not yet integrated into WPT, can you describe the level of regression (and future failure) detection that's in place in chromium? I.e. are we running this CTS on the CQ such that regressions will not be able to land? If another implementor submits a new test or test update what process exists to flag newly failing tests in chromium?
    The WebGPU CTS runs automatically on all Dawn/Tint commits (the WebGPU core libraries) as well as when many GPU-related paths of Chromium are touched. These tests run all the WebGPU CTS on Windows/macOS/Linux, on multiple GPU (and software fallback) configurations. The WebGPU CTS is rolled mostly automatically every day and new expectations added (here is a typical roll). If updates to the CTS cause failures we will notice them in the "untriaged failures" bucket and fix them.

    Rick Byers

    unread,
    Dec 21, 2022, 1:34:24 PM12/21/22
    to Corentin Wallez, blink-dev, Kai Ninomiya, Brandon Jones
    On Wed, Dec 21, 2022 at 12:10 PM Corentin Wallez <cwa...@chromium.org> wrote:
    Thank you Rick for the feedback, I'll try to answer the various questions you have inline but I'm sure more will come up! I'll be OOO shortly, so CCing a couple folks explicitly for future questions.

    Thanks Corentin. Since you're targeting shipping in M113 (branch in March), I assume there's no harm in waiting until ~mid January to get a decision from API owners on this, right? That might give some time for others to digest and contribute their own judgement to this thread.

    On Wed, Dec 21, 2022 at 5:14 PM Rick Byers <rby...@chromium.org> wrote:
    Hi Corentin,
    It's exciting to see WebGPU close to shipping! Clearly the broad support across browser vendors and web developers means it's just a matter of when, not if, WebGPU will ship. The primary job of API owners in this case is to help ensure that the design and implementation have crossed a threshold of maturity and stability such that a fully interoperable implementation across browsers is the likely outcome, and that that interoperability is not determined unreasonably by concerns over compatibility with existing content.

    For a feature as broad and complex as WebGPU, evaluating the level of maturity is obviously quite complex (especially for someone with little context like myself). Mostly I think we need to lean on the judgments of experts like yourself, and (if they're willing) those working on other implementations. To do that, I'd ask that you publish more of your work showing how you've evaluated that stability and why you feel the bar has been (or will soon be) crossed. In particular:
    • Skimming the detailed explainer, I see there is at least one section still marked "API in flux". Can you characterize the precise API surface area covered by this I2S and whether it includes areas such as Image, video and canvas input whose API design is "still in flux"? 
    The explainer should be updated, this API went through many revisions but is no longer in flux. What is in the explainer describes the current shape of the API so we could polish the explainer and remove the issues. The area covered by the I2S is everything that's inside the current WebGPU and WGSL specifications (with potential exceptions of the few already defined "optional features" that are not required to be supported by implementations). I filed an issue to fix up the explainer.

    Great, that's nice and simple. Thanks. 
    • Looking through the list of 313 open spec issues it's hard for me to get a sense of which, if any, represent likely future compat issues. Has the group done a bug triage pass to mark bugs whose decisions are important to resolve prior to the first shipping implementation? Going through the labels briefly, I wasn't able to easily differentiate what seems like minor editorial issues and future enhancements from those with potential compat implications, except perhaps through subtraction (but that leaves 161 issues still).
    There are a LOT of issues in the spec repo but a large number of them are feature requests or investigations for features that will be considered only for after the first release of WebGPU. This I2S covers all issues in the "V1" milestone. In general to track progress of consensus we remove:
    • editorial issues that are not things the group needs to take decisions on, and tracks spec writing
    • meta issues that are used for more process-ey things
    The list of items to discuss for V1 without these currently has 14 items, with only a couple that we expect to still have any contentious discussions on. (compared to the 411 close V1 non-editorial issues, this is VERY small).

    Ah great, sorry I didn't think to check milestones. That indeed looks much more tractable. There are a couple potentially scary issues there but in general I agree this gives the impression to me of being in range of the maturity we expect for shipping a big new feature.
    • Thanks for the extra comments on conformance testing in Chrome Status:
      • "The WebGPU Conformance Test Suite is being built at https://github.com/gpuweb/cts and can be integrated as a subdirectory of WPT. Coverage is still incomplete due to the complexity of the API but progressing quickly. We expect to ship with coverage holes, but with most important and risky aspects of interoperability well tested."
      • Are there implementation conformance reports published anywhere for the different implementations for us to review? 
      • I'm supportive of this nuanced position in general - for a complex feature like this, it likely won't make sense to aim for 100% coverage and test passing prior to shipping. But of course the devil is in the details of "most important and risky aspects". The key question on my mind is how much of a burden would we be placing on other implementations if we were to ship with any given leverage of test coverage. I.e. what's the risk that we're offloading work onto Gecko or WebKit engineers where, to get a compatible implementation in practice, they would have to go well beyond getting the test suite passing and a set of samples working. The easiest way to address that question may be for those other implementers to chime in here with their judgement, but failing (or in addition to) that an analysis by you and your team about the state of test coverage and some quantification of the level of risk would be helpful.
    • Chromium runs the CTS on CQ (more one that below) and has the only conformance report published that I know of, in its expectation file. It has many entries but 1) we will triage and fix most of the fixable ones by shipment and 2) it is small compared to the massive amount of tests in this WebGPU CTS.
    • WebKit ran the CTS in the past and caught bugs (both theirs and the CTS) with it, but that was more than a year ago before they nuked and restarted their WebGPU implementation (which is still in early stages).
    • Firefox is not running the CTS at the moment and is focused on other things in the short term, but Mozilla engineers shared they would be looking at integrating the CTS shortly (and fixing issues found). Their implementation of the core WebGPU libraries (Dawn/Tint equivalent) is only slightly behind Chromium and the spec, but are already massively used as graphics middleware in the Rust ecosystem. Their integration in Firefox is more in progress but already usable to run some content (but needs more work on security for example)
    I would also love for other implementers to chime in on the level of risk they see. Subjectively we have found that while there are many subtle bugs at the intersection of multiple features of WebGPU, things work surprisingly well together once tested in isolation. We see bugs coming from developers experimenting with WebGPU but relatively few of them would have been caught by the CTS (and sometimes they are just very weird driver bugs). Interoperability is already surprisingly good between Firefox and Chromium's implementations, with some extremely advanced use cases like vello running correctly on both implementations with the same code. The goal is definitely not to offload compatibility work on other implementations: Chromium contributors built the vast majority of the CTS, but we will keep expanding it after V1, and help address any bugs raised by other implementers (and fix Chromium if needed too). Do you have additional ideas on how this risk could be mitigated?

    Great, thank you! Examples of sites working correctly on multiple implementations with the same code is definitely strong evidence of plausible interoperability and a relatively mature spec and conformance test suite. Absent evidence to the contrary, I'm inclined to say that the nuance you've added here meets our I2S bar around conformance testing and maximizing future interoperability, but again I'd like to give some time in Jan for others to chime in with other perspectives given the scope of this feature.
    • In addition, since the WebGPU CTS is not yet integrated into WPT, can you describe the level of regression (and future failure) detection that's in place in chromium? I.e. are we running this CTS on the CQ such that regressions will not be able to land? If another implementor submits a new test or test update what process exists to flag newly failing tests in chromium?
    The WebGPU CTS runs automatically on all Dawn/Tint commits (the WebGPU core libraries) as well as when many GPU-related paths of Chromium are touched. These tests run all the WebGPU CTS on Windows/macOS/Linux, on multiple GPU (and software fallback) configurations. The WebGPU CTS is rolled mostly automatically every day and new expectations added (here is a typical roll). If updates to the CTS cause failures we will notice them in the "untriaged failures" bucket and fix them.

    Sounds great, thanks. Having a live dashboard like wpt.fyi is nice but certainly not a requirement.  I see that many of the failing expectations are pointing at bugs in the "Proj-WebGPU-Milestone-V1" label. I assume this is the set of bugs you'll be triaging and burning down to decide when you're ready to ship, is that right?

    Kai Ninomiya

    unread,
    Dec 28, 2022, 5:23:42 PM12/28/22
    to Rick Byers, Corentin Wallez, blink-dev, Brandon Jones

    -Kai (he/they)


    Yes, that's correct, plus the Milestone-V1 issues in the Dawn issue tracker:

    Rick Byers

    unread,
    Jan 11, 2023, 10:37:22 AM1/11/23
    to Kai Ninomiya, Corentin Wallez, blink-dev, Brandon Jones
    Just following up on this now that most folks are fully back to work after the holidays.

    My main outstanding question is what exactly the launch quality bar is, given you don't expect to be ready until March. I love that you've gotten this thread started early, hopefully that'll reduce the risk of late surprises. Are you asking for approval to ship assuming all the known issues in the Proj-WebGpu-Milestone-V1 list are fixed or otherwise determined to be non-launch-blocking and removed from the list? I think a clear list like this is a great way to signal to potential customers and other implementers what quality bar we're holding ourselves to and to give them an opportunity to object to any specific detail they disagree with.

    Thanks,
       Rick

    slightlyoff via Chromestatus

    unread,
    Jan 11, 2023, 11:52:16 AM1/11/23
    to blin...@chromium.org
    An enthusiastic LGTM1 from me. Congrats on getting to this point; a big moment.

    Rick Byers

    unread,
    Jan 11, 2023, 12:06:22 PM1/11/23
    to slightlyoff via Chromestatus, blin...@chromium.org
    We discussed in the API owner meeting and agree that we are impressed with all the work that's gone into interoperability here and the broad general support across implementers. We have high confidence that the team is setting an appropriately high quality bar both for shipping and for ongoing updates and interoperability improvements post-ship. So LGTM2 to ship whenever the team feels it's ready.

    This feature has been a long time in the making and I'm excited to see it launch ASAP, great work!

    Rick

    On Wed, Jan 11, 2023 at 11:52 AM slightlyoff via Chromestatus <admin+sl...@cr-status.appspotmail.com> wrote:
    An enthusiastic LGTM1 from me. Congrats on getting to this point; a big moment.

    --
    You received this message because you are subscribed to the Google Groups "blink-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

    Yoav Weiss

    unread,
    Jan 11, 2023, 12:18:17 PM1/11/23
    to Rick Byers, slightlyoff via Chromestatus, blin...@chromium.org

    Corentin Wallez

    unread,
    Jan 11, 2023, 12:57:53 PM1/11/23
    to blink-dev, Yoav Weiss, slightlyoff via Chromestatus, blin...@chromium.org, Rick Byers
    Thank you everyone for the LGTMs!

    We're super excited to get a high-quality WebGPU implementation in developer's hands! The list of issues we are tracking on the implementation side are these three (for the three parts that make WebGPU) and we expect to fix most issues before shipping, with clear rational of why the ones that aren't can be delayed. Of course we expect to find new issues as we keep expanding the test suite but will add them to the bug trackers I just linked for V1 tracking as well.

    On Wednesday, January 11, 2023 at 6:18:17 PM UTC+1 Yoav Weiss wrote:
    LGTM3

    On Wed, Jan 11, 2023 at 6:06 PM Rick Byers <rby...@chromium.org> wrote:
    We discussed in the API owner meeting and agree that we are impressed with all the work that's gone into interoperability here and the broad general support across implementers. We have high confidence that the team is setting an appropriately high quality bar both for shipping and for ongoing updates and interoperability improvements post-ship. So LGTM2 to ship whenever the team feels it's ready.

    This feature has been a long time in the making and I'm excited to see it launch ASAP, great work!

    Rick

    On Wed, Jan 11, 2023 at 11:52 AM slightlyoff via Chromestatus <admin+slightlyoff@cr-status.appspotmail.com> wrote:
    An enthusiastic LGTM1 from me. Congrats on getting to this point; a big moment.

    --
    You received this message because you are subscribed to the Google Groups "blink-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

    --
    You received this message because you are subscribed to the Google Groups "blink-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

    Ashley Gullen

    unread,
    Jan 12, 2023, 5:55:53 AM1/12/23
    to Corentin Wallez, blink-dev, Yoav Weiss, slightlyoff via Chromestatus, Rick Byers
    Can I ask what the release schedule is for the various WebGPU extensions as well? It's not currently clear to me which extensions are planned to be shipped with the first release of WebGPU and which are to be implemented later down the line.

    As of today's Canary 111.0.5534.0 on Windows 11 with a nVidia GeForce GTX 1070, I can see the following adapter features: indirect-first-instance, texture-compression-bc, depth32float-stencil8, rg11b10ufloat-renderable
    However the current spec's feature index lists 5 other extensions, notably including shader-f16 and timestamp-query. I'm particularly interested in the status of shader-f16, as our product allows for third-party shaders, and I want to avoid any backwards compatibility complications if it's introduced later down the line. But I'm also not clear if the OS/hardware combo is meant to support this too.

    As a WebGPU developer it would be useful to see official documentation somewhere of the individual development/shipping status for each WebGPU extension.

    Thanks for all the great work on WebGPU!


    On Wed, 11 Jan 2023 at 17:57, Corentin Wallez <cwa...@chromium.org> wrote:
    Thank you everyone for the LGTMs!

    We're super excited to get a high-quality WebGPU implementation in developer's hands! The list of issues we are tracking on the implementation side are these three (for the three parts that make WebGPU) and we expect to fix most issues before shipping, with clear rational of why the ones that aren't can be delayed. Of course we expect to find new issues as we keep expanding the test suite but will add them to the bug trackers I just linked for V1 tracking as well.

    On Wednesday, January 11, 2023 at 6:18:17 PM UTC+1 Yoav Weiss wrote:
    LGTM3

    On Wed, Jan 11, 2023 at 6:06 PM Rick Byers <rby...@chromium.org> wrote:
    We discussed in the API owner meeting and agree that we are impressed with all the work that's gone into interoperability here and the broad general support across implementers. We have high confidence that the team is setting an appropriately high quality bar both for shipping and for ongoing updates and interoperability improvements post-ship. So LGTM2 to ship whenever the team feels it's ready.

    This feature has been a long time in the making and I'm excited to see it launch ASAP, great work!

    Rick

    On Wed, Jan 11, 2023 at 11:52 AM slightlyoff via Chromestatus <admin+sl...@cr-status.appspotmail.com> wrote:
    An enthusiastic LGTM1 from me. Congrats on getting to this point; a big moment.

    --
    You received this message because you are subscribed to the Google Groups "blink-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

    --
    You received this message because you are subscribed to the Google Groups "blink-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

    --
    You received this message because you are subscribed to the Google Groups "blink-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
    To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7e739536-1bef-4bee-a44a-d2350ab79f3fn%40chromium.org.

    Corentin Wallez

    unread,
    Jan 12, 2023, 7:22:02 AM1/12/23
    to Ashley Gullen, blink-dev, Yoav Weiss, slightlyoff via Chromestatus, Rick Byers
    Hey Ashley,

    Happy to talk in more detail outside of the I2S thread. In general WebGPU optional features are optional as they can depend on hardware capabilities. The only guarantee is that around texture compression where the following must be true: BC || (ETC2 && ASTC). For shader-float16 for example, we are planning to have it implemented around the V1 timeframe, but it can't be universal as it depends on hardware capabilities and platform compiler support (which is the blocking part of your setup). For F16 one solution to bridge availability is to use type aliases: you can do `type maybe_f16 = f16;` or the same with f32 and use `maybe_f16` everywhere.

    Hopefully this helps, but in general after V1 we should have a clear roadmap to give visibility to the ecosystem.

    Cheers,

    Corentin

    Ashley Gullen

    unread,
    Jan 12, 2023, 10:55:26 AM1/12/23
    to Corentin Wallez, blink-dev, Yoav Weiss, slightlyoff via Chromestatus, Rick Byers
    OK thanks - it's just at the moment it's not clear if extensions aren't supported due to missing implementation (so it won't work anywhere), or an unsupported system (in which case I can potentially get it working and test my code if I find the right system setup). Extra visibility on that would be good.

    - Ashley

    Manuel Rego Casasnovas

    unread,
    Feb 6, 2023, 11:55:42 AM2/6/23
    to Corentin Wallez, blink-dev


    On 14/12/2022 18:02, Corentin Wallez wrote:
    > The WebGPU Conformance Test Suite is being built
    > at https://github.com/gpuweb/cts <https://github.com/gpuweb/cts> and can
    > be integrated as a subdirectory of WPT. Coverage is still incomplete due
    > to the complexity of the API but progressing quickly. We expect to ship
    > with coverage holes, but with most important and risky aspects of
    > interoperability well tested.

    Any plans about integrating the test suite into WPT?

    Thanks,
    Rego

    Corentin Wallez

    unread,
    Feb 7, 2023, 8:28:37 AM2/7/23
    to Manuel Rego Casasnovas, Kai Ninomiya, blink-dev
    Hey Rego,

    The WebGPU CTS is meant to be exportable into a WPT subdirectory, see https://github.com/gpuweb/cts/blob/main/docs/build.md. However I don't know that there's a specific plan to integrate into WPT proper since development uses a lot of combination testing and Typescript, which is not something WPT support (the export step creates individual HTML pages for each test case and compiles the Typescript to Javascript). +Kai Ninomiya, feel free to correct me if I missed something.

    Cheers,

    Corentin

    Kai Ninomiya

    unread,
    Feb 7, 2023, 11:24:27 PM2/7/23
    to Corentin Wallez, Manuel Rego Casasnovas, blink-dev
    There is no active plan to export or migrate the WebGPU CTS into WPT. It's something we'd theoretically like to do in the long run, but there are a lot of blockers:

    - If we just export without moving it, then browser-to-wpt auto-export will not be usable, so I would want to move it.
    - TypeScript meaningfully enables our test development and we would not want to strip it from the code, so we would want to somehow support that inside WPT. (We actually had an idea involving running babel in a service worker that could make this work now, but it's something we wouldn't want to do just for WebGPU.)
    - Each browser's wpt-to-browser auto-import will need to run the WebGPU tests on all hardware/software configurations used on that browser's CQ equivalent, and be able to collect the test results and update expectations files automatically. Without this, auto-imports will frequently be unable to import without breaking the build.
    - Chromium doesn't actually run most of the WebGPU CTS through WPT/web_tests anymore - only reftests still use web_tests. For numerous reasons, it was more practical to run under Chromium's GPU integration test framework. Other browsers are integrating the tests in whatever way is most practical for them (for example WebKit can't run it under their WPT runner using the WPT "variants" feature - they need it split up into files or somehow baked into the WPT manifest).
        - The test tree is very large and deep and test runtimes are highly variable, we needed a heartbeat mechanism for timeouts, which WPT does not have.
        - We needed expectations to depend on the GPU hardware and various configurations of Chromium's graphics and WebGPU stack, which we already had in that framework.
        - It uses the real browser instead of content_shell: tests what we ship, and we also had difficult-to-debug flakiness somehow relating to GPU initialization in content_shell.

    -Kai (he/they)

    Manuel Rego Casasnovas

    unread,
    Feb 8, 2023, 1:19:46 AM2/8/23
    to Kai Ninomiya, Corentin Wallez, blink-dev
    Thanks for the detailed explanation.

    Cheers,
    Rego
    > <https://source.chromium.org/chromium/chromium/src/+/main:third_party/dawn/webgpu-cts/expectations.txt> to depend on the GPU hardware and various configurations of Chromium's graphics and WebGPU stack, which we already had in that framework.
    >     - It uses the real browser instead of content_shell: tests what we
    > ship, and we also had difficult-to-debug flakiness somehow relating to
    > GPU initialization in content_shell.
    >
    > -Kai (he/they)
    >
    >
    > On Tue, Feb 7, 2023 at 5:28 AM Corentin Wallez <cwa...@chromium.org
    > <mailto:cwa...@chromium.org>> wrote:
    >
    > Hey Rego,
    >
    > The WebGPU CTS is meant to be exportable into a WPT subdirectory,
    > see https://github.com/gpuweb/cts/blob/main/docs/build.md
    > <https://github.com/gpuweb/cts/blob/main/docs/build.md>. However I
    > don't know that there's a specific plan to integrate into WPT proper
    > since development uses a lot of combination testing and Typescript,
    > which is not something WPT support (the export step creates
    > individual HTML pages for each test case and compiles the Typescript
    > to Javascript). +Kai Ninomiya <mailto:kai...@chromium.org>, feel
    > free to correct me if I missed something.
    >
    > Cheers,
    >
    > Corentin
    >
    > On Mon, Feb 6, 2023 at 5:55 PM Manuel Rego Casasnovas
    > <re...@igalia.com <mailto:re...@igalia.com>> wrote:
    >
    >
    >
    > On 14/12/2022 18:02, Corentin Wallez wrote:
    > > The WebGPU Conformance Test Suite is being built
    > > at https://github.com/gpuweb/cts
    > <https://github.com/gpuweb/cts> <https://github.com/gpuweb/cts
    > <https://github.com/gpuweb/cts>> and can
    > > be integrated as a subdirectory of WPT. Coverage is still
    > incomplete due
    > > to the complexity of the API but progressing quickly. We
    > expect to ship
    > > with coverage holes, but with most important and risky aspects of
    > > interoperability well tested.
    >
    > Any plans about integrating the test suite into WPT?
    >
    > Thanks,
    >   Rego
    >
    > --
    > You received this message because you are subscribed to the Google
    > Groups "blink-dev" group.
    > To unsubscribe from this group and stop receiving emails from it, send
    > an email to blink-dev+...@chromium.org
    > <mailto:blink-dev+...@chromium.org>.
    > To view this discussion on the web visit
    > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANxMeyD6G97bLgnCFRpqMCmkXhtkpkV9rP7wk2ByoiGgMznoSw%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANxMeyD6G97bLgnCFRpqMCmkXhtkpkV9rP7wk2ByoiGgMznoSw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
    Reply all
    Reply to author
    Forward
    0 new messages