-Kai (he/they)
On Wed, Dec 21, 2022 at 10:34 AM Rick Byers <[email protected]> wrote: > On Wed, Dec 21, 2022 at 12:10 PM Corentin Wallez <[email protected]> > 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 <[email protected]> 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 <[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 bug >>>> https://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/CANxMeyAEHUuVERSwMN1_FnpgH3a%3Dqz6LodA90QXEH0hO3sEWEQ%40mail.gmail.com.
