IRC log of webmachinelearning on 2023-02-02

Timestamps are in UTC.

15:00:17 [RRSAgent]
RRSAgent has joined #webmachinelearning
15:00:21 [RRSAgent]
logging to https://www.w3.org/2023/02/02-webmachinelearning-irc
15:00:21 [Zakim]
RRSAgent, make logs Public
15:00:22 [Zakim]
please title this meeting ("meeting: ..."), anssik
15:00:23 [anssik]
Chair: Anssi
15:00:35 [anssik]
Scribe: Anssi
15:00:39 [anssik]
scribeNick: anssik
15:00:45 [anssik]
scribe+ dom
15:00:57 [anssik]
Present+ Anssi_Kostiainen
15:01:02 [anssik]
Present+ Dominique_Hazael-Massieux
15:01:08 [anssik]
Present+ Ningxin_Hu
15:01:15 [anssik]
Present+ Zoltan_Kis
15:01:45 [anssik]
RRSAgent, draft minutes
15:01:46 [RRSAgent]
I have made the request to generate https://www.w3.org/2023/02/02-webmachinelearning-minutes.html anssik
15:02:05 [anssik]
Present+ Rafael_Cintron
15:02:51 [anssik]
Meeting: WebML WG Teleconference – 2 February 2023
15:02:54 [anssik]
RRSAgent, draft minutes
15:02:55 [RRSAgent]
I have made the request to generate https://www.w3.org/2023/02/02-webmachinelearning-minutes.html anssik
15:05:52 [anssik]
Topic: WebNN API open PRs and issues
15:05:58 [anssik]
ghurlbot, this is webmachinelearning/webnn
15:05:58 [ghurlbot]
anssik, OK.
15:06:05 [anssik]
anssik: I'd like us to review the open PRs discuss key open issues
15:06:11 [RafaelCintron]
RafaelCintron has joined #webmachinelearning
15:06:12 [anssik]
Subtopic: Simplify MLContext creation
15:06:17 [anssik]
anssik: PR #322
15:06:18 [ghurlbot]
https://github.com/webmachinelearning/webnn/issues/322 -> Pull Request 322 Simplify MLContext creation (wchao1115)
15:06:31 [anssik]
... as a re-cap this PR proposes to remove MLDeviceType enum:
15:06:38 [anssik]
enum MLDeviceType {
15:06:38 [anssik]
"cpu",
15:06:38 [anssik]
"gpu"
15:06:38 [anssik]
};
15:06:45 [anssik]
anssik: and to remove "high-performance" from MLPowerPreference enum:
15:06:52 [anssik]
enum MLPowerPreference {
15:06:52 [anssik]
"default",
15:06:52 [anssik]
"high-performance",
15:06:52 [anssik]
"low-power"
15:06:53 [anssik]
};
15:07:13 [anssik]
anssik: this PR makes WebGPU a normative dependency for the WebNN API, streamlines the GPU acceleration path
15:07:23 [anssik]
... with these changes, GPU context can be created only from a WebGPU device
15:07:34 [anssik]
... in our CR plan of record we agreed that WebGPU interop needs more implementation experience
15:07:44 [anssik]
... as a WG we acknowledge WebGPU interop is very important to get right
15:08:02 [anssik]
... I want to give this important feature enough time to mature through implementation experience
15:08:14 [anssik]
... and thus I prefer not to rush this important feature into the initial CR release train
15:08:46 [anssik]
... I will suggest to add an appropriate text and a pointer to this change into the "Status of This Document" section of the upcoming CR to draw attention to this upcoming feature expected in a CR update
15:09:26 [anssik]
... then, we can coordinate with WebGPU contributors and the implementation for an appropriate time for landing this feature into a revised CR that is expected to follow the initial CR
15:09:44 [anssik]
... I think WebGPU folks' feedback and review is required and super important
15:09:56 [dom]
q+
15:10:01 [anssik]
ack dom
15:10:20 [zkis]
q+
15:10:34 [anssik]
dom: couple of remarks, pushing to a revised CR makes sense, was not clear on "v2" semantics
15:10:42 [anssik]
... do we understand the impact on implementations?
15:11:13 [anssik]
... implementations should start based on the CR?
15:11:39 [anssik]
... because it is not a minor change, having it on SOTD and also having it linked from the relevant parts of the spec too
15:11:42 [anssik]
q?
15:12:04 [dom]
anssi: v2 in the agenda is about revised CRs indeed
15:12:27 [dom]
... which can be done relatively easily nowadays
15:12:48 [dom]
... in terms of implementations - we're spec-ing and implementing together
15:13:07 [dom]
... and implementors are directly involved in this conversation
15:13:28 [dom]
... as we're proceeding to a recharter, I think it's important to show our progress with an initial CR
15:14:05 [anssik]
q?
15:14:08 [anssik]
ack zkis
15:15:34 [anssik]
q?
15:16:12 [dom]
zkis: we're discussed a lot in PR - should some of these be moved to issues for greater visibility?
15:16:37 [dom]
anssi: we could retroactively create an issue
15:17:02 [dom]
zkis: having discussion hidden in PRs makes it harder to find from my experience
15:17:52 [dom]
Rafael: I support Chai's proposal in the PR
15:18:12 [dom]
... interop with WebGPU is important to move forward
15:18:30 [dom]
... I think we should keep that flexibility open; not necessarily block on the WebGPU for progress
15:18:36 [dom]
... e.g. for prototyping
15:18:49 [dom]
s/WebGPU/WebGPU WG/
15:18:55 [dom]
... gaining implementation experience is key
15:19:52 [ghurlbot]
https://github.com/webmachinelearning/webnn/issues/322 -> Pull Request 322 Simplify MLContext creation (wchao1115)
15:21:54 [zkis]
q+
15:22:00 [dom]
PROPOSED: the initial CR will include an explicit call for implementation input on a simplify MLContext for WebGPU integration
15:23:09 [anssik]
PROPOSED: the initial CR will include an explicit call for implementation input on PR #322 to simplify MLContext creation
15:25:31 [anssik]
dom: the PR would be open for review and comments
15:25:46 [anssik]
... if we merge this PR, it would land in the next iteration of CR
15:26:24 [dom]
anssik: my take is that we don't have enough implementation experience to ensure the model works
15:26:25 [dom]
q+
15:27:15 [dom]
rafael: the current spec has the same needs of WebGPU interop & reviews
15:27:20 [anssik]
https://github.com/webmachinelearning/webnn/issues/240
15:27:30 [dom]
... this PR improves the WebGPU interop from my perspective
15:28:08 [dom]
anssi: we discussed marking the other piece of WebGPU interop as "at risk" given lack of implementation / review
15:28:20 [dom]
... but this could change in a next CR
15:28:43 [dom]
rafael: so would the current section on WebGPU remains in the spec with a warning?
15:29:13 [dom]
anssi: right - or it could move to a separate spec if the group evaluates it's an improvement
15:30:04 [dom]
rafael: I'm not sure why we shouldn't merge improvements to WebGPU interop given the lack of implementation experience overall in that space
15:30:09 [ningxin_hu]
q+
15:30:34 [dom]
anssi: if we merge this PR, the current implementation in chromium wouldn't reflect the spec
15:30:55 [dom]
... the current impelemntation is partial but aligned with a subset of the spec
15:31:05 [dom]
... with this PR, this would no longer be the case
15:31:57 [anssik]
https://www.w3.org/TR/webnn/#api-mlcontext-webgpu-interop
15:32:31 [dom]
... I see 2 options: keep WebGPU interop sections in the spec and mark them as needing more impl experience; or move them to a separate spec before the initial CR
15:33:16 [anssik]
dom: I'll chime in on process bits, we don't need implementation experience strictly to go to CR
15:33:32 [anssik]
... in that sense moving to a CR with or w/o PR merged is neutral
15:34:11 [anssik]
... the difference I see, because we are putting this in the code of the spec that is implementable without WebGPU support, it makes harder to argue we can move to CR without WebGPU WG review
15:34:40 [anssik]
... that is why we may want to stage the process in such a manner
15:36:46 [anssik]
q?
15:36:48 [dom]
anssi: we need to find a way to engage the WebGPU people on this review
15:36:54 [anssik]
ack ningxin_hu
15:36:55 [dom]
ack me
15:37:52 [dom]
ningxin_hu: this PR is not for WebGPU interop (which is done through MLCommandEncoder)
15:38:04 [dom]
s/is not for/is orthogonal to/
15:38:15 [dom]
... it restructures the GPU context creation for WebGPU devices
15:38:57 [dom]
... today's spec has two ways to create GPU context: with MLDeviceType and power preference setting, and a way from a GPUDevice
15:39:15 [dom]
... this PR unifies the two into one and simplifies it
15:40:10 [dom]
... based on my experience with implementations with existing backends, it actually makes it harder to implement as it removes flexibility
15:40:27 [dom]
... keeping the two options allows to prototype and gain implementation experience across platforms
15:40:47 [dom]
... there are risks we could hit blocking issues on some platforms
15:41:01 [anssik]
q?
15:41:44 [dom]
anssik: this reminds me of how WebRTC APIs depend on the same libwebrt across browsers
15:41:52 [dom]
s/webrt/webrtc/
15:42:08 [dom]
... maybe not
15:42:23 [dom]
q+
15:42:55 [dom]
... are there independent WebGPU implementations?
15:42:57 [dom]
Rafael: 3 independent ones, yes
15:43:34 [dom]
anssik: any thought on the challenge this may create e.g. with MLService on ChromeOS?
15:44:41 [dom]
ningxin_hu: we need to address that gap for other ML native systems - it puts a requirement on native ML APIs and frameworks to support GPUs and need to recognize WebGPU devices and native implementations
15:45:03 [dom]
... from my experience, this would be problematic at least on ChromeOS
15:45:45 [dom]
... it's probably ok on windows, but we should check on MacOS and others - I suspect this may be too constraining there to adapt to these platforms
15:46:21 [anssik]
anssik: our charter states: "The APIs in scope of this group will not be tied to any particular platform and will be implementable on top of existing major platform APIs, such as Android Neural Networks API, Windows DirectML, and macOS/iOS Metal Performance Shaders and Basic Neural Network Subroutines." https://www.w3.org/2021/04/web-machine-learning-charter.html
15:46:21 [dom]
... cross-platform support is important for a Web API
15:47:42 [anssik]
dom: I'm hearing not so much about implementations, more about fundamental design question whether this design supports multiple platforms
15:47:51 [RafaelCintron]
q+
15:48:37 [anssik]
... this is more a judgment call what we see as the most likely direction, will be hit a snag when doing x-platform implementation, or is the current design slowing adoption?
15:48:38 [anssik]
q?
15:48:42 [dom]
ack me
15:48:48 [anssik]
ack RafaelCintron
15:49:09 [dom]
RafaelCintron: having multi-platform support is good - we should do that
15:49:25 [dom]
... the editors have done a good job to ensure new operators are well supported across platforms and frameworks
15:50:04 [dom]
... in MS, we definitely care about windows, but also very much about other platforms where we also have lots of stakes
15:50:26 [dom]
... wrt putting in the spec vs moving to a different spec - the current spec refers to the current status of the WG work
15:50:53 [dom]
... when it's iffy, it's ok to say so in the spec; it's also OK to move it to a separate document if that's better
15:51:08 [dom]
... overall, I think the latest-and-greatest thinking should be merged in the spec, not languish in PRs
15:51:16 [anssik]
q?
15:51:55 [dom]
anssik: one trade-off is the lack of alignment between spec and implementation
15:52:19 [dom]
... could we somehow show the two options as alternatives in the spec?
15:52:31 [dom]
... e.g. with a note explaining the new model in the spec?
15:53:25 [anssik]
dom: this has been done in specs earlier, so not an issue for CR
15:53:44 [dom]
q+
15:54:04 [anssik]
ack dom
15:54:23 [anssik]
dom: how certain we are that the new model would not be implementation on ChromeOS and other platforms?
15:54:25 [anssik]
q?
15:54:33 [anssik]
q+ ningxin_hu
15:54:50 [anssik]
s/implementation/implementable
15:55:21 [anssik]
dom: the level of applicability is important consideration
15:55:24 [anssik]
ack ningxin_hu
15:56:39 [dom]
ningxin_hu: for ChromeOS, we would need more input from ChromeOS people
15:57:02 [dom]
... from what we know in details today, the MLService backend doesn't interact with the WebGPU implementation - unclear if there is a path to a solution
15:57:15 [anssik]
RRSAgent, draft minutes
15:57:16 [RRSAgent]
I have made the request to generate https://www.w3.org/2023/02/02-webmachinelearning-minutes.html anssik
15:57:54 [dom]
... if we stick to the current context creation with MLDeviceType, we can support both ChromeOS and Windows in what we have today
15:58:04 [dom]
... because the GPUDevice can be created and the MLContext can accept array buffers without interactions with WebGPU APIs
15:58:31 [dom]
... if we simplify the MLContext creation to only GPUDevice, we can implement it in DirectML, but unclear for ChromeOS
15:59:29 [anssik]
dom: thanks! I'd say feasibility is complex space here due to platform, OS can evolve to what is required by this spec
15:59:32 [anssik]
... at the high level, to implement the change, if we think it through priority of constituencies
15:59:49 [anssik]
... easier API for developers is higher in priority
16:00:02 [anssik]
... OTOH, if implementers cannot adopt this API then it changes this picture
16:01:21 [anssik]
... I'm hearing, whether it is doable remains unclear, personal sense is maybe merging the PR is the right thing even we don't know if that leads to multi-platform implementations? Not pushing hard on one way or another. We may need to reverts change if impl exp proves otherwise.
16:02:03 [dom]
anssi: our next milestone is the CR release to keep up with our commitment
16:02:18 [dom]
... we need to converge on the content of the CR
16:02:56 [dom]
... my initial proposal was to highlight the PR in the CR and annotate the WebGPU interop section in the spec - we didn't reach consensus, but that remains an option
16:03:19 [dom]
... another option is to merge the PR (the impl is no longer in sync in that case), and we move to CR
16:03:33 [dom]
... another option is to move WebGPU interop to a separate spec
16:03:58 [RafaelCintron]
q+
16:04:18 [dom]
... I like Rafael's point that we need to be as clear as possible in the body of the spec, put front and center our thinking, incl where we haven't converged and need more implementation experience
16:04:30 [dom]
... quite a few options in front of us
16:04:32 [anssik]
ack RafaelCintron
16:04:46 [dom]
q- Zkis
16:05:08 [dom]
RafaelCintron: if there is doubt about implementability, we should work it out in the PR
16:05:46 [dom]
... the spec should reflect the group's thinking; annotating the spec when we lack implementation experience and we don't know if that will work is fine
16:06:08 [dom]
... but it shouldn't be a presentation of disagreements per se
16:06:40 [dom]
... I don't want CR to block us in getting the right content in the spec
16:06:48 [anssik]
q?
16:07:17 [dom]
... as for working with the WebGPU WG, on Feb 16-17, the WebGPU WG has a F2F in California - their first actual F2F since Covid
16:07:30 [dom]
... the agenda of the WG includes future directions of the API
16:07:35 [dom]
s/WG/F2F/
16:07:54 [dom]
... this would be a good opportunity work with them on interop issues and expose more of what WebNN is and what it needs
16:08:02 [dom]
s/opportunity/opportunity to/
16:08:17 [dom]
anssi: thanks for sharing this, that's exciting!
16:08:39 [dom]
... it would be great to have MLCommandEncoder presenter there - e.g. if Chai was able to do so?
16:08:45 [dom]
s/presenter/presented/
16:08:56 [dom]
... or Ningxin remotely, if Chai can't
16:09:48 [dom]
Anssi: I'll discuss with Dom on our path to CR as we discuss our rechartering
16:10:21 [dom]
... heads up that we're hoping to move forward with our charter renewal
16:10:38 [anssik]
q?
16:10:52 [dom]
RRSAgent, draft minutes
16:10:53 [RRSAgent]
I have made the request to generate https://www.w3.org/2023/02/02-webmachinelearning-minutes.html dom
17:51:22 [ghurlbot]
ghurlbot has joined #webmachinelearning
18:30:34 [Zakim]
Zakim has left #webmachinelearning