The professional Mac 3D and CAD markets only exist today because of OpenGL. Apple’s decade plus platforms resurgence in professional 3D and CAD software markets would be for not if it wasn’t for the availability and dominance of a universal and portable graphics API.
So it goes without saying that in the face of newer lower-level graphics APIs in Apple’s Metal, and Vulkan that the direction OpenGL takes from here on is quite critical. So too is knowing which professional software tools are relying on classic OpenGL and which ones are venturing into supporting new low-level graphics APIs.
OpenGL Isn’t Packing for Retirement Yet
On the eve of SIGGRAPH 2017 Neil Trevett, President of the industry consortium The Khronos Group, spoke to Architosh about the evolving OpenGL standard as well as directions the group is taking to plot a path for a universal graphics API that engages the use of low-level APIs.
01 – Neil Trevett of NVIDIA and President of The Khronos Group talks to Architosh about where the industry consortium is taking graphics standards.
Since the announcement of Vulkan—an open industry standard by Khronos—I keep asking Neil Trevett “status of life”-like questions about OpenGL. While Vulkan was never intended to replace OpenGL outright, it seems OpenGL is picking up some of the technologies utilized in Vulkan. And that’s a good thing.
Take for example OpenGL’s latest version and its adoption of SPIR-V.
The importance of SPIR-V
“The key thing in OpenGL 4.6 is that SPIR-V is part of core,” says Trevett, who is also senior VP at NVIDIA. “Anything you can compile to SPIR-V can now be supported in OpenGL.”
Readers may be asking what is SPIR-V and why should I care?
Well for starters, SPIR was originally developed for OpenCL, a parallel programming standard Apple invented and still pushes to this day. Without getting too technical, I asked Trevett to break it down for me. “SPIR-V is a simplifying technology in the graphics API and driver technology stack,” he says, “it is not an API; it’s a file format that connects the front-end compilers to the back-end compilers.
Compilers are key in graphics. The way to think about OpenGL versus Metal or Vulkan, in particular, is this: picture a box in the flow between an app’s code that is bound for your GPU. The bigger the box, the more time it works on translating code into the format your GPU hardware understands. OpenGL has a big box in that flow; Vulkan has a much smaller box. Vulkan is thus faster.
02 – This slide from Trevett’s desk explains the SPIR-V ingestion in OpenGL. Shader languages, like OpenGL’s own GLSL, are translated into SPIR-V via “glslang” and third-party sources. Meanwhile, SPIR-V is bi-directional with LLVM, a compiler; on route, SPIR-V targets OpenCL, Vulkan or OpenGL API pipelines.
Why the different [metaphorically) sizes? The compiler stack in Vulkan is much more streamlined because the developer is writing the graphics code in the Vulkan API and that API has less abstraction. The phrase: programming down to the metal is apt, in this case.
MORE: SIG: The Khronos Group Releases Major Update to Graphics API—OpenGL 4.6 with SPIR-V Support
But back to SPIR-V. The support of it in OpenGL means that OpenGL’s traditional shader languages, like GLSL, can ultimately target final graphics runtimes like OpenCL, Vulkan along with OpenGL. But just as importantly, SPIR-V naturally handles compute shaders along with graphics shaders, providing a comprehensive language shader construct that is aimed at machine independence, cross-compatibility, and in line with future hardware advances, especially in the areas of closer cooperation between CPU and GPU.
All of this boils down to much greater shader language independence and flexibility for developers. It means developers working on OpenGL apps are no longer limited to GLSL for their choice of shader language. This—along with many extensions to OpenGL now incorporated into its core—means that OpenGL is still making big advances.
What Developers Are Still Interested in OpenGL
It turns out that developers still have a very high interest and demand in OpenGL, a trusted API that has sustained the 3D industry robustly for decades.
Trevett explained that there are billions of devices that support OpenGL ES 3 with mobile apps in particular. “So I think that the mobile community will continue to want to use OpenGL for many years to come.”
“In the desktop space it is primarily the professionals who want OpenGL…for CAD applications, design, and visual simulations applications,” says Trevett. He said that some of those companies might begin to transition to Vulkan if they need additional capabilities. But this assumes those capabilities require things only the low-level APIs offer.
Apple’s Fork In The Road at OpenGL ES 3
While the desktop space will continue to march along with OpenGL 4.6 and its future, on the mobile front, Apple threw a fork in the road at OpenGL ES 3. It is the last and final version Cupertino is supporting on its iOS platform.
And it is an unfortunate turn of events because OpenGL ES 3.2—the current latest version—offers a lot more desktop-class functionality. “Version 3.2 is actually shipping on Android devices today,” says Trevett. “For the Android community, a lot of people are familiar with OpenGL ES.”
This leaves the developer community at a pivotal point. And it means The Khronos Group is tasked with handling this fork in the road. This is nontrivial because as Trevett says, “many people like the new style of APIs, the new low-level, high-performance, low-latency APIs.”
SaveSave
SaveSave
SaveSaveSaveSave
SaveSave
SaveSave