Hey Yoav, The W3C group is looking to finish a first version of the spec ASAP and while standardization always has a bunch of unknowns, we want to get to a stable spec in months, not quarters. So for Chromium our hope was that we could keep the OT going until shipping, with maybe a pause of one release in the middle. Burn-in is always a risk but fairly minimal for WebGPU because all browsers are implementing and horizontal reviews seem to have little comments that would change the shape of the API drastically. (so we're not in a situation like when WebVR turned into WebXR). We've also been doing rolling deprecations during the OT and developers all upgraded in a timely fashion.
Of course we might be biased in evaluating the risk of burn-in but it seems minimal, so extending OTs for 12 milestones (or even longer) doesn't look scary. Happy to discuss more obviously :) Re: WebGPU WPT in Firefox and WebKit, short answer is that they aren't running the tests yet, but looking to. - WebKit started implementing WebGPU again <https://github.com/WebKit/WebKit/commits/main/Source/WebGPU> actively a couple weeks ago and assured they wanted the vast majority of their tests to be the WPT ones we develop (and that they are going to contribute to if they find holes). They asked for pointers on how to run the WebGPU CTS through WPT so they must be looking at doing that. - I thought Firefox ran WebGPU WPT on CI but it seems it later got disabled. Kelsey Gilbert confirmed it: "Not as part of Firefox CI yet, but yes we are working on it". wgpu <https://github.com/gfx-rs/wgpu> the library used to implement WebGPU in Firefox, is running the tests through Deno <https://deno.land/>, which provides coverage of most of the code. (from our experience in Chromium). I don't know the pass rate of wgpu though. Cheers, Corentin On Wed, Mar 23, 2022 at 6:06 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > Thanks for tackling this large , important and complex capability! :) > > As this extension will bring the OT to 12 milestones, which is the typical > limit of time we let OTs run (to reduce burn-in risk), I'd love to better > understand the higher level plan. > Are you planning for this to be the last OT extension, and planning to > ship around M105? Are you planning to pause the OT at some point, to reduce > the burn-in risk? Something else? > > On Monday, March 21, 2022 at 2:43:54 PM UTC+1 Corentin Wallez wrote: > >> The origin trial for WebGPU was started in M94 and was later extended to >> end in M101. We are asking to extend for 4 additional releases to M105 so >> that we can address previous feedback from developers and gather additional >> ones. >> >> Particularly important pieces of feedback that we are currently >> investigating are: >> >> - The performance of WebGPU-based video processing on the Web, which >> after extensive efforts by partners is getting to a benchmarkable state >> (so >> we can understand the performance of the API and correct if need be). >> - Missing functionality and its impact on large projects targeting >> WebGPU via emscripten (for example we got multiple important pieces of >> feedback from Unity with likely more coming) >> - The expressed need to have synchronous readbacks from the GPU being >> available in WebGPU (something that you can do in WebGL and that at least >> half a dozen developers requested be added to WebGPU). >> - How the recently agreed upon direction for exposing GPU identifiers >> in WebGPU will work for developers (since it is more limited than >> available >> in WebGL for privacy considerations). >> >> >> Contact emailscwal...@chromium.org, bclay...@chromium.org, >> 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 will provide 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. >> >> >> WebGPU is a large and complex API. Developers take time to port existing >> applications to it and surface feedback on functionality / performance, and >> TAG review is still ongoing due to the complexity of the API. We are >> starting to gather feedback from developers and get additional ones. >> Particularly >> important pieces of feedback that we are currently investigating are: >> >> - The performance of WebGPU-based video processing on the Web, which >> after extensive efforts by partners is getting to a benchmarkable state >> (so >> we can understand the performance of the API and correct if need be). >> - Missing functionality and its impact on large projects targeting >> WebGPU via emscripten (for example we got multiple important pieces of >> feedback from Unity with likely more coming) >> - The expressed need to have synchronous readbacks from the GPU being >> available in WebGPU (something that you can do in WebGL and that at least >> half a dozen developers requested be added to WebGPU). >> - How the recently agreed upon direction for exposing GPU identifiers >> in WebGPU will work for developers (since it is more limited than >> available >> in WebGL for privacy considerations). >> >> We are asking to extend the Origin Trial to keep getting feedback from >> developers during their prototyping and also when they are testing with >> users in the wild. (identifier information for example is only useful in >> the latter case). >> >> 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 statusStill ongoing (after 11 months and regular reminders). >> >> Risks >> >> >> Interoperability and Compatibility >> >> With positive signals (and at least WIP implementations) from all >> browsers, the biggest interoperability risk is the surface of the API which >> is quite large. >> >> Gecko: In development ( >> https://hg.mozilla.org/mozilla-central/file/tip/dom/webgpu) >> >> WebKit: In development ( >> https://github.com/WebKit/WebKit/tree/main/Source/WebGPU/WebGPU) >> >> 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). >> >> Activation >> >> WebGPU is not polyfillable on existing APIs and requires hardware support >> on the system. (software fallback is not enabled by default yet). >> >> >> Security >> >> See detailed security explainer: >> https://gpuweb.github.io/gpuweb/#malicious-use >> >> >> Goals for experimentation >> >> Allow developers to use WebGPU and provide feedback on the API or the >> shading language. We expect feedback about ergonomics, ease of use and ease >> of porting existing content to WebGPU, and missing features. As well as >> many bug reports :) Also help partners evaluate the performance of WebGPU >> in the wild to figure out areas of the implementation to optimize before >> launch. >> >> >> Reason this experiment is being extended >> >> WebGPU is a large and complex API. Developers take time to port existing >> applications to it and surface feedback on functionality / performance, and >> TAG review is still ongoing due to the complexity of the API. We are >> starting to gather feedback from developers and get additional ones. >> Particularly >> important pieces of feedback that we are currently investigating are: >> >> - The performance of WebGPU-based video processing on the Web, which >> after extensive efforts by partners is getting to a benchmarkable state >> (so >> we can understand the performance of the API and correct if need be). >> - Missing functionality and its impact on large projects targeting >> WebGPU via emscripten (for example we got multiple important pieces of >> feedback from Unity with likely more coming) >> - The expressed need to have synchronous readbacks from the GPU being >> available in WebGPU (something that you can do in WebGL and that at least >> half a dozen developers requested be added to WebGPU). >> - How the recently agreed upon direction for exposing GPU identifiers >> in WebGPU will work for developers (since it is more limited than >> available >> in WebGL for privacy considerations). >> >> We are asking to extend the Origin Trial to keep getting feedback from >> developers during their prototyping and also when they are testing with >> users in the wild. (identifier information for example is only useful in >> the latter case). >> >> >> >> Ongoing technical constraints >> >> None >> >> >> Debuggability >> >> Warnings and errors are exposed via dev tools. Specialized tools for >> debugging are TBD. >> >> >> 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 in Origin Trial on: - Android because >> adding Android support is a lot of engineering that we're scheduling to >> happen between the Origin Trial and the shipment of WebGPU. - 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. - Other devices >> that don't support D3D12/Metal/Vulkan or don't have a GPU with good enough >> minimum specifications.(maybe) - ARM devices if we don't find time to test >> on ARM platforms before the Origin Trial starts. 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. >> >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >> ?Yes >> > > Are the Firefox and Safari implementations passing the WPTs? That could be > reassuring from an interop perspective. > > >> >> 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 >> >> Estimated milestones >> OriginTrial desktop last 101 >> OriginTrial desktop first 94 >> >> 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/#!msg/blink-dev/dxqWTSvyhDg/1UDaFD17AQAJ >> Intent to Experiment: >> https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/K4_egTNAvTs >> Intent to Extend: >> https://groups.google.com/a/chromium.org/g/blink-dev/c/l-QcZ7qOcUQ >> > -- 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/CAGdfWNMQJKKRtwnLFverpMXrg2eqvW2qj265cLiBw0yVW0nUPA%40mail.gmail.com.
