https://www.khronos.org/registry/webgl/specs/latest/2.0-comp...
https://www.khronos.org/assets/uploads/developers/presentati...
https://bugs.chromium.org/p/chromium/issues/detail?id=113199...
> macOS' OpenGL implementation never supported compute shaders
which is a pretty valid reason to drop it. Nothing to do with Chrome. Further, OpenGL is dead, every graphics developer knows this. All the browser vendors are working on WebGPU. No reason to waste time on implementing outdating things. There are finite resources. No other browser vendor named any plans to support webgl-compute. So stop with the ridiculous spin
Nothing on the standard requires OpenGL backend, only that the semantics are preserved, GL ES, Metal and DirectX 11 all have compute shaders support.
OpenGL is not dead until Khronos comes up with an API that is actually usable without an EE degree on GPU design and shader compilers.
WebGPU is years away to become usable, even if it happens to be released during 2022, it will be a 1.0 MVP, years behind of what Metal, Vulkan, DX 12, NVN and LibGNM are capable of in 2021.
> In order to reclaim code space in Chromium's installer that is needed by WebGPU, the webgl2-compute context must be removed.
I bet the Chrome team wouldn't bother with code space installer for other Google critical features that are part of Project Fugu.
As a counterpoint, I've been using WebGPU (through wgpu-rs) for the past 1.5 years. It's been a pleasure to use. For instance, here's the CPU-side code for a glow post-process shader using 4 render passes https://github.com/JMS55/sandbox/blob/master/src/glow_post_p....
A plugin framework for 3D APIs is probably the easiest part to implement on a game engine, specially when API like OpenGL and Vulkan already require implementing one due to extension spaghetti.
It would be even further away if all the devs working on it were instead spending years on WebGL-Compute. It's not like you snap your fingers and it works. It takes years of cross platform work and testing. That time is better spent moving forward.
As further proof, the only names on the compute spec are Intel and one Google name. Compare to the WebGPU spec which clearly has buy in from all the browsers.
So if Chrome had shipped it you'd have the gallery of comments bitching about Chrome going too fast, implementing too many things no other browser plans to implement.
BTW: WebGL2 in Safari does not run on Metal (yet)
Why would this ever happen? It seems like there is nothing in the works, nothing on the horizon, and no demand for a higher-level, less-performant API to become a new standard. Even OpenGL itself has been getting lower level and more detailed ever since version 1. People can build/use a wrapper API or game engine or something else if they want easy. It seems weird to say this right after defending Apple’s use of Metal to implement WebGL. Apple’s moves to get rid of OpenGL from the Mac ecosystem are one of the strongest forces pushing OpenGL out.
Regarding Metal, indeed those that leave OpenGL are more likely to move into middleware than forcing Vulkan upon themselves.
Hence why Khronos started ANARI, as most visualisation products and CAD/CAM people couldn't care less that Vulkan on its present state exists.
In many other benchmarks, it loses. That being said, it still manages decent performance, which is extremely impressive for a one man project using only the Vulkan interface. It wouldn't surprise me if it eventually becomes the default OpenGL driver in the open source driver stack (for HW capable enough to support a Vulkan driver, obviously).
As for using middleware, GPU's are vastly more capable and complicated today than 30y ago when OpenGL 1 appeared. In most cases it makes sense to use a higher level interface, specialized for the particular type of application you're writing, be it ANARI, a game engine, some scenegraph library, or whatever.
FWIW as someone who exclusively uses OpenGL for 3D graphics, this actually makes me push Apple out :-P
WebGL on Linux requires the OpenGL backend until eventually Vulkan is supported well enough.
Apple's WebGL2-on-Metal approach involves the same translator engine I work on, and was very much a collaborative effort between Google, Apple, and external contributors. Chrome will adopt this in the future after integration work is finished.
I can confirm that browser GPU programmers are definitely spread pretty thin just ensuring compatibility and reliability across all platforms
No wonder the focus on making streaming work for 3D rendering with current APIs on modern hardware.
That isn't going to happen because everyone is, in fact, moving away from the idea of a "graphics API" altogether and simply allowing the compute systems to calculate everything.
See: the Nanite renderer from EPIC: https://www.youtube.com/watch?v=eviSykqSUUw
To a first and second order approximation, no one cares about graphics that aren't related to games.
Also, none of specific reasons people opposed Microsoft’s policies with IE, like it’s attempts to lock people into windows-only APIs (ActiveX etc) apply today.
In this case, google can pull off something like OP says because it's dominating the market.
> Also, none of specific reasons people opposed Microsoft’s policies with IE, like it’s attempts to lock people into windows-only APIs (ActiveX etc) apply today.
Chrome implements plenty of chrome only API. They like a standard (or propose one), they implement it, use it on their projects like google doc, and let the competition deal with the mess.
This is nothing like the situation was with IE6. Back then basic functionality was half-broken and it was hard to get anything done without a pile of hacks.
Causes are not 1 to 1, but consequences are the same: monopoly leads to abuse, abuse lead to some site not working with Firefox, consommers needs being ignored by google and them abusing their dominant position to pass what they want as standard, or just destroy API they don't like (see the latest adblock scandal).
OP is suggesting that Chrome should have spearheaded a spec that no one but Intel and Google ever showed any interest in. How would that not have been literally "they like a standard (or propose one), they implement it, use it on their projects like google doc, and let the competition deal with the mess"[1]?
Instead they're implementing a spec with broad involvement and support across browsers, it's just taking longer. Seems like exactly how we'd want things to go.
Yes. Exactly what they've been doing with plenty of other "standards"
edit: GLES3.2 => GLES 3.1
WebGPU is still on the horizon during the next couple of years.
Now, years later, Apple actually implemented WebGL on Metal, so today we could think about implementing WebGL compute on Mac. However WebGPU is now in origin trials. It's very unlikely that Apple would put any effort into a compute shader implementation for WebGL now. And Chrome is not going to go implement a major WebGL feature that has no prospect of ever being supported in Safari.
But for WebGL it matters what Apple does?