I know the gfx-rs have been working hard on their WebGPU implementation and have been pushing the spec. With Google having their own implementation, is this a positive signal that WebGPU might manifest into a real contender in the graphics api space?
They should just use sexpr and call it a day. Nobody is going to write shaders in that stupid language anyway. Call it Not-Spirv to make Apple legal happy.
WebGPU is a much more approachable API than Vulkan or DirectX 12 and is more portable than either (or Metal, which is secretly the best graphics API available today if you can put up with Apple). If you're trying to hack something together or write something nominally portable like you could in the good old days of OpenGL, I'd recommend starting with WebGPU. *
However, it's not at all a viable replacement and it's not clear it has a path to become one in its current state. WebGPU is limited to a least common denominator of features that sets it back at least half a decade of hardware and API advancement. Some of these features (like raw pointers to buffers) would be challenging to adapt to the safety requirements expected of WebGPU.
Then, you have to consider that it's yet another layer of indirection on top of a stack that's already filled with more magic than any one developer or company can keep in their head(s). It's another layer removed from the driver written by hardware vendors, too, so hitting the fast paths gets a little harder. Plenty of devs are already hesitant to move from DX12 to Vulkan, so if they move to WebGPU, it'll start with baseline support for browsers and not much else, then maybe expand if WebGPU somehow goes deeper into the hardware stack.
* I need to asterisk this because, to be honest, I think the whole paradigm behind all these APIs is complete and utter garbage but that's a much longer conversation and has no obvious resolution in sight.
> Metal, which is secretly the best graphics API available today if you can put up with Apple
Part of what makes an API good is how portable code written against it is and with Metal that is exactly zero. Phrasing it as "if you can put up with Apple" is disingenuous. It's more like "if you're willing and can afford to only target one single platform that isn't even the most widely used, has very limited hardware choices and is outside the price range of significant chunks of the population".
7 comments
[ 13.4 ms ] story [ 36.1 ms ] threadCurrently it looks like C++, HLSL and Rust had a son, and they are still half way there.
If WebGL progress is to be replicated by WebGPU, in 10 years everyone might eventually support it properly.
Where will native 3D APIs in 10 years time?
However, it's not at all a viable replacement and it's not clear it has a path to become one in its current state. WebGPU is limited to a least common denominator of features that sets it back at least half a decade of hardware and API advancement. Some of these features (like raw pointers to buffers) would be challenging to adapt to the safety requirements expected of WebGPU.
Then, you have to consider that it's yet another layer of indirection on top of a stack that's already filled with more magic than any one developer or company can keep in their head(s). It's another layer removed from the driver written by hardware vendors, too, so hitting the fast paths gets a little harder. Plenty of devs are already hesitant to move from DX12 to Vulkan, so if they move to WebGPU, it'll start with baseline support for browsers and not much else, then maybe expand if WebGPU somehow goes deeper into the hardware stack.
* I need to asterisk this because, to be honest, I think the whole paradigm behind all these APIs is complete and utter garbage but that's a much longer conversation and has no obvious resolution in sight.
Part of what makes an API good is how portable code written against it is and with Metal that is exactly zero. Phrasing it as "if you can put up with Apple" is disingenuous. It's more like "if you're willing and can afford to only target one single platform that isn't even the most widely used, has very limited hardware choices and is outside the price range of significant chunks of the population".
https://github.com/KhronosGroup/GLSL/blob/master/extensions/...