13:55:45 RRSAgent has joined #webmachinelearning 13:55:49 logging to https://www.w3.org/2024/05/02-webmachinelearning-irc 13:55:49 RRSAgent, make logs Public 13:55:50 please title this meeting ("meeting: ..."), anssik 13:56:19 Meeting: WebML WG Teleconference – 2 May 2024 13:56:29 Chair: Anssi 13:56:29 Agenda: https://github.com/webmachinelearning/meetings/blob/main/telcons/2024-05-02-wg-agenda.md 13:56:37 Scribe: Anssi 13:56:41 scribeNick: anssik 13:56:48 gb, this is webmachinelearning/webnn 13:56:48 anssik, OK. 13:57:02 Present+ Anssi_Kostiainen 13:57:15 RRSAgent, draft minutes 13:57:16 I have made the request to generate https://www.w3.org/2024/05/02-webmachinelearning-minutes.html anssik 13:58:23 jsbell has joined #webmachinelearning 13:58:37 Present+ Joshua_Bell 13:58:46 Present+ Dwayne_Robinson 13:59:25 dwayner has joined #webmachinelearning 13:59:41 McCool has joined #webmachinelearning 13:59:42 zkis has joined #webmachinelearning 14:00:10 Present+ Zoltan_Kis 14:00:10 Present+ Michael_McCool 14:00:46 Present+ Ilya_Rezvov 14:00:54 Present+ Austin_Sullivan 14:01:15 Present+ Mike_Wyrzykowski 14:01:48 Regrets+ Ningxin_Hu 14:01:59 Regrets+ Rafael_Cintron 14:02:20 anssik: please join me in welcoming our latest WG participant! 14:02:26 ... - Yunchao He representing ByteDance 14:02:28 zkis: If you can visit chrome://crashes/ and email me any crash IDs I'll follow up 14:02:54 ningxin has joined #webmachinelearning 14:03:02 ... I did a small update to our agenda an hour ago: removed issues #492 #625 that had been addressed (thanks!), removed #475 whose accompanying PR #650 received a draft label; I also added one quick naming-related issue #669 14:03:02 https://github.com/webmachinelearning/webnn/pull/650 -> Pull Request 650 Swap parameters of scalar constant() operand method (by inexorabletash) 14:03:03 https://github.com/webmachinelearning/webnn/issues/669 -> Issue 669 Rename `MLOperandDescriptor`'s `dimensions` to `shape` (by a-sully) [feature request] 14:03:03 https://github.com/webmachinelearning/webnn/issues/625 -> CLOSED Issue 625 Need clarify the maximum limit of the hidden size of the Gru operator (by miaobin) [operator specific] 14:03:03 https://github.com/webmachinelearning/webnn/issues/475 -> Issue 475 Remove `builder.constant(value, type)` variant (by huningxin) [operator specific] 14:03:07 https://github.com/webmachinelearning/webnn/issues/492 -> CLOSED Issue 492 Constant sequential filling operation needs output shape parameter (by fdwr) [feature request] [operator specific] 14:03:11 -> agenda diff https://github.com/webmachinelearning/meetings/commit/771dc249fcc03a2c33c7f33e4b1d14b1871545a7 14:03:26 asully has joined #webmachinelearning 14:03:34 ... with that let's kick off today's meeting with a new incubation that might be of interest to this group to warm up the engine 14:03:40 Present+ Austin_Sullivan 14:03:51 Topic: New incubation of possible interest: Web Translation API 14:03:57 Joshua_Lochner has joined #webmachinelearning 14:04:04 anssik: I want to bring to this WG's attention an early proposal by the Chrome translate API team, Web Translation API, for performing real-time translations 14:04:14 Present+ Joshua_Lochner 14:04:20 -> Explainer for the Web Translation API https://github.com/explainers-by-googlers/translation-api 14:04:23 -> TAG review for the Web Translation API https://github.com/w3ctag/design-reviews/issues/948 14:04:24 https://github.com/w3ctag/design-reviews/issues/948 -> Issue 948 Web Translation API (by domenic) [Progress: untriaged] 14:04:42 anssik: to be clear, this API is not in scope of the WG currently but with adequate support and incubation this API has potential to become a new deliverable of this WG when we charter next time in 2025 14:04:51 ... please let me know if you have any feedback, now or later 14:05:09 anssik: this API intersects with our recent discussion on Hybrid AI, quoting the explainer: "Allow a variety of implementation strategies, including on-device vs. cloud-based translation, while keeping these details abstracted from developers." 14:05:13 ... I believe a hybrid approach could also be feasible for this API 14:05:18 phillis has joined #webmachinelearning 14:05:46 Present+ Phillis_Tang 14:06:07 Topic: NPU support 14:06:12 anssik: issue #623 14:06:13 https://github.com/webmachinelearning/webnn/issues/623 -> Issue 623 WebNN should support NPU and QDQ operations (by wchao1115) [v2] [opset] [feature request] 14:06:22 anssik: given this is a new feature, I want to slot this topic in again to ensure all feedback is captured 14:06:37 ... thanks Dwayne, Phillis, Zoltan for sharing your proposals and feedback in the the GH issue as well as all the fine folks working on the prototype 14:06:51 ... I want to gauge consensus on on the MLDeviceType design specifically: 14:07:00 ... Dwayne with contributions from Phillis' has put together a pros/cons summary of the 4 options for extending MLDeviceType to to document the WG's current thinking: 14:07:04 -> 4 options for extendingMLDeviceType https://github.com/webmachinelearning/webnn/issues/623#issuecomment-2063954107 14:07:04 https://github.com/webmachinelearning/webnn/issues/623 -> Issue 623 WebNN should support NPU and QDQ operations (by wchao1115) [v2] [opset] [feature request] 14:07:07 ... anssik: the 4 options proposed with (+pros -cons): 14:07:19 ... 1) deviceType: "npu" (+++ -) 14:07:19 ... 2) deviceType: "npu" fallbackDeviceType: "gpu" (+ --) 14:07:19 ... 3) deviceTypes: ["npu", "gpu"] (+ --) 14:07:19 ... 4) deviceType: "npu", excludesDeviceTypes: ["gpu"] 14:07:37 ... is the WG ready to let the editors start a PR to formalize option 1 in the spec reflecting what is prototyped in Chromium? 14:07:39 q? 14:08:09 Dwayne: not a lot of comments, the easier approach would be option 1 14:08:31 ... and if no additional ops are proposed this could become de facto standard, it is aligned with the prototype currently 14:09:10 Mike3 has joined #webmachinelearning 14:09:45 q? 14:09:52 ... any further implementation experience to be shared from running models on NPUs completely using the prototype is welcome at any time 14:10:04 s/any further/anssik: 14:10:31 Dwayne: working on a few models, MobileNet, SqueezeNet, ResNet, one transformer model 14:10:43 q+ 14:10:47 ack jsbell 14:11:04 jsbell: +1 to Phillis' recommendation for option 1 14:11:22 ... we may grow to option 3 in the future, but good to start with 1 14:11:24 q? 14:11:38 q? 14:12:14 start with 1, move to 3 as needed seems reasonable 14:12:24 +1 to start with option 1 14:12:48 Present+ Ningxin_Hu 14:13:17 anssik: editors can start formalize the NPU design starting with option 1 14:13:40 q? 14:13:42 Topic: MLBuffer 14:13:50 anssik: issue #542 14:13:51 https://github.com/webmachinelearning/webnn/issues/542 -> Issue 542 [MLBuffer] Creation and representing MLBuffer on a XPU devices (by bbernhar) [webgpu interop] 14:14:19 ... over the last few weeks Austin has investigated supporting MLBuffer on CoreML and shared his suggestions in the issue (thanks!) that discusses creating and representing MLBuffer on XPU devices 14:14:25 ... Austin investigation spurred an active discussion, thanks everyone! 14:14:43 ... I'll hand the mic to Austin to explain what he has found out and to summarize the current state of things to the broader group 14:15:11 asully: a good summary in the table in https://github.com/webmachinelearning/webnn/issues/542#issuecomment-2067555410 14:15:12 https://github.com/webmachinelearning/webnn/issues/542 -> Issue 542 [MLBuffer] Creation and representing MLBuffer on a XPU devices (by bbernhar) [webgpu interop] 14:15:35 asully: zero-copy on CoreML only with fp16, Mike to confirm 14:15:44 ... also data type and shape must be known 14:15:49 yes that's right 14:15:59 ... MLBuffer is a platform-specific tensor and you need to know the shape and data type 14:16:13 ... to pass MLBuffers as input and output both have shape and data type 14:16:45 ... some backends have issues with zero-copy, so argument is that MLBuffer is a tensor and data type and shape should to know up front 14:16:46 q? 14:17:48 asully: thanks Mike for confirming CoreML support status 14:18:07 ... TL;DR: if we don't know data type and shape ahead of time cannot do zero copy 14:19:18 Present+ Deepti_Gandluri 14:19:53 asully: Bryan from Intel has a prototype for MLBuffer, once Bryan's change in landed we can add the Mac prototype on top 14:20:08 ... on some platforms you can allocate an opaque buffer but that is not the case on CoreML 14:20:17 +1 14:20:21 +q 14:21:15 asully: I looked at ONNX Runtime and CoreML backend while doing this prototyping 14:21:23 ack ningxin 14:22:00 ningxin: ONNX Runtime IO Banding allocator interface only pass size when allocating device buffer 14:22:32 ... if we don't change the interface we can allocate this information, pass shape and data type with help from the framework side, so probably want to pull in framework people 14:22:58 asully: if you want to implement these buffers on Mac need to make the same changes (to frameworks) as is proposed to WebNN 14:23:06 ningxin: did you file an ONNX RT issue? 14:23:10 asully: will do that 14:23:25 q? 14:23:47 q+ 14:23:51 ack ningxin 14:24:26 ningxin: another thing, working with Bryan we prototype dispatch pass, optimize Whisper decoder, KV cache 14:24:42 ... we see good performance improvement from up to 50% running on GPU 14:24:59 ... through the prototype found we may need another operator to update the KV cache from the previous iteration to the next one 14:25:14 ... WebNN is static shaped design, so KV cache needs to be allocated as an MLBuffer 14:25:23 ... with adequate size to accommodate that 14:26:01 ... need another tensor to append from the previous to the next, probably want to propose scatternd operator, counterpart to gather, can share this obsercation in another issue to inform the group 14:26:16 s/obsercation/observation 14:26:22 q? 14:26:35 Topic: Open issues and PRs 14:26:40 Subtopic: Debrief on PRs merged recently 14:26:53 anssik: JoshuaB has again submitted a bunch of PR that fixed a number of issues. Thanks again! 14:27:13 ... issue #465 fixed by PR #648 14:27:14 https://github.com/webmachinelearning/webnn/pull/648 -> MERGED Pull Request 648 Editorial: Add note about keepDimensions of reduction ops (by inexorabletash) 14:27:14 https://github.com/webmachinelearning/webnn/issues/465 -> CLOSED Issue 465 `keepDimensions` of reduction ops (by lisa0314) [operator specific] 14:27:25 ... issue #645 fixed by PR #651 14:27:26 https://github.com/webmachinelearning/webnn/pull/651 -> MERGED Pull Request 651 Remove softplus() steepness option (by a-sully) 14:27:26 https://github.com/webmachinelearning/webnn/issues/645 -> CLOSED Issue 645 Consider removing `steepness` parameter of softplus (by shiyi9801) [operator specific] 14:27:36 ... issue (n/a) fixed by PR #655 14:27:37 https://github.com/webmachinelearning/webnn/pull/655 -> MERGED Pull Request 655 gru/lstm: Fix missing/incorrect variables and options use (by inexorabletash) 14:27:43 ... issue #466 fixed by PR #649 14:27:44 https://github.com/webmachinelearning/webnn/issues/466 -> CLOSED Issue 466 Softmax axis absent (by fdwr) [operator specific] 14:27:44 https://github.com/webmachinelearning/webnn/pull/649 -> MERGED Pull Request 649 Add axis argument to softmax() (by inexorabletash) 14:27:51 ... issue #283 fixed by PR #646 (with follow-ups to be discussed later) 14:27:51 https://github.com/webmachinelearning/webnn/pull/646 -> MERGED Pull Request 646 Specify the operand data type constraints of operations (by inexorabletash) 14:27:51 https://github.com/webmachinelearning/webnn/issues/283 -> CLOSED Issue 283 Specify the operand data type constraints of operation (by huningxin) [question] 14:27:58 ... issue #492 fixed by PR #656 14:27:58 https://github.com/webmachinelearning/webnn/pull/656 -> MERGED Pull Request 656 Remove sequential filling overload of constant() (by a-sully) 14:27:58 https://github.com/webmachinelearning/webnn/issues/492 -> CLOSED Issue 492 Constant sequential filling operation needs output shape parameter (by fdwr) [feature request] [operator specific] 14:28:02 ... issue #660 fixed by PR #661 14:28:03 https://github.com/webmachinelearning/webnn/pull/661 -> MERGED Pull Request 661 Bugfix: prelu should validate slope operand (by huningxin) 14:28:03 https://github.com/webmachinelearning/webnn/issues/660 -> CLOSED Issue 660 prelu steps should validate the data type of slope is equal to the data type of input (by huningxin) [bug] 14:28:07 ... issue #614 fixed by PR #665 14:28:07 https://github.com/webmachinelearning/webnn/pull/665 -> MERGED Pull Request 665 Add note about no-op graphs (by inexorabletash) 14:28:07 https://github.com/webmachinelearning/webnn/issues/614 -> CLOSED Issue 614 Allow no-op graphs? (by inexorabletash) [question] 14:28:10 ... issue #625 fixed by PR #644 14:28:12 https://github.com/webmachinelearning/webnn/pull/644 -> MERGED Pull Request 644 Validate the hidden size of GRU and LSTM operators (by inexorabletash) 14:28:13 https://github.com/webmachinelearning/webnn/issues/625 -> CLOSED Issue 625 Need clarify the maximum limit of the hidden size of the Gru operator (by miaobin) [operator specific] 14:28:17 ... issue (n/a) fixed by PR #659 14:28:18 https://github.com/webmachinelearning/webnn/pull/659 -> MERGED Pull Request 659 Simplify, correct, and add validation for GRU/LSTM and friends (by inexorabletash) 14:29:01 jsbell: issue #283 and PR #646 added data type constraints, thanks for reviewers! 14:29:14 #657 14:29:15 https://github.com/webmachinelearning/webnn/pull/657 -> Pull Request 657 Make operand data type and rank validation table-driven (by inexorabletash) 14:29:23 ... a follow-up for table-driven design PR #657 14:29:36 ... if folks want to look at it much appreciated 14:29:53 ... definitely want feedback how does this work for implementers and people writing tests 14:29:54 q? 14:31:16 Dwayne: many PRs are goodness, some have potential to break existing implementation, can we add a label to PRs that may break existing implementations? 14:31:59 jsbell: I can look into best practices on labeling PRs 14:32:15 asully: some mark things as editorial that do not make normative changes that impact implementations 14:33:05 q? 14:33:23 Subtopic: [bug] ArgMax/Min selectLastIndex is not supported on CoreML 14:33:27 anssik: issue #652 14:33:28 https://github.com/webmachinelearning/webnn/issues/652 -> Issue 652 ArgMax/Min `selectLastIndex` is not supported on CoreML (by philloooo) [bug] [operator specific] 14:33:41 ... a proposal from Phillis to consider removing selectLastIndex parameter due to CoreML compatibility 14:33:55 ... Phillis asked if CoreML "argmax is guaranteed to return smaller index?" 14:34:02 ... Mike responded "is not guaranteed and may change" 14:34:10 ... Dwayne proposes some options in the issue I'd like to discuss with the group 14:34:16 ... and hear if someone has other solutions in mind? 14:34:47 I'm speaking with CoreML on the first one 14:34:58 Dwayne: currently not guaranteed this won't change, so can ask Apple to codify one behavior 14:35:33 ... another possibility, there's multiple Apple APIs, we're focused on CoreML, not sure of technical considerations for choosing it over BNNS and MPS for example 14:35:34 BNNS and MPS will not run on the NPU 14:35:51 ... even if undocumented, could also add more ops to address this 14:36:17 ... we could also keep the flag and then some backends would diverge, increases testing complexity 14:36:32 ... last possibility to remove the flag entirely 14:36:58 ... PT and TF decide ties in different way, ONNX has a similar flag 14:36:59 q? 14:37:14 q+ 14:37:17 ack anssik 14:37:44 Mike: only issue with BNNS and MPS is that they don't run on NPU 14:37:57 ... working with engineers on what is possible and will get back to you on the issue 14:38:12 q? 14:38:39 Phillis: option 1 or option 4 are the practical options 14:39:00 ... removing is the simplest way to go 14:39:22 Dwayne: the main reason for the flag is TF and PT can can supported because they have different defaults 14:39:46 ... not sure of any models where this matters 14:39:49 q+ 14:39:59 q? 14:40:01 ack jsbell 14:40:27 op-specific: 654 653 652 629 487 481 444 396 392 383 324 180 14:40:27 broader: 668 658 623 590 489 456 391 14:40:36 jsbell: tangentially, there's a cluster like this one related to interop, is there interest to introduce a [interop] label for these? 14:40:57 ... op-specific: #654 #653 #652 #629 #487 #481 #444 #396 #392 #383 #324 #180 14:40:57 ... broader: #668 #658 #623 #590 #489 #456 #391 14:40:58 https://github.com/webmachinelearning/webnn/issues/652 -> Issue 652 ArgMax/Min `selectLastIndex` is not supported on CoreML (by philloooo) [bug] [operator specific] 14:40:58 https://github.com/webmachinelearning/webnn/issues/654 -> Issue 654 Consider dropping the support of uint64/int64 data type for some operators (by lisa0314) [bug] [operator specific] 14:40:58 https://github.com/webmachinelearning/webnn/issues/653 -> Issue 653 Consider changing output type of ArgMax/Argmin to int32, or allow passing output_type (by philloooo) [bug] [operator specific] 14:41:00 https://github.com/webmachinelearning/webnn/issues/444 -> Issue 444 Zero dilations needs spec clarification (by fdwr) [operator specific] 14:41:03 https://github.com/webmachinelearning/webnn/issues/392 -> Issue 392 `split` into sizes are not widely supported (by huningxin) [operator specific] 14:41:07 https://github.com/webmachinelearning/webnn/issues/383 -> Issue 383 Need to restrict the value of alpha to be positive for elu operation (by lisa0314) [operator specific] 14:41:10 https://github.com/webmachinelearning/webnn/issues/481 -> Issue 481 Should `scale` and `bias` be required inputs for `batchNormalization` op? (by huningxin) [operator specific] 14:41:14 https://github.com/webmachinelearning/webnn/issues/629 -> Issue 629 argMax/Min only support scalar axis in TFLite runtime (by fujunwei) [operator specific] 14:41:17 https://github.com/webmachinelearning/webnn/issues/396 -> Issue 396 Clarify the restriction for `minValue` and `maxValue` of `MLClampOptions` (by huningxin) [operator specific] 14:41:21 https://github.com/webmachinelearning/webnn/issues/456 -> Issue 456 Define the maximum number of operand dimensions (maximum rank) (by huningxin) 14:41:25 https://github.com/webmachinelearning/webnn/issues/180 -> Issue 180 Should dilated pooling be supported (by fujunwei) [operator specific] 14:41:28 https://github.com/webmachinelearning/webnn/issues/391 -> Issue 391 Allow 0 size dimensions (by huningxin) [feature request] 14:41:31 https://github.com/webmachinelearning/webnn/issues/487 -> Issue 487 Should `axes` be required parameter for layerNormalization build method? (by huningxin) [operator specific] 14:41:35 https://github.com/webmachinelearning/webnn/issues/590 -> Issue 590 Consider adopting new broadcasting rules (by a-sully) [question] 14:41:38 https://github.com/webmachinelearning/webnn/issues/324 -> Issue 324 Simplify the operand layout support of conv2d and pooling 2d operations (by huningxin) [feature request] [operator specific] 14:41:39 anssik: would this [interop] be helpful for the group, thoughts? 14:41:42 https://github.com/webmachinelearning/webnn/issues/489 -> Issue 489 Clarify the casting behavior from floating-point / signed integers <-> unsigned integers (by huningxin) 14:41:46 https://github.com/webmachinelearning/webnn/issues/623 -> Issue 623 WebNN should support NPU and QDQ operations (by wchao1115) [v2] [opset] [feature request] 14:41:49 https://github.com/webmachinelearning/webnn/issues/668 -> Issue 668 Do we need an `MLConstantOperand`? (by a-sully) [question] 14:41:53 https://github.com/webmachinelearning/webnn/issues/658 -> Issue 658 Consider removing `MLActivation` parameters used for op fusion (by a-sully) [question] 14:42:19 q? 14:42:39 Subtopic: [bug] Consider changing output type of ArgMax/Argmin to int32, or allow passing output_type 14:42:43 anssik: issue #653 14:42:49 ... Phillis reports: 14:43:00 ... Currently WebNN specifies ArgMax/Min returns int64. 14:43:10 ... - CoreML supported return type is int32 or uint16. 14:43:10 ... - tflite supports int32, int64. 14:43:10 ... - dml supports int32, int64, uint32, uint64. 14:43:28 ... Returning int64 can't be emulated on CoreML (with details in the issue) 14:43:41 ... Phillis proposes two possible options: 14:43:49 ... - a. Update argMin/Max to always output int32 14:44:08 ... - b. On the spec level, allow passing a param of output_type. And allow probing the supported data types for this param. 14:44:17 ... I see thumbs up from Ningxin and Austin, do you want to comment? 14:44:24 q? 14:45:06 Dwayne: for some history, I believe we thought argmax/min to return int32 before we tried some models, and found it complicated things we don't support int64 14:45:18 ... I added it because it was so widely used 14:45:29 ... if we pass an output type for argmax would be amenable 14:45:39 Phillis: if we pass that we could probe it 14:45:52 Dwayne: another issue on data type validation 14:46:20 Phillis: I think we run into these interop issues and need to probe, can you comment on why int64 was important for ONNX models so that I have that reference 14:46:33 Dwayne: all indices are in 64 in tensors and passed as such 14:46:59 Dwayne: indices specifically, if you output argmax tensor to the next one the next op needs them 14:47:07 Phillip: gather needs this, right? 14:47:25 Dwayne: will do research after the meeting and provide information in GH issue 14:47:34 q? 14:48:24 Subtopic: [bug] Consider dropping the support of uint64/int64 data type for some operators 14:48:27 anssik: issue #654 14:48:28 https://github.com/webmachinelearning/webnn/issues/654 -> Issue 654 Consider dropping the support of uint64/int64 data type for some operators (by lisa0314) [bug] [operator specific] 14:49:00 ... informed by implementation experience, certain op + data type combinations can't be supported reliably on certain Windows + DirectML version combination 14:49:04 ... Lisa provided a list (thanks!) of such ops in the issue 14:49:09 ... Austin notes CoreML does not natively support 64-bit types 14:49:28 ... suggests an emulation path is required on platforms that don't support these data types 14:49:40 ... Joshua asked (an implementation-related) question on how to bundle DML with the browser distribution 14:49:48 q? 14:49:51 q+ 14:49:55 ack jsbell 14:50:21 jsbell: possible solution, ask the context if the data type is supported? 14:50:42 ... could entertain that idea, it is OK for WebNN running on different machines can support different ops 14:50:53 ... one path to explore 14:52:01 asully: looking at CoreML Neural Engine prefers fp16 14:52:16 q? 14:52:17 ... if this can be expressed somehow developers might use fp16 more for better performance 14:52:30 Dwayne: is there support for preference vs supports only? 14:52:37 Phillis: only supports 14:52:45 q+ Mike3 14:53:04 asully: CoreML will ballback to CPU internally, another layer of fallback is what UA decides to do 14:53:29 ... the stance has been to push things lower, but the question is if you want to support int64 on CoreML you'd need to do that in userspace 14:53:35 q? 14:53:40 ack Mike3 14:54:08 Mike: echoing what Phillis said, running on ANE is fp16, can fallback to GPU or CPU 14:54:36 q? 14:54:41 I guess #463 was the generic issue re: checking for support 14:54:42 https://github.com/webmachinelearning/webnn/issues/463 -> Issue 463 Allow checking whether operators/types are supported for a backend before creating a graph (by huningxin) [feature request] 14:55:13 q+ 14:55:43 https://github.com/webmachinelearning/webnn/issues/668 14:55:44 https://github.com/webmachinelearning/webnn/issues/668 -> Issue 668 Do we need an `MLConstantOperand`? (by a-sully) [question] 14:56:05 q? 14:56:08 ack asully 14:56:22 Subtopic: [question] Do we need an MLConstantOperand? 14:56:29 anssik: issue #668 14:56:30 https://github.com/webmachinelearning/webnn/issues/668 -> Issue 668 Do we need an `MLConstantOperand`? (by a-sully) [question] 14:56:54 asully: TL:DR: CoreML requires some tensors to be constant, a concept of a constant tensor is not something other frameworks such as TFLite have 14:57:25 ... the other frameworks do not have this concept, some parameters passed as tensors seems solely because they're big (think of them as weights), LSTM weights 14:57:35 ... they're used as constant and passed to this as a parameter 14:57:51 ... on CoreML these are required to be known at compile time 14:58:01 ... to support these ops on CoreML these tensors must be created as constant 14:58:21 ... in WebNN currently there's no distinction to know if this is constant of opaque operand 14:58:42 ... asking if you can create constant, can it give back a parameter 14:58:59 ... some make sense to pass as constants only, if not constants you can't plumb direct to CoreML 14:59:29 ... the questions is, no constant tensor concept in other frameworks, does it make sense to pass anything other than constant make sense, introduce constant operand instead? 15:00:25 q? 15:00:56 RRSAgent, draft minutes 15:00:57 I have made the request to generate https://www.w3.org/2024/05/02-webmachinelearning-minutes.html anssik 15:01:25 Dwayne: looking at this issue and fields in there, all are constant in all the models I've seen I believe? 15:01:43 ... I could look at my ~700 models are see if these fields are linked to non-constant tensors? 15:02:16 asully: hypothesis is these are not always marked as such, because frameworks don't have such a concept, if framework has no way to express this, upstreaming this concept to WebNN would make sense 15:02:28 Dwayne: if output is from another op then what we do? 15:02:35 asully: we need to discuss 15:02:43 ... easier to relax restrictions and add them later on 15:02:57 ... preference would be to try this and if something breaks we discuss that 15:03:13 ... otherwise CoreML support requires a constant tensor to be passed 15:03:14 q? 15:14:53 s/ on on/ on 15:15:16 s/ to to/ to 15:17:31 s/should to know/should be known 15:18:21 s/IO Banding/IO Binding 15:20:39 s/found we/we found we 15:21:37 s/bunch of PR/bunch of PRs 15:24:24 s/be helpful/label be helpful 15:26:25 s/ballback/fallback 15:28:30 s/constant make sense/constant 15:28:36 RRSAgent, draft minutes 15:28:38 I have made the request to generate https://www.w3.org/2024/05/02-webmachinelearning-minutes.html anssik 17:27:01 Zakim has left #webmachinelearning