[ridiculousthrow]

Graphics Programming needs to be restructured.

There’s a lot of focus on API driven learning. Vulkan, D3D12, 11, etc.

Wrong approach.

Learn fundamentals of what the hardware is capable of. For each feature, write down a few ideas of how you could use it by itself. Write down a few ideas of how you could combine it with other features. Think of “I want to do X. What features can allow me to do that?” The APIs, although they are not easily interchangeable, use the same hardware and can often do the same things with a bit of effort.

[cyber_kinetist]

The problem is that when you're starting out on graphics, you don't even know what you're capable of doing with the hardware that you have, and the distance between manipulating things on the hardware and putting something on the screen can seem dauntingly far away.

My advice, start out with OpenGL 1 (the old glBegin()/glEnd() stuff) or Raylib (raylib.com) where you begin to get accustomed to really basic stuff (primitives, transformations, etc.). Then do the LearnOpenGL tutorials to learn modern graphics concepts (vertex buffers, shaders, render passes, etc.) Once you've done this you might have enough knowledge to make a simple game/visualization/application, and you'll know yourself if you need to study D3D12/Vulkan or not.

[Jensson]

But it is kinda hard to ponder ideas to do on a GPU when you don't know how a GPU works and what it is capable of. You have to learn at least one API to start thinking about what to do on a GPU, otherwise it is like being a non-programmer brainstorming programming ideas.

[ginko]

>The APIs, although they are not easily interchangeable, use the same hardware and can often do the same things with a bit of effort.

Actually it's the other way round. GPU architectures can vary wildly especially when you include mobile GPUs which are tiling architectures. Graphics APIs are the least common denominator interface that makes targeting all of them possible.

[pjmlp]

Not at all, hence why AAA game engines have all been based of plugin architecture for their backends, which allows them to take the best advantage of each hardware, no need for least common denominator interface.

Those that try to target everything with a single API are fooling themselves, hence why in the end they all end up with extension spaghetti and multiple code paths, while pretending to still use a single API.

[aliswe]

care to elaborate even further?

[pjmlp]

Sure, OpenGL is portable and works everywhere, right?

Well, first of all OpenGL and OpenGL ES aren't the same thing, so depending on the versions, the set of APIs differ, already there you have some set of alternative code paths.

Then some features are only available as extensions, so you need to query for them, and then programm accordingly what is available.

Some hardware features have different extensions per vendor for the same hardware capability, so yet another execution path.

The shader compilers are quite different across vendors, some more strict than others, or different set of GLSL extensions, so yet another execution path.

Finally, even when everything works, there are driver or hardware bugs to work around, yet another execution path.

In the end it is OpenGL, portable everywhere, yet the engine looks like it is using multiple kinds of APIs just to work around every kind of issue.

Naturally having a rotating cube available everywhere is easy, the problem is having a proper engine with Unreal like capabilities (we are talking about AAA here).

[cyber_kinetist]

When you're learning instead of making something for production, it may be wise to focus on a single platform (whether it be Windows, Linux, or mobile) and start from there.