Skip to content

Latest commit

 

History

History
99 lines (83 loc) · 4.19 KB

WASI-05-21.md

File metadata and controls

99 lines (83 loc) · 4.19 KB

WASI logo

Agenda for the May 21 video call of WASI Subgroup

  • Where: zoom.us
  • When: May 21, 16:00-17:00 UTC
  • Location: link on calendar invite
  • Contact:

Registration

None required if you've attended before. Email Dan Gohman to sign up if it's your first time. The meeting is open to CG members only.

Logistics

The meeting will be on a zoom.us video conference. Installation is required, see the calendar invite.

Agenda items

  1. Opening, welcome and roll call
    1. Please help add your name to the meeting notes.
    2. Please help take notes.
    3. Thanks!
  2. Proposals and discussions
    1. Update on WASI repository reorganization and new proposal repositories
    2. New proposal: wasi-nn: Neural Network API
      1. WebAssembly#272
      2. https://github.com/WebAssembly/wasi-nn
      3. Any initial feedback?
      4. Vote: Approve for Phase 1?

Meeting Notes

Attendees:

Dan Gohman Lee Campbell Johnnie Birch Andrew Brown Mingqiu Sun Piotr Sikora John Plevyak Mark Miller Pat Hickey

Meeting notes:

Update on WASI repository reorganization and new proposal repositories

New proposal: wasi-nn: Neural Network API WebAssembly#272 https://github.com/WebAssembly/wasi-nn Any initial feedback? Vote: Approve for Phase 1? MS: MM: What is the intellectual property side of neural networks? MS: The weights and the model constitute the intellectual property. By keeping the model outside of the primary source programming language and outside of the main wasm program state, intellectual property is better protected. MS: We’re working closely with WebNN proposal MS: We expect many different hardware architectures will implement backend support. MS: Initial POC would target a CPU backend but future devices (GPU, FPGA, TPU) could also be supported. MM: Intellectual property is a legal term; is there any attempt at legal protection of these weights? MS: It’s hard to protect a model across a development and deployment workflow. Model authors want to ensure that their specific weights are protected. What this proposal says is, the model can be opaque. MM: So you’re not talking about legal protection, just about hiding the information? MS: Yes, it’s mainly about confidentiality of the model. MM: So since the questions that wasm would ask of the model through the API would expose information about the model, has there been any analysis? MS: If you use a programmatic model to define weights it’s a lot harder to protect. AB: AB: Showed the proposal: WebAssembly#272 DG: Why explicitly expose the target instead of making it an implementation detail AB/MS: Current thought is that it gives the developer more options. MM: Could you refactor this to move the target enum into init_execution_context? What happens if you ask for a target architecture and it isn’t available? JB: Would it help to say that the target parameter is a hint? AB: I agree; 99% of the time, what you want is just “pick the best one for me” Open question: Web-nn exposes this target parameter; why do that do it? AB: I’ll summarize this discussion in an issue. AB: Let’s look at how we represent tensors next. AB: Is there a better way to represent multi-dimensional arrays?

PH: You need a dynamic number of dimensions, and it’s hard to do that, especially with witx in its current form. DG: Does this definition give everything the implementer need to be efficient .. to change to the format needed? Agree with Pat multi-dimensional support is a hard problem right now. AB: We’ll learn more about the implementation concerns as we start prototyping this. AB: How do we specify how to include dependencies? DG/LC: The concept of optional imports may be useful here. PH: Also have a PR for profiles that is a way to specify in witx dependencies. DG: Have met the requirements for phase 1. Can vote. LC: What happens if there is a fail? AB: Have a mechanism to return error. Vote: WASI-nn advance to phase 1 SF: 7 F: 5 N: 2

Vote succeeds.