The Future of Graphics Programming: The Vulkan API

That was an awesome read. Thanks. Sad how many good opportunities are killed off by such foolishness.

EDIT: Or acquisitions...

Timeless rant? It's more like a history lesson, which is the direct opposite of "timeless".

Nevertheless, thanks for the link, this was incredibly informative and well-written.

Was thinking the same. With Vulkan providing a low-level API, now someone can write a cross-platform OpenGL implementation, and most of the pain people have suffered from crappy GL implementations and their differences can go away.

Of course, OpenGL may still be bloated and slow, but at least consistently so.

Mesa is already working on it, and it seems that there will be a Vulkan Intel driver soon after the official release.

No, it is not just you. It is hard to read for me too. I highlighted the text to make it easier to read it.

You're not alone. I don't know why they couldn't have made it darker for better contrast.

Apple has Metal and MS has DX12, but Apple, Microsoft, Google and others all have Vulkan. Like OpenGL, portability will be its strength.

I think this is an interesting point - in theory I guess it's possible that some kind of library or framework could implement OpenGL on top of Vulkan. It would be a bit like writing a graphics driver in user code, and it could have advantages: Vulkan should have more predictable performance, so OpenGL-on-Vulkan should have more predictable performance too compared to the black box driver with mystery performance pitfalls. It would be far easier to debug and profile for performance issues, and easy to gracefully fall back to normal OpenGL calls where Vulkan isn't supported (just forward the calls to the driver's OpenGL).

Still, I'm not sure who would develop such a framework. It could be a new backend for ANGLE (the framework browsers use to implement OpenGL on top of Direct3D). It might also be too difficult - the whole point of Vulkan is to avoid GPU drivers having to have vast, complex, buggy and slow OpenGL compatibility layers, and OpenGL-on-Vulkan may end up just reimplementing the same thing with the same pitfalls.

I suspect vendors will start implementing more and more of OpenGL in software (and indeed a lot of it's already in the driver) - cards will keep getting better, but there (hopefully) won't be new OpenGL-only software, so it will be ok if OpenGL doesn't unlock a card's full performance. Look at e.g. modern graphics cards' support for 8-bit textures, or MIDI synthesis on modern sound cards.

Whether that will be in the form of an explicit OpenGL-on-Vulkan library, or just similar things within vendor driver implementations, I can't say. Graphics card drivers are already enormous and contain a lot of backward compatibility code.

We never left them.

Contrary to urban myths, game consoles never used OpenGL as such, only GL like APIs (the PS3 PSGL wasn't really used).

Apple also only adopted OpenGL on MacOS X due to NeXTStep, before it used QuickDraw 3D.

Sure, but with OpenGL's state system you could only safely use it from a single thread. Even if you had multiple threads using it, you still needed a command buffer to safely operate it from one thread processing the commands on the command buffer. Vulkan is capable of being fed commands directly from multiple threads.

The OpenGL API no longer matches how the hardware works. As a result drivers are huge, unreliable, unpredictable, and slow. Mantle, DirectX 12, and Metal all cut away layers of abstraction and let applications drive the hardware more directly, without drivers getting in the way as much. OpenGL is getting left behind and Vulkan is the response to that.

Maybe this? http://www.yosoygames.com.ar/wp/2013/09/what-i-hate-from-ope...

OpenGL is a good concept, but it's real-world usage turned it into an ugly mess with a too deep reliance on the competence of the developer.

A really bad analogy (still gets the message across):

If GPU APIs were programming languages OpenGL would be Visual Basic. You're shielded from 90% of the more difficult aspects of accessing the GPU, for a performance cost. Vulkan would be akin to C.

For example: if you use OpenGL the GPU driver will tons of things (costing performance) to make sure that you don't update a texture while the GPU is using it - even if you know what you are doing (e.g. updating a portion of the texture that isn't being used for the render). Vulkan will get right out of your way and let you do what you want: even update a texture while its in use and potentially cause a bug/driver crash or other issues.

The interviewer made this assumption in the second question:

> Vulkan will “replace” OpenGL

Which given my above explanation you will see is probably not true. OpenGL is incredibly valuable because it's so simple - Vulkan and OpenGL simply don't compete with each other, they solve slightly different problems.

OpenGL puts a lot of unnecessary burden on a CPU, while it is possible (now, on a modern hardware) to shift a lot more of the things a driver is doing to the GPU side. A new API is needed to reflect this.

In most DirectX vs OpenGL articles and discussions you see developers hate on OpenGL.

I wrote a long comment on the issues Vulkan addresses a while back https://news.ycombinator.com/item?id=8146533 (can't believe 'a while back' was almost a year ago...)

tldr: OpenGL is great. But, the hardware model it is based on is long outdated. The mantra for the past decade has been "Do your work in huge batches if your want peak performance". But, modern hardware is very capable of getting great perf out of lots of small batches if they are set up correctly. Unfortunately, doing that in OGL requires complicated extensions to work around the old design (AZDO).

That's the big driver. But, there's also a lot of good improvements over OGL that can be made given the past 30 years of hindsight. Not the least of which is a much simpler, more consistent, more reliable, more maintainable driver model (ex: Don't ship a custom, rushed, underfunded compiler in every OS update of every Android device and just point at the spec doc when people complain that they each parse the same code slightly differently from each other.)

Its the same committe running the OpenGL working group among others such as WebGL.

https://en.wikipedia.org/wiki/Khronos_Group

I have a feeling that that's the completely wrong way to look at it, although I'm happy to be corrected if I'm wrong.

Today, GPU vendors write big, complex, closed-source drivers offering high-level APIs that as a result are buggier and harder for FOSS-developers to keep up with and make FOSS replacements for.

With Vulkan, GPU vendors should write smaller/simpler drivers, in theory making it easier/cheaper for them to provide good drivers and probably reducing the amount of work needed to produce a replacement FOSS-driver.

The complexity and the high-level APIs is supposed to move out of the driver and into libraries and engines, and many such will be FOSS and probably more portable than the FOSS kernel drivers can be. Please correct me if I'm wrong, though, as I'm not a graphics guy, but I was happy for FOSS when I first read about Vulkan.

The Vulkan SDK will be open source when it is released.

http://www.gdcvault.com/play/1022018/

This is being spearheaded by Valve so the idea that they want to do anything to harm indie developers or linux gamers is simply incorrect.

What are you talking about? It'll be a Khronos standard. Do not confuse it with proprietary things like Mantle and Metal.

OpenGL has a lot of accumulated cruft over the years,and as others have pointed out, it's state-machine abstraction really doesn't match up with how modern graphics cards actually work.

Vulkan is an open standard, and anyone is free to write their own open-source implementation.

This is exactly the same as OpenGL - OpenGL is an open standard, and has an open-source implementation by the name of [Mesa](http://www.mesa3d.org/).

As other people have said, OpenGL is to Vulkan as C# is to C. For large-scale engine developers, it's quite clear which you'd want to use, under-the-hood.

Besides, just writing the C# runtime environment in C makes an awful lot of sense.

You are completely off base here, do your research.