I know this is quite late, but is WebGPU still due to be implemented after Build 109? (So 110 and above?) On Wednesday 23 March 2022 at 12:22:56 UTC cwa...@chromium.org wrote:
> On Wed, Mar 23, 2022 at 1:13 PM Yoav Weiss <yoav...@chromium.org> wrote: > >> LGTM to continue experimenting till M105 (inclusive) but no further. >> >> Thank you! > > >> On Wed, Mar 23, 2022 at 12:57 PM Corentin Wallez <cwa...@chromium.org> >> wrote: >> >>> 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 :) >>> >> >> Extension beyond the 12 milestone mark would require 3 LGTMs and >> significant analysis of the risks involved. Pausing the OT for a release >> would go a long way towards reducing the risks, so it might be worthwhile >> for y'all to consider. >> >> > Sounds good, I really hope by then we'll be ready for launch, with the > potential gap of one release. We need to figure out the implications but > it's likely we can do a pause. > > >> >>> 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. >>> >>> >> Thanks! May be interesting (but not blocking) to run those WPTs manually >> and see if they pass. Or we could wait for them to integrate them into >> their CI :) >> >> >>> Cheers, >>> >>> Corentin >>> >>> On Wed, Mar 23, 2022 at 6:06 AM Yoav Weiss <yoav...@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 emailscwa...@chromium.org, bcla...@chromium.org, >>>>> kai...@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 bug >>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1156646 >>>>> >>>>> Launch bug >>>>> https://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/0e7ec6d4-766f-4d87-9d30-4f94f2fdbbfdn%40chromium.org.
