The Future of Graphics Programming: The Vulkan API

http://home.seekscale.com/blog/the-future-of-graphics-programming-the-vulkan-api

by Tsiolkovsky • 11 years ago

79 42 11 years ago

home.seekscale.com

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

modeless• 11 years 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• 11 years ago

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.

zamalek• 11 years 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.

sklogic2• 11 years 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• 11 years ago

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

corysama• 11 years ago

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

hobblin• 11 years 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• 11 years ago

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

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

parley• 11 years 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• 11 years ago

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.

zurn• 11 years ago

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

sklogic2• 11 years ago

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

douche• 11 years ago

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.

Qwertious• 11 years ago

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.

justthistime_• 11 years ago

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

I think that's kind of misleading. Mesa lags years behind any current OpenGL standard.

kcbanner• 11 years ago

You are completely off base here, do your research.

qznc• 11 years 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• 11 years 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• 11 years 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• 11 years ago

Timeless Graphics API-related rant: [1]

1: http://programmers.stackexchange.com/a/88055/4994

nickpsecurity2• 11 years ago

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

EDIT: Or acquisitions...

golergka• 11 years 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• 11 years ago

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

VinzO• 11 years 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• 11 years ago

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

joelthelion• 11 years 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.

TazeTSchnitzel2• 11 years 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.

Maken• 11 years ago

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

pjmlp4• 11 years 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.

TazeTSchnitzel2• 11 years 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• 11 years 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.

pjmlp4• 11 years ago

Apple, Microsoft, Google and others all have Vulkan

Where?

outworlder• 11 years 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?

pjmlp4• 11 years 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• 11 years ago

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

nickpsecurity2• 11 years 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• 11 years 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• 11 years 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.

The Future of Graphics Programming: The Vulkan API

Related Stories