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...
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.
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).
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.
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.
Which is hilarious because the trademarks on the S3 Virge with MeTaL API from the late 90s/early 2000s are still in effect. S3 should be suing Apple right now.
>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.
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.
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 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.
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.
"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.
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.
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.
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.
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.
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.
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.
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.
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.
57 comments
[ 4.0 ms ] story [ 103 ms ] threadI'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...
See https://gpuweb.github.io/admin/cg-charter.html
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).
So, Vulkan? This is literally what Vulkan exists for, and does – a shading language and API implemented by all vendors.
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.
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.
Highly unlikely.
Google frequently releases major products without Firefox support, with this only being added months or years later.
This is reality today.
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
I mentioned a 43% desktop ussge for Firefox.
Edit: Source: Hacker News comment a while ago by a person who talked to the team at WWDC
All major graphics middleware and image manipulation applications, are already Metal aware.
This isn't to say Vulkan is bad, everyone seems to be saying "In Vulkan, You really needs to know what you are doing".
Which is hilarious because the trademarks on the S3 Virge with MeTaL API from the late 90s/early 2000s are still in effect. S3 should be suing Apple right now.
>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.
So... pretty much everywhere then?
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.
[1] https://www.khronos.org/blog/khronos-announces-the-vulkan-po...
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.
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
https://github.com/kvark/webgpu-servo
[1] http://github.com/gfx-rs/gfx
"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."
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.
https://github.com/gpuweb/gpuweb/issues/42
https://lists.w3.org/Archives/Public/public-gpu/2017Sep/0015...
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
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.
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.
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.
So the exact equivalent in WebGL is noticeably harder on the system than the WebGPU version.
https://www.khronos.org/webcl/
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)
[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.