Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with wasi-nn 0.6.0 TensorType #98

Open
Scramjet911 opened this issue Apr 22, 2024 · 1 comment
Open

Problem with wasi-nn 0.6.0 TensorType #98

Scramjet911 opened this issue Apr 22, 2024 · 1 comment

Comments

@Scramjet911
Copy link

Scramjet911 commented Apr 22, 2024

I was running a wasmedge server with inference support cloned from here, but with newer dependencies and was facing an error in the GraphExecutionContext's set_input function.
It was an issue with the TensorType parameter. I was passing U8 but it was causing an error in the function
[error] [WASI-NN] Expect tensor type U8, but got I32

It works in wasi-nn 0.4, 0.5 but breaks in 0.6
Now I almost found the change and reason it is happening, This commit is changing the order of the generated TensorType enum (The new position of U8 is the previous position of I32).
So I tried setting the input with TensorType::F64 and it worked.

I couldn't figure out where it is breaking though. Since these are just the bindings for rust, I would like to know where the implementation of it is.
I would love to help if someone can point me in the right direction...

@abrown
Copy link
Collaborator

abrown commented May 1, 2024

The file you see changing is generated from this WITX file. The upstream spec likely added some more variants to that enum and changed the order at the same time. Just remember that this bindings library represents the upstream spec and as that changes, this must as well.

A note on the future: the wasi-nn specification, like the rest of WASI, is moving towards specifying its interface in terms of the component model. This means that (1) this WIT file will have all the latest changes going forward, (2) soon you may have to compile your program as a component instead of a core WebAssembly module, and (3) this bindings crate will no longer be necessary (probably archived), since users of many more languages will be able to generate bindings on the fly using wit-bindgen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants