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 <https://gpuweb.github.io/gpuweb/explainer/#issue-829f95ec> 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 <https://github.com/gpuweb/gpuweb/issues?page=1&q=is%3Aissue+is%3Aopen> 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 <https://github.com/gpuweb/gpuweb/issues?q=is%3Aopen+is%3Aissue+-label%3Aeditorial+-label%3A%22feature+request%22> (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 On Wed, Dec 14, 2022 at 12:02 PM Corentin Wallez <[email protected]> wrote: > 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 [email protected], [email protected], > [email protected] > > Explainerhttps://gpuweb.github.io/gpuweb/explainer > > Specificationhttps://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 componentBlink>WebGPU > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebGPU> > > Search tagsgpu <https://chromestatus.com/features#tags:gpu>, webgl > <https://chromestatus.com/features#tags:webgl> > > TAG reviewhttps://github.com/w3ctag/design-reviews/issues/626 > > TAG review statusIssues 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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ?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 bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1156646 > > Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1156661 > > Sample links > https://github.com/austinEng/webgpu-samples > > Estimated milestones > OriginTrial desktop last 109 > OriginTrial desktop first 94 > > 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 discussionsIntent 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 > > -- > 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 [email protected]. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGdfWNOERFV9DFZERpsP2T75g%3DF%2BwFquV1Oxdiea%2BvP4kKg4cw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY96sBC6zhiYfcq2gBBy0iFmAiCCpGVSkZjQMTm%3D-0hS%3DA%40mail.gmail.com.
