I'm still hoping that WebGPU somehow takes off for non-web use so that we have an easy to use cross platform API with an official spec (a replacement for opengl). However, it seems that outside of the Rust world, there doesn't seem to be much interest for using WebGPU for native code. I don't know any big projects using Dawn for example. Part of the reason seems to be that WebGPU came a bit too late and everyone was already using custom-built abstractions over dx, vulkan and metal.
It won't. It's barely simpler but lacks a lot of functionality. Some stuff that became optional in Vulkan (render passes) are still mandatory on WebGPU, and bind groups are static and thus cumbersome. It also adds additional limitations and cruft, like you can't easily transfer from host to a buffer subregion and need staging buffers.
I'll use it for web since there is no alternative, but for desktop I'll stick with an OpenGL+CUDA interop framework until a sane, modern graphics API shows up. I.e., a graphics API that gets rid of render pases, static pipelines, mandatory explizit syncing, bindings and descriptor sets (simply use buffers and pointers), and all the other nonsense.
If allocating and populating a buffer takes more effort than a simple cuMemAlloc and cuMemcpy, and calling a shader with arguments takes more than simply passing the shader pointers to the data, then I'm out.
>Some stuff that became optional in Vulkan (render passes) are still mandatory on WebGPU
I'd like to call out that a render pass in WebGPU is not like a VkRenderPass. In Vulkan pre-1.3, a VkPipeline and VkFramebuffer are tightly coupled to a VkRenderPass. In WebGPU the pipeline is independent and there is no framebuffer object. Render targets are specified at the start of rendering commands like they are in Vulkan 1.3's dynamic rendering.
>you can't easily transfer from host to a buffer subregion and need staging buffers
For what it's worth, WebGPU has [0] GPUQueue.writeBuffer() and GPUQueue.writeTexture() which do not require an (exposed) staging buffer. They're about as straightforward to use as cudaMemcpy().
...that's assuming that the WebGPU API is set in stone, which hopefully it isn't.
They'd do well to follow the D3D model (major breaking versions, while guaranteeing backward compatibility for older versions) - e.g. WebGPU2, WebGPU3, WebGPU4 each being a mostly new API without having to compromise for backward compatibility.
WebGPU had more features and capabilites back in 2020 before they started removing and limiting them. Forgive my lack of enthusiasm and optimism for the future prospects of an API that was already ancient when development started, and even less capable by the time it was released.
> WebGPU had more features and capabilites back in 2020 before they started removing and limiting them
I think that's the price to pay for trying to cover a wide range of hardware. You can't just make all those shitty Android phones disappear. At least for each WebGPU limit, there's usually a Github ticket which explains why exactly this limit exists.
Yeah, unfortunately I'm in real-time rendering research so I like to play with fairly modern desktop GPUs. The no-phone-left-behind policy made WebGPU a somewhat unattractive target for me. Which is unfortunate because during the early days it felt like we'd get a cutting-edge modern API for the browser and I was excited and ready to abandon OpenGL for WebGPU. Instead, I ended up switching to CUDA which I avoided for years due to platform dependency. But once I noticed how pleasant it is to work with I could not go back to graphics APIs. I really like the "easy things should be easy, complex things should be possible" design of Cuda.
Another reason may be that WebGPU didn't allow for as much optimization and control as Vulkan, and the performance isn't as good as Vulkan. WebGPU also doesn't have all the extensions that Vulkan has.
Even webgl don't give any gurentee about your code will run well on any devices though. It only gurentee that it will run, but it can have 10x performance difference on different platform depends on how you wrote the shaders.
As anyone used to Khronos APIs is aware, that is of little value without actual Conformance Tests Suites, and even then there are plently of forgotten guarantees when using consumer hardware with all the usual OEM quality practices.
Good then that even WebGL mostly doesn't run on Khronos APIs ;) (only on Linux, although I don't know whether ANGLE is now actually using a Vulkan backend on Linux - which of course is also a Khronos API though).
Both WebGL2 and WebGPU are probably the most 'watertight' specced and tested 3D API ever built, and especially WebGPU has gone to great lengths to eliminate UB present in native APIs (even at the cost of usability).
The Android OS and the entire Android ecosystem being a huge pile of excrement isn't really surprising though. But it's 'too big to ignore' unfortunately, at least for browser APIs.
I think the parent is implying there are 1001 soc out there with some form of embedded gpu that probably have issues actually implementing webgpu. Like those in millions of Chinese tablets. Are they likely targets? Probably not now but in 5 years? Mainstream desktop hardware? No problem.
Some part of it is also probably the atrocious naming. I don't do anything with web, only native coding, so whenever I heard something about web gpu somewhere I just ignored it, for literally years, because I just assumed it was some new web tech and thus not relevant to me at all.
