A continuation of the discussion from here.
I think this point was mentioned in the presentation, but I think that’s precisely why beginners will jump toward Vulkan. The current OpenGL atmosphere has way too many unknowns and beginners will be looking for something that offers them a better understanding of what the GPU is doing.
Oh beginners will absolutely jump towards Vulkan. They’ll be attracted by talk about performance, “close to the metal”, and other such things. Vulkan’s new and shiny, while OpenGL is old.
That doesn’t make them right. Nor does it mean that Khronos should support them. Indeed, what Khronos needs to do is widely advertise that Vulkan is not appropriate for beginners. They need to send them to OpenGL or somesuch for a while, until they’re ready for it.
Beginners who have a bad initial experience with a Khronos technology will likely be very upset and not try to use the “old” OpenGL. So Khronos needs to make it clear that Vulkan is not for everyone.
This is not about the “600 lines of code” issue. I’ve written material that attempts to teach beginning graphics programmers based on core OpenGL. So I’ve written ways to teach beginners using “Hello World” programs that are quite verbose. I’m well aware of what you have to do to get a beginner into the right head space.
And that right there is the fundamental problem with Vulkan for beginners.
While I have written learning materials, I’m also the principle curator for the OpenGL Wiki. In that duty, I had to write this information. Now, I’ve done my level best to make that as comprehensible as possible.
But the fact of the matter is this: the people most likely to be effective in comprehending that environment are those who have a firm foundation in multi-threading theory and practical application. And if that defines a particular “beginning graphics programmer”, then that person is clearly an experienced programmer who just hasn’t experienced graphics programming.
That’s a very different audience from random guy on a forum who wants to learn Vulkan.
In OpenGL, that incoherent memory stuff, with it’s oddball barriers and such? That’s opt in; it only applies to certain very advanced features that most OpenGL users can freely avoid. You wouldn’t even be able to use them until you understood the basics of GL.
In Vulkan? That’s every day.
Here’s one of the simplest tasks in graphics: changing the value of a program’s uniform. Let’s be fair and call it a UBO value, so that we can’t cheat on the OpenGL side and call glProgramUniform.
In OpenGL, you map the buffer, set the value, and unmap it. Or you call glBufferSubData. Or whatever. Not using a proper buffer streaming technique may lead to degraded performance, but at least it works.
In Vulkan… you first must make sure the memory isn’t currently being read or due to be read by any outstanding rendering command. And that’s not a Vulkan API call or anything; it’s on you to keep track of that. If you do it wrong, then you hit undefined behavior.
If the memory is currently being read from, then you’re going to have to get a new buffer with new memory and put your value in it, along with all the other values that didn’t change. And if you don’t do it right, then you again achieve undefined behavior.
Uniform setting would be the sort of thing you’d see in the second or third tutorial in OpenGL. It would be pretty trivial, even with UBOs only. But in Vulkan, its an exceedingly complex operation.
Oh, you could just tell them to issue a full CPU/GPU sync after every frame. But then you’re just teaching them to use Vulkan badly. And that’s the last thing we want.
Or to put it another way, OpenGL is to Vulkan as Python is to C++. Sure, C++ is really cool, powerful, and low-level. But unless you actually are Bjarne Stroustrup, you’ll be better off teaching beginning programming students Python first. And even if you are, there’s no evidence that programmers who start off with C++ actually understand what they’re doing better than a programmer who learned Python, then C++.
Furthermore, I don’t believe that Vulkan is that much better for gaining “a better understanding of what the GPU is doing” than OpenGL. And this is again where trying to do it does a disservice to beginners. It gives the impression of knowing what the GPU is doing without the actual knowledge of what it’s really doing.
As an example, Vulkan has this notion of render passes, which represents the concept of rendering to a set of render targets. What does that represent on GPUs?
It depends on the GPU. For a tile-based GPU, it means doing a full render process. For a regular GPU, it means… clearing some caches.
Yet to the Vulkan API, it’s the exact same thing. Someone trying to learn what’s really going on through Vulkan only understands the abstraction, not the hardware. Oh sure, command queues are more explicit, as are GPU devices, state changes, memory allocation, and such (not that OpenGL ever hid any of these save queues and devices). But overall, Vulkan still hides plenty of details about what the hardware is doing.
I doubt you’d be able to tell, for example, that AMD GPUs actually modify your vertex shaders to do vertex attribute field decompression.