W3C

– DRAFT –
WebML CG Teleconference – 14 February 2019

14 February 2019

Meeting minutes

High level vs low level revisited

-> #3 High level vs low level https://‌github.com/‌webmachinelearning/‌webnn/‌issues/‌3

anssik: a lot of discussion in this mega issue #3, hard to resolve since we're branching to multiple directions
… proposal to split into self-contained issues that we can resolve one at a time and make progress with

anssik: my key takeaways from the mega issue #3 are the following positions, quoting:
… @nsthorat: Our preference from TensorFlow is for this specification to focus on operations.
… @RafaelCintron: WebML should include both a "loadModel-style" and "operator-style" APIs.

-> @nsthorat's position https://‌github.com/‌webmachinelearning/‌webnn/‌issues/‌3#issuecomment-453129272

-> @RafaelCintron's position https://‌github.com/‌webmachinelearning/‌webnn/‌issues/‌3#issuecomment-457886464

... I observed one question Rafael asked from Nikhil is unanswered, maybe we can discuss it now? Specifically:

"An operator-style API should allow web developers to build their graph using Javascript function calls. Once the graph is in place, graph-rewriting and fusing of operations like you describe could be possible by the user agent. Am I missing something or do you have a different notion of what an operator-style API entails than I do?"

-> quote from @RafaelCintron's comment https://‌github.com/‌webmachinelearning/‌webnn/‌issues/‌3#issuecomment-454250090

dsmilkov: I like the idea that you could execute a single operation, or a chain of operation, if the API allows makes it much more flexible
… the reason why more flexible, the model you try to exec need to be done in user code
… being able to exec some using built-in ops and go back and forth from user code

[ agreement that there's a common ground, follow up on GH ]

Eager and graph execution mode mapping to native

anssik: next subtopic, implications of eager and graph execution mode mapping

-> eager and graph execution mode mapping https://‌github.com/‌webmachinelearning/‌webnn/‌issues/‌3#issuecomment-459755470

NingxinHu: related to the previous discussion, single operation is eager execution, raphael's graph is execution model

[ NingxinHu describing the findings documented in the mapping table ]

<kreeger> +1 to new issue

<kreeger> Too much discussion on #3

dsmilkov: two issues: 1) exec of ops 2) exec of models

s/discussions/issues to be created/

Splitting the mega issue

proposed RESOLUTION: split #3 into "Executions ops" and "Execution models"

[ agreement ]

Resolved: split #3 into "Executing ops" and "Executing models"

Custom operations

anssik: Daniel Smilkov raised this issue on our previous call and kindly opened an issue for it so we can follow up. I see positions for and against.
… I believe everyone would be fine if we'd commence with some of the investigation and do a decision after we're more informed of the problem space.
… I heard two possible investigation tasks: 1) browser implementation feasibility of built-in ops, 2) survey ops needed to write custom ops

RafaelCintron: OK to investigate, but could ship v1 w/o them and defer to v2

dsmilkov: I wasn't clear when filed the issue that for TF fast data exchange is crucial

NingxinHu: I think if it helps I can investigate as mentioned in the issue, possible investigation is for the CPU side, based on our current setup
… specifically, investigate Wasm implementation path with CPU backend on macOS or Linux
… as for the WebGPU and TF WebGL backend, is it reasonable to investigate WebGL exchange with MPS etc?

kreeger: we've discussed this on our end, op level accelerated endpoints, curious how the spec falls down to multiple long tail devices

kreeger: open-ended questions on how ops are accelerated on specific devices

RafaelCintron: browser could take hints

<kreeger> re: model loading in browser - lots of work for browser vendors to maintain - questions about quantization

<rgesteve> I'd be very grateful to hear about the limitations of NNAPI as briefly described by Nikhil

<rgesteve> as part of the initial WebML API design was based on devices declaring capabilities inspired in the NNAPI design

Any other business

[ hearing nothing ]

Thanks! We're Adjourned. Our next monthly call is scheduled 14 March 2019.

Summary of resolutions

  1. split #3 into "Executing ops" and "Executing models"
Minutes manually created (not a transcript), formatted by Bert Bos's scribe.perl version 2.49 (2018/09/19 15:29:32), a reimplementation of David Booth's scribe.perl. See CVS log.

Diagnostics

Failed: s/discussions/issues to be created/

Succeeded: s/nick/kreeger/

Succeeded: s/Executions ops/Executing ops/

Succeeded: s/Execution models/Executing models/

Succeeded: s/two discussion:/two issues:/

Succeeded: s/exec models/exec of models/

Succeeded: s/exchange crucial/exchange is crucial/

Succeeded: s/since based on/based on/