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?
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.
Is there some reason WebGPU has difficulties getting implemented for Linux, like DRM features or so?
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 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.
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.
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.
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).
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.
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.
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.
Enshittification, as described by C Doctorow and others is just one potential, but likely path for a popular service to take.
Edit: Any suggestions for how to actually solve the network effect problem (long term)?
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.
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
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
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.
Now, when will it become available so that non technical people will actually able to use it, no idea.
It is called "Web" GPU after all.
https://wasm.wavedash.gg/b75d4697-4f78-45c2-a5e1-c290f7a38a4...
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/
Runs great on my m1 macbook air.
Very cool!