Meeting minutes
Repository: webmachinelearning/webnn
Vivek: Joined this WG recently, PM on Chrome Web Platform team, worked on WebGPU, Skia, etc. compute shaders, Wasm
… super excited to support developer-created models inside the browser!
WebNN - WebIDL and Infra standard conventions
anssik: We'll review the open PRs to prep for an upcoming stylistic update that will follow.
The computeSync and computeAsync algorithms
anssik: issue #316 and PR #329
<ghurlbot> Issue 316 Review sync vs async compute differences (zolkis) Editorial
<ghurlbot> Pull Request 329 Rework the sync async algorithms based on PR 323 (zolkis)
anssik: ready to merge once we receive Chai's review
… reviewed by Ningxin, Jiewei, Anssi
Zoltan: this PR factors out common parts to sync and async parts, purely editorial, Ningxin checked for correctness
The batchNormalization algorithm
anssik: issue #334 and PR #339
<ghurlbot> Issue 334 Improve batchNorm (zolkis) Editorial
<ghurlbot> Pull Request 339 Fix #334: Improve the batch norm algorithm (zolkis)
anssik: re-review requested from Ningxin and Chai.
… Changes in this PR:
… - add missing prose for MLBatchNormalizationOptions members: scale, bias, axis, epsilon, acivation
… - editorial tweaks in Arguments section
… - add The batchNormalization() method steps
Zoltan: this PR is an example on how to factor out options and dictionary, ground rules for every PR from now on, feedback to have only this change, I rewrote this section initially, but then reverted to the original wording and add just the delta and defer other changes to other PRs
… all this has been done
<ningxin_hu> received the notice, will review
anssik: thanks!
The clamp algorithm
anssik: issue #347 and PR #348
<ghurlbot> Issue 347 Add the clamp() algorithm (zolkis) Editorial
<ghurlbot> Pull Request 348 Add the clamp() algorithm (zolkis)
anssik: review requested from Ningxin and Chai
… 1 change was requested by Chai to remove "This step does not execute the clamp operation yet..." note
… addressed by Zoltan by removing the note
… Changes in this PR:
… - Add "check clamp options" steps
… - Minor editorial tweaks in Arguments section
… - Add The clamp() method steps
Zoltan: polymorphic function, along with constant() and input(), the first PR that got tagged by Dom on how to do polymorphic
… folks to look the steps they look good, I checked the implementation for this and hope all is good
… ready for merging
ningxin_hu: question about the algorithm used by this PR, it looks like all deps not included in this PR? Copy operand and create MLOperand steps but I cannot see these defined in this PR.
Zoltan: if you see any missing algoritms you'll find them in PR #337 that is marked as draft, it includes all the dependencies
<ghurlbot> Pull Request 337 Add internal slots to MLOperand and MLActivation (zolkis)
Zoltan: I'll add any missing dependencies to that PR
The concat algorithm
anssik: meta issue #210 and PR #366
<ghurlbot> Pull Request 366 Add the concat algorithm (zolkis)
<ghurlbot> Issue 210 Use modern WebIDL and Infra standard conventions (anssiko) enhancement, Editorial
anssik: 1 change requested by Chai to adjust the note in one of the concat() substeps
… updated the note per Chai's suggestion to the following:
… "If the shape of each corresponding dimension and type of the operands, except for those of the dimension given by axis, is not the same, fail."
… final review requested from Chai and Ningxin for the PR that addresses all feedback
Zoltan: I will re-check the dependencies after the meeting and will add them here if something is missing
anssik: the stylistic PR would be up for review after these 4 PRs have been merged
Zoltan: correct, we'll then have collapsible algorithms, some other visual cues
<ningxin_hu> I'll review the three PRs in the following days
anssik: thanks!
New features
Float16Array
anssik: issue #373 and PR #386
<ghurlbot> Issue 373 heads up re: proposal to add Float16Array to JavaScript (bakkot) v2
<ghurlbot> Pull Request 386 Add float16 to MLOperandType and ArrayBufferView compatibility table (anssiko)
anssik: summary: Float16Array design finished, ready to integrate into WebNN
… ECMA folks let us know that the proposal to add Float16Array to JavaScript reached stage 3, meaning the design is finished, the committee is in favor, and engines can start implementing and shipping it.
… I updated PR #386 to align with this new reality that allows us to add this type as a normative reference to the WebNN spec proper
… concretely we're adding a new line to the MLOperandType and ArrayBufferView compatibility table:
… MLOperandType float16
… ArrayBufferView Float16Array
… also added is the following note that documents the current status of Float16Array, its emulation path via Uint16Array and links to issue #373 that says:
… "Float16Array is at ECMA Stage 3 signalling its design is finished. Implementers wanting to enable this type ahead native implementations can emulate the type by passing raw bits via Uint16Array. [Issue webnn#373]"
<ghurlbot> Issue 373 heads up re: proposal to add Float16Array to JavaScript (bakkot) v2
RafaelCintron: I think it is great that we have Float16Array, I'd like to point it takes some time it will get into implementations proper
anssik: do you support the addition of this into WebNN API spec?
RafaelCintron: yes, full support
… this small PR is ready for review by Chai and Ningxin, anyone else
… this received thumbs up support from Dwayne and ECMA folks were excited to hear WebNN is an early adopter of Float16Array
0D scalars
anssik: issue #390 opened by Dwayne (thanks!)
<ghurlbot> Issue 390 0D scalars (fdwr)
anssik: zero-dimension scalars
… Per Dwayne this arose during prototyping additional models and during Chromium code review and ORT review
… please check the issue, the issue is well described in there
… the proposed fix is a small one, delete the following line in https://
… "2. If dimensions.length is 0, return false."
ningxin_hu: this is a good one, I have two open questions
… today we have way to define the scalar: MLOperand for dimensions, if not present, descriptor represents scalar
… zero-dimension would be a better way, this change the optional dimensions field of this MLOperand
Zoltan: makes sense
ningxin_hu: second open question related to XNNPACK implementability
… I'm working on XNNPACK impl in Chromium so can work with Jiawei to take this investigation
anssik: thanks!
<ningxin_hu> will provide inputs in the issue
Enhancements, editorials, questions
Error handling of MLNamedArrayBufferViews transfer algorithm
anssik: issue #351
<ghurlbot> Issue 351 Need to define error handling of MLNamedArrayBufferViews transfer algorithm (huningxin)
anssik: we discussed this issue on our last meeting and since then Domenic reviewed the proposal and confirmed the proposed solution should work
… as part of the solution we'd need an algorithm to "check if an ArrayBuffer is detachable"
… this could be upstreamed to Web IDL spec, Domenic was welcoming such contribution
ningxin_hu: thanks Rafael for proposing this issue!
… we can implement this either in WebNN or upstream WebIDL spec
… ideally we'd upstream this to WebIDL
… I'd be happy if someone who is familiar with WebIDL spec to do that
anssik: any opens regarding the design?
ningxin_hu: no other comments
Remove the support of null value in newShape parameter of reshape build method
anssik: issue #388
<ghurlbot> Issue 388 Remove the support of `null` value in `newShape` parameter of `reshape` build method (huningxin)
anssik: Ningxin explains: "WebNN reshape op build method currently supports a special null value in newShape array that instructs the implementation to compute the size of the dimension with the value null so that the total size remains constant."
… Dwayne's proposal: "WebNN should only support the concrete values in newShape because this can be easily handled by framework through shape inference."
… LGTM from Jiewei and Dwayne
anssik: we have a solution, right?
ningxin_hu: this is great feedback from implementers! thanks!
… editor's view is this is good
… in WebNN graph all shapes are static and can be inferred when compiled
… this is a little helped for the developer, OTOH this calculation can be easily done by the developer
… this makes this little helped in impl less valuable, Jiawei thinks this calculation is less valuable for the developer and from implementer's perspective increases the complexity yet is not so commonly used
… so makes sense to remove support for this, make WebNN new shape concrete and static
… another perspective is if we look at WebNN progress, conventions for axis etc. can be more concrete, also reduces complexity of implementation
… if we make this change we can bring more consistency to the spec
… I support this direction
Support for transformers
anssik: issue #375
<ghurlbot> Issue 375 Support for transformers (dontcallmedom) v2
anssik: continuing our discussion on support for transformers initiated by W3C AC review comment
… we've received fantastic feedback from Joshua who created Transformers.js (thanks!)
webmachinelearning/
anssik: I had a discussion with Joshua and he will join our next call on 8th of June to contribute his insights to inform this WebNN v2 features discussion
… on our next meeting I expect Joshua to talks about Transformers.js supported tasks, planned future tasks, discuss limitations and learnings, use cases that motivated the creation of Transformers.js
… I'm confident that with this feedback we are well informed to recognize transformers in the WebNN use cases to fulfill the original request in this issue #375 and initiate the concrete spec work to bridge the gap in this regard, in op support
… I'm also aware of other related work such as the Dwayne's prototyping to get Stable Diffusion running on a Chromium WebNN implementation
… I expect this effort to similarly inform what additional ops we should consider adding to WebNN v2
… SegmentAnything from Meta with its first featurization transformer block may also provide relevant insights to inform our WebNN v2 feature work
anssik: is Stable Diffusion, SegmentAnything, Transformers.js/HuggingFace's a good start for this investigation?
<ningxin_hu> this list is a good start
Rafael: this is great, we should definitely consider them!
Vivek: re timezones, this timeslot works well for me I'm on the East Coast