Stream: git-wasmtime

Topic: wasmtime / PR #2208 Add an initial wasi-nn implementation...

Wasmtime GitHub notifications bot (Sep 18 2020 at 18:06):

abrown opened PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/tests/example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [ ] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify wasmtime-wasi-nn works
• [ ] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [ ] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Sep 18 2020 at 18:06):

abrown edited PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/tests/example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [ ] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [ ] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [ ] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 01 2020 at 17:55):

abrown requested sunfishcode for a review on PR #2208.

Wasmtime GitHub notifications bot (Oct 01 2020 at 17:55):

abrown requested alexcrichton and sunfishcode for a review on PR #2208.

Wasmtime GitHub notifications bot (Oct 01 2020 at 17:56):

abrown requested alexcrichton, pchickey and sunfishcode for a review on PR #2208.

Wasmtime GitHub notifications bot (Oct 02 2020 at 17:43):

alexcrichton submitted PR Review.

Wasmtime GitHub notifications bot (Oct 04 2020 at 05:36):

sunfishcode submitted PR Review.

Wasmtime GitHub notifications bot (Oct 04 2020 at 05:36):

sunfishcode submitted PR Review.

Wasmtime GitHub notifications bot (Oct 04 2020 at 05:36):

sunfishcode created PR Review Comment:

Is this copy of SECURITY.md file still needed? Does this come from wasi-nn-rust-bindings previously living in its own repository?

Wasmtime GitHub notifications bot (Oct 04 2020 at 05:36):

sunfishcode created PR Review Comment:

For my curiosity, what is a .bdsignore file?

Wasmtime GitHub notifications bot (Oct 04 2020 at 05:36):

sunfishcode created PR Review Comment:

Is anyhow used in the witx-generation macros, or could it be a dev-dependency?

Wasmtime GitHub notifications bot (Oct 13 2020 at 21:18):

abrown submitted PR Review.

Wasmtime GitHub notifications bot (Oct 13 2020 at 21:18):

abrown created PR Review Comment:

Nope, comes from living in its own repository--removed.

Wasmtime GitHub notifications bot (Oct 13 2020 at 21:19):

abrown submitted PR Review.

Wasmtime GitHub notifications bot (Oct 13 2020 at 21:19):

abrown created PR Review Comment:

It's from Black Duck Protex, which we have to use in scanning code we release... I'll remove them.

Wasmtime GitHub notifications bot (Oct 13 2020 at 21:25):

abrown submitted PR Review.

Wasmtime GitHub notifications bot (Oct 13 2020 at 21:25):

abrown created PR Review Comment:

If I remove it:

error[E0433]: failed to resolve: use of undeclared type or module `anyhow`
  --> crates/wasi-nn/src/lib.rs:9:1
   |
9  | / wasmtime_wiggle::wasmtime_integration!({
10 | |     // The wiggle code to integrate with lives here:
11 | |     target: witx,
12 | |     // This must be the same witx document as used above:
...  |
25 | |     missing_memory: { witx::types::Errno::MissingMemory },
26 | | });
   | |___^ use of undeclared type or module `anyhow`
   |
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

So it looks like it needs to be included?

Wasmtime GitHub notifications bot (Oct 13 2020 at 21:27):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/tests/example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [ ] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [ ] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [ ] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 16 2020 at 20:37):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/tests/example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [ ] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [ ] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [ ] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 16 2020 at 20:38):

abrown edited PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/tests/example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [ ] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [ ] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 16 2020 at 20:38):

abrown edited PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/tests/example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [ ] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 16 2020 at 20:55):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/tests/example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [ ] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 16 2020 at 20:55):

abrown edited PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [ ] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 22 2020 at 23:39):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [ ] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 22 2020 at 23:39):

abrown edited PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [x] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 22 2020 at 23:40):

