Wasmtime GitHub notifications bot (Jun 25 2024 at 19:21): Wasmtime GitHub notifications bot (Jun 25 2024 at 19:21):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
witandwitxversions 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
-->
Wasmtime GitHub notifications bot (Jun 25 2024 at 20:19):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::WasiNnCtxinside of awitx::WasiNnCtxdirectly and then using theHostand such traits to implement the internals?(not required of course just a suggestion)
Wasmtime GitHub notifications bot (Jun 26 2024 at 01:17):abrown updated PR #8873.
Wasmtime GitHub notifications bot (Jun 26 2024 at 17:25):abrown updated PR #8873.
Wasmtime GitHub notifications bot (Jun 26 2024 at 21:24):abrown updated PR #8873.
Wasmtime GitHub notifications bot (Jun 26 2024 at 21:34):abrown updated PR #8873.
Wasmtime GitHub notifications bot (Jun 26 2024 at 22:21):abrown updated PR #8873.
Wasmtime GitHub notifications bot (Jun 27 2024 at 18:22):abrown updated PR #8873.
Wasmtime GitHub notifications bot (Jun 27 2024 at 18:55):abrown updated PR #8873.
Wasmtime GitHub notifications bot (Jun 27 2024 at 18:56):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
witandwitxversions 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
Wasmtime GitHub notifications bot (Jun 27 2024 at 18:58):abrown has marked PR #8873 as ready for review.
Wasmtime GitHub notifications bot (Jun 27 2024 at 18:58):abrown requested wasmtime-core-reviewers for a review on PR #8873.
Wasmtime GitHub notifications bot (Jun 27 2024 at 18:58):abrown requested wasmtime-default-reviewers for a review on PR #8873.
Wasmtime GitHub notifications bot (Jun 27 2024 at 18:58):abrown requested alexcrichton for a review on PR #8873.
Wasmtime GitHub notifications bot (Jun 27 2024 at 19:13):alexcrichton submitted PR review.
Wasmtime GitHub notifications bot (Jun 27 2024 at 19:31):alexcrichton merged PR #8873.
Last updated: Nov 22 2024 at 17:03 UTC