6 ms·

The Future of Graphics Programming: The Vulkan API

79 points by Tsiolkovsky 11y ago

personjerry 11y ago
Why is Vulkan needed? Not that I'm familiar with the industry, but I haven't seen a lot of complaints about OpenGL.
- modeless 11y ago
  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.
- kirushik 11y ago
  Maybe this? http://www.yosoygames.com.ar/wp/2013/09/what-i-hate-from-opengl-api/ 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.
- zamalek 11y ago
  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.
- sklogic 11y ago
  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.
- higherpurpose 11y ago
  In most DirectX vs OpenGL articles and discussions you see developers hate on OpenGL.
- corysama 11y ago
  I wrote a long comment on the issues Vulkan addresses a while back https://news.ycombinator.com/item?id=8146533 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.)
hobblin 11y ago
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!
- easytiger 11y ago
  Its the same committe running the OpenGL working group among others such as WebGL. https://en.wikipedia.org/wiki/Khronos_Group https://en.wikipedia.org/wiki/Khronos_Group
- parley 11y ago
  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.
- flippinburgers 11y ago
  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 11y ago
    This is orthogonal to availability of open source Vulkan GPU drivers though.
qznc 11y ago
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 11y ago
  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.
- lmm 11y ago
  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.
anton_gogolev 11y ago
Timeless Graphics API-related rant: [1] 1: http://programmers.stackexchange.com/a/88055/4994 http://programmers.stackexchange.com/a/88055/4994
- nickpsecurity 11y ago
  That was an awesome read. Thanks. Sad how many good opportunities are killed off by such foolishness. EDIT: Or acquisitions...
- golergka 11y ago
  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.
rawoke083600 11y ago
Was it just me or was reading that LIGHT GRAY text on white background hard ??
- VinzO 11y ago
  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.
- artmageddon 11y ago
  You're not alone. I don't know why they couldn't have made it darker for better contrast.
joelthelion 11y ago
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 11y ago
  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.
- deleted 11y ago
  [deleted]
- Maken 11y ago
  Mesa is already working on it, and it seems that there will be a Vulkan Intel driver soon after the official release.
pjmlp 11y ago
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 11y ago
  Apple has Metal and MS has DX12, but Apple, Microsoft, Google and others all have Vulkan. Like OpenGL, portability will be its strength.
  - toksaitov 11y ago
    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 11y ago
      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 11y ago
        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.)
  - pjmlp 11y ago
    > Apple, Microsoft, Google and others all have Vulkan Where?
outworlder 11y ago
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 11y ago
  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.
shmerl 11y ago
What is the story with Apple and Sony? Will they support Vulkan?
nickpsecurity 11y ago
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.
T-zex 11y ago
> 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 11y ago
  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.

79 points by Tsiolkovsky 11y ago

personjerry 11y ago

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

modeless 11y ago
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.
kirushik 11y ago
Maybe this? http://www.yosoygames.com.ar/wp/2013/09/what-i-hate-from-opengl-api/ 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.
zamalek 11y ago
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.
sklogic 11y ago
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.
higherpurpose 11y ago
In most DirectX vs OpenGL articles and discussions you see developers hate on OpenGL.
corysama 11y ago
I wrote a long comment on the issues Vulkan addresses a while back https://news.ycombinator.com/item?id=8146533 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.)

hobblin 11y ago

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!

easytiger 11y ago
Its the same committe running the OpenGL working group among others such as WebGL. https://en.wikipedia.org/wiki/Khronos_Group https://en.wikipedia.org/wiki/Khronos_Group
parley 11y ago
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.
flippinburgers 11y ago
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 11y ago
  This is orthogonal to availability of open source Vulkan GPU drivers though.

qznc 11y ago

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 11y ago
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.
lmm 11y ago
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.

anton_gogolev 11y ago

Timeless Graphics API-related rant: [1] 1: http://programmers.stackexchange.com/a/88055/4994 http://programmers.stackexchange.com/a/88055/4994

nickpsecurity 11y ago
That was an awesome read. Thanks. Sad how many good opportunities are killed off by such foolishness. EDIT: Or acquisitions...
golergka 11y ago
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.

rawoke083600 11y ago

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

VinzO 11y ago
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.
artmageddon 11y ago
You're not alone. I don't know why they couldn't have made it darker for better contrast.

joelthelion 11y ago

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 11y ago
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.
deleted 11y ago
[deleted]
Maken 11y ago
Mesa is already working on it, and it seems that there will be a Vulkan Intel driver soon after the official release.

pjmlp 11y ago

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 11y ago
Apple has Metal and MS has DX12, but Apple, Microsoft, Google and others all have Vulkan. Like OpenGL, portability will be its strength.
- toksaitov 11y ago
  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 11y ago
    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 11y ago
      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.)
- pjmlp 11y ago
  > Apple, Microsoft, Google and others all have Vulkan Where?

outworlder 11y ago

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 11y ago
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.

shmerl 11y ago

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

nickpsecurity 11y ago

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.

T-zex 11y ago

> 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 11y ago
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.