490d49a768
* Adjust dependency directives between crates This commit is a preparation for the release process for Wasmtime. The specific changes here are to delineate which crates are "public", and all version requirements on non-public crates will now be done with `=A.B.C` version requirements instead of today's `A.B.C` version requirements. The purpose for doing this is to assist with patch releases that might happen in the future. Patch releases of wasmtime are already required to not break the APIs of "public" crates, but no such guarantee is given about "internal" crates. This means that a patch release runs the risk, for example, of breaking an internal API. In doing so though we would also need to release a new major version of the internal crate, but we wouldn't have a great hole in the number scheme of major versions to do so. By using `=A.B.C` requirements for internal crates it means we can safely ignore strict semver-compatibility between releases of internal crates for patch releases, since the only consumers of the crate will be the corresponding patch release of the `wasmtime` crate itself (or other public crates). The `publish.rs` script has been updated with a check to verify that dependencies on internal crates are all specified with an `=` dependency, and dependnecies on all public crates are without a `=` dependency. This will hopefully make it so we don't have to worry about what to use where, we just let CI tell us what to do. Using this modification all version dependency declarations have been updated. Note that some crates were adjusted to simply remove their `version` requirement in cases such as the crate wasn't published anyway (`publish = false` was specified) or it's in the `dev-dependencies` section which doesn't need version specifiers for path dependencies. * Switch to normal sever deps for cranelift dependencies These crates will now all be considered "public" where in patch releases they will be guaranteed to not have breaking changes.
wasmtime-wasi-nn
This crate enables support for the wasi-nn API in Wasmtime. Currently it contains an implementation of wasi-nn using OpenVINO™ but in the future it could support multiple machine learning backends. Since the wasi-nn API is expected to be an optional feature of WASI, this crate is currently separate from the wasi-common crate. This crate is experimental and its API, functionality, and location could quickly change.
Use
Use the Wasmtime APIs to instantiate a Wasm module and link in the WasiNn implementation as follows:
let wasi_nn = WasiNn::new(&store, WasiNnCtx::new()?);
wasi_nn.add_to_linker(&mut linker)?;
Build
This crate should build as usual (i.e. cargo build) but note that using an existing installation of OpenVINO™, rather
than building from source, will drastically improve the build times. See the openvino crate for more information
Example
An end-to-end example demonstrating ML classification is included in examples:
tests/wasi-nn-rust-bindingscontains ergonomic bindings for writing Rust code against the wasi-nn APIstests/classification-examplecontains a standalone Rust project that uses the wasi-nn APIs and is compiled to thewasm32-wasitarget using thewasi-nn-rust-bindings
Run the example from the Wasmtime project directory:
ci/run-wasi-nn-example.sh