14:58:06 RRSAgent has joined #webmachinelearning 14:58:10 logging to https://www.w3.org/2025/01/30-webmachinelearning-irc 14:58:10 RRSAgent, make logs Public 14:58:11 please title this meeting ("meeting: ..."), anssik 14:58:28 Meeting: WebML WG Teleconference – 30 January 2025 14:58:32 Chair: Anssi 14:58:47 Agenda: https://github.com/webmachinelearning/meetings/blob/main/telcons/2025-01-30-wg-agenda.md 14:58:49 Scribe: Anssi 14:59:01 dwayner has joined #webmachinelearning 14:59:01 scribeNick: anssik 14:59:10 gb, this is webmachinelearning/webnn 14:59:10 anssik, OK. 14:59:20 Present+ Anssi_Kostiainen 14:59:21 jsbell has joined #webmachinelearning 14:59:22 McCool has joined #webmachinelearning 14:59:29 Present+ Etienne_Noel 14:59:39 Present+ Joshua_Bell 14:59:43 Present+ Michael_McCool 15:00:21 Present+ Bryan_Bernhart 15:00:56 Present+ Christian_Liebel 15:01:19 Present+ Tarek_Ziade 15:01:35 Present+ Zoltan_Kis 15:01:45 RafaelCintron has joined #webmachinelearning 15:02:09 Present+ Rafael_Cintron 15:02:21 RRSAgent, draft minutes 15:02:22 I have made the request to generate https://www.w3.org/2025/01/30-webmachinelearning-minutes.html anssik 15:02:39 Present+ Dominique_Hazael-Massieux 15:03:26 tarek has joined #webmachinelearning 15:03:31 o/ 15:03:38 Joshua_Lochner has joined #webmachinelearning 15:03:42 zkis has joined #webmachinelearning 15:04:13 Present+ Joshua_Lochner 15:04:29 Present+ Ayu 15:05:06 Present+ Dom 15:05:16 anssik: Happy Lunar New Year to our participants using lunar calendars! 15:05:22 ... our PRC participants are taking time off to celebrate during this period 15:05:57 .... welcome to Tarek Ziade from Mozilla, Mike Wasserman and Christine Hollingsworth from Google to the WebML WG 15:06:25 ... also welcome to Stalgia Grigg from Bocoup and Mingyu Lei from Google, Yuichiro Tachibana from Hugging Face, Sushanth Rajasankar from Microsoft, Tarek Ziade from Mozilla joining the WebML CG! 15:07:15 Tarek: I work in ML AI team at Mozilla that integrates inference features into Firefox desktop 15:07:49 ... my team working to integrate Transformers.js into the browser extension, first use case PDF.js with alt text generation for images 15:08:33 ... running locally via ONNX Runtime, recently wrapped that API into a new trial API for Web Extensions, doing similar things such as Transformers.js with its pipeline API 15:08:58 ... with Web Extensions API we do in addition caching, run inference in a separate process 15:09:21 ... very interested in this group, learn about what is happening, hope to see everything converging to cool new stuff for web developer! 15:10:01 Topic: W3C Breakouts Day 2025 15:10:12 anssik: there's a call for breakout session proposals for W3C Breakouts Day 2025 on 26 March 2025 15:10:32 ... the goal of the day is to foster discussion among the full W3C community about new or existing topics 15:10:42 ... this is an opportunity to reach out to folks outside our WebML community 15:10:53 ... breakout format is quite relaxed, can be e.g. a presentation and/or discussion 15:10:56 ... duration max 1 hour 15:11:03 ... deadline for breakout proposals 12 March 15:11:09 ... no registration, anyone with a W3C account eligible, non-Members too 15:11:14 ... proposals are submitted via new GH issues: 15:11:18 -> Propose a new breakout session https://github.com/w3c/breakouts-day-2025/issues/new?assignees=&labels=session&projects=&template=session.yml 15:11:26 anssik: instruction linked from the issue template 15:11:34 anssik: you can check the earlier breakouts for inspiration: 15:11:38 -> 2024 breakout proposals https://github.com/w3c/tpac2024-breakouts/issues/ 15:11:42 -> 2023 breakout proposals https://github.com/w3c/tpac2023-breakouts/issues/ 15:11:45 anssik: more information available on GH: 15:11:49 -> W3C Breakouts Day 2025 https://github.com/w3c/breakouts-day-2025/ 15:11:59 anssik: please let me know if you'd be interested in suggesting a breakout session and I can help get it in 15:12:07 ... one possible topic could be to present and discuss the new Community Group incubations 15:13:10 Topic: Device selection 15:13:23 anssik: PR #809 specifies the Proposed Minimum Viable Solution per device-selection-explainer.md 15:13:24 https://github.com/webmachinelearning/webnn/pull/809 -> Pull Request 809 Remove MLDeviceType (by zolkis) [device selection] 15:13:28 ... and closes issues #749 and #302 15:13:28 https://github.com/webmachinelearning/webnn/issues/302 -> Issue 302 API simplification: context types, context options, createContext() (by zolkis) [v2] [device selection] 15:13:29 https://github.com/webmachinelearning/webnn/issues/749 -> Issue 749 MLContextOptions.deviceType seems unnecessary outside of conformance testing (by mwyrzykowski) [device selection] 15:13:35 -> device-selection-explainer.md https://github.com/webmachinelearning/webnn/blob/main/device-selection-explainer.md 15:13:45 anssik: thank you Zoltan for the PR and Josh for review comments! 15:13:55 ... summary of changes: 15:14:00 ... - Remove MLDeviceType as explicit context option 15:14:06 ... - Update MLContext so that it becomes device agnostic 15:14:17 ... - Add algorithmic steps or notes to implementations on how to map power preference to devices 15:14:25 ... the following changes documented in the explainer is not in this PR: 15:14:33 ... - Also, to align with GPUPowerPreference, we should remove the "default" MLPowerPreference, i.e. the lack of hints will result in creating a generic context. 15:14:46 ... In addition, privacy considerations have been updated, reducing fingerprintable surface further 15:14:51 ... the corresponding IDL change is the following: 15:14:58 -enum MLDeviceType { 15:14:59 - "cpu", 15:14:59 - "gpu", 15:14:59 - "npu" 15:14:59 -}; 15:14:59 15:14:59 dictionary MLContextOptions { 15:14:59 - MLDeviceType deviceType = "cpu"; 15:14:59 MLPowerPreference powerPreference = "default"; 15:14:59 }; 15:15:16 anssik: PR invites further review, I expect we are able to merge this soonish 15:15:47 Zoltan: didn't remove "default" because strictly speaking not part of this minimal change 15:16:06 ... discussion on the explainer suggests we could keep it this way for now 15:16:27 ... Josh brought up a point the context creation needs some work, should we include it here or let it be another PR? 15:17:26 anssik: editor can decide on how to go about that 15:17:30 Zoltan: PTAL everyone 15:17:38 Dwayne: I will look at it today 15:17:41 q? 15:17:50 ack dom 15:18:22 Dom: should the explainer we reviewed by TAG and/or Privacy WG? 15:19:13 anssik: proposal to do that review in context of the next CRS 15:20:15 q? 15:20:47 Topic: Operator set Wave 3 15:20:52 anssik: PR #805 15:20:53 https://github.com/webmachinelearning/webnn/pull/805 -> Pull Request 805 Operator set wave 3 (by fdwr) 15:21:01 ... this sizable PR addresses a number of open issues 15:21:08 ... thank you Dwayne for updates and Ningxin and Josh for your review comments 15:21:21 ... first I'd like to check we're capturing all the issues this PR closes, current list: 15:21:23 (re: previous topic) To be explicit: plan to "review the change in context of the next CRS" SGTM 15:21:35 ... closes #93 - PR adds quantizeLinear and dequantizeLinear 15:21:36 https://github.com/webmachinelearning/webnn/issues/93 -> Issue 93 Add QuantizeLinear and DequantizeLinear for mixed precision (by kpu) [opset] [feature request] 15:21:49 ... closes #467 - PR adds scatterElements, scatterND, gatherElements, gatherND (gather added earlier) 15:21:49 https://github.com/webmachinelearning/webnn/issues/467 -> Issue 467 Where is scatter and gather op? (by muazhuda) [feature request] [operator specific] 15:22:03 ... closes #772 - PR adds MLSliceOptions 15:22:04 https://github.com/webmachinelearning/webnn/issues/772 -> Issue 772 Support strides option for `slice` operator (by huningxin) [feature request] [operator specific] 15:22:28 ... closes #767? - we're adding scatter and gather ops, do we want "this operation can be generically emulated" box? 15:22:29 https://github.com/webmachinelearning/webnn/issues/767 -> Issue 767 Request the decomposition for gatherElements, scatterElements and scatterND (by fujunwei) [operator specific] 15:22:39 ... closes #773 - PR adds reverse 15:22:39 https://github.com/webmachinelearning/webnn/issues/773 -> Issue 773 Support `reverse` operator (by huningxin) [feature request] [operator specific] 15:22:54 ... closes #779 - PR adds blockwise broadcasting to quantizeLinear and dequantizeLinear 15:22:55 https://github.com/webmachinelearning/webnn/issues/779 -> Issue 779 Support block-wise quantization (by huningxin) [operator specific] 15:23:12 ... the spec PR is annotated with "TODO:" for sections that welcome contributions 15:23:19 q? 15:23:45 Dwayne: thanks everyone for your feedback! 15:23:58 Thanks Dwayne!!! 15:25:26 Dwayne: algorithm steps for gather and scatter would welcome contributions 15:26:41 JoshB: I did a rough pass over many of the issues, nothing more related to this 15:27:16 q? 15:27:19 A reminder to use GitHub's magic keywords in PRs to link to issues: https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue 15:27:50 Topic: WebNN v2 issue triage 15:28:07 anssik: I discussed our "v2" issues with our two-person triage team, so wanted to bring the proposals to the group: 15:28:22 ... to recap, we've used "v2" triage label when "issue is not considered a blocker for Proposed Recommendation” 15:28:43 ... IOW, issues we expect to take a long time to settle, sometimes indefinitely if we choose a different design 15:28:54 ... here's our proposals from "v2" triage: 15:29:00 ... #714 - keep “v2” 15:29:01 https://github.com/webmachinelearning/webnn/issues/714 -> Issue 714 Support multiple op sets / builders (by zolkis) [question] [v2] [opset] 15:29:45 ... #623 - remove “v2”, since #809 address the device type and #805 QDQ - also noted in device-selection-explainer.md 15:29:45 https://github.com/webmachinelearning/webnn/pull/805 -> Pull Request 805 Operator set wave 3 (by fdwr) 15:29:46 https://github.com/webmachinelearning/webnn/issues/623 -> Issue 623 WebNN should support NPU and QDQ operations (by wchao1115) [v2] [opset] [feature request] [device selection] 15:29:46 https://github.com/webmachinelearning/webnn/pull/809 -> Pull Request 809 Remove MLDeviceType (by zolkis) [device selection] 15:30:22 ... #375 - remove “v2”, partially addressed by #805 15:30:23 https://github.com/webmachinelearning/webnn/issues/375 -> Issue 375 Support for transformers (by dontcallmedom) [v2] [opset] 15:31:03 ... #346 - closed per https://github.com/w3c/machine-learning-charter/issues/37 15:31:04 https://github.com/w3c/machine-learning-charter/issues/37 -> CLOSED Issue 37 Core operator set, scope and coordination (by anssiko) 15:31:04 https://github.com/webmachinelearning/webnn/issues/346 -> CLOSED Issue 346 WebNN and StableHLO opset compatibility (by anssiko) [v2] [opset] 15:31:23 ... #302 - remove “v2”, to be closed by #809 15:31:23 https://github.com/webmachinelearning/webnn/issues/302 -> Issue 302 API simplification: context types, context options, createContext() (by zolkis) [v2] [device selection] 15:31:55 ... #6 keep “v2” 15:31:56 https://github.com/webmachinelearning/webnn/issues/6 -> Issue 6 Custom operations (by dsmilkov) [v2] [device selection] 15:32:10 ... #1 keep “v2” — this is explored in the CG and could be relevant for future WebNN 15:32:11 https://github.com/webmachinelearning/webnn/issues/1 -> Issue 1 Look into pre-canned models (by anssiko) [v2] 15:32:36 ... does this look good to you? 15:32:42 ... we'll update the issue tracker accordingly 15:33:10 Sounds fine to me. 15:33:31 Topic: Disallow operations on scalar tensors that are no-ops 15:33:44 anssi: issue #794 was discussed on our previous call and we agreed to look at for which ops scalars make sense 15:33:45 https://github.com/webmachinelearning/webnn/issues/794 -> Issue 794 Disallow operations on scalar tensors that are no-ops (by reillyeon) [operator specific] 15:34:05 ... Dwayne brought up a point that in a math sense adding scalars makes sense, but implementation complexity may suggest otherwise 15:34:15 ... Ningxin provided Chromium implementation experience to fill in the operator <-> scalar support table 15:35:12 ... now that the results are in, quoting Dwayne's proposal we'd next: 15:35:17 ... "determine which backends support scalars already, which do not, and whether it's worth extra code to wrap that operator in a temporary reshape of 0D to 1D" 15:35:54 Dwayne: I will doublecheck Ningxin's feedback and update the table, and will check with Reilly if he has any reservations for TFLite 15:36:18 SG. I'll let Reilly and Phillis know. 15:36:21 ... seems like this is well on track, thanks! 15:36:30 anssik: any questions or comments? 15:36:54 q? 15:36:57 q+ 15:37:02 ack jsbell 15:37:13 Topic: Caching mechanism for MLGraph 15:37:18 anssik: issue #807 15:37:19 https://github.com/webmachinelearning/webnn/issues/807 -> Issue 807 Caching mechanism for MLGraph (by anssiko) [question] [feature request] 15:37:52 jsbell: Reilly IDL is not a concrete proposal, the next steps would be to work on an explainer and document use cases 15:37:59 s/Reilly/Reilly's 15:38:45 jsbell: encourage the group to work on this, not a high priority for the Google Chrome currently 15:39:07 McCool: have looked at this in the past, will see if I can contribute to the explainer 15:39:40 q? 15:41:32 Bryan: many app developers have abandoned monolithic caches in favor of reverting to the older hash-and-cache approach. This method involves setting various pieces of state independently, hashing them all for a GPU call, and using the hash as a key in an app-managed cache 15:42:25 ... implicit caching is still the norm for drivers 15:44:08 Rafael: I think the proposal Reilly put forward is something to consider down the road, all comes down to what the platforms underneath do and recommend 15:44:28 ... e.g. Core ML saves the compiled graph to disk that could be reused 15:46:11 ... I can reach out to the web developers to provide feedback to the WG 15:46:17 q? 15:47:04 q+ 15:47:23 ack zkis 15:47:54 Zoltan: it would be good to list developer use cases as code, couldn't we achieve the same with existing graph provided to the builder? 15:48:11 ... use MLGraph objects themselves 15:48:29 q? 15:48:44 Topic: Expose WebNN API to service workers 15:48:56 anssik: issue #804 is a request from a web developer who's trying to use WebNN in a browser extension 15:48:57 https://github.com/webmachinelearning/webnn/issues/804 -> Issue 804 Expose WebNN API to service workers (by zweack) [use case] [feature request] 15:49:04 ... the error report in the issue is from the Edge browser dev tools console 15:49:19 ... I believe all Chromium-based browsers use a service worker for the extension's background code that stays off the main thread 15:49:27 -> https://developer.chrome.com/docs/extensions/develop/migrate/to-service-workers 15:49:41 anssik: WebGPU recently added support for service workers (and shared workers) to enable use cases such as WebLLM chrome extension 15:49:46 -> https://github.com/gpuweb/gpuweb/issues/4197 15:49:46 https://github.com/gpuweb/gpuweb/issues/4197 -> CLOSED Issue 4197 API should be exposed to ServiceWorker (by MiguelsPizza) [proposal] [feature request] 15:49:52 -> https://github.com/mlc-ai/web-llm/tree/main/examples/chrome-extension-webgpu-service-worker 15:50:12 anssik: it looks like WebNN could similarly consider exposing the API to service workers to enable this use case for extensions? 15:50:18 ... there are probably also other use cases for service workers? 15:50:28 ... currently the ML interface is exposed to window and dedicated worker scope only 15:50:52 q+ 15:51:03 ... a separate consideration would be whether to expose the API to shared workers that can be accessed from several browsing contexts that share the exact same origin e.g. windows, iframes, also interested in use cases and possible abuse cases that we should mitigate against 15:51:05 q? 15:51:07 ack RafaelCintron 15:51:21 https://github.com/gpuweb/gpuweb/issues/4197 15:51:24 RafaelCintron: this same issue with service workers came up with WebGPU and they said yes 15:51:38 ... I don't know under which criteria a Web API should not be exposed to service workers 15:51:38 q+ 15:51:47 q? 15:52:06 ack jsbell 15:52:25 jsbell: makes sense to me, haven't looked at this deeply 15:52:36 -> https://www.w3.org/TR/design-principles/#expose-everywhere "When exposing a feature, please consider whether it makes sense to expose the feature to all possible environments (via the [Exposed=*] annotation or including it on all global scope interfaces)." "Only purely computational features should be exposed everywhere. That is, they do not 15:52:36 perform I/O and do not affect the state of the user agent or the user’s device." 15:52:43 ... an API for SW has to be async, because not sync APIs supported in that context 15:53:18 ... for SW there's no user visible surface, cannot support surfacing UI from SW 15:53:31 ... long compute this might be an issue, because SW are short-lived and browser can shut them down after some activity 15:53:47 ... if we do a graph build and it takes 30 seconds we should discuss with SW whether that is OK 15:53:49 q? 15:53:54 q+ 15:54:02 ack dom 15:54:35 dom: I put some guidance from TAG on this, "only purely computational APIs should be exposed everywhere" 15:54:56 ... no observable side-effects in WebNN, seems compliant 15:55:45 jsbell: shared worker use case, we get that from folks doing big web apps so can move logic to a worker so not getting taxed when multiple tabs from the same origin are open 15:56:39 q? 15:56:59 Topic: Community Group meeting scheduling poll 15:57:08 anssik: the Community Group has been rechartered and the group’s scope expanded to new incubations 15:57:14 -> Community Group Incubations https://webmachinelearning.github.io/incubations/ 15:57:16 s/compliant/compliant. This suggests we may need to consider even exposing everywhere, not just in serviceworker 15:57:25 ... to provide another venue for participants to exchanges ideas in addition to asynchronous collaboration through GitHub 15:57:43 ... we plan to restart the Community Group meetings 15:57:52 ... I asked interested CG participants to respond to the meeting scheduling poll by EOB 29 Jan 2025 to find a good time 15:57:56 ... thank you for your responses, the results are now in: 15:58:04 ... thank you for your responses, the results are now in: 15:58:09 s/... thank you for your responses, the results are now in:/ 15:58:12 s/... thank you for your responses, the results are now in:// 15:58:16 (sorry, ntd) 15:58:21 -> W3C WebML Community Group meeting poll https://doodle.com/meeting/participate/id/e5VrnyAa 15:58:25 ... the top 3 options are: 15:58:34 Option 1 (14 yes) 15:58:34 Tue 4-5 pm PST / Wed 00-01 am UTC / Wed 8-9 am CST / Wed 9-10 am JST 15:58:34 cannot attend: Rafael, Thomas, Christian, Maxim, Christine 15:58:50 Option 2 (13 yes, 1 if need be) 15:58:50 Wed 4-5 pm PST / Thu 00-01 am UTC / Thu 8-9 am CST / Thu 9-10 am JST 15:58:50 cannot attend: Sushanth, Thomas, Christian, Christine 15:58:50 if need be: Etienne 15:59:00 Option 3 (11 yes, 2 if need be) 15:59:00 Tue 2-3 pm PST / Tue 10-11 pm UTC / Wed 7-8 am CST / Wed 7-8 am JST 15:59:00 cannot attend: Brad, Thomas, Ningxin, Sungpil, Domenic, Maxim 15:59:00 if need be: Christian, Christine 16:00:27 s/(14 yes)/(14 yes, 1 if needs be) 16:02:11 anssik: I'd like to find a time that works for the editor Domenic 16:02:16 ... I've asked Etienne to help facilitate these meetings, so should the time fit him too 16:02:21 ... it looks like Option 1 is the best compromise 16:02:28 ... for consideration for people who cannot attend, meeting summary will be provided and discussed in the next WG meeting 16:02:36 ... I believe this setup will enable closer WG-CG collaboration across multiple timezones 16:03:43 RRSAgent, draft minutes 16:03:45 I have made the request to generate https://www.w3.org/2025/01/30-webmachinelearning-minutes.html anssik 16:04:48 s/developer!/developers! 16:05:19 Present+ Christine_Hollingsworth 16:05:53 s/instruction/instructions 16:07:26 s/editor can/editors can 16:07:47 s/we reviewed/be reviewed 16:11:50 s/doublecheck/double-check 16:14:56 s/not sync APIs/sync APIs are not 16:15:16 s/compute this/compute time 16:15:53 s/serviceworker/service worker 16:17:51 s/(13 yes, 1 if need be)/(14 yes, 1 if need be) 16:18:31 s/(11 yes, 2 if need be)/(12 yes, 2 if need be) 16:19:04 s/fit him too/should fit him too 16:19:34 RRSAgent, draft minutes 16:19:36 I have made the request to generate https://www.w3.org/2025/01/30-webmachinelearning-minutes.html anssik 16:25:55 s/so should the time should fit/so should choose the time that works for 16:25:57 RRSAgent, draft minutes 16:25:58 I have made the request to generate https://www.w3.org/2025/01/30-webmachinelearning-minutes.html anssik