Should new graphics programmers be learning Vulkan instead of OpenGL?



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.


Posted 2016-06-07T21:13:56.997

Reputation: 370

If you can do something in one API, you can do it any other API, just the way of doing it will depend on the API. – A---B – 2016-06-07T21:46:02.013




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.


Posted 2016-06-07T21:13:56.997

Reputation: 441


Good answer, reminded me of this:

– Will – 2016-06-08T16:52:32.307

5This C++ analogy is inappropriate. Vulkan is a new next generation API developed by the creators of OpenGL. C++ is an established, mostly backwards-compatible competitor to C. – Moby Disk – 2016-06-09T13:33:16.703

Those specifics are irrelevant to the point of the analogy. – mHurley – 2016-06-09T13:59:02.013

2Claiming specialization is inefficient or unmarketable is incredibly naive. A translator that knows all of five words in every single spoken language is useless, people will hire translators that mastered (a.k.a specialized in) a small number of languages. Now over-specializing is problematic. A translator that completely mastered one language and only knows that language is also not a useful translator. And devs (indie or otherwise) need to be careful not to spend all their time learning new tools. Eventually they need to actually make something to sell, lest they find themselves bankrupt – 8bittree – 2016-06-09T18:32:26.773

Just to be clear, I don't necessarily disagree with you in regards to OpenGL and Vulkan, This quite possibly is a case where learning both instead of just Vulkan is the better choice. – 8bittree – 2016-06-09T18:34:30.713

I'm pretty sure that's what I implied by using the examples I did ;-) maybe not... – mHurley – 2016-06-09T18:38:41.940

@MobyDisk - actually, the C++ analogy is right on, though "C vs Java" or "C vs C#" might be a better comparison. Vulkan is a lower-level API than OpenGL, not a next-gen replacement. According to Khronos, they are "complementary". Eventually I expect we'll see an OpenGL-inspired layer on top of Vulkan. That would be a next-gen successor, if it successfully combined performance-gains with higher-level API calls for programmer convenience. – ToolmakerSteve – 2017-10-04T20:52:22.547


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.

  1. 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.

  2. 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.

Dan Hulme

Posted 2016-06-07T21:13:56.997

Reputation: 3 783

1I somewhat disagree. Vulkan (and DX12)has proven to be very difficult to implement, for experienced devs. With all the power that Vulkan gives you, it's very very easy to shoot yourself in the foot. In a addition, Vulkan requires a lot more boilerplate code. For someone just learning about GPU programming, I tend to think that Vulkan will be very overwhelming. – RichieSams – 2016-06-10T12:09:34.540

