WebGPU-Native -> WASI

[tqchen]

As part of the discussion here WebAssembly/WASI#276

There seems to be enough interest to bring webgpu native to WASI(on the wasi side). It would be welcoming devlopment that potentially makes webgpu-native run on wasm vms besides the web env. Just want to bring up the attention from this community, and see if it is of interest to the webgpu-native community (@lachlansneff already volunteered)

[doug-moen]

There is an open issue to add WebGPU to WASI here: WebAssembly/WASI#53

[Kangz]

Can you highlight what would be the difference between wasi-webgpu and webgpu.h + the WebGPU specification? Would it basically add discussion of the event model and maybe more precisions about what happens on mapping?

[tqchen]

My hope is that there shouldn't be any difference ideally, to just land the webgpu-native as a formal wasi spec.

[Kangz]

webgpu.h is not just for WASI though but other native uses, so we'll have to see what the implications are.

[tqchen]

@Kangz I agree, that is why I actually hope you and @kvark could champion the wasi-webgpu spec if possible, to ensure the consistency between the specs.

There are three potential usecases of a GPU API:

• K0: Run on the web
• K1: Run on a native wasm vm(e.g. wasmtime)
• K2: Run on native

WebGPU JS API covers K0, and potentially K2(via nodejs). Vulkan/metal covers K2. Currently webgpu-native covers K0 and K2.

Having webgpu-native as part of WASI would greatly boost the importance of the webgpu-native, because it enables something that neither WebGPU JS API nor the other native APIs(vulkan) can offer(covers all the usecases).

[kainino0x]

IMO adding WebGPU as a WASI spec should be outside the domain of this group. We'll define the header and API contracts and bringing it to WASI should hopefully be mechanical.

If there are changes or decisions that need to be made about webgpu.h in order to support WASI, please file new issues!
For tracking, I'm closing this issue for now.