14:50:23 <RRSAgent> RRSAgent has joined #webmachinelearning
14:50:27 <RRSAgent> logging to https://www.w3.org/2026/04/23-webmachinelearning-irc
14:50:27 <Zakim> inviting RRSAgent
14:50:27 <Zakim> RRSAgent, make logs Public
14:50:28 <Zakim> please title this meeting ("meeting: ..."), anssik
14:50:30 <anssik> Meeting: WebML WG Teleconference – 23 April 2026
14:50:36 <anssik> Chair: Anssi
14:50:41 <anssik> Agenda: https://github.com/webmachinelearning/meetings/blob/main/telcons/2026-04-23-wg-agenda.md
14:50:46 <anssik> Scribe: Anssi
14:50:50 <anssik> scribeNick: anssik
14:50:58 <anssik> gb, this is webmachinelearning/webnn
14:50:58 <gb> anssik, OK.
14:51:02 <anssik> Present+ Anssi_Kostiainen
14:51:06 <anssik> Regrets+ Christian_Liebel
14:51:28 <anssik> RRSAgent, draft minutes
14:51:29 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/23-webmachinelearning-minutes.html anssik
14:55:26 <DwayneR> DwayneR has joined #webmachinelearning
14:55:42 <anssik> Present+ Dwayne_Robinson
14:57:42 <Winstonc> Winstonc has joined #webmachinelearning
14:58:27 <anssik> Present+ Winston_Chen
14:58:32 <lgombos> lgombos has joined #webmachinelearning
14:59:49 <anssik> Present+ Markus_Tavenrath
15:00:32 <anssik> Present+ Bryan_Bernhart
15:00:54 <anssik> Present+ Rafael_Cintron
15:01:13 <anssik> Present+ Ehsan_Toreini
15:01:18 <anssik> Present+ Ningxin_Hu
15:01:34 <RafaelCintron> RafaelCintron has joined #webmachinelearning
15:01:38 <anssik> RRSAgent, draft minutes
15:01:39 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/23-webmachinelearning-minutes.html anssik
15:02:34 <phillis> phillis has joined #webmachinelearning
15:02:46 <ningxin> ningxin has joined #webmachinelearning
15:02:56 <anssik> Present+ Phillis_Tang
15:03:03 <anssik> RRSAgent, draft minutes
15:03:04 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/23-webmachinelearning-minutes.html anssik
15:03:12 <lgombos> Present+ Laszlo_Gombos
15:03:14 <anssik> Anssi: please join me in welcoming the latest new participants to the WG:
15:03:18 <anssik> ... Yoav Weiss from Shopify
15:03:23 <anssik> ... Fidel Tian from Zoom
15:03:29 <anssik> ... Ali Spivak from Google
15:03:33 <anssik> Topic: Web Neural Network API
15:03:51 <anssik> Subtopic: Lower limit for conv2d/pool2d kernel sizes, dilations, strides
15:04:02 <anssik> Anssi: issue #928
15:04:03 <gb> 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:04:10 <handellm> handellm has joined #webmachinelearning
15:04:19 <anssik> ... I'd like to have a group discussion on the edge cases reported in the issue that may cause integer overflows
15:04:30 <anssik> ... and also discuss the proposed mitigations to be codified in the specification
15:04:36 <mtavenrath> mtavenrath has joined #webmachinelearning
15:04:57 <anssik> ... Phillis reports she found edge cases in pool2d and conv2d when "unreasonably large" sizes for the parameters are used
15:05:07 <anssik> ... this may cause integer overflows in some backends
15:05:10 <zolkis> zolkis has joined #webmachinelearning
15:05:17 <anssik> ... Phillis notes in real-life use cases these parameters never have such large values
15:05:29 <anssik> ... and thus proposes as mitigations parameter upper bounds that are "reasonable for all use cases"
15:05:36 <anssik> ... this helps with fuzz testing by limiting scope
15:05:40 <anssik> ... initial proposal suggests the following size limits:
15:05:44 <anssik> ... kernel size 1024
15:05:51 <anssik> ... strides and dilations 256
15:07:18 <anssik> Phillis: Dillon works for TFLite and proposed checks to fix "fishy" parameter sizes
15:07:31 <anssik> -> https://github.com/webmachinelearning/webnn/issues/928#issuecomment-4284066424
15:07:31 <gb> 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:08:29 <tarek> tarek has joined #webmachinelearning
15:08:51 <tarek> Sorry I am late.
15:08:55 <anssik> Dwayne: I agree with limits on the high level, I want to be cautious picking arbitrary ranges that we feel should be safe
15:09:30 <anssik> ... express in terms of inputs instead, some of our samples e.g. SD use more than the initially proposed limits
15:09:42 <anssik> ... want to be careful to not break things with these limits
15:09:54 <anssik> ... Dillon's statements are in terms of input sizes and as such relative metrics
15:10:31 <anssik> Anssi: "these rules would catch some valid graphs, but [...] unlikely that "real" graphs would violate these checks"
15:11:09 <anssik> Dwayne: would help to have collection of cases where we have int overflows in backends
15:11:31 <anssik> Anssi: Phillis, can that information we shared in public?
15:12:02 <anssik> Phillis: will check with the team
15:12:10 <anssik> Present+ Tarek_Ziade
15:12:14 <mtavenrath> q+
15:12:38 <anssik> Ningxin: I haven't yet received an update from investigation from my side
15:12:39 <anssik> q?
15:12:42 <anssik> ack mtavenrath
15:12:47 <anssik> Present+ Zoltan_Kis
15:12:55 <anssik> Present+ Markus_Handell
15:13:42 <anssik> MarkusT: should WebNN do this, or should different backends do this? Can we expose underlying limits of the backend, would this cause fragmentation
15:13:44 <handellm> handellm has joined #webmachinelearning
15:14:48 <anssik> q?
15:15:36 <anssik> Dwayne: I'll review Dillon's checks with additional information provided
15:16:18 <anssik> Subtopic: conv2d output channels validation
15:16:22 <anssik> Anssi: issue #925
15:16:22 <gb> https://github.com/webmachinelearning/webnn/issues/925 -> Issue 925 Mandate `output_channels % groups == 0` validation for conv2d (by lynne0326) [security-tracker] [Agenda+]
15:16:54 <anssik> Phillis: Lynne from Google works on WebNN
15:17:09 <anssik> Anssi: let's discuss the issue and review the proposed spec change
15:18:20 <anssik> Phillis: this issue also triggers some errors in the backends and we'd like to the proposed validation to the spec for conv2d
15:18:39 <anssik> ... proposed spec change: "The specification must mandate that the total number of output channels is a multiple of the groups attribute."
15:19:25 <anssik> Anssi: motivation: "This eliminates an entire class of potential buffer overflows before the graph is ever compiled."
15:19:57 <handellm> handellm has joined #webmachinelearning
15:20:05 <anssik> Anssi: as future work, add the same validation to convTranspose2d if it adds support for groups > 1 that'd cause OOB write
15:20:06 <ningxin> +q
15:20:09 <anssik> ack ningxin
15:20:15 <DwayneR> I think this restriction should be okay.
15:20:52 <anssik> Ningxin: I think this is a good addition, looking at conv2d groups attribute, it also mentions channels are divided in two, just need to add this to the validation step, +1 from me
15:20:54 <anssik> q?
15:21:17 <anssik> MarkusT: it is a good change, +1 from me
15:23:24 <anssik> Anssi: Dwayne +1'd
15:23:30 <anssik> RESOLUTION: Add the proposed mitigation to conv2d spec to eliminate potential buffer overflows. (issue #925)
15:23:55 <anssik> Subtopic: MLComputePolicy naming
15:24:01 <anssik> Anssi: PR #923
15:24:01 <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] [Agenda+]
15:24:15 <anssik> ... we are close to landing this PR
15:24:22 <anssik> ... the remaining thing we need to agree on is naming
15:24:29 <anssik> ... MikeW approved with "fallback" as the name
15:24:45 <anssik> ... I see Dwayne's "compatible" alternative name has merit and warrants discussion
15:24:50 <anssik> ... the staged PR has the following names for the MLComputePolicy:
15:24:57 <anssik> [[
15:24:57 <anssik> enum MLComputePolicy {
15:24:57 <anssik>   "default",
15:24:57 <anssik>   "high-performance",
15:24:57 <anssik>   "low-power",
15:24:57 <anssik>   "fallback"
15:24:57 <anssik> };
15:24:58 <anssik> ]]
15:25:02 <anssik> Anssi: the proposed alternative is "fallback" -> "compatible":
15:25:08 <anssik> [[
15:25:08 <anssik> enum MLComputePolicy {
15:25:08 <anssik>   "default",
15:25:08 <anssik>   "high-performance",
15:25:08 <anssik>   "low-power",
15:25:08 <anssik>   "compatible"
15:25:08 <anssik> };
15:25:09 <anssik> ]]
15:25:24 <anssik> Anssi: Web Platform Design Principles that has a section called "Naming principles" to help spec authors choose names:
15:25:28 <anssik> -> https://www.w3.org/TR/design-principles/#naming-is-hard
15:25:41 <anssik> Anssi: I put these two names, "fallback" and "compatible", through this test to inform the naming decision:
15:26:00 <anssik> ... - 12.1 Use common words - both "fallback" and "compatible" are readable US English
15:26:07 <anssik> ... - 12.2 Use ASCII names - both "fallback" and "compatible" pass this test with flying colors
15:26:27 <anssik> ... - 12.3 Consult others on naming - "fallback" in more common name on the web platform
15:26:31 <anssik> -> "fallback" name in WebGPU and CSS https://dontcallmedom.github.io/webdex/f.html#[[fallback]]@@adapter@attribute
15:26:36 <anssik> -> "compatMode" name in DOM https://dontcallmedom.github.io/webdex/c.html#compatMode@@Document@attribute
15:27:01 <anssik> ... - 12.4 Use names that describe a purpose - "compatible" seems better aligned with TAG principles
15:27:12 <anssik> ... TAG says "Name things for what they do, not how they do it."
15:27:22 <anssik> ... "fallback" tells how to do it ("use fallback device")
15:27:30 <anssik> ... "compatible" describes behavior ("use device that provides maximum compatibility")
15:27:51 <anssik> ... - 12.5 Name things consistently - "compatible" seems more consistent within MLComputePolicy names
15:28:00 <anssik> ... TAG says "Naming schemes should aim for consistency, to avoid confusion"
15:28:14 <anssik> ... "compatible", "high-performance" and "low-power" all describe what is to be prioritized
15:28:20 <anssik> ... "fallback" describes how to do it
15:28:33 <anssik> ... the non-scientific TAG naming principles test score, using equal weight for all tests:
15:28:37 <anssik> ... - "fallback" 3/5 - fails tests 12.4 and 12.5
15:28:41 <anssik> ... - "compatible" 4/5 - fails test 12.3
15:28:53 <anssik> ... if we give more weight to naming consistency within the web platform APIs it is a tie
15:29:08 <anssik> ... my gut feeling is folks who try WebNN are also familiar with WebGPU
15:29:21 <anssik> q?
15:29:47 <handellm> +q
15:29:47 <anssik> ... I see preference from Dwayne and Zoltan for the "compatible" name, Markus seems indifferent?
15:29:53 <anssik> ack handellm
15:30:27 <anssik> MarkusH: I was wondering, as a follow up, would be nice to have an effective compute policy on Graph.devices
15:30:29 <zolkis> q+
15:30:48 <anssik> ... slight preference for "fallback"
15:31:02 <anssik> ack zolkis
15:31:20 <mtavenrath> mtavenrath has joined #webmachinelearning
15:31:31 <anssik> Zoltan: an original issue connected to this PR, used "fallback" as the name
15:31:52 <anssik> ... argument for fallback was then that WebGPU is also using it, but WebGPU prefers an adapter concept that does not exist in WebNN
15:32:12 <anssik> ... so adapter and ComputePolicy do not go so well together
15:32:51 <anssik> ... ComputePolicy being fallback is not too far from WebGPU fallback adapter
15:32:57 <anssik> ... adding more consideration
15:33:21 <anssik> q?
15:34:25 <RafaelCintron> +1
15:34:32 <RafaelCintron> +q
15:34:37 <anssik> ack RafaelCintron
15:34:56 <anssik> Rafael: we prefer "fallback" to keep aligned with WebGPU naming
15:35:27 <Ehsan> Ehsan has joined #webmachinelearning
15:36:18 <anssik> Dwayne: I can live with "fallback"
15:38:15 <anssik> MarkusT: should we have a priority list of devices?
15:38:31 <zolkis> we started long ago with a priority list
15:39:54 <anssik> Zoltan: we have an explainer with background discussion
15:40:14 <anssik> RESOLUTION: Use MLComputePolicy "fallback" as the name for maximum compatibility preference. (PR #923)
15:40:28 <anssik> Anssi: other enhancements from this PR, to be addressed in a separate PR:
15:40:38 <anssik> ... - "low-latency" MLComputePolicy, example use case audio processing
15:40:59 <anssik> ... - "precision" MLContextOptions, to signal chopping off low bits is not preferred for this context
15:41:40 <anssik> q?
15:41:42 <anssik> Subtopic: Bounded dynamic dimension
15:41:50 <anssik> Anssi: issue #883
15:41:50 <gb> https://github.com/webmachinelearning/webnn/issues/883 -> Issue 883 Support flexible input sizes (by huningxin) [feature request] [operator specific] [Agenda+]
15:41:57 <anssik> ... thanks Ningxin and Markus for providing new information for this consideration
15:42:10 <anssik> ... first, ORT Web does not currently support dimension bounds
15:42:23 <anssik> ... Ningxin proposed to add freeDimensionBounds similar to freeDimensionOverrides in WebNN EP session options, Guenther was pinged
15:42:53 <anssik> Ningxin: I will catch up with Guenther
15:43:15 <anssik> Anssi: Markus notes some backends could accept any shape size, thus min/max bounds are to be considered as hints
15:43:42 <anssik> ... this is backend specific, questions to ONNX team how to handle this in a compatible manner across all backends
15:44:11 <anssik> s/questions to/question to
15:45:26 <anssik> Ningxin: two aspects, ONNX Runtime API, another is EP interface, for the EP interface we can talk with a person in ONNX team with Rafael
15:45:58 <anssik> ... Ningxin reports SOTA image generation model Z-Image-Turbo, cannot be supported by only having input dynamic dimension as in the previous proposal shared on Feb 11:
15:46:01 <anssik> -> https://github.com/webmachinelearning/webnn/issues/883#issuecomment-3885459576
15:46:01 <gb> https://github.com/webmachinelearning/webnn/issues/883 -> https://github.com/webmachinelearning/webnn/issues/883
15:46:20 <anssik> Anssi: to address this limitation, Bin and Wanming prototyped 9 new ops to enable Z-Image-Turbo successfully:
15:46:29 <anssik> [[
15:46:29 <anssik> + MLOperand mod(MLOperand a, MLOperand b, optional MLOperatorOptions options = {});
15:46:29 <anssik> 
15:46:29 <anssik> + MLOperand shape(MLOperand input, optional MLOperatorOptions options = {});
15:46:29 <anssik> 
15:46:30 <anssik> + MLOperand range(MLOperand start, MLOperand limit, MLOperand delta, optional MLOperatorOptions options = {});
15:46:30 <anssik> 
15:46:30 <anssik> + MLOperand dynamicReshape(MLOperand input, MLOperand newShape, optional MLOperatorOptions options = {});
15:46:31 <anssik> 
15:46:31 <anssik> + MLOperand dynamicExpand(MLOperand input, MLOperand newShape, optional MLOperatorOptions options = {});
15:46:31 <anssik> 
15:46:32 <anssik> + MLOperand dynamicSlice(MLOperand input, MLOperand starts, MLOperand ends, optional MLOperatorOptions options = {});
15:46:32 <anssik> 
15:46:32 <anssik> + MLOperand dynamicPad(MLOperand input, MLOperand pads, optional MLOperatorOptions options = {});
15:46:33 <anssik> 
15:46:33 <anssik> + sequence<MLOperand> dynamicSplit(MLOperand input, MLOperand splits, unsigned long numOutputs, optional MLOperatorOptions options = {});
15:46:33 <anssik> 
15:46:34 <anssik> + MLOperand dynamicResample2d(MLOperand input, MLOperand sizes, optional MLDynamicResample2dOptions options = {});
15:46:34 <anssik> ]]
15:46:40 <anssik> -> https://github.com/webmachinelearning/webnn/issues/883#issuecomment-4302848951
15:46:41 <gb> https://github.com/webmachinelearning/webnn/issues/883 -> Issue 883 Support flexible input sizes (by huningxin) [feature request] [operator specific] [Agenda+]
15:47:06 <anssik> Ningxin: I want to get the group's feedback for there new proposed ops
15:47:44 <anssik> ... dynamic size calculation required within the graph, initial proposal allows develop to define dynamic dimensions at input, placeholder with name and bounds
15:48:22 <anssik> ... this new model and other Transformers.js models require share calculation, using pad-to-chunks algorithm
15:48:41 <anssik> ... later we want to pad the input to multiple chunks, padding size need to be calculated at runtime
15:49:02 <anssik> ... must get shape at runtime and return tensor shape in another tensor, int64 or uint32
15:49:23 <anssik> ... tensor size used by other calculations to calculate e.g. padding to chunk size value
15:49:31 <anssik> ... only static padding supported currently
15:50:03 <anssik> ... dynamic size should be accepted, that's why we proposed dynamicPad
15:50:43 <anssik> ... 9 proposed ops, one missing, sample element-wise unary op
15:51:21 <anssik> ... they are dynamic versions of existing ops, e.g. dynamicReshape
15:51:43 <anssik> ... range is a tensor generation op
15:51:57 <anssik> ... Z-Image-Turbo has three models
15:52:40 <anssik> ... this proposal to add 9 new ops is in addition to the previous proposal that is also required, both are required
15:53:08 <anssik> ... we can validate tensor shape, dynamic version of this op, you don't know what the output tensor size is at build time
15:53:25 <anssik> ... next step to explore dispatch-time shape validation when all tensors' sizes are specified or can be inferred
15:54:02 <anssik> q?
15:54:49 <anssik> Anssi: multiple new models require these new features?
15:54:55 <anssik> Ningxin: correct
15:55:11 <anssik> q?
15:56:21 <anssik> MarkusT: thank you Ningxin for this work
15:57:21 <RafaelCintron> q+
15:57:24 <anssik> Anssi: everyone happy with the direction and the proposed next steps?
15:57:27 <anssik> ack RafaelCintron
15:58:19 <anssik> Rafael: I'm supportive of this work if we can do this, given some platforms are more challenging wrt dynamic shapes
15:59:13 <anssik> MarkusT: some NPUs may have problems supporting this, in those cases GPU or CPU could be used as a fallback
15:59:52 <anssik> Ningxin: I think fallback compute policy provides a solution to that issue
15:59:53 <anssik> q?
16:00:51 <anssik> RRSAgent, draft minutes
16:00:53 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/23-webmachinelearning-minutes.html anssik
16:09:57 <anssik> s/Ningxin reports //
16:10:36 <anssik> s/develop to/developer to
16:10:57 <anssik> s/share calculation/shape calculation
16:11:14 <anssik> s/need to be/needs to be
16:11:59 <anssik> s/proposal to add/proposal is to add
16:12:16 <anssik> s/is in addition/in addition
16:13:00 <anssik> RRSAgent, draft minutes
16:13:02 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/23-webmachinelearning-minutes.html anssik
18:30:31 <Zakim> Zakim has left #webmachinelearning
19:48:12 <gb> gb has joined #webmachinelearning