[QUERY] In 2021, To Learn OpenGL or Vulkan? : Khronos

OpenGL
1

To the Khronos Committe:

Should one learn openGL or Vulkan?

I felt that it was better to go straight to the source and ask the Khronos committee directly.

Based on rumours, forum gossip and videos on Youtube,

OpenGL

  1. OpenGL is legacy code, it has flaws that have built up over the years.
  2. OpenGL will still be supported but it will be deprecated someday in favour of Vulkan.

Vulkan

  1. Vulkan is the new multi-platform API for graphics.
  2. Vulkan is harder to learn than openGL
  3. Vulkan will make it easier to port games between Windows, Mac and Linux.
  4. While Vulkan is harder to learn, all you have to do is code it once for everything.
  5. Ray tracing

I apologise for any factual errors and I hope I’ve not missed out anything important.

2

I would highlight OpenGL on these pages and read the matching sections:

Also, to help other readers offer input on your question, please indicate:

  • Your level of 3D Computer Graphics and GPU knowledge,
  • The platforms and GPUs you’re targeting
  • What you’d like to develop and why (toy, throwaway apps; reusable graphics engines; etc.)
  • Your top requirements in choosing a graphics API.
  • How important to your application it is:
    1. having access to the latest GPU features and/or
    2. achieving absolute maximum possible performance on the target system(s).

As-is, your primary question is woefully under-specified. The answer will vary depending on the needs.

Sounds like C++, doesn’t it? It’s not going away anytime soon either.

Harder to learn? Possibly. Code it once for everything? No.

From the 3rd link above:

Also, these forums are for users of Khronos APIs and technology (and those interested in using them). And I am not on any of the Khronos boards or working groups. If your intent is to take up conversion with Khronos more directly, take a look at this page:

3

I’d also add knowledge about programming in general. Particularly multithreaded programming techniques, as getting the best out of Vulkan requires that.

4

Hi Dark Proton,
My replies to your query in bold.

I’m looking for a recommendation from Khronos to see what is worth learning.

It would make zero sense to learn openGL just to find out Khronos is going to deprecate it.

That would be the equivalent of learning Flash, only to have Flash support just die out.

1. Your level of 3D Computer Graphics and GPU knowledge

Very low, else I wouldn’t ask the question

2. The platforms and GPUs you’re targeting

Windows, Linux, mobiles, consoles like PS5, Switch, Xbox. Unsure about specific GPUs. If there are any limitations, could you please kindly correct me. Thank you.

What you’d like to develop and why (toy, throwaway apps; reusable graphics engines; etc.)

Not toys or throwaway apps. Reusable graphic engines for games, specifically a card game.

Your top requirements in choosing a graphics API.

I’ll say performance, in terms of not taking up large amounts of RAM during runtime. ie not Unity games which takes up a lot of RAM.

How important to your application it is:
    having access to the latest GPU features and/or
    achieving absolute maximum possible performance on the target system(s).

The absolute latest features are not a must but nice to have. I assume you are talking about features like ray-tracing?

5

True and false. While it has been designed with this in mind, Mac doesn’t support it for example. Everything depends on the mood of such companies…

I have a doubt about this point. Most (if not all nowadays) PC games support only Direct3D. So, all in all, a MS oriented game will have to be ported to Linux (Vulkan/GL, Posix…) and to Mac (Metal/GL, Posix).

I also doubt about this. The key of doing things low-level is to reduce overheads higher level APIs cannot help with. But different hardware will behave differently while in run, and that might force you to have different variations of your code to handle things properly.

Inherently, OpenGL has partial RT support threw GLSL. It lacks the core functions. I believe that wouldn’t be a big mess to add this. But I doubt that Khronos or IHVs are interested in this.

My opinion is that if you never did 3D programming, start with GL. That will help to understand some good principles and practices.

Currently, Vulkan is barely used in the industry (understand non-gaming), where most of the companies are still focusing on OpenGL (for historical reason: it’s a big no to rewrite a 15 years old program to only switch to Vulkan, and for human reasons: it’s harder to find a Vulkan programmer than a GL programmer).

That were my 2 cents.

6

For card games, I don’t see any obvious points for the use of Vulkan.

7

Inherently, OpenGL has partial RT support threw GLSL. It lacks the core functions. I believe that wouldn’t be a big mess to add this. But I doubt that Khronos or IHVs are interested in this.

