It's going to be around for the next few years while Vulkan ramps up and develops an ecosystem.
#Vulkan vs opengl 4.5 software
With these experiences from real developers, they convinced me that programming against Vulkan is viable even for a beginner in graphics, and that the overall complexity is less once you get past the tutorial and starting building demos or applications you can give to other people.Īs others have said: GL is available on many platforms, WebGL is a nice delivery mechanism, there's a lot of existing software that uses GL, and there are many employers hiring for that skill. But after getting to that stage, they found it much easier to build up to a real, shippable application, because (a) the behaviour is a lot more predictable between different vendors' implementations, and (b) getting to something that performed well with all the effects turned on didn't involve as much trial-and-error. getting to having one triangle on the screen) involved learning more concepts and having longer boilerplate code, but it wasn't too complex, even for the indies. Their experience was that getting started (i.e. These people range from developers at Epic working on UE4 integration to hobbyist game developers. I posed this question to some members of the Working Group, and they said they have some data points from people they've spoken to who've already moved to Vulkan. I was concerned at first that Vulkan is much harder to program against, and that while it would be OK for the experienced developers at larger companies, it would be a huge barrier to indies and hobbyists.
#Vulkan vs opengl 4.5 code
If you have code that works in GL or GLES, you almost have to start again to make it work efficiently in Vulkan: especially if it was written in a legacy style (see point 1). If you have some code that works in Vulkan, it's quite easy to port that to GL or GLES instead, and you end up with something that uses good GL/GLES habits.
#Vulkan vs opengl 4.5 driver
It pushes a lot of complexity up from the driver to the application: but by doing so, it gives control to the application, and makes it simpler to get predictable performance and compatibility between different GPU vendors.
Vulkan makes explicit a lot of things that were hidden or unpredictable in GL, such as concurrency control, sharing, and rendering state.
It's much easier to move from Vulkan to GL or GLES than vice-versa. It's hard for GL programmers to find out what is no longer encouraged. I see lots of people who've started with GL or GLES and immediately get into bad habits like issuing separate draw calls per-object instead of using VBOs, or even worse, using display lists. Vulkan offers programming models that are much closer to how contemporary GPUs work, so if you learn Vulkan, you'll have a better understanding of how the technology really works, and of what is efficient and what is inefficient. (The most obvious difference being immediate-mode draw calls vs tiling and command queues.) GL encourages you to think in an immediate-mode style, and has a lot of legacy cruft. GL and GLES were designed many years ago, when GPUs worked quite differently. Maybe you should learn GL later too, but there are a couple of reasons to think Vulkan-first. If you're getting started now, and you want to do GPU work (as opposed to always using a game engine such as Unity), you should definitely start by learning Vulkan. Specialization is rarely an efficient paradigm. Specializing in Vulkan only limits your options. An indie dev is even more dependent on flexibility and being able to choose what works, over what's getting funded. Specialization is rarely a marketable skill.įor those who don't need to market their skills as such, like indie developers, it'd be even MORE foolish to remove a tool from their toolbox. It's entirely possible that a company would choose OpenGL over Vulkan, especially this early in the game, and that company would not be interested in someone who doesn't know OpenGL, regardless of whether they know Vulkan or not. Additionally, OpenGL does different things differently. This seems a lot like asking "Should new programmers learn C++ instead of C," or "Should new artists be learning digital painting instead of physical painting."Įspecially because it's NOT backward compatible, graphics programmers would be foolish to exclude the most common graphics API in the industry, simply because there's a new one.