Hacker News Reader

Comment by coffeeaddict1 | Hacker News Reader

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.

View on HN

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.

...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.

>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

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.

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.

wgpu can run the WebGPU Conformance Test Suite for validation against the WebGPU specification. Was there something else you'd like to see?

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.

they just have to implement Vulkan, enough for it to run Dawn or wgpu

See Android for how much fun it is to debug OpenGL ES and Vulkan issues.

Not really, as mentioned, middleware does the job with much better developer tooling.

What I really would like to see is browser vendors finally providing WebGL and WebGPU debugging tools.

I think a decade has been more than enough for that.

Then again, no one is paying for browsers, so I guess I should not complain.

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).

And yet it is lots of fun to debug on Android.

We only need to open chrome://gpu and see how many workarounds are implementated.

Those that happen to own a device where workarounds are yet to be implemented, have quite interesting experiences, depending on the root cause.

As this is an increasing list across Chrome releases.

Lets see how it works out there with Firefox and Safari, the later still not fully WebGL 2.0 compliant.

So much for the watertightness.

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.

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.

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.

Reply on news.ycombinator.com