Should new graphics programmers be learning Vulkan instead of OpenGL?

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.

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

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.

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.

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

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

//EDIT

Little comment to what i meant:

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 will searching 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 probability that in job you will not writing in OpenGL neither in Vulkan but knowledge about GPU will be always useful.

Sorry for my really bad english.

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.

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.

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

http://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.