Return of the DirectX vs. OpenGL Debates
by Jarred Walton on March 24, 2014 3:55 PM EST
With the announcement of DirectX 12 features like low-level programming, it appears we're having a revival of the DirectX vs. OpenGL debates—and we can toss AMD's Mantle into the mix in place of Glide (RIP 3dfx). I was around back in the days of the flame wars between OGL and DX1/2/3 devotees, with id Software's John Carmack and others weighing in on behalf of OGL at the time. As Microsoft continued to add features to DX, and with a healthy dose of marketing muscle, the subject mostly faded away after a few years. Today, the vast majority of Windows games run on DirectX, but with mobile platforms predominantly using variants of OpenGL (i.e. smartphones and tablets use a subset called OpenGL ES—the ES being for "Embedded Systems") we're seeing a bit of a resurgence in OGL use. There's also the increasing support of Linux and OS X, making a cross-platform grapics API even more desirable.
At the Game Developers Conference 2014, in a panel including NVIDIA's Cass Everitt and John McDonald, AMD's Graham Sellers, and Intel's Tim Foley, explanations and demonstrations were given suggesting OpenGL could unlock as much as a 7X to 15X improvement in performance. Even without fine tuning, they note that in general OpenGL code is around 1.3X faster than DirectX. It almost makes you wonder why we ever settled for DirectX in the first place—particularly considering many developers felt DirectX code was always a bit more complex than OpenGL code. (Short summary: DX was able to push new features into the API and get them working faster than OpenGL in the DX8/9/10/11 days.) Anyway, if you have an interest in graphics programming (or happen to be a game developer), you can find a full set of 130 slides from the presentation on NVIDIA's blog. Not surprisingly, Valve is also promoting OpenGL in various ways; the same link also has a video from a couple weeks back at Steam Dev Days covering the same topic.
The key to unlocking improved performance appears to be pretty straightforward: reducing driver overhead and increasing the number of draw calls. These are both items targeted by AMD's Mantle API, and presumably the low level DX12 API as well. I suspect the "7-15X improved performance" is going to be far more than we'll see in most real-world situations (i.e. games), but even a 50-100% performance improvement would be huge. Many of the mainstream laptops I test can hit 30-40 FPS at high quality 1080p settings, but there are periodic dips into the low 20s or maybe even the teens. Double the frame rates and everything becomes substantially smoother.
I won't pretend to have a definitive answer on which API is "best", but just like being locked into a single hardware platform or OS can lead to stagnation, I think it's always good to have alternatives. Obviously there's a lot going on with developing game engines, and sometimes slower code that's easier to use/understand is preferable to fast/difficult code. There's also far more to making a "good" game than graphics, which is a topic unto itself. Regardless, code for some of the testing scenarios provided by John McDonald is available on Github if you're interested in checking it out. It should work on Windows and Linux but may require some additional work to get it running on OS X for now.
Source: NVIDIA Blog - GDC 2014
Facebook
Twitter
RSS
105 Comments
View All Comments
ET - Tuesday, March 25, 2014 - link
There was never an OpenGL wrapper. In NT there were two driver models, MCD and ICD, where MCD provided some common code in software so was easier to implement but slower. That got dropped in later OS's. However there was nothing to "wrap" at the NT time since D3D didn't exist.IIRC there was some talk of a D3D -> OpenGL 1.4 wrapper in Vista, but it got dropped, and we were left with the old OpenGL 1.1 software implementation or ICD implementation.
risa2000 - Tuesday, March 25, 2014 - link
Right. I used the wrong word. It was simply software implementation. I do not remember though if something similar existed in Win9x/ME.Penti - Wednesday, March 26, 2014 - link
Are you sure your not confusing it with the built in opengl-libraries? MS supplied their own for a while. It never got updated above OGL1.1. However that's not the driver (M-/ICD in the old days) and you use WGL, GLX, GLU libraries/headerfiles from Khronos, or a GLUT wrapper, SDL or some other library to talk to the drivers. Microsoft doesn't provide their own way here. Apple does, that why it can take a while and an OS update to get the full API moved along. Apple doesn't really stop things like extensions, Cuda or other such things though.syxbit - Monday, March 24, 2014 - link
What does Java have to do with anything?Android games are coded with the NDK (native code against OpenGL).
lmcd - Monday, March 24, 2014 - link
Java has to do with platform dominance -- if Android's Java implementation fails, Android fails, and Microsoft takes 2nd place in tablets and smartphones.R. Hunt - Tuesday, March 25, 2014 - link
I don't think Android problems have anything to do with Java. Android suffers a lot from sub-par hardware, terrible OEM customizations, and lack of timely updates (if at all) and decent support. Those are not related to Java at all.theromz - Tuesday, March 25, 2014 - link
Doesn't look like its going to fail real, and windows is so far behind in everything it would need to explode into bits before they even got close.sprockkets - Monday, March 24, 2014 - link
"Also, the way tablets are going, we're going to be back to the 90s soon enough. Intel-based Windows 8 tablets likely take over much of Android's strength in productivity tablets, and Apple will always have the iPad for content consumption and overall luxury."Why? Because of office which is available on Android as well? Because of the crappy legacy desktop?
Microsoft will still be around for the desktop. But they won't be able to dictate the market like they used to for the end users.
"Android has had a good run, but counting on Dalvik as the center of your OS (which is bound to the weaknesses of Java) puts a damper on Android power efficiency, performance, and scalability which can't be recovered. Android probably dead-ends somewhere between 5.x and 7.x, where Chrome OS takes over on Google's side and subsequently loses a huge install base."
Uh, no. And seeing how Windows is starting over with winrt, that really isn't any different.
"Basically, unless Google has an upgrade plan from Dalvik code to Dart code, I would put Microsoft as 1st or 2nd in tablet before 2018. If WP comes together with Windows (and finishes integration) then Windows Phone could start making a similar push."
Keep dreaming. And dart has nothing to do with dalvik. Have a nice day!
lmcd - Monday, March 24, 2014 - link
WinRT isn't starting over. It uses a new UI framework on top of .NET, which has been the de-facto Microsoft programming language for how long?Dart has a ton to do with Dalvik -- Dart is Google's newest VM and likely candidate for app development within Google. It likely becomes the default way to develop Android apps. There's a programming paradigm shift that needs to occur within Google that is only partially underway.
Office was not relevant to my comment. The desktop is not relevant to my comment, aside from the legacy of Windows RT (and the similarities in code patterns between the desktop and Modern).
Given how close Samsung is to diving to Tizen, Google's fall-off could happen independently of Microsoft (I'll grant you that), but it is coming.
Lastly, how is "Uh, no." any sort of rebuttal? Would you have questioned ARM's dominance in tablets a year or two ago? I'm not dreaming, I'm predicting. Google could pull off a better transition than I expect but I don't imagine it soon, or working well.
Honest Accounting - Tuesday, March 25, 2014 - link
What is MS going to have to offer (by 2018 or before) which will increase market share? The OS platform is largely irrelevant - especially in the productivity space you reference. The baseline reference there is HTML5 and it's associated development tools/environment - ie.browsers, and browser run-time environments. The only performance area in the consumer space is gaming where the best applications are native. You can talk about the inefficiency of Dalvik, but why can Nokia launch a Android phone (Nokia X) on lower spec hardware than a device running Windows phone 8.x (Nokia 520)? The same specs (Cortex A5) should be used for the 52x to highlight the performance advantages of Windows Phone. No?