My opinion is that if you never did 3D programming, start with GL. That will help to understand some good principles and practices.

Currently, Vulkan is barely used in the industry (understand non-gaming), where most of the companies are still focusing on OpenGL (for historical reason: it’s a big no to rewrite a 15 years old program to only switch to Vulkan, and for human reasons: it’s harder to find a Vulkan programmer than a GL programmer).

Ok, what would you use Vulkan for?

Or what is Vulkan good at?

It would be nice to know what Vulkan is specifically good at, so Googling will just return a “Don’t use Vulkan for these things” and “Use Vulkan for these things”.

8

(for historical reason: it’s a big no to rewrite a 15 years old program to only switch to Vulkan)

This is a very good reason to choose between openGL or Vulkan.

May I ask what applications would you use Vulkan for?

9

Use it when you need to squeeze every last drop of performance from both the CPU the GPU and are willing to sacrifice flexibility and simplicity to that end.

AFIACT, the biggest difference between OpenGL and Vulkan is that Vulkan is more amenable to multi-threaded programming. OpenGL just about “tolerates” multi-threaded use, but historically it hasn’t been a priority.

10

MacOS doesn’t directly support it, but MoltenVK provides a Vulkan implementation overtop of Metal. There are similar projects that exist for D3D12, presumably for Windows on ARM.

Really? Because I’m pretty sure there are quite a few games that support Vulkan. As well as game engines.

Um, yes it would. NVIDIA is pretty much the biggest proponent of OpenGL around, and even they aren’t trying to do it. They’ve basically said “if your OpenGL program needs ray tracing support, use OpenGL/Vulkan interop to access it”.

The thing about ray tracing is that it’s not just “add a couple of shader stages and off you go”. It is a process that is fundamentally asynchronous in a way that regular OpenGL is simply not equipped to handle at an API level.

Vulkan is a high-performance graphics API, and the #1 application for such APIs is gaming. So it’s no surprise that non-gaming applications haven’t exactly switched en-masse to it.

11

AFIACT, the biggest difference between OpenGL and Vulkan is that Vulkan is more amenable to multi-threaded programming. OpenGL just about “tolerates” multi-threaded use, but historically it hasn’t been a priority.

What is AFIACT? It shares the same acronym as real-time heat detection for cows.

Is the multi-threaded “tolerance” due to GLSL using row major vs column major for the cache lines?

12

The thing about ray tracing is that it’s not just “add a couple of shader stages and off you go”. It is a process that is fundamentally asynchronous in a way that regular OpenGL is simply not equipped to handle at an API level.

I’m new here but isn’t ray tracing very old technology?

I think ray casting = ray tracing.

My understanding is that the main benefit today is parallel processing allows for real-time ray tracing.

The real-time processing is the core difference between 40 years ago and today.

Please correct me if I understood it wrongly.

13

Typo for AFAICT = As far as I can tell

No. Partly it’s due to state handling being designed around single-threaded use. Example: prior to the introduction of UBOs, if you wanted to use a shader program from multiple threads, you had to create a separate program object for each thread if you wanted to be able to set uniforms, because the default uniform block is part of the program object and thus common to all threads using the program object. Similarly with texture state prior to the introduction of sampler objects. Beyond that, OpenGL historically hasn’t provided much in the way of features which would be useful for multi-threaded rendering. Prior to the introduction of sync objects, the only way to wait until completion of a particular command was to force the thread that submitted it to synchronise (i.e. glFinish or some function performing implicit synchronisation) and wait for that. Which tends to result in a pipeline stall unless there are yet more threads which can keep the GPU busy.

Ray tracing is old, hardware support for ray-tracing is new. The difficult part of ray-tracing is maintaining a spatial index which allows you to efficiently determine which objects a given ray intersects. Calculating the reflected ray and calculating the point of intersection between a ray and a given object is relatively straightforward. But you don’t want to have to iterate through every object in a scene for each ray, given that rays tend to be somewhat coherent (i.e. reflected rays for adjacent pixels will often take similar paths), but not to the extent that you can just create a 2D map.

14

No, it has nothing to do with that.

The OpenGL API is structured as a synchronous API. It allows the GPU to go off and execute commands on its own, and it has some allowances for that, but for the most part, every OpenGL command works as if ever prior OpenGL command has finished executing. That only makes sense within one thread.

