As I see it, the current state of graphics API is worse now than the OpenGL era, despite its promises none of the modern API's are easier to use, truly portable and cross platform.
Having to reinvent OpenGL by creating custom wrappers around Vulkan, Metal, DirectX12, etc is such a time waster as dropping strings and going back to raw char arrays in the name of performance on every modern language.
whatevsmate · 44m ago
What promises were made, by whom? Graphics APIs have never been about ease of use as a first order goal. They've been about getting code and data into GPUs as fast as reasonably possible. DevEx will always play second fiddle to that.
I think WebGPU is a decent wrapper for exposing compute and render in the browser. Not perfect by any means - I've had a few paper cuts working with the API so far - but a lot more discoverable and intuitive than I ever found WebGL and OpenGL.
unconed · 30m ago
"What promises were made, by whom?"
Technically true, but practically tone deaf.
WebGPU is both years too late, and just a bit early. Wheras WebGL was OpenGL circa 2005, WebGPU is native graphics circa 2015. It shouldn't need to be said that the bleeding edge new standard for web graphics shouldn't be both 10 years out of date and awful.
Vendors are finally starting to deprecate the old binding model as the byzantine machinery that it is. Bindless resources are an absolute necessity for the modern style of rendering with nanite and raytracing.
Rust's WGPU on native supports some of this, but WebGPU itself doesn't.
It's only intuitive if you don't realize just how huge the gap is between dispatching a vertex shader to render some triangles, and actually producing a lit, shaded and occlusioned image with PBR, indirect lighting, antialiasing and postfx. Would you like to render high quality lines or points? Sorry, it's not been a priority to make that simple. Better go study up on SDFs and beziers.
Which, tbh, is the impression I get from webgpu efforts. Everyone forgets the drivers have been playing pretend for decades, and very few have actually done the homework. Of those that have, most are too enamored with being a l33t gfx coder to realize how terrible the dev exp is.
dvdkon · 1h ago
I don't see the problem. There have been lower-level APIs in the graphics stack for a long time (e.g. Mesa's Gallium), only now they are standardised and people are actually choosing to use them. It's not like higher-level APIs don't exist now, OpenGL is still supported on reasonable platforms and WebGPU has been usable from native code for some time.
As for true portability of those low-level APIs, you've basically got Apple to blame (and game console manufacturers, but I don't think anyone expected them to cooperate).
cogman10 · 18m ago
> you've basically got Apple to blame
Yeah, that's the thing that really irks me. WebGPU could have been just a light wrapper over Vulkan like WebGL is (or was, it's complicated now) for OpenGL. But apple has been on a dumb war with Khronos for the last decade which has made everything more difficult.
So now we have n+1 low level standards for GPU programming not because we needed them, but because 1 major player is obstinate.
m-schuetz · 11m ago
I agree. I'll keep using OpenGL with CUDA interop until something better shows up. Vulkan isn't it. I tried Vulkan to get away from OpenGL, but ended up with CUDA instead since it's so much nicer to work with. Vulkan has way too much overengineered complexity with zero benefit.
on_the_train · 5m ago
OpenGL is still such a powerful technology. I use it all the time because Vulkan is just so much more difficult to use. It's a pity, so much good software not being built because ogl is more or less a dead man walking
dist-epoch · 51m ago
Modern graphics APIs are the graphical equivalent to assembly language - you are not supposed to use them directly, but through another higher level layer, like a programming language or a graphics engine.
They are a specialized API intended for tool writers.
naikrovek · 1h ago
Yeah, it’s kind of insane how things have gotten.
There are no adults, no leaders with an eye on things leading us away from further mistakes, and we keep going deeper.
coffeeaddict1 · 4h 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.
m-schuetz · 16m 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.
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.
crthpl · 4h ago
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.
pjmlp · 3h ago
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.
mandarax8 · 24m ago
Can you point me to some good middleware then? I haven't been able to find any.
pjmlp · 6m ago
GDC Vault programming track has plenty of examples.
coffeeaddict1 · 2h ago
None of those middlewares have a spec and none of them offer the compatibility guarantees that WebGPU provides.
mmis1000 · 1h ago
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.
pjmlp · 2h ago
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.
grovesNL · 2h ago
wgpu can run the WebGPU Conformance Test Suite for validation against the WebGPU specification. Was there something else you'd like to see?
le-mark · 2h ago
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.
_bent · 2h ago
they just have to implement Vulkan, enough for it to run Dawn or wgpu
pjmlp · 1h ago
See Android for how much fun it is to debug OpenGL ES and Vulkan issues.
pjmlp · 1h ago
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.
JasperBekkers · 5h ago
Very happy to see this as it means that our gpu-allocator [0] crate (used currently by wgpu's dx12 backend, but capable of supporting vulkan & metal as well) will see a significant wider audience then what we've been using it for so far (which is shipping our gpu benchmark suite: evolve [1]
It runs the SmolLM2 model compiled to WebAssembly for structured data extraction. I previously thought that demo only worked in Chrome.
(If I try it in regular Firefox for Mac I get "Error: WebGPU is not supported in your current environment, but it is necessary to run the WebLLM engine.")
erichdongubler · 1h ago
Member of Firefox's WebGPU team here. This is expected. Stable support for macOS is something we hope to ship soon!
bobajeff · 3h ago
>we plan to ship WebGPU on Mac and Linux in the coming months, and finally on Android
Sounds good. I'm not really thrilled about it as of now. What ever the reason, it's not been supported in Linux for any browsers as of yet. My guess is it's too hard to expose without creating terrible attack surfaces.
This seems to support my view that web standards are too overgrown for how users actually use the web. It's obviously too late to do anything about it now but all the issues of monoculture and funding we are worried about today stem from the complexity of making a web browser due to decisions tracing all the way back to the days of Netscape.
pjmlp · 3h ago
Depends on which Linux, it is supported on Android/Linux, WebOS/Linux and ChromeOS/Linux.
However it kind of proves the point on how relevant browser vendors see GNU/Linux for this kind of workloads.
modeless · 1h ago
Seems like Firefox will ship WebGPU on Linux before Chrome does, then.
politelemon · 7h ago
Thanks, looking forward to the Linux implementation as well. Are there any webgpu demos worth trying when this is released?
Most of the sites I’ve seen are indeed just demos. I especially like Compute Toys [0], a Shadertoy clone for WebGPU. [1] is probably the best place to find demos. I have a site myself in which I experiment mainly with WebGPU Compute Shaders [2].
I was feeling a bit dirty playing around with WebGPU with only Chrome into the game thus far, even Safari has enabled their preview quite recently.
joelthelion · 4h ago
What are the use cases for this? Are we sure sites are not just going to use it to mine bitcoins using their users' hardware?
m-schuetz · 1m ago
- Streaming point cloud data setsnover web browsers (used by many surveying and construction companies, as well as geospatial government agencies).
- Visualize other scan data such as gaussian splat data sets, or triangle meshes from photogrammetry
- Things like google earth, Cesium, or other 3D globe viewers.
It's a pretty big thing in geospatial sciences and industry.
andybak · 2h ago
Same use cases that native apps have for using a GPU except in a browser?
> Are we sure sites are not just going to use it to mine bitcoins using their users' hardware?
Some almost certainly will but like all similar issues the game of cat and mouse will continue.
popcar2 · 4h ago
It'll open the door for more ambitious webgames and web apps that use the GPU.
pjmlp · 3h ago
I keep waiting to see ambitious webgames that could match the experience of Infinity Blade from 2010, used to demo iOS new OpenGL ES 3.0 capabilities, the foundation of WebGL 2.0.
The only thing I like in Web 3D APIs, is that outside middleware engines, they are the only mainstream 3D APIs designed with managed languages in mind, instead of after the fact bindings.
Still waiting for something like RenderDoc on the respective browser developer tools, we never got anything better than SpectorJS.
It isn't even printf debugging, rather pixel colour debugging.
grovesNL · 2h ago
Really excited to see WebGPU/wgpu ship in Firefox! Congratulations and thanks to Mozilla for supporting this.
erichdongubler · 58m ago
Thanks! Can't forget your help in the process.
Zealotux · 4h ago
Great news, congrats to the team!
pixelpoet · 6h ago
Nice one, been waiting for this! Thanks to the devs.
tux3 · 6h ago
Great news, congrats to the gfx team!
darkwater · 7h ago
Very cool! Now, let see how much will take for G-products to actually use it and not complaining about "browser not supported for this feature, use Chrome".
sroussey · 7h ago
Which google products use it?
mort96 · 6h ago
The one I can think of is Google Meet, where some GPU-thing is used to add background effects such as blur. However I'm not sure this actually uses WebGPU; it used to use on Firefox until Google added a browser check, and AFAIK, if you could fool Meet to think Firefox was Chrome, it would still work.
This might still be a semi-legitimate thing, i.e maybe they kept around a WebGL implementation for a while as a fallback but moved the main implementation to WebGPU and don't want to maintain the fallback. It certainly fits well into their strategy of making sure that the web really only works properly with Chrome.
Yeah, Meet works in Firefox, but the background effects don't.
firtoz · 6h ago
I'm on Brave Linux which requires special flag for WebGPU (not turned on for me) and can confirm that background blur still works with Meet without WebGPU
dragonelite · 4h ago
It sounds like something webgl2 should be able to handle easily.
darkwater · 5h ago
I don't know :) I was referring basically to the Meet situation back in the day with FF where the feature was there but Meet complained the browser was not capable.
chrismorgan · 5h ago
There was a genuine technical reason for that, a part of WebRTC that Firefox hadn’t implemented yet, where if even a single member of a group call lacked that feature, it had to fall back to something that used a lot more CPU for everyone. Can’t remember the details exactly, but it was approximately that.
r2vcap · 3h ago
If I remember correctly, the issue was related to newer APIs like MediaStreamTrackProcessor, offscreen surfaces, and WebRTC–WebCodecs interoperability, as well as the ability to run ML inference efficiently in the browser. At the time, Firefox hadn’t fully implemented some of these features, which impacted Google Meet’s ability to apply effects like background blur or leverage hardware-accelerated video processing.
vFunct · 3h ago
Pretty sure Apple is going to release WebGPU support in Safari in Mac OS X 26 Tahoe as well. There was a WebGPU video in one of the WWDC sessions.
nmstoker · 5h ago
Great news. Now hope they can sort it for Firefox on Android.
I think WebGPU is a decent wrapper for exposing compute and render in the browser. Not perfect by any means - I've had a few paper cuts working with the API so far - but a lot more discoverable and intuitive than I ever found WebGL and OpenGL.
Technically true, but practically tone deaf.
WebGPU is both years too late, and just a bit early. Wheras WebGL was OpenGL circa 2005, WebGPU is native graphics circa 2015. It shouldn't need to be said that the bleeding edge new standard for web graphics shouldn't be both 10 years out of date and awful.
Vendors are finally starting to deprecate the old binding model as the byzantine machinery that it is. Bindless resources are an absolute necessity for the modern style of rendering with nanite and raytracing.
Rust's WGPU on native supports some of this, but WebGPU itself doesn't.
It's only intuitive if you don't realize just how huge the gap is between dispatching a vertex shader to render some triangles, and actually producing a lit, shaded and occlusioned image with PBR, indirect lighting, antialiasing and postfx. Would you like to render high quality lines or points? Sorry, it's not been a priority to make that simple. Better go study up on SDFs and beziers.
Which, tbh, is the impression I get from webgpu efforts. Everyone forgets the drivers have been playing pretend for decades, and very few have actually done the homework. Of those that have, most are too enamored with being a l33t gfx coder to realize how terrible the dev exp is.
As for true portability of those low-level APIs, you've basically got Apple to blame (and game console manufacturers, but I don't think anyone expected them to cooperate).
Yeah, that's the thing that really irks me. WebGPU could have been just a light wrapper over Vulkan like WebGL is (or was, it's complicated now) for OpenGL. But apple has been on a dumb war with Khronos for the last decade which has made everything more difficult.
So now we have n+1 low level standards for GPU programming not because we needed them, but because 1 major player is obstinate.
They are a specialized API intended for tool writers.
There are no adults, no leaders with an eye on things leading us away from further mistakes, and we keep going deeper.
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.
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.
[0]: https://github.com/Traverse-Research/gpu-allocator/
[1]: https://www.evolvebenchmark.com/
I just installed the Mac nightly from https://www.mozilla.org/en-US/firefox/channel/desktop/ and now this demo works: https://huggingface.co/spaces/reach-vb/github-issue-generato...
It runs the SmolLM2 model compiled to WebAssembly for structured data extraction. I previously thought that demo only worked in Chrome.
(If I try it in regular Firefox for Mac I get "Error: WebGPU is not supported in your current environment, but it is necessary to run the WebLLM engine.")
Sounds good. I'm not really thrilled about it as of now. What ever the reason, it's not been supported in Linux for any browsers as of yet. My guess is it's too hard to expose without creating terrible attack surfaces.
This seems to support my view that web standards are too overgrown for how users actually use the web. It's obviously too late to do anything about it now but all the issues of monoculture and funding we are worried about today stem from the complexity of making a web browser due to decisions tracing all the way back to the days of Netscape.
However it kind of proves the point on how relevant browser vendors see GNU/Linux for this kind of workloads.
1. https://boat-demo.cds.unity3d.com/
2. https://www.keijiro.tokyo/WebGPU-Test/
3. https://www.chatlord.com/4/
Gaussian splatting training and rendering using webgpu
[0] https://compute.toys/
[1] https://github.com/mikbry/awesome-webgpu
[2] https://github.com/s-macke/WebGPU-Lab
It also works without WebGPU, just very slowly.
https://vester.si/motion/
I was feeling a bit dirty playing around with WebGPU with only Chrome into the game thus far, even Safari has enabled their preview quite recently.
- Visualize other scan data such as gaussian splat data sets, or triangle meshes from photogrammetry
- Things like google earth, Cesium, or other 3D globe viewers.
It's a pretty big thing in geospatial sciences and industry.
> Are we sure sites are not just going to use it to mine bitcoins using their users' hardware?
Some almost certainly will but like all similar issues the game of cat and mouse will continue.
https://en.wikipedia.org/wiki/Infinity_Blade
Game demo, https://www.youtube.com/watch?v=_w2CXudqc6c
The only thing I like in Web 3D APIs, is that outside middleware engines, they are the only mainstream 3D APIs designed with managed languages in mind, instead of after the fact bindings.
Still waiting for something like RenderDoc on the respective browser developer tools, we never got anything better than SpectorJS.
It isn't even printf debugging, rather pixel colour debugging.
This might still be a semi-legitimate thing, i.e maybe they kept around a WebGL implementation for a while as a fallback but moved the main implementation to WebGPU and don't want to maintain the fallback. It certainly fits well into their strategy of making sure that the web really only works properly with Chrome.