Questions about WIT transition

[yamt]

my understanding is

• wit version and witx version of the interface are not API/ABI compatible
• the only implemention of the wit version is https://github.com/fermyon/wasi-experimental-toolkit/tree/main/crates/nn-tract-wasmtime

am i right?

[abrown]

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?)

[radu-matei]

Moving the Tract implementation into Wasmtime is still a really good idea!
(particularly because Tract has no additional hardware or software prerequisites)

[yamt]

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?)

[abrown]

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?

[yamt]

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 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?

[yamt]

bytecodealliance/wit-bindgen#285

[yamt]

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.

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?

[tonibofarull]

any update regarding this?

[abrown]

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:

• The component model is moving to WIT; I added a WIT definition for wasi-nn but retained the WITX one until it is absolutely no longer needed. In my view, 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).
• There are two sides to this: guest-side bindings and host-side bindings. Guest-side bindings are what is generated from WIT (by 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.
• I do not believe the wasi-nn specification will be substantially affected by the switch from WITX to WIT. The wasi-nn API is quite high-level and the same concepts can be expressed in both IDLs. If there are any minor ABI changes, they should be due to changes upstream, such as in the component model, etc., not due to wasi-nn itself (unless by typo!). In other words, I'm aiming to keep any changes from the WITX-to-WIT transition separate from any changes to wasi-nn itself (see feature: add "named models" #36, e.g.).

Hope that helps!