Friday, December 6, 2013

Why OpenGL Probably isn't the Graphics API of the Future and I Hope it Dies

Anybody who has followed my Twitter for any length of time is probably aware there is no love lost between myself and OpenGL. Up until this point I haven't really done a good job of explaining why, courtesy of Twitter's 140 character limit, however the land of graphics API's has recently gotten really interesting with AMD's announcement of Mantle and Valve throwing its weight behind Linux/OpenGL with SteamOS so I've decided to wade into the fray.

First some background information: the I-Novae Engine has both OpenGL and D3D11 rendering backends for maximum cross platform portability. Both rendering backends are actively maintained by myself and Flavien. If you don't know what the I-Novae Engine is or why you should care then please watch this video. In my day job I work as a contractor programming OpenGL drivers for an RTOS being used by a large multinational corporation for its safety-critical embedded systems. I bring this up because I think most people in either the D3D camp or the OpenGL camp have little experience with the opposing API so I just wanted to say I've worked quite extensively with both and I hope this gives me the opportunity to be as unbiased as possible. Lastly if you're a programmer you can skip the next 2 sections and go straight to "the only reason why you should use OpenGL".

A condensed history of 3D graphics API's

Back in the glory days of Doom there was no such thing as OpenGL or DirectX. A graphics programmer had to code the entire 3D pipeline himself. The awesome part of this was that you had complete control over every aspect of the rendering pipeline. The downside was that everybody had to reinvent a whole lot of wheels and a general purpose CPU just isn't that great at (quickly) meeting the unique needs of 3D rendering - thus the consumer GPU was born. When GPU's were originally created they came with severe limitations on what a graphics programmer could do. These limitations are commonly referred to as the "fixed function" rendering pipeline because its features were fixed in silicon - a programmer couldn't add any additional functionality. To access these fixed function graphics capabilities there originally were 3 major API's:
  1. 3dfx Glide
  2. OpenGL
  3. DirectX
DirectX and OpenGL are general abstractions that make it easy for a developer to access the capabilities of a GPU from any manufacturer. Glide was proprietary to GPU's produced by 3dfx as it was the heavyweight champion of its day until NVIDIA suddenly gobbled it up, killed Glide in favor of OpenGL, released the Geforce 256, and took over the world of graphics.

Back in those days OpenGL was awesome. In fact I first started teaching myself graphics programming in high school using OpenGL and NeHe's tutorials (still a great resource for beginners). DirectX, while still supported by all of the various GPU manufacturers, was widely considered laughable. This all changed with the revolution that was, and still is, the programmable pipeline.

Viva la revoluciĆ³n!

The root problem with OpenGL, its Achilles heel if you will, is the fact that it's designed by a committee called the Khronos Group. Open standards hippies think this is great and while there are certainly some really good reasons not to have everything controlled by a single, evil corporation there are also some serious problems. For example HTML5 is all the rage these days and all of the web hippies are out basking in the glorious death of Flash and Silverlight. The problem with this line of thinking is that it took an entire decade for HTML5 to come out. While I have no love for Flash if you've ever used Silverlight you know that it's super easy to use, has great tools, and it's fast. If you've ever had to code a website by hand then you know it's a complete and total nightmare for absolutely no good reason. You have to deal with all these different implementations of the HTML standard in all these different browsers and for some completely insane reason Javascript became the lingua franca for client-side scripting. The story of OpenGL and DirectX at this point follow a similar arc - except Microsoft won - with good reason.

A programmable pipeline in the context of a GPU means a programmer can write little programs, called shaders, that get executed directly on a GPU to ultimately control the color that is output for each individual pixel. When programmable GPU's were first released OpenGL 2.0 and DirectX 8 came out to let developers access these new features. DirectX 8 was a complete rewrite of the DirectX API however OpenGL 2.0, in order to maintain backwards compatibility, kept all the old cruft and stapled on some new programmable pipeline stuff - similar to how each version of HTML just staples more crap onto the previous version. Needless to say when it came to working with shaders the shiny new DirectX 8 was awesome and the not so shiny and not so new OpenGL 2.0 was... not. At that point the only reason to choose OpenGL over DirectX was the fact that OpenGL was supported on non-Microsoft platforms. Since at that time consoles all used proprietary rendering API's and Windows was by far the most dominant gaming platform this really didn't matter so everybody switched over to DirectX.

The only reason you should use OpenGL... for now... I hope...

Realistically I think if you ask any hardcore graphics programmer if he prefers DirectX or OpenGL he's probably going to tell you he wishes he didn't have to use either one. Ironically, with the maturation of the programmable pipeline due to compute shaders, 3d graphics is coming full circle and you can now write very complicated "shaders" that run entirely on a GPU - they don't even have to have anything to do with graphics. The ultimate goal for graphics programmers is to be able to write C/C++ code, or possibly even some other language someday, that seamlessly executes on both CPU's and GPU's and lets you pass pointers without any hassle. There will only be fixed function hardware for rasterization and maybe a few other things and that'll be it. Both DirectX and OpenGL currently get in the way of this process by forcing you to dance a complicated jig as you move data to/from the CPU and GPU. Addressing this problem is the whole reason AMD recently announced Mantle but I'll get to that in a minute.

