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

<ol>
<li><p>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.</p></li>
<li><p>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).</p></li>
</ol>

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

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

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

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

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

CC BY-SA 3.0
2017-10-04T21:07:04.937Z
@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
CC BY-SA 3.0
2017-10-05T09:06:28.180Z
@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
CC BY-SA 3.0
2016-06-10T12:09:34.540Z
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.
RichieSams
CC BY-SA 3.0
2016-06-10T16:01:46.880Z
@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
CC BY-SA 3.0
2016-06-10T16:06:08.887Z
Correct. Implement is perhaps a poor word choice. I meant 'to use' in your program. But I like your edits. Well put
RichieSams
CC BY-SA 3.0
2016-06-08T10:29:07.650Z
2016-06-10T16:00:06.960Z
2016-06-10T16:00:06.960Z
Dan Hulme
<p>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.</p>
<p>So the question is this: do you want to learn how to use an API? Or do you want to learn <em>graphics</em>?</p>
<p>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.</p>
<p>If your goal is to learn graphics concepts, the time you're spending with the API is time you're not spending <em>learning graphics concepts</em>. 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.</p>
<p>But they aren't actually graphics concepts. They are a means to an end.</p>
<p>It takes a <em>lot</em> 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.</p>
<p>By contrast, getting to that point with OpenGL requires less work. And yes, I'm talking about modern, shader-based core-profile OpenGL.</p>
<p>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.</p>
<p>In OpenGL... it's three functions: <code>glClearColor</code>, <code>glClear</code>, and the platform-specific swap buffers call. If you're using more modern OpenGL, you can get it down to two: <code>glClearBufferuiv</code> 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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<hr />
<p>All that being said, there are two caveats to be pointed out here.</p>
<p>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 <em>cannot work</em> under OpenGL.</p>
<p>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 <em>need</em> 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.</p>
<p>But Vulkan's command-buffer based API handles it just fine.</p>
<p>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.</p>
<p>Second, there is more to learning graphics than learning graphical techniques. There's one area in particular where Vulkan wins.</p>
<p>Graphical <em>performance</em>.</p>
<p>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.</p>
<p>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.</p>
<p>But in order to achieve performance in OpenGL, you have to know that implementations do this, so that you can <em>avoid it</em>. 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.</p>
<p>With Vulkan... <em>you</em> are the one who has to issue those synchronization events. Therefore, you <em>must</em> 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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>It'll still take much longer before you can get to the point where you can learn graphical rendering techniques.</p>

