13:50:15 RRSAgent has joined #webmachinelearning 13:50:15 logging to https://www.w3.org/2022/11/03-webmachinelearning-irc 13:50:18 RRSAgent, make logs Public 13:50:19 please title this meeting ("meeting: ..."), anssik 13:50:21 Meeting: WebML WG Teleconference – 3 November 2022 13:50:25 Chair: Anssi 13:50:33 Agenda: https://github.com/webmachinelearning/meetings/blob/main/telcons/2022-11-03-wg-agenda.md 13:50:37 Scribe: Anssi 13:50:41 scribeNick: anssik 13:50:56 Present+ Anssi_Kostiainen 13:51:00 Regrets+ Dominique_Hazael-Massieux 13:51:08 RRSAgent, draft minutes 13:51:08 I have made the request to generate https://www.w3.org/2022/11/03-webmachinelearning-minutes.html anssik 13:52:36 ghurlbot, this is webmachinelearning/webnn 13:52:36 anssik, OK 14:00:10 ningxin_hu has joined #webmachinelearning 14:01:28 Present+ Ningxin_Hu 14:01:34 Present+ Chai_Chaoweeraprasit 14:01:42 Present+ Zoltan_Kis 14:02:14 zkis has joined #webmachinelearning 14:02:15 Present+ Bruce_Dai 14:02:31 Present+ Jonathan_Bingham 14:02:50 Present+ Rafael_Cintron 14:02:56 RRSAgent, draft minutes 14:02:56 I have made the request to generate https://www.w3.org/2022/11/03-webmachinelearning-minutes.html anssik 14:03:17 bruce_dai has joined #webmachinelearning 14:03:34 Topic: WebNN API Candidate Recommendation open issues 14:03:42 -> Current CR issues https://github.com/webmachinelearning/webnn/labels/cr 14:03:57 Subtopic: Support asynchronous context creation, naming issues 14:04:09 anssik: for background refresh, Support asynchronous context creation discussed in #272 14:04:10 https://github.com/webmachinelearning/webnn/issues/272 -> Issue 272 Support asynchronous context creation (huningxin) cr 14:04:13 ... we asked TAG for advice on naming convention to use: 14:04:20 -> Delta review (to CR) of Web Neural Network API https://github.com/w3ctag/design-reviews/issues/771 14:04:45 RafaelCintron has joined #webmachinelearning 14:04:48 anssik: TAG considered this topic important enough for inclusion into its Web Platform Design Principles document that contains a set of design principles to be used when designing web platform technologies 14:04:54 -> Web Platform Design Principles https://w3ctag.github.io/design-principles/ 14:04:58 -> New principle: Patterns for x() vs xSync() https://github.com/w3ctag/design-principles/issues/402 14:05:03 anssik: the principle is yet to land in that doc, but per TAG issue discussion the recommendation is: 14:05:09 "I think both naming schemes are useful in different cases, basically x() should be the common case and xSync()/xAsync() the exception. I.e. if the main usage is sync, then x() and xAsync() seems preferable. If the main usage is async, then x() and xSync() seems preferable." 14:05:45 anssik: what follows is that if we agree that the main usage of the following methods is async as follows: 14:05:50 ... ML.createContext() returns Promise 14:05:53 ... MLGraphBuilder.build() returns Promise 14:05:57 ... MLContext.compute() returns Promise 14:06:03 q+ 14:06:13 anssik: then per this TAG recommendation we are guided to merge the PR #274 that use Sync postfix and close PR #285 that proposed Async postfix 14:06:15 https://github.com/webmachinelearning/webnn/issues/274 -> Pull Request 274 Support async context creation and use sync postfix (huningxin) 14:06:15 https://github.com/webmachinelearning/webnn/issues/285 -> Pull Request 285 Introduce MLContext.createContextAsync (huningxin) 14:06:17 ... any comments? 14:06:19 q? 14:06:21 ack zkis 14:06:22 chai has joined #webmachinelearning 14:07:11 zkis: one possibility would be to make some constructors, to avoid name clashing e.g. in createContext 14:07:17 anssik: thanks for that input 14:07:58 anssik: thanks everyone who contributed to this discussion that ultimately helped Web Platform Design Principles to add a new guidance for x() vs xSync() patterns 14:08:09 ... naming is never easy because there is no absolute truth as in maths, this is why having a doc such as Web Platform Design Principles is important 14:08:19 ... we should probably inform WebGPU WG of this Web Platform Design Principle to allow them consider this in the naming of WebGPU API interfaces 14:08:32 proposed RECOMMENDATION: Per TAG recommendation adopt x() and xSync() naming pattern for createContext(), build() and compute() methods. 14:08:51 +1 14:09:35 RESOLUTION: Per TAG recommendation adopt x() and xSync() naming pattern for createContext(), build() and compute() methods. 14:09:57 Subtopic: Web platform tests 14:10:11 anssik: I want us to discuss & resolve any blockers for w-p-t & webnn-baseline reference impl. 14:10:23 ... web-platform-tests tracker issue #265 is kept up to date by Bruce (thanks!) 14:10:26 https://github.com/webmachinelearning/webnn/issues/265 -> Issue 265 WPT tests tracker (BruceDai) cr 14:10:32 -> webnn-baseline implementation plan https://github.com/webmachinelearning/webnn-baseline/issues 14:10:56 anssik: as a reminder, webnn-baseline is the pure JS double-precision baseline implementation of WebNN operations for testing purpose without 3rd party deps 14:11:08 ... let's look at the recently updated wpt PRs: 14:11:12 -> Add WebNN API operations tests https://github.com/web-platform-tests/wpt/pull/34287 14:11:49 anssik: in #34287 following Dwayne's precision-metrics suggestions, updated existed data movement ops float32 tests which use ULP metrics, added tanh op float32 tests which uses ATOL metrics and gemm op float32 tests which uses IEPOE metrics, this PR is under review 14:11:51 https://github.com/webmachinelearning/webnn/issues/34287 -> Issue 34287 [not found] 14:12:03 anssik: Bruce anything blocking this PR? 14:12:19 Bruce: no blockers from my side, thanks for the review and support 14:12:30 q? 14:13:04 -> Add others first-wave ops tests for WebNN API https://github.com/web-platform-tests/wpt/pull/36202 14:13:19 anssik: in #36202 other float32 tests for remaining first-wave ops have updated test data (float64 inputs + float32 baseline) and precision metrics 14:13:21 https://github.com/webmachinelearning/webnn/issues/36202 -> Issue 36202 [not found] 14:14:39 https://github.com/web-platform-tests/wpt/pull/36202 14:15:28 Bruce: no blockers for this PR either 14:15:31 q? 14:16:12 Subtopic: API review questions in prep for normative algorithm definition 14:16:17 #298 14:16:18 https://github.com/webmachinelearning/webnn/issues/298 -> Issue 298 API review, questions, brainstorming (zolkis) 14:16:36 anssik: The aim of this discussion is to process review questions to clear the path for algorithm updates. 14:16:53 ... first, thanks for Zoltan for looking at the spec with fresh eyes and providing a number of questions and proposals to the WG for consideration 14:17:14 ... I talked with Zoltan about this review and expectations and we agreed we want to err on the side of being conservative with normative changes to not cause the spec change underneath of the ongoing implementations in unexpected ways 14:17:45 ... to help guide this review, we put priority on clarifying questions and API design aspects where the changes are motivated by user needs per Priority of Constituencies codified in the Web Platform Design Principles 14:17:50 -> Put user needs first (Priority of Constituencies) https://w3ctag.github.io/design-principles/#priority-of-constituencies 14:18:07 anssik: this TAG mandated principle helps Web API authors focus efforts on areas where the positive impact on users is maximized: 14:18:11 "If a trade-off needs to be made, always put user needs above all." 14:18:16 "User needs come before the needs of web page authors, which come before the needs of user agent implementors, which come before the needs of specification writers, which come before theoretical purity." 14:18:44 ... we expect majority of the WebNN API usage to be driven by JS ML frameworks and abstractions built atop 14:18:55 ... when we talk about WebNN, the users we want to put first are the JS ML frameworks 14:19:47 zkis: first ask for patience, I will step on previous discussions as I explore 14:20:24 ... I might not have find everything, based on what I found I try to find algos for different ops and reference internal slots, factor out algos, follow WebGPU conventions where it makes sense 14:20:44 ... I think we could eventually make the spec simpler, it has moved quite a lot in the past 14:21:38 ... first I needed to understand why context is introduced, I figured out the way it is used provides an abstraction for things needed to implement and use the API, I had several questions and Ningxin answered some of them 14:21:49 ... we could simplify things we are not using in the spec now 14:22:15 ... MLGraph we are using to host methods such as compute() moved to context, we are using context as if it was hosting everything we need for building 14:22:39 ... encode dispatch in the GPU context and compute 14:23:10 ... please fix me in the issue and provide past context if I missed some prior discussions and decisions 14:23:18 ... will make it easier for the next pair of fresh eyes 14:24:10 anssik: top 3 user-first improvements? 14:24:47 zkis: it would be simpler to be more flexible with future, graph could be an internal slot completely, have a lifecycle, allows to add APIs later 14:26:48 https://github.com/webmachinelearning/webnn/issues/298#issuecomment-1299990149 14:27:48 chai: I have not had time to look at this yet 14:28:25 q+ 14:28:30 zkis: I'd like to get feedback on the latest IDL proposal https://github.com/webmachinelearning/webnn/issues/298#issuecomment-1299990149 14:28:44 ack chai 14:29:02 Chai: I'll some time to go through this issue discussion, it is pretty long 14:29:17 ... agree with Zoltan, breaking up into many issues might be harder due to interdependencies 14:29:35 ... the way the thinking is summarized in the issue is good, it just takes time to go through 14:30:07 ... concrete cases of impl difficulty will make for a stronger case to change things 14:30:36 ... almost in all cases when we make a case was because Ningxin implemented either polyfill of webnn-native, of TF.js team gave concrete feedback 14:30:50 ... that experience makes it easier to decide where to go 14:31:00 ... what you see today is a result of all of those conversations 14:31:23 ... there's a lot of them! no one can combine all of that historical discussions during the past few years 14:32:11 ... e.g. one immutable context, why not go there, those are outcomes and mirror the implementation we've built 14:32:42 ... changes may have side-effects for implementation, it is good to have the past, I just want to caution the way it is today there's a reason for it, to change it we need a good reason to do so 14:32:59 zkis: I totally agree with that and know the journey from impl feedback to the spec and back 14:33:21 ... I'm interested in how to expose, what and why, need to go through that periodically 14:33:50 ... it tells me I should talk more often with Ningxin, we have these bi-weekly and should have additional sync points maybe to understand impl impacts 14:34:24 ... if Chai you read the comments I'd appreciate any guidance you may have, my thought process is implemented in the issue, it is not a proposal to be clear 14:35:09 Chai: my point is, a concrete example makes it easier to demonstrate the benefit to not have a philosophical point 14:35:55 "User needs come before the needs of web page authors, which come before the needs of user agent implementors, which come before the needs of specification writers, which come before theoretical purity." 14:36:01 q? 14:36:08 q? 14:36:10 ack zkis 14:36:42 zkis: I agree on Priority of Constituencies 14:38:33 ... I take any feedback on the issue, I want to understand it and make consistent algos that refer to the things that are connected to use cases 14:39:33 anssik: also informative text contributions are valuable 14:39:57 zkis: we can move offline with this and you can add comments to the issue 14:40:39 q? 14:41:03 Topic: WebNN-WebGPU interop 14:41:34 anssik: Review WebGPU interop mechanism and its normative WebGPU dependencies to assess whether WebGPU interop is a feasible CR target or a v2 feature. 14:41:45 ... consider implementation feedback from the WebNN DirectML backend. 14:42:19 ... we should make sure the WebNN API interop mechanism with WebGPU API is specified in adequate detail and check that the normative WebGPU API dependencies are defined in a fashion they can be implemented in an interoperable fashion 14:42:38 ... the standard way to test interop is with a cross-browser test suite that runs against one or more implementations 14:43:10 ... if we cannot yet produce a good set of tests that exercise the WebGPU interop mechanisms, it would be logical to make this a v2 feature, otherwise CR->PR advancement would be blocked until after the interop can be demonstrated 14:43:20 ... assuming WebGPU interop is testable, we have a few options: 14:43:48 ... 1) Keep WebGPU interop features in spec as is and mark them as "at risk" for CR purposes, improve algorithms 14:44:07 ... 2) Move WebGPU interop features into a branch and stabilize the main branch for CR. Con: tedious logistics-wise to sync branches. 14:44:39 q? 14:44:43 q+ 14:44:48 ack RafaelCintron 14:45:11 RafaelCintron: so far I know there hasn't been on impl experience on this aspect 14:45:32 ... if there's need to impl this in different process vs. GPU process, we need more impl experience on this aspect of the spec 14:45:34 q? 14:45:48 q+ 14:45:51 ack ningxin_hu 14:46:30 ningxin_hu: some experience from DirectML prototype, so far the impl focuses on WebNN standalone usage 14:46:43 ... compute takes ArrayBuffers as input and output 14:47:21 ... because WebGPU team wants to focus on their v1 release, for WebNN and WebGPU it is required for WebGPU to expose some interfaces 14:47:33 ... currently no bandwidth for that work 14:48:00 ... WebNN-WebGPU interop prototype might be postponed until both parties have bandwidth to spend on that 14:49:04 q? 14:49:47 ningxin_hu: one clarification, the issues are related to WebNN-WebGPU interop 14:50:11 anssik: so what we haven't implemented yet is MLCommandEncoder https://www.w3.org/TR/webnn/#mlcommandencoder 14:50:22 ningxin_hu: right 14:50:35 ... device type GPU is there and prototyped 14:52:44 anssik: can someone implement the spec ignoring https://www.w3.org/TR/webnn/#mlcommandencoder 14:53:03 Chai: yes, I specified it as such 14:53:03 that's true 14:54:41 RafaelCintron: I've understood Brian is working on some other things currently, not actively working on WebNN 14:55:38 RafaelCintron: we haven't gotten official feedback from WebGPU WG, unofficial feedback only 14:57:34 anssik: any aspects of WebGPU API that are going to ship WebNN would not be happy with? 14:57:54 RafaelCintron: not aware of any, but impl experience is crucial in validating that 14:58:49 q? 14:59:19 q+ 15:00:12 ningxin_hu: we are working on the WebNN main flow functionality in Chromium, one big CL to prototype WebNN mem flow, GPU device type via DML integration 15:01:01 ... this is for main flow usage, WebNN-WebGPU interop would be postponed for later and focus is to get Mojo interface design and DirectML design and WebNN mapping, security review, moving forward with smaller CLs landed 15:01:23 ... depending on WebGPU folks' bandwidth we can start WebNN-WebGPU interop work 15:01:53 ... I think if someone has bandwidth to prototype WebNN-WebGPU earlier, feel free to review the big CL we sent for review and start from there 15:02:25 ... experiment how to impl this interop capability, but this requires changes to WebGPU implementation and good to have experience in that space 15:03:43 q? 15:04:23 ack ningxin_hu 15:04:58 that's fine 15:06:25 RRSAgent, draft minutes 15:06:25 I have made the request to generate https://www.w3.org/2022/11/03-webmachinelearning-minutes.html anssik 15:11:53 zkis_ has joined #webmachinelearning 15:57:54 zkis has joined #webmachinelearning 17:28:54 zkis has joined #webmachinelearning 17:30:56 Zakim has left #webmachinelearning 18:16:52 zkis has joined #webmachinelearning 19:23:16 zkis has joined #webmachinelearning 21:11:35 zkis has joined #webmachinelearning