Meeting minutes
ghurlbot, this is webmachinelearning/webnn
<ghurlbot> anssik, OK
Announcements
anssik: the 1st WebNN API Chromium patch landed!
… congrats to everyone who helped get through the review process
… collaboration across several companies working together
<Geun-Hyung> congratulation!
<ningxin_hu_> https://
ningxin_hu: the patch was submitted by Junwei
… we had started the intent to prototype process together with Rafael and Chai
… This is the first patch with Blink-side IDL definition with MLGraphBuilder
… it's the very minimal initial set to try the blink interfaces
… it's aligned with what Honglin has done for the Model Loader API
… they're making good progress in the ChromeOS team
… we've discussed aligning interfaces, e.g. the MLContext interface would be shared between the two APIs
… Thanks to Honglin for his review and others like Jonathan for their help to go through this
… Junwei sent a second patch that adds more methods of the MLGraphBuilder
… targeting the 1st wave ops identified in the spec
… we'll be adding more, and figure out the next steps of implementations e.g. integration with the native backends
… as explored in webnn-native
webnn-native open-source project
ningxin_hu: we'll need to figure out which backends can be brought to Chromium
… we hope to bring webnn and make it available for testing soon
<dom> Congrats to everyone involved indeed!
WebNN API Candidate Recommendation - release vs. post-release scope
anssi: we're marching towards the CR spec milestone
… to get there, we need to figure out the technical scope of the spec
… please look at the current issues for the spec and triage them for release (things to fix by CR), and post-release (things to address after CR)
anssi: CR indicates a spec is considered complete and fit for purpose
<ningxin_hu_> the 2nd CL, feel free to help review: https://
anssi: no further text changes are expected beyond implementation feedback and testing, a spec that can be meaningfully implemented as is
… please note issues that you think need to be tracked for our CR milestone
… we're committed to hit during this year
chai: do we believe the list of issues is complete? does it need a full review?
anssik: it's not finalized, it's our current best understanding
… there may be additional issues - the WG participants should identify those
chai: we have quite a few operators defined, but that list can never be completed
… we probably have between 30-50% of what complete would look like
… what criteria do we believe the list of operators for v1 need to fulfill?
anssik: one approach could be to look at the use cases we identified for spec - do the current opset satisfy the scope of these use case? how is the match?
… what you said is a key point - the number of ops is growing, but we're not going to 100% with this release
… we need to explain our story for this particular set, and how we might grow it in the future
… e.g. similar to how it may have been done for ONNX
… it may be appropriate to express this in the spec itself
chai: it would be useful to ask for the group what kind of models we want to support for V1
… we make a good job for CNN; do we need to support Transformers for V1?
… this may lead to adding more operators
… Transformers is an example of a popular model kind, but there may be others
anssik: the first wave models document has been guiding the initial work
… one task might be to make sure that these first wave models reflects the current state of reality
… clearly the opset target is a key consideration for our CR milestone
Support asynchronous graph compilation
#263
<ghurlbot> Issue 263 Support asynchronous graph compilation (wchao1115)
#266
<ghurlbot> Pull Request 266 Add buildAsync method for async graph compilation (huningxin)
anssik: the PR LGTM - we could discuss it now or on github
<chai> i'll take a look at PR 266
ningxin_hu: mostly straightforward PR based on #257
ningxin_hu: we have computeAsync, Junwei requested an async build method for main thread usage
… this is needed to ensure a graph is ready for efficient execution
… with this PR, when the promise resolves, the graph is ready for execution
CommandBuffer usage clarification
#264
<ghurlbot> Issue 264 CommandBuffer usage clarification: internal, external, both? (bbernhar)
"I was seeking for clarification on the usage of MLCommandBuffer: will it be internal-only (read/write by WebNN), external-only (read-only by WebNN, read/write by WebGPU) or both (read/write both WebNN and WebGPU)."
WebNN API - WebGPU Interoperability section
<chai> sorry i'll have a hard stop this morning at 7:40
anssik: one of the underlying issue is if the WebGPU API changes under our feet, this may create issues for us
chai: this is one of the last topics for the async discussion
… we want to separate the interface from the implementation
… we don't need to reinvent a new type for a commandbuffer - there aren't a lot of benefits to reinvent the WebGPU command buffer
… Brian's feedback is on the implementation side - the two new APIs need to agree and allow them working together under the hood
… In terms of API, I think it doesn't really matter whether it's ML- or GPUCommandBuffer
… from the implementation perspective, we need to work with the Chromium Dawn project to make sure that what WebNN produces can be used by WebGPU
dom: thanks Chai, I want to make sure this implementation concern isn't Chromium specific so that decision in this space do not make it harder for other engines to adopt WebNN
… nothing suggests that would be the case, but want to make sure we do not optimize for Chromium implementation, but enable other implementations with different architectures to perform equally well
chai: +1
… from my experience, the interop between WebGPU & WebNN is helped a bit by the API, but the key is at the implementation level
… the key thing is to make sure the API doesn't prevent from the right thing to happen
… currently, GPUCommandBuffer is obviously not WebNN-aware
… the question is whether the implementation of GPUCommandBuffer can be amended to handle WebNN needs
RafaelCintron: +1
… the bottom line is that we need implementation experience to give us clarity on the API shape
anssik: please bring that input to the issue as well (I'll post the minutes there already)
WebNN API Ethical Considerations integration
ghurlbot, this is ethical-webmachinelearning
<ghurlbot> dom, OK
Ethical Principles for Web Machine Learning
anssik: we're expected to integrate mitigations in the WebNN spec informed by the work done on the ethical principles for machine learning
… we've received substantial contributions from people outside the group
#20
… this is inline with our charter commitment
… we will need to start integrating mitigations in the WebNN spec - it might be hard to translate from abstract ethical issues to mitigations, but there may be areas to provide implementors guidance
<ghurlbot> Pull Request 20 Incorporate feedback from the Ethical ML workshops (anssiko)
dom: I think once I get to review the PR we should look at publishing first public W3C Note of the Ethical Principles doc
… deriving mitigations from principles will be another task, substantial work item
anssik: at the minimum I expect we will surface informative indications in WebNN; maybe some normative mitigations, unclear yet
… this is a first in a W3C WG
WebNN API Privacy Review refresh
anssik: an earlier version of the spec got reviewed by the Privacy IG
… and committed to submit another review on potentially privacy-impacting work
… what has changed since the initial review that would have privacy implications?
… we have at least one open issue on device selection
ghurlbot, this is webnn
<ghurlbot> dom, OK
#169
<ghurlbot> Issue 169 Device selection with MLDevicePreference and MLPowerPreference (anssiko)
dom: I think the safest thing would be to do a diff and see what has changed send that to PING
… or review the PRs that got merged since last review
WebGPU and WebGL WG review
anssik: we have dependencies with WebGL & WebGPU
… we haven't interacted much with the Khronos WebGL WG yet
gpuweb/gpuweb#2500
<ghurlbot> Issue 2500 Investigation: how WebNN / WebGPU interop could be happening (huningxin)
anssik: for WebGPU, we have an ongoing conversation and have a plan to share with them our latest design
… do we need to coordinate with WebGL in some manner?
RafaelCintron: if we have WebGL datatypes in WebNN, yes - the same way if WebNN datatypes were being used elsewhere
… once WebGPU ships, I expect WebGL will move to a maintenance mode; if interop with WebGL is too costly, we could also consider not interop-ing with it esp once WebGPU ships
anssik: sounds like a CR scoping consideration
dom: Rafael, do you expect there are dragons in WebGL interop?
RafaelCintron: speaking for Chrome on Windows, WebGL implementation is built in DirectX 11 which will create lots of GPU copies and surprising performance degradation
dom: the dragons are in terms of reality of implementation than dragon in the spec interop?
… do we see value in providing WebML interop? Or is it because WebGPU was uncertain when we started WebNN?
RafaelCintron: I would favor dropping WebGL interop given the reality of implementations
… WebGPU is the path forward
<ningxin_hu_> +1 to drop WebGL interop
ningxin_hu: +1 to opening an issue on this; I would also support dropping WebGL interop
… when we started WebNN, the frameworks could only use WebGL to use GPU as a backend
… that's the historical reason for having it
… now that WebGPU is the path forward and WebGL in maintenance, dropping WebGL will also help performance-wise for implementations
… my experience with the video processing sample #226, WebGL created issues for performance
<ghurlbot> Issue 226 Integration with real-time video processing (dontcallmedom)cr
ningxin_hu: which was confirmed by the tensorflow.js developer
… this is a known issue in the WebGL chromium implementation with no plan to be fix it soon
… so +1 to dropping WebGL interop
Ethical Content Filtering use case
anssik: Humera provided more concrete use cases with technical requirements to support the proposed "Ethical Content Filtering" use case - please help review and see the PR comments
#253
… Use Case 1: Support for network level request filtering through WebNN's API
… Use Case 2: Support for DOM access through WebNN's API
<ghurlbot> Pull Request 253 Add "Ethical Content Filtering" use case to WebNN specs (humeranoor)