The one and only Holy Bible of Graphics Programming. If you're starting to learn computer graphics, just study through the entire site and do the examples one by one. It doesn't matter one bit that it uses a slightly outdated API called OpenGL - you're supposed to learn how to render things first, not about some weird obscure hardware / driver details!
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...)
I've heard that learning WebGPU is a pretty decent alternative, it's cross-platform, has runners that are non-web, and has some of the niceties of Metal without being platform lock-in
" it's cross-platform"
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).
Indeed, and a well regarded WebGPU guide is also trending on the front page at the same time :P
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.
"The "universal" nature of WebGPU with the "web" focus feels a lot like the graphics API equivalent of WASM"
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.
>The one and only Holy Bible of Graphics Programming.
The textbooks Real Time Rendering and Physically Based Rendering are far more deserving of such claims.