Announcing Vulkan 1.0

Umm, yes there is. It's called Weston.

> Vulkan clients can run on unmodified Wayland servers, including
> Weston, GENIVI LayerManager, Mutter / GNOME Shell,
> Enlightenment, and more.

http://video.fosdem.org/2016/k1105/vulkan-in-open-source.mp4

If that's your reaction, Vulkan is Not For You, and that's fine. OpenGL is still there, and it does the job.

Vulkan is for when you need to push the hardware as hard as you can, and are willing to get it at the cost of throwing away all the convenience (memory allocation, state tracking, error handling...) that OpenGL gives you.

I'm a game dev, and I'll be using Vulkan, but if I'm going to do something like a tool, I may well do it in OpenGL. You can kind of think of Vulkan as C/C++ where OpenGL is more Ruby or Python. If it's not performance critical, OpenGL is easier and good enough.

Not a graphics dev, but from a broad overview, I think the whole purpose of Vulkan is removing abstraction, and letting you get as close to the metal as you possibly can.

Abstractions always have a cost, both in terms of runtime and in narrowing the possible solution space for a problem. Vulkan seems to be about throwing away most of those, and then letting you build your own, ones that exactly match your specific goals.

I understand that existing toolkits are also pretty strongly single-threaded, which is no longer true in Vulkan. On modern multi-core processors, you should be able to get much better performance.

I rather expect you'll start to see small/simple abstraction layers to manage the worst of the boilerplate, while still taking advantage of the multithreading.

But, fundamentally, this is not a product to make your life simple. Rather, it's a product to make your programming life complex, and in return to give you blazing speed.

I haven't looked into details of the new API, but from what I have seen it is pretty lean API already. Yes you can make it smaller, but at expense of loss of functionality. One can wish it to be a bit more complex or simple, depending on one's taste or needs, but I would say in its current form it is pretty good and reasonable. I wouldn't call it overengineered or a product of consortium.

The impression I get is that its (substantial) level of complexity is necessary to achieve its goals, and that its goals are good ones.

I think typical OpenGL drivers broadly consist of two parts: the first is a wrapper around the very low-level hardware details, and the second is mapping between the first part and the OpenGL API. The second part has to maintain compatibility with the decades-old API and with every application that has ever used it, and tries to map those applications onto the hardware as efficiently as possible, even when those applications are very poorly written, which is a hard job.

Expert game engine developers don't like that second part because it's a lot of complicated code that they have no visibility into and that they can't debug or optimise for their specific use cases, and that is different between every GPU vendor. All that code, and the OpenGL API itself, is just a frustrating obstacle between their game engine and the hardware.

So they want to eliminate that second part from the drivers and take over its responsibilities themselves. Vulkan lets them do that, by specifying a vendor-independent API to the code that wraps the low-level hardware details. Hardware is complicated so that API is necessarily complicated.

The engine developers will likely wrap Vulkan in their own ad-hoc high-level API, essentially implementing a driver that the rest of their graphics engine will call into. That means the total amount of code in the stack is roughly the same as with OpenGL, but they've minimised the amount of it that's specified in a standard. The remainder of the code is now free of the painful restrictions of standards (the need for backward compatibility, design by committee, multiple independent implementations, binary blobbiness, etc), and engine developers are free to innovate and improve it.

From an open source perspective, I think it's good for driver developers (they have less work to do), very challenging for engine developers (they have a lot more work to do), a significant risk that nobody will be able to cope with using Vulkan directly and will all move to non-Free engines like Unity and Unreal, but a significant opportunity for new middleware developers who can design a new high-level API (lower level than an entire graphics engine, perhaps slightly higher level than OpenGL (and much cleaner)) that could be shared by many open source game engines.