Meeting minutes
ghurlbot, this is webmachinelearning/webnn
<ghurlbot> anssik, OK
Announcements
webnn-polyfill npm package published
anssik: webnn-polyfill published as an npm package:
https://
… thank you to all the polyfill contributors!
<ghurlbot> @webmachinelearning
WebNN API Candidate Recommendation open issues
Web platform tests
anssik: I want to discuss & resolve any blockers for w-p-t & webnn-baseline reference impl.
… webnn-baseline is the pure JS double-precision baseline implementation of WebNN operations for testing purpose without 3rd party deps
anssik: webnn-baseline remaining implementation work is documented in:
webnn-baseline implementation open issues
Implement softsign
Implement softplus
Implement resample2d
Implement others reduction operations
Implement l2Pool2d
Implement pad
Implement linear
Implement instanceNormalization
Implement hardSwish
Implement hardSigmoid
Implement convTranspose2d
New feature: Support float16
anssik: next, let's discuss the status of the wpt open PRs
wpt open PRs
… I bucketed the wpt PRs into:
… 1) Ready to merge?
… 2) Ready to close?
… 3) Review comments to be addressed
… 4) Pending reviewers
… let's look at each of these buckets. Bruce, et al. please correct me needed.
… 1) Ready to merge?
[wpt] concat tests
… 36782 is reviewer approved but fails auto merge due to wpt-chrome-dev-stability failure (sink-task is a check that reports a failure if any of the taskcluster checks fails)
… is this due to the WebNN API being under a build-time flag in Chromium?
<bruce_dai> https://
Bruce: #36782 blocked by #36908
<ghurlbot> Issue 36782 [not found]
<ghurlbot> Issue 36908 [not found]
anssik: I could ping Dom to accelerate the merge of this PR
Bruce: that'd be good
… 2) Ready to close?
[wpt] polyfill as an idlharness.js dep
anssik: 31771 proposed to add the webnn-polyfill as an idlharness.js dep, but per review comments injecting scripts into idlharness.js is not allowed
anssik: can we close this PR #31771?
<ghurlbot> Issue 31771 [not found]
Bruce: can close this
anssik: ... 33857 is superceded by now merged https://
anssik: can we close #33857?
<ghurlbot> Issue 33857 [not found]
Bruce: #33857 can be closed
… 3) Review comments to be addressed
[wpt] first-wave ops tests (part 1)
anssik: comments from Dwayne to be addressed prior to merging
Bruce: this big PR can be closed, now separated in multiple smaller PRs
… #34287 can be closed
anssik: looks like very fresh PR that is being worked on
anssik: 4) Pending reviewers:
<ghurlbot> Issue 34287 [not found]
Bruce: submitted this IDL manually, this naming PR is OK
[wpt] first-wave ops tests (part 2)
Bruce: #36202 is separated into smaller PRs, can be closed
<ghurlbot> Issue 36202 [not found]
Bruce: Dwayne, Wanming and Ningxin are reviewing these PRs, concat actively being reviewed now
anssik: thank Bruce and Dwayne, others for your work on wpt! Contributions from everyone is welcome even informal reviews for the above-mentioned PRs to get them into a merge-able state.
… We have a good testing story developing here for CR publication purposes
… I'm confident we will be able to satisfy the "must document how adequate implementation experience will be demonstrated" CR requirement even if some of these wpt tests would be still be in review while we transition to CR.
Use modern WebIDL conventions
anssik: to satisfy the CR readiness requirements, the WebNN API spec is expected to specify its normative parts using the modern authoring conventions. This convention is codified in the WebIDL spec.
… Zoltan has volunteered to make editorial adjustments to the specification. I have discussed this work with Zoltan and we agreed to focus on editorial changes and minimize any normative changes unless they are needed to fix a spec bug, or to clarify an aspect where the spec and implementation disagree.
… Zoltan, please feel free to introduce the editorial changes in PR #301
<ghurlbot> Pull Request 301 WiP: editorials (zolkis)
Zoltan: pushed a few editorial changes after discussion
… in this PR #301 it is mainly trivial changes
… changed the section titles to include interface/method/dictionary etc.
… improved the ML.createContext() steps using prose also used in other spec's.
… discussion on preferred "in parallel" usage in the PR
… removed the unused internal slot [[implementation]]
… we should see if we need internal slot for ML context, or we can also refer to it in prose
… added first stab at MLGraphBuilder constructor steps
… should we validate context given to the builder?
… a workaround would be to move builder to context.
… can create separate issues for these
ningxin_hu: question, this PR has WiP title, are you still working on it, is it ready for review?
Zoltan: ready to review
Zoltan: prefer smaller atomic PRs
ningxin_hu: I briefly reviewed the 3 commits in the PR, we can separate trivial ones to separate PR to accelerate
… in Chromium we use big PR to show the overall direction or arch change, get early feedback and then once solidified we separate that for smaller pieces for landing
… this PR #301 is a collection of multiple editorial changes
<ghurlbot> Pull Request 301 WiP: editorials (zolkis)
Zoltan: if you make comments in that PR I will refine the PR with feedback
ningxin_hu: prefer smaller self-contained PRs e.g. proposing to separate the promise usage to a separate PR
Zoltan: I'll work on the editorial change in between the calls and will share with editors PRs for review offline
Zoltan: welcome comments on proposals in #298
<ghurlbot> Issue 298 API review, questions, brainstorming (zolkis)
Zoltan: specifically: Proposal for exposing context
… and proposal to include graph builder, command encoder as attributes to MLContext, and make MLGraph an internal slot of MLContext
… two of the most recent proposals
anssik: it'd be good if these proposal would be positioned as v2 / post-CR to not de-stabilize the ongoing implementation and interop testing efforts during our last mile sprint to CR readiness
<zkis> Proposal 1: https://
<zkis> Proposal 2: https://
ningxin_hu: thanks for this brainstorming happy to discuss
… as Anssi said, regarding CR target, I also prefer to these be positioned v2 / post-CR and focus on CR blockers
… another comment regarding implementation, with this implementation we have Dev Trial available in browser and can gather developer feedback and be in a better position on what changes are benefiting the API customers
… with implementation experience and developer feedback we are in a better position
https://
WebML WG Charter 2023-2025 under development
anssik: Web Machine Learning Working Group Charter for 2023-2025 is now under development.
anssik: we expect to have a good draft charter ready EOY 2022
… - Q4 '22: Charter development
… - Q1 '23: W3C Advisory Committee review
… - Q2' 23: Charter approved
[new] OpenXLA coordination
anssik: on our last call Google's Eugene Burmako presented on StableHLO that is a portable ML compute operation set being worked on as part of OpenXLA project. We heard StableHLO is being adopted by Google products and projects
–> WebML WG Teleconference – 17 November 2022 https://
anssik: it was discussed we should consider revising the op set compatibility exploration we did earlier in this group
WebNN op compatibility exploration
anssik: this initial WebNN op compatibility exploration looked at lowering to XLA-HLO in 2020.
… it was suggested we should coordinate with the OpenXLA project to ensure any synergies can be unlocked between WebNN and StableHLO op sets
… a proposal was to add StableHLO into the compat study. We heard from Eugene that StableHLO targets feature completeness EOY 2022 and thus a good start for this effort would be ~Q1-Q2'23.
… External Coordination section of the charter is the place where to note related work in the ecosystem where coordination is expected
… the current charter notes Khronos and ECMA TC39 in this section
External Coordination (from current charter)
anssik: here's my proposed addition to the External Coordination of the charter:
OpenXLA Project develops StableHLO, a portable ML compute operation set that makes frameworks easier to deploy across different hardware. WebNN API targets diverse hardware platforms and defines an operation set whose high-level operations can be decomposed to low level primitives that can map to StableHLO operations. Coordination and alignment between these two operation sets is beneficial to the open ML ecosystem.
anssik: feedback welcome via the GH issue
proposed RESOLUTION: Add OpenXLA Project to External Coordination
<ningxin_hu_> +1
anssik: any objections or concerns?
<ningxin_hu_> PR sgtm
RESOLUTION: Add OpenXLA Project to External Coordination
anssik: I will craft a PR to document the proposal and seek review from the WG
/github.com/w3c/machine-learning-charter/issues/27///github.com/w3c/machine-learning-charter/issues/27
[new] On-device training
anssik: currently, on-device training is out of scope:
"Training capabilities are out of scope due to limited availability of respective platform APIs."
anssik: Please provide feedback if you think on-device training should be in scope for 2023-2025.