LGTM to continue experimenting till M105 (inclusive) but no further.

On Wed, Mar 23, 2022 at 12:57 PM Corentin Wallez <[email protected]>
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.


>
> 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 <[email protected]> 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 [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 bug
>>> https://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/CAL5BFfVef%2BhoxRPmPgq8uKCAbxeiocAg_SDydL7MNmzKEprs_A%40mail.gmail.com.

Reply via email to