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 <https://bugs.chromium.org/p/chromium/issues/list?q=label:Proj-WebGPU-Milestone-V1> 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 On Wed, Dec 28, 2022 at 5:23 PM Kai Ninomiya <kain...@chromium.org> wrote: > > -Kai (he/they) > > > On Wed, Dec 21, 2022 at 10:34 AM Rick Byers <rby...@chromium.org> wrote: > >> On Wed, Dec 21, 2022 at 12:10 PM Corentin Wallez <cwal...@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 <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. >>> >> >> Great, that's nice and simple. Thanks. >> >>> >>>> - 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). >>> >> >> 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 <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? >>> >> >> 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 >>> <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. >>> >> >> 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 >> <https://bugs.chromium.org/p/chromium/issues/list?q=label: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? >> > > Yes, that's correct, plus the Milestone-V1 issues in the Dawn issue > tracker: > https://bugs.chromium.org/p/dawn/issues/list?q=Milestone%3DV1&can=2 > > >> 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 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 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/CAFUtAY-Q%3DdNE8Hu0rpUMnc8SBRMEhb5HJNww12LquamGtKh7aw%40mail.gmail.com.