Consider a simple example: you render to an image, then use the result as a texture. In OpenGL, single-threaded, this is simple: you attach the image to an FBO, render to it, change render targets, bind the texture, and use it.

But what if you wanted to do that multi-threaded? If thread A is doing the “render to the texture” part, and thread B is doing the “read from the texture” part… how would you do that in OpenGL?

Because all OpenGL commands are executed “immediately”, thread B cannot execute any of the commands to read from the texture until it is notified by thread A that it has finished sending the commands that write to that texture. Now maybe you could introduce some kind of synchronization operation, where thread B calls a GL function that prevents the execution of any of its GL commands until thread A calls its corresponding function. But OpenGL doesn’t have that kind of functionality because it isn’t designed to.

With Vulkan, threading works almost exactly like non-threading. All commands go into a command buffer, an explicit object that represents a sequence of commands that have not yet been executed. You no longer need to care about the order in which commands are generated; you only need to care about the order in which command buffers are executed, and you can work that out once all the CBs have been generated.

Whether you doing both operations on the same thread or in different threads, Vulkan requires that you explicitly synchronize everything, to explicitly prevent reading commands from overlapping with writing commands. And so forth.

It’s an API designed for multithreading.

15

Ah, so Vulkan is for parallel processing while OpenGL is for a single-thread.

Thanks for that.

Out of curiousity, was Vulkan ever used for any engineering software?

16

That’s a bit oversimplified. You can write multithreaded OpenGL programs. However, with OpenGL you should generally limit the number of threads that call into the graphics API to 1 thread. You can go beyond this, but there are some severe limitations.

The issue is the cost of the driver code. With OpenGL, the driver is very “thick”, and you eventually hit circumstances where you wish you could push some of what it does internally off to another thread (or threads). Your hands are generallly tied here. Not so with Vulkan, which has a relatively “thin” driver and is designed a-priori for efficient multithreaded use.

See:

Parent links: 2020, 2019.

17

You’ve gotten a lot of good feedback already. But I wanted to circle back to a few of the issues you’re considering for choosing between Vulkan and OpenGL:

With Windows, Linux, and Android (mobile), you should be good for recently released systems with either Vulkan or OpenGL (OpenGL ES on mobile). For iOS (mobile), Apple likes their walled garden, but you can still target it using Vulkan using MoltenVK. I’ve even seen mention of folks using OpenGL on iOS/MacOS by layering Zink on top of MoltenVK.

Nintendo Switch I think supports Vulkan. For PS5/Sony, I believe you’re looking at another walled garden, where you’ll probably be targeting GNM / GNMX / PSSL. And XBox/Microsoft, walled garden; DX12 there.

If you need to support old platforms, that may cause you to lean toward OpenGL (desktop) or OpenGL ES (mobiles). You’ll just have to look at specific platforms/GPUs you’re targeting and see what they support.

For simple apps, either API should be fine. Though of course you have much more low-level control with Vulkan. On mobile with OpenGL ES, you have to be careful about usage patterns to avoid bloating out GPU memory with ghosted textures. But the rules there are simple to learn and follow once you know about them.

Re latest GPU features, ray tracing is but one example. In general what we’re seeing is the GPU vendors often only offering access to the latest GPU hardware capabilities through Vulkan. OpenGL is very much in maintenance mode, but again, not going away anytime soon. So just be aware of that.

As far as max perf, sounds like your needs are simple now while you’re learning about GPUs and 3D graphics. So either would be fine, with OpenGL making it easier to get up-and-running and get your “mental map” for realtime graphics without getting lost in the forest.

Down the road when you’re pushing the GPU/driver harder, it goes without saying you’ll have the most control with Vulkan.

18

Thanks, I think I understand a little bit more now.

This is my mental model.

While my uses are small now, it won’t scale efficently with openGL if I were to add “heavier” loads.

Vulkan allows one to scale from small applications all the way to graphics-intensive games, while openGL has a limit that is hard to overcome. However, Vulkan is limited to new GPU hardware.

19

It’s not really that new. Really, any (desktop) GPU that was designed in the last 7 years or so can run Vulkan.

20

Well, new or old really depends on who you’re talking to.

In the computing fields, Moore’s Law outdates everyone every 18 months. You can move from 32-bit to 64-bit, floppy disks to glass petabyte storage, etc

For certain dead infrastructure, I’ve seen an empty building still stand for more than 240 months (2 decades) with no one using it.