abrown opened PR #8873 from abrown:wasi-nn-resources
to bytecodealliance:main
:
Recent discussion in the wasi-nn proposal (see [wasi-nn#59], e.g.) has concluded that the right approach for representing wasi-nn "things" (tensors, graph, etc.) is with a component model _resource_. This sweeping change brings Wasmtime's implementation in line with that decision.
Initially I had structured this PR to remove all of the WITX-based implementation (#8530). But, after consulting in a Zulip [thread] on what other WASI proposals aim to do, this PR pivoted to support _both_` the WITX-based and WIT-based ABIs (e.g., preview1 era versus preview2, component model era). What is clear is that the WITX-based specification will remain "frozen in time" while the WIT-based implementation moves forward.
What that means for this PR is a "split world" paradigm. In many places, we have to distinguish between the
wit
andwitx
versions of the same thing. This change isn't the end state yet: it's a big step forward towards bringing Wasmtime back in line with the WIT spec but, despite my best efforts, doesn't fully fix all the TODOs left behind over several years of development. I have, however, taken the liberty to refactor and fix various parts as I came across them (e.g., the ONNX backend). I plan to continue working on this in future PRs to figure out a good error paradigm (the current one is too wordy) and device residence.[wasi-nn#59]: https://github.com/WebAssembly/wasi-nn/pull/59
[thread]: https://bytecodealliance.zulipchat.com/#narrow/stream/219900-wasi/topic/wasi-nn's.20preview1.20vs.20preview2.20timelineprtest:full
<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
alexcrichton commented on PR #8873:
At a high level this looks reasonable to me, but one recommendation I might have is that the way we implemented WASIp1 was to have it be a wrapper effectively around WASIp2. Internally all of WASIp1 is implemented in terms of WASIp2's underlying functions. Would it be possible to do that here as well? For example storing a
wit::WasiNnCtx
inside of awitx::WasiNnCtx
directly and then using theHost
and such traits to implement the internals?(not required of course just a suggestion)
abrown updated PR #8873.
abrown updated PR #8873.
abrown updated PR #8873.
abrown updated PR #8873.
abrown updated PR #8873.
abrown updated PR #8873.
abrown updated PR #8873.
abrown edited PR #8873:
Recent discussion in the wasi-nn proposal (see [wasi-nn#59], e.g.) has concluded that the right approach for representing wasi-nn "things" (tensors, graph, etc.) is with a component model _resource_. This sweeping change brings Wasmtime's implementation in line with that decision.
Initially I had structured this PR to remove all of the WITX-based implementation (#8530). But, after consulting in a Zulip [thread] on what other WASI proposals aim to do, this PR pivoted to support _both_` the WITX-based and WIT-based ABIs (e.g., preview1 era versus preview2, component model era). What is clear is that the WITX-based specification will remain "frozen in time" while the WIT-based implementation moves forward.
What that means for this PR is a "split world" paradigm. In many places, we have to distinguish between the
wit
andwitx
versions of the same thing. This change isn't the end state yet: it's a big step forward towards bringing Wasmtime back in line with the WIT spec but, despite my best efforts, doesn't fully fix all the TODOs left behind over several years of development. I have, however, taken the liberty to refactor and fix various parts as I came across them (e.g., the ONNX backend). I plan to continue working on this in future PRs to figure out a good error paradigm (the current one is too wordy) and device residence.[wasi-nn#59]: https://github.com/WebAssembly/wasi-nn/pull/59
[thread]: https://bytecodealliance.zulipchat.com/#narrow/stream/219900-wasi/topic/wasi-nn's.20preview1.20vs.20preview2.20timeline
abrown has marked PR #8873 as ready for review.
abrown requested wasmtime-core-reviewers for a review on PR #8873.
abrown requested wasmtime-default-reviewers for a review on PR #8873.
abrown requested alexcrichton for a review on PR #8873.
alexcrichton submitted PR review.
alexcrichton merged PR #8873.
Last updated: Dec 23 2024 at 12:05 UTC