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.
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.
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.)
Ok... "the industry" thinks that we need a new, completely incompatible, standard for graphics development that is locked down (no mention of open source or free software) and that lower level of abstraction will make it more reliable (that is some major PR-bullshit)...
This can, as I see it, only lead to giving more power to the big companies and shafting the indie developers and linux gamers... So in general, fuck those people!
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.
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.
Will there be an OpenGL compatibility layer on top of Vulkan? Otherwise, GPU vendors will have to maintain OpenGL for backwards compatibility for a very long time?
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.
I think this has a good chance of vastly improving the graphics driver situation on Linux. Providing Vulkan support should be a lot less work than providing a full OpenGL driver, and an OpenGL library can probably be written on top of that.
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.
I watched all the relevant WWDC Metal talks and they look pretty serious to use it as their only graphics API, with OpenGL left in its current state for backwards compatibility.
Unless Apple proves me wrong by adding Vulkan support, I would say they were on the meetings more to learn how to improve Metal than anything else.
Would it be feasible to implement Vulkan atop Metal as a library without horrible performance? (Keeping in mind that the baseline of Apple's OpenGL is already fairly slow and behind the times. And Apple's customers already have fairly low expectations wrt gaming/etc.)
This is good news. Simplification will help across the board. Also, open source graphics card and middleware projects might benefit from the simplification of lower layers.
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.
43 comments
[ 2.6 ms ] story [ 96.6 ms ] threadOpenGL 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.
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.
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.)
This can, as I see it, only lead to giving more power to the big companies and shafting the indie developers and linux gamers... So in general, fuck those people!
https://en.wikipedia.org/wiki/Khronos_Group
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.
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.
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.
I think that's kind of misleading. Mesa lags years behind any current OpenGL standard.
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.
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.
1: http://programmers.stackexchange.com/a/88055/4994
EDIT: Or acquisitions...
Nevertheless, thanks for the link, this was incredibly informative and well-written.
Of course, OpenGL may still be bloated and slow, but at least consistently so.
Currently I see it only mattering on Android (if Google cares about it) and GNU/Linux.
Unless Apple proves me wrong by adding Vulkan support, I would say they were on the meetings more to learn how to improve Metal than anything else.
Where?
Are we back to the Glide days?
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.
Surely you have to do this with OpenGL as well.