14:59:17 <RRSAgent> RRSAgent has joined #webmachinelearning
14:59:21 <RRSAgent> logging to https://www.w3.org/2026/03/12-webmachinelearning-irc
14:59:21 <Zakim> RRSAgent, make logs Public
14:59:22 <Zakim> please title this meeting ("meeting: ..."), anssik
14:59:26 <anssik> Meeting: WebML WG Teleconference – 12 March 2026
14:59:26 <anssik> Chair: Anssi
14:59:31 <anssik> Agenda: https://github.com/webmachinelearning/meetings/blob/main/telcons/2026-03-12-wg-agenda.md
14:59:38 <anssik> Scribe: Anssi
14:59:42 <anssik> scribeNick: anssik
14:59:58 <anssik> Present+ Anssi_Kostiainen
14:59:59 <anssik> RRSAgent, draft minutes
15:00:01 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/12-webmachinelearning-minutes.html anssik
15:01:42 <Ehsan> Ehsan has joined #webmachinelearning
15:02:51 <RafaelCintron> RafaelCintron has joined #webmachinelearning
15:03:01 <Mike_Wyrzykowski> Mike_Wyrzykowski has joined #webmachinelearning
15:03:32 <ningxin> ningxin has joined #webmachinelearning
15:03:56 <handellm> handellm has joined #webmachinelearning
15:04:21 <BenGreenstein> BenGreenstein has joined #webmachinelearning
15:04:27 <anssik> Anssi: please welcome the new participants who joined the WG:
15:04:34 <anssik> ... Christopher Hebert from NVIDIA
15:04:40 <anssik> ... Ninja.zx Zhangxiao from ByteDance
15:04:45 <anssik> ... Jaewon Lee from Google
15:04:48 <anssik> ... welcome all!
15:05:02 <zolkis> zolkis has joined #webmachinelearning
15:05:04 <anssik> Topic: Incubations
15:05:20 <anssik> Subtopic: Dynamic AI Offloading Protocol
15:05:23 <anssik> gb, this is webmachinelearning/daop
15:05:23 <gb> anssik, OK.
15:05:43 <anssik> Anssi: PR #1
15:05:43 <gb> https://github.com/webmachinelearning/daop/pull/1 -> Pull Request 1 Add DAOP explainer and estimateQoS() illustration with background blur demo (by jonathanding)
15:05:59 <anssik> Anssi: today, we will review and approve the initial PR as the baseline for further incubation
15:06:03 <anssik> ... to recap the timeline:
15:06:10 <anssik> ... in January, the group resolved to create an explainer for the Dynamic AI Offloading Protocol (DAOP) and initiate prototyping:
15:06:14 <anssik> -> 2026-01-15 resolution https://www.w3.org/2026/01/15-webmachinelearning-minutes.html#89af
15:06:18 <anssik> Anssi: in February, Jonathan delivered an explainer and a prototype and the group reviewed the proposal
15:06:18 <mtavenrath> mtavenrath has joined #webmachinelearning
15:06:21 <anssik> -> 2026-02-12 review feedback https://www.w3.org/2026/02/12-webmachinelearning-minutes.html#1e1f
15:06:36 <anssik> ... today, the proposed next step is to approve to merge the initial PR to allow further incubation of this proposal in the WebML CG
15:07:13 <anssik> ... the WebML WG will review the progress of this CG incubation from time to time and will separately from today's decision resolve whether to adopt the feature into the WebNN spec after adequate incubation period
15:07:25 <anssik> Anssi: any comments or questions?
15:08:33 <Mike_Wyrzykowski> +1
15:08:53 <ningxin> +1
15:09:01 <zolkis> +1
15:09:03 <anssik> RESOLUTION: Approve the initial Dynamic AI Offloading Protocol (DAOP) PR as the baseline for further incubation in the WebML CG.
15:09:21 <anssik> Subtopic: WebNN Graph DSL and Portable File Format
15:09:33 <anssik> gb, this is webmachinelearning/proposals
15:09:33 <gb> anssik, OK.
15:09:49 <anssik> Anssi: issue #16
15:09:50 <gb> https://github.com/webmachinelearning/proposals/issues/16 -> Issue 16 Standardize a WebNN Graph DSL and Portable File Format (by tarekziade)
15:10:02 <anssik> Anssi: for this topic I want to review and discuss use cases for the new proposal, WebNN graph DSL and portable file format
15:10:07 <anssik> ... this proposals from Tarek addresses the following use cases:
15:10:18 <anssik> ... 1) Toolchain interoperability: ONNX (or other formats) -> WebNN deployment
15:10:24 <anssik> ... 2) Team collaboration and code review
15:10:29 <anssik> ... 3) Long-term reproducibility and governance
15:10:43 <anssik> .... the target audience is ML tooling authors, framework and converter maintainers, browser implementers, and application teams shipping WebNN models at scale
15:11:02 <anssik> ... the proposal has three parts:
15:11:09 <anssik> ... (1) a human-readable text representation (.webnn)
15:11:18 <anssik> ... (2) a canonical JSON representation for tooling
15:11:25 <anssik> ... (3) an optional external weights manifest + binary container
15:11:34 <anssik> ... Dave Raggett supported for the proposal in the issue
15:11:45 <anssik> ... MarkusT proposed to consider GGUF as the weight file format
15:11:49 <anssik> -> GGUF file format https://github.com/ggml-org/ggml/blob/master/docs/gguf.md
15:12:17 <anssik> MarkusT: first, I was thinking of GGUF initially, maybe safetensors is more approrpriate
15:12:41 <anssik> ... we have Python and Rust bindings, C++, JS for WebNN with a serialization format we'd have the ecosystem
15:13:07 <anssik> ... Torch to WebNN converter being worked on by a colleague of mine
15:13:58 <anssik> ... my questions to the group, does the group like the idea WebNN would be for not just for web browers but also for other environments?
15:14:15 <anssik> ... also about tests, would be great to be able to have a more generic test suite for other languages
15:14:16 <anssik> q?
15:14:28 <Mike_Wyrzykowski> q+
15:14:32 <anssik> ack Mike_Wyrzykowski
15:15:19 <anssik> MikeW: WebNN being for other environments, I don't think there's any objections for having support from other enviroments, for WebNN Apple prefers it being limited to the Web as a naming thing, if a native environment wants to exists it is fine
15:15:44 <anssik> MarkusT: we can think about the names, we have RustNN already for the Rust implementation, we'd like to keep the consistent interface across languages
15:15:52 <anssik> MikeW: RustNN would be totally fine
15:15:56 <RafaelCintron> q+
15:16:01 <anssik> ack RafaelCintron
15:16:25 <anssik> Rafael: I have not read the proposal in detail, but would not be opposed to spec a serialization format
15:16:52 <anssik> ... the ops supported in the seriazation format should be specified here in this group to make ensure interop
15:17:39 <anssik> ... whether this should be implemented just in browsers, we should be open to other enviroments to allow use of this proposed format
15:18:02 <anssik> MarkusT: this could be a small library that could be reused by projects
15:18:30 <anssik> ... this serialization format is defined as close to WebNN ops as possible and should map to WebIDL
15:18:30 <anssik> q?
15:18:51 <anssik> q?
15:19:11 <anssik> Anssi: as the next step I'd invite further review from the group for this proposal
15:19:16 <anssik> Topic: Web Neural Network API
15:19:20 <anssik> gb, this is webmachinelearning/webnn
15:19:22 <gb> anssik, OK.
15:19:29 <anssik> Subtopic: Public API surface reduction investigation
15:19:34 <anssik> Anssi: issue #907
15:19:35 <gb> https://github.com/webmachinelearning/webnn/issues/907 -> Issue 907 Composite operators / subgraphs (by fdwr) [opset]
15:19:49 <anssik> ... Markus opened an issue for a proposal to reduce the public API surface with a subgraph operator library
15:19:56 <anssik> ... the group has had similar discussions earlier in context of core op set #573
15:19:57 <gb> https://github.com/webmachinelearning/webnn/issues/573 -> Issue 573 Core operator set (by philloooo) [question] [opset]
15:20:16 <anssik> ... Markus' proposed to let backends implement more complex ops, such as lstm and gru #689
15:20:17 <gb> https://github.com/webmachinelearning/webnn/issues/689 -> Issue 689 Consider removing `lstm` and `gru` operators (by a-sully) [question] [operator specific]
15:20:25 <anssik> ... Markus' summary shared:
15:20:36 <anssik> ... 26 WebNN ops with an emulation path
15:20:43 <anssik> ... 3 ops only via emulation path
15:21:04 <anssik> ... WebNN op set has evolved guided by the following litmus test for each op:
15:21:13 <anssik> ... - are there use cases?
15:21:20 <anssik> ... - are there sample models?
15:21:29 <anssik> ... - cross-framework support?
15:21:35 <anssik> ... - implementable and performant across platforms?
15:21:46 <anssik> -> Contributing: Proposing and adding a new operation https://github.com/webmachinelearning/webnn/blob/main/CONTRIBUTING.md#proposing-and-adding-a-new-operation
15:22:55 <anssik> MarkusT: for RustNN I implemented WebNN per the spec, if we build composite ops we wouldn't need to do this for all backends
15:23:27 <anssik> ... with a library approach people could make a new graph and spin it into a new higher-level op
15:23:32 <anssik> q?
15:23:51 <anssik> MarkusT: would have been easier to not needing to implement those 26 ops
15:24:23 <anssik> ... to support lstm and gru, this discussion would not be required if we'd do that via a subgraph approach
15:24:24 <anssik> q?
15:25:12 <anssik> Dwayne: I agree the smaller op set facilitates adoption, for that list I want to check we have emulation paths defined, I'd would not remove ops before we have subgraphs feature done
15:25:28 <anssik> MarkusT: agree to not remove any ops before subgraph feature has been added
15:26:18 <anssik> Dwayne: if WebNN's graph builder is extended with dynamic tensor shapes, then those operators certainly become more important
15:26:39 <anssik> MarkusT: we'd have to detect those ops are emulated, there are a few ops that would be interesting to carry around
15:26:51 <anssik> ... we don't want to add too many ops to the spec by default
15:26:52 <anssik> q?
15:27:14 <anssik> q?
15:27:58 <anssik> Anssi: proposed next step to figure out a clean interface for the subgraph before advancing with the op cleanup
15:28:00 <anssik> q?
15:28:07 <ningxin> q+
15:28:14 <anssik> ack ningxin
15:28:42 <anssik> Ningxin: want to add an aspect from a performance perspective, we discussed that high-level ops were added due to performance
15:29:20 <anssik> ... before removing any I highly suggest the group will investigate that we can fuse the ops if we feed subgraph to them to understand the performance impact of possible op removal
15:29:20 <anssik> q?
15:29:36 <anssik> q?
15:29:56 <anssik> Subtopic: Generalize/relax the normalize* ops
15:30:01 <anssik> Anssi: issue #490 and #904
15:30:01 <gb> https://github.com/webmachinelearning/webnn/issues/904 -> Issue 904 2D, or not 2D, that is the question (by fdwr) [opset]
15:30:01 <gb> https://github.com/webmachinelearning/webnn/issues/490 -> Issue 490 Clarify `instanceNormalization`'s support for 1d, 2d, 3d use cases (by huningxin) [operator specific]
15:30:07 <anssik> ... initially this issue was filed by Jiewei in 2023 to rename instanceNormalization to instanceNormalization2d to clarify its 2d data use case
15:30:19 <anssik> ... we got recent input to resample2d naming, and Dwayne pointed out this is under consideration in #904
15:30:25 <anssik> ... this recent comment spurred another improvement suggestion from Dwayne
15:30:42 <anssik> ... to generalize/relax this now unnecessary rank restriction for also normalize* ops (normalizeInstance, normalizeBatch, normalizeLayer)
15:31:05 <mtavenrath> mtavenrath has joined #webmachinelearning
15:31:53 <anssik> Dwayne: I will update the issue #904 with new information
15:32:59 <Mike_Wyrzykowski> +1
15:33:21 <mtavenrath> +1
15:33:49 <anssik> RESOLUTION: Generalize/relax the now unnecessary rank restriction for also normalize* ops. (issue #904)
15:34:02 <anssik> Subtopic: Create a context in-parallel steps refinement
15:34:06 <anssik> Anssi: issue #919
15:34:07 <gb> https://github.com/webmachinelearning/webnn/issues/919 -> Issue 919 Creating a context should be done using finer-grained in-parallel steps (by gterzian)
15:34:25 <anssik> ... Gregory who works on RustNN with Tarek and Markus proposed a fix to the WebNN spec to align its "create a context" algorithm with the latest in-parallel steps conventions
15:34:28 <anssik> -> https://www.w3.org/TR/webnn/#create-a-context
15:34:32 <anssik> Anssi: Greg's proposal verbatim:
15:34:42 <anssik> [[
15:34:42 <anssik>   So I propose creating the MLContext object directly using steps on the event-loop, and then just adding a finer-grained in-parallel step to "start the timeline for the context in an implementation defined manner", and then to queue a task to reject or resolve the promise based on whether that operation was successful.
15:34:42 <anssik> ]]
15:34:48 <anssik> Anssi: I think the group agrees with this proposal, so this proposal is ready to be converted into a PR
15:35:09 <anssik> ... any questions or comments?
15:37:46 <handellm> handellm has joined #webmachinelearning
15:37:50 <anssik> q?
15:38:13 <anssik> Subtopic: Power preferences and the fallback concept
15:38:21 <anssik> Anssi: issue #911
15:38:22 <gb> https://github.com/webmachinelearning/webnn/issues/911 -> Issue 911 accelerated should be prior to powerPreference for device selection (by mingmingtasd) [device selection]
15:38:32 <anssik> ... Zoltan shared an updated IDL sketch to make the proposal more concrete (thanks for all the iteration!)
15:38:41 <anssik> ... comments were requested from MarkusH, Mingming, MikeW, and Ningxin
15:38:46 <anssik> -> https://github.com/webmachinelearning/webnn/issues/911#issuecomment-3897412058
15:38:47 <gb> https://github.com/webmachinelearning/webnn/issues/911 -> Issue 911 accelerated should be prior to powerPreference for device selection (by mingmingtasd) [device selection]
15:38:52 <anssik> Anssi: here's the proposed IDL:
15:38:58 <anssik> [[
15:38:58 <anssik> enum MLComputePolicy {
15:38:58 <anssik>   "default",  // or even better: "auto",
15:38:58 <anssik>   "high-performance",
15:38:58 <anssik>   "low-power",
15:38:58 <anssik>   "fallback"
15:38:59 <anssik> };
15:38:59 <anssik> 
15:38:59 <anssik> dictionary MLContextOptions {
15:39:00 <anssik>   MLComputePolicy computePolicy = "default";
15:39:00 <anssik> };
15:39:00 <anssik> 
15:39:01 <anssik> [SecureContext, Exposed=(Window, Worker)]
15:39:01 <anssik> partial interface MLContext {
15:39:01 <anssik>   ...
15:39:02 <anssik>   readonly attribute MLComputePolicy computePolicy;
15:39:02 <anssik>       // or would you prefer a "boolean fallback" instead?
15:39:02 <anssik>   readonly attribute boolean fallback;
15:39:03 <anssik> }
15:39:03 <anssik> ]]
15:39:07 <anssik> Anssi: a summary of IDL changes:
15:39:21 <anssik> ... - rename enum MLPowerPreference -> enum MLComputePolicy (enum rename not web-exposed)
15:39:31 <anssik> ... - add a new "fallback" value to MLComputePolicy
15:39:37 <anssik> ... - add a new MLContext.computePolicy attribute
15:39:42 <anssik> ... - add a new MLContext.fallback attribute
15:39:48 <anssik> Anssi: MarkusH gave thumps up in the issue
15:40:26 <RafaelCintron> q+
15:40:27 <anssik> Zoltan: not a powerPreference anymore, using an ORT convention
15:40:31 <anssik> ack RafaelCintron
15:41:15 <anssik> Rafael: I think what's the issue is about is fine, if we but fallback in the enum, the attribute on the MLContext need to be computePolicy
15:41:40 <anssik> Zoltan: IIRC there was a reason to expose a fallback as a boolean
15:41:48 <anssik> ... thanks for pointing that out
15:42:06 <anssik> Rafael: I'd be fine with the WebGPU approach, powerPreference + fallback separately
15:42:31 <anssik> ... if we put this in an enum we don't need the seperate boolean, to avoid fallback
15:42:53 <anssik> s/avoid fallback/avoid double fallback
15:43:08 <anssik> Zoltan: we should expose computePolicy, I think I agree
15:43:32 <anssik> Anssi: would it be a reasonable next step to spin up the PR based on this IDL sketch and improvements we just discussed
15:44:56 <anssik> Ningxin: I think Mingming can help with the PR
15:45:21 <Mike_Wyrzykowski> +1
15:45:31 <gb> https://github.com/webmachinelearning/webnn/issues/911 -> Issue 911 accelerated should be prior to powerPreference for device selection (by mingmingtasd) [device selection]
15:45:31 <zolkis> +1
15:45:35 <ningxin> +1
15:45:39 <anssik> RESOLUTION: Convert the MLComputePolicy IDL sketch into a spec PR. (issue #911)
15:45:54 <anssik> Anssi: I'd like to squeeze the post-compile graph.devices as a new topic next because MikeW bumped that (thanks!) and it connect with this topic we just discussed
15:45:58 <anssik> -> https://github.com/webmachinelearning/webnn/issues/836#issuecomment-4044875502
15:45:59 <gb> https://github.com/webmachinelearning/webnn/issues/836 -> Issue 836 Get devices used for a graph after graph compilation (by philloooo) [device selection]
15:46:04 <anssik> Subtopic: Post-compile graph.devices
15:46:09 <anssik> Anssi: issue #836
15:46:10 <gb> https://github.com/webmachinelearning/webnn/issues/836 -> Issue 836 Get devices used for a graph after graph compilation (by philloooo) [device selection]
15:46:16 <anssik> ... MikeW asked whether this issue can be closed, so I wanted to bring this topic to the agenda
15:46:23 <anssik> ... I believe the remaining open tasks for the group are:
15:46:38 <anssik> ... - document use case(s) for graph.devices, MarkusH contributed the adaptation use case, others?
15:47:00 <anssik> ... - check graph.devices API and pre-compile hints (MLComputePolicy) fit well together
15:47:20 <anssik> Anssi: ONNX Runtime is adding support for querying the device type to which the subgraph is assigned to
15:47:26 <anssik> ... any new implementation experience to be shared from that?
15:47:34 <anssik> ... I'd await for these two tasks to be completed before making a resolution on this issue
15:47:35 <Mike_Wyrzykowski> q+
15:47:47 <anssik> ack Mike_Wyrzykowski
15:48:34 <anssik> MikeW: there's strong concerns from privacy perspective for having any mechanism to report on which device the graph runs, we'd prefer to keep with the hints as discussed in the earlier issue and not provide the information to web apps regarding which device the graph run on
15:48:36 <anssik> q?
15:49:08 <RafaelCintron> q+
15:49:09 <handellm> q+
15:49:20 <anssik> ack RafaelCintron
15:49:53 <mtavenrath> mtavenrath has joined #webmachinelearning
15:49:54 <anssik> Rafael: wanted to ask about the Kobe resolution
15:50:51 <Mike_Wyrzykowski> q+
15:51:05 <anssik> ack Mike_Wyrzykowski
15:51:37 <RafaelCintron> q+
15:51:48 <anssik> MikeW: if the information is "is my graph accelerated" we can provide it via hints, post-compilation the graph runs on accelerated device
15:52:19 <handellm> has the audio broken again?
15:52:19 <zolkis> q+
15:53:09 <anssik> ack handellm
15:53:33 <anssik> MarkusH: wanted to understand can be expose effective compute policy on the graph?
15:54:21 <anssik> MikeW: I think exactly that, using the same enum for both the pre- and post-compilation that'd be acceptable
15:54:31 <RafaelCintron> q-
15:54:34 <anssik> q?
15:54:43 <anssik> ack zoltan
15:55:23 <RafaelCintron> q+
15:55:27 <anssik> Zoltan: wanted to ask, this is relative to the whole graph, what happens when we have subgraphs, can we use execute different graphs on different devices
15:55:34 <anssik> ack RafaelCintron
15:55:42 <anssik> q- zolkis
15:56:27 <anssik> Rafael: a machine with an NPU without all the ops, the system could say "low-power" yes, but not all ops supported still
15:56:54 <anssik> ... then can find out only some of the ops run on NPU and others on CPU and the experience will be worse
15:57:31 <anssik> ... for fingerprinting concern, maybe we can have a compromise by using bucketing "90% run on NPU" so people don't know exactly which ops run on which device
15:57:37 <anssik> q?
15:57:55 <zolkis> +1 to Rafael
16:00:15 <anssik> RRSAgent, draft minutes
16:00:17 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/12-webmachinelearning-minutes.html anssik
16:15:26 <anssik> Present+ Markus_Tavenrath
16:15:33 <anssik> Present+ Christian_Liebel
16:15:37 <anssik> Present+ Dwayne_Robinson
16:15:42 <anssik> Present+ Ehsan_Toreini
16:15:56 <anssik> Present+ Jaewon_Lee
16:16:05 <anssik> Present+ Markus_Handell
16:16:11 <anssik> Present+ Mike_Wyrzykowski
16:16:15 <anssik> Present+ Ningxin_Hu
16:16:20 <anssik> Present+ Rafael_Cintron
16:16:33 <anssik> Present+ Zoltan_Kis
16:16:37 <anssik> RRSAgent, draft minutes
16:16:38 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/12-webmachinelearning-minutes.html anssik
16:21:58 <anssik> s/this proposals/this proposal
16:22:39 <anssik> s/supported for the proposal/supported the proposal
16:23:14 <anssik> s/approrpriate/appropriate
16:24:27 <anssik> s/RustNN would/RustNN (as a name) would
16:24:54 <anssik> s/make ensure/ensure
16:25:36 <anssik> s/Markus' proposed/Markus proposed
16:26:17 <anssik> s/WebNN op set/I note WebNN op set
16:27:12 <anssik> s/I'd would/I would
16:30:59 <anssik> s|So I propose creating the MLContext object directly using steps on the event-loop, and then just adding a finer-grained in-parallel step to "start the timeline for the context in an implementation defined manner", and then to queue a task to reject or resolve the promise based on whether that operation was successful.|https://github.com/webmachinelearning/webnn/issues/919#issue-3951842470
16:31:41 <anssik> s/thumps/thumbs
16:33:51 <anssik> s/it connect/it connects
16:35:18 <anssik> s/can be expose/can we expose
16:35:47 <anssik> s/use execute/execute
16:36:21 <anssik> RRSAgent, draft minutes
16:36:23 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/12-webmachinelearning-minutes.html anssik
18:30:21 <Zakim> Zakim has left #webmachinelearning