14:52:23 <RRSAgent> RRSAgent has joined #webmachinelearning
14:52:28 <RRSAgent> logging to https://www.w3.org/2026/03/26-webmachinelearning-irc
14:52:28 <Zakim> RRSAgent, make logs Public
14:52:29 <Zakim> please title this meeting ("meeting: ..."), anssik
14:52:29 <anssik> Meeting: WebML WG Teleconference – 26 March 2026
14:53:09 <anssik> Chair: Anssi
14:53:14 <anssik> Agenda: https://github.com/webmachinelearning/meetings/blob/main/telcons/2026-03-26-wg-agenda.md
14:53:18 <anssik> Scribe: Anssi
14:53:23 <anssik> scribeNick: anssik
14:53:29 <anssik> gb, this is webmachinelearning/webnn
14:53:30 <gb> anssik, OK.
14:53:35 <anssik> Present+ Anssi_Kostiainen
14:53:41 <anssik> RRSAgent, draft minutes
14:53:42 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/26-webmachinelearning-minutes.html anssik
14:57:43 <anssik> Present+ Rafael_Cintron
14:57:55 <RafaelCintron> RafaelCintron has joined #webmachinelearning
15:00:12 <anssik> Present+ Dwayne_Robinson
15:01:20 <anssik> Present+ Mike_Wyrzykowski
15:01:30 <anssik> Present+ Ehsan_Toreini
15:01:42 <anssik> Present+ Gregory_Terzian
15:02:18 <Mike_Wyrzykowski> Mike_Wyrzykowski has joined #webmachinelearning
15:03:54 <anssik> Present+ Zoltan_Kis
15:04:18 <anssik> Present+ Ningxin_Hu
15:04:38 <zolkis> zolkis has joined #webmachinelearning
15:04:46 <anssik> Anssi: please welcome the new participants to the WG:
15:05:01 <ningxin> ningxin has joined #webmachinelearning
15:05:09 <handellm> handellm has joined #webmachinelearning
15:05:10 <anssik> ... Gregory Terzian as an Invited Expert, working on WebNN Servo implementation
15:05:17 <anssik> ... Tarek Ziade from Hugging Face, working on RustNN implementation, transitioning from Mozilla
15:05:18 <ningxin> Present+
15:05:38 <anssik> Present+ Tarek_Ziade
15:05:50 <anssik> Present+ Markus_Handell
15:06:15 <anssik> Anssi: Chelsea Kohl from Flying Okole
15:06:16 <anssik> ... Joan Leon, David Mulder as an individual contributors
15:06:21 <anssik> ... welcome all!
15:06:32 <RafaelCintron> Present+ RafaelCintron
15:06:40 <anssik> ... I'm pleased to new diverse implementation experience
15:06:53 <anssik> ... this broader implementation feedback continues to further strengthen and validate the WebNN API spec design
15:07:03 <tarek> tarek has joined #webmachinelearning
15:07:10 <anssik> Topic: Web Neural Network API
15:07:17 <anssik> Subtopic: MLComputePolicy-driven device selection
15:07:25 <anssik> Anssi: PR #923
15:07:26 <gb> https://github.com/webmachinelearning/webnn/pull/923 -> Pull Request 923 Refactor device selection: Rename to computePolicy, remove accelerated, and add fallback (by mingmingtasd) [device selection]
15:07:38 <anssik> ... we'll review the PR that executes the resolution:
15:07:48 <anssik> -> Resolution https://www.w3.org/2026/03/12-webmachinelearning-minutes.html#61df
15:07:53 <anssik> Anssi: last time we resolved to convert the MLComputePolicy IDL proposal into a spec PR
15:08:19 <anssik> ... Mingming has submitted a PR #923 for review that refactors the device selection preference API to establish a more extensible framework by replacing MLPowerPreference with MLComputePolicy in MLContextOptions
15:08:24 <anssik> ... thank you Mingming for this contribution
15:08:33 <anssik> ... key changes proposed:
15:08:41 <anssik> ... - renamed preference enum MLPowerPreference -> MLComputePolicy
15:08:46 <anssik> ... - clarified extensibility
15:08:53 <anssik> ... - removed "accelerated" option
15:08:58 <anssik> ... - introduced "fallback" policy
15:09:05 <anssik> ... there's a corresponding Chromium CL providing implementation experience:
15:09:09 <anssik> -> https://chromium-review.googlesource.com/c/chromium/src/+/7513189
15:09:17 <anssik> Anssi: spec PR review was requested from Rafael, Dwayne, Ningxin and Reilly
15:09:23 <anssik> ... any questions or comments?
15:09:33 <zolkis> q+
15:09:40 <anssik> ack zolkis
15:10:45 <anssik> Zoltan: this is expressing developer preference when context is created
15:10:51 <anssik> q?
15:11:04 <anssik> Zoltan: I gave thumbs up
15:11:52 <RafaelCintron> I will take a look but it looks good to me so far.
15:12:03 <anssik> ... up to MikeW and Markus to say whether they're happy
15:12:34 <handellm> Looks good, I'll follow up on the PR
15:12:38 <anssik> q?
15:12:40 <anssik> Subtopic: Bounded dynamic dimension
15:12:44 <anssik> Anssi: issue #883
15:12:45 <gb> https://github.com/webmachinelearning/webnn/issues/883 -> Issue 883 Support flexible input sizes (by huningxin) [feature request] [operator specific] [Agenda+]
15:13:03 <anssik> Anssi: next we'll discuss the proposed new bounded dynamic dimension mechanism for MLDynamicDimension
15:13:19 <anssik> ... MarkusT suggested to add minSize to complement maxSize
15:13:36 <anssik> ... maxSize use case is to inform the implementation of memory allocation
15:13:42 <anssik> ... minSize use case would be similar, Dwayne gave thumbs up
15:13:53 <tarek8> tarek8 has joined #webmachinelearning
15:13:55 <anssik> ... Ningxin proposed minSize to be optional with 1 as default
15:14:18 <anssik> ... Ningxin conducted a survey for bounded dynamic dimensions, notes "supported by CoreML, TensorRT and OpenVINO"
15:14:39 <anssik> ... but notes ONNX model cannot represent dimension bounds
15:14:45 <anssik> ... also JS ML frameworks don't support dimension bounds
15:14:58 <anssik> ... ONNX model cannot pass dimension bounds info to EPs
15:15:25 <anssik> ... MarkusT notes min/max bounds are just hints
15:15:29 <anssik> ... this allows implementations to accept any size
15:16:39 <anssik> Ningxin: I got the task to create the PR, we're still exploring framework support, specifically ORT Web, looking to define session options, e.g. freeDimensionBounds
15:16:48 <anssik> ... similar to freeDimensionOverride
15:17:14 <anssik> ... with this mechanism we can satisfy the WebNN change proposal, freeDimension will require maxSize
15:17:49 <anssik> ... we're prototyping this and making good progress, testing with various models
15:18:22 <anssik> ... on the WebNN backend side, MarkusT shared we can inform the underlying runtime via some mechanism, but haven't yet prototyped that and will explore it
15:19:02 <anssik> ... another open issue is, TF.js models are more flexibly wrt free dimensions. e.g. shape op can capture tensor shape at runtime followed by e.g. gather and squeeze to construct a shape at inference time
15:19:31 <anssik> ... and also have dynamic ops like reshape, where new shape is defined by dynamic tensor, like a dynamic slice
15:19:58 <anssik> ... not sure yet if we should introduce such new ops, their output would be defined by tensor rather than something that can be inferred at model build time
15:20:33 <anssik> ... we have WebNN tensor element count validation at build time, with dynamic ops it is challenging to do shape inference and validation at build time
15:20:34 <anssik> q?
15:20:52 <anssik> Ningxin: I can append the issue accordingly
15:22:10 <anssik> q?
15:22:42 <anssik> Subtopic: Tensor element count limit
15:22:56 <anssik> Anssi: issue #924 and PR #926
15:22:57 <gb> https://github.com/webmachinelearning/webnn/pull/926 -> Pull Request 926 Specify element count limit (by philloooo)
15:22:57 <gb> https://github.com/webmachinelearning/webnn/issues/924 -> Issue 924 Consider specifying tensor element count limit (by philloooo) [feature request] [Agenda+]
15:23:03 <anssik> ... a proposal from Phillis to spec tensor element count limit
15:23:19 <anssik> ... WebNN API currently reports the maximum supported length of tensors in bytes via MLOpSupportLimits.maxTensorByteLength
15:23:21 <anssik> -> https://www.w3.org/TR/webnn/#dom-mlopsupportlimits-maxtensorbytelength
15:23:40 <anssik> Anssi: but tensor element count is not exposed and there's are apparently use cases that require both maxTensorByteLength and total element count
15:23:50 <anssik> ... Chromium implementation already checks for the tensor element count limit
15:23:54 <anssik> -> https://chromium-review.git.corp.google.com/c/chromium/src/+/7682064
15:24:34 <anssik> Anssi: PR #926 updates the "check dimensions" algorithm to test that the tensor element count is within the range of long, ~2B elements
15:24:42 <anssik> q?
15:25:33 <anssik> Dwayne: this seems reasonable, in some cases element count can be different from max byte count, e.g. something fits in memory but exceeds max indexing size for the API
15:25:41 <anssik> ... we say 32 max is the limit for this
15:27:04 <DwayneR> DwayneR has joined #webmachinelearning
15:27:32 <RafaelCintron> q+
15:27:42 <anssik> Dwayne: I did not see any dissent about this in the issue or PR discussions
15:27:49 <anssik> ack RafaelCintron
15:28:16 <anssik> Rafael: I think this is fine for now, later on we may add a context attribute so developer knows what the limit is
15:28:54 <anssik> ... it helps to give web developers less than what you have
15:29:20 <anssik> Dwayne: opSupportsLimits could have that as a complement
15:31:28 <anssik> Subtopic: Security considerations for out-of-bounds access
15:31:42 <anssik> Anssi: we have the following inline issue in the security considerations:
15:31:55 <anssik> ... "Document operations susceptible to out-of-bounds access as a guidance to implementers"
15:32:02 <anssik> -> https://www.w3.org/TR/webnn/#security
15:32:23 <anssik> Anssi: with further implementation experience across backends I believe the group is in a good position to make progress with this issue
15:32:44 <anssik> ... the proposed path forward is to document ops the group believes are susceptible to out-of-bounds access
15:33:01 <anssik> ... and propose mitigations as a guidance to implementers
15:33:33 <anssik> ... the mitigations are most likely implementation-defined to allow each implementation to use the mitigation techniques best suited for them, thus generic language is appropriate
15:33:40 <anssik> -> https://infra.spec.whatwg.org/#implementation-defined
15:33:53 <anssik> q?
15:34:32 <RafaelCintron> q+
15:34:37 <anssik> ack RafaelCintron
15:34:55 <anssik> Rafael: what's in the spec seems fine to me, the browser should be secure by default
15:34:57 <ningxin> +1
15:35:32 <ningxin> q+
15:36:10 <anssik> Rafael: I consider all ops as important in terms of security
15:36:13 <anssik> ack ningxin
15:37:01 <anssik> Ningxin: I think the spec already has text about bounds, for e.g. scatter and gather we have text that talks about OOB mitigation, how to use clamp to sanitize
15:37:49 <anssik> ... another related thing, some ops are more compute intensive than others e.g. conv* and may allocate a buffer for layout as an optimization
15:38:09 <anssik> ... such a buffer may be larger than the conv weights, for example
15:39:00 <anssik> ... in such cases we should do overflow checks, not sure if WebNN can impose that, it would be implementation-defined check
15:39:09 <anssik> ... to make sure the pointer does not overflow
15:39:29 <anssik> ... web spec should have non-normative section to inform the implementations
15:39:30 <anssik> q?
15:40:44 <anssik> q?
15:41:33 <anssik> MikeW: in general, anything resulting in undefined behaviour is not good, we should, as best we can, limit undefined behaviour, have default action
15:41:59 <anssik> ... e.g. in WebGPU OOB read would still be defined and you get no zero but some random data instead
15:42:28 <anssik> -> https://www.w3.org/TR/webgpu/#security-shader
15:43:09 <anssik> MikeW: this section was produced based on looking at the three major graphics APIs and observing how they behave
15:43:52 <RafaelCintron> https://registry.khronos.org/webgl/specs/latest/1.0/#4.5 has WebGL position.  Similar to WebGPU.
15:43:57 <DwayneR> Evidently Metal and DirectML have the same clamping behavior (clamped to buffer length rather than returning 0).
15:44:29 <anssik> Rafael: WebGL has similar text to what happens when you index OOB
15:44:50 <anssik> ... you get a value in a buffer or all zeros, it won't be able to access data that belongs to another domain
15:47:12 <DwayneR> +1
15:47:30 <Mike_Wyrzykowski> +1
15:47:35 <anssik> RESOLUTION: Open a meta issue to discuss out-of-bounds access issue in general and other security considerations.
15:47:47 <anssik> Subtopic: WPT runners for testing on GPU devices
15:48:02 <anssik> Anssi: in this topic, I wanted to discuss possible WPT runner improvements for GPUs
15:48:18 <anssik> ... and also check if our WebGPU folks have learning from the WebGPU CTS work
15:48:24 <anssik> -> https://github.com/gpuweb/cts/issues/2252
15:48:25 <gb> https://github.com/gpuweb/cts/issues/2252 -> Issue 2252 Export or move the WebGPU CTS into WPT (by kainino0x)
15:48:42 <anssik> Anssi: I provided as background material cost estimate from RustNN perspective drafted by Tarek
15:48:54 <anssik> ... I expect us to be in the same ballpark for the other implementers
15:49:22 <anssik> ... Tarek's cost estimate is 6k USD / year for RustNN across Linux/Windows/macOS if usage is capped to 1 hour/day
15:49:26 <anssik> ... if we add Chromium into the mix, and relax the daily cap, we'd multiply that with some number
15:49:51 <anssik> -> GitHub-hosted GPU runners cost estimate for rustnn https://docs.google.com/document/d/1zz1bc_RUpfM9uGzRH2AWWz5YDBZkRBbSAvU1iA8QFwo/
15:50:13 <anssik> Tarek: renting a box would be probably cheaper than renting GPUs per time unit
15:50:50 <anssik> ... if there are many projects that would use this infra, e.g. WebGPU, would be good to know if partners would like to have use their e.g. H100 GPU clusters to run these tests
15:50:51 <anssik> q?
15:51:55 <anssik> Ningxin: I think we don't have dedicated GPU bots in Chromium, we use SW only
15:52:00 <tarek8> q+
15:52:14 <anssik> ack tarek
15:52:47 <anssik> Tarek: we also may want to consider multi-GPU environments, moving data from GPU from another GPU, test with WebNN and WebGPU together
15:52:47 <anssik> q?
15:53:43 <anssik> Anssi: I will check if W3C has budget for this WPT infra improvement
15:53:48 <anssik> ... I think this would be a sponsorship opportunity for interested W3C members
15:55:20 <anssik> Dwayne: I think Kai's post notes WebGPU CTS is its own island, and Kai thinks WebGPU CTS should be put to WPT, WebGL is the same, part of Khronos Group
15:55:22 <tarek8> q?
15:56:52 <anssik> Tarek: Mozilla has boxes that could be used, I can also ask Hugging Face if they'd be interested in donating
15:57:09 <anssik> ... we want to have more projects to use this testing infra
15:58:07 <tarek8> +1
15:58:16 <anssik> RESOLUTION: Inform the W3C team about the suggested WPT runner infra improvements to support GPUs. Share cost estimates to understand the sponsorship opportunity for W3C members.
15:59:00 <anssik> RRSAgent, draft minutes
15:59:02 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/26-webmachinelearning-minutes.html anssik
16:02:09 <tarek8> servo fork: https://github.com/rustnn/servo-ml
16:02:52 <anssik> RRSAgent, draft minutes
16:02:53 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/26-webmachinelearning-minutes.html anssik
16:04:13 <anssik> s/pleased to new/pleased to see new
16:06:28 <anssik> s/freeDimensionOverride/freeDimensionOverrides
16:08:31 <anssik> s/flexibly/flexible
16:09:59 <anssik> s/there's are/there are
16:11:40 <anssik> s/and may/may
16:13:06 <anssik> s/learning from/learnings from
16:13:53 <anssik> s/e.g. WebGPU/e.g. also WebGPU
16:14:45 <anssik> s/have use/share
16:16:23 <anssik> s/Dwayne: I think Kai's/Rafael: I think Kai's
16:16:53 <anssik> RRSAgent, draft minutes
16:16:55 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/26-webmachinelearning-minutes.html anssik
18:01:11 <Zakim> Zakim has left #webmachinelearning