Difference between Vulkan, GLES, and OpenGL?

[forealdo]

I've primarily used OpenGL, but looking at the changelog for GZDoom 4.11.1, I saw the default backend was changed to Vulkan, so I was curious. I also saw mention of GLES. What's the difference between the three backends, and which one do you use personally?

[Professor Hastig]

Vulkan is the more modern graphics API. Feature wise it is currently on par with OpenGL but that will certainly change in the future.
GLES is mainly for low performance hardware that's normally found in cheap older laptops. It removes some less used features in favor of getting better performance out of such hardware.

[GreaseMonkey]

In theory: Vulkan is for newer desktop GPUs than what OpenGL targets, and newer phone GPUs than what GLES targets.
But ultimately, you should use whatever works. I have a top-of-the-line GPU (Radeon RX 7900 XTX) and yet I use the GLES renderer because it loads really quickly which is important for testing maps. The Vulkan renderer takes about 2 seconds each time, and the OpenGL renderer doesn't work properly here.

(And having programmed for all 3: Vulkan is really, *really* painful to start using in your code. The "hello world" triangle takes about 1,000 lines of code, contrasted with GL3 or GLES2 taking about 200 lines, or GL1 taking about 10 lines. Vulkan may be the better choice for pushing performance for those who know what they're doing, but OpenGL as an API will continue to live on even if it remains at version 4.6 forever.)

[Professor Hastig]

but OpenGL as an API will continue to live on even if it remains at version 4.6 forever.)

As you noticed yourself with your high end hardware not working properly, no it won't live on. It will eventually be replaced by a wrapper that's good enough to handle old existing software but nothing performance demanding. I'd rather wait those 2 seconds on launch than reverting to a feature restricted implementation.

[Graf Zahl]

but OpenGL as an API will continue to live on even if it remains at version 4.6 forever.)

Seconding that you shouldn't be too sure here.
Just have a look where OpenGL stands right now.

On macOS it is for all intents and purposes already dead, it is stuck at an ancient version that's lacking essential features for modern rendering, on Windows all driver support for pre-Vulkan hardware has completely stopped and modern drivers see a gradual winddown of first class support for it. If this continues it will only 'live on' on Linux because there's an attitude around to not let old things die, never mind that they are obsolete.
Many engines that once supported OpenGL will move on because they are stuck with a frozen feature set that by now is almost 10 years old. And the more software abandons it, the less relevant it will be for the driver developers. The end of the story will be that for the remaining software that still needs it - by then virtually all old stuff - a wrapper layer like Zink will be more than adequate to handle it.

By then it'll be as relevant as D3D8 is now.

[GreaseMonkey]

Yeah I suspect zink is going to be the way to go for OpenGL once it's mature enough - that way, you get a good OpenGL implementation that works with everything.

With that said, the main reason OpenGL stuff tends to have issues is *not* because of a lack of care for it on the driver side, but because too many developers only test their stuff using NVidia's implementation, which is so full of bug workarounds that you can't turn off that anything you write is guaranteed to be wrong.

Anyway, trying it again, shoving it into GDB, and... it actually works, but it takes a long time to compile all of the shaders (20 seconds if it's all cached, probably about 3 minutes if it's not). Some improvements could definitely be done here, but if the same sort of improvements are applied to the Vulkan backend then there's a chance that 2-second delay would be eliminated.

[Rachael]

With that said, the main reason OpenGL stuff tends to have issues is *not* because of a lack of care for it on the driver side, but because too many developers only test their stuff using NVidia's implementation, which is so full of bug workarounds that you can't turn off that anything you write is guaranteed to be wrong.

This is massively misleading.

While it might be true that most OpenGL stuff is tested on NVidia GPU's, that isn't the reason for its problems. If that were the case it'd be even worse with DX12 and Vulkan due to the to-the-metal implementations that these API's offer.

The truth is that OpenGL was the least popular API to develop on even when it was in its prime. Vendors like AMD and Intel only did OpenGL implementations out of necessity for compatibility with popular OpenGL games of the time (especially id Software titles), it was merely a necessity for surviving in the market. And the only reason NVidia cared was because it was a way for them to show off how performant their GPU's were versus the competition.

OpenGL always was a forgotten child in its prime, and its deprecation to Vulkan made that even worse.

[dpJudas]

I believe GreaseMonkey is referring to the Nvidia GLSL compiler accepting input that wasn't allowed according to the GLSL spec. While that indeed did cause some trouble, the Intel GLSL compiler was far worse - it could not handle the most basic GLSL constructs such as "vec3 foo = vec3(0);".

DX11, DX12 and Vulkan does not have these problems since the driver doesn't have the compiler front-end. They all compile IR byte code (SPIR-V for Vulkan). There is an extension for OpenGL 4.6 that lets you do that for OpenGL as well.

The API OpenGL had was garbage from 2.0 until 4.5 compared to any of the Direct3D offerings. People don't stick to OpenGL nowadays because it is good, but rather because Direct3D 12 and Vulkan is way too verbose and unforgiving for developers. That doesn't change the fact that OpenGL is effectively dead and will probably never get any of the features added to Vulkan. That means an OpenGL application can never access RT cores or mesh shaders. This can only be fixed if OpenGL stops being provided by drivers now and instead becomes a library on top of VK, with a team actively extending OpenGL. I'm just not sure anyone technically advanced to pull that off will put in the work to make that a reality.

[Graf Zahl]

I don't think any such library will ever happen. There will be API wrappers for sure but they will most certainly invent their own API and not replicate the poor design that had been plaguing OpenGL since its inception and where everything that could have been done wrong actually was done wrong. In fact, this is the main reason why there have always been problems. The API was so poorly designed that it was impossible to implement sanely.

The only reason it even survived for so long is not games but mainly legacy CAD applications that were too massive to be rewritten, but I guess nowadays sticking with OpenGL in today's market is so poisonous that they will have to be rewritten to remain competitive.

And the only reason NVidia cared was because it was a way for them to show off how performant their GPU's were versus the competition.

No, that wasn't the reason. The real reason behind NVidia's support is their professional graphics cards. The customers of these needed OpenGL to run the aforementioned CAD software so NVidia had to provide good drivers.
I don't think it's hard to guess what will happen here if this software migrates to Vulkan - and it surely will do that.

[Talon1024]

There's more information about OpenGL vs. Vulkan on the Blender developer blog.