Stream: general

Topic: Experimental WASI WebGPU support


view this post on Zulip 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!

Soon will come the time to decide how to pain something on a screen, are there discussions about this topic in the community? didn't see any. Seeing what WebGPU is supposed to do seems like a n...
Standalone JIT-style runtime for WebAssembly, using Cranelift - bytecodealliance/wasmtime

view this post on Zulip 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?

This issue is a tracking issue for discussing the addition of a machine learning module to WASI. I created a very rough draft of what the API could look like, wasi_ephemeral_nn.witx: it is loosely ...

view this post on Zulip nasso (May 23 2020 at 02:45):

@Leon Wang what do you mean by entry point?

view this post on Zulip Leon Wang (May 23 2020 at 02:46):

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

view this post on Zulip nasso (May 23 2020 at 02:47):

yeha my inner guess was correct then :p

view this post on Zulip 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

Contribute to webgpu-native/webgpu-headers development by creating an account on GitHub.

view this post on Zulip 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).

Low level tooling for WebAssembly . Contribute to bytecodealliance/wasm-tools development by creating an account on GitHub.
Compiler infrastructure and toolchain library for WebAssembly - WebAssembly/binaryen

view this post on Zulip nasso (May 23 2020 at 15:03):

Thanks! I'll look into it!

view this post on Zulip 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!

view this post on Zulip 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

view this post on Zulip 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

view this post on Zulip 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

view this post on Zulip 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.

view this post on Zulip nasso (May 31 2020 at 00:24):

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

view this post on Zulip nasso (May 31 2020 at 00:24):

i can still use it from that folder?

view this post on Zulip 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)

view this post on Zulip 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?)

Contribute to webgpu-native/webgpu-headers development by creating an account on GitHub.
Contribute to webgpu-native/webgpu-headers development by creating an account on GitHub.

view this post on Zulip nasso (May 31 2020 at 00:44):

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

view this post on Zulip Pat Hickey (May 31 2020 at 02:09):

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

view this post on Zulip Pat Hickey (May 31 2020 at 02:09):

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

view this post on Zulip 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

view this post on Zulip 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.

view this post on Zulip Pat Hickey (May 31 2020 at 02:12):

opaque types are called handle in witx

view this post on Zulip 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.

view this post on Zulip nasso (May 31 2020 at 12:15):

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

view this post on Zulip 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 ?

view this post on Zulip nasso (May 31 2020 at 13:21):

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

Contribute to webgpu-native/webgpu-headers development by creating an account on GitHub.

view this post on Zulip 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?

Contribute to webgpu-native/webgpu-headers development by creating an account on GitHub.

Last updated: Dec 23 2024 at 13:07 UTC