Soapbox Stand: OpenGL vs. Direct3D

Yea, yea, yea, I know what you are thinking, “here we go again..”  Bear with me though, as after reading an interesting perspective from a real developer over Rage3D (see source link), things may not be as they seem today.  Technical jargon aside, he has a good point.  Read on to find out. 


I have no doubt you will be able to find loads and loads of testings, many swaying one way, some the other, but the general consensus is that Direct3D reigns supreme.  It is quite the uphill battle for OpenGL, even at a time today, when Valve and the Source Engine team battle their way into a space, that until recently, was not in the spotlight, Linux.  The debates can go on forever and ever, but often either side, or both, are uninformed techno nerds, who have never even programmed for either platform.  Thankfully people like “BobV” shed a little light on this subject and huge controversy.

An anecdote from “Bob”

In his long, but very informational post, BobV outlines just what experience has taught him , and in classic bi-partisan style, illustrates exactly why OpenGL isn’t as good as Direct3D, just yet.   His experience goes a far way to explain how this is the case, with experience developing for the consoles, as well as PC.  Sure I could show you subjective graphs from all over the web, but that is something you can do easily without me telling you.  I had to share BobV’s perspective, because I believe there is some good insight attached to it, and maybe you’ll understand what all the hubbub is about.

There seems to be this big revelation that, because the new Sony and Microsoft consoles have an x86 architecture, they will be largely the “same.”  This is simply not true, as you’ll soon find out.  Back on PS3 and Xbox360, OpenGL was rarely used ever, and only possible with the OpenGL wrapper on the PS3.  Also, with one GPU better than the other at that time, difference existed also there, as well as the obvious numbers game with each consoles themselves.   The hardware differences make a good deal of difference when it comes to the abstraction layers talking to the hardware, and also the APIs.    The game talks to the abstraction layer, which then talks to the hardware specific code (PS3/4, Xbox360/One), and finally, on to the APIs (i.e. Gnm, D3D, or OpenGL).

With the advent of the newer Sony and Microsoft consoles, we have a common Direct3D11 class of features to work with.    This essentially means you will get the same set of features between the two consoles, but when it comes “down to the metal,” that is where things diverge.  The PC will likely not see a great benefit here, as much as all of you want to believe, just because it follows a similar architecture (x86), as the consoles take hold of hardware functionality over PC driver APIs.  

The differences

The problem is this: you simple cannot make assumptions on the PC platform (on any OS, be it windows/OS X/Linux).  The example BobV gives us is compute shaders.  On a console, computational threads are lock-step and never change, so definite assumptions can be made about performance, and things like shaders can be pushed, as we know the limit.  With the PC, you have to account for variables out of your control, and dynamically compile shaders or risk issues not operating in “the safe zone.”  Having set constraints, such as the memory size available for the GPU to work with. The graphics API used on the consoles is not as “heavy” as the PC, removing a lot of the “talking” needed to get the job done.  On the PC, graphics drivers make a lot of heavy overhead for the command buffers, with layers to talk back and forth from software to hardware.  These drivers on the PC change rapidly in contrast.

Additionally, OpenGL does not use a common runtime like Mircrosoft does with Direct3D, which is done at a low level in the DDI (Device Driver Interface).  This point makes a considerable difference given the fact that both Direct3D and OpenGL use a display driver on the PC.  With OpenGL, every vendor implements the entire API in the driver itself, producing varying behavior when it comes to API calls, and increases development time and efforts for game makers.    The ease of use for Direct3D has largly kept the prize away from OpenGL.  It is funny too, as John Carmack once, in 1997, pleaded with Microsoft to switch to OpenGL instead of Direct3D.  When that didn’t happen, all it took was time and money, and Microsoft slowly evolved the API to a much better state.  People, like Carmack, quickly turned around when it evolved.  OpenGL by comparison though, has far better programming language support and lack of dependency on any one feature of a given language.   The fact that OpenGL does not rely on the hardware specifics, but rather an emulated hardware approach.  It wasn’t even until DX10 that Direct3D was able to perform “marshalling,” in which optimization can occur between user-mode and kernel mode calls. 

The main advantage of OpenGL, and perhaps it’s saving grace, is extensions.  Being an open platform means a lot when it comes to welcoming changes and improvements, and OpenGL is a perfect example of this.  Any drive can advertise its own extensions with OpenGL, adding functions and capabilities  for the GPU and system.  The simple fact that OpenGL can take these extensions and build them into the core of OpenGL from many vendors and developers is key.  Direct3D relies on one vendor, Microsoft.  While this means there is a more consistent API, we are denied access to vendor-specific additions or extensions.   Where this hurts OpenGL is code has to be written for each brand of card/system, where Microsoft has one code path for both brands of card. 

The meat and potatoes: Linux OpenGL use

This is where the fun part comes in, and apologies for all the back story, those who were only concerned about the Linux side of this, but it all goes together, and I’ll explain why.   While many considers Valve’s “numbers” to be a PR stunt, they do show to some degree, what OpenGL is capable of.  But, because it was written in the high times of DX9, it shows, with higher overhead for per-draw calls to the API.  As stated, it was never a contest of what was faster, but the tools of the trade.  OpenGL simply does not have good tools or driver support (in BobV’s eyes).  I would have to investigate a bit more, but I can believe this in large to the massive support gap of OpenGL in favor of DirectX. 

To me, it is largely a case of Internet Explorer all over again.  We have a system that has been so ingrained in our heads from, surprise!, Microsoft, that getting out of the trenches will take some work.  The programming model just isn’t there for OpenGL, specifically games, despite seeing some awesome projects on the web on what it can do.  In the professional world, OpenGL was actually king of the hill, due to SGI’s involvement.  That gap has narrowed today of course.    Thought the advantage of a wide range of hardware support, from low-level cards to the highest end, is what makes OpenGL a still viable choice for many.  There is a reason why CERN uses Unix/Linux and OpenGL.

So, in the end, OpenGL does have the capability to be great, but until some of the platforms edges are smoothed over, and support increases in the Vendor world, it will be an uphill battle.  Like IE on Windows, until the vast majority knows that potentially better alternatives can make it, no one will give it the amount of support it needs.  I honestly believe if all DX11 developers just moved to OpenGL today, and the tools and programming model were rewritten, it would be fantastic.  An Open System that anyone can thrive on.  Hmmm…this must be the kind of things that Richard Stallman warned us about 🙂 

Since 2005, improvements like Frame Buffer Objects, made it substantially easier to manipulate pixels and textures.   Things like that are making the two differing APIs come to almost a convergence, and in my opinion, we will see OpenGL come out on top in the end. There are other roadblocks in the way, but as long as certain pieces of the puzzle are closed source (Nvidia/ATI etc), it will be harder to tap into the power that could be unlocked.  You can’t write good tools without a way to interface with some of the better hardware features that exist elsewhere.  I truly wish OpenGL was just a tad stronger, as having one company (Microsoft) string along a closed system, is far from what I prefer.  As long as OpenGL is essentially shunned from consoles (due to preference for those consistent APIs), adoption will be slow, as the PC market for games is small.  The open system of OpenGL is a world I would much rather live in.

Thoughts?  Comments?




About professorkaos64

Posted on 20130807, in Soapbox Stand and tagged , , , , , , , . Bookmark the permalink. Leave a comment.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s