search

bytecodealliance / wasi-nn

High-level bindings for wasi-nn system calls
Apache License 2.0
41 stars 33 forks source link

Problem with wasi-nn 0.6.0 TensorType #98

Open Scramjet911 opened 4 months ago

Scramjet911 commented 4 months ago

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 commented 3 months ago

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.