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 [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 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/19d73cc6-cacf-47ce-b317-a50c812af7ebn%40chromium.org.
