currently this is not necessary because context (WASINNContext) is
local to instance. (wasm_module_instance_t)
i plan to make a context shared among instances in a cluster when
fixing https://github.com/bytecodealliance/wasm-micro-runtime/issues/4313.
this is a preparation for that direction.
an obvious alternative is to tweak the module instance context APIs
to allow declaring some kind of contexts instance-local. but i feel,
in this particular case, it's more natural to make "wasi-nn handles"
shared among threads within a "process".
note that, spec-wise, how wasi-nn behaves wrt threads is not defined
at all because wasi officially doesn't have threads yet. i suppose, at
this point, that how wasi-nn interacts with wasi-threads is something
we need to define by ourselves, especially when we are using an outdated
wasi-nn version.
with this change, if a thread attempts to access a context while
another thread is using it, we simply make the operation fail with
the "busy" error. this is intended for the mimimum serialization to
avoid problems like crashes/leaks/etc. this is not intended to allow
parallelism or such.
no functional changes are intended at this point yet.
cf.
https://github.com/bytecodealliance/wasm-micro-runtime/issues/4313https://github.com/bytecodealliance/wasm-micro-runtime/issues/2430
as wasi-nn doesn't have these concepts, the best we can do without
risking breaking certain applications here is to pass through tensors
as they are.
this matches wasmtime's behavior.
tested with:
* wasmtime classification-example
(with this change, this example fails on tensor size mismatch
instead of implicitly resizing it.)
* license-plate-recognition-barrier-0007, a converted version
with non-fp32 output. [1]
(with this change, this model outputs integers as expected.)
[1] cd7ebe313b/models/public/license-plate-recognition-barrier-0007
- wasi_nn.h: make this compatible with wasi_ephemeral_nn
cf. https://github.com/bytecodealliance/wasm-micro-runtime/issues/4323
- fix WASM_ENABLE_WASI_EPHEMERAL_NN build
this structure is used by host logic as well.
ideally definitions for wasm and host should be separated.
until it happens, check __wasm__ to avoid the breakage.
* this enum is (@witx tag u8) in witx
* it seems that some wasm modules actually use non-zero padding
and cause errors
* it's a bad practice to use C enum for ABI description anyway
sync with a more appropriate version of the definitions.
as we use the "wasi_ephemeral_nn", which is p1-based, it seems
more appropriate to use definitions from witx, not wit.
it's a bit unfortunate p2-based wasi-nn made gratuitous changes
like this from p1.
note: this is an ABI change.
it seems meaningless and quite confusing to access a table with
two aliases ("lookup" and "backends") within a function.
no functional changes are intended.
```
CMake Error at CMakeLists.txt:4 (cmake_minimum_required):
Compatibility with CMake < 3.5 has been removed from CMake.
Update the VERSION argument <min> value. Or, use the <min>...<max> syntax
to tell CMake that the project requires at least <min> but has been updated
to work with policies introduced by <max> or earlier.
Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.
```
A recent change on ./product-mini/platforms/linux/CMakeLists.txt renamed
libiwasm to vmlib, but wasi-nn.cmake still wants to link libiwasm.so.
Replace libiwasm with vmlib in wasi-nn.cmake to resolve iwasm build error
when WAMR_BUILD_WASI_NN enabled.
Rust compiler previously deprecated, and now removed the wasm32-wasi target and replaced it with wasm32-wasip1. This
change updates all the occurrences of wasm32-wasi in the context of Rust compilation.
covers the wasi-nn/test.
By default, the project() CMake command defaults to C and C++. [1]
Therefore, CMake might perform tests for both C and C++ compilers as
part of the configuration phase.
However, this has the consequence of the configuration phase to fail if
the system does not have a C++ toolchain installed, even if C++ is not
really used by the top-level project under the default settings.
Some configurations might still require a C++ toolchain, so
enable_language is selectively called under such circumstances.
[1]: https://cmake.org/cmake/help/latest/command/project.html
We need to fix numpy version since the latest is incompatible.
> A module that was compiled using NumPy 1.x cannot be run in
NumPy 2.0.0 as it may crash. To support both 1.x and 2.x
versions of NumPy, modules must be compiled with NumPy 2.0.
Some module may need to rebuild instead e.g. with 'pybind11>=2.12'.
- All files under *core/iwasm/libraries/wasi-nn* are compiled as shared libraries
- *wasi-nn.c* is shared between backends
- Every backend has a separated shared library
- If wasi-nn feature is enabled, iwasm will depend on shared library libiwasm.so
instead of linking static library libvmlib.a
