Especially frustrating in the case of Safari, which only needs to support one native API backend (Metal) on a pretty narrow set of hardware and drivers. Firefox has a much bigger task with needing to support everything, like Chrome, but with far less resources than Google or Apple can afford to throw at it.

Its in technology preview, so likely to go GA at the next major OS cycle (1yish)

I'm not holding my breath, their WebGL2 support entered preview in early 2017 but didn't actually ship until late 2021...

And last I heard still has show-stopping performance bugs affecting eg Unity web target.

For Safari that's par for the course, but Firefox is in surprisingly far behind in terms of anything GPU related in the browser.

I've recently been shocked trying out the WebGL aquarium demo [0] on Chrome and Firefox after running into some really odd performance issues on a project. You'd expect them to behave about the same with GPU acceleration, but FF barely gets half the framerate at the same load. Like, what?! On Linux FF is also several times slower at canvas rendering.

[0] https://webglsamples.org/aquarium/aquarium.html

I‘m not an expert but I think it works on IOS with Safari. You have to enable WebGPU in the extra flag category in the settings app.

But I still need to figure out what exactly this is.

Can confirm, I have it enabled on iOS 18.1 and this seems to work fine.

Agreed! Though support should be coming soon it seems. As a complete WebGPU novice I was really impressed with how quick it was to get going.

WebGL 2 took almost 5 years to come to Safari after Chrome. It will not take as long for WebGPU; development is active now.

It is also a bit frustrating that Chrome has not enabled WebGPU on all platforms by default yet.

Even Chrome only supports it officially on Windows, macOS and Android, no GNU/Linux (as stable).

And when it becomes widespread, just like WebGL 2.0, it will be a decade behind of what native APIs are capable of.

And in both cases, good luck debugging, other than replicating the content on native APIs, as means to use proper GPU debuggers, because even Chrome has yet to offer any developer tooling for GPU debugging.

Runs great on my ChromeBook.

ChromeOS is not a Linux distribution, change my mind.

ChromeOS is a Linux kernel with some software bundled on top to make a usable system; it is by definition a Linux distro. Curiously, it's even a GNU/Linux distro, as it uses glibc and GNU coreutils, unlike ex Android which is a non-GNU distro.

I will grant that it's a slightly odd distro, but is it any weirder than NixOS or Fedora Silverblue?

Only runs browser instances. Even Crostini is sandoxed in a way similar to WSL2.

User-facing apps are browser instances and VMs, and under that is a pretty normal userland. It's still a distribution of software on a Linux kernel. And for that matter, is Silverblue any less a Linux distro with its read-only root and apps in flatpak/distrobox? Are Qubes OS or Proxmox with everything in VMs?

People buying a Chromebook down at the mall will never see GNU userland.

Folks using Silverblue and Flatpak distributions get to use GNU userland.

No luck on Steam Deck :(

Forgot about that, which isn't GNU/Linux anyway.

By what metric? It's a gentoo deriviative with glibc, coreutils, etc.

A JavaScript userspace juggling Chrome instances.

...no, it isn't?

Even if you're claiming (incorrectly) that the window manager, etc. contain javascript, the same would apply to GNOME!

GNOME allows GNU userland to be used.

it's still not well supported on Linux unfortunately either

Why do you need webgpu? It's unfortunate that people use technology that is "state-of-the-art techniques to run simulations at interactive speeds" without fully understanding what it's for. General compute on GPU is what webgpu is for.. To simulate basic waves like in this demo you absolutely do not need that, in fact it's an indication the author implemented the solution in a non-optimal way. WebGL is fully supported by all browsers fully supported by well-maintained libs like 3js, yet here we are people writing a sin function with basic interference patterns, one of the most elementary 3D primitives, in webgpu and argue that's using the "state-of-the-art" techniques.

Good question! This is actually a numerical solver for a few coupled partial differential equations - the method in this context (electromagnetism) is called FDTD. It's implemented as a WebGPU compute shader.

You absolutely could do this using WebGL2 compute shaders too, but I thought it would be fun to try this newer API.

Annoyingly WebGL2 doesn't have compute shaders even though GLES3.x that it is based on does.

Thank Google for that, as they dropped Intel contribution to WebGL Compute, with the reasoning WebGPU would be good enough.

That's no solver, it just displays a sine wave pattern.

Did ChatGPT write that for you because it has missed the mark by 500 metres.

The point was that the implementation of this tool is not a sin+cos function. It's more like

  let newEz = Ez0[me] +  calcEzDiff(vec2u(id.x, id.y), dx, dy, aspect);

  let newEzAbove = Ez0[above] +  calcEzDiff(vec2u(id.x, id.y + 1), dx, dy, aspect);
  let newEzRight = Ez0[right] +  calcEzDiff(vec2u(id.x + 1, id.y), dx, dy, aspect);

  Hx1[me] = Hx0[me] - (uniforms.dt/mu0)*(newEzAbove - newEz) / dy;
  Hy1[me] = Hy0[me] + (uniforms.dt/mu0)*(newEzRight - newEz) / dx;

  Ez1[me] = newEz;

  let localDelta = delta[me];
  let fac = 1 + uniforms.omega * uniforms.dt * (delta[me] / eps[me] / 2);
  Ez1[me] = Ez1[me] / fac;
  Hx1[me] = Hx1[me] / fac;
  Hy1[me] = Hy1[me] / fac;

and then a bunch of other GPU code. You can find this with little effort from the bundle, if you care, by base64-decoding the Pt("xxx") parts.

Though I do imagine it indeed could be implementable with WebGL shaders, but I also wouldn't start a new compute-based on it, unless I had a particular need to support older systems. And this I say as a Firefox user..