Hacker News Reader

Comment by shmerl | Hacker News Reader

What's the story with WebGPU in Firefox? Why is it still not enabled by default?

Hey, member of the Firefox WebGPU team here. The short summary is: it's not yet ready for general consumption, but we're hoping to do so on the order of months, not years! Many things already work, and we'd encourage you to try it out on Nightly.

There is a _lot_ of work to do still to make sure we comply with the spec. in a way that's acceptable to ship in a browser. We're 90% of the way there in terms of functionality, but the last 10% of fixing up spec. changes in the last few years + being significantly more resourced-constrained (we have 3 full-time folks, Chrome has/had an order of magnitude more humans working on WebGPU) means we've got our work cut out for us.

If you're interested if your use cases work already a consumer of WebGPU in JS on Firefox, you can:

- Follow the `Platform Graphics: WebGPU` component in Bugzilla ([0]).

- CC yourself on the `webgpu-v1`[0] bug and its dependent meta bugs (which aggregate yet more work). These get updated every so often to recognize the (ahem) ever-growing list of things we have to do in Firefox.

- Try things out in Nightly, and file issues to help us prioritize things!

[0]: https://bugzilla.mozilla.org/buglist.cgi?component=Graphics%...

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=webgpu-v1

Good to know, thanks!

Cheering on the progress. As a long time user of wgpu in Vello, I'm impressed with the progress there. The advanced compute stuff has been working quite well, and it's also got some nice extensions like subgroups (so far only usable in native configurations, but I'm hopeful the extension will be standardized so it's available in browser as well).

Add proper game-pad and joystick calibration support.

The whole sandbox HID scope capture issue is a core problem that needs resolved.

Best of luck =3

I don't think that is related to WebGPU ..

If people want it to be relevant to its primary use case, than low-latency HID interface callbacks are certainly required... Otherwise you will have people fighting the mouse-in-browser scope issues, and partying like its 1993 on the keyboard.

If people don't keep the IMU/navigation interfaces close to graphics interface layer, than the project will develop difficult to debug syncing and or lag issues in the VM layer.

I could be wrong about this issue, but it was the primary reason we culled the js based game engine project. =3

I did not say your wishes are unreasonable. Just that here is not the place for them. The person you replied to works on WebGPU and is quite buisy with that ..

It is not personal feature requests, but rather a historical comparison with why VRML/X3D failed to gain popularity.

Ignoring users and project architects is hardly a new problem by any stretch of the imagination. Leave the noted key features out, and the GPU API will remain vestigial. =3

You're informing people (i.e., me and my team) that are working on implementing a spec. from a single piece of the web platform that their piece of the platform (graphics programming) is useless for a specific use case (gaming) without a very different piece of functionality being implemented on the web platform. That's valid feedback, but also difficult to act on with it's current form and audience.

I think what lukan is trying to tell you is that if you're serious about your advice being taken, you will need to find a venue in which the right people in the web ecosystem can engage with it. Neither me nor my team are the right audience for that, unfortunately. I suggest you file an issue on Bugzilla, if you want to start there! I'm happy to assist in making that happen, if you want.

If you do actually follow up with the above, I think you need to answer first: What APIs already exist on the web platform, and why are they not sufficient? For example, the Gamepad API exists; were you aware of it before, and do you think it fulfills the stated use case? Why or why not?

I will also push back on these statements:

> If people want it to be relevant to its primary use case, than low-latency HID interface callbacks are certainly required...

> Leave the noted key features out, and the GPU API will remain vestigial. =3

...because it appears to ignore valid use cases that exist outside of gaming. My team doesn't just serve the gaming use case (though we sure hope it will), and calling the API we're working on "vestigial [without supporting gaming]" is disrespectful to both people who need those other use cases filled _and_ people like me who are trying to make them possible. It also implies a responsibility for the platform as a whole that we can't possibly shoulder ourselves; the amount of expertise required to make a platform across all major OSes for just _one_ of these web platform APIs can be huge, and WebGPU is, indeed, very large.

If the intended primary use-case is Google Maps specific, than they should not require your team to be volunteering their time (should be sponsoring the project at minimum.) The fact remains that simply click-capturing the mouse interface is an insufficient way to handle the GUI in most Browsers, and for most general users (CAD/Games/VR etc.)

Your team needs to consider _why_ the history of VRML browser standards ended up fragmenting, becoming overly niche, or simply being replaced with something proprietary.

I am unaware how perceived disrespect is derived from facts. If you choose to be upset, than that is something no one except yourself can control.

Certainly APIs can grow in complexity with time, but this is often a result of unconstrained use-case permutation issues or the Second-system effect.

Have a great day, and certainly feel free to reach out if you have any questions, observations, or insights. =3

You can run LLMs via WebGPU today, among many other things. If you call this useless, you probably mean, this is useless to your use case and this is right.

In theory, this should have been possible long ago with WebGL Compute, had Google not given up on it, and removed it from Chrome, quoting WebGPU as the future, and the OpenGL execuse on Apple platforms (excuse, because they ended up switching to Metal for WebGL anyway, and use DirectX on Windows).

WebGL compute was not viable, and only existed as an engineering prototype with lots of rough edges. There were a bunch of hard problems that needed to get solved to ship WebGPU. Perhaps in an alternate universe, that work could have been done in the context of WebGL, but it didn't.

I'll give one example (as it's one I was personally invested in). Doing a barrier in non-uniform control flow is wildly unsafe undefined behavior (I've had it reboot my computer, and it's easy to believe it could be exploited by malicious actors). To make these barriers safe WebGPU does a "uniformity analysis." However, that in turn required adding uniform broadcast intrinsic to the shader language, otherwise a class of algorithms would be impossible to express.

As I say, it's plausible this kind of work could have been done as extensions to WebGL, but I think the end result would have been a lot less compelling than what we have now.

The fact was that Intel did the work, and it was about to ship on Chrome, and as interesting as your explanation is, it wasn't the official reason for the Chrome team to drop support for WebGL 2.0 Compute.

Rather WebGPU and Apple's OpenGL lack of support for compute shaders.

Which became irrelevant the moment Chrome decided to move WebGL on top of Metal via Angle, just like it does with DirectX on Windows.

The official deprecation [1] cites "some technical barriers, including ... [macOS support]". I'm not able to speak for Chrome, but my understanding is that these technical barriers included serious challenges in making it safe. That's where a significant amount of engineering went into WebGPU from the beginning.

[1]: https://issues.chromium.org/issues/40150444

The reality is device specific render output signatures are already demonstrably unique.

So it is likely impossible to make these GPU APIs anonymous, and thus can never really be considered "secure".

Have a nice day, =3

LLM are still considered niche to most, but thank you for confirming my point about ignoring what users say. =)

The use cases we initially thought were worth testing out:

https://doc.babylonjs.com/features/featuresDeepDive/webXR

https://doc.babylonjs.com/features/featuresDeepDive/physics/...

https://doc.babylonjs.com/features/featuresDeepDive/mesh/gau...

The goofy game pad use case, and the user level experience: https://doc.babylonjs.com/features/featuresDeepDive/input/ga...

In the end, I culled that project due to simpler inexpensive engine options.

Have a great day, and good luck =3

It is related to 3D Web being meaningful for anything besides shadertoy like demos, data visualization and ecommerce 360° visualizations.

Thanks for posting here! Very encouraging!

Can't wait to see WebGL / WebGL2 / WebGPU performance benchmark tables comparing all the browser and platforms when it ships everywhere.

Because they haven't finished implementing it and lots of functionality is missing. Neither has Safari ship it. Same reason. They aren't done.

We investigated this many years ago:

https://github.com/BabylonJS/Babylon.js/

1. It works just fine for basic 3D functionality, but has limited support for tricks like fog FX etc. WebGL is actually quite capable when combined with simplified physics engines, and animated mesh packing formats.

2. In a business context it fails to check all the boxes, as people are not going to invest in a platform with near zero IP protection.

3. Steam + Unreal has all the advantages, and none of the problems/overhead of a Browser. i.e. peoples game pads, spacial audio, and shader cache buffers will work properly.

WebGL is just hitting the same VRML market that failed decades ago for the same reasons. =3

WebGL powers both Google Maps and Figma. maybe you're thinking too small

as for ip protection. Which platforms do that?

https://www.models-resource.com/

Then Google Maps is still in App form because... just kidding... we both already know why. =3

confused . There is no native desktop app for google maps. And it does full 3d. maybe you meant on mobile? But you brought up Steam so clearly not mobile

Earth is WebGL now too

https://earth.google.com

Google Earth Pro download link:

https://www.google.com/earth/about/versions/

Probably a bad example, but it is not our concern if Google wants to repeat the VRML/X3D trajectory. Best of luck =3

Reply on news.ycombinator.com