Meeting minutes
WebNN API explainer
Update the webnn explainer docs (PR #109)
Chai: Considered alternatives still missing content
anssik: perhaps mention Model Loader and MLIR-inspired proposals
Chai: those are actually already discussed in other sections
… we haven't had any U-turns on the API design
… I can do some cleanup and fill the acknowledgements sections
anssik: "One of the most important things you can do in your design process is to catalog the set of roads not taken. As you iterate on your design, you may find that major choices in your approach or API style will be revisited and enumerating the full space of alternatives can help you apply one (or more) of them later, may serve as a “graveyard” for u-turns in your design, and can give reviewers and potential users
confidence that you’ve got your ducks in a row."
Rafael: Maybe we could delete this section
… only alternative we could ask here is Model Loader, or why don't we just use WebGL/GPU
… refer to sections providing answers to those question
ningxin_hu: as discussed before, agree perf and efficiency are to be highlighted in here
anssik: after completing the considered alternatives and ack section, Anssi to initiate TAG review
Support the execution of the sub-graph scenario
Support the execution of the sub-graph scenario (issue #105)
ningxin_hu: this should be covered in the PR #94
… also related issue #105
Ping's comment: "With this API, the computation is tied with the compilation. should the compile method have the inputs/outputs pair and execution can only execution the graph compiled with the input/output pair? Otherwise, the compilation might not support the execution of the sub-graph scenario?"
Chai: two ways to do this, described in a PR:
https://
anssik: what is Ping's reaction to the proposal?
Chai: no comments yet
ningxin_hu: Ping would need to elaborate the use case to understand the gap better
Proposed new ops Mirrorpad, SquaredDifference, Pow, TransposeConv
anssik: Please review the issue and provide feedback
WebNN API is not support Mirrorpad, SquaredDifference, Pow, TransposeConv (issue #108)
Chai: this issue is about how do we know what models we need to support?
… we should look at the models people want, this is one such a request
… I'm open to brainstorming what models we should look at and map into the spec
… personally I don't prefer expanding the first wave models, but we need a way to accept extensions
… we could have a separate repo e.g. "models" under "webmachinelearning" GH org
<Chai> examples: ONNX model zoo https://
<Chai> TensorFlow model garden: https://
anssik: What type of questions we should ask from folks proposing new ops to be added?
Chai: Style Transfer is pretty known model and supported in e.g. ONNX Model Zoo, so I think the model we might not support are those that are used in classical ML for example
… any Deep Neural Network would be good to look into supporting
… nothing wrong in Style Transfer
anssik: can you respond to Calvin maybe providing platform support information?
ningxin_hu: can do that, also cross-check between ONNX and XLA-HLO
… re model criteria, maybe ask folks to look at the use cases in the WebNN spec, if the use case is not included need to start from there
https://
ningxin_hu: linking models to use cases could be the precondition
anssik: style transfer indeed one of the use cases
<Chai> + 1 on ningxin's
anssik: you can implement only a subset of the use cases with the first-wave ops?
Secure Context
anssik: proposal to expose WebNN API only over HTTPS.
Added extended attributes to Web IDL definition (PR #101)
anssik: ningxin can you work with Wonsuk to address the PR conflicts?
ningxin_hu: conflicts due to changes in deployment infra, will work with Wonsuk on this
WebNN API ergonomics improvements
Chained API for the Operands
Chained API for the Operands (issue #106)
anssik: Ping's proposal
anssik: parking this for later to have sync discussion with Ping
Options dictionary for functions with lots of args
anssik: this issue #90 was fixed with PR #112, anything to report?
… thanks Zoltan for the proposal, and Chai for the PR
Suggestion: use an options dictionary for functions with lots of args (issues #90)
Use optional dictionaries for operator's optional parameters (PR #112)
Chai: great suggestion, helped with versioning
ningxin_hu: want to mention re Chai's update to add the dict-based options, I'm working to update the webnn-polyfill to match
<ningxin_hu> https://
<ningxin_hu> https://