[Joel_Mckay]

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

[lukan]

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.

[pjmlp]

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).

[raphlinus]

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.

[pjmlp]

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.

[raphlinus]

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

[Joel_Mckay]

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

[Joel_Mckay]

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