This week at the Games Developers Confab in San Francisco the big news was all about the new Vulkan™ graphics and compute API, destined to displace the fabled and industry graphics work-horse OpenGL.
At the conference, gaming developer stalwarts got on stage to demo and boast the virtues of the new Vulkan API showing early apps work on early drivers. In some demos a 5x speed up over OpenGL was achieved with Vulkan.
Vulkan: Five Things for Apple Users
Over the past week the announcement of Vulkan has spurred on dozens and dozens of questions and even more heated commentary and speculations, the vast majority of it not really that focused on Apple’s platforms. But this clearly affects Apple and there are five key issues or questions we want to map out for you now.
- Will Vulkan not just replace OpenGL but inadvertently fork developers, thereby hurting Mac OS X users in particular?
- OpenCL and CUDA compete in the compute space, will Vulkan unify, displace or affect these standards?
- Apple has its new explicit graphics API in Metal, will Vulkan kill off developer interest in Apple’s proprietary Metal?
- Khronos says it will continue to supporting OpenGL, but if its development stagnates what might become of graphics on Mac OS X for the non-gaming side of the market?
- If Apple’s Metal is successful on iOS might Apple bring it to OS X, and if so what affect might that have on Vulkan’s success on the desktop?
Will Vulkan not just replace OpenGL but inadvertently fork developers, thereby hurting Mac OS X users in particular?
Actually, it’s OS specific API’s that typically fork development, as in Microsoft DirectX or Apple’s new Metal. Vulkan™ will be the only cross platform explicit (low-level) GPU API.
Vulkan looks much more like a “unification force” acting in the GPU-API market, regardless of Vulkan’s effects on OpenGL. For Pro apps on the desktop, some specific apps may quickly take advantage of Vulkan, displacing OpenGL or even OpenCL and CUDA. Since the trend line in the CAD market has been on supporting more platforms, there likely be significant pressure on the Khronos Group to advance OpenGL despite Vulkan.
Both Vulkan and Microsoft’s explicit direction with DirectX 12 technology will have less appeal to pro desktop CAD and DCC apps than the older API’s that feature more hardware abstraction. Despite the fact that CPU’s continue to progress at pithy rates, these developers are investing in many other methods for speeding up workflows (like tapping grid render farms on the cloud) and actually turning workstations into new types of thin-clients (power+cloud power) tapped into cloud (think OTOY and Octane Cloud.)
If one looks at the companies behind Vulkan it is clear this is gaming industry driven. Not only that, but when Khronos tried to implement some of these technologies in OpenGL 3.0 spec, the CAD members of the Khronos Group revolted, forcing the group back on such efforts. From one perspective Vulkan may shape up to be the open standard API of the gaming world, while OpenGL remains the open standard API of the CAD world. (see image 02)
Vulkan and OpenGL will continue to develop side-by-side and Vulkan doesn’t appear to present any threats to forking development across desktop in such a way to hurt OS X. If anything, some of the compute aspects of Vulkan in combining with graphics may help the platform. (we have ideas and will investigate this soon)
OpenCL and CUDA compete in the compute space, will Vulkan unify, displace or affect these standards?
CUDA and OpenCL and Vulkan are all quite unique APIs with distinct advantages. OpenCL being related to Vulkan both through the same group (Khronos) and via SPIR-V shared core technology, each support each other. They will both benefit from SPIR-V related technology and advancements. This will include kernels and shaders in C++ and other high-level languages, front-ends, and backend compiler technologies.
In short, Vulkan and OpenCL should be seen as siblings of a sort when it comes to compute. The key difference, or one of them, is that OpenCL is heterogeneous, meaning it can be executed over CPUs as well as GPUs and both at the same time. Vulkan may displace OpenCL for applications that can gain from both compute and graphics at the same time.
Vulkan isn’t likely to displace CUDA quickly either, as CUDA is a matured and entrenched technology. When it comes to forking, developers in the CAD and DCC space have often chosen one over the other, forking users over the proprietary Nvidia hardware support with CUDA. This is the issue at the moment, for some folks, with the new Mac Pros, which do not support CUDA.
Apple has its new explicit graphics API in Metal, will Vulkan kill off developer interest in Apple’s proprietary Metal?
On both desktop and mobile, new battle lines for graphics API supremacy are being drawn, with the ambitions of developer alliance and “first to my OS” goals for leading apps always at stake.
Every Mac gamer knows how crappy such a strategy is if you are on the losing end of that. So do many console gamers, who have had to wait for games they hunger for because of a “first to my OS” strategy not working in their favor. Neil Trevett, president of Khronos, says that the group is always about giving developers (and thus users) choice, thus open standards.
Vulkan could very much be Microsoft’s “OpenGL” in mobile. Much as Apple leveraged a key open standard in OpenGL to gain the Mac a seat at the table in the pro apps markets, so too could Microsoft gain a seat at the table for the mobile gaming market if it made sure that game developers embraced Vulkan rather than Apple’s proprietary Metal. The beauty of that strategy is it might further Vulkan as heir apparent to OpenGL and OpenGL ES, thus further assuring Vulkan the ascendency across desktop as well. Doing so would likely be good for the Mac.
It is totally unclear if Vulkan will be embraced by either Microsoft or Apple. Microsoft is not on the working group, despite its Khronos Group member status. Apple is.
Metal’s shader language is C++11 based and implemented using clang and LLVM. LLVM to SPIR-V translators are already in the works. SPIR-V itself is derivative of LLVM, which is a compiler infrastructure project that is open source and largely influenced by Apple. Swift has a compiler that uses LLVM.
The bottom line is only time will tell what kind of impact Vulkan will have on Apple’s own Metal API and how game developers in particular will respond to both options in the market.
Khronos says it will continue to support OpenGL, but if its development stagnates what might become of graphics on Mac OS X for the non-gaming side of the market?
It is hard to imagine going back to the days when Apple essentially used its own graphics API in QuickDraw 3D. Yet, with Metal for iOS here we are again with Apple offering its own platform a superior solution. The difference this time is that Apple has near total control of the technology stack—authoring the operating system (iOS), having special licensing with ARM and Imagination to architect its own chips (A-series CPU and PowerVR version technology for the graphics processing), and the ability to author its own graphics API.
That is a unique advantage that nobody else shares with Apple. So Apple’s Metal is aptly named, for the company can not only program for the metal with its explicit API but it can architect the “metal” to fit its software API as well. However, unlike iOS the Mac platform doesn’t offer Apple that unique controlling advantage. Macs—like Windows PCs—rely on CPUs and GPUs architected by others, with associated and linked software technologies.
If OpenGL stagnates on the desktop market, for any reason, the Mac desktop market may find itself back where it was in the late 1990’s. A GPU API split between Microsoft Windows and the rest of the desktop industry isn’t a good thing. For its part, Neil Trevett, President of the Khronos Group, said that OpenGL (and OpenGL ES) APIs will continue to be advanced by the consortium, yet he also shared what possible benefits from Vulkan’s efforts may come to OpenGL.
I asked Trevett what kinds of things might the Khronos Group do next for OpenGL that bear some relation to the benefits afforded developers in Vulkan? Trevett replied: “That is still being debated—but enabling OpenGL to ingest SPIR-V is one obvious potential convergence opportunity.”
The convergence of some technologies from Vulkan touching down on the older open standard will help them potentially stick around longer for those types of developers who need them. As someone said in a comment on another site, they can see OpenGL sticking with the market for another ten years. On the other hand, Steve Jobs killed Apple’s high-level QuickDraw 3D graphics API just three years into its promising life.
If Apple’s Metal is successful on iOS might Apple bring it to OS X, and if so what affect might that have on Vulkan’s success on the desktop?
So this begs the last question. What if Apple ends up with such success with its own graphics API—just like Microsoft—and decides to develop such an API for Mac OS X? This is a good question because Vulkan was aided by AMD’s Mantle API which AMD ushered into the industry consortium last year.
AMD’s Mantle was created to give AMD GPUs unique advantages over Nvidia GPUs and to finally have the dream low-level, explicit GPU API the game community had been waiting for. Mantle was available for the Windows desktop system. And initially folks got very excited. Mantle would compete with DirectX 12 technology. And if AMD’s plans ultimately took Mantle to OS X, it would have competed with OpenGL on both platforms.
If AMD can get Mantle running on Windows so can Apple get Metal running on Mac OS X. Traditionally, Microsoft had the clout to get unique focus from the hardware vendors so that DirectX technology was optimal. But Apple these days has that clout as well. Through agreements that span both mobile and desktop, a range of possible scenarios could be imagined. If both Microsoft and Apple brought proprietary GPU APIs to the desktop market the effect on the Vulkan API might be pretty bad for the new open standard.
Let’s hope Apple doesn’t do that, but instead puts its weight behind “open standards” and the new Vulkan.
Over the course of the past few days I have been in contact with Khronos Group president, Neil Trevett, who is a wealth of knowledge in all things GPU related and of course in what the group hopes for Vulkan and the other standards. Here are few more nuggets worth knowing about.
While Vulkan is not backward compatible with OpenGL API architecture, Trevett explained that Vulkan utilizes the same shader language—GLSL. “Existing [OpenGL] shaders will continue to work.” Additionally—and relieving concern about this transition or cross-over of APIs—there will be layered utility libraries over Vulkan that will make things easier on developers. Out on the Net some have wondered if it might be possible to implement fully conformant OpenGL drivers over Vulkan, Trevett said Khronos does not have that as a primary design goal and such a thing could be tricky.
One last piece that folks may find interesting is this. Like OpenGL, it largely doesn’t matter how much Microsoft gets behind Vulkan, or not, graphics vendors will likely ship Vulkan drivers wherever OpenGL drivers are shipped for those developers who choose to use them. But interestingly, Trevett adds that Vulkan will be able to ship to any version of Windows, whereas DirectX 12 drivers will only ship on Windows 10. “This is significant,” says Trevett, “because many game developers will want to ship using a modern API across as many windows systems as possible.”