Mendy Berger (May 01 2024 at 21:13): Mendy Berger (May 01 2024 at 21:13):Seems like a lot of wasi proposals are struggling with how to do shared buffers, since wasm doesn't allow for easy mounting and unmounting of memory.
E.g. wasi-webgpu needs to provide access to a gpu-buffer when it's mapped to the cpu, but not when it's mapped to the gpu. And the gpu-buffers constantly change where they're mapped to.
Another example is wasi-frame-buffer. The buffer that's writable changes at every frame, and there's no way to mount and unmount buffers like this in wasm.
I believe that wasi-nn and the embedded SIG have been dealing with the same issue. So I think it might make sense to solve it together.
So I was thinking, can we just use a wit resource with get/set methods? This will allow for easy mounting/unmounting, and can be done with the current tooling already.
Something like the following:
resource remote-buffer {
get8: func(i: u32) -> u8;
set8: func(i: u32, val: u8);
get-range8(from: u32, to: u32) -> list<u8>;
set-range8(from: u32, vals: list<u8>);
get32: func(i: u32) -> u32;
set32: func(i: u32, val: u32);
get-range32(from: u32, to: u32) -> list<u32>;
set-range32(from: u32, vals: list<u32>);
length: func() -> u32;
}
Thoughts anyone?
(cc'ing some people I've had discussions about this or related topics @Sean Isom @Atanas Atanasov @Chris Woods @Andrew Brown @Mingqiu Sun @Dan Gohman @Bailey Hayes)
Sean Isom (May 02 2024 at 21:21):This makes sense to me - from the graphics perspective, this will solve the problem of giving ephemeral access to mapped GPU buffers to Wasm guests and let the host take ownership when unmapped. @Chris Woods curious if this will work for some of your embedded use cases
Last updated: Dec 23 2024 at 12:05 UTC