Comment by m-schuetz
8 days ago
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.
> 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.
1 reply →