Computer Graphics Stack Exchange is a question and answer site for computer graphics researchers and programmers. It only takes a minute to sign up.
Sign up to join this community
From the wiki: "the Vulkan API was initially referred to as the 'next generation OpenGL initiative' by Khrono", and that it is "a grounds-up redesign effort to unify OpenGL and OpenGL ES into one common API that will not be backwards compatible with existing OpenGL versions".
So should those now getting into graphics programming be better served to learn Vulkan instead of OpenGL? It seem they will serve the same purpose.
Hardly!
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."
Especially 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. Additionally, OpenGL does different things differently. 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.
Specialization is rarely a marketable skill.
For 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. An indie dev is even more dependent on flexibility and being able to choose what works, over what's getting funded. Specializing in Vulkan only limits your options.
Specialization is rarely an efficient paradigm.
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. Maybe you should learn GL later too, but there are a couple of reasons to think Vulkan-first.
GL and GLES were designed many years ago, when GPUs worked quite differently. (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. 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. 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. It's hard for GL programmers to find out what is no longer encouraged.
It's much easier to move from Vulkan to GL or GLES than vice-versa. Vulkan makes explicit a lot of things that were hidden or unpredictable in GL, such as concurrency control, sharing, and rendering state. 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. 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. 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).
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. 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. These people range from developers at Epic working on UE4 integration to hobbyist game developers. Their experience was that getting started (i.e. 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. 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. 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.
As 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. It's going to be around for the next few years while Vulkan ramps up and develops an ecosystem. For these reasons, you'd be foolish to rule out learning GL entirely. Even so, you'll have a much easier time with it, and become a better GL programmer (and a better GPU programmer in general), if you start off with something that helps you to understand the GPU, instead of understanding how they worked 20 years ago.
Of course, there's one option more. I don't know whether this is relevant to you in particular, but I feel I should say it for the other visitors anyway.
To be an indie games developer, or a game designer, or to make VR experiences, you don't need to learn Vulkan or GL. Many people get started with a games engine (Unity or UE4 are popular at the moment). Using an engine like that will let you focus on the experience you want to create, instead of the technology behind it. It will hide the differences between GL and Vulkan from you, and you don't need to worry about which is supported on your platform. It'll let you learn about 3D co-ordinates, transforms, lighting, and animation without having to deal with all the gritty details at once. Some game or VR studios only work in an engine, and they don't have a full-time GL expert at all. Even in larger studios which write their own engines, the people who do the graphics programming are a minority, and most of the developers work on higher-level code.
Learning about the details of how to interact with a GPU is certainly a useful skill, and one that many employers will value, but you shouldn't feel like you have to learn that to get into 3D programming; and even if you know it, it won't necessarily be something you use every day.
Learning graphics programming is about more than just learning APIs. It's about learning how graphics works. Vertex transformations, lighting models, shadow techniques, texture mapping, deferred rendering, and so forth. These have absolutely nothing to do with the API you use to implement them.
So the question is this: do you want to learn how to use an API? Or do you want to learn graphics?
In order to do stuff with hardware-accelerated graphics, you have to learn how to use an API to access that hardware. But once you have the ability to interface with the system, your graphics learning stops focusing on what the API does for you and instead focuses on graphics concepts. Lighting, shadows, bump-mapping, etc.
If your goal is to learn graphics concepts, the time you're spending with the API is time you're not spending learning graphics concepts. How to compile shaders has nothing to do with graphics. Nor does how to send them uniforms, how to upload vertex data into buffers, etc. These are tools, and important tools for doing graphics work.
But they aren't actually graphics concepts. They are a means to an end.
It takes a lot of work and learning with Vulkan before you can reach the point where you're ready to start learning graphics concepts. Passing data to shaders requires explicit memory management and explicit synchronization of access. And so forth.
By contrast, getting to that point with OpenGL requires less work. And yes, I'm talking about modern, shader-based core-profile OpenGL.
Just compare what it takes to do something as simple as clearing the screen. In Vulkan, this requires at least some understanding of a large number of concepts: command buffers, device queues, memory objects, images, and the various WSI constructs.
In OpenGL... it's three functions: glClearColor, glClear, and the platform-specific swap buffers call. If you're using more modern OpenGL, you can get it down to two: glClearBufferuiv and swap buffers. You don't need to know what a framebuffer is or where its image comes from. You clear it and swap buffers.
Because OpenGL hides a lot from you, it takes a lot less effort to get to the point where you're actually learning graphics as opposed to learning the interface to graphics hardware.
Furthermore, OpenGL is a (relatively) safe API. It will issue errors when you do something wrong, usually. Vulkan is not. While there are debugging layers that you can use to help, the core Vulkan API will tell you almost nothing unless there is a hardware fault. If you do something wrong, you can get garbage rendering or crash the GPU.
Coupled with Vulkan's complexity, it becomes very easy to accidentally do the wrong thing. Forgetting to set a texture to the right layout may work under one implementation, but not another. Forgetting a sychronization point may work sometimes, but then suddenly fail for seemingly no reason. And so forth.
All that being said, there are two caveats to be pointed out here.
First, the above is true but only for the time being. Now that a few years have passed since command-buffer APIs have come into being, hardware vendors are starting to develop important graphical features that fundamentally cannot work under OpenGL.
Ray tracing is the prime example here. It requires such a fundamentally different rendering structure that OpenGL just has no way to handle it. This isn't like mesh shaders, where you replace the vertex processing pipeline with a different one. Here, you absolutely need to be able to access any texture/buffer at any time for any reason. And while you kind of can do that in OpenGL with bindless textures and a few other extensions, it ultimately becomes too complicated to make work with the structure of OpenGL.
But Vulkan's command-buffer based API handles it just fine.
As time goes on, more and more graphical features like this will exist. Features which are inherently incompatible with OpenGL-like APIs. So for the time being, OpenGL and Vulkan have transferable graphical concepts, this will become increasingly less true as time goes on. New features will be added to Vulkan and not OpenGL, not because OpenGL is old, but because it just can't work well with those features.
Second, there is more to learning graphics than learning graphical techniques. There's one area in particular where Vulkan wins.
Graphical performance.
Being a 3D graphics programmer usually requires some idea of how to optimize your code. And it is here where OpenGL's hiding of information and doing things behind your back becomes a problem.
The OpenGL memory model is synchronous. The implementation is allowed to issue commands asynchronously so long as the user cannot tell the difference. So if you render to some image, then try to read from it, the implementation must issue an explicit synchronization event between these two tasks.
But in order to achieve performance in OpenGL, you have to know that implementations do this, so that you can avoid it. You have to realize where the implementation is secretly issuing synchronization events, and then rewrite your code to avoid them as much as possible. But the API itself doesn't make this obvious; you have to have gained this knowledge from somewhere.
With Vulkan... you are the one who has to issue those synchronization events. Therefore, you must be aware of the fact that the hardware does not execute commands synchronously. You must know when you need to issue those events, and therefore you must be aware that they will probably slow your program down. So you do everything you can to avoid them.
An explicit API like Vulkan forces you to make these kinds of performance decisions. And therefore, if you learn the Vulkan API, you already have a good idea about what things are going to be slow and what things are going to be fast.
If you have to do some framebuffer work that forces you to create a new renderpass... odds are good that this will be slower than if you could fit it into a separate subpass of a renderpass. That doesn't mean you can't do that, but the API tells you up front that it could cause a performance problem.
In OpenGL, the API basically invites you to change your framebuffer attachments willy-nilly. There's no guidance on which changes will be fast or slow.
So in that case, learning Vulkan can help you better learn about how to make graphics faster. And it will certainly help you reduce CPU overhead.
It'll still take much longer before you can get to the point where you can learn graphical rendering techniques.
The primary appeal of OpenGL (at least to me) is that it works on many platforms. Currently, Vulkan does not work on OSX, and Apple has a competing API called Metal. It's very possible that it will be some time before Apple supports Vulkan, and when they do, Vulkan support may only come to their latest hardware. OpenGL already supports most hardware, and will continue to do so.
I would like to give you my graphics beginner perspective on the subject. What I realised (in many years working as an engineer in another field) is that the fundamental concepts are the most important part. Once you have a solid understanding of those, learning the last shiny new API is the least difficult part. I don't know if you are a young hobbiest trying to program the new Skyrim or if you are looking for a job in the CG field.
I tell you what I think it's the best approach in my opinion to learn computer graphics "like a pro".
Starting to worry about performance before understanding how to draw a line is like worrying about the aerodynamics of your car before getting the driving license.
It depends on what you want to do. If you want to learn graphics programming only for yourself, it really doesn't matter what you choose.
If you are thinking about professional work I recommend Vulkan. It is closer to hardware and I think knowledge about what hardware do is important for graphics programmers.
Vulkan is closer to hardware because OpenGL does a lot of stuff under the hood which in Vulkan you do manually, like execute command queue.
Also memory management is up to application not driver. You need to worry about allocate memory for uniforms(variable that you pass from CPU to GPU), about tracking them. You have more things to worry about but also it gives more freedom on usage of memory.
It can sound scary and overwhelming but it really isn't. It's only next API that you need to learn.
Understanding this things also will help in understanding how GPU work. What will allow you to do some optimization both on Vulkan and OpenGL.
And one more thing that come to my mind, if you are starting to learn graphics programming probably when you look for a job as one Vulkan will be more popular (maybe more popular than OpenGL). Also, as far as I know most of companies that are using some graphics API write own functions around it so there is a chance that on the job you will not be writing in OpenGL nor in Vulkan but knowledge about GPU will be always useful.
I've been "getting in to" graphics programming for a few months now.
Right now I'm still in High School, and I can tell you I am almost always looking to develop cross platform applications. This is in fact my number one problem with Vulkan - It isn't developed to work on all platforms. I work with OpenGL in Java and have for over 6 months.
Another problem I have is with Vulkan's claims is how it claims to be better. While OpenGL certainly isn't updating their website very often. They continue to constantly release updates and I always look forward to new updates that run faster or work better with new hardware.
That being said, while I mostly work with OpenGL I understand basic principles of DirectX and Vulkan. While I don't work with them extensively, especially Vulkan as it's very hard to learn and not as well structured for programming as OpenGl and DirectX.
Lastly, I'd like to add that specializing in a single field like I mostly use Java and OpenGL isn't amazingly marketable standalone. If I wanted to get a job at a company that made games, for the most part OpenGL would only be used to make games for Linux and Android development and possibly OSX. DirectX for Windows and Consoles < Which Vulkan can replace in some cases.
I can't hold out for OpenGL updates forever, and I wont. But it's my preference for developing.
I'm self taught in C++ without any formal education and throughout the past 15 years I've learned both OpenGL 1.0 up through Modern OpenGL and DirectX 9c, 10 and 11. I have not gotten into DirectX 12 and I've been wanting to try my hand at Vulkan. I have only completed a few basic tutorials to draw a simple triangle or a simple spinning cube with Vulkan. As with DirectX 11 and OpenGL 3.3+ I have written fully working 3D Game Engines and even used them Engines to build simple games.
I would have to say that it depends on the overall environment of the person who is learning. If you are just getting into 3D Graphics Programming I would say for starters to jump into OpenGL or DirectX 11 since there is plenty of tutorials, resources, examples and already working applications out there. Learning 3D Graphics is by no means an easy subject.
If we abstract away from the programming aspect of it and just focus on the notion of what kind of techniques are used involving the different levels of math leading into data sets and data structures and algorithms; there is a lot that you have to know and understand first before you can even try to build a 3D Game Engine or to use an existing one effectively.
Now if you already understand all of the math and theory behind it and you have some programming experience you can use already existing APIs, Libraries and Applications such as Unity or Unreal Engine and just write the source code and scripts you need to make your application work.
So from my own understanding and the way that I see it is this if you are looking to build a quick game just for the sake of building a game; go with already existing frame works that would make your production time much smaller. On the other hand, if you want to understand the inner workings of how Game Engines / Physics Engines / Animation Engines and Simulators are designed and want to build one yourself, then this is where you have a choice between choosing your API such as DirectX, OpenGL or Vulkan. One of the determining factors here would also be your existing programming knowledge. What I mean by this is if you don't know anything about multi-threading, synchronous vs asynchronous calls, memory fences, data races, semaphores, and parallelism (parallel programming), then I would suggest to stay away from Vulkan and stick with either DirectX 11 or OpenGL versions 3.3 - 4.x.
I mention this because if you don't know how to properly manage your memory along with your threads and access time; Vulkan will bite you in the arse! Where OpenGL and DirectX will hold your hand all the way through consuming much more CPU power.
Now if your level of programming knowledge is decent, and you have the following math backgrounds that involves all levels of Algebra, Geometry, Trigonometry, Boolean Algebra, Probability, Statistics, Vector - Matrix based Algebra, Calculus I,II,.... Infinty(lol). Vector Calculus, Linear Algebra, Systems of Linear Equations, Analytical Geometry with Vector Calculus of Multi-variable calculations, Number and Set Theory, Data Sets and Structures, Computational Analysis, Computational and Algorithmic Design. Then you can get into the concepts of what it takes to make an actual game engine and this is without any Applied Mathematics or any Physics equations which you will need. Once you have that background and enough programming experience especially memory management and pointer arithmetic then you can begin to build your Game Engine.
So the thing here is you have to understand all of the aspects of what it takes to make a Game Engine in order to Do Advanced Graphics Programming. If you are doing just 2D graphics then life isn't too hard as you can do that in Python without any of the aforementioned APIs! But if you want to be serious and design a full fledged power house Game Engine that is robust with many feature sets, then the choice here would be either C or C++ and using either OpenGL, Direct X or Vulkan. Any of them would be just fine. Now if you are building the Engine from Scratch and you are looking for the most "efficient" running Engine with the least amount of resource overhead then you would want to choose Vulkan. But if you go this route you should at least know everything that I had mentioned above and some!
So as you can see Vulkan is not really geared towards beginner programmers in this field. You have to have extensive knowledge of all of the math, programming paradigms, all of the different types of data sets and algorithms including threading, memory synchronization, parallel programming. And even then that's just to get the application to load a simple 2D triangle on to the screen. What can be done in about 100 lines of code in OpenGL or 250 lines of code in DirectX takes almost 1,000 lines of Code in Vulkan!
Vulkan leaves everything up to you as your are responsible for all aspects of how you are using Vulkan in your application. There is no hand holding, it doesn't get in your way, it'll allow you to shoot yourself in the foot or allow you to hang yourself buy a recursive noose!
Now this isn't to say that beginners or those that are new to this field shouldn't learn Vulkan, but what I would suggest for them is this: First Learn enough of OpenGL and or DirectX to get your feet wet to see how a basic application is structured just to render a simple triangle or a spinning cube. Get familiar with their APIs and their recurring patterns of their structures. While learning that you could learn Vulkan on the side in Parallel then this way you can see how each of the three are accomplishing the same task, but know how they do it differently, then you can also compare the results between the different APIs and from there you can then make a choice of which is preferred to you. This method would also give you another tool in your tool box, and you could even write your application to support all 3 and have the "User" select which Renderer to choose at application start up.
In the end it is all up to that person to choose which route they want to go down, and from there their success will be determined by their dedication, constant study, hard work, trial and error, and most importantly their failures. If you don't fail then you are not successful! You are only successful if you have failed, found your mistake(s), fixed them, moved on and got back up and did it all over again!
For the foreseeable future, there will be three primary platforms.
OpenGL has a number of advantages in terms of more examples available, more broadly support (even Apple still supplies some OpenGL support). The one downside is that it is said to use a lot of CPU time to use.
Vulcan is newer, but not neccessarily easier to use. Vulkan leaves a lot of setup to the programmer. Far more than OpenGl or Apple Metal. This does allow you to optimize specific aspects in exchange for more complexity demanded of you.
Apple's Metal had an objective to provide similar (but not identical features) as OpenGL, but with less computational power required by the CPU. Metal does a great deal of behind-the-scenes management for you, so deviating from the common is more difficult at times.
Learn Metal if you intend to support Apple iOS or macOS projects, Vulcan for Linux or projects requiring heavy optimization, or OpenGL if you wish to have the most widespread appeal.
You should be learning OpenGL first, as that is the standard for Graphics, across so many platforms.
Even if there is a newer library, understanding the basics, and working with a language that is used all over the industry, is very important... Especially since Vulkan wont be used in Big Companies for awhile, since.
No one wants to adapt right away and end up screwing themselves over with a non-stable Framework/Library.
They would need to hire / re-train their current Open-GL programmers, and there is no need to.
Also, I've heard that OpenGL, and Vulkan, aren't exactly the same. I hear Vulkan is a lower level API, and closer to machine code, than OpenGL.
This answer I just found seems to have a lot of great info
https://gamedev.stackexchange.com/questions/96014/what-is-vulkan-and-how-does-it-differ-from-opengl
Another thing that is something to consider is the issue that happened back with OpenGL 1.
OpenGL 1 to OpenGL 2 had MAJOR changes, and since many people were using OpenGL1, and hardware supported it, there is heavy backwards compatibility needed to be implemented in some applications/engines, and that sometimes is really painful for the devs to keep supporting it.
Besides the support, the language shifted so much, that you had to learn new stuff.
This has happened with frameworks such as JavaFX (from 1.x to 2.x) and Play! Framework (Also 1.x to 2.x). Complete changes to the framework, meaning we have to relearn... everything...
So essentially what you should do is wait until Vulkan is STABLE. That means wait until Probably the 2.0 patch. IT doesn't mean you cannot learn about the basics of Vulkan, but just know this might change. I would assume that a group like Kronos would provide a very stable API from the start, especially since there are multiple Nvidia and AMD engineers working on Vulkan, including a high up Nvidia person overseeing the project apparently, as well as The base of Mantle; however, like any software, we the coders will see how well it works from the start, but many are wary and waiting to see what happens.
