
The Future of Graphics Programming: The Vulkan API - Tsiolkovsky
http://home.seekscale.com/blog/the-future-of-graphics-programming-the-vulkan-api
======
anton_gogolev
Timeless Graphics API-related rant: [1]

1:
[http://programmers.stackexchange.com/a/88055/4994](http://programmers.stackexchange.com/a/88055/4994)

~~~
golergka
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.

------
joelthelion
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.

~~~
TazeTSchnitzel
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.

------
rawoke083600
Was it just me or was reading that LIGHT GRAY text on white background hard ??

~~~
VinzO
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.

------
pjmlp
I wonder how relevant Vulkan is going to be with Apple replacing OpenGL with
Metal, Microsoft on DX12, Sony with GNMX, Nintendo with GX2.

Currently I see it only mattering on Android (if Google cares about it) and
GNU/Linux.

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

~~~
toksaitov
Citation for Apple? After the last WWDC the situation for any other API on
Mac/iOS seems hopeless. And no, that logo on a slide doesn't say much.

~~~
pjmlp
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.

~~~
glhaynes
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.)

------
qznc
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?

~~~
AshleysBrain
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.

------
outworlder
So, Vulkan on Linux, Direct3D on Windows, Metal on OSX, whatever the consoles
use... and WebGL(which is OpenGL-ESish).

Are we back to the Glide days?

~~~
pjmlp
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.

------
T-zex
> Vulkan API is more low-level than OpenGL (programmer is responsible for
> memory and threads management for example), what triggered this decision?

Surely you have to do this with OpenGL as well.

~~~
leetNightshade
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.

------
shmerl
What is the story with Apple and Sony? Will they support Vulkan?

------
personjerry
Why is Vulkan needed? Not that I'm familiar with the industry, but I haven't
seen a lot of complaints about OpenGL.

~~~
zamalek
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.

------
nickpsecurity
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.

------
hobblin
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!

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

[http://www.gdcvault.com/play/1022018/](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.

~~~
zurn
This is orthogonal to availability of open source Vulkan GPU drivers though.

~~~
profsnuggles
Well Valve paid someone to write an open source Linux Intel Vulkan driver.

    
    
        - The day The Khronos Group releases the Vulkan specifications is when they plan to open-source their Intel Linux driver. 
    

[http://www.phoronix.com/scan.php?page=news_item&px=LunarG-
Vu...](http://www.phoronix.com/scan.php?page=news_item&px=LunarG-Vulkan-AMA)