1@RichieSams I don't think you meant "implement". Only the GPU vendor has to implement Vulkan, and it's a lot easier than implementing OpenGL. (Believe me, I've done it!) But assuming you meant it's difficult to integrate with or program against, I've added a paragraph with some information I learned from the Vulkan WG. – Dan Hulme – 2016-06-10T16:01:46.880

Correct. Implement is perhaps a poor word choice. I meant 'to use' in your program. But I like your edits. Well put – RichieSams – 2016-06-10T16:06:08.887

@DanHulme - I'm surprised by your comment "GL encourages you to think in an immediate-mode style". I thought that was only true of early OpenGL versions? – ToolmakerSteve – 2017-10-04T21:07:04.937

@ToolmakerSteve The OpenGL WG has put a lot of work into adding concurrency and batched writes, so you can express your program in a way that's suitable for tiling/deferred implementations. But it's still a foundation that was set in the immediate-mode age, which is why those people decided a fresh start in Vulkan was needed. And I still see a lot of new users starting with GL and forming an immediate-mode mental model of how implementations work. – Dan Hulme – 2017-10-05T09:06:28.180


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 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.

Nicol Bolas

Posted 2016-06-07T21:13:56.997

Reputation: 2 725

I'm glad you posted this, because it makes very clear some ideas that I was hesitating to express in my answer: that learning the concepts is most important. I think where we differ is that you encourage GL because it's easier to get started, while I think that ease of getting started brings a risk of doing things in legacy ways. It's quite hard to know in GL what the "modern GL idiom" is, compared with programming in a legacy style. If nobody tells you to use VAOs instead of a separate draw call per primitive, it's a lot harder to unlearn that mistake later. – Dan Hulme – 2016-06-10T16:08:50.723

1@DanHulme: It's all a matter of using the right learning materials. There are plenty of such materials online that use modern idioms. Nobody should ever try learning graphics just by reading a reference manual or specification. – Nicol Bolas – 2016-06-10T16:28:17.220

You make it sound really easy! Even so, I still see programmers getting started in graphics - some of them very competent in other fields - and using legacy features and learning nothing about the performance characteristics. It's really hard to get that wrong in Vulkan, because it makes expensive things look expensive. Anyway, we don't need to argue. I agree with your main point: learning the concepts is most important, and you can do that without Vulkan or GL. – Dan Hulme – 2016-06-11T00:08:47.103

@DanHulme: "It's really hard to get that wrong in Vulkan" Because you're too busy getting everything else wrong ;) Also, it's still pretty easy to get performance wrong in Vulkan. Unnecessary synchonization. Using only the "general" image layout. Not taking advantage of subpasses. Frequent pipeline changes. And so forth. Not to mention, different vendors don't even agree on how best to use Vulkan. – Nicol Bolas – 2016-06-11T00:23:03.147


@DanHulme: As for how easy it is to use modern OpenGL, I do my best to make it easy. If people insist on learning from garbage sites like NeHe, or by reading random documentation, that's not something anyone can help. You can lead horses to water, but you can't make them drink.

– Nicol Bolas – 2016-06-11T00:25:05.303


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.

Gavin Higham

Posted 2016-06-07T21:13:56.997

Reputation: 61

I would bet that if OSX would ever support Vulkan it will support only a small subset of it, and that would also become the Next Generation graphics api for web browsers, OpenGL is still ways simpler to use (to a certain degree of course) than Vulkan, what vulkan gain in simplicity over rendering pipeline it lose it in explicit handling of much other stuff – GameDeveloper – 2016-06-08T08:04:14.783

1@DarioOO OpenGL immediate mode is way simpler to use than whatever-you-call-the-thing-that's-not-immediate-mode, yet it's not recommended. – immibis – 2016-06-08T08:56:08.637

1@Gavin: It should be noted that OpenGL versions 4.2 or greater aren't supported on OSX either. So if you want to use anything recent from OpenGL on OSX, you can't. And Apple is highly unlikely to adopt later OpenGL versions. The Apple platform is all-in on Metal, so cross-platform is a bust either way. – Nicol Bolas – 2016-06-09T17:40:28.680

Apple will never support Vulkan unless they're forced to, and the economics of it are pretty simple. By going all in on Metal, they hope to lock in mobile game developers that need more than GLES2 can offer but don't have the resources to write their games for both Vulkan and Metal. They're prepared to sacrifice Mac's tiny gaming ecosystem for this, especially if iOS devs also release on the Mac App Store. – Jonathan Baldwin – 2016-06-30T07:52:16.723


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.


Posted 2016-06-07T21:13:56.997

Reputation: 195


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.

Winter Roberts

Posted 2016-06-07T21:13:56.997

Reputation: 31

"Another problem I have is with Vulkan's claims is how it claims to be better." Vulkan does not claim to be anything. It's just an API; it cannot make claims. – Nicol Bolas – 2016-06-09T15:18:32.767

You do realise that Vulkan and GL are made by mostly the same people? – Dan Hulme – 2016-06-11T00:03:25.313

Yes I do. I still prefer GL – Winter Roberts – 2016-06-11T00:04:18.247


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.

  1. No one wants to adapt right away and end up screwing themselves over with a non-stable Framework/Library.

  2. 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

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.


Posted 2016-06-07T21:13:56.997

Reputation: 105

Vulkan is stable right now. Your GL 1.0 vs 2.0 analogy is apt. Starting with GL now would be like starting learning GL 1.0 six months after GL 2.0 comes out. – Dan Hulme – 2016-06-09T08:15:01.433

Vulkan might be "stable" it doesn't mean things wont change, this is the nature of languages, which I presented 2 recent changes to languages within the last few years, so how do we know this wouldn't happen to Vulkan? You're basically saying that learning OpenGL is a waste, and that's false. Making it seem like OpenGL is dead, and wont be used any more... Also false. Besides, I'm not the only one who believes that Vulkan could have stability issues. It might not, but with any new language, that's what you look for. – XaolingBao – 2016-06-09T16:07:02.913

1Of course things will change, and the working group is already working towards new features for a next spec version (ssh, you didn't hear that from me). Stable means that those things will add to the spec, and the things you learn about it today will still be valid two years from now. OTOH, the things you learn about GL today are already a poor match for how GPUs work: just like learning about fixed-function pipelines in a programmable-shader world. If you read my answer, you see I don't think learning GL now is a waste. But "Vulkan is too new" is not a good reason to discount it. – Dan Hulme – 2016-06-09T16:13:32.113

Libraries change with addons, but I'm talking about architecture changes, which is what happened in FX, Play!, OpenGL, and others. How can we say in 2 years it will be the same? The Fixed-Pipeline comment is what the issue with GL 1-2 was, so yes, why learn it if soon it could change, and we wouldn't even know? Vulkan is too new isn't the full reason. It's that it's subject to change, not many companies will adapt to using it right away, and how many people really want to change from OpenGL to Vulkan who are hardcore GL coders? I think you should look at Vulkan though. – XaolingBao – 2016-06-09T16:18:43.730

1@Lasagna: "It's that it's subject to change, not many companies will adapt to using it right away" Valve. Epic. Unity. All of them are heavily invested in making their engines work on Vulkan. CryTech and Id aren't exactly ignoring it either. So your statement is not commensurate with the facts. – Nicol Bolas – 2016-06-09T17:37:22.600

Just because it's being adapted into 3D Engines, doesn't mean that companies are investing their projects into it, especially projects that are mid-way. You might get a brand new project in Vulkan, but again, are you willing to hire new employees, train new ones, and be the one to test out a new platform? I've done testing on new platforms, and it's a PITA sometimes working around bugs, reporting bugs, etc, when you're trying to just put out a product. – XaolingBao – 2016-06-09T19:38:40.367

1@Lasagna: "Just because it's being adapted into 3D Engines, doesn't mean that companies are investing their projects into it" ... So 3D engines don't qualify as "projects"? Does DOTA2 count as a "project"? Because it's got support for Vulkan right now. Does Samsung's line of smartphones and tablets count as a "project"? Because they're looking at incorporating it into the UI. The reality is that lots of people are willing to "be the one to test out a new platform", if that platform gets them what they need. – Nicol Bolas – 2016-06-09T22:30:15.220