Today I’ve made a substantial update to one of my open source libraries, “Math3D”, and I’ve changed one of my internal libraries, “GLTools”, on GitHub from private to public, and made it open source as well (technically it always was open source, just this repo was private). Both libraries are published under the MIT license, and are free to use in both free and commercial software. GLTools is a toolkit for OpenGL, and in its current form it has been updated specifically to support OpenGL ES 3.x (or desktop OpenGL 4.x). Math3D was originally more focused on OpenGL, but it has since been made more agnostic and can be used with OpenGL or Vulkan either one. Some of the classes in the original GLTools also were really math classes and have been moved over to Math3D instead. There are other fine math and utilities libraries available, there’s nothing special about mine in particular other than their history and my intimate knowledge of them tends to make me prefer them for productivity’s sake when working on my own projects. We all know the adage, choose the best tool for the job, and often the best tool is the one you already know.
Both of these libraries go back to the days of the OpenGL SuperBible, and the OpenGL class I taught for 15 years at Full Sail University near Orlando Florida. (OpenGL is a software interface that programmers use to create interactive 3D renderings like you see in computer games). That class saw a lot of evolution over 15 years from the fixed function pipeline, to shaders, and at the end it was mostly focused on OpenGL ES, which at the time was still popular for games on mobile platforms.
Much has changed, both in the industry and in my own work. For a while I was a full-time astronomy software developer working under contract for Software Bisque mostly, and fiddling with my own stuff occasionally. All of this work was OpenGL based as far as any graphics related work was concerned. Now, I’m working full time at LunarG, but still fiddling with my own astronomy stuff on the side, and doing some casual consulting for other astronomy software vendors.
My job at LunarG brings some gravity on what I’m about to say I think. I work directly on the Vulkan SDK, mostly the macOS/iOS versions. For my astronomy friends who are “Muggles” in the world of computers who are reading this, let me spell it out. I used to be an OpenGL “expert”, and now I work directly on “Vulkan”, which is widely seen as the successor to OpenGL. I’ve drank the “Vulkan Kool-Aide”, and I’m a big fan. That said, it has its place, but it’s not always the very best tool for every task.
And here’s my thesis for today. OpenGL is not dead, and it’s a long way from dead. Specifically, though, I really mean OpenGL ES, and to put an even finer point on it, OpenGL ES 3.x. There are two main arguments that support this point.
First is that advanced 3D computer games or high-end visualization most certainly should be done with Vulkan. Anything that needs a lot of GPU compute horsepower, does hardware accelerated ray tracing, etc. The truth is however, that although “games rule the world”, there are a great number of technical applications or more casual 3D rendering domains that just don’t need Vulkan. I recently saw a presentation where a team ported a sophisticated game from OpenGL to Vulkan and got a whopping 3 fps increase in rendering performance. They were very proud too. This was a fairly complex game, and it struggled to begin with. They were doing about 45 frames per second with a native OpenGL driver, and got 48 fps with the Vulkan port. Okay… At first, I was a bit underwhelmed, but if you consider the complexity of what they were rendering, Vulkan is A LOT faster than OpenGL for very complex graphics tasks. Never-the-less, if a less intense game was already running at 60fps (basically drawing as fast as the screen can refresh itself), what would be the point of making the effort? Clearly Vulkan is well suited for cutting edge stuff, and a better choice than OpenGL. (Demonstrating an extended battery life would really have to be clearly demonstrated and not assumed).
My wife loves casual games, and she plays them on her iPad daily, and I watch occasionally as she explains the puzzles or tasks at hand. Absolutely nothing she’s showed me would benefit from being ported to Vulkan over if they were written in OpenGL ES 3.x. If a consultant or engineer insists on porting an engine or game from OpenGL ES to Vulkan and it’s already getting 60fps, I would seriously question their motives.
Second, OpenGL ES is not going away. Yes, you’ve heard all the major vendors are not going to make OpenGL drivers any longer, and are focusing on Vulkan. This is true. However, there are many projects that are mature today, and more in development that will layer what is arguably now, a high-level API such as OpenGL ES 3 on top of a low level, high performance API such as Vulkan. There’s way too much legacy code and applications that need to run for years to come. There are also 3D technologies that are becoming standard for web browsers to make it easier to develop 3D accelerated web-based games and other applications, and they are all based on OpenGL ES 3, and are often layered ON TOP of Vulkan. OpenGL ES 3 layered on Vulkan makes a lot of sense for a huge number of applications, and this even includes many games, I think. On macOS, Vulkan itself is actually layered on top of Apple’s Metal API, and there are OpenGL ES libraries that run on top of Metal, and yes, we could see apps running with OpenGL ES, that is layered over Vulkan, that is layered on Metal. What does this do to performance? Well, if you are doing VR or AR, or a detailed immersive 3D game, you may take a hit performance wise. But if you are drawing pie charts, bouncing bunnies, or constellation outlines, it probably won’t matter a bit.
When it comes to performance, engineers love to obsess. One of our favorite pastimes is to compare performance of sorting algorithms. The bubble sort is probably the worst sorting algorithm in terms of performance, but it’s simple, and I can even code it by hand from memory. It’s great to teach to students who are just learning to program. Most seasoned developers would die rather than use a bubble sort in production code. The truth is however, if you only have 10 items to sort, it really doesn’t matter which sorting algorithm you use (and please spare me some convoluted example where you need to sort 10 items, 500,000 times a second… you are missing the point).
“So, what about your astronomy work Richard?”. Well, case in point. An astronomy software vendor recently asked me to take a look at their OpenGL ES code. It’s mostly OpenGL ES 2.0 with some 3.0 mixed in. It could certainly stand a little modernization and update, but it would be creating work for no reason for me to advise them to rewrite the whole engine with Vulkan. It’s already smooth and beautiful, and even with some new “gee wiz” things we are talking about adding, there’s absolutely no justification for moving to Vulkan right now. Should the time come that Apple removes OpenGL entirely for example, there’s plenty of solutions to layer OpenGL on top of Metal or Vulkan ourselves and it will be 1/100th the work of moving entirely to Vulkan. Vulkan is the new King of Android too you might point out, and yes, there’s also ways to layer OpenGL ES 3 on Vulkan for Android too (and Google is investing heavily in this). When it comes to product development, part of your job is to evaluate tradeoffs, and get a product to market in a timely fashion. Yes, there will be minimum performance criteria, but don’t use a cannon to kill a mosquito.
“Oh, but I LOVE Cannons… and they make such great noise, and… and…BOOM!”. This is why many engineering teams need some adult supervision in the form of a product manager. Engineers love their work, and given the chance will create more work for themselves, to the detriment of the product schedule.
As for my own astronomy projects, I have two. One is code named BTS, and the other TSA. BTS has been around for more than two decades, and dates back to when my S-Corp was making weather software. I re-started it with a dual rendering backend post Software Bisque, and then decided to ditch OpenGL and focus on Vulkan as I was making progress on OpenGL way faster than Vulkan and part of my motivation was to get up to speed more on Vulkan when I started. I’m not sure that wasn’t a mistake and I think I’m going to go back to OpenGL just for productivity’s sake. (Now I’m the engineer creating work for himself). Vulkan will outperform OpenGL, but the OpenGL renderer is already at 90+fps, and frankly, the code is simpler, and I can get things done faster (as in writing code late at night) with OpenGL than Vulkan. That matters when you only have a precious few hours every week to spend on a project. Hmmm… thinking about it now, if I took a week off work, I could probably have the OpenGL version on the app store, as I use the OpenGL version myself all the time… it’s already a useful observing tool.
TSA on the other hand… this is the project that is getting most of my time right now, and it all but demands that I use Vulkan. I’m hoping to deliver an almost magical experience with this astronomy-imaging application, and it requires every ounce of GPU horsepower I can muster, and it requires a great deal of bandwidth and careful synchronization between the GPU and CPU pipelines. I’d be a fool to try and attempt what I’m trying to do with OpenGL. Well, maybe not a fool, but it’s a simple task that I need to run very very fast, and Vulkan is clearly the right tool for the job.
Time will tell, and we’ll see how this blog ages in a few years. In the meantime, I have code to write….