IRC log of webmachinelearning on 2022-11-03

Timestamps are in UTC.

13:50:15 [RRSAgent]
RRSAgent has joined #webmachinelearning
13:50:15 [RRSAgent]
logging to https://www.w3.org/2022/11/03-webmachinelearning-irc
13:50:18 [Zakim]
RRSAgent, make logs Public
13:50:19 [Zakim]
please title this meeting ("meeting: ..."), anssik
13:50:21 [anssik]
Meeting: WebML WG Teleconference – 3 November 2022
13:50:25 [anssik]
Chair: Anssi
13:50:33 [anssik]
Agenda: https://github.com/webmachinelearning/meetings/blob/main/telcons/2022-11-03-wg-agenda.md
13:50:37 [anssik]
Scribe: Anssi
13:50:41 [anssik]
scribeNick: anssik
13:50:56 [anssik]
Present+ Anssi_Kostiainen
13:51:00 [anssik]
Regrets+ Dominique_Hazael-Massieux
13:51:08 [anssik]
RRSAgent, draft minutes
13:51:08 [RRSAgent]
I have made the request to generate https://www.w3.org/2022/11/03-webmachinelearning-minutes.html anssik
13:52:36 [anssik]
ghurlbot, this is webmachinelearning/webnn
13:52:36 [ghurlbot]
anssik, OK
14:00:10 [ningxin_hu]
ningxin_hu has joined #webmachinelearning
14:01:28 [anssik]
Present+ Ningxin_Hu
14:01:34 [anssik]
Present+ Chai_Chaoweeraprasit
14:01:42 [anssik]
Present+ Zoltan_Kis
14:02:14 [zkis]
zkis has joined #webmachinelearning
14:02:15 [anssik]
Present+ Bruce_Dai
14:02:31 [anssik]
Present+ Jonathan_Bingham
14:02:50 [anssik]
Present+ Rafael_Cintron
14:02:56 [anssik]
RRSAgent, draft minutes
14:02:56 [RRSAgent]
I have made the request to generate https://www.w3.org/2022/11/03-webmachinelearning-minutes.html anssik
14:03:17 [bruce_dai]
bruce_dai has joined #webmachinelearning
14:03:34 [anssik]
Topic: WebNN API Candidate Recommendation open issues
14:03:42 [anssik]
-> Current CR issues https://github.com/webmachinelearning/webnn/labels/cr
14:03:57 [anssik]
Subtopic: Support asynchronous context creation, naming issues
14:04:09 [anssik]
anssik: for background refresh, Support asynchronous context creation discussed in #272
14:04:10 [ghurlbot]
https://github.com/webmachinelearning/webnn/issues/272 -> Issue 272 Support asynchronous context creation (huningxin) cr
14:04:13 [anssik]
... we asked TAG for advice on naming convention to use:
14:04:20 [anssik]
-> Delta review (to CR) of Web Neural Network API https://github.com/w3ctag/design-reviews/issues/771
14:04:45 [RafaelCintron]
RafaelCintron has joined #webmachinelearning
14:04:48 [anssik]
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 [anssik]
-> Web Platform Design Principles https://w3ctag.github.io/design-principles/
14:04:58 [anssik]
-> New principle: Patterns for x() vs xSync() https://github.com/w3ctag/design-principles/issues/402
14:05:03 [anssik]
anssik: the principle is yet to land in that doc, but per TAG issue discussion the recommendation is:
14:05:09 [anssik]
"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]
anssik: what follows is that if we agree that the main usage of the following methods is async as follows:
14:05:50 [anssik]
... ML.createContext() returns Promise<MLContext>
14:05:53 [anssik]
... MLGraphBuilder.build() returns Promise<MLGraph>
14:05:57 [anssik]
... MLContext.compute() returns Promise<undefined>
14:06:03 [zkis]
q+
14:06:13 [anssik]
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 [ghurlbot]
https://github.com/webmachinelearning/webnn/issues/274 -> Pull Request 274 Support async context creation and use sync postfix (huningxin)
14:06:15 [ghurlbot]
https://github.com/webmachinelearning/webnn/issues/285 -> Pull Request 285 Introduce MLContext.createContextAsync (huningxin)
14:06:17 [anssik]
... any comments?
14:06:19 [anssik]
q?
14:06:21 [anssik]
ack zkis
14:06:22 [chai]
chai has joined #webmachinelearning
14:07:11 [anssik]
zkis: one possibility would be to make some constructors, to avoid name clashing e.g. in createContext
14:07:17 [anssik]
anssik: thanks for that input
14:07:58 [anssik]
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 [anssik]
... 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 [anssik]
... 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 [anssik]
proposed RECOMMENDATION: Per TAG recommendation adopt x() and xSync() naming pattern for createContext(), build() and compute() methods.
14:08:51 [zkis]
+1
14:09:35 [anssik]
RESOLUTION: Per TAG recommendation adopt x() and xSync() naming pattern for createContext(), build() and compute() methods.
14:09:57 [anssik]
Subtopic: Web platform tests
14:10:11 [anssik]
anssik: I want us to discuss & resolve any blockers for w-p-t & webnn-baseline reference impl.
14:10:23 [anssik]
... web-platform-tests tracker issue #265 is kept up to date by Bruce (thanks!)
14:10:26 [ghurlbot]
https://github.com/webmachinelearning/webnn/issues/265 -> Issue 265 WPT tests tracker (BruceDai) cr
14:10:32 [anssik]
-> webnn-baseline implementation plan https://github.com/webmachinelearning/webnn-baseline/issues
14:10:56 [anssik]
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 [anssik]
... let's look at the recently updated wpt PRs:
14:11:12 [anssik]
-> Add WebNN API operations tests https://github.com/web-platform-tests/wpt/pull/34287
14:11:49 [anssik]
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 [ghurlbot]
https://github.com/webmachinelearning/webnn/issues/34287 -> Issue 34287 [not found]
14:12:03 [anssik]
anssik: Bruce anything blocking this PR?
14:12:19 [anssik]
Bruce: no blockers from my side, thanks for the review and support
14:12:30 [anssik]
q?
14:13:04 [anssik]
-> Add others first-wave ops tests for WebNN API https://github.com/web-platform-tests/wpt/pull/36202
14:13:19 [anssik]
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 [ghurlbot]
https://github.com/webmachinelearning/webnn/issues/36202 -> Issue 36202 [not found]
14:14:39 [bruce_dai]
https://github.com/web-platform-tests/wpt/pull/36202
14:15:28 [anssik]
Bruce: no blockers for this PR either
14:15:31 [anssik]
q?
14:16:12 [anssik]
Subtopic: API review questions in prep for normative algorithm definition
14:16:17 [anssik]
#298
14:16:18 [ghurlbot]
https://github.com/webmachinelearning/webnn/issues/298 -> Issue 298 API review, questions, brainstorming (zolkis)
14:16:36 [anssik]
anssik: The aim of this discussion is to process review questions to clear the path for algorithm updates.
14:16:53 [anssik]
... 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 [anssik]
... 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 [anssik]
... 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 [anssik]
-> Put user needs first (Priority of Constituencies) https://w3ctag.github.io/design-principles/#priority-of-constituencies
14:18:07 [anssik]
anssik: this TAG mandated principle helps Web API authors focus efforts on areas where the positive impact on users is maximized:
14:18:11 [anssik]
"If a trade-off needs to be made, always put user needs above all."
14:18:16 [anssik]
"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 [anssik]
... we expect majority of the WebNN API usage to be driven by JS ML frameworks and abstractions built atop
14:18:55 [anssik]
... when we talk about WebNN, the users we want to put first are the JS ML frameworks
14:19:47 [anssik]
zkis: first ask for patience, I will step on previous discussions as I explore
14:20:24 [anssik]
... 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 [anssik]
... I think we could eventually make the spec simpler, it has moved quite a lot in the past
14:21:38 [anssik]
... 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 [anssik]
... we could simplify things we are not using in the spec now
14:22:15 [anssik]
... 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 [anssik]
... encode dispatch in the GPU context and compute
14:23:10 [anssik]
... please fix me in the issue and provide past context if I missed some prior discussions and decisions
14:23:18 [anssik]
... will make it easier for the next pair of fresh eyes
14:24:10 [anssik]
anssik: top 3 user-first improvements?
14:24:47 [anssik]
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 [zkis]
https://github.com/webmachinelearning/webnn/issues/298#issuecomment-1299990149
14:27:48 [anssik]
chai: I have not had time to look at this yet
14:28:25 [chai]
q+
14:28:30 [anssik]
zkis: I'd like to get feedback on the latest IDL proposal https://github.com/webmachinelearning/webnn/issues/298#issuecomment-1299990149
14:28:44 [anssik]
ack chai
14:29:02 [anssik]
Chai: I'll some time to go through this issue discussion, it is pretty long
14:29:17 [anssik]
... agree with Zoltan, breaking up into many issues might be harder due to interdependencies
14:29:35 [anssik]
... the way the thinking is summarized in the issue is good, it just takes time to go through
14:30:07 [anssik]
... concrete cases of impl difficulty will make for a stronger case to change things
14:30:36 [anssik]
... 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 [anssik]
... that experience makes it easier to decide where to go
14:31:00 [anssik]
... what you see today is a result of all of those conversations
14:31:23 [anssik]
... there's a lot of them! no one can combine all of that historical discussions during the past few years
14:32:11 [anssik]
... e.g. one immutable context, why not go there, those are outcomes and mirror the implementation we've built
14:32:42 [anssik]
... 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 [anssik]
zkis: I totally agree with that and know the journey from impl feedback to the spec and back
14:33:21 [anssik]
... I'm interested in how to expose, what and why, need to go through that periodically
14:33:50 [anssik]
... 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 [anssik]
... 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 [anssik]
Chai: my point is, a concrete example makes it easier to demonstrate the benefit to not have a philosophical point
14:35:55 [anssik]
"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 [zkis]
q?
14:36:08 [anssik]
q?
14:36:10 [anssik]
ack zkis
14:36:42 [anssik]
zkis: I agree on Priority of Constituencies
14:38:33 [anssik]
... 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]
anssik: also informative text contributions are valuable
14:39:57 [anssik]
zkis: we can move offline with this and you can add comments to the issue
14:40:39 [anssik]
q?
14:41:03 [anssik]
Topic: WebNN-WebGPU interop
14:41:34 [anssik]
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 [anssik]
... consider implementation feedback from the WebNN DirectML backend.
14:42:19 [anssik]
... 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 [anssik]
... the standard way to test interop is with a cross-browser test suite that runs against one or more implementations
14:43:10 [anssik]
... 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 [anssik]
... assuming WebGPU interop is testable, we have a few options:
14:43:48 [anssik]
... 1) Keep WebGPU interop features in spec as is and mark them as "at risk" for CR purposes, improve algorithms
14:44:07 [anssik]
... 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 [anssik]
q?
14:44:43 [RafaelCintron]
q+
14:44:48 [anssik]
ack RafaelCintron
14:45:11 [anssik]
RafaelCintron: so far I know there hasn't been on impl experience on this aspect
14:45:32 [anssik]
... 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 [anssik]
q?
14:45:48 [ningxin_hu]
q+
14:45:51 [anssik]
ack ningxin_hu
14:46:30 [anssik]
ningxin_hu: some experience from DirectML prototype, so far the impl focuses on WebNN standalone usage
14:46:43 [anssik]
... compute takes ArrayBuffers as input and output
14:47:21 [anssik]
... 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 [anssik]
... currently no bandwidth for that work
14:48:00 [anssik]
... WebNN-WebGPU interop prototype might be postponed until both parties have bandwidth to spend on that
14:49:04 [anssik]
q?
14:49:47 [anssik]
ningxin_hu: one clarification, the issues are related to WebNN-WebGPU interop
14:50:11 [anssik]
anssik: so what we haven't implemented yet is MLCommandEncoder https://www.w3.org/TR/webnn/#mlcommandencoder
14:50:22 [anssik]
ningxin_hu: right
14:50:35 [anssik]
... device type GPU is there and prototyped
14:52:44 [anssik]
anssik: can someone implement the spec ignoring https://www.w3.org/TR/webnn/#mlcommandencoder
14:53:03 [anssik]
Chai: yes, I specified it as such
14:53:03 [ningxin_hu]
that's true
14:54:41 [anssik]
RafaelCintron: I've understood Brian is working on some other things currently, not actively working on WebNN
14:55:38 [anssik]
RafaelCintron: we haven't gotten official feedback from WebGPU WG, unofficial feedback only
14:57:34 [anssik]
anssik: any aspects of WebGPU API that are going to ship WebNN would not be happy with?
14:57:54 [anssik]
RafaelCintron: not aware of any, but impl experience is crucial in validating that
14:58:49 [anssik]
q?
14:59:19 [ningxin_hu]
q+
15:00:12 [anssik]
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 [anssik]
... 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 [anssik]
... depending on WebGPU folks' bandwidth we can start WebNN-WebGPU interop work
15:01:53 [anssik]
... 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 [anssik]
... 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 [zkis]
q?
15:04:23 [anssik]
ack ningxin_hu
15:04:58 [ningxin_hu]
that's fine
15:06:25 [anssik]
RRSAgent, draft minutes
15:06:25 [RRSAgent]
I have made the request to generate https://www.w3.org/2022/11/03-webmachinelearning-minutes.html anssik
15:11:53 [zkis_]
zkis_ has joined #webmachinelearning
15:57:54 [zkis]
zkis has joined #webmachinelearning
17:28:54 [zkis]
zkis has joined #webmachinelearning
17:30:56 [Zakim]
Zakim has left #webmachinelearning
18:16:52 [zkis]
zkis has joined #webmachinelearning
19:23:16 [zkis]
zkis has joined #webmachinelearning
21:11:35 [zkis]
zkis has joined #webmachinelearning