Support loading models by name#38
Conversation
Also added in typenames to make wit-bindgen generation more straightforward.
|
I think the register/deregister methods make sense for the FaaS scenario, but optional/unnecessary for a standalone env. We should document those two use cases, maybe via sample programs? |
wit/wasi-nn.wit
Outdated
| import execution | ||
| import errors | ||
|
|
||
| export run: func()-> result<_,string> |
There was a problem hiding this comment.
A world definition that exports a run like this is meant for a program that imports those four interfaces, takes no arguments, and has no other imports. I don't think that is actually a world anyone wants to target.
My expectation is that downstream of this spec, embedders will provide the wasi-nn imports, but the export funcs will be part of some other spec. e.g. if its a CLI program the export will be provided by the wasi:cli/command world, and if its used in a web server the export will be provided by the wasi:http/proxy world.
There was a problem hiding this comment.
This may have been a stray experimentation error while I was trying to track down what was causing the wit-bindgen failure. This can be removed entirely.
That said, I wasn't 100% clear on what is going to get exported here for use by other components. Do the graph and execution interfaces need to be exported so that other components can perform inference?
There was a problem hiding this comment.
a world is from the perspective of the user, as opposed to an implementer: import in the world definition says, if I'm writing a component that uses inference I have these interfaces available to import. the implementer of a world needs to make imports available as exports.
README.md
Outdated
| ### Detailed design discussion | ||
|
|
||
| For the details of the API, see [wasi-nn.wit.md](wasi-nn.wit.md). | ||
| For the details of the API, see [wasi-nn.wit.md](legacy_wit/wasi-nn.wit.md). |
There was a problem hiding this comment.
unclear to me why this file was renamed and why the pointer is to it instead of to wit/wasi-nn.wit
There was a problem hiding this comment.
I will just delete it and point it at the new file. If someone needs access they can pull from git history.
This change refactors the `wasmtime-wasi-nn` crate to allow access from both `preview1` and `preview2` ABIs. Though the `wasi-nn` specification has included a WIT description for some time, here we use some in-tree files until WebAssembly/wasi-nn#38 is landed. The `preview2` code is not exercised anywhere yet: ideally this would be wired up once component model `resource`s are fully implemented in Wasmtime.
This change refactors the `wasmtime-wasi-nn` crate to allow access from both `preview1` and `preview2` ABIs. Though the `wasi-nn` specification has included a WIT description for some time, here we use some in-tree files until WebAssembly/wasi-nn#38 is landed. The `preview2` code is not exercised anywhere yet: ideally this would be wired up once component model `resource`s are fully implemented in Wasmtime.
This change refactors the `wasmtime-wasi-nn` crate to allow access from both `preview1` and `preview2` ABIs. Though the `wasi-nn` specification has included a WIT description for some time, here we use some in-tree files until WebAssembly/wasi-nn#38 is landed. The `preview2` code is not exercised anywhere yet: ideally this would be wired up once component model `resource`s are fully implemented in Wasmtime.
This change refactors the `wasmtime-wasi-nn` crate to allow access from both `preview1` and `preview2` ABIs. Though the `wasi-nn` specification has included a WIT description for some time, here we use some in-tree files until WebAssembly/wasi-nn#38 is landed. The `preview2` code is not exercised anywhere yet: ideally this would be wired up once component model `resource`s are fully implemented in Wasmtime. prtest:full
This change refactors the `wasmtime-wasi-nn` crate to allow access from both `preview1` and `preview2` ABIs. Though the `wasi-nn` specification has included a WIT description for some time, here we use some in-tree files until WebAssembly/wasi-nn#38 is landed. The `preview2` code is not exercised anywhere yet: ideally this would be wired up once component model `resource`s are fully implemented in Wasmtime. prtest:full
This change also removes some extra functions that snuck through the review of WebAssembly#38: `set-input-by-name`, `eval`.
* Move original documentation to new `wasi-nn.wit` file This change also removes some extra functions that snuck through the review of #38: `set-input-by-name`, `eval`. * Move `wasi-nn.wit` to top-level directory * Remove original `*.wit.md` documents * Tweak `get-output` return type
* wasi-nn: refactor to allow `preview2` access This change refactors the `wasmtime-wasi-nn` crate to allow access from both `preview1` and `preview2` ABIs. Though the `wasi-nn` specification has included a WIT description for some time, here we use some in-tree files until WebAssembly/wasi-nn#38 is landed. The `preview2` code is not exercised anywhere yet: ideally this would be wired up once component model `resource`s are fully implemented in Wasmtime. prtest:full * wasi-nn: use `preview1` linkage prtest:full * review: rename `preview*` to `wit*` This is based on @pchickey's [comments] on ABI naming. [comments]: https://bytecodealliance.zulipchat.com/#narrow/stream/266558-wasi-nn/topic/wasi-nn.20.2B.20preview2/near/383368292 * review: update README * fix: remove broken doc links * fix: replace typo `wit` with `gen` * review: use `wit` types everywhere This removes the crate-specific types in order to use the WIT-generated types throughout the crate. The main effect of this is that the crate no longer optionally includes `wasmtime` with the `component-model` feature--now that is required. * review: move `BackendKind` conversion into `witx.rs` * review: remove `<'a>` * review: use `tracing` crate instead of `eprintln!`
* wasi-nn: refactor to allow `preview2` access This change refactors the `wasmtime-wasi-nn` crate to allow access from both `preview1` and `preview2` ABIs. Though the `wasi-nn` specification has included a WIT description for some time, here we use some in-tree files until WebAssembly/wasi-nn#38 is landed. The `preview2` code is not exercised anywhere yet: ideally this would be wired up once component model `resource`s are fully implemented in Wasmtime. prtest:full * wasi-nn: use `preview1` linkage prtest:full * review: rename `preview*` to `wit*` This is based on @pchickey's [comments] on ABI naming. [comments]: https://bytecodealliance.zulipchat.com/#narrow/stream/266558-wasi-nn/topic/wasi-nn.20.2B.20preview2/near/383368292 * review: update README * fix: remove broken doc links * fix: replace typo `wit` with `gen` * review: use `wit` types everywhere This removes the crate-specific types in order to use the WIT-generated types throughout the crate. The main effect of this is that the crate no longer optionally includes `wasmtime` with the `component-model` feature--now that is required. * review: move `BackendKind` conversion into `witx.rs` * review: remove `<'a>` * review: use `tracing` crate instead of `eprintln!`
This change has been scoped down to only adding support for getting a handle to a named model for inference and updating the WIT bindings to the latest spec.