hckrnws
Learn OpenGL, extensive tutorial resource for learning Modern OpenGL
(learnopengl.com)
266
141
by ibobev
by ibobev
After you've learned it, you can start learning CUDA if you want to do some more low-level compute stuff on the GPU (sorry, but you should just buy an NVIDIA card, CUDA is just that good). Or if you actually want to just make things but want to use a nicer cross-platform graphics API than OpenGL, then I recommend SDL3. (Or use Metal if you want to make macOS exclusive apps - it's actually a quite nice API)
Vulkan or DX12 are currently flawed APIs that are unnecessarily complex and doesn't even match the performance characteristics of current-gen hardware anymore. (see the titular post: https://www.sebastianaaltonen.com/blog/no-graphics-api). However if you want a computer graphics career (either in the game industry or in other niche domains) having experience with these APIs will be beneficial since these are what many production apps are currently stuck with - though honestly the job market for graphics really suck nowadays. (The biggest sector was triple-A game companies with their own engines, but the game industry is imploding right now...)
Then pick up something like Modern OpenGL and you'll easily intuit if you've put in the hard yards above, which parts of this pipeline are fixed and which are programmable on a hardware designed specifically to do 3D. It just so happens that the same is reusable for compute and there you go with all the D/ML jazz. After this, read up on the HW architecture of GPU's (the literature is sparse as these are vendor locked) but realtimhrendering books has chapters on it and you can find out why Vulkan, DX12, Metal are in vogue now and OpenGL has been deprecated.
[1] https://pikuma.com/courses/learn-3d-computer-graphics-progra...
[0] https://github.com/floooh/sokol [1] https://wiki.libsdl.org/SDL3/CategoryGPU
Then I realized you're just writing code that executes on all pixels sequentially. That made it easier to understand
or in parallel?
I would say that's one thing that the "stop killing games" movement would not see coming. I am not expert enough in graphics programming.
I am wary because lately, I realized I could not run blender 4.5 on a thinkpad from 2014, on windows, I had to use a 3.x version because that thinkpad has a chipset.
Generally in software, making things work for a long time doesn't generate profits, and it feels like opengl is getting a bit old already. I hope it won't happen and people can contradict me here.
I definitely recommend it to anyone interested! Honestly one of the biggest things it helps with is explaining the setup boilerplate for OpenGL.
The biggest issue with c# dev is OS specific window management. CLR doesn't have good wayland support yet if you're trying to do this from a modern Linux distro.
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.
[dead]
Nothing in real time graphics _actually_ is cross platform. You are always programming a vendor hardware.
"Cross platform" really has no value in graphics programming, honestly, when discussing the lowest level programmable api.
You always need to explicitly say which platforms you target, and then test on those platforms.
The main questions should be "on which platform will my users run it" and "can I debug and test this".
So if you are starting out - pick out the easiest api for you. Don't go looking for universality as a value on it's owm (if you want universal rendering, choose CPU rendering. if you want high perf - choose your GPU platform(s) explicitly).
The "universal" nature of WebGPU with the "web" focus feels a lot like the graphics API equivalent of WASM. In that regard there are also some interesting projects/opportunities.
Having shipped non-trivial WASM code in two projects That's not a positive thing. WASM is stuck in zone between living and the dead - just good enough (barely) to merit creating production code when you need the perf in browser but not good enough to register as industrial quality tool as it's not possible really to debug a WASM application.
If you really, really need the perf in your browser app, WASM may be the only option, but it's not really a good one.
[deleted]
The textbooks Real Time Rendering and Physically Based Rendering are far more deserving of such claims.
The RTR book doesn't teach you the programming side of things at all, the material is more theoretical and reads more like a reference book. Most importantly it doesn't have any examples with full source code, so it's not a friendly book to follow for beginners. The PBR book is much better in this regard, but it mainly focuses on offline ray tracing / path tracing which is bit of a distinct topic from conventional real-time rendering on the GPU.
[deleted]
Why is that? Is it because of AI automating many steps of game creation?
Then layer in some incredibly bad bets like Game Pass for XBox and audience tastes shifting away from splashy big budget releases making them an “inevitable” success. It’s left middle aged execs heads in a twist.
In a broader view discoverability is the big problem for everyone. People are hoping in the short term that reducing budgets and scope will save things but all that will do is make the discoverability problem worse. So everyone’s hot under the collar for codev, offshoring, “the Hollywood model*” and so on without looking at the downstream effects of everyone doing that.
AI has largely impacted games by sucking all the available money away and the discoverability problem has made what little is left extremely conservative.
* - This has been a thing for at least three decades now in games despite the obvious collapse of this model and Hollywood.
Add to that a mass-rejection of the media produced by the western DEI priest caste resident in game studios (the players buy games as they used too from china, korea, japan, the slump literally only affects western studios). Nobody goes to a preachy church for escapism. Bad bets all around.
You're absolutely wrong here and without backing it up with strong justification.
FWIW, I work at a FAANG as a HW/SW GPU Engineer, have enough experience to not have any need to do this course but did so to confirm it's appropriate and found it of top notch quality. We don't have enough GPU engineers and recommend this as one of the initial courses when we hire from other domains.
Also for your confusion it truely is parallel, the best kind in fact. The trivial kind, each pixel's color is independent of every other pixel so you can and thus want too do them ALL at the same time!
You want to start with OpenGL because the API is organized roughly around these high level concepts. Starting with something like Vulkan means you're dropped straight into hundreds of lines of low level boilerplate setting up VkCommandBuffers and VkRenderPasses and VkPipelines and shaders, and all this GPU programming, and it's all just bewildering if you're used to thinking about things at the high level first, or just want to draw a fucking triangle on the screen.
I would agree if by modern you mean DX12 or Vulkan, but WebGPU (and maybe even Metal) are quite decent.
If you must use a modern api to learn for whatever reason, go with vulkan and use dynamic rendering and buffer device addressing.
Even if OpenGL doesn't get new features what exists now will continue to work for decades.
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).
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.
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.
If you are going to use Vulkan, check out 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 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
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..
If you're in it for learning how to play music, the flea market guitar will serve you better.
But I can agree with CUDA. CUDA is great, in a large part because it actually offers an easy to use API.
It's also much easier to grasp than Vulkan, Metal, or Direct3D.
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/d...
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.
https://github.com/sigmaco/mantle-docs
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]
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) - 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)
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
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)
I wonder if somebody has written a adapter layer to write old OpenGL and translate it on the fly to Vulkan?
Apple themselves also don't ship a native OpenGL driver anymore, only a layer that translates OpenGL to Metal.
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.
Even if you use OpenGL you still need to write shaders.
> Even if you use OpenGL you still need to write shaders.
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.
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...
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.
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.
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.
[deleted]
With the old OpenGL API you could do this in like 10 lines of code (probably even less with SGI's GL).
With the new/shader-based API, well... https://learnopengl.com/Getting-started/Hello-Triangle
Vulkan - I don't even want to know.
Almost 1000: https://github.com/Overv/VulkanTutorial/blob/main/code/15_he...
(From Chapter 15 of the Vulkan Tutorial from vulkan-tutorial.com)
Quite right.
After 15 years, browsers vendors still don't care about 3D APIs on the developer tools, you need to have a native version and hope that the issue is actually on your code and not something that the browser does.
Because of its nature and the browser sandbox, you have no idea if the application is actually working on customer browsers, or even be able to have workarounds like on native APIs.
Finally it lags a decade behind hardware capabilities being surfaced on the API.
However there is nothing else on the browser.
The only positive thing is being 3D APIs designed with managed languages in mind.
...as others have said, this is a solved problem and has been for quite a while:
https://marketplace.visualstudio.com/items?itemName=ms-vscod...
I might even go that far and say that this solution is on average more robust and more responsive than debugging native code in Xcode.
Then again perhaps the devx was just not as bad as I expected given how often I had heard this warning.
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.
You need a native build for proper GPU debugging, or do shader printf debugging style.
However, it is what is available.
Unfortunately WebGPU is like 5 years behind OpenGL 4.6, which is already 8 years old. WebGPU is pretty ancient.
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.
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://juandiegomontoya.github.io/modern_opengl.html, https://ktstephano.github.io/, https://patrick-is.cool/posts/2025/on-vaos/
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.
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-...)
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%20s...)
Until now it has been pretty much only usable on Google and Samsung phones.
Why would you do that? Why would you want to learn an API for graphics cards from the 90s instead of an API for the graphics card from the 2010s?
> The value of learnopengl.com isn't in the APIs, it's about learning the basic concepts of graphics programming.
Then you should learn concepts of graphics programming that isn't defined with code snippets like
#version 330 core
struct Material {
> And you'll probably have to unlearn Vulkan and DX12 again once a new API has surfaced
Strange. You "have to unlearn a newer API when an even newer one has surfaced, but you should learn this ancient API anyway".
Edit. See also another comment: https://news.ycombinator.com/item?id=49027094
It does not cover all the fundamentals. It hardly explains the necessary math.
Is it? All the fundamentals are tied to how it's done in OpenGL with somewhat sparse explanations in between. And many "fundamentals" are literally something like
#version 330 core
struct Material {https://learnopengl.com/PBR/Lighting
Even the code snippets start with "#version 330", if you implement these in another tech stack (say vulkan+slang) the relevant shader code would look very similar. It's quite strange to me that you think just because of "#version 330" it's not about fundamentals, tbh.
I disagree. OpenGL is truly bad, but there is no API in this world as bad as Vulkan.
[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
That's something you'll only understand after trying to build something non-trivial with an older graphics API like OpenGL.
If you don't mind - what's your specific setup when debugging Sokol, I might start from replicating that workflow?
And only "works" for specific languages.
It should also work for all compiler toolchains that generate DWARF debug info, which is pretty much standard across all compiled languages, otherwise gdb or lldb couldn't be used either with those languages (Microsoft of course does its own thing, as is tradition, but its not like msvc supports wasm output in the first place - Blazor oth appears to support wasm debugging in VS and VSCode)
Given how bad most of WebAssembly tooling still is to this day, versus native languages, I was kind of sceptic.
Another link floated to the top of HN discussion just now, and every sibgle link there is better than these "fundamentals": https://news.ycombinator.com/item?id=49022038 E.g. "Computer Graphics from Scratch" https://gabrielgambetta.com/computer-graphics-from-scratch/ or Mathematics for Computer Graphics https://www.amazon.co.uk/Mathematics-Computer-Graphics-John-...
#version 450
struct Material {