No offense to my ‘weekend on boat’ friends<g>!
My journey into Vulkan continues. In my last blog (has it really been a YEAR?) I talked about how OpenGL (ES) might just live forever, and it might just be the “higher level easier to use API” most people need who aren’t doing severely performance critical things. I mean… if you want 3D pie charts, or even straight forward data visualization… well, let’s face it, even a lot of games can perfectly well be done with OpenGL and don’t require the extra control and performance edge that Vulkan provides. OpenGL ES is also EVERY FREAKING WHERE (including the web), so it clearly meets any cross platform needs as well. Moreover, the OpenGL layered on Vulkan technologies are still getting better and more pervasive. So… I still think some new projects might well be just fine using OpenGL, and old legacy OpenGL projects do not necessarily need to start porting to Vulkan ASAP. That’s the advice I’m giving to one of my clients in the astronomy software business as well. I’m sure readers will recognize too that there is an abundance of high-level toolkits for both OpenGL and Vulkan that will meet a lot of needs. They are like Python maybe, where OpenGL is C++, and Vulkan is hand optimized assembler (I sometimes can’t help myself with analogies).
How does this reflect in my own work? Well, as one of the Vulkan SDK curators at LunarG, it’s my job to be fluent in Vulkan. Being an SDK expert, means I have a better than average understanding of the Vulkan Loader, how the layers work, and how to get Vulkan up and going on most platforms, etc. I’m also one chat box away from people who are far smarter than me when it comes to these details. Let’s face it though, creating an animated ball bouncing around is another kind of skill set though. I did work on a Vulkan “application” (as opposed to tools) at LunarG for a client, but it was mostly a framework that someone else got up and going, and my job was 90% just doing some fancy 3D math, and refactoring existing code a bit. It has taken me a while to become “competent” with Vulkan as an “application developer” since then.
Now by competent, I do mean in my own eyes. I still don’t know if I will ever be as all powerful as I feel when doing OpenGL (it’s a high bar considering how long I did OpenGL primarily… um… since version 1.0), but I’m no longer intimidated by Vulkan, and have now… my THIRD iteration of a Vulkan framework(third times the charm!) up and going which allows me to pretty quickly get any rendering project up and going. I’m calling this framework “Vulkan Building Blocks”, and it will be open source in the near future when I’m done cleaning it up. Making bouncing balls or some such is now something I can accomplish pretty quickly on macOS, Windows, Linux, or iOS. Yay! Android will come in time, sure. I have done OpenGL on Android and I’ll get there with modern Vulkan, but man it’s time consuming to get the tools going reliably.
So, about that astronomy stuff. There’s a saying in technology circles, “Eat your own dog food”. So, you’re making a tool? Are you willing to use the tool yourself? (and tool here is Vulkan and the Vulkan SDK). Why yes, yes I am. My side-gig is consulting and product development in the amateur (and occasionally professional) astronomy community. I have three projects that continually get trickle time. One, possibly two of them I’ll likely not finish (is anything ever finished?) until retirement, but I love them the way some people love to wax their sports cars on a sunny Saturday morning. Only one of which is publicly available but languishing for time from me. It is a “Lucky Imaging” app (TSA). This is a kind of astronomical imaging used for high resolution images of the Sun, Moon, and Planets. A high-speed camera is used to capture thousands of frames that are later scrubbed for “very still and clear” images free of atmospheric turbulence. I recently gave a one-hour lecture on this at a conference, so forgive me that I just can’t really do the topic complete justice here. There’s an old blog here that might help though.
This particular application controls a high-speed camera displaying images on the screen, and Vulkan compute doing work along the way and as a part of post processing. This is the goal, and it’s in open beta for macOS now as it does have at least enough features to be marginally useful to someone other than myself now.
What’s eating up the late nights my wife allows, and my weekend mornings is another product I’m helping with that is being produced and marketed by Simulation Curriculum (the makers of Sky Safari) and Pegasus Astro. It’s basically a telescope eyepiece that uses a camera to integrate light over a long period of time and create… <pretty picture of space things> as time passes that is displayed on an internal screen – just like an eyepiece would normally work – it’s just a much brighter and detailed image than you get with your naked eye. It’s pretty hot if you ask me, but I digress. There’s a tiny, embedded computer inside, with a GPU that is far more powerful than the CPUs, and yes, it’s Vulkan powered. There are indeed things I’m doing with Vulkan that just can’t be done with OpenGL, or can’t be done easily. The GPU is also wildly, unimaginably, faster than the CPU for image manipulation tasks. Mobile or embedded apps that have heavy lifting to do, absolutely should be taking a hard look at Vulkan.
There’s no amount of getting stuck that will make me quit and go back to OpenGL for either of these two projects, Vulkan really is the definitive winner here. As that little man everyone liked in that one TV show everyone liked said…
I have spoken.