wasi-nn: refactor to allow preview2 access

[abrown]

This change refactors the wasmtime-wasi-nn crate to allow access from both preview1 and preview2 ABIs. Though the wasi-nn specification has included a WIT description for some time, here we use some in-tree files until WebAssembly/wasi-nn#38 is landed. The preview2 code is not exercised anywhere yet: ideally this would be wired up once component model resources are fully implemented in Wasmtime.

[alexcrichton]

One part of this is that it defines a hierarchy of types and then provides conversion of WIT and WITX-generated types into this hierarchy of types. That's reasonable for this crate since the set of types is quite small, but for something like wasi-common I'm not sure if that would work well (or larger proposals). In that sense it might make more sense to unconditionally generate WIT bindings (e.g. not a compile time feature) and always use the WIT types generated? That way there'd only be one conversion necessary which is WITX-to-WIT.

Also one thing to consider is that this has impl WasiNnTrait for WasiNnCtx which means that it's not going to be easily usable from embedders. Currently with bindgen! we're using something that looks like impl<T> WasiNnTrait for T where T: WasiNnView so that way if WasiNnCtx is embedded in a store somewhere the WasiNnView defines how to access it.

Also as a final thing, it looks like the implementation bodies of WIT and WITX are duplicated? Would it be possible for one to delegate to the other?

[abrown]

In that sense it might make more sense to unconditionally generate WIT bindings (e.g. not a compile time feature) and always use the WIT types generated

Yeah, I would prefer that. Is it fine if wasmtime-wasi-nn enables the component-model feature, though, forcing every user of this (e.g., the CLI) to do so too?

impl<T> WasiNnTrait for T where T: WasiNnView

I saw this over in wasi or wasi-common and didn't really "get" it. Let me look into it a bit more.

Also as a final thing, it looks like the implementation bodies of WIT and WITX are duplicated? Would it be possible for one to delegate to the other?

They are duplicated in essence but not all the details are the same; e.g., anywhere we need a slice in witx.rs we do the Wiggle GuestSlice dance. I'll look into this a bit more...

[abrown]

@alexcrichton: one more thought about your comments is that perhaps some of these improvements could be done as a separate PR. There is clearly more work that needs to be done here (e.g., replace all these temporary WIT files with their upstream versions, implement named models, etc.) so perhaps some of the refactorings you suggest could fit into some of those PRs.

[pchickey]

Adding the representation that is a duplicate of the wasmtime-wit-bindgen generated types creates a lot of noise in this implementation. Wasmtime is going to have the component-model feature enabled in its use in the cli as soon as #6836 lands (should be very soon, just some minor conflicts), at which point you can make wasi-nn available to components as well.

I'd rather see this PR land with just the wit-bindgen generated types instead of the duplicates, rather than iterate on that later.

[pchickey]

This looks a lot better, thanks!

[pchickey]

if the goal of this list of lists is just to pass in a list<u8> for xml and a list<u8> for weights, then can we just make it two arguments that are each list<u8>?

[abrown]

well, other backends will have different numbers of list<u8> to be passed in so the spec has to account for that; the Backend trait mirrors that so that other backends can be implemented.

[geekbeast]

I think eventually we should use named parameters here as well, but @abrown is correct that different frameworks take a different number of options and some even take an execution plan for a model.