Note this is not about WebGL, but about WebGPU by Apple, claiming it "generally offers better performance" than OpenGL/WebGL.

I'm not an expert in this area, but isn't it a bad idea to introduce another standard if there's already WebGL with great cross-browser and -platform support? It reminds me of what people have been raging about towards Microsoft for years...

Apple's WebGPU is just one of 3 proposals (from Mozilla, Google and Apple) of what the WebGL successor will look like. WebGPU is (more or less) a mapping of the Metal 3D API to the web, but the final standard API will have to be a common subset of Vulkan, D3D12 and Metal with a common shading language.

The WebGL programming model has a lot of shortcoming from a modern point of view, see here: http://floooh.github.io/2016/08/13/webgl-next.html (you can mostly ignore my criticism of adopting Vulkan for the web, the Mozilla proposal (called Obsidian) is pretty close to Vulkan, and doesn't look as bad as I feared when I wrote that blog post).

> a common subset of Vulkan, D3D12 and Metal with a common shading language.

So, Vulkan? This is literally what Vulkan exists for, and does – a shading language and API implemented by all vendors.

In a perfect world yes, but Apple doesn't support Vulkan and probably never will. Microsoft doesn't support Vulkan in UWP apps either.

Vulkan being a universal 3D API is a myth - it only exists on Windows (as a second class citizen), Linux, Android, and the Nintendo Switch.

And on Switch, Nintendo also has their own API, in a similar vein to Sony when they toyed with OpenGL ES 1.0 support.

Well, then Apple users will just see what a Firefox user sees today when they visit Google Earth: Your Browser is not supported.

This isn’t an issue – there’s more people using Firefox, or even more unusual browsers, which can’t use half the web, than there are people using Apple devices.

> [...] there’s more people using Firefox, or even more unusual browsers, which can’t use half the web, than there are people using Apple devices.

Highly unlikely.

In Germany, Apple has a sub-16% mobile marketshare, and even less on desktop. Firefox has 43% marketshare.

Google frequently releases major products without Firefox support, with this only being added months or years later.

This is reality today.

Germany != the World.

Besides, market share of iOS in Germany is ~32% [1], and Firefox ~17% [2], according to stat counter.

And even those numbers are lower/higher(respectively) than those of countries like USA, UK, Australia, Japan etc...

[1] http://gs.statcounter.com/os-market-share/mobile/germany

[2] http://gs.statcounter.com/browser-market-share/all/germany

Congratulations, you counted mobile usage, not desktop usage.

I mentioned a 43% desktop ussge for Firefox.

Vulkan is only available on Win32, Linux and Android though. The reality is that there is no standard low-level 3D-API. I don't see this as a problem though, the complexity of Vulkan shows that it is very hard to create a one-size-fits-all 3D API, competition is good and Metal shows that it is possible to create a balanced 3D-API which combines modern features with ease of use.

Regarding Windows, Vulkan is only available on the desktop.

UWP only allows for DirectX.

And it is an optional 3D API on Android, starting with version 7.0. Which makes it pretty useless when targeting the majority of Android market, given the whole upgrade story.

This is solvable, to an extend, on the user side via a software layer ([1]).

[1] https://www.khronos.org/blog/khronos-announces-the-vulkan-po...

Yeah, but I read somewhere that Apple dislikes Vulkan and will never support it on their platforms. After all, they have a competing API, Metal

Edit: Source: Hacker News comment a while ago by a person who talked to the team at WWDC

https://hn.algolia.com/?query=metal%20wwdc&sort=byDate&type=... -> https://news.ycombinator.com/item?id=15734680

>acoye: I see a couple of issues with the Mac / TF OpenCL situation. Apple is pushing metal and performance shaders, I would not bet on strong support from them keeping up to date drivers with performant ocl. I asked at wwdc17 about vulkan and they clearly do not want it on their platform.

Unfortunately for Apple, there's even more people outside of Apple who just wish Metal would die.

I have never heard anyone who has used Vulkan actually advocate for it. But I have heard a lot of good things from Graphics Developers on Metal.

This isn't to say Vulkan is bad, everyone seems to be saying "In Vulkan, You really needs to know what you are doing".

Metal the API has some elegance in it, but the target range of hardware is controllable and way more limited than what Vulkan was designed for. Apple can choose what graphics goes into their Macs and iPhones, collaborate with the mobile GPU provider, etc.

Only on HN.

All major graphics middleware and image manipulation applications, are already Metal aware.

It's being introduced for the same reason it was on desktop, increased performance, more GPU features, avoidance of poor driver implementation, and more optimal usage of the underlying hardware.

See https://gpuweb.github.io/admin/cg-charter.html

This is like the web variant of Vulcan/Metal/etc, isn't it? Lower level API than GL.

If it maps closely enough to Vulkan, it's good (and it seems it will be the case according to the other comment). It's not the only competing successor of WebGL.

Apple's prototype is basically WebMetal, and the question about how well it maps to Vulkan is still open. Like, surely, there are hoops you've got to solve (w.r.t memory types, pipeline barriers, etc), but it's not clear how much actual real-world performance is going to be lost on this emulation.

Same goes to the other direction (mapping from Obsidian/WebVulkan to Metal), with a caveat that Vulkan requires more state to be communicated, so it's easier to ignore some of the user input (if it doesn't make sense on Metal) than to figure out the missing bits.

Is Apples WebGPU proposal still being actively developed? I haven't seen any signs of life since the initial reveal nearly a year ago, or from Mozilla's Obsidian proposal for that matter.

At least from an outsider's perspective, the only active proposal for a WebGL successor seems to be Googles NXT: https://github.com/google/nxt-standalone

Perhaps this is Mozilla's implementation?

https://github.com/kvark/webgpu-servo

