5 ms·
In 2026: Please don't learn this; it's obsolete. Learn Vulkan (Or another modern API; or how to build engines on top of them; or how to write shaders; or how to
by the__alchemist 3mo ago
In 2026: Please don't learn this; it's obsolete. Learn Vulkan (Or another modern API; or how to build engines on top of them; or how to write shaders; or how to do GPU compute using CUDA etc)
- samiv 3mo agoOpenGL is not obsolete and is totally fine for many use cases. Vulkan is way too complicated and cumbersome for many. Even if OpenGL doesn't get new features what exists now will continue to work for decades.
- reactordev 3mo agoSadly, the OP is right, OpenGL is deprecated on a number of platforms and down right removed from others. Please don't learn this now. Vulkan has the shape of every modern graphics api out there, DX included. Learn this or at the very least WebGPU.
- flohofwoe 3mo agoThe problem with OpenGL isn't so much that its programming model is outdated, but that it is an incredibly confusing and (in many places) just plain badly designed API (just look at VAOs, it's hard to come up with a more broken and useless feature - some of the problems have been salvaged on more recent OpenGL versions, but those are not portable to macOS or GLES3.x). Another (related) problem is that the many sediment layers that have accumulated over nearly three decades are not clearly separated (and Vulkan is starting to suffer from the same problem btw, there's always at least five different ways to do the same thing, three of which are outdated or not recommended to be used on specific GPU architectures, and the other two have complicated relationships and interdependencies with other redundant or optional features, it's apparently some sort of Khronos curse to always create the biggest possible mess when it comes to 3D APIs). On Windows (maybe even on Linux via Proton), starting with D3D11 makes a lot more sense, or on macOS with Metal v1. Both APIs are 'close enough' to modern 3D APIs to carry a lot of the knowledge over, but without being too low-level like Vulkan or D3D12, WebGPU running in browsers is also a good choice (even though it inherits some bad design decisions from Vulkan 1.0 when it comes to resource bindings, and is in some places actually slower than WebGL2).
- cyber_kinetist 3mo agoI think the dark side of OpenGL for beginning graphics programming is that debugging can be really frustrating! I really think learnopengl.com should have a mandatory section for how to use RenderDoc (https://renderdoc.org/ https://renderdoc.org/) - it's night and day if you know how to use it. DX11 suffers from the problem that there aren't that much high quality material comparable to learnopengl.com - I really don't like RasterTek which just dumps code at you without explaining things properly. Same for Metal - the best way would be to just download and read the example source code from the official Apple site, but it's rather unfriendly for beginners.
- pjmlp 3mo ago> incredibly confusing and (in many places) just plain badly designed API Thankfully Khronos has ensured Vulkan follows up in this tradition, lets see if the usability improvements from 1.4 onwards are good enough for Vulkan to stay relevant beyond Android, embedded and SteamDeck.
- hmry 3mo agoI do agree Vulkan is too cumbersome, but OpenGL is definitely obsolete. The OpenGL API with its binding-based approach is also very confusing for beginners, but the replacement Direct State Access API came too late (after Apple already decided they would deprecate OpenGL, so it never got supported on macOS). And the fact that the GLSL parser and compiler are part of the driver means there are tons of hardware-specific bugs and miscompilations. Intel integrated drivers on Windows are notorious for being especially buggy. All of those make OpenGL a pretty poor target for learning. Personally, I would recommend WebGPU to people who want to get into graphics programming. It's very similar to DirectX/Metal, and like a more streamlined Vulkan. The WGPU implementation of WebGPU has a C API, which also has C++ headers, and a native Rust API. And you can also use WebGPU in your browser from JavaScript, if you don't know any native languages.
- sigmoid10 3mo agoWhat is the current status of WebGPU support in browsers? I tried to get into it a while ago go, when the writing was already on the wall for WebGL. But WebGPU just wasn't there yet, so I had to stick with WebGL.
- pjmlp 3mo agoAs always, a decade behind current hardware capabilities andnl browser vendors refuse to have debugging tools. You need a native build for proper GPU debugging, or do shader printf debugging style. However, it is what is available.
- m-schuetz 3mo ago> Personally, I would recommend WebGPU to people who want to get into graphics programming. Unfortunately WebGPU is like 5 years behind OpenGL 4.6, which is already 8 years old. WebGPU is pretty ancient.
- hmry 3mo agoWebGPU only got started in 2021, so Im not sure what you mean. Could you explain? (Or are you thinking of WebGL?)
- flakiness 3mo agoA data point: "OpenGL ES is still supported on Android, but is no longer under active feature development. Vulkan offers the following advantages over OpenGL ES" "Vulkan is the preferred Android interface to the GPU. Android 15 and up includes ANGLE as an optional layer for running OpenGL ES on top of Vulkan." https://developer.android.com/games/develop/vulkan/overview https://developer.android.com/games/develop/vulkan/overview
- cyber_kinetist 3mo agoAndroid smartphones are notorious in having low-quality Vulkan drivers full of bugs and spec violations... (I'm looking at you Qualcomm!) A data point: SDL3-GPU maintainers announced that they will not give a shit about Android support, since there's just too many devices that haven't properly implemented the Vulkan spec. (https://github.com/libsdl-org/SDL/issues/12652#issuecomment-2755770682 https://github.com/libsdl-org/SDL/issues/12652#issuecomment-...) Another data point: the current maintainer of the renderer portion of the Godot engine suffering through all the bug reports from Android devices (https://github.com/godotengine/godot/issues?q=is%3Aissue%20state%3Aopen%20android%20vulkan https://github.com/godotengine/godot/issues?q=is%3Aissue%20s...)
- m-schuetz 3mo agoIronically, the Vulkan discord always complains about the bad support of Vulkan on mobile devices, and how OpenGL ES is still better supported.
- 3mo ago
- fp64 3mo agoOpenGL is limited to 4.1 on Apple platforms if I am not mistaken, and will not get updated ever. So you will run into missing features eventually on some platforms, e.g. SSBOs are really nice but you can't them use on Apple devices. For me, a much stronger argument against OpenGL is that is requires a global state. This often leads to bad design, is miserable to multi-thread, and is rather tedious to port to Vulkan. I have spent several years fighting with multi-threading applications doing all sort of things in OpenGL and it is not great. Yes, Vulkan is extremely painful to set-up and you have to think about a million things you might not really care about directly, but honestly, I would also recommend against starting anything serious in OpenGL. To get your hands wet maybe, as with a couple lines you can get something running..
- cyber_kinetist 3mo agoI think if you're trapped in the Apple ecosystem then Metal is your only production-quality option. But beginner-level learning material for it is quite sparse, so it's better to transition from OpenGL to Metal rather than learning Metal from scratch. (If you're an experienced graphics dev, you should be able to follow up on Metal by just reading their example source code)
- fp64 3mo agoMoltenVK is pretty good I've been told
- cyber_kinetist 3mo agoNope, the limitations are just too huge for actual usage. Heard Godot Engine tried to use MoltenVK for macOS but experienced too many issues so they just developed a Metal backend. The fundamental problem is Metal 3 is just too high-level to be able to emulate all of Vulkan's behavior. The new Metal 4 API (which is more low level and similar to Vulkan in many ways) might have improved things recently, but sadly MoltenVK hasn't been rewritten to this new API yet.
- 3mo ago
- corysama 3mo agoI still think that OpenGL is a better place to start learning 3D because there is so much less bookkeeping to do regarding memory and concurrency vs. Vulkan. I'm working on a "Post-Modern OpenGL" tutorial that exclusively teaches the most "modern" (merely a decade old) APIs and practices of GL 4.6. But, writing is slow going... If you are going to use Vulkan, check out https://howtovulkan.com/ https://howtovulkan.com/ Vulkan started with a lot of compromises to make mobile hardware happy at the expense of making everything overly complicated on desktop. Over the past decade, desktop devs have managed to get a lot of features added to make Vulkan on desktop more sane. How To Vulkan covers that newer approach. This recent video "It's Not About the API" https://www.youtube.com/watch?v=7bSzp-QildA https://www.youtube.com/watch?v=7bSzp-QildA shows how simple it can be if you let it. And, if you are on a Mac, folks who use Metal like it a lot. Don't worry about lock-in. Once you learn the basics, knowledge is easily transferable to DX12 and Vulkan. You should plan to write 3 or 4 renderers to throw away anyway :P
- cyber_kinetist 3mo ago> I'm working on a "Post-Modern OpenGL" tutorial that exclusively teaches the most "modern" (merely a decade old) APIs and practices of GL 4.6. But, writing is slow going... Is it the AZDO stuff? Quite interested, since there isn't really much information on the Internet about it rather than some slides and GDC videos.
- corysama 3mo agoYep. It's my thesis that early GL APIs feel beginner-friendly because they are so hand-holdy, one-step-at-a-time. But, they end up more complicated when you get serious and they instill bad practices. Instead, the "modern" APIs allow you to leverage your pre-existing knowledge of "allocate arrays of structs and start indexing them." That's not trivial. But, it is already familiar. And, it ends up a lot better in the end compared to "Invoke whole lot of functions to manipulate a hidden state machine." You can find a little info on Modern OpenGL at https://github.com/fendevel/Guide-to-Modern-OpenGL-Functions https://github.com/fendevel/Guide-to-Modern-OpenGL-Functions, https://juandiegomontoya.github.io/modern_opengl.html https://juandiegomontoya.github.io/modern_opengl.html, https://ktstephano.github.io/ https://ktstephano.github.io/, https://patrick-is.cool/posts/2025/on-vaos/ https://patrick-is.cool/posts/2025/on-vaos/
- criddell 3mo agoIt's so much easier than Vulkan or writing shaders and the performance is more than good enough for a lot of applications. I wonder if somebody has written a adapter layer to write old OpenGL and translate it on the fly to Vulkan?
- hmry 3mo agoMesa has Zink which translates OpenGL to Vulkan. AFAIK Asahi uses it because they only wrote a native Vulkan driver for the hardware, no native OpenGL driver. Apple themselves also don't ship a native OpenGL driver anymore, only a layer that translates OpenGL to Metal.
- flohofwoe 3mo ago> write old OpenGL and translate it on the fly to Vulkan Apple's OpenGL on macOS and iOS has been a shim over Metal for a very long time. The feature set is stuck somewhere between GL 3.x and 4.1 though (e.g. no compute shaders), but not for technical reasons.
- raincole 3mo ago> It's so much easier than Vulkan or writing shaders Even if you use OpenGL you still need to write shaders.
- throwaway2046 3mo ago> Even if you use OpenGL you still need to write shaders. Not in OpenGL 1.x
- jplusequalt 3mo agoOpenGL 1.x is older than the hills.
- badsectoracula 3mo agoIt is also the simplest and most widely available one[0], working from decades old PCs to whatever is latest one, not only from the official drivers but also 3rd party implementations[1] that target other lower level APIs for environments where there isn't an official implementation. [0] on open platforms at least [1] it most likely wont be a 100% compliant one (even SGI had trouble on that front :-P) but in practice it'd be usable
- PcChip 3mo agoOpenGL works fine, I'm using it in my hobby game engine (shaders, not the old fixed-function OpenGL) it also will run just fine on windows or Linux using Proton with no issues if I had to learn Vulkan from scratch instead, that would have been a whole different animal...
- cyber_kinetist 3mo agoIn 2026: Yes yes, please please learn this if you're beginning computer graphics. This is basically the One and Only Holy Bible of graphics programming, and dealing with a slightly outdated and weird API doesn't make it worse even a teeny bit. You will never get the same quality of fundamental education material from any of the other tutorials (especially Vulkan ones, since most of them assume you already know the basics and delve straight into writing thousands of lines of code that doesn't even perform better than OpenGL). You need to first learn the really basic things like homogeneous coordinates, matrix transforms, vertex and fragment shaders, various shading models like Phong and PBR, multi-pass rendering, etc, before actually diving into lower-level details where you want to optimize things. Vulkan and DX12 are currently flawed APIs that are unnecessarily complex and doesn't even match the performance characteristics of current-gen hardware (see the titular post: https://www.sebastianaaltonen.com/blog/no-graphics-api https://www.sebastianaaltonen.com/blog/no-graphics-api) - if you want to really learn the low-level details you should start diving into something like CUDA or get into graphics driver development (start by reading Mesa open source driver code - which you will then learn why Vulkan is flawed)
- troupo 3mo ago> You will never get the same quality of fundamental material If you're looking for fundamental material, the last thing you want is learning a very (not slightly) outdated and weird API. > Vulkan and DX12 are currently flawed APIs that are unnecessarily complex and doesn't even match the performance characteristics of current-gen hardware And OpneGL is worse
- cyber_kinetist 3mo ago> If you're looking for fundamental material, the last thing you want is learning a very (not slightly) outdated and weird API. I've never seen a more detailed tutorial than LearnOpenGL that actually goes through the concepts of graphics programming thoroughly and actually make things other than just "learn how to use the API". That alone should be enough to cement the site's longevity. > And OpneGL is worse It's never late to learn Vulkan / DX12 after learning learnopengl.com! The value of learnopengl.com isn't in the APIs, it's about learning the basic concepts of graphics programming. If you start learning with Vulkan without any prerequisite knowledge, you'll be bogged in low-level details from the start that isn't really related with learning the actual fundamentals. (And you'll probably have to unlearn Vulkan and DX12 again once a new API has surfaced)
- grishka 3mo agoOpenGL is the only truly cross-platform graphics API out there. Vulkan isn't on Apple platforms, unless you use MoltenVK which implements it on top of Metal. Also I don't know why, but Windows games tend to use Direct3D even though afaik GPU drivers do implement Vulkan on Windows, so there must be a good reason for that. It's also much easier to grasp than Vulkan, Metal, or Direct3D.
- reactordev 3mo agoOpenGL is deprecated and version locked on Mac/iOS.
- deleted 3mo ago[deleted]
- pjmlp 3mo agoContrary to urban myths, OpenGL never was a big thing on game consoles. Windows official API is DirectX, OpenGL and Vulkan use a plugin API, ICD, which is nonetheless DirectX underneath. https://learn.microsoft.com/en-us/windows-hardware/drivers/display/loading-an-opengl-installable-client-driver https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
- grishka 3mo ago> OpenGL never was a big thing on game consoles. I've never tried developing anything for a 3D-capable console, but I've always had the feeling that their graphics APIs are bespoke, thin abstraction layers on top of the raw graphics hardware just so you don't have to poke the GPU registers directly.
- pjmlp 3mo agoYes, they are quite low level, hence how painful Vulkan happens to be, as its design was driven by console vendors feedback, and based on Mantle, basically AMD trying to make a PC API close to how modern consoles work. https://github.com/sigmaco/mantle-docs https://github.com/sigmaco/mantle-docs https://ir.amd.com/news-events/press-releases/detail/466/amds-revolutionary-mantle-graphics-api-adopted-by-industry-leading-game-developers-cloud-imperium-eidos-montreal-and-oxide https://ir.amd.com/news-events/press-releases/detail/466/amd... While there have some support, Playstation 3 had OpenGL ES 1.0 with Cg for shading, Wii had a GL like API with GLSL subset, and SWitch does support GL 4.6/Vulkan, they were never fully adopted by devs, rather favouring the native ones.
- deleted 3mo ago[deleted]
- aarongeisler 3mo agoI still write games using OpenGL for the reasons described in the comments here. I've had very good results with it despite it being "old". It works on my MacBook, PC, and SteamDeck and it has yet to surprise me.
- vblanco 3mo agoIm the author of vkguide.dev and i disagree. I wrote that tutorial specifically for people that have already gone through learnopengl and want to learn vulkan. The core problem with the modern apis is that they are so incredibly complicated that they will kill any newbie on the spot. When the student still doesnt really know what a mesh is, having them setup GPU side memory allocators and graphics compute pipelines is absurd. Opengl meanwhile is significantly easier, and will give them the important terminology and math required to do graphics. Once the student has learned opengl and wrote a small renderer with a few basic techniques, moving to vulkan or DX12 will happen far more smoothly. In particular, learnopengl explains a lot of basics like transformation coordinates, what a mesh is, and other similar "basic knowledge", while all vulkan and dx12 tutorials skip through that because they are meant for a much more experienced audience.
- coffeeaddict1 3mo ago> The core problem with the modern apis is that they are so incredibly complicated that they will kill any newbie on the spot. I would agree if by modern you mean DX12 or Vulkan, but WebGPU (and maybe even Metal) are quite decent.
- m-schuetz 3mo agoWebGPU has the issue that feature/capability-wise it is essentially 5 years behind OpenGL 4.6, which came out 8 years ago. And the other downside being that it adopted old Vulkan concepts that even Vulkan started to ditch, like render passes and static pipelines.
- pjmlp 3mo agoWithout any sort of proper debugging tools.
- coffeeaddict1 3mo agoFor beginners that's irrelevant. WebGPU has more than enough features for beginners to learn about graphics programming. Not just that, once you're used to WebGPU, going to Vulkan will be much easier than the transition from OpenGL.
- gspr 3mo agoRelatedly: could someone recommend a Vulkan introduction for people who don't "just want to make it work"? I understand the fact that Vulkan abstracts away a lot less of the rendering device than OpenGL does – that may be a strength or a weakness, but either way I'd like to understand. It seems a lot of introductions just skip over it all while apologizing for the boilerplate. I think I once bookmarked an article which takes an interesting approach, namely doing all rendering with Vulkan compute! Does that ring a bell to anyone? I can't find it again. It seems very appealing to me. It may not be the best way to approach graphics, but I know a lot more about computations in general than I do graphics in particular. And knowing Vulkan Compute would help me in lots of ways, so it I can also use it for graphics that's a nice bonus.
- jplusequalt 3mo ago>could someone recommend a Vulkan introduction for people who don't "just want to make it work"? Khronos has a tutorial that walks you through getting a triangle on the screen, to rendering a glTF model, all the way up to how you go about making a simple engine. But I'm not sure what you mean by "understand". If you want to understand the graphics theory, Vulkan tutorials aren't going to teach you that.
- gspr 3mo ago> But I'm not sure what you mean by "understand". If you want to understand the graphics theory, Vulkan tutorials aren't going to teach you that. I meant understand the Vulkan-specific minutiae of setting everything up for either graphics or compute. There's an order of magnitude or two more of it than for OpenGL, and lots of tutorials seem to skip it and focus on the graphics. I'd like to understand what all that setup does and why it's done a particular way.
- jplusequalt 3mo ago>I'd like to understand what all that setup does and why it's done a particular way. That's something you'll only understand after trying to build something non-trivial with an older graphics API like OpenGL.
- pton_xd 3mo agoThis advice is basically like a teenager wanting to play electric guitar to jam out a few rock tunes, but their parents insist on learning classical guitar instead because starting with the fundamentals is the only "real" way to become a great musician. Meanwhile the kid loses interest and moves on to something else.
- trq01758 3mo agoExcept that Vulkan is the classic guitar here, you will suffer with it before your first triangle while with OpenGL you can jam almost instantly.
- imtringued 3mo agoThis analogy doesn't work. Vulkan is more like assembling your own electric guitar from scratch, while OpenGL is a used out of shape electric guitar you found on the flea market that is long since out of production. If you're in it for learning how to play music, the flea market guitar will serve you better.
- m-schuetz 3mo agoVulkan is garbage. It's completely needlessly overengineered. Like, you literally have to write 50 lines of code just to allocate GPU memory, which is a one-liner in other APIs like CUDA. These 50 lines include things like heap type shopping and usage flags, that are entirely pointless for modern desktop GPUs. I know there is VMA, but that is a poorly made bandaid over a badly designed API, and barely addresses one out of 100 UX issues with Vulkan. There is a reason so many are sticking with OpenGL. OpenGL is fairly bad, but at least it isn't Vulkan. But I can agree with CUDA. CUDA is great, in a large part because it actually offers an easy to use API.
- ivanjermakov 3mo agoWonder how this opinion will age. Won't be surprised if in 10 years OpenGL will be more widely supported and used than Vulkan. It's the Lindy effect after all.
- topspin 3mo agoAll I can say for certain is that 10 years from now there will great OpenGL-to-VulcanMetalWhatever translators, at least as good as the ones already built-in to several graphics stacks today, and the learnopengl.com tutorial and examples will still work. So unless you actually intend to compete with AAA game engine designers, you may safely invest your time in OpenGL.
- imtringued 3mo agoThe anti OpenGL sentiment is so strange to me. OpenGL is basically supported everywhere even in places where Vulkan is unpopular. Any sane person who actually wants to do low level graphics programming should rather work on the libgodot effort since it will make it much easier to use Godot as a wrapper around Metal and Vulkan by defining a custom RenderingServer without even touching the Godot scene graph or having Godot own your application lifecycle.
- fasterik 3mo agoOpenGL is arguably still better for learning the fundamentals of computer graphics. All you really want early on is a simple vertex and fragment shader up and running so that you can learn how to move a camera around, transform objects, basic lighting and texturing, etc. Vulkan is overkill for that. If you follow the LearnOpenGL tutorials you'll get as far as HDR lighting and shadows. At that point you'll be better equipped to understand an API like Vulkan and probably a lot more successful at porting an engine over to it.
- jplusequalt 3mo agoTrying to learn Vulkan as a first API is doable, but you'll probably burn yourself out by the time you've gotten a triangle on the screen (unless you vibe code everything, in which case, you're lame).