Thanks - hopefully it will serve well. For now, given that Google already did a great work of developing a compatible bindings library, I did not want to entertain the idea of upstreaming this library to one of the Emscripten "system" headers. We certainly would not want to maintain two different ones side by side there.
I don't know how many developers will find it valuable to be able to target WebGPU outside the browser via Dawn, so it is hard for me to judge which bindings layer is of "better" value. Hence giving way to the Google-developed one in Emscripten, and developing our own thing in a separate repo. I know Kai was pondering the idea of what it would look like to implement the Dawn cross-platform compatibility header on top of wasm_webgpu implementation, though not sure how much value that work would be either, given that the current Dawn WebGPU bindings library already exists in Emscripten. The old headers for OpenAL, GLFW, SDL1.4, GLEW, X11, EGL are all something I wish one day we'll be able to remove. They were immensely useful back in the day when Emscripten was in its infancy setting out to prove its viability. Now, and especially with the requirements brought on by SharedArrayBuffer for multithreading, their implementations don't follow the best practices anymore, so we should not use their existence as a motivation for adding more into Emscripten. Wasm_webgpu is able to live comfortably as a "userspace" library in a separate repo, with the sole exception of issue https://github.com/emscripten-core/emscripten/issues/15211 , which is a problem that we don't have a solution for. I.e. due to #15211 Emscripten system JS library headers are "more powerful" compared to user-created JS libraries. On Thu, Aug 25, 2022 at 6:43 PM Floh <[email protected]> wrote: > > This looks super interesting for cross-platform 3D API wrapper libs like my > sokol_gfx.h, where access to WebGPU doesn't actually need to go through the > cross-platform webgpu.h header, because linking with a native WebGPU > implementation like libdawn or wgpu.rs isn't a primary goal (because when > compiled natively, the header will talk directly to Metal, GL or D3D11 > instead - although having a native WebGPU implementation is nice during > implementation of the backend and for debugging). > > If there are some obvious advantages (like the different resource mapping > approach) I wonder if it makes sense to put this wrapper into the Emscripten > SDK as an alternative to webgpu.h? It's not like the Emscripten include > directory isn't already a pretty wild hodgepodge of web API wrappers ;) > ...and in my experience at least, the API wrappers which are more closely > modelled after their underlying web APIs have been a lot more flexible and > useful than the API wrappers which tried to emulate 'native platforms APIs' > (like OpenAL, GLFW, SDL etc...). > > Cheers and thanks for putting your work on github instead of keeping it > inhouse :) > -Floh. > On Wednesday, 24 August 2022 at 12:51:04 UTC+2 jj wrote: >> >> Hey all, >> >> Emscripten supports targeting WebGPU out of the box via the >> -sUSE_WEBGPU linker flag and a set of WebGPU headers that are provided >> by Google autogenerated from the Dawn project. >> >> I have been working on our own set of handwritten interop headers for >> WebGPU. We use this interop layer at Unity for prototyping our WebGPU >> experiments. >> >> The reason for writing another system header is that we had slightly >> different goals than what the current Emscripten WebGPU bindings have. >> >> One of the goals of the Dawn-provided headers is to enable one to also >> target other native platforms (Windows/Linux/etc.) with WebGPU by >> linking against the Dawn API. >> >> In our case, we only wish to target the web, so wanted an interop >> layer tuned specifically for Wasm<->JS interop, hence handwriting a >> bindings layer specifically for that task. >> >> This resulted in the imaginatively named wasm_webgpu repository, which >> you can find at https://github.com/juj/wasm_webgpu . This enables a >> low-level C style API for accessing WebGPU in a browser. >> >> The project has been at a complete enough stage for quite a while now, >> and is up to date with the latest WebGPU specification draft at the >> time of writing, so I wanted to advertise its existence here, in case >> someone else might find it useful to play around with. Bug reports are >> welcome! >> >> Cheers, >> Jukka > > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/4ce07754-3d10-444a-a42a-c0d8c1da0b80n%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CA%2B6sJ-0z2f%3DKufFs5tNE7NUc4pzT42gfUqq02jkFdNtGPL2vDA%40mail.gmail.com.
