Low level graphics programming is tough, specialist work. Imagine a relatively simple stateful API layer over the top of this stuff, widely adopted and with an open spec. We could call it the Open Graphics Library, or OpenGL for short.
Well, as I understand it the issue with OpenGL was that it was very high-level without an option to drop to a lower level on demand since it was implemented in a complex GPU driver. This meant that drivers mostly had to guess what the intention was, and be optimized for e.g. specific games inside of the driver. With Vukan and a high-level library, you would have the option of dropping down to a lower level if you want and making those optimisations yourself. Keeping the complexity inside of the library, not the driver means you can modify it as you wish.
And a horribly painful codebase that is a horror to work with.
Nowadays people are more comfortable with having objects that represent something, and executing operations on them, than having to bind an object to a global variable, execute a global procedure, and unbinding it.
You think so? I think people like to call functions with comprehensible arguments.
I don't agree that people like to bind an object to a global variable, execute a global procedure, and unbind it. Does that sound like the
API of anyone's dreams? The binding and unbinding sounds like pure overhead to me.
I understand that very high performance and easy API may not be achievable, but seriously, the modern graphics APIs are hard to love.
> I don't agree that people like to bind an object to a global variable, execute a global procedure, and unbind it. Does that sound like the API of anyone's dreams? The binding and unbinding sounds like pure overhead to me.
That's exactly the global state I am complaining about.
The current polygonal environment is a global state variable.
The current vertex is a globally set variable (as you'll notice once you try to set textures and colors, becayse glVertex3f just sets a global variable), etc.
Try throwing two threads at this, you'll get hilarious results, and there's no way to propeely fix this.
And OpenGL 1.0 to 1.5 and then 2.0 made it even worse.
You allocate a buffer, fine.
But to write to it, you first bind the buffer to a global variable, then use a call writing to a global variable.
> The current vertex is a globally set variable (as you'll notice once you try to set textures and colors, becayse glVertex3f just sets a global variable), etc.
Bad example. glVertex3f is the one function (among the various glColor, glMultiTexCoord etc.) which doesn't set global state. It actually triggers a vertex to be sent (which takes its attributes from the global state you mentioned).
But all this is pretty moot, because it's not how OpenGL has been meant to be used in ages. Use the core profile, where these functions don't even exist any more.
> You allocate a buffer, fine.
> But to write to it, you first bind the buffer to a global variable, then use a call writing to a global variable.
Also outdated, though not by quite as much. Direct state access (DSA) has been a thing for a pretty long time, now.
> Also outdated, though not by quite as much. Direct state access (DSA) has been a thing for a pretty long time, now.
If it just worked for everything...
Even in 4.5 there's many functions that have no direct state version yet, and many others were only introduced in 4.4 and 4.5 (meaning it won't be really compatible anywhere).
For me, the #1 advantage of Vulkan is having DSA for everything, just working.
I think this might be a misunderstanding, I said that Vulkan (with complicated calls, but no shared state whatsoever) is far preferrable to OpenGL (no complicated calls, but all procedures only operate on global state).
Except when all you have to debug it is a black screen.
Graphics work is tricky, you need everything to line up just right or stuff renders in ways that don't lend well to understanding what went wrong. When you put a framework abstraction in between that it can be really difficult to find out exactly what went wrong.