The only reason you should use OpenGL today is the exact same reason you would use OpenGL over DirectX 10 years ago: you want to target non-Microsoft platforms. With the emergence of mobile, another thing I'll get to in a minute, this is not an insignificant reason to favor OpenGL however it comes with some rather severe costs which are the primary reasons why I hate working with OpenGL:

  1. Now that we're onto OpenGL 4.4 the API has had a whole extra 2.4 versions haphazardly stapled onto it since 2.0. You now have to deal with things like two completely different sets of functions to do the exact same thing, like enumerate uniform buffer objects, because one set of functions supports a single extra feature that the other doesn't for absolutely no good reason.
  2. You have swiss army knife functions. An example of this is resolving an MSAA render target. All you want to do is resolve the MSAA render target but you have to use a function that can do 100 different things and you're left trying to figure out what which combination of flags you need.
  3. Driver support on Windows, still a dominant gaming platform, isn't that great since everybody has been using DirectX
  4. DirectX has an awesome debug layer, OpenGL's debug context pales in comparison
  5. DirectX has awesome tools (awesome is a relative word here), OpenGL does not. Granted, OpenGL has recently made some improvements in this area but saying OpenGL now has good tools is like saying that you would rather get kicked in the balls than be shot. Both options really suck though one just happens to be slightly better than the other
  6. OpenGL documentation sucks. If there is one thing that Microsoft tends to do better than everybody else it's developer tools and API documentation
Lastly the OpenGL specification has, historically, been updated very slowly relative to DirectX though recently the Khronos group has improved on this front. OpenGL acquired support for compute shaders a year after DirectX and both AMD and Apple still haven't released fully compatible drivers. There is, however, one caveat. Recently Microsoft has made the unfortunate choice of restricting new versions of DirectX to new versions of Windows. This sucks because Windows 8 adoption is much slower than Windows 7 and the newer versions of DirectX 11 have some really nice features. There are also some rumors floating around that Microsoft might kill off DirectX and that is obviously a huge concern when deciding which API to go with.

Mantle & CUDA

Ultimately Mantle, which is an open specification like OpenGL, and CUDA are the reason I think OpenGL is doomed, or at least the reason OpenGL should be doomed unless the Khronos Group does something radical, and they're also the reason the API wars are so interesting right now. For those of you who don't know, at a high level a graphics driver primarily does 3 things: it manages memory and it creates then executes command buffers. The primary purpose of Mantle is to provide developers with a lightweight hardware abstraction layer so they have more control over those 3 things than DirectX and OpenGL currently allow. Basically it gets developers closer to how the hardware actually works while reducing OS and driver overhead. CUDA isn't actually a graphics API per se, it's a proprietary compute shader language/runtime that provides seamless integration with C/C++, however I don't think it would take much for NVIDIA to turn it into a direct competitor with Mantle which is why I mention it here.

The jury is still out on Mantle and I think a lot depends on how Intel and NVIDIA react. If AMD can convince one of them or one of the mobile manufacturers to include it on their platform that'd be a huge vote of confidence for Mantle being useful on something other than AMD hardware. The reason Mantle and CUDA are such a threat to OpenGL is because, as has already been mentioned, the Khronos Group is not very good at responding quickly to changes in the marketplace. Microsoft has established with DirectX 8 and DirectX 10 that it is not afraid to completely rewrite DirectX to better accommodate changes in the architecture of next-gen hardware. There is nothing to prevent Microsoft from creating a Mantle style API with DirectX 12 and porting it to older versions of Windows whereas the Khronos Group demonstrated the exact opposite when they failed to rewrite OpenGL in any meaningful way with version 3.0. If Mantle gains traction, and Microsoft rewrites DirectX with version 12 to meet that threat, what incentive remains to use OpenGL? An even more radical thought is what if Microsoft does in fact discontinue development of DirectX, as AMD has suggested it might, in favor of Mantle? That would certainly explain why AMD made such a bold statement. Either way if Mantle begins gaining serious traction it seems likely OpenGL will no longer be worth supporting.

OpenGL ES and WebGL

There isn't much to say about OpenGL ES that hasn't already been said about the regular desktop version of OpenGL. Basically I think the Khronos Group really screwed up with OpenGL 2.0+ and WebGL. Firstly I think they screwed up with WebGL because they gave it the same feature set as OpenGL ES 2.0 instead of the full desktop OpenGL. Secondly I think they screwed up OpenGL ES 2.0 because they had an opportunity to start with a clean slate and create something really forward looking for mobile, like say Mantle, and instead they just took desktop OpenGL 2.0 and made it slightly more sane. Sure, there are some good reasons for that since plenty of people already have experience working with desktop OpenGL, but if Mantle or perhaps an NVIDIA competitor gets any traction in mobile then I can't think of any good reason as a developer to continue to use OpenGL ES.

