Comment by coffeeaddict1
9 days ago
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().
[0]: https://developer.mozilla.org/en-US/docs/Web/API/GPUQueue
...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.
2 replies →
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.
It is called middleware, no need to wait for WebGPU outside of the browser, with all the constraints of an API design targeted to browser sandboxes.
None of those middlewares have a spec and none of them offer the compatibility guarantees that WebGPU provides.
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.
8 replies →
Can you point me to some good middleware then? I haven't been able to find any.
GDC Vault programming track has plenty of examples.
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.