The 2024 Wheel Reinvention Jam just concluded. See the results.

How well is OpenGL 4.5 supported?

I thought I might've asked this question before but couldn't find it when browsing my previous posts but there was question Casey answered on Handmade hero here (timestamp 01:43:45):

https://guide.handmadehero.org/code/day335/#6215

Where he was saying he would rather program in opengl 4.5 instead of vulkan but he wasn't sure of how well opengl 4.5 with extensions would be supported. I'm wondering how well it is supported in 2022 and what it's outlook is like at this moment since its been a few years.

On Windows there are some lower end Intel gpu's that do not support more than GL 4.4 (or even earlier version). But this is mostly driver issue. On same hardware on Linux the driver exposes 4.5 or even 4.6.

Other than Intel there are no problem using at least 4.5 on desktop. AMD & Nvidia has it for many years.

Basically if you want to target lower end on Windows with Intel hardware, I'd suggest sticking with D3D. It as also much more stable and way less buggy. On Linux there should not be problems with 4.5 - as long as users have updated kernel & mesa package versions.

You can browse https://opengl.gpuinfo.org/ site - filter out specific things, based on OS or GPU. And see what kind of versions they offer.


Edited by Mārtiņš Možeiko on

You can browse https://opengl.gpuinfo.org/ site - filter out specific things, based on OS or GPU. And see what kind of versions they offer.

Ah, perfect. This was my next question. Thanks.

Basically if you want to target lower end on Windows with Intel hardware, I'd suggest sticking with D3D. It as also much more stable and way less buggy

So, as far as you know, is the 'bugginess' in 4.5 mostly isolated on these lower end, intel drivers? In my limited understanding I would also assume less probability of bugs with something like 4.5 given the AZDO philosophy which in theory should greatly reduce reliance on drivers.


Replying to mmozeiko (#26673)

The bugginess is still there on every implementation. I would not recommend shipping OpenGL on windows at all.

If you really want GL like API, then I would recommend using Google's Angle library instead - it gives EGL & GLES2/GLES3 api that is implement with D3D11. This is how all browsers nowadays offer WebGL on windows. So you can imagine how well it is tested. It compiles down to two simple .dll files that you place next to your .exe.

All the source is here: https://github.com/google/angle
You can get prebuilt Windows .dll files & libs from releases in my repo here: https://github.com/mmozeiko/build-angle

In Linux case pretty much all drivers expose EGL & GLES natively, so there's minimum effort to get it working there.


Edited by Mārtiņš Možeiko on
Replying to boagz57 (#26675)

While considering that Macintosh is dropping OpenGL support from being an obsolete mess of a completely broken graphics API, you might as well use a thin abstraction layer or helper library on top of Vulkan and run on both Windows and Linux with decent performance, without having to write or transpile shaders for different APIs.

That would be very strange choice - to not choose GL because macOS is dropping support for it and thus choose Vulkan. Because macOS does not have Vulkan too. So you'll be using 3rd party wrappers in any case.


Edited by Mārtiņš Možeiko on
Replying to Dawoodoz (#26685)

The only point in using OpenGL over Vulkan was supporting more platforms than Vulkan. Now that OpenGL is no longer the JavaScript of graphics APIs (existing everywhere and hated everywhere), OpenGL can safely be called a relic of the past. I would not like to do strange workarounds with global states, sampler states tied to textures, up-side-down coordinate systems, strange methods that only filled a purpose 30 years ago, when Vulkan removes half of that crap and supports the same systems.


Edited by Dawoodoz on
Replying to mmozeiko (#26686)

IMHO nobody should be using Vulkan if they are just starting and do not know which GPU api to use. There are too many things that you need to do properly in VK otherwise your code will be way worse and run much slower than even crappiest and simplest OpenGL code. On differnet platforms and different vendors you need to do VK code a bit differently to be efficient. Which is not what beginners should focus.

Here are few of examples (but there much more than this) what you need to understand and know to write proper Vulkan code:

https://www.jlekstrand.net/jason/blog/2022/08/descriptors-are-hard/
https://asawicki.info/news_1740_vulkan_memory_types_on_pc_and_how_to_use_them
https://zeux.io/2020/02/27/writing-an-efficient-vulkan-renderer/
https://therealmjp.github.io/posts/gpu-memory-pool/ (D3D12, but applies the same to Vulkan)


Edited by Mārtiņš Možeiko on
Replying to Dawoodoz (#26687)

For someone looking to learn a graphics api to write a 3D renderer as a beginner (me), who has no experience with rendering or rendering API’s is plain opengl still worth learning or should I be looking into the Google angle library instead?

For someone looking to learn a graphics api to write a 3D renderer as a beginner (me), who has no experience with rendering or rendering API’s is plain opengl still worth learning or should I be looking into the Google angle library instead?

If you decide learning GL itself, then it does not matter which one you learn, as modern core profile GL and GLES2/3 versions are almost the same. They have very minor differences. GLES2 is almost like GL 2.1 with old FFP functionality removed. And GLES3 is almost like core profile GL 3.3.

The point of why I am suggesting to use Angle instead of regular GL is that it is much more stable and tested across various driver. With regular GL you'll find that you have a ton of bugs and smalls differences on many different PC when you're shipping your application. Which makes writing and debugging GL code very hard.

That said, if you're on Windows, then I would strongly recommend using D3D11 instead. The API is way better, and it has less driver issues.


Replying to MrCelsius88 (#26691)