CC BY-SA 3.0
2016-06-10T16:08:50.723Z
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
CC BY-SA 3.0
2016-06-10T16:28:17.220Z
@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
CC BY-SA 3.0
2016-06-11T00:08:47.103Z
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
CC BY-SA 3.0
2016-06-11T00:23:03.147Z
@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
CC BY-SA 3.0
2016-06-11T00:25:05.303Z
@DanHulme: As for how easy it is to use modern OpenGL, I [do my best](https://www.opengl.org/wiki/Main_Page) to [make it easy](http://alfonse.bitbucket.org/oldtut/). 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
CC BY-SA 4.0
2018-07-12T11:55:09.677Z
Your second link in your last comment seems to be broken (redirects to main page of BitBucket).
Ruslan
CC BY-SA 4.0
2018-07-12T13:27:26.503Z
@Ruslan: Comments can't be edited, but the correct link is at "bitbucket.io" rather than ".org". They changed their URLs since then.
Nicol Bolas
CC BY-SA 4.0
2021-04-15T15:11:05.140Z
@Ruslan I believe this is the page he is referring to (username checks out): https://nicolbolas.github.io/oldtut/
Lorem Ipsum
CC BY-SA 4.0
2020-07-15T02:08:48.027Z
"the time you're spending with the API is time you're not spending learning graphics concepts." This is sooo true. I learned way more about graphics programming by implementing everything in cpu.
Kaan E.
CC BY-SA 4.0
2016-06-09T15:43:51.957Z
2023-01-15T03:15:33.453Z
2023-01-15T03:15:33.453Z
Nicol Bolas
<p>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.</p>

CC BY-SA 4.0
2018-06-11T15:54:53.287Z
Vulkan now works on macOS (previously OS X): https://moltengl.com/
Alexander
CC BY-SA 3.0
2016-06-08T08:04:14.783Z
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
CoffeDeveloper
CC BY-SA 3.0
2016-06-08T08:56:08.637Z
@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.
Criticize SE actions means ban
CC BY-SA 3.0
2016-06-09T17:40:28.680Z
@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
CC BY-SA 3.0
2016-06-30T07:52:16.723Z
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
CC BY-SA 3.0
2016-06-08T01:02:11.473Z
2016-06-08T01:02:11.473Z
Gavin Higham
<p>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.</p>

<p>I tell you what I think it's the best approach <strong>in my opinion</strong> to learn computer graphics "like a pro".</p>

<ol>
<li>Learn Linear Algebra and geometry like a pro. Without this, forget any fancy API or graphics</li>
<li>Buy a good book on computer graphics (e.g. <a href="https://rads.stackoverflow.com/amzn/click/1482229390" rel="noreferrer">Fundamentals of computer graphics</a>)</li>
<li>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 <strong>before</strong> trying to get 10000 FPS</li>
<li>Now take on OpenGL, Vulkan or DirectX and repeat your fancy example (see above).</li>
</ol>

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

CC BY-SA 4.0
2018-07-06T05:24:46.217Z
2018-07-06T05:24:46.217Z
ingframin
<p>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.</p>

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

<p>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 <code>uniforms</code>(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.</p>

<p>Understanding this things also will help in understanding how GPU work. What will allow you to do some optimization both on Vulkan and OpenGL. </p>

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

CC BY-SA 3.0
2016-06-08T07:27:09.513Z
2017-04-24T10:19:22.833Z
2017-04-24T10:19:22.833Z
Derag
<p>I've been "getting in to" graphics programming for a few months now.</p>

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

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

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

<p>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 &lt; Which Vulkan can replace in some cases. </p>

<p>I can't hold out for OpenGL updates forever, and I wont. But it's my preference for developing.</p>

CC BY-SA 3.0
2016-06-09T15:18:32.767Z
"*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
CC BY-SA 3.0
2016-06-11T00:03:25.313Z
You do realise that Vulkan and GL are made by mostly the same people?
Dan Hulme
CC BY-SA 3.0
2016-06-11T00:04:18.247Z
Yes I do. I still prefer GL
parabolah
CC BY-SA 3.0
2016-06-09T04:38:43.670Z
2016-06-09T04:38:43.670Z
parabolah
<p>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.</p>

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

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

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

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

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

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

<p>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! </p>

<p>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!</p>

<p>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!</p>

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

<p>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! </p>

CC BY-SA 4.0
2019-09-11T06:23:36.163Z
2019-09-11T06:23:36.163Z
Francis Cugler
<p>For the foreseeable future, there will be three primary platforms.</p>
<ul>
<li>OpenGL</li>
<li>Vulcan</li>
<li>Metal</li>
</ul>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h2>Which one to learn?</h2>
<p>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.</p>

CC BY-SA 4.0
2024-10-19T20:55:55.997Z
DirectX isn't primary platform?
rofrol
CC BY-SA 4.0
2022-12-18T01:32:57.990Z
2022-12-18T01:32:57.990Z
James Risner
<p>You should be learning OpenGL first, as that is the standard for Graphics, across so many platforms.</p>

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

<ol>
<li><p>No one wants to adapt right away and end up screwing themselves over with a non-stable Framework/Library.</p></li>
<li><p>They would need to hire / re-train their current Open-GL programmers, and there is no need to.</p></li>
</ol>

<hr>

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

<p>This answer I just found seems to have a lot of great info</p>

<p><a href="https://gamedev.stackexchange.com/questions/96014/what-is-vulkan-and-how-does-it-differ-from-opengl">https://gamedev.stackexchange.com/questions/96014/what-is-vulkan-and-how-does-it-differ-from-opengl</a></p>

<hr>

<p>Another thing that is something to consider is the issue that happened back with OpenGL 1.</p>

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

<p>Besides the support, the language shifted so much, that you had to learn new stuff.</p>

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

<hr>

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

CC BY-SA 3.0
2016-06-09T08:15:01.433Z
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
CC BY-SA 3.0
2016-06-09T16:07:02.913Z
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
CC BY-SA 3.0
2016-06-09T16:13:32.113Z
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.
Dan Hulme
CC BY-SA 3.0
2016-06-09T16:18:43.730Z
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
CC BY-SA 3.0
2016-06-09T17:37:22.600Z
@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
CC BY-SA 3.0
2016-06-09T19:38:40.367Z
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
CC BY-SA 3.0
2016-06-09T22:30:15.220Z
@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
CC BY-SA 3.0
2016-06-08T16:04:31.510Z
2016-06-09T16:13:28.647Z
2017-04-13T12:18:54.697Z
XaolingBao
<p>Hardly!</p>

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

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

<p>Specialization is rarely a marketable skill.</p>

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

<p>Specialization is rarely an efficient paradigm.</p>

CC BY-SA 3.0
2016-06-08T16:52:32.307Z
Good answer, reminded me of this: http://www.elise.com/quotes/heinlein_-_specialization_is_for_insects
Will
CC BY-SA 3.0
2016-06-09T13:33:16.703Z
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.
Moby Disk
CC BY-SA 3.0
2016-06-09T13:59:02.013Z
Those specifics are irrelevant to the point of the analogy.
mHurley
CC BY-SA 3.0
2016-06-09T18:32:26.773Z
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
8bittree
CC BY-SA 3.0
2016-06-09T18:34:30.713Z
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
CC BY-SA 3.0
2016-06-09T18:38:41.940Z
I'm pretty sure that's what I implied by using the examples I did ;-) maybe not...
mHurley
CC BY-SA 3.0
2017-10-04T20:52:22.547Z
@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
CC BY-SA 3.0
2016-06-07T21:20:37.550Z
2016-06-07T21:25:46.773Z
2016-06-07T21:25:46.773Z
mHurley
<p><a href="https://en.wikipedia.org/wiki/Vulkan_(API)">From the wiki</a>: "the Vulkan API was initially referred to as the 'next generation OpenGL initiative' by Khrono", <a href="https://en.wikipedia.org/wiki/OpenGL#Vulkan">and that it is</a> "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".</p>

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

CC BY-SA 4.0
2022-12-18T15:55:51.367Z
Answers to this question are opinion based. The answers should all start with the words "In my *opinion*"
pmw1234
CC BY-SA 4.0
2022-12-19T10:27:42.190Z
@pmw1234 I agree with you. This question (even though it is an old one) is opinion based and will be closed. There are already enough answers for everybody who is interested in this topic.
wychmaster
<opengl><api><vulkan>
Should new graphics programmers be learning Vulkan instead of OpenGL?
galois
# Should new graphics programmers be learning Vulkan instead of OpenGL?

(Asked by: username_0 on 2016-06-07)

[From the wiki](https://en.wikipedia.org/wiki/Vulkan_(API)): "the Vulkan API was initially referred to as the 'next generation OpenGL initiative' by Khrono", [and that it is](https://en.wikipedia.org/wiki/OpenGL#Vulkan) "a grounds-up redesign effort to unify OpenGL and OpenGL ES into one common API that username_23 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 username_23 serve the same purpose.

**Tags:** opengl, api, vulkan

> **Comments:**
> **username_1**: Answers to this question are opinion based. The answers should all start with the words "In my *opinion*"  
> **username_2**: @username_1 I agree with you. This question (even though it is an old one) is opinion based and username_23 be closed. There are already enough answers for everybody who is interested in this topic.  

---

## 10 answers

### Answer by username_22 on 2016-06-07. Score: 39 | Accepted answer

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.

> **Comments:**
> **username_23**: Good answer, reminded me of this: http://www.elise.com/quotes/heinlein_-_specialization_is_for_insects  
> **username_24**: 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.  
> **username_22**: Those specifics are irrelevant to the point of the analogy.  
> **username_25**: 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 username_23 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  
> **username_25**: 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.  
> **username_22**: I'm pretty sure that's what I implied by using the examples I did ;-) maybe not...  
> **username_4**: @username_24 - 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.  

---

### Answer by username_3 on 2016-06-08. Score: 53

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 username_23 let you focus on the experience you want to create, instead of the technology behind it. It username_23 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 username_23 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.

> **Comments:**
> **username_5**: 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 username_23 be very overwhelming.  
> **username_3**: @username_5 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.  
> **username_5**: Correct. Implement is perhaps a poor word choice. I meant 'to use' in your program. But I like your edits. Well put  
> **username_4**: @username_3 - 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?  
> **username_3**: @username_4 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.  

---

### Answer by username_6 on 2016-06-09. Score: 43

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 username_23 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 username_23 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 username_23 exist. Features which are inherently incompatible with OpenGL-like APIs. So for the time being, OpenGL and Vulkan have transferable graphical concepts, this username_23 become increasingly less true as time goes on. New features username_23 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 username_23 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 username_23 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 username_23 be fast or slow.

So in that case, learning Vulkan can help you better learn about how to make graphics faster. And it username_23 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.

> **Comments:**
> **username_3**: 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.  
> **username_6**: @username_3: 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.  
> **username_3**: 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.  
> **username_6**: @username_3: "*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.  
> **username_6**: @username_3: As for how easy it is to use modern OpenGL, I [do my best](https://www.opengl.org/wiki/Main_Page) to [make it easy](http://alfonse.bitbucket.org/oldtut/). 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.  
> **username_7**: Your second link in your last comment seems to be broken (redirects to main page of BitBucket).  
> **username_6**: @username_7: Comments can't be edited, but the correct link is at "bitbucket.io" rather than ".org". They changed their URLs since then.  
> **username_9**: "the time you're spending with the API is time you're not spending learning graphics concepts." This is sooo true. I learned way more about graphics programming by implementing everything in cpu.  
> **username_8**: @username_7 I believe this is the page he is referring to (username checks out): https://username_6.github.io/oldtut/  

---

### Answer by username_10 on 2016-06-08. Score: 8

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 username_23 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 username_23 continue to do so.

> **Comments:**
> **username_12**: I would bet that if OSX would ever support Vulkan it username_23 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  
> **username_13**: @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.  
> **username_6**: @username_10: 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.  
> **username_14**: Apple username_23 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.  
> **username_11**: Vulkan now works on macOS (previously OS X): https://moltengl.com/  

---

### Answer by username_15 on 2018-07-06. Score: 7

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](https://rads.stackoverflow.com/amzn/click/1482229390))
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.


---

### Answer by username_16 on 2016-06-08. Score: 4

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 username_23 help in understanding how GPU work. What username_23 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 username_23 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 username_23 not be writing in OpenGL nor in Vulkan but knowledge about GPU username_23 be always useful.


---

### Answer by username_17 on 2016-06-09. Score: 3

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.

> **Comments:**
> **username_6**: "*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.  
> **username_3**: You do realise that Vulkan and GL are made by mostly the same people?  
> **username_17**: Yes I do. I still prefer GL  

---

### Answer by username_18 on 2019-09-11. Score: 1

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 username_23 bite you in the arse! Where OpenGL and DirectX username_23 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 username_23 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 username_23 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!


---

### Answer by username_19 on 2022-12-18. Score: 1

For the foreseeable future, there username_23 be three primary platforms.

* OpenGL
* Vulcan
* Metal

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.

## Which one to learn?

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.

> **Comments:**
> **username_20**: DirectX isn't primary platform?  

---

### Answer by username_21 on 2016-06-08. Score: 0

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 username_23 see how well it works from the start, but many are wary and waiting to see what happens.

> **Comments:**
> **username_3**: 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.  
> **username_21**: 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.  
> **username_3**: Of course things username_23 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 username_23 add to the spec, and the things you learn about it today username_23 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.  
> **username_21**: 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 username_23 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 username_23 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.  
> **username_6**: @Lasagna: "*It's that it's subject to change, not many companies username_23 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.  
> **username_21**: 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.  
> **username_6**: @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.  

---

