
Vulkan is Here - ekianjo
https://www.khronos.org/vulkan/.
======
Udo
This chart sums it up pretty well:

[https://twitter.com/renderpipeline/status/699346348651507713](https://twitter.com/renderpipeline/status/699346348651507713)

There is no reason why any given app developer would want to talk to Vulkan
directly. It's basically only suitable for a subset of engine developers and
low level API programmers.

I also heard some people who were under NDA might have some disappointing
things to report about the Vulkan decision process now that it's out. But the
question is whether it matters at all whether it's a good API or not, given my
impression that it's apparently not intended for interfacing to humans but to
higher layer APIs.

~~~
masklinn
A more recent version of the chart from the same source:
[https://pbs.twimg.com/media/CbUg4_5WEAANwhc.jpg:orig](https://pbs.twimg.com/media/CbUg4_5WEAANwhc.jpg:orig)

It's quite a bit more positive about vulcan.

~~~
zanny
This is the primary UX for Vulkan. The problem is not the API PDF for OpenGL
you download from Khronos - its all the drivers that implement it. Not only do
you have to support he lowest common denominator GL version and then
extension-check every higher level feature you want to use with two code paths
every time, you also need to work around all the driver bugs you _will_ find
across the board with every combination of platform + GPU.

If OpenGL as of 4.5 were implemented perfectly on all hardware on all systems,
we would never need Vulkan because everyone could just AZDO for optimization.
Since we don't live in that fantasy world where pigs fly and Nvidia releases
freedom respecting drivers, Vulkan takes responsibility away from hardware
vendors who demonstrably cannot handle the work and puts the burden on the
developer, who... probably also cannot handle the work, but thats a per-
application problem rather than a fundamental API problem.

~~~
Hello71
Why couldn't someone write a "Vulkan backend for OpenGL" that combined proper
standards conformance with actual hardware acceleration?

~~~
zanny
You can. Go ahead and do it. Mesa is likely to implement future OpenGL
extensions by translating them to Vulkan rather than implementing them
natively to the metal, and someone is probably going to make a libgl that
targets Vulkan rather than any of the intermediary layers used around the
ecosystem.

------
bd
For reality check read "Talos Principle" FAQ on their Vulkan port (probably
the most complex non-toy Vulkan application you can try today):

[http://steamcommunity.com/app/257510/discussions/0/412447331...](http://steamcommunity.com/app/257510/discussions/0/412447331651720139/)

TLDR: optimism for the future but right now performance is actually noticeably
worse than their DirectX 11 rendering backend.

\--------

 _A: Ok, first, in GPU-bound scenarios (ultra settings, resolution higher than
full HD), you 'll see lower performance, 20 to 30% lower. This is work in
progress, and we (both Croteam and IHVs) are analyzing and optimizing the
performance. We'll get to the bottom of this!_

 _Q: And CPU-bound scenarios?

A: Same or a bit faster. But for now, those scenarios really have to be super-
CPU-bound. Like, rendering whole levels, without any help from visibility
system, frustum, distance or occlusion culling._

~~~
tux1968
You're right about the current status, but there is no reason to believe that
there is any architectural issue in the way of performance parity with
DirectX. This is a necessary first step, and there is a lot of reason for
optimism :-)

~~~
ramy_d
Indeed, from their Q&A
[http://steamcommunity.com/app/257510/discussions/0/412447331...](http://steamcommunity.com/app/257510/discussions/0/412447331651720139/)

 _Let me put it this way: When The Talos Principle came out, it had a very
similar frame rate in DirectX 9 vs DX 11. But then we optimized the game, and
the drivers were optimized in the meantime, and now D3D11 is 20-30% faster
than D3D9! I have a firm belief that this will also happen to Vulkan vs D3D11,
over time However, for now you can actually expect lower frame-rate compared
to D3D11. C 'mon, it's brand new API, give it some time. :)_

------
shmerl
Congratualations! It's a major step forward.

Note this however:

 _> “Vulkan takes cross-platform performance and control to the next level,”
said Bill Hollings of The Brenwill Workshop. “We are excited to be working
through Khronos, the forum for open industry standards, to bring Vulkan to iOS
and OS X.[1]”_

Of course Apple had to remain the jerks they are and not support Vulkan
natively, forcing developers to write translation layers[2]...

[1] [https://www.khronos.org/news/press/khronos-releases-
vulkan-1...](https://www.khronos.org/news/press/khronos-releases-
vulkan-1-0-specification)

[2] [https://moltengl.com/metalvk/](https://moltengl.com/metalvk/)

~~~
Htsthbjig
"Of course Apple had to remain the jerks they are and not support Vulkan
natively, forcing developers to write translation layers[2]..."

We write programs that use DirectX,Metal, OpenGL/OpenCL, and now Vulkan and I
disagree.

We believe competition is great. OpenGL/CL was in theory a standard but over
the years we had to funnel way more resources to make that work than with
DirectX or Metal combined. Why? Because of the "design by committee" mentality
of OpenGL/CL.

The only reason they had to react with Vulkan was competition from private
companies and even then the reaction was slow and painful for those that were
forced to support the bloat software for years.

We could do the same thing in OpenGL/CL with 5 different ways,one modern way
and 4 obsolete but not pruned from the standard because some company of the
committee that had obsolete legacy code banned the removal.

This made the codebase so big and hard to maintain, and expensive for
developers to support.

If Microsoft and Apple runs circles around those people, they are forced to
act and develop a better standard.

For us it is easier to develop translation layers that support OpenGL/CL
messiness.

~~~
shmerl
_> We believe competition is great._

Competition is great, sure. But Apple are anti-competition here. Competition
would mean choosing between using Vulkan or Metal on their system. Where is
that choice (wrapper is a workaround, but besides)?

All those lock-in proponents are actually scared of competition. So we are not
in disagreement. Competition is indeed good. Lock-in however is not, and lock-
in is anti-competition.

 _> The only reason they had to react with Vulkan was competition from private
companies_

It's the other way around. The only reason MS and Apple suddenly woke up is
because AMD was planning to open up Mantle (which resulted in Vulkan). Except
they reacted in their usual manner. Instead of helping the shared effort they
pushed for more lock-in.

~~~
Htsthbjig
I am not scared about Apple getting a monopoly. They are not going to sell as
much as Android because they only care about the high margin stuff.

I am more worried about Microsoft though, with Windows and Xbox they force
millions of people to use DirectX.

Yeah, we agreed on that . It took millions for our company to support
OpenGL/CL only because we did not want to make our code dependent on just one
provider. It was tough to justify that decision (financially). Decision that
only started to pay back with Android popularity.

~~~
shmerl
The good part is, since all of them (Vulkan as well as DX12 and Metal) have
roots in Mantle, they have a lot of similarities, which makes creating
translation layers easier. So I wouldn't be surprised if we'll see Vulkan →
DX12 layer in addition to Vulkan → Metal one. As well as other way around.

------
unsigner
NOT a successor. It's a very different beast. It's frequently described as a
"low-level" API, but "explicit API" is more correct. It gives you control (and
responsibility) for things that happen behind your back in OpenGL, e.g.
semantics of sharing of resources between the CPU and the GPU, explicit
separate access to many GPUs, explicit separation of command buffer building
and submission etc.

It will live side-by-side with OpenGL for the foreseeable future. It's just
targeting the same general area (graphics using GPUs) and is standardized by
the same folks (Khronos).

~~~
creshal
OpenGL is not going away (huge existing code basis etc.), but I'm not sure how
much continued development it's going to see.

Is there any case where you would _not_ want to use Vulkan in a new project?

~~~
bryanlarsen
I think that Vulkan would almost always be the wrong choice for a new project.
A higher level abstraction is probably the right choice, whether that would be
OpenGL or a third party game engine or CAD kernel or visualization engine etc
depends on the project.

[https://twitter.com/renderpipeline/status/699501481632886786](https://twitter.com/renderpipeline/status/699501481632886786)

~~~
creshal
> or a third party game engine

All major engines already have announced migrating to Vulkan and/or its
platform-specific counterparts (DX12/Metal), so you'd be indirectly using
Vulkan anyway.

~~~
TazeTSchnitzel
Well, when you write in Haskell and compile it to x86-64 machine code, you are
indirectly using x86-64 machine code. That doesn't mean a Haskell programmer
would like to write x64 asm, they're on quite different levels of abstraction.

------
pavlov
As usual, not available for Mac.

If this follows the usual trajectory, we'll have a sort-of-working
implementation of Vulkan 1.0 in OS X 10.13 (although it will kernel panic if
you look at it the wrong way).

But maybe Apple's stance on Vulkan is different now due to their own Metal
API? Is Apple involved in Vulkan at all?

~~~
SG-
Apple is a major Vulkan supporter and is on the "Board of Promoters". They
went for Metal because they needed and wanted better performance long before
Vulkan was going to be released.

My guess is we'll see Vulkan in the next major OSX/iOS release.

~~~
mtgx
Long before? Didn't they just adopt Metal on Mac OS mid last year? Surely they
knew Vulkan is almost done.

I think they just wanted to see if they can push major game developers to
adopt Metal for Mac games early on. If they could do that - awesome for them,
and they would never have to adopt Vulkan. If they can't, they'll have to
adopt Vulkan.

Here's hoping the latter will happen.

~~~
creshal
> Didn't they just adopt Metal on Mac OS mid last year? Surely they knew
> Vulkan is almost done.

Vulkan was announced in December 2014, with no significant commitment.

iOS 8 including Metal was announced mid-2014, and would have been in
development for a considerable time before. By the time it was announced for
OSX, Vulkan was still anaemic and not showing significant progress.

So it does make sense to keep using Metal for them.

> I think they just wanted to see if they can push major game developers to
> adopt Metal for Mac games early on. If they could do that - awesome for
> them, and they would never have to adopt Vulkan.

If that was the plan, it's probably going to fail: The developers of Unity
e.g. found Metal, DX12 and Vulkan so similar that they estimate to be able to
support all three with minimal development overhead.

~~~
mtgx
Why does everyone misinterpret my comment to mean that I was talking about
iOS?

I know Metal was announced for iOS earlier - I was talking about the support
for Mac OS X. They had no _good reason_ to adopt it for Mac OS X at that
point, if they were planning on adopting Vulkan in the near future anyway.
Unless, like I said, they'd prefer to keep Metal over Vulkan, and wanted to
give it a head start to see if PC game developers would start adopting it.

> If that was the plan, it's probably going to fail: The developers of Unity
> e.g. found Metal, DX12 and Vulkan so similar that they estimate to be able
> to support all three with minimal development overhead.

I'm not sure how you see that as a "failure". If they are so similar that game
engine developers will keep Metal around anyway, then we'll see games be built
on Metal, not Vulkan, for Mac OS X. How is that a "failure"? It would mean
Metal "won".

~~~
masklinn
> They had no good reason to adopt it for Mac OS X at that point

Of course they did: it was already their API of choice on iOS, platform
unification alone makes it a damn good idea to adopt it for OSX: iOS is by far
their most popular gaming platform, integrating the API back to OSX makes it
more likely they'd get more OSX support.

Not to mention a mid-2015 _release_ of Metal-on-OSX means they'd probably been
working on it since the Metal-on-iOS release. On top of fragmenting their
platforms, waiting for Metal would have meant a year-long delay.

~~~
shmerl
_> Of course they did_

They did have a reason, except it's nowhere good. They don't want to support
Vulkan because it increases their lock-in control and puts extra tax on cross
platform development. Same reason MS doesn't want to support it on Xbox. It's
not a good reason, it's pretty crooked but very Apple like.

~~~
webjprgm
Apple isn't usually about "locking people in" but more about controlling the
experience. That can lead to the same thing, where they want everyone to use
their API and not someone else's, but the difference is whether they have
greedy, malicious intent or not. I don't think they do. Having good intentions
means they are more likely to surprise you and do something good eventually.

Still, I wouldn't hold my breath on Apple supporting Vulkan soon. Their OpenGL
support is usually a few versions behind so if they do ever support Vulkan I
would expect it to be late.

~~~
shmerl
_> Having good intentions means they are more likely to surprise you and do
something good eventually._

I'll agree to that when I'll see it. I.e. if their intentions are good -
they'll get behind the Vulkan effort and will add native support for it on
their systems. So far they clearly stayed away from it, but surely noted all
its ideas to use in their lock-in variant.

~~~
rarepostinlurkr
Your definition of good and mine clearly differ. As has been noted, Metal
existed and shipped before Vulkan, yet you claim they are using all its ideas
in their own lock in variant.

Multiple people have mentioned in this thread how engine vendors have
abstracted all 3 competing technologies (Metal, DX12, "Vulkan") with minimal
effort.

How is there any lock in here? How is it any different from Microsoft or any
other vendor deciding to, or not, implement DX12 or Vulkan?

~~~
shmerl
_> Metal existed and shipped before Vulkan_

As was noted, it didn't exist before Mantle and before AMD decided to open it.
So Apple in fact knew about it all along. Again, you can't try to dismiss
their lock-in attitude with the claim that they just needed something and had
no alternatives. They simply made the lock-in choice.

 _> Multiple people have mentioned in this thread how engine vendors have
abstracted all 3 competing technologies (Metal, DX12, "Vulkan") with minimal
effort._

Indeed, since they share lot's of core ideas (all of them originate in
Mantle). The question is not about why one can't abstract them, but why Apple
and MS push their lock-in instead of collaborating. And you wouldn't like the
answer.

 _> How is there any lock in here? How is it any different from Microsoft_

Who said it's different? It's the same crooked practice. But I'm surprised you
don't see the obvious lock-in issue here.

~~~
masklinn
> As was noted, it didn't exist before Mantle and before AMD decided to open
> it.

I see that claim, I don't see any evidence. The first evidence of Mantle being
donated to Khronos date back to early 2015, not early 2014. Mantle was _not_
open-source or open at initial release, and wasn't even supported on all AMD
hardware.

> So Apple in fact knew about it all along. Again, you can't try to dismiss
> their lock-in attitude with the claim that they just needed something and
> had no alternatives.

Wait, so Apple's proprietary API is bad because AMD's proprietary existed
before it? How does that even make sense?

> They simply made the lock-in choice.

Mantle was only available for AMD hardware on Windows, Apple's first need was
ARM/PowerVR on iOS…

> The question is not about why one can't abstract them, but why Apple and MS
> push their lock-in instead of collaborating. And you wouldn't like the
> answer.

You do realise your pet conspiration theories are only answers to the question
"what are your pet conspiration theories" no matter how many time you hint at
them, right?

~~~
shmerl
_> Mantle was only available for AMD hardware_

Its design was generic, and both Apple and MS used it to make their lock-in
variants.

------
vegabook
Thank you AMD. Vulkan is essentially a development of Mantle, AMD's next-gen
graphics API, and without that forward-thinking leadership, we'd still be
messing with (closed) D3D on Windows, (closed) proprietary per-game drivers
from greedy Nvidia, and the outdated OpenGL.

Kudos all the more deserved for the fact that AMD doesn't have the financial
firepower of its competitors.

------
hatsunearu
The website says it is also a compute API. I haven't heard this before; I
didn't know Vulkan came with a GPGPU stack. Does anyone have any experience
looking at the compute aspects of Vulkan and how it compares to OpenCL?

I wanted to take a squiz at making GPU compute code for "fun" and I'm
wondering if Vulkan compute is worth looking at.

~~~
zanny
Vulkan has explicit compute command queues. It is worth noting that OpenCL 2.1
compiles to the same SPIR-V bytecode that Vulkan drivers consume, you just
generate it with a C API rather than GLSL, but either turn into the same
thing.

------
ekianjo
And here's a chart on whether or not you should switch to Vulkan:

[https://pbs.twimg.com/media/CbUg4_5WEAANwhc.jpg:large](https://pbs.twimg.com/media/CbUg4_5WEAANwhc.jpg:large)

~~~
1ace
Much better resolution:
[https://pbs.twimg.com/media/CbUg4_5WEAANwhc.jpg:orig](https://pbs.twimg.com/media/CbUg4_5WEAANwhc.jpg:orig)

And credit:
[https://twitter.com/renderpipeline/status/699501481632886786](https://twitter.com/renderpipeline/status/699501481632886786)

------
dman
Dont notice any AMD products at
[https://www.khronos.org/conformance/adopters/conformant-
prod...](https://www.khronos.org/conformance/adopters/conformant-
products#vulkan) even though AMD already has drivers out. Whats up with that?

~~~
mastax
The AMD drivers haven't been sent for conformance testing yet, probably due to
the fact that they're very buggy. (No personal experience but somewhere in
this thread someone said they're unusable).

------
Benjamin_Dobell
> Google gives you everything you need to incorporate Vulkan into your Android
> games and other apps where graphics performance is key

Err, do they? Where?

I was under the impression this isn't implemented yet and is expected to be
included in Android 7.

~~~
nercury
Yeah, I am also wondering. All I see is the same ol' link to half-outdated NDK
documentation.

~~~
corysama
Nvidia has an SDK today for Sheild devices
[https://developer.nvidia.com/vulkan-
android](https://developer.nvidia.com/vulkan-android)

Imagination Tech has an SDK as well. Apparently, a Nexus Player is a good
device to work on with it.

[https://www.reddit.com/r/gamedev/comments/463jo2/vulkan_api_...](https://www.reddit.com/r/gamedev/comments/463jo2/vulkan_api_example_code_early_drivers_available/)

------
speps
Examples and demos :
[https://github.com/SaschaWillems/Vulkan](https://github.com/SaschaWillems/Vulkan)

~~~
tjelen
Thanks for the link. I think that just looking at the "simple" triangle
example tells quite a lot about how low-level the API is (at least for me).
The source C++ file is >27kB and ~760 LOC..

------
maufl
Could OpenGL be implemented as a library on top of Vulkan? So that future
drivers will only implement the Vulkan API and if you want OpenGL, you just
use an OpenGL library?

~~~
robohamburger
I was thinking the same thing. Seems like that could have a lot of neat
applications as afar as porting and keeping existing software working.

Hopefully with lower level APIs like vulkan it means higher level APIs could
be better designed than opengl perhaps?

------
bitmapbrother
A video showing the dramatic performance difference between Vulkan and OpenGL
on an Android TV device:

[https://www.youtube.com/watch?v=P_I8an8jXuM](https://www.youtube.com/watch?v=P_I8an8jXuM)

~~~
lohengramm
Can anyone explain (or at least provide a glimpse to) why the difference is so
huge?

~~~
flohofwoe
It's described in the link: [http://blog.imgtec.com/powervr/gnomes-per-second-
in-vulkan-a...](http://blog.imgtec.com/powervr/gnomes-per-second-in-vulkan-
and-opengl-es), the code doesn't use any batching but each gnome is a unique
draw call, which is a worst-case scenario for OpenGLES2.

------
coetry
This is finally my chance to delve into graphics hacking. I'm interested in
bindings to Common Lisp with this >:)

~~~
agentultra
Not to dissuade you from graphics hacking in CL (it's a lot of fun!) but this
isn't what Vulkan is for.

It's a graphics API that gives you more explicit control over synchronization,
buffering, and resource sharing. There's still many reasons to prefer OpenGL
(for which there are good bindings in CL already and could use more
contributors!).

If you're just the curious sort and want to know more then by all means... it
will be a tough battle if this is your first delve into graphics programming.

~~~
teps
Could Vulkan be the opportunity to build a small and simple API for people to
learn graphic programming? I did learn OpenGl 10 years ago but it was already
a big mess and each time I were searching for some information I could only
discover mountains of hacks. I'm quit sure it's worse now.

~~~
agentultra
OpenGL is much better these days and if it's your first foray into graphics
programming learning WebGL is not a bad start IMO. You might need to use a
browser that can support some of the OpenGL ES features (WebGL extensions)
like VBO's and such but you can get really far that way.

Vulkan is not the right choice if you're just getting started unless you're
already motivated and intensely curious (ie: already have some decent exposure
to OpenGL, multi-threading, and are curious to know more).

------
znpy
Dumb question: what will change for end-users ?

~~~
Laremere
I think that's quite a reasonable question.

1\. Less CPU usage than an equivalent game in OpenGl. This is especially true
for games which want to draw lots of different individual things to the
screen, so you may be seeing more of those.

2\. Smaller drivers, which means more consistently performant and bug free.
There's far less of a chance of getting weird things from having an unusual
operating system or graphics card setup.

3\. More cross platform. There are many different pieces which change on
different platforms (consoles vs desktops vs mobile), but depending on what
platforms choose to support Vulkan, it's one less thing to worry about when
porting over.

4\. Maybe better games. There's a bunch of things which help with development,
so as long as a sufficient majority of graphics cards get vulkan drivers, it
may help reduce some coding cost.

Games which use common engines (ie, Unity) will likely get these features for
free. Others will have to work harder for it.

~~~
WorldMaker
That's the big question I have: how well does Vulkan seem to be bridging the
divide between API and GPU semantics? Will we finally see a time where
graphics drivers no longer monkey-patch _per game_?

(I'm still somewhat skeptical as the monkey patching is a value-add secret
sauce that seems likely to continue solely because it's such a weird
competitive thing between the two biggest vendors and a galvanizer for the
brand loyalties they try to maintain, but perhaps I'm just feeling pessimistic
about the capitalist drives here.)

~~~
snuxoll
> how well does Vulkan seem to be bridging the divide between API and GPU
> semantics?

That's the entire point behind Vulkan. OpenGL was created back when we still
had fixed-function rendering pipelines in GPU's, and while it has evolved to
support the massively parallel supercomputers GPU's have become it doesn't
have much low-level control over it. Vulkan gives the engine developer the
thinnest abstraction possible over a modern GPU, from everything from explicit
resource sharing and even explicit access to multiple GPU's (no more relying
on nVidia and AMD to add SLI/Crossfire profiles).

------
auvi
Great news! I am waiting for the book titled "Vulkan Programming Guide: The
Official Guide to Learning Vulkan (OpenGL) 1st Edition" to come out. Looks
like it will be out in August 2016.

------
diakritikal
I think what's most interesting is strong multi threading support in
conjunction with an intermediate representation.

Looking forward to seeing SPIR-V compilers in other languages...

------
frik
I am seeing forward to a possible "WebVulkan" analog to WebGL.

~~~
f_
Yes, it would be great, but it is most likely not happening anytime soon. As
previously discussed on the WebGL mailinglist, Vulkan is strictly (and
rightfully, wrt performance) working against all the security considerations
that went into WebGL by design. A "WebVulkan" would thus not be much of a
benefit, or even usable, if it's severly crippeled in it's features.

~~~
withjive
Even though Vulkan for would be of little gain for the web due to all the
security considerations required, a WebGL backend should still be able to
benefit from being built on Vulkan instead.

Due to the refinement of the pipeline and memory access, etc. provided by
Vulkan, there's a lot of room for optimization.

___

Though on the other hand, even with additional overhead on a Vulkan web API,
the improved state management and access to command buffers may still allow
for smarter rendering with negligible overhead via JS

Fun times

~~~
f_
I completely agree and one could theoretically do away with things like ANGLE!
Though, I also suspect that the implementor's overhead is rather large in
contrast to the current way WebGL is implemented in Chrome and FF, which is
currently a relatively 'thin' layer on top of OpenGL.

On the other hand the nature of implementation in Chrome, i.e. does seem to
lend itself somewhat to a command buffer approach as in Vulkan.

------
gulpahum
The reason I have been waiting for Vulkan is to get rid of OpenGL driver bugs.
I hope that being closer to metal means less bugs.

------
nercury
It is rare to see a cross platform release with so much collaboration behind
the scenes. Extremely exciting!

------
tgb
Does this do anything to address the difficulties of sharing the gpu resources
among processes, particularly concerning untrusted code like a website? Even
opengl es can crash my video driver easily under a heavy load and it's more
careful than opengl.

~~~
SXX
> Even opengl es can crash my video driver easily under a heavy load and it's
> more careful than opengl.

If Vulkan as low-level as expected then it's will easily let app lockup your
GPU completely. Though as drivers are they shouldn't cause troubles anymore.

~~~
SXX
* Ooops, as drivers are tiny.

------
advanderveer
Would it be worthwhile to write a Golang API on top of such a low level
implementation or would that just negate the reason it exists in the first
place?

------
bd
Quick Vulkan starter pack (if you just want to see if it runs on your system,
without compiling anything).

Windows-centric, but many things also available for Linux and Android.

\------- Drivers -------

Nvidia GPU driver: [https://developer.nvidia.com/vulkan-
driver](https://developer.nvidia.com/vulkan-driver) (worth trying even if your
GPU is not listed as supported, e.g. 900 series mobile Maxwell GPUs like GTX
970M or GTX 980M work ok)

AMD GPU driver: [http://support.amd.com/en-us/kb-articles/Pages/Radeon-
Vulkan...](http://support.amd.com/en-us/kb-articles/Pages/Radeon-Vulkan-
Beta.aspx)

\------- Demos -------

Nvidia Vulkan Choppers demo:
[https://nvidia.app.box.com/s/rj9nzxkpz21qu34h8zew301kray9urb...](https://nvidia.app.box.com/s/rj9nzxkpz21qu34h8zew301kray9urbf)

Nvidia Vulkan Fish demo (threaded rendering):
[http://developer.download.nvidia.com/mobile/shield/assets/Th...](http://developer.download.nvidia.com/mobile/shield/assets/ThreadedRenderingVk/ThreadedRenderingVk_20160215-02.zip)

Vulkan examples binaries by Sascha Willems:
[http://vulkan.gpuinfo.org/examples.php](http://vulkan.gpuinfo.org/examples.php)

\- requires assets from source distribution (create "bin" subfolder and place
binaries there):
[https://github.com/SaschaWillems/Vulkan](https://github.com/SaschaWillems/Vulkan)

\- also may need to install Visual Studio 2015 redistributables:
[https://www.microsoft.com/en-
us/download/details.aspx?id=481...](https://www.microsoft.com/en-
us/download/details.aspx?id=48145)

\------- Games -------

Talos Principle:
[http://store.steampowered.com/app/257510/](http://store.steampowered.com/app/257510/)
(there is a free demo available)

See how to enable Vulkan support here:
[http://steamcommunity.com/app/257510/discussions/0/412447331...](http://steamcommunity.com/app/257510/discussions/0/412447331651559970/)

\------- Tools -------

Vulkan HW capabilities database:
[http://vulkan.gpuinfo.org/](http://vulkan.gpuinfo.org/)

Vulkan Hardware Capability Viewer:
[http://vulkan.gpuinfo.org/download.php](http://vulkan.gpuinfo.org/download.php)

~~~
gnarbarian
Nvidia also just put out a C++ API as well:

[https://github.com/nvpro-pipeline/vkcpp](https://github.com/nvpro-
pipeline/vkcpp)

~~~
zanny
Why did they call it vk_cpp.h and not vulkan.hpp? Why???

------
robohamburger
I haven't read the docs yet but I wonder if this means there could be an open
source d3d or opengl implementation that uses vulkan as its backend.

Also: it is a shame the API docs appear to be behind a login page. Hopefully
that will change! The nice thing about opengl is it (at least when I used it)
the docs were easy to get at.

------
kbwt
Quick Reference:
[https://www.khronos.org/registry/vulkan/specs/1.0/refguide/V...](https://www.khronos.org/registry/vulkan/specs/1.0/refguide/Vulkan-1.0-web.pdf)

The Khronos site seems to be overloaded right now.

------
Bytes
It will be interesting to see the adoption rate for games and other
applications now that it has been released.

------
Aardwolf
Too bad the sample code linked to from multiple locations is empty... only a
README.md: [https://github.com/KhronosGroup/Vulkan-
Samples](https://github.com/KhronosGroup/Vulkan-Samples)

~~~
nilstycho
It might be this:
[https://github.com/SaschaWillems/Vulkan](https://github.com/SaschaWillems/Vulkan)

------
cousin_it
Newbie question: let's say I want to display a simple 3D object (say, a box)
which controlled by the mouse, and the latency between mouse and screen has to
be as small as possible. What are my best options? Is it packaged somewhere?

------
bane
Vulkan backend for RetroArch

[https://github.com/libretro/RetroArch/pull/2729](https://github.com/libretro/RetroArch/pull/2729)

------
wenderen
Apparently the GeForce 800 series doesn't support Vulkan :(

[https://developer.nvidia.com/vulkan-
driver](https://developer.nvidia.com/vulkan-driver)

Why is this so, any idea?

~~~
SG-
They support Geforce 600 and up. I don't even think Nvidia released a Geforce
800 except on mobile which is just a rebranded Geforce 700 so it's likely
actually supported.

~~~
wenderen
on my laptop:

$ lspci | grep -i nvidia 03:00.0 3D controller: NVIDIA Corporation GM108M
[GeForce 840M] (rev a2)

~~~
djur
Note the 'M' at the end of the model number. The laptop GeForce models are
different (and less powerful) than the desktop models. According to the
website, the 840M supports "entry-level gaming", which isn't really the
primary use case for Vulkan.

------
Eduard
So many teasered demos, but no video to look at...

------
bovermyer
Vulkan remains, and will only ever be, the Primarch of the Salamanders for me.
Sorry, I guess my gamer culture overrides my tech nerd culture.

------
meerita
Where is Apple on that page?

------
bijbij
I have dream to see such a master piece enabled on web browsers through
javascript.

