Waiting for the dust to settle
All hell is going to break loose and the PC industry is going to go up in flames if another API war is launched. AMD, Apple, Khronos, Microsoft, EA, Crytek, and others are threatening to unravel all the work done over the past 15 years to stabilize the in-dustry. Or are they?
Those of you who were around in the mid to late 1990s will recall we had several APIs to use. Glide was one of the most popular for gaming, Microsoft was improving DirectDraw, OpenGL was available and used in some games, and most of the AIB or graphics chip (they weren’t called GPUs yet) suppliers had their own API.
These APIs exposed the special hardware features of the chip/board so game developers could get the most out of the device and deliver the best game. There were two problems with that situa¬tion: the drivers were buggy as hell and largely responsible for the blue screen of death (which Microsoft was unfairly blamed for), and the game developers had to support a half-dozen APIs if they wanted to get their game to be playable on the most PCs. At the time there was no dominant AIB supplier.
Microsoft decided the display API was too important to be left in the hands of a bunch of uncooperative and competitive chip and board builders and took over the API, introducing its DirectX API. DirectX 1.0. It was a good first attempt but lacked certain re-finements and 3D sophistication. It was released with Windows 95 in late August 1995. Nvidia was the first graphics chip company to embrace Microsoft’s DirectX API, and in 1996 declared that it would be the first 3D company without a proprietary native-mode API.
DirectX 7 and 8 and beyond
It took time and several iterations, and by 1999 when Microsoft introduced Windows 2000, it came with DirectX 7. DirectX 7 was pretty good, more than good enough, and the burden of supporting one’s own API was tak¬ing a toll on the surviving AIB and chip builders, so by the end of the year 2000 when DirectX 8 was introduced, it became the industry standard. Life calmed down in the PC and gaming industry, blue screen occurrences dropped, and games improved. The Internet bubble burst, and consolidation began in the PC and in particular in the AIB and graphics chip markets.
Over the years Microsoft made improvements to DirectX, usually in sync with the (now) GPU supplier’s developments. OpenGL tracked DirectX on features, occasionally leading on one function or another, but generally a year behind. Microsoft had no serious competition for DirectX and the last thing the survivors of the market consolidation wanted was disruption, added costs, and confusion due to multiple APIs. There was, as we said at the time, peace in the valley.
The peace held for nine years, and in 2009 DX had evolved to version 11 with extensions. That was four years ago, four years without any major improvements to DirectX 11. However, during those four years the committee-based, consensus-driven Khronos Group that manages and develops OpenGL (as well as many other open APIs) caught up with and passed DX in terms of advanced CG functions and features. That didn’t bother Microsoft since no one was using OpenGL in games any longer except for a few games that ran on Apple machines. Apple would sooner bite off its arm than use a Microsoft API, so as a Khronos member, it not only fully supported OpenGL, it made major contributions to the code-set and library, albeit it was Apple-centric.
Mantle to the rescue
But there were storm clouds on the horizon, and in the fall of 2013, in Hawaii, AMD surprised a gathering of press and analysts with the announce¬ment of a new lightweight (i.e., “thin”) API specifically designed for games and called Mantle.
By 2013 DX had become a bloated, heavy API, carrying with it, as it had to, backward compatibili¬ty with machines made be¬fore the turn of the century. A case in point: recently here at Mt. Tiburon Test¬ing Labs we downloaded and installed a mod to the 2007 game Stalker called Alpha-one. In order to get it running, it was necessary to install DirectX 7 elements.
AMD’s Mantle ignores all that backward compat¬ibility and is designed to be employed, and deployed, only on the newest of games like Battlefield 4 and oth¬ers. Mantle doesn’t carry the overhead of a big draw¬ing library because most of the draw functions are now in the game engines. Mantle gets the application as close to the hardware as possible— “close to the metal.”
When game and game-engine devel¬opers started declaring their support for Mantle, Microsoft did take notice. At the GDC in March 2014, Microsoft gathered some of its loyal friends and made a declaration that there would be a thinner, lighter new DirectX coming, soon, as in maybe a year. It was some¬where between comical and pathetic, but the industry was put on notice: don’t go messing around with another API—we will obsolete it, steal from it, and make your life miserable if you’re caught using it.
At the same time, but without hoo¬ray and fanfare, Khronos was discussing with developers an idea they had/have for what they are calling the zero-driver. This would be the thinnest of all, ex¬pose everything, everything—including all the special accelerators, LUTs, and state-engines in any GPU that would sign up for the API. However, the Zero- API was also at least a year away.
Apple fights back
Apple, which has always marched to the beat of its own drum, heard all that. They, of course, knew what was going on at Khronos, didn’t give a damn about what was going on at Microsoft, and admired what AMD did. They de¬cided the time had come to unleash the dogs from their skunk works, and at their recent developer’s conference an-nounced their new Apple-specific API, which they are calling Metal; currently for iOS, like Apple’s other graphics programs and tools, it could migrate to OS X.
The new generation of API wars has begun. We now have, or soon will have, five competing APIs: DirectX 12, Man-tle, Metal, OpenGL 4.4, and Zero-Driver. There are rumors Intel is also considering a super-thin driver for its embedded graphics GPU (and in fact there is a bit of one buried in their drivers now).
The future—what do we think?
Microsoft has lost a lot of its mojo. It’s no longer the 800-pound gorilla in the room—feared, checked with, or watched like it used to be a few years ago. The company has never been a leader, but it was a damn good stabi¬lizer. Those days may be past, too. An easy prediction (using the rear-view mirror) would be to say when Microsoft re-leases DirectX 12 (or whatever they end up calling it, since Metal, Mantle, and Zero are more exciting novo names), it will be, as in the past, adopted by all and once again become the industry standard.
We don’t think so this time.
Yes, DX12 will probably become the most widely used, just for convenience if nothing else. But for the high-end enthusiast users, the power users, and the boutique suppliers, the game developers will support two or more thin, fast, rich APIs. The software development tools and debuggers are much better today. The overhead of supporting multiple APIs, especially when they are thin and light, is not the burden it used to be. Also, as a result of the consolidation of the industry, the surviving companies are much bigger and stronger and can easily carry the burden. In addition, it will give them differentiation opportunities just as TressFX did for Tomb Raider, and Nvidia’s Tessella¬tion engine did for them in The way it’s meant to be played. Those features were extensions, done around DX, and they showed that the industry won’t wait for sluggish Microsoft to deliver the industries solutions on Microsoft’s schedule.
Apple may abandon OGL with Metal, or Khronos may adopt it. It matters little to Apple, and Khronos doesn’t need Apple to survive.
The game developers will take Mantle away from AMD and use it on any GPU. That means Nvidia will probably announce their new thin-and-light API at the next GTC or CES.
So will there be a new round of API wars—only if Microsoft wants to start a war due to paranoia and fear of los¬ing mind-share. There’s really nothing wrong with having multiple APIs if they are thin and light, and if there are good compliance testing polices. That will be a self-discipline the game developers will have to employ, but it’s in their best interests to do so—no one wants a review that talks about how buggy the game is. So don’t think of it as API wars but rather the democratization of APIs and a new generation of high-performance games. That’s a win-win. .jpg)
P.S.: If you’d like to learn more about the development of APIs in computer graphics, there is more detail in my book, The History of Visual Magic in Computers: How Beautiful Images are Made in CAD, 3D, VR and AR.—J.P