-> #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 ]
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/
proposed RESOLUTION: split #3 into "Executions ops" and "Execution models"
[ agreement ]
Resolved: split #3 into "Executing ops" and "Executing models"
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
[ hearing nothing ]
Thanks! We're Adjourned. Our next monthly call is scheduled 14 March 2019.
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/