Open yamt opened 2 years ago
No, I don't think so. When I switched this repository over to WIT in #17, I kept the API the same, so unless I unwittingly made a mistake, there should be no change for users.
With #17 now complete, it seems like a good time to migrate existing implementations to the WIT-based tooling (e.g., in Wasmtime, in the wasi-nn bindings repository). Are you interested in helping out with that?
(@radu-matei, we had talked previously about migrating the tract implementation into Wasmtime--what do you think about that now?)
Moving the Tract implementation into Wasmtime is still a really good idea! (particularly because Tract has no additional hardware or software prerequisites)
No, I don't think so. When I switched this repository over to WIT in #17, I kept the API the same, so unless I unwittingly made a mistake, there should be no change for users.
wit version of get-output returns the tensor
record while witx version of it only returns tensor-data.
With #17 now complete, it seems like a good time to migrate existing implementations to the WIT-based tooling (e.g., in Wasmtime, in the wasi-nn bindings repository). Are you interested in helping out with that?
yes. i'm more interested in C implementation than rust though.
(@radu-matei, we had talked previously about migrating the tract implementation into Wasmtime--what do you think about that now?)
wit version of get-output returns the tensor record while witx version of it only returns tensor-data
Oh, sorry, I will fix that.
i'm more interested in C implementation than rust though.
You mean using wasi-nn from C code that you compile to wasm32-wasi
? If so, does wit-bindgen
do enough here or is more needed?
i'm more interested in C implementation than rust though.
You mean using wasi-nn from C code that you compile to
wasm32-wasi
? If so, doeswit-bindgen
do enough here or is more needed?
i meant to implement wasi-nn api for C-based engines. (eg WAMR) my understanding is that wit-bindgen's C support today is only for wasm modules. is it right?
No, I don't think so. When I switched this repository over to WIT in https://github.com/WebAssembly/wasi-nn/pull/17, I kept the API the same, so unless I unwittingly made a mistake, there should be no change for users.
when you say the API is kept, which level are you referring?
the generated rust definitions like mod wasi_nn
? or wasm import/export? or something else?
any update regarding this?
Looking up at the previous comments, I don't think I knew how to respond to this (and still am not clear). Let me take a stab at explaining how I see the wasi-nn world right now:
wit-bindgen
is moving along but until I get the thumbs up that WITX can be replaced, I am planning to keep the WITX definitions around (e.g., see this auto-generation script).wit-bindgen
, e.g.) to provide high-level access to WASI interfaces from a variety of languages (e.g., Rust, C, AS, etc.)--without guest-side bindings, the user has to write raw, low-level, i32
-manipulating code in order to use WASI. On the other side, host-side bindings help engine developers plumb raw Wasm values over to the actual WASI implementation in the engine--without host-side bindings, the engine developer has to write raw, low-level code. wit-bindgen
can also help with host-side bindings and you can (hopefully) understand my confusion and what I'm getting at with my questions up above.Hope that helps!
my understanding is
am i right?