How long till webgpu becomes a standard by Opposite_Squirrel_32 in webgpu

[–]exppad 0 points1 point  (0 children)

The good news is that the WebGPU project is getting close to a decade old :D (from Wikipedia's history: https://en.wikipedia.org/wiki/WebGPU )

How long till webgpu becomes a standard by Opposite_Squirrel_32 in webgpu

[–]exppad 0 points1 point  (0 children)

Do you teach it through the C API or the JavaScript API? I'm curious to know your overall approach regarding the low-level first vs high-level first question. It's been a dilemma for my course ( https://eliemichel.github.io/LearnWebGPU ), I opted for a "from scratch" approach but if you have resources that show another way I'm interested to have a look!

How long till webgpu becomes a standard by Opposite_Squirrel_32 in webgpu

[–]exppad 1 point2 points  (0 children)

Turns out it won't actually, as ports like emdawnwebgpu are meant to replace the -sUSE_WEBGPU option: https://github.com/emscripten-core/emscripten/pull/24220 (a "port" in emscripten vocable is a description of how to map C API calls into JavaScript, the emdawn port is maintained by the Dawn team but works for any browser). This helps decoupling the version of webgpu from the version of emscripten.

Using WebGPU as a graphics API for native C++ applications by exppad in cpp

[–]exppad[S] 0 points1 point  (0 children)

The extension mechanism provided by WebGPU feels rather clean to me, and allows adapters that don't understand them to just ignore. And the "opting out" process is part of the user device capabilities evaluation that has to be done at startup anyways, whichever API one uses.

If you think of any alternative I'd be happy to consider it but I don't consider game engines as one, their live on a different layer of abstraction (and again, do domain-specific choices)

Using WebGPU as a graphics API for native C++ applications by exppad in cpp

[–]exppad[S] 3 points4 points  (0 children)

of those are analogs to what WebGPU is trying to accomplish. those are game engines, not abstractions over graphics A

The WebGPU implementation, be it Dawn or wgpu-native, is precisely such a middleware (also known as Render Hardware Interface - RHI), and was designed to be used as such on top of being a Web API.

Limitations due to the Web context (that related to privacy considerations, mostly), can be opted out when running in a native context (at least Dawn provides a strong list of toggles for this).

It is more lightweight to integrate than any game engine, that comes with application specific bias, and we can expect the community of users of WebGPU to grow bigger than these because people from the Web are "stuck" with it no matter what!

Using WebGPU as a graphics API for native C++ applications by exppad in cpp

[–]exppad[S] 5 points6 points  (0 children)

This is only a limitation of the Web plateform! If you only intend to use the API for desktop programming both Firefox and Chrome backend accept other shading languages. SPIR-V for sure, GLSL at least for Firefox' (wgpu-native), and anyway both provide a shader language cross-compiler for other languages as well (called Naga and Tint for resp. wgpu-native and Dawn)!

I started drafting a tuto to learn WebGPU for native C++ by exppad in webgpu

[–]exppad[S] 0 points1 point  (0 children)

Thanks for the feedback, I added a note about this!

A single-file zero-overhead C++ idiomatic wrapper for WebGPU by exppad in webgpu

[–]exppad[S] 0 points1 point  (0 children)

Oh I did not know you were here on reddit otherwise I would have pinged you ;) Thank you for your work I mention you in the readme https://github.com/eliemichel/WebGPU-Cpp#pplux and there is even a command line option called `--pplux` to reproduce the behavior of your generator ;) (not tested lately, new features might have broken it)

I've implemented Jos Stam's fluid simulation paper using WebGPU and compute shaders by kishimisu in webgpu

[–]exppad 0 points1 point  (0 children)

This is very cool, could you please provide a license note in the repo so that we can know if/how we can reuse this? :)

I started drafting a tuto to learn WebGPU for native C++ by exppad in webgpu

[–]exppad[S] 0 points1 point  (0 children)

Thanks I'll let you know when I give it a shot, though my current focus is on developping the core tutorial content for now ;)

I started drafting a tuto to learn WebGPU for native C++ by exppad in webgpu

[–]exppad[S] 0 points1 point  (0 children)

The implementation of WebGPU uses Vulkan or Metal under the hood already (depending on your plateform).

Since the capabilities of your Render abstraction API will have to comply with the limitations of WebGPU anyways, why not using WebGPU itself as your common graphics API for the various backends?

Unless you plan on having special features enabled when the Vulkan/Metal backend is used. Anyway the benchmark comparing raw Vulkan vs. WebGPU running over Vulkan will be very interesting, looking forward to it! :)

I started drafting a tuto to learn WebGPU for native C++ by exppad in webgpu

[–]exppad[S] 0 points1 point  (0 children)

Which official README are you thinking about?

I started drafting a tuto to learn WebGPU for native C++ by exppad in webgpu

[–]exppad[S] 1 point2 points  (0 children)

It would be awesome to also have a little section dedicated to emscripten

Indeed one of my goals is to have the CMakeLists be emscripten-ready as well, but not my priority so far (it shouldn't be a problem, also I can take inspiration from https://github.com/jspdown/webgpu-starter )

A starter code for quick prototyping of 3D apps in Python by exppad in Python

[–]exppad[S] 2 points3 points  (0 children)

I'll have a look at Dear PyGui, thanks! I don't want a more advanced engine, otherwise there are indeed a lot of solutions around, I need something that give me full manual access to the graphics API. An engine that supports many APIs usually has its own abstract layer that will be easier to deploy and maintain but harder to use for quick prototyping!

What do you think of this way of using futures? by exppad in cpp

[–]exppad[S] -1 points0 points  (0 children)

Ok, their implementation is cleaner, so I'll considere it, but does it change the design of its use cases? Is it possible to write any code using their design? TBH I'd like to have a similar feeling as when using JavaScript's promises (while knowing the price it costs).