15:01:32 RRSAgent has joined #webmachinelearning 15:01:32 logging to https://www.w3.org/2020/02/20-webmachinelearning-irc 15:01:39 Zakim has joined #webmachinelearning 15:01:47 RRSAgent, make logs public 15:01:47 Rama has joined #webmachinelearning 15:01:52 Meeting: WebML CG Teleconference – 20 February 2020 15:01:54 jonathan has joined #webmachinelearning 15:01:57 Chair: Anssi 15:02:02 Agenda: https://github.com/webmachinelearning/meetings/blob/master/telcons/2020-02-20-agenda.md 15:02:07 Scribe: Anssi 15:02:12 scribeNick: anssik 15:02:32 Present+ Anssi_Kostiainen 15:02:38 Present+ Ningxin_Hu 15:02:39 Present+ Ningxin_Hu 15:02:47 Present+ Oleksandra_Raraska 15:02:51 Present+ Ganesan_Ramalingam 15:02:57 Present+ Rafael_Cintron 15:03:11 Present+ Ganesan_Ramalingam 15:03:27 Present+ Paul_McDaniel 15:03:40 Present+ Jonathan_Bingham 15:03:46 RRSAgent, draft minutes v2 15:03:46 I have made the request to generate https://www.w3.org/2020/02/20-webmachinelearning-minutes.html anssik 15:04:01 TOPIC: Announcements 15:04:13 anssik: 2020-02-13 update: Web & ML workshop postponed sine die due to ongoing challenges around international travel 15:04:26 ... all registrants have been informed, we do not yet have a new date, monitoring the situation actively 15:04:33 ... workshop page also updated 15:04:38 -> https://www.w3.org/2020/01/machine-learning-workshop/ [POSTPONED] W3C Workshop on Web & Machine Learning 15:04:48 anssik: questions? 15:05:01 TOPIC: conv2d op definition 15:05:08 anssik: nignxin submitted a PR https://github.com/webmachinelearning/webnn/pull/43 15:05:16 ... signature only, to be evolved in subsequent PRs to add more details, proceducal algorithms 15:05:38 ... open is the default tensor layout: NHWC or NCHW 15:05:44 ... NHWC matches HTMLMediaElements 15:05:53 ... NCHW more natural to convolution 15:06:14 ... perf implications: NCHW more GPU-friendly, but situation evolves 15:06:40 ... anssik: what are the problems we want to solve? are they really problems we need to solve on the WebNN API level? 15:07:27 ningxin_hu: PR submitted, based on original proposal from Nikhil and compat study we put together in this group 15:07:55 ... no issues around arguments themselves, the default input tensor layout is he only open issue 15:08:21 ... NHWC per Nikhil's proposal, HTMLMediaElements uses this layout as the default 15:09:30 Chai: agree with Ningxin, the most important change we should make is to make sure conv2d support both the layouts, since it depends how the model is trained which layout to use 15:09:52 ... most training scripts use NCHW thanks to cuDNN 15:10:12 ... when training on GPU this is a reasonable default 15:11:56 ... ONNX and CoreML default to NCHW layout 15:12:20 ... both the formats want to perform well on GPU 15:12:51 jdarpinian has joined #webmachinelearning 15:13:18 ... side question about HTMLMediaElement, maybe not so relevant since need to convert to tensor anyway 15:14:00 ... prefer to default to NCHW 15:15:16 q+ 15:15:46 ningxin_hu: I updated Conv2d compat table, all native APIs support NCHW 15:15:50 ack Rafael 15:16:25 Rafael: the PR seems fine, but eventually we need to allow ppl to pass image elements into these APIs 15:17:33 Chai: propose we create a new issue for passing image elements into conv2d 15:18:56 PROPOSED RESOLUTION: Add data format argument to conv2d to allow input tensor layout to be configured as NHWC or NCHW, default to NCHW 15:19:39 anssik: any concerns with the proposed resolution? 15:21:07 PROPOSED RESOLUTION: Add data format argument to conv2d to allow input tensor layout to be configured as NHWC or NCHW, the API needs to support both, default to NCHW 15:22:22 RESOLUTION: Add data format argument to conv2d to allow input tensor layout to be configured as NHWC or NCHW, the API needs to support both, default to NCHW 15:22:31 TOPIC: Remove Compilation.finish and setPreference 15:22:56 anssik: this PR https://github.com/webmachinelearning/webnn/issues/39 spun off from float16 OperandType PR #35 15:23:14 ... based on feedback new refined IDL proposed by Ningxin: https://github.com/webmachinelearning/webnn/issues/39#issuecomment-588865620 15:23:47 PROPOSED RESOLUTION: Refactor into createCompilation(CompilationPreference preference) and createExecution() 15:24:16 q+ 15:24:22 ack Rafael 15:24:41 Rafael: is Execution an object to bind inputs to? 15:25:31 ningxin_hu: yes, that's the current design, also output bound to it 15:25:45 Rafael: Execution is a one-shot? 15:25:49 ningxin_hu: right 15:26:09 Rafael: why execution needs to return a promise, and not create a new? 15:26:24 ... I understood compilation can take a long time 15:26:42 ... why execution also needs to return a promise and not return (synchronously) 15:27:08 [scribe missed] 15:27:41 Rafael: fine with the proposed IDL, can maybe refine in fugure updates these API further 15:28:05 Rama: createExecution needs to wait first, motivation for the design? 15:28:15 ... buffers may need to wait perhaps? 15:28:34 ningxin_hu: in prototyping noticed lag in first execution due to buffer allocation 15:29:23 PROPOSED RESOLUTION: Refactor into createCompilation(CompilationPreference preference) and createExecution() 15:29:52 anssik: any concerns? 15:29:53 +1 proposed IDL looks good to me. 15:30:20 RESOLUTION: Refactor into createCompilation(CompilationPreference preference) and createExecution() 15:30:35 TOPIC: Handling unsupported OperandType 15:30:49 anssik: this issue was actually closed, since the real issue is with quantization-specific params https://github.com/webmachinelearning/webnn/issues/44 15:30:51 q+ 15:31:14 ack ningxin_hu 15:32:30 ningxin_hu: https://github.com/webmachinelearning/webnn/issues/36 may need to be reopened 15:33:12 Chai: issues are a bit unrelated, want to keep OperandType and OperandDescriptor clean for the future 15:33:56 ... quantization is still evolving, now APIs implement linear quant, if we add quant option in enum type and descriptor, can be potentially ongoing 15:34:12 ... proposal to keep operand just about datatype 15:34:45 ... I can add more detail in the issue #44 15:35:51 ningxin_hu: #44 is clear, my question is float16 was just added as a datatype but if not supported by underlying platform, how the API should react? 15:36:08 Chai: the API should fail in such case 15:36:52 ningxin_hu: we need to specify how to surface this error condition through the API 15:37:11 ... prefer to reopen #36 to flesh out how to signal the error in it 15:38:32 TOPIC: WebML synopsis at WebGPU F2F 15:38:47 anssik: I wanted to discuss key WebML takeaways from WebGPU F2F 15:38:58 -> https://docs.google.com/document/d/1fsAV1SyV-eSfjnA0C4WjpXAJcmRUnkzXAh4AblSotoI/edit#heading=h.e1hdus1hfzn6 WebGPU CG F2F 2020-02-13 meeting minutes 15:39:26 Present+ James_Darpinian 15:39:58 Rafael: I can give a summary of summary :-) 15:40:19 ... Apple seemed rather supportive of a load model API 15:40:32 ... the two groups agreed to work together 15:42:41 Chai: on Q from the F2F, what does WebML want from WebGPU? Custom op support discussed, how to make interop happen, exercise for the future to PoC ML custom op in terms of WebGPU, how custom op would look like 15:42:50 q+ 15:42:56 ack ningxin_hu 15:43:09 https://github.com/webmachinelearning/webnn/issues/6 15:43:49 ningxin_hu: re custom ops WebGPU, we have issue #6 about this topic and have done some preliminary investigation into the topic, using WebGPU compute shader 15:45:01 Chai: exercise was to prototype that but in JS, not internally calling into OS API but on a higher-level, figure out how buffer sharing would work, WebGPU has a BufferResource, how graph builder API would consume it 15:45:53 TOPIC: Inference API to load and run a model 15:46:07 anssi: Let's discuss feedback and decide next steps for inference API to load and run a model. 15:46:13 -> https://github.com/webmachinelearning/webnn/issues/41 Revisit inference API to load and run a model #41 15:46:19 -> https://github.com/jbingham/web-ml-inference Explainer 15:47:10 jonathan: thanks to people who commented ningxin and chai 15:47:29 ... discussed whether this is complementary to the existing API, consensus seems to be it is 15:48:00 ... another discussion, whether we need separate compilation step or not, it seems the answer is probably yes 15:48:34 ... discussions around what information needs to be exposed to web developer vs graph builder API 15:48:50 ... also discussed what workstreams could come out of this 15:49:26 ... ningxin_hu's existing POC work would be extended with model loader API, possibly 15:49:57 ... personally would like to be able to separate the two API surfaces, if an implemented wants to implement only one, not both 15:50:11 s/implemented/implementer 15:53:54 q+ 15:54:00 ack Rafael 15:54:31 https://webscreens.github.io/cg-charter/ 15:54:41 s/https://webscreens.github.io/cg-charter/// 15:54:48 q+ 15:54:53 https://webmachinelearning.github.io/charter/ 15:55:06 quote from the charter: "Allow to construct a neural network computational graph by common building blocks, including constant values and base operations such as convolution, pooling, softmax, normalization, fully connected, activation, recurrent neural network (RNN) and long short-term memory (LSTM);" 15:56:41 ack Chai 15:58:50 q+ 15:59:34 Chai: I feel like it is important to define the graph builder API, since with load model API we'd abstract out many important details 15:59:51 ... model loader API would be like the OS-provided API 15:59:59 ack Rafael 16:01:03 Rafael: agree with Chai, just to add, if the group cannot agree on a model format to digest, then graph builder API is a great hedge and allows leaving model parsing etc. to JS 16:01:09 q+ 16:01:52 ack ningxin_hu 16:02:34 ningxin_hu: would like to hear feedback on our POC proposal 16:03:05 ningxin_hu: The existing WebNN Proof-Of-Concept (POC) is based on Chromium and implements the model-builder API on top of Android NNAPI, Windows DirectML and macOS MPS/BNNS. For the new model-loader API prototype, I propose to extend the existing Chromium-based POC and start with WinML. 16:03:43 https://github.com/webmachinelearning/webnn/issues/41#issuecomment-588849050 16:03:52 https://github.com/otcshare/chromium-src 16:05:21 Chai: in short, I think if we take the load model API separate from graph builder API, could have two parallel tracks that evolve differently, maybe not so good idea since we do not want to punt important design issues to OS 16:06:08 ... load model API as a convenience on top of graph builder API is my preference 16:07:37 anssik: anyone else interested in prototyping the load model API? 16:07:43 (hearing none) 16:08:23 TOPIC: Adjourn 16:08:32 RRSAgent, draft minutes v2 16:08:32 I have made the request to generate https://www.w3.org/2020/02/20-webmachinelearning-minutes.html anssik 16:23:53 Present+ Chai_Chaoweeraprasit 16:23:56 RRSAgent, draft minutes v2 16:23:56 I have made the request to generate https://www.w3.org/2020/02/20-webmachinelearning-minutes.html anssik 16:26:03 s/webscreens.github.io// 16:26:18 s/webscreens.github.io// 16:26:27 s/cg-charter// 16:26:29 RRSAgent, draft minutes v2 16:26:29 I have made the request to generate https://www.w3.org/2020/02/20-webmachinelearning-minutes.html anssik 16:26:58 s/cg-charter// 16:27:00 RRSAgent, draft minutes v2 16:27:00 I have made the request to generate https://www.w3.org/2020/02/20-webmachinelearning-minutes.html anssik 16:49:01 zkis has joined #webmachinelearning 18:13:39 zkis has joined #webmachinelearning 18:29:08 zkis has joined #webmachinelearning 18:46:07 Zakim has left #webmachinelearning 19:35:19 zkis has joined #webmachinelearning 21:28:30 zkis has joined #webmachinelearning 22:53:09 zkis has joined #webmachinelearning