52
$\begingroup$

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.

$\endgroup$
  • 1
    $\begingroup$ 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. $\endgroup$ – A---B Jun 7 '16 at 21:46
32
$\begingroup$

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.

$\endgroup$
  • 2
    $\begingroup$ Good answer, reminded me of this: elise.com/quotes/heinlein_-_specialization_is_for_insects $\endgroup$ – Will Jun 8 '16 at 16:52
  • 7
    $\begingroup$ This 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. $\endgroup$ – Moby Disk Jun 9 '16 at 13:33
  • $\begingroup$ Those specifics are irrelevant to the point of the analogy. $\endgroup$ – mHurley Jun 9 '16 at 13:59
  • 4
    $\begingroup$ Claiming 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 $\endgroup$ – 8bittree Jun 9 '16 at 18:32
  • $\begingroup$ 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. $\endgroup$ – 8bittree Jun 9 '16 at 18:34
40
$\begingroup$

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.

$\endgroup$
  • 1
    $\begingroup$ I 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. $\endgroup$ – RichieSams Jun 10 '16 at 12:09
  • 2
    $\begingroup$ @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. $\endgroup$ – Dan Hulme Jun 10 '16 at 16:01
  • $\begingroup$ Correct. Implement is perhaps a poor word choice. I meant 'to use' in your program. But I like your edits. Well put $\endgroup$ – RichieSams Jun 10 '16 at 16:06
  • $\begingroup$ @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? $\endgroup$ – ToolmakerSteve Oct 4 '17 at 21:07
  • 1
    $\begingroup$ @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. $\endgroup$ – Dan Hulme Oct 5 '17 at 9:06
24
$\begingroup$

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.

$\endgroup$
  • 1
    $\begingroup$ 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. $\endgroup$ – Dan Hulme Jun 10 '16 at 16:08
  • 1
    $\begingroup$ @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. $\endgroup$ – Nicol Bolas Jun 10 '16 at 16:28
  • $\begingroup$ 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. $\endgroup$ – Dan Hulme Jun 11 '16 at 0:08
  • $\begingroup$ @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. $\endgroup$ – Nicol Bolas Jun 11 '16 at 0:23
  • 2
    $\begingroup$ @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. $\endgroup$ – Nicol Bolas Jun 11 '16 at 0:25
7
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ 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 $\endgroup$ – GameDeveloper Jun 8 '16 at 8:04
  • 1
    $\begingroup$ @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. $\endgroup$ – immibis Jun 8 '16 at 8:56
  • 1
    $\begingroup$ @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. $\endgroup$ – Nicol Bolas Jun 9 '16 at 17:40
  • $\begingroup$ 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. $\endgroup$ – Jonathan Baldwin Jun 30 '16 at 7:52
  • $\begingroup$ Vulkan now works on macOS (previously OS X): moltengl.com $\endgroup$ – Alexander Jun 11 '18 at 15:54
4
$\begingroup$

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.

$\endgroup$
2
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ "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. $\endgroup$ – Nicol Bolas Jun 9 '16 at 15:18
  • $\begingroup$ You do realise that Vulkan and GL are made by mostly the same people? $\endgroup$ – Dan Hulme Jun 11 '16 at 0:03
  • $\begingroup$ Yes I do. I still prefer GL $\endgroup$ – Winter Roberts Jun 11 '16 at 0:04
2
$\begingroup$

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

  1. Learn Linear Algebra and geometry like a pro. Without this, forget any fancy API or graphics
  2. Buy a good book on computer graphics (e.g. Fundamentals of computer graphics)
  3. While you study the book, set up a programming environment with something that allows you to draw on an image and implement the algorithms! It can be Java 2D or C++ and SDL or even Python and Pygame for what it matters. At this stage you need to get your spinning textured gears with multiple camera views up and running before trying to get 10000 FPS
  4. Now take on OpenGL, Vulkan or DirectX and repeat your fancy example (see above).

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.

$\endgroup$
-1
$\begingroup$

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

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.

$\endgroup$
  • $\begingroup$ 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. $\endgroup$ – Dan Hulme Jun 9 '16 at 8:15
  • 1
    $\begingroup$ 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. $\endgroup$ – XaolingBao Jun 9 '16 at 16:07
  • 1
    $\begingroup$ Of 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. $\endgroup$ – Dan Hulme Jun 9 '16 at 16:13
  • 1
    $\begingroup$ @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. $\endgroup$ – Nicol Bolas Jun 9 '16 at 17:37
  • 2
    $\begingroup$ @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. $\endgroup$ – Nicol Bolas Jun 9 '16 at 22:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.