abrown edited PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [x] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then [edit: I ended up publishing them prior to merging that PR; we are still trying to figure out where that code will end up]
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 22 2020 at 23:47):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [x] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then [edit: I ended up publishing them prior to merging that PR; we are still trying to figure out where that code will end up]
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 22 2020 at 23:49):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [x] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then [edit: I ended up publishing them prior to merging that PR; we are still trying to figure out where that code will end up]
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 22 2020 at 23:51):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [x] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then [edit: I ended up publishing them prior to merging that PR; we are still trying to figure out where that code will end up]
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 22 2020 at 23:55):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [x] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then [edit: I ended up publishing them prior to merging that PR; we are still trying to figure out where that code will end up]
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 22 2020 at 23:59):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [x] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then [edit: I ended up publishing them prior to merging that PR; we are still trying to figure out where that code will end up]
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 23 2020 at 16:13):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [x] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then [edit: I ended up publishing them prior to merging that PR; we are still trying to figure out where that code will end up]
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 23 2020 at 16:27):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [x] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then [edit: I ended up publishing them prior to merging that PR; we are still trying to figure out where that code will end up]
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 23 2020 at 16:40):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [x] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then [edit: I ended up publishing them prior to merging that PR; we are still trying to figure out where that code will end up]
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 23 2020 at 16:48):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [x] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then [edit: I ended up publishing them prior to merging that PR; we are still trying to figure out where that code will end up]
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 23 2020 at 17:06):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [x] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then [edit: I ended up publishing them prior to merging that PR; we are still trying to figure out where that code will end up]
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 23 2020 at 17:07):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [x] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then [edit: I ended up publishing them prior to merging that PR; we are still trying to figure out where that code will end up]
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 23 2020 at 17:12):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [x] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then [edit: I ended up publishing them prior to merging that PR; we are still trying to figure out where that code will end up]
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 23 2020 at 17:38):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [x] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then [edit: I ended up publishing them prior to merging that PR; we are still trying to figure out where that code will end up]
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 23 2020 at 18:07):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [x] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then [edit: I ended up publishing them prior to merging that PR; we are still trying to figure out where that code will end up]
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 23 2020 at 18:09):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [x] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then [edit: I ended up publishing them prior to merging that PR; we are still trying to figure out where that code will end up]
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 23 2020 at 23:03):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [x] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then [edit: I ended up publishing them prior to merging that PR; we are still trying to figure out where that code will end up]
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 23 2020 at 23:17):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [x] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then [edit: I ended up publishing them prior to merging that PR; we are still trying to figure out where that code will end up]
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 23 2020 at 23:41):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [x] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then [edit: I ended up publishing them prior to merging that PR; we are still trying to figure out where that code will end up]
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 24 2020 at 00:07):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [x] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then [edit: I ended up publishing them prior to merging that PR; we are still trying to figure out where that code will end up]
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Oct 24 2020 at 00:24):

abrown has marked PR #2208 as ready for review.

Wasmtime GitHub notifications bot (Oct 24 2020 at 00:30):

abrown requested alexcrichton and pchickey for a review on PR #2208.

Wasmtime GitHub notifications bot (Oct 24 2020 at 00:30):

abrown requested alexcrichton, pchickey and sunfishcode for a review on PR #2208.

Wasmtime GitHub notifications bot (Nov 02 2020 at 18:35):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [x] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then [edit: I ended up publishing them prior to merging that PR; we are still trying to figure out where that code will end up]
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Nov 13 2020 at 00:36):

abrown updated PR #2208 from wasi-nn-rebased to main:

This change adds a crate, wasmtime-wasi-nn, that uses wiggle to expose the current state of the wasi-nn API and openvino to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:

• crates/wasi-nn/examples/classification-example contains Rust code that is compiled to the wasm32-wasi target and run with a Wasmtime embedding that exposes the wasi-nn calls
• the example uses Rust bindings for wasi-nn contained in crates/wasi-nn/tests/wasi-nn-rust-bindings; this crate contains code generated by witx-bindgen and eventually should be its own standalone crate

This change does not wire up wasi-nn to Wasmtime in any way that an external user would be able to observe.

Things to discuss:

• [x] the end-to-end classification test contains a 95MB model weight file which adds considerable weight to a git clone--what to do? Removing the test would mean that the CI could not verify that wasmtime-wasi-nn works
• [x] the openvino crate is not yet published but should be when https://github.com/openvinotoolkit/openvino/pull/2342 is merged; this means that builds of this PR will fail until then [edit: I ended up publishing them prior to merging that PR; we are still trying to figure out where that code will end up]
• [x] the wasi-nn-rust-bindings crate should probably be its own repository but I cannot move it there until I wade through Intel's external release process (for reference, it took me several weeks for the openvino crate); it could be moved to its own repository in a separate PR
• [x] the last time we talked about this, the consensus was to hide the wasi-nn functionality behind a Cargo feature; I will check this item off once I figure out how to do that correctly but I wanted to get feedback on the current approach

Wasmtime GitHub notifications bot (Nov 16 2020 at 18:53):

alexcrichton submitted PR Review.

Wasmtime GitHub notifications bot (Nov 16 2020 at 18:54):

alexcrichton merged PR #2208.

Last updated: Dec 23 2024 at 12:05 UTC