14:55:49 <RRSAgent> RRSAgent has joined #webmachinelearning
14:55:53 <RRSAgent> logging to https://www.w3.org/2026/06/18-webmachinelearning-irc
14:55:54 <Zakim> RRSAgent, make logs Public
14:55:55 <Zakim> please title this meeting ("meeting: ..."), anssik
14:56:06 <anssik> Meeting: WebML WG Teleconference – 18 June 2026
14:56:06 <anssik> Chair: Anssi
14:56:06 <anssik> Agenda: https://github.com/webmachinelearning/meetings/blob/main/telcons/2026-06-18-wg-agenda.md
14:56:07 <anssik> Scribe: Anssi
14:56:09 <anssik> scribeNick: anssik
14:56:23 <anssik> Present+ Anssi_Kostiainen
14:56:28 <anssik> RRSAgent, draft minutes
14:56:29 <RRSAgent> I have made the request to generate https://www.w3.org/2026/06/18-webmachinelearning-minutes.html anssik
14:58:14 <dwayner> dwayner has joined #webmachinelearning
14:58:30 <anssik> Present+ Dwayne_Robinson
14:59:12 <Mike_Wyrzykowski> Mike_Wyrzykowski has joined #webmachinelearning
14:59:20 <anssik> Present+ Mike_Wyrzykowski
15:00:00 <ydaniv> ydaniv has joined #webmachinelearning
15:01:02 <anssik> Present+ Yehonatan_Daniv
15:01:02 <anssik> Present+ Bryan_Bernhart
15:01:06 <anssik> Present+ Ningxin_Hu
15:02:09 <anssik> Present+ Rafael_Cintron
15:02:20 <anssik> Present+ Reilly_Grant
15:02:29 <anssik> RRSAgent, draft minutes
15:02:30 <RRSAgent> I have made the request to generate https://www.w3.org/2026/06/18-webmachinelearning-minutes.html anssik
15:03:06 <anssik> Anssi: please join me in welcoming the latest new participant to the WG:
15:03:11 <anssik> ... Severin Ferrand from Google
15:03:19 <anssik> ... Yehonatan Daniv from Vix.com
15:03:27 <RafaelCintron> RafaelCintron has joined #webmachinelearning
15:05:08 <anssik> ... Julien Bataille from Rakuten Group, Inc.
15:05:12 <anssik> ... welcome all!
15:05:19 <ningxin> ningxin has joined #webmachinelearning
15:05:24 <anssik> Topic: Announcements
15:05:34 <anssik> Subtopic: TPAC 2026
15:05:41 <ydaniv> s/Vix.com/Wix.com/
15:05:41 <anssik> Anssi: as discussed, TPAC 2026 takes place in Dublin, Ireland on 26-30 October 2026
15:05:58 <anssik> ... I have requested Monday, 26 October 2026, for this Working Group, to be confirmed by TPAC planners
15:06:06 <anssik> ... I have also started a F2F agenda issue where I invite the group to share their thoughts on potential agenda topics for the TPAC F2F meeting:
15:06:10 <anssik> -> https://github.com/webmachinelearning/meetings/issues/39
15:06:11 <gb> https://github.com/webmachinelearning/meetings/issues/39 -> Issue 39 WebML WG/CG F2F Agenda - TPAC 2026 (Dublin, Ireland) (by anssiko)
15:06:12 <Ehsan> Ehsan has joined #webmachinelearning
15:06:30 <anssik> Anssi: the expectation is we use the F2F to have both discussions on the shorter-term issues as well as longer-term horizon with new features for future directions
15:06:48 <anssik> ... we also provide space for sharing demos and implementation updates with the broader community
15:07:08 <anssik> Anssi: I have planned the Community Group meeting for Tuesday, 27 October 2026, so if you attend TPAC you may want to consider attending that as well to connect with the broader community
15:07:27 <anssik> ... we operate in the same space and there is a lot of overlap between the two groups, TPAC is a prime opportunity for cross-pollination of ideas between the groups
15:07:46 <anssik> ... I expect the TPAC group schedule to be finalized later this month, I will share more information as soon as it becomes available
15:07:50 <anssik> Anssi: questions, comments?
15:07:58 <anssik> q?
15:08:06 <anssik> q+ to ask a question
15:08:07 <anssik> ack anssik
15:08:07 <Zakim> anssik, you wanted to ask a question
15:08:20 <anssik> Subtopic: New charter proposal
15:08:26 <anssik> Anssi: I want to share an update on the new charter proposal for this Working Group
15:08:42 <anssik> ... as you may have noticed, the WebMCP proposal being developed in the WebML CG has generated excitement and momentum
15:08:47 <anssik> -> https://github.com/webmachinelearning/webmcp
15:09:49 <anssik> Anssi: I added WebMCP deliverable to the WebML CG last year, and I'm pleased to see the progress that has been made by the WebML CG, and the excitement WebMCP has generated within the broader web community
15:10:07 <anssik> ... WebMCP is one of the fastest growing incubations in the history of the W3C's Community Group (CG) program
15:10:24 <anssik> ... the W3C CEO and senior leadership team is supportive of evolving the WebML WG charter to include WebMCP as a deliverable
15:10:41 <anssik> ... the next step is to finalize the formal charter proposal document that outlines the proposed changes to the charter, including the addition of WebMCP as a deliverable, and submit it for review by the W3C membership
15:10:44 <anssik> ... the draft charter proposal is available for you to review:
15:10:49 <anssik> -> https://github.com/w3c/charter-drafts/pull/829/changes
15:10:50 <gb> https://github.com/w3c/charter-drafts/pull/829 -> Pull Request 829 [wg/webmachinelearning] Adds WebMCP in scope (by plehegar)
15:11:15 <anssik> Anssi: as an important deliverable, I expect active discussion in the W3C community, a healthy part of the process
15:11:21 <anssik> ... I welcome your feedback on the draft charter proposal on our next call
15:11:32 <anssik> ... in the meantime, if you have any immediate thoughts or questions about the draft charter proposal, please feel free to share them now or reach out to me directly
15:11:41 <anssik> q?
15:11:55 <anssik> Topic: Web Neural Network API
15:12:00 <anssik> gb, this is webmachinelearning/webnn
15:12:01 <gb> anssik, OK.
15:12:13 <RafaelCintron> RafaelCintron has joined #webmachinelearning
15:12:15 <anssik> Subtopic: WebGPU interop
15:12:26 <anssik> Anssi: this topic is to discuss WebGPU interop and expected spec changes
15:12:37 <anssik> ... I have invited Bryan to the call who has signaled interest in this topic and has been actively involved in the WebGPU interop discussions
15:12:49 <anssik> ... the MLTensor Explainer discussed WebGPU interop:
15:12:53 <anssik> -> https://github.com/webmachinelearning/webnn/blob/main/mltensor-explainer.md#webgpu-interop
15:12:58 <anssik> Anssi: we have a few "webgpu interop" related issues:
15:13:02 <anssik> -> "webgpu interop" issues https://github.com/webmachinelearning/webnn/labels/webgpu%20interop
15:13:06 <anssik> Anssi: issue #529 for WebNN timelines
15:13:08 <gb> https://github.com/webmachinelearning/webnn/issues/529 -> Issue 529 Specify WebNN timelines (by a-sully) [webgpu interop]
15:13:13 <anssik> another issue #343 for WebGPU interop sample code
15:13:14 <gb> https://github.com/webmachinelearning/webnn/issues/343 -> Issue 343 Add sample code for WebGPU interop (by huningxin) [editorial] [webgpu interop]
15:13:38 <anssik> Anssi: are there any other spec changes expected either in the WebNN or WebGPU spec, or both, to enable WebGPU interop?
15:13:48 <reillyg> q+
15:13:52 <anssik> ... have we ported over all the necessary WebGPU interop bits from the MLTensor explainer to the WebNN spec?
15:13:54 <anssik> ack reillyg
15:14:01 <anssik> Rack reillyg
15:14:08 <anssik> s/Rack reillyg//
15:15:04 <Mike_Wyrzykowski2> Mike_Wyrzykowski2 has joined #webmachinelearning
15:15:11 <anssik> Reilly: we have a Chromium prototype, the JS API itself is implemented to some extent, platform-specific bits e.g. HW buffers, most mature on macOS, being implemented on WIndows and Linux with LiteRT
15:15:43 <anssik> ... it is currently in an explainer only, WebGPU interop changes have not been ported over the WebNN spec
15:16:08 <anssik> ... Bryan made a change to make the export  feature synchronous to improve pipelining
15:16:16 <anssik> q?
15:16:46 <anssik> Bryan: I agree with Reilly, the explainer is out of date, a lot of people want to use this feature and would like to see this well specified
15:17:20 <RafaelCintron> +1 to specifying it more formally and updating the explainer.
15:17:24 <ningxin> +1
15:17:27 <Mike_Wyrzykowski> +1
15:17:30 <anssik> ... more formal specification would be helpful, does the group support specifying WebGPU interop parts in the spec?
15:17:53 <ningxin> q+
15:18:16 <dwayner> +1
15:18:29 <anssik> ack ningxin
15:19:07 <anssik> Ningxin: about WebGPU interop sample, I shared a demo at TPAC 2025, I recommend to move that sample to the group's webnn-samples repo
15:20:02 <reillyg> +1
15:20:05 <ningxin> +1
15:20:06 <RafaelCintron> +1
15:20:08 <anssik> RESOLUTION: The group acknowledges the importance of WebGPU interop and supports porting over the necessary features to the WebNN API spec from the MLTensor explainer.
15:20:18 <reillyg> q_
15:20:19 <reillyg> q+
15:20:25 <anssik> ack reillyg
15:20:49 <anssik> Reilly: Bryan mentioned some difficulties, was that about undocumented buffering requirements maybe?
15:21:12 <anssik> Bryan: today the usage, if  you import a buffer, it is implicit, what format each side of the APIs need to use
15:21:22 <anssik> Reilly: these could be formally documented in the spec
15:21:57 <anssik> ... when implementing this on Core ML there are some limitations in terms of data types and shapes for input buffers
15:22:36 <anssik> ... we partially worked around these, probably an open question, something to be exposed through opSupportLimits
15:23:10 <anssik> Bryan: there was another issue about device selection that breaks interop, we need to clarify how that will work
15:23:33 <anssik> Reilly: there's a version of  content creation that takes a GPUDevice
15:23:52 <anssik> ... implicit hint to pick a device that is efficient
15:24:08 <anssik> ... some platforms may ignore this hint
15:24:41 <anssik> ... looking at ML inference frameworks, GPUs seem to like tensors in certain shapes
15:24:49 <anssik> q?
15:25:16 <anssik> Bryan: we have to come up with guidelines for this
15:25:24 <anssik> q?
15:26:29 <anssik> Reilly: can you open a new GH issue for this Bryan?
15:26:43 <ningxin> +1 to open an issue about gpudevice passing
15:26:54 <anssik> Bryan: will do that, filing separate issues
15:26:55 <anssik> q?
15:27:02 <anssik> q?
15:27:09 <anssik> Subtopic: Effective MLComputePolicy
15:27:14 <anssik> Anssi: issue #934
15:27:15 <gb> https://github.com/webmachinelearning/webnn/issues/934 -> Issue 934 Effective MLComputePolicy exposure (by anssiko) [policy selection] [Agenda+]
15:27:23 <anssik> Anssi: last time we received an update on the Dynamic AI Offloading Protocol (DAOP) incubation by Jonathan
15:27:33 <anssik> ... we had a limited timebox for DAOP, so on this call, I wanted to share some additional information about the explainer to inform the effective MLComputePolicy discussion
15:27:42 <anssik> -> The estimateQoS() API https://github.com/webmachinelearning/daop/tree/main#the-estimateqos-api
15:27:56 <anssik> ... DAOP explainer contained estimateQoS() API for performance negotiation
15:28:25 <anssik> ... using the estimateQoS() API the web developer can get a performance tier estimate for executing the graph on the local device, which can help them make informed decisions about offloading to the cloud or executing locally
15:28:34 <anssik> [[
15:28:34 <anssik> dictionary MLQoSReport {
15:28:34 <anssik>   MLPerformanceTier performanceTier;
15:28:34 <anssik> };
15:28:36 <anssik> partial interface MLContext {
15:28:36 <anssik>   Promise<MLQoSReport> estimateQoS(MLGraph graph, optional MLQoSOptions options);
15:28:36 <anssik> };
15:28:39 <anssik> dictionary MLQoSOptions {
15:28:39 <anssik>   // Input characteristics
15:28:39 <anssik>   record<DOMString, MLOperandDescriptor> inputDescriptors;
15:28:42 <anssik>   // Weights characteristics (Optional)
15:28:42 <anssik>   boolean weightsSparsity = false;
15:28:42 <anssik> };
15:28:43 <anssik> ]]
15:29:04 <anssik> -> Performance Tiers https://github.com/webmachinelearning/daop/tree/main#performance-tiers
15:29:27 <anssik> Anssi: performance tiers are represented as Tier strings to avoid fingerprinting and to allow implementations evolve the exact tier boundaries based on their specific hardware capabilities and performance characteristics:
15:29:37 <anssik> Anssi: Tier / Indicative Latency / Interpretation
15:29:39 <anssik> ... "excellent"	/ < 16 ms /	Real-time (60 fps frame budget)
15:29:39 <anssik> ... "good"	/ < 100 ms / Interactive responsiveness
15:29:39 <anssik> ... "fair"	/ < 1 s / Responsive for non-real-time tasks
15:29:39 <anssik> ... "moderate"	/ < 10 s / Tolerable for batch or one-shot tasks
15:29:40 <anssik> ... "slow"	/ < 30 s /	Noticeable wait
15:29:40 <anssik> ... "very-slow"	/ < 60 s /	Long wait
15:29:40 <anssik> ... "poor"	/ ≥ 60 s /	Likely unacceptable for most use cases
15:30:24 <anssik> Anssi: the important point to note is that the exact tier boundaries are implementation-defined
15:30:34 <anssik> ... the explainer also provides an "Adaptive Background Blur" example to make the API more concrete:
15:30:38 <anssik> -> https://github.com/webmachinelearning/daop/tree/main#example-code-adaptive-background-blur
15:30:57 <anssik> Anssi: in this example, if the tier is one of "excellent", "good", "fair", or "moderate" the graph is executed locally, otherwise the graph is offloaded to the cloud
15:31:17 <anssik> -> Boolean Requirement API https://github.com/webmachinelearning/daop/tree/main#1-boolean-requirement-api
15:31:43 <anssik> Anssi: this meetsRequirement() API returns asynchronously and via events a "can meet requirement" boolean response given a tier expectation:
15:31:50 <anssik> [[
15:31:50 <anssik> partial interface MLContext {
15:31:50 <anssik>   Promise<boolean> meetsRequirement(MLGraph graph, MLPerformanceTier requiredTier, optional MLQoSOptions options);
15:31:50 <anssik> };
15:31:52 <anssik> interface MLQoSChangeEvent : Event {
15:31:52 <anssik>   readonly attribute boolean meetsRequirement;
15:31:52 <anssik> };
15:31:53 <anssik> ]]
15:32:40 <anssik> Anssi: with these DAOP insights in mind, I want to circle back to the effective MLComputePolicy discussion in issue #934
15:32:41 <gb> https://github.com/webmachinelearning/webnn/issues/934 -> Issue 934 Effective MLComputePolicy exposure (by anssiko) [policy selection] [Agenda+]
15:32:44 <anssik> ... the following proposals were discussed last time:
15:32:50 <anssik> ... - 1) compilation metrics & runtime estimates by MikeW
15:32:50 <anssik> ... - 2) low latency v high throughput tradeoff implications by Dwayne
15:32:50 <anssik> ... - 3) strict hints to fail at build by MarkusH
15:32:50 <anssik> ... - 4) "low-latency" and "precision" hints by Dwayne
15:33:21 <anssik> Anssi: looking at the recent comments, I see an exchange between Ningxin and MikeW about runtime drift considerations
15:33:28 <anssik> ... Ningxin acknowledged MikeW's point that system load, thermal state, and accelerator contention do change over time
15:33:35 <anssik> ... Ningxin proposed an intendedComputePolicies API, a compile-time signal to address MarkusH's use case "if fallback, route to cloud":
15:33:39 <anssik> -> https://github.com/webmachinelearning/webnn/issues/934#issuecomment-4626388359
15:33:40 <gb> https://github.com/webmachinelearning/webnn/issues/934 -> Issue 934 Effective MLComputePolicy exposure (by anssiko) [policy selection] [Agenda+]
15:34:16 <anssik> Ningxin: I want to find a middle ground, MikeW make a good point that runtime characteristics are dynamic, timestamp query would be one approach
15:35:19 <anssik> ... my point was for an application, for MarkusH's use case, the intended compute policy, the best result the context can deliver against the user's hint, decided at MLGraphBuilder.build() and stable for the MLGraph's lifetime
15:36:05 <anssik> ... the API could have some signal to let the application know the compile-time intention for graph execution plan, we make it clear this could change at runtime, if runtime monitoring is needed, other solutions need to be used
15:36:16 <anssik> Anssi: the proposed API for this is as follows:
15:36:18 <anssik> [[
15:36:18 <anssik> interface MLGraph {
15:36:18 <anssik>   // Compile-time assignment, not a runtime guarantee.
15:36:19 <anssik>   readonly attribute FrozenArray<MLComputePolicy> intendedComputePolicies;
15:36:19 <anssik> }
15:36:19 <anssik> ]]
15:36:24 <anssik> q?
15:37:08 <anssik> MikeW: the association of fallback with a quaranteed CPU path seems questionnable, because there can be multiple CPU path
15:38:10 <anssik> ... hints for web apps to make a decision is a wrong API shape
15:39:34 <anssik> ... the current proposal seems to be that hints can be translated to performance characteristics, it would be better to provide performance characteristics, for instance, latency, how many milliseconds bucketized, runtime execution, bucketized
15:39:42 <anssik> q?
15:39:58 <anssik> Present+ Ehsan_Toreini
15:40:00 <reillyg> q+
15:40:05 <anssik> ack reillyg
15:40:53 <anssik> Reilly: MikeW, in the scenario where we are providing bucketed performance characteristics, how does that interact with the system how the graph is constructed at later stage?
15:41:16 <anssik> ... how much does this is a guarantee, how much sites could use this information?
15:41:39 <RafaelCintron> Q+
15:42:16 <anssik> MikeW: you can poll the API, or the granularity of the metrics will be made less precise
15:42:18 <anssik> q?
15:42:23 <anssik> ack RafaelCintron
15:42:53 <anssik> Rafael: question to MikeW, is your proposal to have the UA take the model and guess how long it takes to run and provide that information before inference?
15:43:03 <anssik> ... and during runtime, tell how long it took?
15:43:16 <anssik> MikeW: I don't have preference and would be fine with either of these options
15:43:32 <reillyg> q+
15:44:00 <anssik> Rafael: the second solution seems better fit, the guessing approach, how would you implement that on Core ML?
15:44:34 <anssik> MikeW: we can guess when we compile the model, you get back information from Core ML, and can guess based on this, consider it a rough hint
15:44:50 <ningxin> q+
15:44:57 <anssik> Rafael: if all ops running on GPU the guess would be "fast"
15:45:22 <anssik> ... I wonder how well that would work in practice, how good a guess our "guess" would be
15:45:23 <anssik> q?
15:45:28 <anssik> ack reillyg
15:46:10 <anssik> Reilly: I think that guessing is not required, you can run the model, and in the heat of loading the benchmark would be worse than at runtime
15:46:27 <anssik> ... possible to implement, yes, but not clear on the details
15:47:18 <anssik> ... related discussion for CPU Performance API on blink-dev
15:48:05 <anssik> ... multiple pipelines could submit to hardware, changes are dynamic, if performance is not adequate could switch to another compute unit
15:48:45 <anssik> ... applications are capable of dynamic scaling, but in ML models, loading an ML model is a significant upfront cost, loading and compiling both are costly
15:49:10 <anssik> ... the purpose of an API like this is to really allow the developer to pick something to do initially that is close to correct
15:49:46 <anssik> ... the developer may look at this performance information and see it is "mid-tier" and it is much more than they need, and they could download a bigger model in the background, while the app is running fine using a smaller model
15:50:13 <anssik> ... the space seems to me like solving the "page load time problem", how to in a reasonable amount of time to decide what to load initially to allow the page to function
15:50:27 <anssik> ... all the solutions discussed don't solve that problem
15:50:28 <anssik> q?
15:50:41 <anssik> ack ningxin
15:51:16 <anssik> Ningxin: by revising MarkusH's use case I observe, it is not only about model inference performance, but also want to avoid data copies
15:51:41 <anssik> ... use case about noise suppression, audio comes from CPU and the application does not want to move the work to other compute unit
15:51:50 <anssik> ... this is something I suppose the app wants to avoid
15:52:24 <anssik> ... also Markus mentions the need to get the execution to be scheduled to a low-latency enabling compute unit
15:52:52 <anssik> ... I want to add to MikeW's proposal, if we have performance characteristics, could we also indicate if there is a data copy?
15:53:09 <anssik> ... e.g. add low-latency signal?
15:53:10 <anssik> q?
15:54:12 <anssik> MikeW: what Ningxin and Reilly said sounds good, both ideas are valuable and we should consider real use cases such as MarkusH
15:54:17 <anssik> q?
15:55:07 <anssik> q?
15:57:05 <anssik> Subtopic: Discrepancies with maxPool2d padding behavior
15:57:08 <anssik> Anssi: issue #935
15:57:09 <gb> https://github.com/webmachinelearning/webnn/issues/935 -> Issue 935 Discrepancies with maxPool2d padding behavior (by philloooo) [operator specific] [Agenda+]
15:57:28 <anssik> ... Phillis reports that maxPool2d with roundingType "ceil" produces inconsistent results for different backends when pooling windows cover only padding elements
15:57:32 <anssik> -> https://www.w3.org/TR/webnn/#dom-mlroundingtype-ceil
15:57:41 <anssik> Anssi: questions posed to the group:
15:57:55 <anssik> ... - "What is the expected behavior when a pooling window covers only padding elements for maxPool2d?
15:58:04 <anssik> ... - "Should the spec clarify whether padding elements are treated as -Infinity (ignored) or if there is a fallback value like 0 when no valid input elements are in the window?"
15:58:18 <anssik> Anssi: Ningxin proposed "Ignoring padding elements for maxPool2d makes sense to me. A window covering only padding would also be ignored."
15:58:32 <anssik> ... Dwayne +1'd "ignoring padding elements for maxPool2d"
15:58:41 <anssik> ... suggests that for "a window covering only padding" needs some value for the pool() op, either 0 or -Infinity
15:58:55 <anssik> q?
15:59:58 <anssik> Ningxin: for maxPool2d if we ignore window, the value does not matter, we should make the spec text clear so that we ignore also window for padding elements, should change the output size calculation to adjust output size with stride and padding if window only covers the padding elements
16:00:42 <anssik> Dwayne: I mentioned in general, you can't sample outside window and padding size, making this point moot
16:01:06 <anssik> Ningxin: in my proposal "ignore padding elements" if the window covers partially, this is implementation-defined, spec can say ignore this
16:01:23 <anssik> ... ONNX reference implementation is NaN for this case
16:01:32 <anssik> q?
16:04:18 <anssik> RESOLUTION: Ignore padding elements for maxPool2d and adjust output size when a window covers only padding. (issues #935)
16:04:23 <anssik> RRSAgent, draft minutes
16:04:25 <RRSAgent> I have made the request to generate https://www.w3.org/2026/06/18-webmachinelearning-minutes.html anssik
16:04:31 <Mike_Wyrzykowski> +1
16:08:33 <anssik> s/WIndows/Windows
16:08:51 <anssik> s/an explainer/the explainer
16:09:16 <anssik> s/ported over the/ported over to the
16:10:20 <anssik> s/need to use/should use
16:26:02 <anssik> RRSAgent, draft minutes
16:26:04 <RRSAgent> I have made the request to generate https://www.w3.org/2026/06/18-webmachinelearning-minutes.html anssik