You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Moving to a CG-style phases process: https://github.com/WebAssembly/WASI/pull/252
56
+
LC: What should be the expectations for wasi-sdk and/or other toolchains when a feature is stabilized?
57
+
DG: witx support will help wasi-sdk, Rust, and others adopt to new APIs
58
+
PH: witx is written in Rust, we’re happy for people to implement it in other languages as well. Currently it just emits markdown docs. Wasi-libc has a C header generator.
59
+
LC: witx becomes the ABI standard, “bytes on the wire”. Clients may have higher-level abstractions. The ABI is where the stability is. Applications may link against different versions of higher-level abstraction layers, but as long as the ABI layer is stable they can run on ABI-conforming implementations.
60
+
61
+
62
+
Proxy-wasm
63
+
Vote: approve for Phase 1 (see previous item)?
64
+
Result - approved, unanimous
65
+
66
+
Discussion: Next steps.
67
+
Piotr to split out pieces of the spec which can be considered independently.
68
+
69
+
Discussion: Threads in APIs
70
+
https://github.com/WebAssembly/threads/issues/138
71
+
LC: It’d be nice to start thinking about thread safety and which APIs are thread-safe.
72
+
BB: Function signatures are typically not sufficient to know if something is thread-safe.
73
+
LW: The “is shared” predicate needs to be propagated through APIs. Everything is unshared by default. We need a shared attribute for tables, etc., and we’d need to have the shared attribute on functions to make them shared.
74
+
Without the shared attribute, functions can only be called from one thread.
75
+
The shared attribute for functions would need to be added in the core wasm spec, and then witx, being based on core wasm, would inherit it.
76
+
LW: Part of adding threading support sufficient for WASI would require adding a thread-local storage mechanism.
77
+
78
+
Discussion: mmap
79
+
LC: What is the short-term plan for mmap?
80
+
DG: On the web, mmap is complicated by web compat. But WASI can pursue this.
81
+
LW: FWIW, https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#finer-grained-control-over-memory is a long-standing thing we’ve said we’ve wanted in the wasm CG, but maybe it’s better solved by WASI
82
+
83
+
LW: I can put together a proposal for a platform-independent mmap interface.
Copy file name to clipboardExpand all lines: meetings/2020/WASI-05-21.md
+63Lines changed: 63 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -34,3 +34,66 @@ Installation is required, see the calendar invite.
34
34
1. Vote: Approve for Phase 1?
35
35
36
36
## Meeting Notes
37
+
38
+
Attendees:
39
+
40
+
Dan Gohman
41
+
Lee Campbell
42
+
Johnnie Birch
43
+
Andrew Brown
44
+
Mingqiu Sun
45
+
Piotr Sikora
46
+
John Plevyak
47
+
Mark Miller
48
+
Pat Hickey
49
+
50
+
Meeting notes:
51
+
52
+
Update on WASI repository reorganization and new proposal repositories
53
+
54
+
New proposal: wasi-nn: Neural Network API
55
+
https://github.com/WebAssembly/WASI/issues/272
56
+
https://github.com/WebAssembly/wasi-nn
57
+
Any initial feedback?
58
+
Vote: Approve for Phase 1?
59
+
MS: <presentationonWASI-nn>
60
+
MM: What is the intellectual property side of neural networks?
61
+
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.
62
+
MS: We’re working closely with WebNN proposal
63
+
MS: We expect many different hardware architectures will implement backend support.
64
+
MS: Initial POC would target a CPU backend but future devices (GPU, FPGA, TPU) could also be supported.
65
+
MM: Intellectual property is a legal term; is there any attempt at legal protection of these weights?
66
+
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.
67
+
MM: So you’re not talking about legal protection, just about hiding the information?
68
+
MS: Yes, it’s mainly about confidentiality of the model.
69
+
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?
70
+
MS: If you use a programmatic model to define weights it’s a lot harder to protect.
71
+
AB: <APIpresentation>
72
+
AB: Showed the proposal: https://github.com/WebAssembly/WASI/issues/272
73
+
DG: Why explicitly expose the target instead of making it an implementation detail
74
+
AB/MS: Current thought is that it gives the developer more options.
75
+
MM: Could you refactor this to move the target enum into init_execution_context?
76
+
What happens if you ask for a target architecture and it isn’t available?
77
+
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”
80
+
Open question: Web-nn exposes this target parameter; why do that do it?
81
+
AB: I’ll summarize this discussion in an issue.
82
+
AB: Let’s look at how we represent tensors next.
83
+
AB: Is there a better way to represent multi-dimensional arrays?
84
+
85
+
PH: You need a dynamic number of dimensions, and it’s hard to do that, especially with witx in its current form.
86
+
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.
87
+
AB: We’ll learn more about the implementation concerns as we start prototyping this.
88
+
AB: How do we specify how to include dependencies?
89
+
DG/LC: The concept of optional imports may be useful here.
90
+
PH: Also have a PR for profiles that is a way to specify in witx dependencies.
91
+
DG: Have met the requirements for phase 1. Can vote.
0 commit comments