I agree with Adam Sawicki that it's not that relevant any more but also I do believe it's valuable lesson to tech students where the modernity comes from.
I just don't see personally sense to focus on it longer than just 1mo of intro, tutorial, get through simple example, show limitations, carry on to Vulkan/WGPU with background story that there is also DX12 and Metal that follow similar principles.
> carry on to Vulkan/WGPU with background story that there is also DX12 and Metal that follow similar principles
Except that's a minefield all of its own. DirectX 12 is its own special beast that is unlike the others. Vulkan is already mired in 3 revisions of architecture changes. WGPU is based on the (outdated) first cut of Vulkan, not the current model. Of all of these, only Metal has a reasonable on-ramp for newcomers to 3D graphics.
And then there are also the NVN and LibGNM(X) in the corner that folks forget about, due to NDAs and such.
Ah, and DirectX on XBox is not the same as on Windows.
Live by the NDA, die (at least wrt education/mindshare) by the NDA. Seems fair.
Playstation and Nintendo are doing just fine in regards to mindshare, XBox less so, but it has nothing to do with DirectX NDA for it, rather mismanagement.
Console mindshare is not the same as a broad body of engineers being familiar with the graphics API thereon
Those games are written by someone.
They are, but in practice you have a fairly small group of low-level rendering specialists who bounce around the major studios and game engine vendors
I agree, this is also where I'm investing my time Metal mostly and then try to adapt it to DX12 on Windows and I totally skipped Vulkan for that simple reason you have described. but in generic terms only Vulkan comes with portability as analogy to original OGL vision.. I respect that even though the whole framework is to be ditched and rethought into something even more modern and sustainable...
so Metal yes, if somebody wants to be Apple focused. but in the academic world I don't believe that's the case either...
Note that in regards to OpenGL original vision, game consoles never supported OpenGL, although some models kind of did support something, so game studios always cared about pluggable backends than targeting the one true API.
Only the FOSS community is so hard focused on Khronos APIs.
Nintendo Switch 1 and 2 support both OpenGL 4.6 and Vulkan via the NVIDIA driver.
I've shipped a desktop OpenGL 3.3+ game sharing the same graphics code on Windows, Linux, macOS and Nintendo Switch. For example, worked just fine.
No translation layer overhead.
It does, yet NVN is what matters for most studios.
A lucky scenario where you have not faced drivers issues, or extensions, that required multiple code paths.
It really wasn't that big of a deal, to be honest. It's a relatively complex 3D commercial game shipping on PC and modern consoles, the FUD seems overblown.
Wondering if a ton of people are just repeating things they heard around instead of trying it themselves. Because OpenGL + SDL in 2026 is not 2011 OpenGL, and seems to work portably across the NVIDIA, AMD, Intel, Mesa, Apple drivers and more vendors I've tried first-hand.
The FUD is such overblown that Godot had to implement a DirectX backend, when they only originally planned Khronos APIs, due to driver support issues they were getting.
I think I'll stick to my first-hand industry experience over hype, typical HN armchair blogpost-reader dogma, generalizations and hearsay.
Nothing lucky about write-once-run-everywhere, I literally did it and it works solidly. I also work with NDA'd APIs, wrote and profiled a production GL/Gnm/D3D12.x renderer for a client's custom engine on my own and know the tradeoffs very well.
So yeah, OpenGL (or even Vulkan) is perfectly okay for Windows + Linux + macOS + Nintendo Switch + Nintendo Switch 2 (yeah, surprise, turns out some of the most popular consoles ever are officially conformant to run and endorse Khronos APIs) in 2026.
You do need Direct3D 12.x for GDKX and so on, so that's why it gets implemented by engines, even if they don't tell you why. :)
[1] https://khronos.org/conformance/adopters/conformant-products...
[2] https://khronos.org/conformance/adopters/conformant-products...
Tbf, it all depends on how deep you look into the fractal ;) The main differences between the modern APIs are in how resource binding is done, but many other concept overlap quite well between Vulkan, D3D12 and Metal (especially in more recent Vulkan revisions).
> Of all of these, only Metal has a reasonable on-ramp for newcomers to 3D graphics.
...unless you start with Metal 4, which is bringing in a lot of Vulkan/D3D12 concepts (for better or worse, it's definitely not great for 'convenience' but may help with porting Vulkan or D3D12 code over).