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
nico_mach - Saturday, March 29, 2014 - link
Let me say, whatever Valve's motivations, it's unlikely that one is 'faster' than the other ultimately, it's all about the effort put in by developers. That's been proven time and against outside the JIT compilers, determined programmers can generally get top performance, it's a question of how long it takes, and MS has always catered to that need.Scali - Monday, March 31, 2014 - link
Graphics APIs can differ quite a bit in terms of supported features and overall design. Perhaps you missed the recent buzz about Mantle and DX12? They significantly reduce CPU overhead and improve multi-threaded performance.So yes, it is quite possible to run into the limitations of a given API and/or driver.
althaz - Monday, March 24, 2014 - link
Does it perform better? I've seen this claimed many times, but have not seen a demonstration (other than newest OpenGL vs DirectX 9, which is hardly relevant).Alexvrb - Tuesday, March 25, 2014 - link
I was just thinking this. I can't believe they would brag about beating DX9. What's their next challenge? Glide?tuxRoller - Tuesday, March 25, 2014 - link
Well, you can see the above slides where the AMD, Nvidia and Intel devs claimed gl is about thirty percent faster, without any optimizations.inighthawki - Tuesday, March 25, 2014 - link
The entire point of the slides above was how it is faster WITH the new extensions/optimizations...tuxRoller - Tuesday, March 25, 2014 - link
I wouldn't call it the ENTIRE point since, according to the article, they've also said that unoptimized gl is about 30% faster than d3d.Most, if not all, of the features are addressing gl 4.3(with some extensions).
Klimax - Tuesday, March 25, 2014 - link
And where is evidence and data plus description of their test for replication?JarredWalton - Tuesday, March 25, 2014 - link
In the Github source link at the end of the article, presumably -- I haven't looked to see if any DX code was released, though, which would of course be needed to compare the two APIs.risa2000 - Tuesday, March 25, 2014 - link
I no longer follow OGL (maybe someone can shed some light on this from today's perspective), but back then (in late 80, early 90) on every Windows NT there was OGL wrapper provided by MS. And then there could be also native OGL provider implemented by hardware vendor (Nvidia, ATI, 3Dfx, Matrox, Intel). The app could choose, which provider it will use but at least one (MS) was guaranteed. Performance was not comparable though.Later on (I am not sure if it was Win2000, or WinXP) this OGL wrapper was removed from the system as DirectX was supposed to be "one and only gfx API to rule them all". And it did pretty good job at forcing certain level of quality on both ends - apps and underlying hardware. OGL was left to different HW vendors as an option, but for some reason the quality was usually subpar to DX implementation. Only some titles/engines were able to achieve comparable performance on both. So since then OGL was kind of option (also with different flavors depending on hw), while DX was guaranteed. I imagine this can still apply today as long as there is no guaranteed OGL provider on every Windows incarnation.