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 > <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"? > > 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 <https://gpuweb.github.io/gpuweb/> and WGSL <https://gpuweb.github.io/gpuweb/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 <https://github.com/gpuweb/gpuweb/issues/3703> to fix up the explainer. > > - 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). > > 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" <https://github.com/gpuweb/gpuweb/issues?q=is%3Aopen+is%3Aissue+milestone%3AV1.0> 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 <https://github.com/gpuweb/gpuweb/issues?q=is%3Aopen+is%3Aissue+milestone%3AV1.0+-label%3Aeditorial+-label%3Ameta>, 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 <http://third_party/dawn/webgpu-cts/expectations.txt>. 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 <https://github.com/linebender/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 <https://source.chromium.org/chromium/chromium/src/+/main:infra/config/generated/luci/commit-queue.cfg;l=1334?q=dawn-linux-x64-deps-rel%20&start=11#:~:text=1333-,1334,-1335> 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 <https://dawn-review.googlesource.com/c/dawn/+/113141>). If updates to the CTS cause failures we will notice them in the "untriaged failures" bucket and fix them. Thanks, > Rick > > > On Wed, Dec 14, 2022 at 12:02 PM Corentin Wallez <cwal...@chromium.org> > 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 emailscwal...@chromium.org, bclay...@google.com, >> kain...@chromium.org >> >> 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 blink-dev+unsubscr...@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 >> <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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGdfWNN33B_gSEy7tdEsz_Yrp1BvByiC9yPyRF-jNjA_23gg5w%40mail.gmail.com.