In Closing

I've decided to leave out discussing SteamOS because I think that could be a blog of its own and this one is already way too long. Ultimately, regardless of what happens to OpenGL, I think 2014 is going to be an exciting year for computer graphics and high end gaming in general. New consoles, new API's, and ever more powerful PC hardware. The best part, if you're a consumer, is you don't have to worry about any of this API jazz. Us developer types shall wage holy war upon each other and once we get comfortable with these new API's and hardware capabilities consumers are going to have some great games to play!

6 comments:

  1. This comment has been removed by the author.

    ReplyDelete
  2. Can't edit my comment so had to delete it and rewrite it.

    The Khronos Group didn't enter the picture until 2006 after which iterations on OpenGL started to accelerate and now are released yearly. Before Khronos took control from .. the ARB group I think? .. the time between released was huge and this was the period where DirectX took the crown from OpenGL. Since Khronos took control OpenGL has gained on DirectX again and released things such as WebGL and GL ES, increasing the relevancy of OpenGL again to the point where people are thinking about using it once more. So Khronos is actually doing a good job (from a market point of view at least). Yes Khronos likes to keep backwards compatibility around .. mostly because of Nvidia as far as I understand, who doesn't want to let go of their investment in their OpenGL driver. They also made some mistakes over the years in the API which they're trying to retro-actively change with new versions and new entry-points. I think their iterations are actually improving over time, but their insistence of keeping backwards compatibility doesn't help. As for Khronos not being able to respond quickly? I don't know, I think they'll be able to respond relatively quickly (it does take time to write API's after all) ... they'd probably write new API entry-points / extensions to get the same functionality as Mantle does instead of rewriting OpenGL .. and of course OpenGL already has fewer issues with draw-calls than directX does ..
    Regardless it should be interesting what will happen, Mantle looks very interesting .. but vendors starting to each release their own API's will not be a good thing for developers. So either Nvidia & intel will need to "join forces" in the design of Mantle (which, unfortunately, I don't see happening because of company politics) or Mantle will be left as a footnote in history, hopefully a stepping stone to another new API which would be supported by all parties.

    ReplyDelete
    Replies
    1. The Khronos Group was founded in 2000 (http://en.wikipedia.org/wiki/Khronos_Group) and my impression is basically the ARB just changed its name and became a non-profit - perhaps that's wrong. OpenGL has only caught up to D3D11, in terms of the specification, within the last year or two. In terms of driver support it still has a *long* way to go. I agree that the Khronos group, since ~2011, has been doing a much better job updating the API however that has still mostly been playing catch-up to DirectX. I also totally agree that as a developer life is going to be a lot more complicated if all of the IHV's start releasing their own API's. That's why I hope Mantle will be successful in unseating OpenGL but I'm really quite skeptical Intel and NVIDIA will hop on board for the same reasons you mention.

      Delete
  3. I don't want OpenGL to "go away". It's currently the only option that works across such a wide range of platforms. It's has problems certainly, and I'll happily lament the missed opportunity to throw large chunks of it away that they passed up with you.

    A replacement simply isn't going to emerge though. Practically anyway. For a while I hoped that there was a chance we might see DirectX implemented on other platforms but MS would never allow the official IGPs to actually write drivers for it.

    Mantle will be another also-ran. No-one I know is using it on console, and no-one is on PC except as an afterthought or experiment to test the waters. Neither Intel nor nVidia will implement it especially as everything I've read about it suggests that it's slightly biased towards the way AMDs GPU operate.
    This is the same reason that Intel and AMD won't implement CUDA for example.

    My real hope is that we get our desired next-gen API thanks to Valve and SteamOS finally forcing improvements to both the drivers and OpenGL APIs.

    Otherwise what we might see is Intel and nVidia releasing their own custom Matnle-alike thin wrapper and then we'll all be writing the same code 3 to 5 times over to support all of the old cards that use DirectX & OpenGL, plus AMDs Mantle, Intels-bodge-can't-be-bothered-with-gfx-LOL, and nVidia-super-fast-but-oh-god-I've-just-lost-my-whole-leg! :)

    By that point the idea of DirectX + DirectCompute & OpenGL + OpenCL / CUDA will lovely positively pleasant :)

    ReplyDelete
    Replies
    1. I think the only reason OpenGL would die would be if it was supplanted by something with equally ubiquitous support but better features. Lots of proprietary systems wouldn't emerge to take its place for exactly the reasons you mention - we're lazy and we don't want to write multiple versions of code to support multiple APIs.

      Delete
  4. I found that site very usefull and this survey is very cirious, I ' ve never seen a blog that demand a survey for this actions, very curious... https://pcreviewer.org

    ReplyDelete