15:00:17 RRSAgent has joined #webmachinelearning 15:00:21 logging to https://www.w3.org/2023/02/02-webmachinelearning-irc 15:00:21 RRSAgent, make logs Public 15:00:22 please title this meeting ("meeting: ..."), anssik 15:00:23 Chair: Anssi 15:00:35 Scribe: Anssi 15:00:39 scribeNick: anssik 15:00:45 scribe+ dom 15:00:57 Present+ Anssi_Kostiainen 15:01:02 Present+ Dominique_Hazael-Massieux 15:01:08 Present+ Ningxin_Hu 15:01:15 Present+ Zoltan_Kis 15:01:45 RRSAgent, draft minutes 15:01:46 I have made the request to generate https://www.w3.org/2023/02/02-webmachinelearning-minutes.html anssik 15:02:05 Present+ Rafael_Cintron 15:02:51 Meeting: WebML WG Teleconference – 2 February 2023 15:02:54 RRSAgent, draft minutes 15:02:55 I have made the request to generate https://www.w3.org/2023/02/02-webmachinelearning-minutes.html anssik 15:05:52 Topic: WebNN API open PRs and issues 15:05:58 ghurlbot, this is webmachinelearning/webnn 15:05:58 anssik, OK. 15:06:05 anssik: I'd like us to review the open PRs discuss key open issues 15:06:11 RafaelCintron has joined #webmachinelearning 15:06:12 Subtopic: Simplify MLContext creation 15:06:17 anssik: PR #322 15:06:18 https://github.com/webmachinelearning/webnn/issues/322 -> Pull Request 322 Simplify MLContext creation (wchao1115) 15:06:31 ... as a re-cap this PR proposes to remove MLDeviceType enum: 15:06:38 enum MLDeviceType { 15:06:38 "cpu", 15:06:38 "gpu" 15:06:38 }; 15:06:45 anssik: and to remove "high-performance" from MLPowerPreference enum: 15:06:52 enum MLPowerPreference { 15:06:52 "default", 15:06:52 "high-performance", 15:06:52 "low-power" 15:06:53 }; 15:07:13 anssik: this PR makes WebGPU a normative dependency for the WebNN API, streamlines the GPU acceleration path 15:07:23 ... with these changes, GPU context can be created only from a WebGPU device 15:07:34 ... in our CR plan of record we agreed that WebGPU interop needs more implementation experience 15:07:44 ... as a WG we acknowledge WebGPU interop is very important to get right 15:08:02 ... I want to give this important feature enough time to mature through implementation experience 15:08:14 ... and thus I prefer not to rush this important feature into the initial CR release train 15:08:46 ... 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 ... 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 ... I think WebGPU folks' feedback and review is required and super important 15:09:56 q+ 15:10:01 ack dom 15:10:20 q+ 15:10:34 dom: couple of remarks, pushing to a revised CR makes sense, was not clear on "v2" semantics 15:10:42 ... do we understand the impact on implementations? 15:11:13 ... implementations should start based on the CR? 15:11:39 ... 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 q? 15:12:04 anssi: v2 in the agenda is about revised CRs indeed 15:12:27 ... which can be done relatively easily nowadays 15:12:48 ... in terms of implementations - we're spec-ing and implementing together 15:13:07 ... and implementors are directly involved in this conversation 15:13:28 ... as we're proceeding to a recharter, I think it's important to show our progress with an initial CR 15:14:05 q? 15:14:08 ack zkis 15:15:34 q? 15:16:12 zkis: we're discussed a lot in PR - should some of these be moved to issues for greater visibility? 15:16:37 anssi: we could retroactively create an issue 15:17:02 zkis: having discussion hidden in PRs makes it harder to find from my experience 15:17:52 Rafael: I support Chai's proposal in the PR 15:18:12 ... interop with WebGPU is important to move forward 15:18:30 ... I think we should keep that flexibility open; not necessarily block on the WebGPU for progress 15:18:36 ... e.g. for prototyping 15:18:49 s/WebGPU/WebGPU WG/ 15:18:55 ... gaining implementation experience is key 15:19:52 https://github.com/webmachinelearning/webnn/issues/322 -> Pull Request 322 Simplify MLContext creation (wchao1115) 15:21:54 q+ 15:22:00 PROPOSED: the initial CR will include an explicit call for implementation input on a simplify MLContext for WebGPU integration 15:23:09 PROPOSED: the initial CR will include an explicit call for implementation input on PR #322 to simplify MLContext creation 15:25:31 dom: the PR would be open for review and comments 15:25:46 ... if we merge this PR, it would land in the next iteration of CR 15:26:24 anssik: my take is that we don't have enough implementation experience to ensure the model works 15:26:25 q+ 15:27:15 rafael: the current spec has the same needs of WebGPU interop & reviews 15:27:20 https://github.com/webmachinelearning/webnn/issues/240 15:27:30 ... this PR improves the WebGPU interop from my perspective 15:28:08 anssi: we discussed marking the other piece of WebGPU interop as "at risk" given lack of implementation / review 15:28:20 ... but this could change in a next CR 15:28:43 rafael: so would the current section on WebGPU remains in the spec with a warning? 15:29:13 anssi: right - or it could move to a separate spec if the group evaluates it's an improvement 15:30:04 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 q+ 15:30:34 anssi: if we merge this PR, the current implementation in chromium wouldn't reflect the spec 15:30:55 ... the current impelemntation is partial but aligned with a subset of the spec 15:31:05 ... with this PR, this would no longer be the case 15:31:57 https://www.w3.org/TR/webnn/#api-mlcontext-webgpu-interop 15:32:31 ... 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 dom: I'll chime in on process bits, we don't need implementation experience strictly to go to CR 15:33:32 ... in that sense moving to a CR with or w/o PR merged is neutral 15:34:11 ... 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 ... that is why we may want to stage the process in such a manner 15:36:46 q? 15:36:48 anssi: we need to find a way to engage the WebGPU people on this review 15:36:54 ack ningxin_hu 15:36:55 ack me 15:37:52 ningxin_hu: this PR is not for WebGPU interop (which is done through MLCommandEncoder) 15:38:04 s/is not for/is orthogonal to/ 15:38:15 ... it restructures the GPU context creation for WebGPU devices 15:38:57 ... 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 ... this PR unifies the two into one and simplifies it 15:40:10 ... based on my experience with implementations with existing backends, it actually makes it harder to implement as it removes flexibility 15:40:27 ... keeping the two options allows to prototype and gain implementation experience across platforms 15:40:47 ... there are risks we could hit blocking issues on some platforms 15:41:01 q? 15:41:44 anssik: this reminds me of how WebRTC APIs depend on the same libwebrt across browsers 15:41:52 s/webrt/webrtc/ 15:42:08 ... maybe not 15:42:23 q+ 15:42:55 ... are there independent WebGPU implementations? 15:42:57 Rafael: 3 independent ones, yes 15:43:34 anssik: any thought on the challenge this may create e.g. with MLService on ChromeOS? 15:44:41 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 ... from my experience, this would be problematic at least on ChromeOS 15:45:45 ... 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: 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 ... cross-platform support is important for a Web API 15:47:42 dom: I'm hearing not so much about implementations, more about fundamental design question whether this design supports multiple platforms 15:47:51 q+ 15:48:37 ... 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 q? 15:48:42 ack me 15:48:48 ack RafaelCintron 15:49:09 RafaelCintron: having multi-platform support is good - we should do that 15:49:25 ... the editors have done a good job to ensure new operators are well supported across platforms and frameworks 15:50:04 ... in MS, we definitely care about windows, but also very much about other platforms where we also have lots of stakes 15:50:26 ... 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 ... 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 ... overall, I think the latest-and-greatest thinking should be merged in the spec, not languish in PRs 15:51:16 q? 15:51:55 anssik: one trade-off is the lack of alignment between spec and implementation 15:52:19 ... could we somehow show the two options as alternatives in the spec? 15:52:31 ... e.g. with a note explaining the new model in the spec? 15:53:25 dom: this has been done in specs earlier, so not an issue for CR 15:53:44 q+ 15:54:04 ack dom 15:54:23 dom: how certain we are that the new model would not be implementation on ChromeOS and other platforms? 15:54:25 q? 15:54:33 q+ ningxin_hu 15:54:50 s/implementation/implementable 15:55:21 dom: the level of applicability is important consideration 15:55:24 ack ningxin_hu 15:56:39 ningxin_hu: for ChromeOS, we would need more input from ChromeOS people 15:57:02 ... 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 RRSAgent, draft minutes 15:57:16 I have made the request to generate https://www.w3.org/2023/02/02-webmachinelearning-minutes.html anssik 15:57:54 ... 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 ... because the GPUDevice can be created and the MLContext can accept array buffers without interactions with WebGPU APIs 15:58:31 ... if we simplify the MLContext creation to only GPUDevice, we can implement it in DirectML, but unclear for ChromeOS 15:59:29 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 ... at the high level, to implement the change, if we think it through priority of constituencies 15:59:49 ... easier API for developers is higher in priority 16:00:02 ... OTOH, if implementers cannot adopt this API then it changes this picture 16:01:21 ... 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 anssi: our next milestone is the CR release to keep up with our commitment 16:02:18 ... we need to converge on the content of the CR 16:02:56 ... 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 ... 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 ... another option is to move WebGPU interop to a separate spec 16:03:58 q+ 16:04:18 ... 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 ... quite a few options in front of us 16:04:32 ack RafaelCintron 16:04:46 q- Zkis 16:05:08 RafaelCintron: if there is doubt about implementability, we should work it out in the PR 16:05:46 ... 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 ... but it shouldn't be a presentation of disagreements per se 16:06:40 ... I don't want CR to block us in getting the right content in the spec 16:06:48 q? 16:07:17 ... 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 ... the agenda of the WG includes future directions of the API 16:07:35 s/WG/F2F/ 16:07:54 ... 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 s/opportunity/opportunity to/ 16:08:17 anssi: thanks for sharing this, that's exciting! 16:08:39 ... it would be great to have MLCommandEncoder presenter there - e.g. if Chai was able to do so? 16:08:45 s/presenter/presented/ 16:08:56 ... or Ningxin remotely, if Chai can't 16:09:48 Anssi: I'll discuss with Dom on our path to CR as we discuss our rechartering 16:10:21 ... heads up that we're hoping to move forward with our charter renewal 16:10:38 q? 16:10:52 RRSAgent, draft minutes 16:10:53 I have made the request to generate https://www.w3.org/2023/02/02-webmachinelearning-minutes.html dom 17:51:22 ghurlbot has joined #webmachinelearning 18:30:34 Zakim has left #webmachinelearning