14:57:16 RRSAgent has joined #webmachinelearning 14:57:20 logging to https://www.w3.org/2025/06/05-webmachinelearning-irc 14:57:20 RRSAgent, make logs Public 14:57:21 please title this meeting ("meeting: ..."), anssik 14:57:21 Meeting: WebML WG Teleconference – 5 June 2025 14:57:26 Chair: Anssi 14:57:30 Agenda: https://github.com/webmachinelearning/meetings/blob/main/telcons/2025-06-05-wg-agenda.md 14:57:36 Scribe: Anssi 14:57:42 scribeNick: anssik 14:57:51 gb, this is webmachinelearning/webnn 14:57:51 anssik, OK. 14:58:17 Present+ Anssi_Kostiainen 14:58:22 RafaelCintron has joined #webmachinelearning 14:58:23 Present+ Zoltan_Kis 14:58:53 Present+ Rafael_Cintron 14:59:05 Mike_Wyrzykowski has joined #webmachinelearning 14:59:05 Present+ Dwayne_Robinson 14:59:17 Present+ Mike_Wyrzykowski 14:59:34 zkis has joined #webmachinelearning 14:59:46 RRSAgent, draft minutes 14:59:47 I have made the request to generate https://www.w3.org/2025/06/05-webmachinelearning-minutes.html anssik 15:00:43 DwayneR has joined #webmachinelearning 15:01:34 Present+ Ningxin_Hu 15:02:12 Present+ Brad_Triebwasser 15:02:27 ningxin has joined #webmachinelearning 15:02:55 anssik: please welcome Sun Shin from NVIDIA to the WebML WG! 15:03:16 Present+ Markus_Handell 15:03:32 Present+ Ehsan_Toreini 15:04:14 anssik: also, please welcome Thomas Beverley and Rhys Jones from AxonZeta to the WebML CG! 15:04:37 ... Tom and Rhys have developed AiBrow browser extension that implements the built-in AI APIs defined in the CG and have also extends it with new advanced features 15:04:52 Topic: Incubations 15:05:04 anssik: the WebML Community Group met at EU-APAC friendly time on Mon 26 May 2025 15:05:08 -> https://github.com/webmachinelearning/meetings/blob/main/telcons/2025-05-26-cg-agenda.md 15:05:12 -> https://github.com/webmachinelearning/meetings/blob/main/telcons/2025-05-26-cg-minutes.md 15:05:30 anssik: Tom and Rhys joined us to share their implementation experience from AiBrow browser extension 15:05:41 ...this new implementation of the built-in AI APIs extends the Prompt API with e.g.: 15:05:44 handellm has joined #webmachinelearning 15:05:47 -> custom models https://docs.aibrow.ai/examples/using-different-models 15:05:51 -> embedding API https://docs.aibrow.ai/examples/embedding-api 15:06:22 anssik: notably AiBrow aligns with Mozilla's extension-based API proposal with its support for custom models 15:06:33 ... I expect to see future work in the CG around custom models given multiple implementations 15:06:55 anssik: WebML CG also adopted the Proofreader API, and this spec is now open for wider community contributions 15:07:13 -> https://github.com/webmachinelearning/proofreader-api 15:07:27 ... we reviewed Prompt API security and privacy considerations, noting a lot is shared across built-in AI APIs 15:07:37 ... the shared parts are now parked in the Writing Assistance APIs spec and cross-referenced from elsewhere 15:07:49 ... interested folks should definitely review these considerations, TAG feedback has been incorporated already 15:07:54 -> https://webmachinelearning.github.io/writing-assistance-apis/#privacy 15:07:59 -> https://webmachinelearning.github.io/writing-assistance-apis/#security 15:08:15 Ehsan has joined #webmachinelearning 15:08:57 Topic: Operator specific issues 15:09:02 -> [operator specific] issues https://github.com/webmachinelearning/webnn/labels/operator%20specific 15:09:21 Subtopic: The minimum data type set, web-platform-tests updates 15:09:26 anssik: issue #853 15:09:27 https://github.com/webmachinelearning/webnn/issues/853 -> Issue 853 The minimum data type set (by huningxin) [operator specific] 15:09:39 ... this issue is a follow-up from TPAC 2024 and our previous telcon: 15:09:44 -> TPAC 2024 https://www.w3.org/2024/09/23-webmachinelearning-minutes.html#b5cc 15:09:48 -> 2025-05-22 telcon https://www.w3.org/2025/05/22-webmachinelearning-minutes.html#b53b 15:10:14 anssik: Ningxin documented his finding from the minimum data type set implementable across all Chromium backends DirectML, TFLite and Core ML (thanks!) 15:10:39 Ningxin: promising results, all ops have data type overlap except two ops 15:10:46 ... I shared JSON output with details 15:11:10 ... - l2Pool2d: it is not implemented in TFLite backend yet 15:11:45 ... - sign: it is not implemented the CoreML backend yet 15:12:46 ... for other ops, if you expand the table, I shared the intersection for opSupportLimits() 15:14:32 anssik: Reilly proposed changes to w-p-t 15:14:36 ... make tests for the intersecting opSupportLimits mandatory 15:14:40 ... others skip automatically if not supported 15:14:57 ningxin: Bruce is working on wpt, starting with logical operators 15:15:04 Joshua_Lochner has joined #webmachinelearning 15:15:44 ... graph level has no uint in Core ML, we're changing wpt for logical operators to adapt to this graph level output 15:16:01 ... for this logical operator we will cast uint8 15:16:11 Present+ Joshua_Lochner 15:16:37 ningxin: in the future we try to manage the test cases with minimal data type tests as mandatory and others will be made detectable 15:17:08 q? 15:17:25 Subtopic: layerNormalization, Core ML question/clarification 15:17:30 anssik: issue #748 15:17:30 https://github.com/webmachinelearning/webnn/issues/748 -> Issue 748 Is there a reason to support out of order `axes` for layerNormalization? (by philloooo) [question] [operator specific] 15:17:50 anssik: with MikeW around 15:18:02 ... I'd like to see if we can clarify layerNormalization axes Core ML behaviour 15:18:06 ... specifically whether "out of order" means nonincreasing or noncontiguous? 15:18:40 Dwayne: the question is whether Core ML sorts the axes? 15:18:43 q+ 15:18:47 ack Mike_Wyrzykowski 15:19:05 MikeW: generally, if we can repro, it helps expedite 15:19:19 Dwayne: I will provide a snippet and tag MikeW in the comments 15:19:36 Subtopic: triangular 15:19:42 anssik: issue #768 15:19:43 https://github.com/webmachinelearning/webnn/issues/768 -> Issue 768 Consider removing or redesigning the `triangular` operator (by a-sully) [operator specific] 15:19:52 ... based on our previous discussion the consensus seems to be we keep this op? 15:19:56 -> 2025-05-22 minutes https://www.w3.org/2025/05/22-webmachinelearning-minutes.html#a3b5 15:20:02 anssik: confirming we have consensus to keep this, any concerns or question? 15:20:46 [ MikeW and Dwayne thumbs up ] 15:20:58 anssik: we have an agreement to keep triangular, the editors can close this issue 15:21:02 +1 15:21:20 Topic: Other issues and PRs 15:21:25 anssik: I want to acknowledge a few issue with PRs that welcome review and feedback 15:21:31 Subtopic: isNaN and isInfinite operators 15:21:35 anssik: issue #811 and PR #858 15:21:36 https://github.com/webmachinelearning/webnn/pull/858 -> Pull Request 858 Add `isNaN` and `isInfinite` operators (by fdwr) 15:21:36 https://github.com/webmachinelearning/webnn/issues/811 -> Issue 811 Behavior when there are NaNs in argmin/max inputs (by philloooo) [interop] 15:22:01 anssik: we made a group decision to add isNaN op and we now have PR for isNaN and isInfinite (thanks Dwayne!) 15:22:05 ... the IDL change is as follows: 15:22:12 ``` 15:22:12 partial interface MLGraphBuilder 15:22:12 { 15:22:12 ... 15:22:12 + MLOperand isNaN(MLOperand a, optional MLOperatorOptions options = {}) 15:22:12 + MLOperand isInfinite(MLOperand a, optional MLOperatorOptions options = {}) 15:22:12 ... 15:22:12 }; 15:22:13 ``` 15:22:33 anssik: see the PR for rationale to include both together, mappings to backend functions, some questions 15:22:57 Dwayne: questions are Q&A for the audience 15:23:14 Subtopic: roundEven operator 15:23:19 anssik: issue #817 and PR #859 15:23:19 https://github.com/webmachinelearning/webnn/pull/859 -> Pull Request 859 Add `roundEven` operator (by fdwr) 15:23:19 https://github.com/webmachinelearning/webnn/issues/817 -> Issue 817 Rounding operators (by fdwr) [feature request] [interop] 15:23:32 ... another PR from Dwayne (thanks!!) per our discussion on rounding operators 15:23:40 ``` 15:23:40 partial interface MLGraphBuilder 15:23:40 { 15:23:40 ... 15:23:40 + MLOperand roundEven(MLOperand input, optional MLOperatorOptions options = {}); 15:23:40 ... 15:23:40 }; 15:23:41 ``` 15:24:30 Dwayne: Core ML does not have direct mapping but can compose it with two ops 15:24:38 MikeW: I just approved this PR 15:24:48 q? 15:25:05 Topic: Wide review 15:25:11 anssik: we have received new wide review feedback 15:25:35 ... i18n is completed, TAG/Architecture, a11y & Privacy await feedback integration, only Security has no review feedback yet 15:25:39 -> https://github.com/w3ctag/design-reviews/issues/1072#issuecomment-2941185185 15:25:39 https://github.com/w3ctag/design-reviews/issues/1072 -> CLOSED Issue 1072 Updated review of Web Neural Network API (by anssiko) [Topic: Design Principles] [Resolution: satisfied with concerns] [Topic: Machine Learning] 15:25:44 Subtopic: Accessibility 15:26:05 anssik: a11y review focused on ensuring use cases consider accessibility 15:26:12 -> https://github.com/w3c/apa/issues/350#issuecomment-2940147416 15:26:13 https://github.com/w3c/apa/issues/350 -> Issue 350 WebNN Review (APA thread) (by matatk) 15:26:19 ... I volunteered to integrate their feedback, but a11y reviewers wanted to open an issue and/or submit a PR themselves which we can then review, appreciate that 15:26:41 q? 15:26:53 Subtopic: Architecture/TAG 15:27:09 anssik: TAG review was completed with a resolution: "The TAG is satisfied with this work overall but requires changes" 15:27:13 -> https://github.com/w3ctag/design-reviews/issues/1072#issuecomment-2941185185 15:27:26 anssik: the trend is good, the previous TAG review was resolved with "satisfied with concerns" 15:27:30 anssik: I'll break down the TAG review feedback: 15:27:42 ... first, we asked TAG for advice on naming lowercase 2d vs uppercase 2D 15:27:46 > TAG: On operator naming, "2D" is an initialism (for "2 Dimensional" or similar), and so the guidance in https://w3ctag.github.io/design-principles/#casing-rules says that it should be "All caps, except when the first word in a method or property". 15:28:04 anssik: issue #821 is for this naming consideration 15:28:05 https://github.com/webmachinelearning/webnn/issues/821 -> Issue 821 Operator naming 2D vs 2d (by fdwr) [conventions] 15:28:19 anssik: TAG points us back to the Design Principles, since we felt that doc was not explicit in this case it is up to us to decide 15:28:41 ... to help us make an informed decision, I added some data to the issue with diffs of various options we've considered 15:28:48 -> diff of naming options https://github.com/webmachinelearning/webnn/issues/821#issuecomment-2943722033 15:28:49 https://github.com/webmachinelearning/webnn/issues/821 -> Issue 821 Operator naming 2D vs 2d (by fdwr) [conventions] 15:29:17 ... it looks like going all uppercase D would introduce a lot of breaking changes to the API surface 15:29:22 ... would this be too big a breaking change at this stage? 15:29:49 ... renaming gatherNd and scatterNd to lowercase "Nd" would keep us consistent within this spec, be a smaller breaking change 15:30:15 ... I note naming is not always consistent across all the Web APIs for historical reasons 15:30:58 ... if we diverge, we could note in the specification it uses a domain-specific naming convention for a reason X to not surprise web authors and to also warn other API authors to not copy the naming convention blindly without consideration 15:30:59 q? 15:31:29 q+ 15:31:38 ack zkis 15:32:35 zkis: I see a comment from Josh re WebGL alignment 15:32:39 q+ 15:32:58 ack DwayneR 15:33:17 Dwayne: given the precedence of uppercase, prefer consistency 15:33:24 +1 15:33:26 q+ 15:33:41 ... if WebNN is not used directly, then we need to update ORT and samples 15:33:44 q? 15:33:49 ack Mike_Wyrzykowski 15:34:38 MikeW: I suppose we could do deprecation for old names to gracefully migrate 15:34:58 Dwayne: we could do that adding an alias 15:35:47 ningxin: probably we can assess the compatibility impact and leave the issue open for collecting that feedback 15:36:53 Dwayne: a lot of ML APIs use snake case due to Python 15:37:45 q? 15:37:56 >TAG: We would appreciate if the WG would evaluate the likely impacts on sustainability from introducing this API, perhaps in collaboration with the Sustainable Web IG. There are several competing likely effects, including the comparative energy efficiency of personal devices vs datacenters, the greater efficiency of WebNN over WebGPU for the same workload, increased use of neural nets as they get easier to access, faster device 15:37:56 obsolescence if older devices can't effectively run the workloads this API encourages, and likely other considerations. Any sustainability impacts might be balanced by increased utility and privacy, but it would be good to know what we're signing up for. 15:38:46 anssik: purpose-built ML accelerators aka NPUs are generally known to be more power-efficient than GPUs 15:38:51 ... other considerations to respond to the sustainability question? 15:39:30 zkis: we could include sustainability aspects in the device selection explainer 15:39:30 q+ 15:39:35 ack RafaelCintron 15:40:43 Rafael: as far as sustainability, WebNN does better because it can use NPU and can use it together with CPU and GPU 15:41:33 -> https://github.com/mozilla/standards-positions/issues/1215 15:41:33 -> https://github.com/WebKit/standards-positions/issues/486 15:41:33 https://github.com/mozilla/standards-positions/issues/1215 -> Issue 1215 Web Neural Network API (by iampi31415) 15:41:33 https://github.com/WebKit/standards-positions/issues/486 -> Issue 486 Web Neural Network API (by iampi31415) 15:41:52 >TAG: We endorse the concerns that Chrome expressed in webmachinelearning/webnn#453, that WebNN is a proposal that browsers implement a compilation and optimization engine for yet another high level language, on top of the Javascript, Wasm, and WebGPU engines that we've already signed up for. WebNN might be worth doing, but it's a relatively high cost, and we'd like some evidence that it's going to pay off. 15:41:52 https://github.com/webmachinelearning/webnn/issues/453 -> CLOSED Issue 453 Google Chrome Feedback on WebNN: aiming for broad device coverage and maintainability (by vsekhar) [process] [opset] [use case] 15:42:18 anssik: #453 was closed as completed, I think we should make sure the explainer clarifies the relationship with Wasm, WebGPU 15:42:19 https://github.com/webmachinelearning/webnn/issues/453 -> CLOSED Issue 453 Google Chrome Feedback on WebNN: aiming for broad device coverage and maintainability (by vsekhar) [process] [opset] [use case] 15:42:29 ... we have a section where we explicitly talk about WebGL/GPU relationship 15:42:33 -> https://github.com/webmachinelearning/webnn/blob/main/explainer.md#stay-the-course-and-build-machine-learning-solutions-on-webglwebgpu 15:42:49 anssik: we could similarly talk about Wasm vs WebNN, what would be the key message to highlight? 15:43:16 q? 15:43:20 q+ 15:43:41 anssik: overall, TAG is happy and closed the review, an action on the group is to report back 15:43:46 ... TAG also shared they like the Ethical Principles for Web Machine Learning effort 15:43:55 Subtopic: Internationalisation 15:44:00 anssik: the i18n review has been completed and all feedback addressed by PR #851 15:44:00 https://github.com/webmachinelearning/webnn/pull/851 -> MERGED Pull Request 851 Note Unicode sequences in Security Considerations (by anssiko) 15:44:07 Subtopic: Privacy 15:44:20 anssik: Privacy WG reviewed the WebNN API at their latest meeting, all the feedback was about the opSupportLimits() API future-proofness 15:44:42 ... the ask was to ensure opSupportLimits() design is compatible with a future where there may no longer be 1:1 correlation between the OS/browser version and the support per operator 15:44:50 ... I responded to their questions and we're awaiting their response 15:45:09 Subtopic: Security 15:45:29 anssik: no security review feedback received yet, if there's any recent input from the Chromium security reviewers, please let me know 15:46:15 Rafael: TAG feedback about new language, it is not a new language it is a new JS API and unlocks new devices that cannot be reached from Wasm and WebGPU 15:46:37 ... they say, maybe the payoff is not worth it, that's why we do an OT and put it in front of developers to test 15:47:19 q? 15:47:31 ack RafaelCintron 15:48:52 Topic: Query supported devices 15:49:31 anssik: we split this issue in two: "before graph compilation" and "after graph compilation" 15:49:48 ... first, I think we all agree we want to document the motivating use cases in the explainer, be use case driven in our API design 15:50:21 ... we have the first stab at the "before graph compilation" use cases in the explainer that maps use cases to possible device selection preferences 15:50:30 anssik: we should similarly document use cases for "after graph compilation" 15:50:44 Subtopic: After graph compilation (MLGraph.devices) 15:50:50 anssik: issue #836 and PR #854 15:50:51 https://github.com/webmachinelearning/webnn/pull/854 -> Pull Request 854 define graph.devices (by philloooo) 15:50:51 https://github.com/webmachinelearning/webnn/issues/836 -> Issue 836 Get devices used for a graph after graph compilation (by philloooo) [device selection] 15:51:06 ... Phillis implemented the MLGraph.devices API in Chromium (thanks!) across Core ML, DirectML and TFLite backends 15:51:26 ... I'd like to first discuss the implementation experience 15:51:42 q+ 15:51:46 ack RafaelCintron 15:51:59 Rafael: I have reviewed the proposal and Mike has provided feedback 15:52:31 ... I tend to agree with the feedback, one concern I have is web developers get an impression that NPUs are always slowed and better for battery life and make decisions based on that 15:52:57 ... can make sense on some platforms, while on some platforms NPU may be better than GPU on some other platforms 15:53:02 q+ 15:53:15 q+ 15:53:22 q- 15:53:26 q? 15:53:48 ack handellm 15:53:51 q+ 15:54:14 Markus: I can understand people might jump to premature conclusions when they see NPU supported or not 15:54:27 q+ 15:54:59 ... generally I'd jump to a conclusion using hardware is faster and more power efficient, for my use case I'd say if I see CPU offered without NPU and GPU, I'd consider it won't run our use case real time 15:55:16 ... this would cause an UX glitch visible to the users 15:55:32 ... is it possible to rank the devices with estimated execution speed 15:56:19 ... can we figure out if something is able to run in less than 35 ms 15:56:21 q? 15:56:27 ack zkis 15:57:22 zkis: I want to say I'm trying to document the use cases based on feedback in this issue, I see NPU is not considered the main use case, trying to figure out if WebNN supports running the graph on GPU, before and after model building 15:57:46 ... use case seemsto be can the app use WebNN or not 15:57:59 q? 15:58:02 ack RafaelCintron 15:58:37 Rafael: would it be better if we maybe return "hardware-accelerated" or "not-hardware accelerated"? 15:58:50 ... w/o acceleration, could use a fallback path 15:59:35 ... in graphics APIs, sometimes running in software mode is okay as a fallback 15:59:44 q? 16:00:18 ... Ningxin asked about Windows ML implementability 16:00:23 q+ 16:00:26 ack ningxin 16:01:26 Rafael: we can explore the Windows ML path, DirectML can only pick one device 16:01:57 ningxin: we could look at the native space, this capability is supported across Core ML, DML, TFLite, what's the use case for native apps? 16:02:08 q+ 16:02:11 ack handellm 16:02:43 Markus: wanted to ask MikeW, you commented you never know what device is used by Core ML? 16:02:48 MikeW: we can ask, a change might take a long time 16:03:01 q? 16:03:26 Subtopic: Before graph compilation 16:03:34 anssik: issue #815 16:03:34 https://github.com/webmachinelearning/webnn/issues/815 -> Issue 815 Query supported devices before graph compilation (by anssiko) [device selection] 16:03:48 anssik: at our previous meetings we discussed various device selection hints (names in quotes are placeholders): 16:03:54 ... "prefer CPU", "prefer NPU", "prefer GPU", "maximum performance", "maximum efficiency", "minimum overall power" 16:04:28 ... to help move this feature forward, I crafted a use case PR #855 based on our meeting discussion that maps the considered device selection hints to use cases 16:04:29 https://github.com/webmachinelearning/webnn/pull/855 -> MERGED Pull Request 855 Add device preference use cases to explainer (by anssiko) 16:04:59 ... (this PR was also an experiment on how coding agents could work in the spec authoring space) 16:05:09 ... feedback thse use cases welcome 16:05:16 s/thse/the 16:05:20 -> Device Preference Use Cases https://github.com/webmachinelearning/webnn/blob/main/device-selection-explainer.md#device-preference-use-cases 16:06:05 zkis: we are in mapping phase in map-reduce, need to continue this work 16:06:18 q? 16:06:44 RRSAgent, draft minutes 16:06:45 I have made the request to generate https://www.w3.org/2025/06/05-webmachinelearning-minutes.html anssik 16:10:44 Regrets+ Tarek_Ziade 16:14:58 s/slowed/slower than GPUs 16:15:27 s/while on some /while on some other 16:15:44 s/GPU on some other platforms/GPU 16:19:00 s/we can ask/we could propose this new feature for Core ML 16:19:38 s/feedback the/feedback on the 16:20:00 RRSAgent, draft minutes 16:20:02 I have made the request to generate https://www.w3.org/2025/06/05-webmachinelearning-minutes.html anssik 18:29:32 Zakim has left #webmachinelearning