14:57:53 RRSAgent has joined #webmachinelearning 14:57:57 logging to https://www.w3.org/2026/09/10-webmachinelearning-irc 14:57:59 RRSAgent, make logs Public 14:58:00 please title this meeting ("meeting: ..."), anssik 14:58:04 Meeting: WebML WG Teleconference – 10 September 2026 14:58:06 Chair: Anssi 14:58:12 Agenda: https://github.com/webmachinelearning/meetings/blob/main/telcons/2026-09-10-wg-agenda.md 14:58:19 Scribe: Anssi 14:58:31 scribeNick: anssik 14:58:43 Present+ Anssi_Kostiainen 14:59:00 RRSAgent, draft minutes 14:59:01 I have made the request to generate https://www.w3.org/2026/09/10-webmachinelearning-minutes.html anssik 15:00:13 mklimenko has joined #webmachinelearning 15:00:51 Present+ Bryan_Bernhart 15:01:02 Present+ Mike_Wyrzykowski 15:01:09 DwayneR has joined #webmachinelearning 15:01:18 Present+ Mikhail_Klimenko 15:01:23 Present+ Dwayne_Robinson 15:01:32 Present+ Ningxin_Hu 15:01:51 ningxin has joined #webmachinelearning 15:03:14 RRSAgent, draft minutes 15:03:15 I have made the request to generate https://www.w3.org/2026/09/10-webmachinelearning-minutes.html anssik 15:03:33 Anssi: welcome to Rattan Priya Bhasin from Microsoft joining us as a new participant since our last meeting 15:04:00 Topic: Web Neural Network API 15:04:05 gb, this is webmachinelearning/webnn 15:04:05 anssik, OK. 15:04:13 Mike_Wyrzykowski has joined #webmachinelearning 15:04:21 Subtopic: WebNN-WebGPU zero-copy device selection 15:04:31 Present+ Reilly_Grant 15:04:32 Anssi: PR #942 15:04:33 https://github.com/webmachinelearning/webnn/pull/942 -> PR 942 Add initial WebNN-WebGPU Interop specification (by bbernhar) [Agenda+] 15:04:53 Anssi: we discussed this spec PR last time and I called for final review with an expectation we'll merge the PR after any remaining comments are addressed 15:04:56 ... all comments are now marked a resolved 15:05:01 ... thank you Bryan for the PR updates and everyone for reviewing 15:05:31 ... the PR updates were the following during the review round: 15:05:32 Ali has joined #webmachinelearning 15:05:35 ... per MikeW's suggestion, acknowledged read-only storage use case for read-only WebGPU ops, to be added later, MikeW to open a new issue for this? 15:06:28 ... per Ningxin's suggestion, added explicit cross-timeline ordering, a note to describe what happens when a GPUDevice is lost (stays exported), and spec'd explicit failure path when export fails, by throwing an exception 15:07:11 ... Dwayne had comments and questions regarding naming and we landed on consensus that the current naming is appropriate given WebGPU nomenclature, we also agreed usage flags would be useful, to be discussed in a new issue, Dwayne to open? 15:07:41 Bryan: appreciate everyone's feedback and help on this PR 15:07:50 ... with that, we can resolve to merge this PR now 15:08:19 +1 15:08:30 Present+ Ali_Spivak 15:08:32 +1 15:08:39 RESOLUTION: Add initial WebNN-WebGPU interop support per PR #942 to WebNN API spec. 15:09:00 Anssi: next I'd like us to discuss v2 features 15:09:24 Anssi: zero-copy device selection for WebNN-WebGPU interop is issue #941 15:09:24 https://github.com/webmachinelearning/webnn/issues/941 -> Issue 941 WebNN/WebGPU zero-copy device selection (by bbernhar) [webgpu interop] [Agenda+] 15:10:13 Bryan: we discussed this issue with Reilly, while prototyping 15:10:45 ... API was not clear on how interop works in zero-copy situation, I proposed two options 15:11:48 ... Reilly prefers the createContext({ interopDevice: gpuDevice }) option over createContext(GPUDevice) overload 15:12:28 Reilly: the idea is that depending on architecture GPU devices may interop as non-GPU devices, we should separately talk about interop device and power and performance 15:12:54 ... interop device and power and performance are related, but we don't have to make GPU specific createContext 15:12:54 q? 15:12:56 q+ 15:13:01 ack ningxin 15:13:45 Ningxin: questions related to the PR, new createExportableTensor, that interface also takes GPUDevice, I'd like to understand how these two GPUDevices are related? 15:14:19 Bryan: it's the source and destination device, when exporting a tensor, that's the destination, source device could be NPU, or the same GPU in which case could do zero-copy 15:14:37 ... could be a different device and behind the scenes would do zero-copy 15:14:53 ... we spec'd this like this because the tensor is created differently depending on the device for compatibility's sake 15:14:54 q? 15:15:24 MikeW: I will take a look at the proposal 15:15:36 q? 15:16:30 Anssi: next v2 feature proposal is read-only storage use case for read-only WebGPU ops 15:17:10 MikeW: I created and issue for this, real-only is possible today already, but perhaps you want to use exportedMLTensor as an indirect buffer 15:17:28 https://github.com/webmachinelearning/webnn/issues/954 15:17:29 https://github.com/webmachinelearning/webnn/issues/954 -> Issue 954 MLTensor export to GPUBuffer with custom usages? (by mwyrzykowski) 15:18:01 q? 15:18:37 Bryan has joined #webmachinelearning 15:18:59 Anssi: another v2 feature proposal is usage flags for createExportableTensor from Dwayne 15:19:09 ... Dwayne, do you want to introduce the usage flags idea? 15:19:31 Dwayne: I don't have a list of flags that would be applicable right now, will create an issue for this 15:19:31 q? 15:20:09 -> https://github.com/webmachinelearning/webnn/pull/942#discussion_r3929230261 15:20:10 https://github.com/webmachinelearning/webnn/pull/942 -> PR 942 Add initial WebNN-WebGPU Interop specification (by bbernhar) [Agenda+] 15:21:26 Bryan: flags feel related to MikeW's proposal in issue #954, we need to explicitly pass WebGPU flags and see how they correspond, good symmetry between the two 15:21:27 https://github.com/webmachinelearning/webnn/issues/954 -> Issue 954 MLTensor export to GPUBuffer with custom usages? (by mwyrzykowski) [webgpu interop] 15:21:27 q? 15:22:28 Subtopic: Accuracy for reductions 15:22:33 Anssi: issue #947 15:22:34 https://github.com/webmachinelearning/webnn/issues/947 -> Issue 947 reduceLogSumExp reference decomposition contradicts conformance test; accuracy requirements missing (by mtavenrath) [Agenda+] 15:22:47 Anssi: MarkusT notes accuracy for reductions is generally underspecified 15:23:02 ... I'd like the group to review the proposed fix for reduceLogSumExp 15:23:05 ... and second, agree on general guidelines for other reductions 15:23:53 Mikhail: there's diversion between spec and what happens on real HW, we can fix this either by fixing WPT tests so they represent reality, not really looking into this 15:24:19 ... second option is to modify reference decomposition in the spec, prototyped in RustNN and it works fine, propose we go with option (b) 15:24:40 Anssi: proposed fix to "replace the reference decomposition with the numerically stable formulation" 15:25:41 Dwayne: just adding this improved decomposition used in frameworks 15:25:44 q+ 15:25:52 s/used/is used 15:26:57 Reilly: the reference decomposition in the are not reference implementations to be mandated 15:27:49 ... very often the spec does not specify exact algorithms 15:27:50 q? 15:28:04 ack reillyg 15:28:56 Anssi: what do we want to do with other reductions? 15:29:37 Dwayne: others may not have more accurate representations 15:30:01 Anssi: no need to adjust other reduction decompositions then 15:30:33 +1 15:30:39 +1 15:30:45 RESOLUTION: Update the spec to use numerically more stable reduceLogSumExp decomposition. (issue #947) 15:31:23 Yes, he's from Google's LiteRT team. 15:31:35 Subtopic: Subgraphs 15:31:39 Anssi: issue #907 15:31:39 https://github.com/webmachinelearning/webnn/issues/907 -> Issue 907 Composite operators / subgraphs (by fdwr) [opset] [Agenda+] 15:31:46 ... we've received new feedback for this issue since we touched this last time, that was also a while ago 15:31:56 Changming used to be on ONNX Runtime. 15:32:40 Anssi: to recap, this issue is exploring how to allow WebNN express "big ops" (attention, gelu, RMSNorm) as composite operators aka subgraphs 15:32:49 ... the recent feedback on GH from snnn seems to argue the proposed design wouldn't work for LLMs 15:33:23 ... MarkusT commented that he disagrees with that assessment and gives an example of GroupQueryAttention experiment by Ningxin that demonstrated clear performance benefits 15:34:16 ... MarkusT suggests a standardized subgraph construction API (option C) would provide the best path forward to avoid fragile pattern matching approaches, avoid scope creep and minimize maintenance burden, and enable maximum performance 15:34:34 Anssi: do we need more performance data on how the proposed subgraph API would perform with LLMs? 15:34:44 q? 15:35:38 q+ 15:35:43 ack ningxin 15:36:32 Ningxin: I want to share two aspects, we should look at GenAI and LLM trends, we delivered good GenAI model support with Transformer ops 15:37:05 ... no we see some challenges with new LLMs, e.g. attention for flow control 15:38:12 ... llama.cpp has a few ops and get good performance, Joshua published well-optimized WebGPU kernels recently, should look into these efforts 15:39:40 q+ 15:39:41 ... did some experiments, but received some pushback that pattern matching is complex, should consider some ahead-of-time to reduce complexity imposed on framework authors 15:39:44 ack reillyg 15:40:43 Reilly: I generally agree with MarkusT's comment, Chungming's observation is also correct, however custom kernels cannot be done inside WebNN 15:41:01 ... what we can express is grouped graph nodes and given them to the underlying implementations 15:41:02 q? 15:41:46 MikeW: I'll look at this issue 15:41:53 Mike_Wyrzykowski has joined #webmachinelearning 15:43:13 Dwayne: experiments that Ningxin did helped, not sure we need more of that, would like to see the shape of the possible new subgraph API 15:44:13 +1 15:45:49 +1 15:45:50 q+ 15:45:54 ack ningxin 15:45:58 q+ 15:47:18 Ningxin: I think the subgraph API drafting is good approach, also example usages would be good complement, we did example decomposition experiment, could provide some decomposition in current form using JS pseudocode, to share one GQA example, so we can exercise the new graph API 15:47:59 +1 15:48:03 +1 15:48:05 -q 15:48:13 RESOLUTION: Draft a subgraph API proposal and JS usage example code for group review and feedback. (issue #907) 15:48:58 Subtopic: Full-sequence output validation 15:49:02 Anssi: issue #949 15:49:03 https://github.com/webmachinelearning/webnn/issues/949 -> Issue 949 Validate LSTM/GRU full-sequence output regardless of the `returnSequence` flag (by shiyi9801) [security-tracker] [Agenda+] 15:49:12 Anssi: the group puts high priority in resolving any security related issues, and the last three are particularly relevant in this context 15:49:17 ... I labeled this issue with [security-tracker] to keep track of security related issues we've discussed in the WG and their mitigations 15:49:47 ... many mitigations happen at the implementation level, but where applicable, we mitigate at the spec level and/or provide guidance for implementers to allow all implementations benefit from the latest security best practices 15:49:59 ... Shiyi reports certain backends allocate the full-sequence output tensor internally regardless of the returnSequence flag, but do not validate the size 15:50:24 ... this might cause an out-of-bounds write 15:50:30 ... proposed fix is to always validate the full-sequence output descriptor so that oversized shapes are rejected before reaching the backend 15:50:38 ... does the group have any concerns for adding this fix to the spec? 15:50:52 ... Chromium implementation experience validates this approach in practice 15:51:14 ... next step would be to create a spec PR with the proposed fix to align with that 15:51:22 ... and I believe we also want to update WPT tests to validate the fix 15:52:00 q? 15:52:02 q+ 15:52:07 ack reillyg 15:53:00 Reilly: I'm curious from other implementers, to provide more context, this is a case where implementing a security mitigation changes so that web developers can observe the mitigation is in place 15:54:22 +1 15:54:25 +1 15:54:37 +! 15:54:44 RESOLUTION: Validate LSTM/GRU full-sequence output descriptor to mitigate OOB writes, prepare a spec PR for review. (issue #949) 15:54:57 Subtopic: Formulaic mitigation for integer overflows 15:55:06 Anssi: issue #928 15:55:06 https://github.com/webmachinelearning/webnn/issues/928 -> Issue 928 Consider specify lower limit for conv2d/pool2d kernel sizes, dilations, strides (by philloooo) [security-tracker] [Agenda+] 15:55:23 ... for this issue, we resolved to extend opSupportLimits() to be able to express limits on the size of inputs 15:55:53 ... recently we received implementation experience from Chromium for mitigation that rejects conv2d/pool2d/convTranspose2d strides, dilations and filters that exceed the usable extent: 15:55:59 -> https://chromium-review.googlesource.com/c/chromium/src/+/8250961 15:56:05 Anssi: we also landed corresponding WPT updates: 15:56:09 https://github.com/web-platform-tests/wpt/pull/62066 15:56:10 https://github.com/web-platform-tests/wpt/pull/62066 -> MERGED PR 62066 [WebNN] Reject conv2d/pool2d/convTranspose2d strides, dilations and filters that exceed the usable extent (by chromium-wpt-export-bot) [chromium-export] [webnn] [wg-s_webmachinelearning] 15:56:28 Anssi: what remains is to update the spec to reflect these limits and ensure all implementations adhere to them 15:56:50 q+ 15:56:55 ack reillyg 15:57:29 Reilly: this one is interesting, a case where an op is well defined, but with a very large value we can wrap around 15:57:46 ... the proposal is to make passing these large values invalid, so the developer needs to pass smaller values 15:58:05 ... this allow WebNN implementation to have more control over values to be passed to underlying framework 15:58:28 ... WebNN could do some of this conversion by itself 15:58:28 q? 15:59:45 Dwayne: do we have clear limits? 16:00:11 ... instead of having hard coded limits prefer to have relational limits 16:00:26 q+ 16:00:39 ack reillyg 16:00:55 Reilly: I agree with Dwayne, proposal we've made have run into this issue 16:02:26 q+ 16:02:31 ack ningxin 16:04:02 Ningxin: rather than propose the limit, can we propose algorithmic steps to compute the tensor/buffer size, would this be an alternative way to address this? 16:04:40 Dwayne: that would be more robust and would address my concern 16:05:23 Ningxin: I will provide my suggestion in the issue 16:05:38 q? 16:06:00 RRSAgent, draft minutes 16:06:01 I have made the request to generate https://www.w3.org/2026/09/10-webmachinelearning-minutes.html anssik 16:07:26 s/a resolved/as resolved 16:13:55 s/decomposition in the are/decompositions in the spec are 16:14:22 s/others may/other reductions may 16:16:02 s/snnn/Changming 16:16:46 s/no we see/now we see 16:17:04 s/get good/gets good 16:17:56 s/ahead-of-time/ahead-of-time optimization 16:18:34 s/Chungming's/Changming's 16:18:52 s/given them/give them 16:22:15 s/labeled this issue/labeled these issues 16:26:15 RRSAgent, draft minutes 16:26:16 I have made the request to generate https://www.w3.org/2026/09/10-webmachinelearning-minutes.html anssik 18:31:48 Zakim has left #webmachinelearning