Stream: general

Topic: Experimental WASI WebGPU support

nasso (May 22 2020 at 19:22):

Hello!

I have a personal project that has a plugin system based on WASM (all plugins are just *.wasm files).
I will have 2 hosts for those plugins: one is web based (in the web browser) and the other is native (using wasmtime).
The same plugin must work the same way on the two hosts, so I thought using WASI was a good idea!

My issue is that the plugins must be able to render images, so I'd like to use WebGPU (because it's available on all platforms), but WASI doesn't have WebGPU support (though discussed on this issue).

I'd like to experiment locally and add the WebGPU API to wasi-common, but I have no idea where to start and how to test it.
Maybe I should mention the fact that I'm on Windows 10 (though I have WSL 2 and a laptop running a native GNU/Linux distribution if the need arises).
Thanks!

Leon Wang (May 23 2020 at 02:36):

@nasso Nice suggestion, maybe the proposal of WASI-nn (https://github.com/WebAssembly/WASI/issues/272) would help to formulate the entrypoint?

nasso (May 23 2020 at 02:45):

@Leon Wang what do you mean by entry point?

Leon Wang (May 23 2020 at 02:46):

You can design the wit interface based on the WASI-nn proposal.

nasso (May 23 2020 at 02:47):

yeha my inner guess was correct then :p

nasso (May 23 2020 at 02:51):

Are there tools to make the process a little less repetitive? I think the interface would be very similar to this header

Leon Wang (May 23 2020 at 02:54):

Sorry I'm not very familiar with the tool, but I think you can find it from the organization (https://github.com/bytecodealliance/wasm-tools or https://github.com/WebAssembly/binaryen).

nasso (May 23 2020 at 15:03):

Thanks! I'll look into it!

nasso (May 31 2020 at 00:18):

The WebGPU API has a lot of custom types, should I define those types in typenames.witx like its done for the other witx files? I guess not, since the nn proposal doesn't, but I prefer to ask!

Pat Hickey (May 31 2020 at 00:19):

i'd discourage adding more stuff to typenames.witx - one thing we've talked about informally is that, with a bunch of proposed extensions to wasi including your own, we are going to need namespacing of type names

Pat Hickey (May 31 2020 at 00:20):

so probably all typenames will end up being defined inside modules at some point, or maybe some other mechanism to allow many namespaces

Pat Hickey (May 31 2020 at 00:20):

at any rate, theres no reason to add them to typenames.witx if you can just put them in a separate file

Pat Hickey (May 31 2020 at 00:22):

so id encourage you to write all of the webgpu types and modules in a separate witx file, and only take deps on the existing wasi via (use "wasi_snapshot_preview1.witx"), because at some point soonish typenames.witx may not exist anymore.

nasso (May 31 2020 at 00:24):

oh i should use the snapshot? im in the ephemeral folder right now

nasso (May 31 2020 at 00:24):

i can still use it from that folder?

nasso (May 31 2020 at 00:27):

either way, for now i will create them in my witx file and prefix them like in c (e.g. $gpu_adapter)

nasso (May 31 2020 at 00:30):

though, what is the usual way to type opaque types in a wasi interface? like, im basically mapping the webgpu API from webgpu.h but im not sure if i should typename pointers (e.g. on line 59) to u64 or if there's a better type for it (usize i'd guess?)

nasso (May 31 2020 at 00:44):

after second thought, maybe i should model the module type after the WebGPU WebIDL instead?

Pat Hickey (May 31 2020 at 02:09):

sorry, was afk. yeah, rather than snapshot you should import ephemeral if you're in ephemeral.

Pat Hickey (May 31 2020 at 02:09):

witx describes something a lot closer to a C header file than webidl

Pat Hickey (May 31 2020 at 02:10):

the interface types repo contains a writeup some explanations of why webidl is not very well-suited for describing webassembly interfaces. but in short, i would stick to the c headers

Pat Hickey (May 31 2020 at 02:11):

the goal of witx is to eventaully describe interface types, but since there are no implementations of that proposal yet, we are still describing a C ABI. so, starting with a c header is the best way for now.

Pat Hickey (May 31 2020 at 02:12):

opaque types are called handle in witx

Pat Hickey (May 31 2020 at 02:12):

they get represented as u32 for now. when interface types comes, itll be possible to represent them as ref types (for languages that support it), u32, u64, etc.

nasso (May 31 2020 at 12:15):

thanks for the info! i will stick to the C header then!

nasso (May 31 2020 at 13:18):

Pat Hickey said:

sorry, was afk. yeah, rather than snapshot you should import ephemeral if you're in ephemeral.

there doesn't seem to be a wasi_ephemeral_preview1.witx, what should i import ?

nasso (May 31 2020 at 13:21):

also, how would i represent C enums with explicit values (like on line 85) in witx?

nasso (May 31 2020 at 16:11):

wgpuCreateInstance takes a WGPUInstanceDescriptor const * descriptor as the first parameter, should i represent that as a u32 or is there a better type for that?

Last updated: Nov 22 2024 at 17:03 UTC