I still teach OpenGL ES 3.0

For teaching I would generally use the web browser via WebGL2 or WebGPU, just because those APIs require much less boilerplate in the browser environment to get to your first triangle and the edit-test-loop is pretty much instant.

Better than OpenGL, but don't expect that much improvements coming into their way, other than what the Chrome team might feel like pushing, as I doubt Firefox or Safari teams have much left to say about where it goes beyond version 1.0.

Interacting with webgpu from wasm is also often slower than webgl because the api is lower level and causes more gc overhead on js side.

https://nehe.gamedev.net/

Talk about nostalgia!

Good times.

The tutorials and hands on coding examples made me understand how to program with GPUs. I loved them because at the time, khronos was still in its infancy and just started out with GLES extensions and the whole WebGL ecosystem.

Meanwhile I kind of believe that learning where it came from (fixed function pipeline, buffer/texture and uniform problems etc) makes a lot of sense to learn first so you start thinking in shader computation pipelines much easier, as you understand the whys and whens much better.

You can implement in software whatever you want and just handwave specific parts to GL, like rasterization. The rest of the boilerplate code will be minimal.

In new APIs you are bound to write 100s of lines of boilerplate code to get to the point. In the time you should be learning about barycentric coordinates, you are still learning about descriptor sets. And still, you don't learn about rasterization, texture mapping, clipping, face culling, because they are still fixed pipeline.

The only problem with learning with 100% cpu rendering is that you need some patience before seeing beautiful stuff because you need to learn/implement everything up until that point.

A fundamental shift in thinking that got me into high performance graphics programming and parallelized image processing, the "Aha" Moment, is being forced to express how to calculate the final pixel independently, without having access to neighboring pixels of the same output buffer, confined to the straight jacket of the fragment shader. OpenGL with it's combination of hand-holding and relative simplicity as compared to Vulkan and limits of a predefined shader pipeline as compared to a pure software implementation is exactly the thing that I needed to get into graphics programming. It's an excellent jump in point I think.

Could you recommend any resources for learning that?

There's WebGPU (probably the best option for teaching), D3D11 and Metal.

And (shameless plug): sokol-gfx tries to find a balance between simplicity and modern 3D APIs:

https://github.com/floooh/sokol

Demos with links to C source and shader code:

WebGL2 backend: https://floooh.github.io/sokol-html5/

WebGPU backend (has a couple more demos which use features not available on GLES3.0/WebGL2, like compute shaders): https://floooh.github.io/sokol-webgpu/

My take is that older versions of GL feel nicer to teach to beginner programmers because they have so many specific functions to do each specific thing. You can have a lot of verbose, step-by-step instruction. But, much of what you have to convey is understanding of a convoluted interface to a hidden state machine. And, the one-step-at-a-time nature of the old interfaces build bad habits that don’t scale when you get serious.

With 4.6 we can get Direct State Access, Programmable Vertex Pulling and MultidrawIndirect. With that we can move the complexity from “lots of functions to manipulate a state machine” to a few functions that strongly resemble using malloc and memcpy to work with arrays of structs. That’s not trivial. But, it should be extremely familiar. It’s visible, flexible, scalable, and it sets you up to move on to Vulkan after you’ve learned the essentials of 3D rendering.

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.

If you really want to see why all the cruft is there, and how much you could remove if you dropped support for older hardware, look no further than Sebastian Aaltonen's "No Graphics API" blog post (which he actually implemented too): https://www.sebastianaaltonen.com/blog/no-graphics-api/

E.g. if CPUs would have closed ISAs and heavily guarded IPs, you'd also need a 'driver' and an 'OpenCPU API' to make any use of them (of course the public ISA of a CPU is essentially the driver interface baked into the hardware).

The other big difference is focus on decent single-thread performance for CPUs versus performing thousands of small tasks in parallel on GPUs, but each one slowly. This difference causes a different programming model (e.g. running an entire application in a single 'main' function from start to finish, versus spawning small specialized tasks which are running across hundreds of threads).

And the specific problem with Vulkan is that it tried to solve two conflicting requirements: on one hand being an explicit low-level API without 'magic abstractions', on the other hand supporting very different GPU architectures (especially the mobile GPU zoo). The resulting mess was quite predictable to be honest...

CUDA being the winner (closed source, not really usable on non-nvidia GPUs) between those 2 and nvidia not wanting to open their competitive advantage to the competition for the niche of non gamings uses / scientific computing (and later AI, which became a huge win for nvidia).

vulkan came around after as this open thing (based on a previous attempt by AMD called mantle) that's trying to break down the leaky abstractions and the divide between language for graphics & video games and separate language/frameworks for gpu non-graphic computing with the promise of giving more control and more room for squeezing performance from the hardware at the cost of more complexity with the idea that you'll probably build your own abstractions on top of it for your subset of applications.

If GPU were from the get go designed as a parallelism tool first and video game tools second the hardware architecture and the language would probably be different than today and simpler (and if the competition between the duopoly didn't sabotage things)

don't forget that the drivers for GPUs would until recently get updates to patch specific video games for performance issues (not sure if they still do that ?)

A bunch of the complexity comes from having to write both client and server, and the communication protocol between them, then some more comes from the client being responsible for spinning up the server. As with every network service, client/server traffic is the slowest part of the architecture, so a bunch of complexity then comes from having to minimise the amount of network calls (or draw calls, in this case).

Then you hit the part where all of this is performance critical (soft-realtime requirements), so the whole thing is geared towards “writing your own userspace IP stack in C++” rather than “writing a flask application in Python”.

Generally GPUs punish you more by bad performance if you don't optimise your code.

But GPUs have thousands of cores, which means if you want any benefit, the smallest data type you must use is something like array[n * 1024], or your GPU is wasted doing nothing. So you must shape your programs into that memory model or you're just wasting your time (and GPU).

That's >50% of the problem.

There are a few libraries that try to abstract over all this indirection but all the graphics APIs themselves are lower-level so you're left to do all of that yourself.

https://docs.swmansion.com/TypeGPU/

https://github.com/google/toucan

But also partly in the fact that the GPU is specialized for certain operations over a CPU. It wants and need to obtain data in a different way from a CPU to maximize throughput. So language constructs are designed around making sure developers stay on this fast path. The complexity can be seen as some intentional gatekeeping to signal that this kind of programming is only for specific kinds of problems.