At this point, since there is no consensus on the shape of the API or even the concrete feature set/programming model, we decided to focus on the low-level graphics abstraction layer ([1]) instead of pushing the WebGPU-Servo prototype further. This can change once things clear up a bit.

[1] http://github.com/gfx-rs/gfx

No, Mozilla's is Obsidian: https://github.com/KhronosGroup/WebGLNext-Proposals/tree/mas...

Obsidian ultimately became WebGPU in servo (the op's link) –https://github.com/KhronosGroup/WebGLNext-Proposals/pull/11#...

Would rather see something like WebCL back in development for general purpose GPU computation, most importantly deep learning, on the web, then the Xth attempt on superseeding WebGL. Funneling things through WebGL just doesn't feel right, where proper OES_texture_float support is also not guaranteed.

https://www.khronos.org/webcl/

Apparently WebCL was blocked by Apple who refused to let their OpenCL patents be used: https://www.khronos.org/files/ip-disclosures/webcl/Apple-Web... ("Apple does not agree to make available .. for any WebCL Specifications")

WebGPU will almost certainly include support for general purpose compute shaders, which pretty much removes the need for a dedicated compute API:

https://docs.google.com/presentation/d/1l1rTCtKHowIEhwzA4l1u...

(besides, building a new API on top of OpenCL would be questionable given that OpenCL is all but dead at this point)

OpenCL is irritating for graphics development, because it doesn't integrate as seamlessly with the rest of the graphics pipeline as GL compute shader does. Unified approaches such as GL compute shader or Vulkan are much more convenient.

Float textures were just optional back in WebGL 1[1]. Any new spec is going to lose in support coverage to WebGL 2 which has been shipping for a year now!

[1] Look for RGBA32F in the WebGL 2 and corresponding OpenGL ES 3.0 specs. Also documented on MDN's coverage of OES_texture_float.

I peeked at the source code of the shaders, it looks like it is metal for the web. I don't get how a closed API like metal could be the future of an open internet. Yet it can start a discussion.

It's meant to be a starting point:

"We expect the discussions around the shading language to be one of the most fun parts of the standardization process, and look forward to hearing community opinions.

For our WebGPU prototype, we decided to defer the issue and just accept an existing language for now. Since we were building on Apple platforms we picked the Metal Shading Language."

As someone who likes developing OpenGL apps in his spare time, that handwaving actually bothered me. Of course Apple's going to pick Metal's shader language, they don't fully support anything else! They're still on OpenGL 4.1 in their drivers, even though those GPUs support GL 4.5, in what seems to be an effort to move graphics devs to supporting Metal. I have no idea why anyone would let them near an open graphics spec discussion after such a stunt.

Just like Sony, Nintendo and Microsoft.

Apple had their own 3D API in the old days, Quickdraw 3D.

They only played nice with OpenGL, because of NeXT acquisition, NeXTSTEP had Renderman and OpenGL, and they needed to bring developers into their eco-system to avoid closing doors.

Now the bank is full and with graphics middleware, a 3D API is just another interface implementation for the scene graph rendering calls, that are actually used.

Metal is already supported by the majority of engines that matter in the industry, with Qt in the process of adopting configurable backends as well.

well that's precisely why the discussion is open – Apple can come in with their (arguably selfish) ideas, but they can't impose them on other big players such as MS, Google and Mozilla. In an ideal world this prevents the final common API from only working for one of them.

In their latest proposals, they're actually proposing a variant of HLSL which they call "Secure HLSL":

https://github.com/gpuweb/gpuweb/issues/42

Previous discussion from 9 months ago: https://news.ycombinator.com/item?id=14100783 (34 comments)

This is amazing - I've never run any kind of demos like this before in a browser (i.e. WebGL) that didn't immediately spin up all fans with 100%+ CPU usage for the browser. I ran the Shadertoy on a 4k monitor in full screen mode and CPU (as well as energy usage) was minimal, if noticable at all on my MacBook Pro. (Edited: Which means it's using the GPU only... that's the whole point here.)

There shouldn't really be any performance difference between WebGL and WebGPU in a ShaderToy-like example, given that only requires a single draw-call per frame. The API overhead should be utterly negligible in that case.

If WebGPU really does perform better in an apples-to-apples comparison (i.e. running the same shader) then there's something seriously wrong with Apples WebGL implementation.

edit: here's that example translated verbatim to WebGL if you want to compare: https://www.shadertoy.com/view/Mt2fRy

I tried that shadertoy and it's running at around 26-28% CPU usage in both Chrome and Safari.

So the exact equivalent in WebGL is noticeably harder on the system than the WebGPU version.

While you are right, for me WebGL is nothing more than just for prototyping purposes, in what concerns mobile devices.

Most of the WebGL demos that get posted around here, always have issues running on my mid-range devices, that don't have any issues playing my collection of 3D games.

So I still look forward to a 3D Web API that can actually compete with native 3D across all mobile devices, not only on flagship ones.

Or proper implementations of WebGL, if that is actually the issue.

I'll just refer back to the last time you replied to me with that exact comment :P

https://news.ycombinator.com/item?id=16086537

I suspect that Three.js is the main reason why so many WebGL demos are slow, rather than WebGL itself.

Hehe, didn't notice the username. :)

Might be, but what counts is the perception when someone goes to a given web page.

EDIT: Just tried your shader toy example on an LG Power X, with a Mali T720, it averages on 20FPS.

This works great in safari, which makes me wonder why they're doing this at all

Would love to see some kind of status update on WebGPU from any of the participants. Is this the latest?

https://lists.w3.org/Archives/Public/public-gpu/2017Sep/0015...

I wouldn't say that we've crossed any significant milestone since Chicago F2F. There's been progress on the implementations, but conceptually the main questions about the API are still open.

But why?