Well, mine anyway!
Well, it’s been a year and a half since I blogged about OpenGL and Vulkan, and it’s time to check in about how that blog has aged. A year and a half later, I’ve done a lot more work on my three ongoing astronomy projects, and my experience has not changed my mind on the topic. The main thesis that remains is thus:
- If don’t want to learn a 3D graphics API, then just use a high-level toolkit or gaming framework. These are built on lower-level API’s and pick one that is portable if you want to deploy on multiple devices or operating systems. I’m a huge Qt fan for example, and Qt3D does a lot of “neat” things for 3D applications and simple games even. There’s no shortage of frameworks with a more gaming centered focus either. Go get one.
- If you don’t like TV dinners (metaphorically) and want lower-level control, OpenGL is still a viable graphics API. If you want to throw around textured triangles, and write shaders, you can get a lot done here, and still be productive. OpenGL/OpenGL ES/WebGL are going to be around a long time and will likely be implemented on top of other more modern graphics API’s for years to come. That said, I’d stick to OpenGL ES really for new projects. Maybe even better… WebGPU. I’ll get back to that.
- There’s a whole other level of GPU control waiting for you with Vulkan. This is the ultimate low level graphics API. It’s modern, and GPU vendors are pushing this API forward. Vulkan is scalable, portable, has better multi-threaded capabilities and has complex task synchronization built right in. Compute is also part of the API, no mixing and matching or complex buffer sharing gymnastics required.
It’s forgivable to think that Vulkan is the successor to OpenGL, as OpenGL came first, Vulkan came along, and OpenGL seems… well, old and abandoned. I think this is wrong. It’s like saying that C++ is the successor to Python. Two programming languages for different kinds of tasks and needs. So too, OpenGL and Vulkan are two different graphics API’s and should be selected based on your project’s goals. OpenGL is faster to learn, easier to use, and far more productive when it comes to prototyping and proofing new code in my own experience.
OpenGL however has a problem — There will never be an OpenGL 5.0. Opinions vary wildly, but my hot take is that OpenGL just isn’t new and hot, and engineers love new and hot technologies. Moving OpenGL forward would also require a serious make over in a 5.0 incarnation, and we’d have to leave some things behind. Alas, in technology, just like nature, sometimes the forest has to burn to the ground in order to make something new.
There is a need for something higher level than Vulkan in my opinion, and I’m not alone. Something between the constraints of a fixed game engine or toolkit, but higher level than what is arguably nearly a device driver level graphics API. OpenGL can fill this role, but not forever. I think the real successor to OpenGL may just be WebGPU. I’ve worked on three somewhat large legacy astronomy projects that are OpenGL/ES based, and one has a big WebGL component. None of those projects are never going to need Vulkan, but WebGPU for the web interface, and Dawn (the C++ part of WebGPU) for the desktop/device code could be a good fit moving forward. WebGPU however is still quite young but is gaining momentum. The day may come but is not yet here where I’d bet the farm on WebGPU.
So, all of this said, how about an update on my own astro-software projects. I still have the same three projects in various states of gestation. The one eating most of my weekend mornings and a few late nights is “SmartEye”. This project is running on an embedded computer and I’m using Vulkan exclusively. I’m sharing buffers between the CPU, compute shaders, and rendering pipelines. Vulkan is absolutely the right choice for this. I’m even writing the code on a desktop OS (macOS actually using MoltenVK) and then rebuilding and debugging on the device (under Linux). This is working great for me. We hope to be shipping SmartEye first quarter of next year too, so that’s exciting.
The other two projects are in crockpot slow cooker mode until SmartEye gets out. TSA was “announced” at NEAF/NEAIC earlier this year and is on the back burner for SmartEye, although there are a few beta testers using this imaging application regularly. TSA is also all Vulkan, and a good bit of TSA has ended up migrating to SmartEye. Synergy! For the same reasons mentioned earlier Vulkan is a better choice, mostly because I’m blending compute and graphics together, and trying to do some fancy stuff to make things as fast as theoretically possible as this will be a performance-based product eventually.
Finally, BTS… my labor of love for almost 25 years. This app is really a playground that I hope to share with the world before much longer. When I’m burned out and don’t feel like working on anything else, I work on BTS. Oh, BTS stands for “Big Textured Sphere”. BTS has two rendering backends, OpenGL and Vulkan, and I’ve started to toy with adding Dawn/WebGPU. It told you it was a playground. One must have structure for productive play and self-study 😉
In short. Stop thinking Vulkan is the successor to OpenGL. If anything, I think WebGPU is the more likely “successor”. Vulkan is like assembly language, and OpenGL is more like a nice friendly C++ application framework (metaphorically – or use C/Python if that makes you happier). There are a lot of libraries that make Vulkan easier to use as well, just like OpenGL, and in fact I will probably be talking about my own Vulkan helper library in my next blog — “Vulkan Building Blocks.”