14:03:39 RRSAgent has joined #webmachinelearning 14:03:39 logging to https://www.w3.org/2021/04/15-webmachinelearning-irc 14:03:41 RRSAgent, make logs Public 14:03:42 please title this meeting ("meeting: ..."), anssik 14:03:48 Meeting: WebML CG Teleconference – 15 April 2021 14:04:01 Chair: Anssi 14:04:05 Agenda: https://github.com/webmachinelearning/meetings/blob/master/telcons/2021-04-15-agenda.md 14:04:07 RafaelCintron has joined #webmachinelearning 14:04:10 Scribe: Anssi 14:04:15 scribeNick: anssik 14:04:24 Present+ Anssi_Kostiainen 14:04:28 Present+ Ningxin_Hu 14:04:33 Present+ Chai_Chaoweeraprasit 14:04:39 Present+ Rafael_Cintron 14:04:43 Present+ Ping_Yu 14:04:49 Present+ Ganesan_Ramalingam 14:04:54 RRSAgent, draft minutes 14:04:54 I have made the request to generate https://www.w3.org/2021/04/15-webmachinelearning-minutes.html anssik 14:05:10 Topic: Web Machine Learning WG 14:05:27 anssik: I wanted to give you an update where we're at with the Web Machine Learning Working Group and its charter review 14:05:35 -> https://lists.w3.org/Archives/Public/public-webmachinelearning/2021Apr/0002.html Changes to the proposed Web Machine Learning Working Group charter 14:05:44 -> https://w3c.github.io/machine-learning-charter/charter.html Updated WG charter 14:05:51 -> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2021%2F02%2Fproposed-machine-learning-charter.html&doc2=https%3A%2F%2Fw3c.github.io%2Fmachine-learning-charter%2Fcharter.html WG charter changes diff 14:06:11 anssik: first would like to thank everyone who reviewed the charter and provided feedback and support signals. 14:06:41 anssik: let me summarize the key events over the course of last 1.5 months: 14:06:45 ... W3C Advisory Committee has now reviewed the proposed WG charter 14:06:56 ... based on that review, we incorporated changes in the charter before its final approval by the W3C Director TimBL, launch expected next week 14:07:03 ... summary of changes: 14:07:26 Jonathan has joined #webmachinelearning 14:07:37 ... 1) aligned the language around the scope of the WebNN API with the CG 14:08:05 ... 2) Model Loader API has been clarified as depending on the availability of a well-defined standard format for Machine Learning models 14:08:52 ... 3) coordination with WebRTC WG and Ecma TC39 added 14:09:08 ... 4) coordination with the W3C TAG on Ethical Web Principles added 14:09:39 ... 5) new deliverable "Ethical Impact of Machine Learning on the Web" added, a W3C Note 14:10:42 ... Please contact dom at w3.org if any of these changes feel problematic, before April 16. 14:10:48 anssik: any questions? 14:11:26 Topic: Privacy review feedback normative changes 14:11:34 -> https://github.com/webmachinelearning/webnn/issues/145 [privacy-tracker] Make WebNN API a policy-controlled feature (issue #145) 14:11:41 -> https://github.com/webmachinelearning/webnn/pull/159 Add Permissions Policy Integration and initial createContext() hooks (PR #159) 14:12:02 anssik: we discussed this on our previous call and there was unanimous support 14:12:30 ... so I crafted a PR #159 that adds Permissions Policy Integration 14:13:11 ... also added initial steps for createContext() method to allow integration of the "allowed to use" check 14:13:30 ... I believe Chai may want to base some of his work on top of this? 14:13:41 proposed RESOLUTION: Merge PR #159 to add Permissions Policy Integration and initial createContext() hooks 14:15:16 anssik: any comments? 14:15:34 Present+ Jonathan_Bingham 14:15:52 Topic: Operation-specific APIs proposal 14:15:58 -> https://github.com/webmachinelearning/proposals/issues/2 operation-specific APIs proposal by Ping and Jonathan 14:16:33 anssik: we've been refining the work-in-progress features that satisfy the requirements of the operation-specific APIs proposal 14:16:41 Subtopic: WebAssembly scenario of the op level execution use case 14:16:45 -> https://github.com/webmachinelearning/webnn/issues/156 Support CPU - WebAssembly scenario of the op level execution use case (issue #156) 14:16:53 anssik: as for the WebAssembly scenario of the op level execution use case described in issue #156 by Ningxin 14:17:12 ... there's a PR #162 that in part enables an efficient interop with WebAssembly, among other aspects 14:17:16 -> https://github.com/webmachinelearning/webnn/pull/162 Add support for device selection and asynchronous data downloads for GPU readbacks (PR #162) 14:17:28 ... Chai, Ningxin you want to summarize your investigation and progress? 14:18:21 Chai: PR #162 should address the original issue of inteop with Wasm, while allowing the result of compute() method, now sync, to be downloaded on demand based on TF.js use case described by Ningxin 14:18:53 ... from GPU point of view, should work as well, since interop with WebGPU context 14:19:08 ... this PR is a "solution" for using WebNN as an op-level API 14:19:49 Ping: LGTM! Thanks Chai and Ningixn 14:19:57 s/Ningixn/Ningxin 14:20:04 Chai: thanks Ping and Ningxin! 14:20:32 Thanks Chai for making this PR 14:20:54 Subtopic: Clarify at which point weights are used in the compilation 14:21:02 anssik: quoting Rafael: "wanted to say, one thing we need to clarify at which point the web developers weights are used in the compilation, if they give us an ArrayBuffer, change it in between, need to specify when that work be more explicit if compilation means we copy things" 14:21:41 anssik: anything to discuss about this issue? 14:21:43 ... do editors see aspects that need to be agreed with the group prior to advancing with this issue? 14:21:43 q+ 14:21:47 ack ningxin_hu 14:22:23 Ningxin: I'll work on a PR for this issue, no issue with ArrayBuffer and weights, since that was clarified on the previous meeting 14:22:55 q+ 14:23:05 q+ 14:23:07 ... weights are to be provided via GPU or GL buffer, so the open is how the weights via GPU resources are interacted with, are they copied in the compile and build steps? 14:23:08 q? 14:23:12 ack RafaelCintron 14:23:25 Rafael: I haven't read through the new PR that Chai submitted 14:23:49 ... re GPU buffers, as long as you don't get the computation as a promise, we're OK 14:24:54 ... as long as there are promises there are data races 14:25:24 ... or if you don't get the model compilation as a promise, we're OK too 14:25:47 ... this is undefined, need to define what happens when the promises are unresolved 14:26:30 sounds good 14:26:33 q? 14:26:37 ack chai 14:27:00 Chai: I did not address that in the existing PRs, because this needs its own PR 14:27:15 ... Rafael, addressing your issue is still in my queue 14:27:44 q? 14:28:04 Subtopic: How the caller using an op-specific API can resource upload and download 14:28:48 anssik: I believe PR #162 explains in an informative example, how MLGraph.compute() invokes tasks on different timelines in parallel, and how JS code can do asynchronous data downloads 14:29:13 ... I believe we still need to add normative algorithmic prose to specify MLGraph.compute() steps in detail 14:29:24 ... also need to specify the steps for MLTensor.data() i.e. normative steps that happen prior to the promise returned by MLTensor.data() is resolved 14:29:30 q? 14:29:40 one question is about webgl inputs, the texture sharing is not possible across context, are there APIs guarding against that? 14:30:08 Chai: about the upload and download, I make modifications in PR #162 on what happens when the call completes, in particular for uploads 14:30:29 ... downloads should be added to the PR, will add that to PR #162 14:31:53 q+ 14:31:57 ack ningxin_hu 14:32:16 q+ 14:32:29 Ningxin: if MLTensor created for a GPU buffer or texture? 14:32:53 ... it has its own data download method, do we need MLTensor to handle that or delegate to WebGPU API? 14:33:02 q? 14:33:41 Chai: IIUC, question is how MLTensor is constructed? It can be constructed of any resource types we define 14:34:16 Ningxin: GPUBuffer has its own download/upload methods, do we use MLTensor.data to handle DL or leave that to the WebGPU API 14:34:47 Chai: my assumption is this is handled by the implementer, these tasks happen in the backend in the browser engine 14:35:10 ... assumption it is good enough to defer this to browser implementation 14:36:41 ... MLTensor interface encapsulates many resources, GPU and system memory 14:36:57 ... should work across resource types, otherwise you have to deal with different type of resources 14:37:22 ... I'll take a look at the feedback in the PR, good topic to look deeper into 14:37:26 ... concern is it 14:37:49 ... gets too complicated to handle with ever expanding number of resource types 14:38:00 Ningxin: proposal to separate system resource type from GPU resource type 14:38:26 q? 14:38:32 ack Ping_Yu 14:39:44 Ping: data download is this downloading data to the CPU(?) 14:39:48 [line breaking] 14:40:14 Ping: you want to get it from the CPU, there are users that want to access the data on CPU as a handle to the texture or buffer 14:40:58 ... another questions, WebGPU textures not shared across contexts 14:41:45 Chai: the design of this PR is that the data method is CPU download only 14:41:59 ... separation between output resource and system memory resource that gets copied from 14:42:18 ... the data method is meant to be CPU download because CPU readback is expensive 14:42:27 ... and there might be layout manipulation 14:42:53 ... targeting the CPU memory, for GPU resource there's another method, currently "resource" for the lack of a better word 14:43:17 ... as for the second questions, how the app deals with the edge between the WebNN and WebGPU APIs 14:43:46 ... web developers do that themselves, if additional DL/UL needs to happen it is the responsibility of the JS framework 14:44:28 ... related to how to deal with WebGPU DL/UL, better left to the callers of WebNN 14:44:46 ... too much assumptions how other APIs deal with these aspect, will become an problem 14:44:47 q? 14:45:19 zkis has joined #webmachinelearning 14:45:29 Present+ Zoltan_Kis 14:45:49 (back now) 14:47:05 sounds good 14:47:14 Chai: thanks Ping for your help with this work! 14:47:14 will comment on the PR 14:47:27 Topic: TAG review feedback - open issues without associated PRs 14:47:39 anssik: Let's look at the remaining open TAG review issues and proposed resolutions, if any 14:47:44 Subtopic: Define a common term for logical tensor changes? 14:47:53 -> https://github.com/webmachinelearning/webnn/issues/150 [tag-tracker] issue #150 14:47:57 anssik: no proposed resolution, yet? 14:48:14 q+ 14:48:14 RRSAgent, draft minutes 14:48:14 I have made the request to generate https://www.w3.org/2021/04/15-webmachinelearning-minutes.html anssik 14:48:19 ack RafaelCintron 14:49:46 Rafael: Rafael: what does "tensor changes" mean in this context? 14:49:51 anssik: please ask in that issue :-) 14:49:56 q? 14:50:12 Subtopic: Isomorphic JS story, worker scope exposure 14:50:20 -> https://github.com/webmachinelearning/webnn/issues/142 [tag-tracker] issue #142 14:50:42 anssik: Ningxin shared the webnn-polyfill CPU backend (dep on TF.js CPU backend) already works in Node.js for testing 14:51:07 ... navigator can be emulated in Node, but non-browser implementation could bind ML object to whatever is appropriate for a given JS exec environment as Ningxin suggested? 14:51:43 anssik: I wanted to point out already now Deno (JS and TypeScript runtime using V8) has an experimental support for WebGPU API https://deno.land/posts/v1.8 and its GPU object hangs off of navigator object similarly to the ML object for WebNN API 14:52:29 ... worker scope exposure would enable inference without blocking the main thread 14:52:39 ... communication between worker(s) and the main thread is via postMessage() API 14:53:06 proposed RESOLUTION: Expose ML interface to Worker in addition to its default Window context 14:53:24 q? 14:54:10 Rafael: I'd prefer to expose ML object elsewhere than in navigator 14:54:44 -> https://gpuweb.github.io/gpuweb/#navigator-gpu navigator.gpu 14:55:31 Rafael: maybe expose WebNN API in the same contexts as WebGPU is exposed 14:56:13 https://gpuweb.github.io/gpuweb/#navigator-gpu 14:56:37 proposed RESOLUTION: Expose ML interface to Worker scope similarly to WebGPU API 14:57:21 RESOLUTION: Expose ML interface to Worker scope similarly to WebGPU API 14:57:32 Subtopic: Ergonomics of the JS examples 14:57:38 -> https://github.com/webmachinelearning/webnn/issues/139 [tag-tracker] issue #139 14:58:05 anssik: I've understood TAG is not fully satisfied with the positioning of the WebNN API as an API for frameworks as its primary consumer 14:58:10 ... so I'm wondering whether we could explain in the WebNN API how the Model Loader API is expected to provide a more approachable API for web developers to use directly? 14:58:22 ... I think we have text like that in the explainer, maybe making that connection in the spec intro would help? 14:58:27 proposed RESOLUTION: Explain in the spec intro the rationale why the primary API consumer is a JS framework, note Model Loader API as a higher-level abtraction targeting web developers 15:01:02 Chai: there's nothing wrong for a web dev to call into WebNN API, we want the frameworks to take advantage of WebNN 15:01:28 ... API not for web devs is not fully accurate, but Model Loader API will be easier for web developers for sure 15:02:20 rama has joined #webmachinelearning 15:03:14 RESOLUTION: Explain in the spec intro the rationale why the primary API consumer is a JS framework, note Model Loader API as a higher-level abtraction targeting web developers 15:03:29 Subtopic: String enum for activations 15:03:33 -> https://github.com/webmachinelearning/webnn/issues/138 [tag-tracker] issue #138 15:03:49 anssik: I noted there's an active discussion going on in this issue, I suggest we let this discussion settle before we propose a resolution 15:03:59 ... quoting Sangwhan/TAG: "The fact that hardware-accelerated implementations of common blocks can have limitations is an implementation detail that should not be ossified into the design of the API. Instead of baking the silicon limitations into the API, shouldn't it throw based on the limitations of the context?" 15:04:16 q+ 15:04:22 ... all, please review the issue and provide your perspective 15:04:25 ack chai 15:04:53 Chai: I'm concerned with the proposal from Sangwhan bacouse activation functions is ever growing list 15:05:15 ... there are 20+ but only a subset are relevant 15:05:51 ... we might impose to implementer to support all the activations, or success in some and fail in some 15:06:01 ... either or is bad from API implementer point of view 15:06:12 ... you want to strive for an API you really know can be implemented succesfully 15:06:24 ... otherwise it might be ignored 15:07:10 ... we can already compose a network, see gru section 15:07:56 ... I see both the sides of the discussion, but prefer not leave the API open ended, knowing these are combinations that can fail, the issue is the user might not know when the API fails 15:08:11 ... if the user cannot be confident the API works, the user won't use it 15:08:28 ... I feel quite strongly about my position 15:09:52 anssik: clarifying the extensibility story is one possible approach 15:10:38 zkis has joined #webmachinelearning 15:11:07 RRSAgent, draft minutes 15:11:07 I have made the request to generate https://www.w3.org/2021/04/15-webmachinelearning-minutes.html anssik 15:11:14 RRSAgent, draft minutes 15:11:14 I have made the request to generate https://www.w3.org/2021/04/15-webmachinelearning-minutes.html anssik 15:11:14 Topic: Adjourn 15:13:10 s/proposed RESOLUTION: Merge/RESOLUTION: Merge 15:13:11 RRSAgent, draft minutes 15:13:11 I have made the request to generate https://www.w3.org/2021/04/15-webmachinelearning-minutes.html anssik 16:18:09 zkis has joined #webmachinelearning 17:33:32 Zakim has left #webmachinelearning