Particle Life simulation in browser using WebGPU(lisyarus.github.io)
lisyarus.github.io
Particle Life simulation in browser using WebGPU
https://lisyarus.github.io/blog/posts/particle-life-simulation-in-browser-using-webgpu.html
69 comments
> What's the situation of WebGPU, is it supposed to work in Linux or not?
Chrome officially supports WebGPU on all platforms except Linux for now, you can force it on with a flag but it's obviously not meant for prime time yet. Firefox has yet to officially ship WebGPU at all but it's supposed to be coming in version 141, due at the end of July. Safari is still dragging its feet with no indication at all of when they'll get around to shipping.
Chrome officially supports WebGPU on all platforms except Linux for now, you can force it on with a flag but it's obviously not meant for prime time yet. Firefox has yet to officially ship WebGPU at all but it's supposed to be coming in version 141, due at the end of July. Safari is still dragging its feet with no indication at all of when they'll get around to shipping.
I see, I thought 3D graphics in browsers already existed and worked in Linux for a very long time so this must be a new one then... what's the difference between WebGPU, and WebGL that allowed demos like this one since long ago? https://madebyevan.com/webgl-water/
Is there some reason WebGPU has difficulties getting implemented for Linux, like DRM features or so?
Is there some reason WebGPU has difficulties getting implemented for Linux, like DRM features or so?
> what's the difference between WebGPU, and WebGL
WebGL has a bunch of limitations, but a big one is that you can only use the gpu to move around triangles vertices (vertex shader) and color them in (pixel shader).
If you want to do something like that cool water simulation you have to do some painful hackery to pretend all your data is actually vertices or colors in a texture. Even with hackery, there's still lots of things you simply can't do.
WebGPU supports compute shaders which let you read and write whatever data you want.
WebGL has a bunch of limitations, but a big one is that you can only use the gpu to move around triangles vertices (vertex shader) and color them in (pixel shader).
If you want to do something like that cool water simulation you have to do some painful hackery to pretend all your data is actually vertices or colors in a texture. Even with hackery, there's still lots of things you simply can't do.
WebGPU supports compute shaders which let you read and write whatever data you want.
Most likely minor behaviour differences or bugs in specific Linux Vulkan drivers or driver versions and the Chrome WebGPU team first wanting to get other platforms in shape. Chrome for Android has WebGPU enabled and that also runs on top of Vulkan, but I guess Google has more control over driver quality in the Android ecosystem than on Linux.
Different API, WebGPU is supposed to be a safe common denominator for Vulkan, DirectX 12 and Metal.
WebGL is that, but for OpenGL ES 2.0, and WebGL 2 is that but for OpenGL ES 3.0. WebGL is OK for graphics, but pretty hard to effectively adapt for compute / simulations.
WebGL is that, but for OpenGL ES 2.0, and WebGL 2 is that but for OpenGL ES 3.0. WebGL is OK for graphics, but pretty hard to effectively adapt for compute / simulations.
If I had to guess, the reason WebGPU is not implemented in Linux is because nobody is paid to add features to Linux. This means that new features are delayed by several years. WebGL is old, and well supported. WebGPU is newer, and has less support.
Google cares about Chrome Linux support and pays people to work on it, for two reasons. One is Chrome OS, and the other is that most Google engineers use Linux desktops for work.
that's a pretty WebGL fluid demo, it runs even well on iPhone.
Huh, disappointing that it hasn't shipped in Chrome on Linux. There's no pressure for other browsers to implement it when it's not even on all of Chrome's supported platforms yet.
[deleted]
Are you using Chrome, or Chromium?
Chromium is typically the bundled browser, but around 2019 Google restricted certain aspects of Chromium under Linux, and in order to continue using things like browser login under Ubuntu, I needed to install Chrome instead.
Hardware acceleration perks seem like another feature that may have a Chrome/Chromium divide.
Chromium is typically the bundled browser, but around 2019 Google restricted certain aspects of Chromium under Linux, and in order to continue using things like browser login under Ubuntu, I needed to install Chrome instead.
Hardware acceleration perks seem like another feature that may have a Chrome/Chromium divide.
I did something similar a few years back(press 'q' to see the individual particles move): https://lorentz.app/experiments.html
It's much simpler in design though. Each particle has a constant forward speed, and varying move-angle. For each step, it can either change it's turn-angle to be more left, or more right. The turn angle then determines how strong the 'glow' of a particle is. If it turns strongly to the left, the glow is strongly red. Vise versa for blue and right.
Then, for the upcoming iteration, the underlying point of the particle is evaluated by colour. If the colour the particle is under is red -> become more red. If it's blue -> become more blue. So this way, it's a dynamically shifting system where particles turn from blue to red depending on it's surroundings.
All calculations are made on the GPU. The positions are encoded into textures (last 3 positions to calculate current moving angle), then also the previous step's render.
Often particles becomes very isolated due to it's high turn, there are clusters. But then a huge pack of opposite-turners may come and disrupt this. Sometimes one colour wins.
It's much simpler in design though. Each particle has a constant forward speed, and varying move-angle. For each step, it can either change it's turn-angle to be more left, or more right. The turn angle then determines how strong the 'glow' of a particle is. If it turns strongly to the left, the glow is strongly red. Vise versa for blue and right.
Then, for the upcoming iteration, the underlying point of the particle is evaluated by colour. If the colour the particle is under is red -> become more red. If it's blue -> become more blue. So this way, it's a dynamically shifting system where particles turn from blue to red depending on it's surroundings.
All calculations are made on the GPU. The positions are encoded into textures (last 3 positions to calculate current moving angle), then also the previous step's render.
Often particles becomes very isolated due to it's high turn, there are clusters. But then a huge pack of opposite-turners may come and disrupt this. Sometimes one colour wins.
I never knew WebGL or OpenGL, my first experience was learning WebGPU, because I planned to use it for the drawing of 90s.dev which is meant to be future-first. But WebGPU is just not there yet. And from what I read about it, it looks like it has only slightly better performance than WebGL2, being the common denominator to all post-2015 native GPU frameworks. So it's disproportionately harder to write, doesn't have nearly all the same features as native would, and all this to be only slightly faster. Which is why I switched to WebGL2 as the graphics backend (WIP). Now I have to learn how all the GL state functions work (ugh), I admit that was easier to reason about in WebGPU, mainly because it's easier to deeply digest and understand APIs when they have clear ins/outs that link together clearly and cleanly. Which GL doesn't. At all. Just a buncha confusing globals. But this helps, kinda: https://webgl2fundamentals.org/webgl/lessons/resources/webgl...
Yeah, GLs global state is awful. The least-bad way to deal with it is to build your own pipeline abstraction on top, similar to the native pipeline constructs of newer APIs like WebGPU, so most of the messy global state manipulation is centralized in your "bindPipeline" function. Then the rest of your codebase can mostly pretend it's running on a sane (albeit dated) API instead of a giant ball of spaghetti.
While WebGPU is supposed to be more efficient, the real appeal is that it supports new features like compute shaders, in a form that Apple will actually agree to implement (they refuse to implement newer versions of OpenGL due to legal disputes with Nvidia). And we care whether Apple ships it because of their monopoly on iOS browser engines. Of course, Apple hasn't actually shipped it yet either...
Shameless plug: sokol_gfx.h has an API quite similar to WebGPU and has a WebGL2 backend (most notably WebGPU-style immutable pipeline objects which on WebGL2 use a state cache to avoid redundant calls into WebGL2), I'd say that the API is even easier to use than WebGPU, but of course I'm biased ;)
https://floooh.github.io/sokol-html5/
...or with the WebGPU backend (which gives you a couple more options, like storage buffers/images and compute shaders):
https://floooh.github.io/sokol-webgpu/
...this is only an option if you're comfortable with C or Zig though (for native build targets you'd have more language options), although I keep rolling the idea around the back of my head to eventually add JS/TS to the language bindings generator.
PS: You're spot on with the performance comparison. It's baffling that WebGPU in some areas isn't any faster or even slower than WebGL2 (but tbf, D3D11 - which WebGL2 uses on Windows - is hard to beat when it comes to raw throughput - I wonder if a WebGPU D3D11 backend would beat the current D3D12 backend).
https://floooh.github.io/sokol-html5/
...or with the WebGPU backend (which gives you a couple more options, like storage buffers/images and compute shaders):
https://floooh.github.io/sokol-webgpu/
...this is only an option if you're comfortable with C or Zig though (for native build targets you'd have more language options), although I keep rolling the idea around the back of my head to eventually add JS/TS to the language bindings generator.
PS: You're spot on with the performance comparison. It's baffling that WebGPU in some areas isn't any faster or even slower than WebGL2 (but tbf, D3D11 - which WebGL2 uses on Windows - is hard to beat when it comes to raw throughput - I wonder if a WebGPU D3D11 backend would beat the current D3D12 backend).
From everywhere I've seen performance is actually worse than WebGL2. Especially on mobile devices.
It's crazy how WebGPU has been a thing for years, yet it's still barely available accross devices and browsers.
It runs worse but it being new made everyone believe and hope it would be an overall improvement and perform better. Graphics is extremely performance bound.
It runs just fine and adds important functionality that is entirely absent in WebGL (storage buffers and compute shaders). But I disagree with a lot of the design decisions that made me eventually give up on WebGPU. Like, what's the point if it's still 10 years behind current desktop capabilities, just like WebGL when it came out. And it adopted way too much of Vulkans needless complexity, some of which is not even necessary in Vulkan anymore but still in WebGPu, like render passes.
> like render passes
Render passes in WebGPU are more like in Metal and Vulkan's Dynamic Rendering extension (which is pretty much a direct copy of Metal's render pass concept). The problem with Vulkan 1.0 render pass objects is that they are baked objects, and worse, that pipeline objects required a render pass object reference (although it didn't have to be an actual render pass used for rendering, just a 'compatible' render pass - still a pretty bad design wart).
Metal-style transient render passes are actually a very good thing, especially for tiler gpus.
Render passes in WebGPU are more like in Metal and Vulkan's Dynamic Rendering extension (which is pretty much a direct copy of Metal's render pass concept). The problem with Vulkan 1.0 render pass objects is that they are baked objects, and worse, that pipeline objects required a render pass object reference (although it didn't have to be an actual render pass used for rendering, just a 'compatible' render pass - still a pretty bad design wart).
Metal-style transient render passes are actually a very good thing, especially for tiler gpus.
Storage buffers are 32bit blocks of memory so why not just use a 32bit texture as a storage buffer? With their implementation is it actually different?
You can't do random writes to textures in WebGL, which is required by the vast majority of algorithms. Some hacks exist, all of which come with severe limitations and performance penalties.
[deleted]
Treating a texture as a 'poor man's storage buffer' often works but is much more awkward than populating a storage buffer in a compute shader, and you're giving up on a lot of usage scenarios where WebGPU is simply more flexible (even simple things like populating a storage buffer in a compute shader and then binding it as vertex- or index-buffer).
But at this point I'm thinking that it would have been way better if they had just added storage buffers and compute shaders to webgl.
There was a planned compute shader update for WebGL2, but AFAIK it has been abandondend in favour of WebGPU:
https://groups.google.com/a/chromium.org/g/blink-dev/c/bPD47...
It would have made sense 5 years ago when it wasn't clear that WebGPU would be delayed for so long, but now that WebGPU support in browsers is actually close to the finish line it's probably not worth the hassle.
https://groups.google.com/a/chromium.org/g/blink-dev/c/bPD47...
It would have made sense 5 years ago when it wasn't clear that WebGPU would be delayed for so long, but now that WebGPU support in browsers is actually close to the finish line it's probably not worth the hassle.
Arsiliath on twitter/x also has some really nice gpu life simulations and courses:
https://x.com/arsiliath
X is completely unusable and it saddens me people keep posting valuable content to it.
I'm not a big fan of it, but that's quite an exaggeration. If it were "completely unusable", then people wouldn't be using it, and it wouldn't have been an issue. The fact that the situation isn't what we want it to be, but nevertheless is still tenable makes it a much harder problem to deal with.
Alright. I confess, it has parts that functionally work. You can press buttons and enter text and most of the time they respond.
I literally cannot access the “content”, usually a single sentence, without signing in.
I’m frustrated because it is being used by politics and government as well as some sort of universal comms and it’s very, very far from that.
I literally cannot access the “content”, usually a single sentence, without signing in.
I’m frustrated because it is being used by politics and government as well as some sort of universal comms and it’s very, very far from that.
It's really why enshittification can be a thing. Network effect-ed services can do random walks in quality or degrade significantly while still keeping staying power.
Enshittification, as described by C Doctorow and others is just one potential, but likely path for a popular service to take.
Enshittification, as described by C Doctorow and others is just one potential, but likely path for a popular service to take.
If we could just have a workaround to network effects that would be great.
Edit: Any suggestions for how to actually solve the network effect problem (long term)?
Edit: Any suggestions for how to actually solve the network effect problem (long term)?
I’m European, so: heavy—ass regulation. Don’t trust the market.
We don’t trust capitalism with all important bits of civilization: government, water and food quality, care, education, etc. I don’t see why it has to be let loose here.
Social media has a special place in my heart. A hateful place. If it were up to me I’d ban it outright. It’s eroding the fundaments of society while contributing nothing of value. It’s like crystal meth in that regard.
We don’t trust capitalism with all important bits of civilization: government, water and food quality, care, education, etc. I don’t see why it has to be let loose here.
Social media has a special place in my heart. A hateful place. If it were up to me I’d ban it outright. It’s eroding the fundaments of society while contributing nothing of value. It’s like crystal meth in that regard.
Nice.
The only downside, is that I can spend so much time looking at this system where something seems to emerge, but not quite ...
Try looking at this system - lots of "lifeforms" emerge with several interesting behaviours https://lisyarus.github.io/webgpu/particle-life.html?particl...
My laptop was having absolutely none of that, basically couldn't run it at all. Pretty cool idea, though.
For those on brave, you need to set the experimental WebGPU flag in here to try it: brave://flags/#enable-web-usb-on-extension-service-worker
For those on brave, you need to set the experimental WebGPU flag in here to try it: brave://flags/#enable-web-usb-on-extension-service-worker
Here's an Unreal Engine 5 WebGPU demo: https://garage.cjponyparts.com/
Gets stuck at 98% on initial load screen in Firefox, Safari and Chrome (all on MacOS).
Doesn't work on Firefox/Linux for me.
Nor Chrome(ium)/Linux.
WebGPU is experimental in Firefox all platforms, but especially on Linux. Chrome on linux should have it, but I've not gotten it to work - might be chromium, might be a flag, or something else.
Here's more info on the status of WebGPU: https://github.com/gpuweb/gpuweb/wiki/Implementation-Status
WebGPU is experimental in Firefox all platforms, but especially on Linux. Chrome on linux should have it, but I've not gotten it to work - might be chromium, might be a flag, or something else.
Here's more info on the status of WebGPU: https://github.com/gpuweb/gpuweb/wiki/Implementation-Status
Seems like we might get WebGPU support soon, maybe in FF 141 according to https://github.com/gpuweb/gpuweb/wiki/Implementation-Status
WebGPU is currently only a Chrome API available across macOS, Android and Windows.
Everywhere where Chrome runs is an experimental API.
On Firefox and Safari, who knows when they will ever get out of preview API, and in what platforms, especially on Firefox's case.
WebGL 2.0 took about a decade to reach a wide enough audience, and WebGPU isn't yet widely available since the whole effort started in 2016.
This is why most companies are either doing native or streaming for 3D content.
Everywhere where Chrome runs is an experimental API.
On Firefox and Safari, who knows when they will ever get out of preview API, and in what platforms, especially on Firefox's case.
WebGL 2.0 took about a decade to reach a wide enough audience, and WebGPU isn't yet widely available since the whole effort started in 2016.
This is why most companies are either doing native or streaming for 3D content.
Doesn't work on my Samsung Galaxy A56, in either Chrome or Samsung Internet. It's running Android 15 and Chrome 136
In theory it should, in practice, it is another example why Web 3D doesn't take off for games like Flash did.
https://developer.chrome.com/blog/new-in-webgpu-121
https://developer.chrome.com/blog/new-in-webgpu-121
It's in Safari or at least Safari Tech Preview
I know, https://github.com/gpuweb/gpuweb/wiki/Implementation-Status
Now, when will it become available so that non technical people will actually able to use it, no idea.
Now, when will it become available so that non technical people will actually able to use it, no idea.
Yeah, I forgot I turned on the flag for webgpu on my iPhone. Seeming works well, and this simulation is fun to watch!
Firefox doesn't support WebGPU in stable yet.
Chromium does support WebGPU in stable, but not on Linux.
change `dom.webgpu.enabled` in `about:config` from `false` to `true` by double-clicking on it
I was mistaken, it seems to work only in Nightly builds
This looks awesome. Is there a repo with a LICENSE from which I may bum some of this with permission?
Here's another WebGPU demo, a 3D commerce car configurator, for anyone interested:
https://garage.cjponyparts.com/
https://garage.cjponyparts.com/
Just wanted to mention huge props for including a video in your post. Most people browse the web on mobile which makes most of these web GPU demos literally unwatchable.
Really cool! We're building a marketplace for high quality webgpu games @ Wavedash. We made this little demo of unity's viking village you can see how it runs on your comp and if it uses webgl or webgpu (also optimizing load times rn sorry bout that). Press "c" to walk around
https://wasm.wavedash.gg/b75d4697-4f78-45c2-a5e1-c290f7a38a4...
https://wasm.wavedash.gg/b75d4697-4f78-45c2-a5e1-c290f7a38a4...
That's cool and all, but both WebGL and WebGPU builds of that Unity demo were already done 2 years ago by someone... so your post doesn't offer anything new or groundbreaking, sorry to say. See the links below:
Github link: https://github.com/animeshjha-unity/VikingVillageURP-2023?
WebGL demo: https://vv-webgl-2023-3-0a12.netlify.app/
WebGPU demo: https://vv-webgpu-2023-3-0a12.netlify.app/
Github link: https://github.com/animeshjha-unity/VikingVillageURP-2023?
WebGL demo: https://vv-webgl-2023-3-0a12.netlify.app/
WebGPU demo: https://vv-webgpu-2023-3-0a12.netlify.app/
made this particle playground with a matterjs
https://github.com/magical-paperclip/sics-ground
star it if possible
Include screenshots in your README, that will improve your chances of getting recognition many times.
I spent a bunch of time now tweaking the parameters.
Runs great on my m1 macbook air.
Very cool!
Runs great on my m1 macbook air.
Very cool!
this is awesome
What's the situation of WebGPU, is it supposed to work in Linux or not?
I'm sure that I've seen other GPU-like things (water simulations etc...) run in my browser before so I'm not sure what's wrong this time, or how many different GPU-like API's exist for browsers other than WebGPU (like WebGL).
I sometimes enable and/or disable "hardware acceleration" in Chrome and/or Firefox because sometimes one or sometimes the other causes video problems (sometimes having hardware acceleration on can make videos slower despite what you'd think). Is this hardware acceleration setting related to WebGPU?