“Welcome back to the second part of this important story on the future of graphics and how The Khronos Group is striving to deliver a universally portable graphics API in the emerging post-OpenGL era. Those interested in Part 1 can go here.
Why WebGL Plays A Big Factor in Universality
In Part 1 we discussed that with OpenGL ES 3.0 the entire computer industry had a true, universally portable graphics API that worked literally everywhere. In fact, OpenGL ES—which stands for OpenGL for Embedded Systems— is the most widely deployed 3D graphics API in history, which is why it is frustrating that Apple stopped supporting it beyond version 3.0.
It is important to understand that OpenGL ES is actually a subset of OpenGL, the API for graphics on desktop operating systems. This means that an app written for OpenGL ES 2 should be easily portable for the desktop OpenGL 2.
But developers have wanted to take graphics apps to browsers for years and thus grew the emergence of WebGL. WebGL is a Javascript API, and Javascript control code calls down to the native OpenGL running on that particular device. If you write for the modern web browser, you are writing code for just about every modern device. Thus the popularity and rise of WebGL.
The Critical Link
WebGL 1.0 is based on OpenGL ES 2.0, while WebGL 2.0 is based on OpenGL ES 3.0. Recall that OpenGL ES 3 is completely universal. But anything beyond the 3.0 version is not supported on Apple’s iOS devices. Therefore, thanks to Apple, the universality the industry has so enjoyed gets broken.
| Version | Maps To |
| WebGL 1.0 | OpenGL ES 2.0 |
| WebGL 2.0 | OpenGL ES 3.0 |
Not only does Apple’s break from OpenGL ES hurt app developers writing OpenGL apps for mobile devices across platforms it creates a problem for what comes next for WebGL after version 2.0.
Why WebGL 2 Rocks and Will Sustain for Years
OpenGL ES 3.0 brings desktop class graphics functionality to mobile operating systems and via WebGL 2 brings advanced new graphics capabilities in apps delivered through the browser. Neil Trevett, President of The Khronos Group, says that there are two ways the browser community wants to tap into WebGL 2. “Browsers are using them for both “composition” as well as their straight forward rendering,” he says, “and they need to be portable.”
As WebGL 2.0 moves into full adoption, over the next year and beyond, another key technology in WebAssembly comes into play. Also known as wasm, WebAssembly is a portable stack machine, a type of software computer that crunches numbers really fast.
The “interesting thing is it not just about WebGL anymore,” adds Trevett, “now we have WebAssembly, which is a really cool pairing.” He adds, “there is no doubt that WebGL 2 is where the action is going to be for web developers for the next few years. Both Apple and Microsoft have committed to it and will be shipping support for WebGL 2 very soon.”
But Developers Want More—Compute and Universality
While the world will be busy shipping products based on OpenGL ES 3.x and WebGL 2.0 for the next few years, things are critically missing.
For example, OpenGL ES 3.1 got compute shaders. “The compute shaders that people have been asking for in WebGL was lost on our universality just at the wrong moment,” says Trevett, referring to Apple not supporting OpenGL ES 3.1 and beyond on iOS.
“The Android and Windows community is probably going to do an extension for compute shaders…but that is a kind of half-ass thing to do without the support of Apple platforms,” says Trevett. “That’s why it’s important we get this WebGL Next—whatever that ends up being—off the ground and done.”
01 – This slide from Trevett’s deck shows where Khronos is headed to provide a unified graphics future for the industry. (image: Khronos / Architosh. All rights reserved.)
Trevett explains that developers want to utilize the GPU for things like vision processing, neural net instancing, and AI, and they want to do this through the web browser.
The Vulkan Subset Solution
“So we need a native universally portable API and a Javascript binding of it, so WebGL and WebAssembly can continue to work together,” says Trevett. At first, The Khronos Group approached the developer community with the idea of creating a mix of the three major APIs, but they scoffed at that saying the graphics world doesn’t need a fourth API.
“They said, please don’t create another API, three is bad enough. So we changed our strategy, and we are not going to create a new unifying API, what we decided to do is create a subset of the Vulkan API.” (see image 01 above)
The Khronos Group is still working on what they call the “overlap analysis, ” but Trevett says there is an 85 percent overlap between these three APIs (meaning Apple’s Metal, Microsoft’s DirectX 12, and Khronos’ Vulkan). “The overlap is substantial,” he adds, “so we think we can define a pretty big subset of Vulkan.
Khronos will create an open source library that will map Vulkan calls to Metal calls, for example, or Vulkan calls to DirectX 12 calls. “We can provide a Vulkan Tools Layer that will warn developers they are working outside the subset, so they don’t get unwanted surprises,” he adds, “and we can use SPIR-V Cross Translator to handle the shader languages that may differ.”
In Conclusion
When Khronos created the Vulkan API, it was hoped initially that all three major operating system vendors (Apple, Microsoft, and Google) would fully support it. But Apple just didn’t get on board, preferring instead to focus on providing their developers with the new Metal API. Metal isn’t as deeply low-level as Vulkan, providing some level of abstraction but not at the penalty level of OpenGL.
02 – This slide from Trevett’s deck shows the market forces demanding to unify and how the Vulkan Subset approach can solve it and meet developer target needs. (image: Khronos Group / Architosh) All rights reserved.) Click on image to see it larger.
The key thing is developers don’t want to get forked into supporting only some operating systems—using their native low-level APIs—due to cost constraints. But that’s what can happen.
Game engines, native 3D apps, browser engines, and Javascript and WebAssembly native bindings can all work through the Vulkan Portability Subset to target multiple native low-level APIs at once with common core code.
“The only rational way forward is to take one of the rival [low-level] APIs and subset it,” says Trevett. “So this is the process we are going through, and it’s moving pretty fast.”
MORE: Apple’s WebGPU Standard Proposal—Aiming at Common Access to Explicit Graphics
Quickness is important because Apple’s Webkit team earlier this year proposed a similar proposal to address a common way to access low-level graphics called WebGPU. “We are moving with great urgency because we want to be ready in case the W3C group agrees with us,” says Trevett.
Let’s hope there can be consensus soon in the industry that includes Apple sitting at the table like everyone else.
Reader Comments
Comments for this story are closed