Vulkan 1.0 specification and SDK have been released

I just hope Blizzard implement this in WoW because it really is the one and only game/application that annoyingly keeps me dual booting.

One can dream.

Blizzard is owned by Activision, and those are known as next EA. They also losing subs and Activision is very greedy at this point. So pointless.

WoW works very nicely under Wine, never had problems with it. Never dual booted because of WoW.

* Lots of mobile chips support Vulkan API trough Android (how about other Linux based distros? Are those drivers platform neutral)?

well.. the kernel couldn't care less, though, the compositor above will ;-). So in a driver-sense, android drivers stay android drivers, support for other display servers would require the driver to support them (e.g. X11, Wayland, Mir).

Good point, so essentially, other mobile Linux platforms can utilize those drivers. Nice.

* Lots of mobile chips support Vulkan API trough Android (how about other Linux based distros? Are those drivers platform neutral)?

well.. the kernel couldn't care less, though, the compositor above will ;-). So in a driver-sense, android drivers stay android drivers, support for other display servers would require the driver to support them (e.g. X11, Wayland, Mir).

Good point, so essentially, other mobile Linux platforms can utilize those drivers. Nice.

All with the same display server as Android. Since Android has it's own display server - nope. Just everything based on the Android graphics stack will be able to use the drivers.

I don't really get it. Why should i use Vulkan today, if almost no game is supported ? Why is Vulkan so good ? i didn't follow anything about it, where can i read a resume or something ?

The Vulkan renderer for Talos Principle isn't on Linux yet. Hopefully that will arrive soon.

It will, they say!
https://steamcommunity.com/app/257510/discussions/0/412447331651559970/#c412447331651682425

* Lots of mobile chips support Vulkan API trough Android (how about other Linux based distros? Are those drivers platform neutral)?

well.. the kernel couldn't care less, though, the compositor above will ;-). So in a driver-sense, android drivers stay android drivers, support for other display servers would require the driver to support them (e.g. X11, Wayland, Mir).

Good point, so essentially, other mobile Linux platforms can utilize those drivers. Nice.

All with the same display server as Android. Since Android has it's own display server - nope. Just everything based on the Android graphics stack will be able to use the drivers.

Not exactly. Those drivers provided OpenGL ES support, now they will provide Vulkan support. Everything that speaks in Vulkan API is a go.

Android display server will add Vulkan support to talk with these drivers instead.

The Vulkan renderer for Talos Principle isn't on Linux yet. Hopefully that will arrive soon.

It will, they say!
https://steamcommunity.com/app/257510/discussions/0/412447331651559970/#c412447331651682425

Day or two...nice. Thanks for info drop!

I just hope Blizzard implement this in WoW because it really is the one and only game/application that annoyingly keeps me dual booting.

One can dream.

Blizzard is owned by Activision, and those are known as next EA. They also losing subs and Activision is very greedy at this point. So pointless.

WoW works very nicely under Wine, never had problems with it. Never dual booted because of WoW.

Considering the WoW Engine, which supports OpenGL and we don't have a Linux release, it's very likely even if they port their Engine to Vulkan (which I see as very likely over the next few years).

For the Legion tests - no, there isn't any sign of significant engine changes. Except that they'll require SM3 compatibility.

Nvidia beta vulkan drivers installed, and talos publicbeta installed.
But there's still no vulkan support for linux on talos.

Q: Almost forgot - what about minimum and recommended specs to run Talos under Vulkan?

A: Oh, yes, you're right - that's important! Here:

OS: Windows 7, 8.1 or 10 (Linux later)
RAM: 8 GB (16 GB just in case)
GPU: latest generation (or one previous gen)
(NV: 770 or better, 960 or better, could work on 600 but haven't tested;
AMD: 7970, 280 or better, 370 or better, Fury)
VRAM: 1 GB (not so sure about this, better have 2 GB at least)
SOUND: doesn't matter, Vulkan is for graphics!

So.. Uninstalling the drivers.. =/

Nvidia beta vulkan drivers installed, and talos publicbeta installed.
But there's still no vulkan support for linux on talos.

Q: Almost forgot - what about minimum and recommended specs to run Talos under Vulkan?

A: Oh, yes, you're right - that's important! Here:

OS: Windows 7, 8.1 or 10 (Linux later)
RAM: 8 GB (16 GB just in case)
GPU: latest generation (or one previous gen)
(NV: 770 or better, 960 or better, could work on 600 but haven't tested;
AMD: 7970, 280 or better, 370 or better, Fury)
VRAM: 1 GB (not so sure about this, better have 2 GB at least)
SOUND: doesn't matter, Vulkan is for graphics!

So.. Uninstalling the drivers.. =/

Talos Vulkan Linux version coming in day or two.

I've become curious about one thing: if Vulkan provides such a low level access to hardware, what will happen if an app (a game usually) starts to misbehave?
<...>

Is it any better with OpenGL? It's direct access too. A misbehaving game/driver can easily freeze a system. You can sometimes switch to a console to kill the game, but often it is not possible. You could still ssh into the box if you have another system available, but how many users can do it?

Technically, yes. I had XCOM 2 freezing the driver completely with Xorg. Connected via SSH from tablet, killed X but the image on screen remained. Couldn't rmmod nvidia (module is in use), had to reboot. So yes, OpenGL can break the system. But it has enough layers of protection to prevent many possible ways of doing that unintentionally. Vulkan, as I understand it, has none or very few. So here comes a question, do we agree to trade stability for performance? A hard one to answer I must say.

The nvidia drivers with beta Vulkan support have got the version number 355.00.26, my Debian drivers have got 355.11 - so should Vulkan already be included? Or is there some number confusion (like a ".00" too much)? Is there any easy way to query if the driver supports Vulkan?

I've become curious about one thing: if Vulkan provides such a low level access to hardware, what will happen if an app (a game usually) starts to misbehave?
&lt;...&gt;

Is it any better with OpenGL? It's direct access too. A misbehaving game/driver can easily freeze a system. You can sometimes switch to a console to kill the game, but often it is not possible. You could still ssh into the box if you have another system available, but how many users can do it?

Technically, yes. I had XCOM 2 freezing the driver completely with Xorg. Connected via SSH from tablet, killed X but the image on screen remained. Couldn't rmmod nvidia (module is in use), had to reboot. So yes, OpenGL can break the system. But it has enough layers of protection to prevent many possible ways of doing that unintentionally. Vulkan, as I understand it, has none or very few. So here comes a question, do we agree to trade stability for performance? A hard one to answer I must say.

Vulkan abstraction most likely have some safety measures built in. It is not complete raw access.

The nvidia drivers with beta Vulkan support have got the version number 355.00.26, my Debian drivers have got 355.11 - so should Vulkan already be included? Or is there some number confusion (like a ".00" too much)? Is there any easy way to query if the driver supports Vulkan?

I will guess that Vulkan support is added to branch 355.00.26, 355.11 is just next branch without Vulkan in it. When it will come out of beta phase it will be added to latest Nvidia driver officially.

The error checking is a different layer in Vulkan that can be enabled in dev and disabled in production. This should theoretically take care of all the major problems before they hit users. Then again AAA titles should be obvious bug-free on launch and we all now how take works...

The error checking is a different layer in Vulkan that can be enabled in dev and disabled in production. This should theoretically take care of all the major problems before they hit users. Then again AAA titles should be obvious bug-free on launch and we all now how take works...

My concern exactly. For now a buggy shader may prevent rendering some parts of the scene like skin in Assassin's Creed. Looks awfully but at least you can exit the game. If the entire desktop hangs up instead (together with unsaved documents and what else), gamers would be not just upset but furious.

In the meantime you may check [these demos](http://vulkan.gpuinfo.org/examples.php) (from [this source](https://github.com/SaschaWillems/Vulkan)). They require [Vulkan SDK](https://vulkan.lunarg.com) (sign in isn't required, look at the bottom) and the mentioned source repository. Binaries are supposed to be placed in the subdir of the cloned repo, I named it "binaries" so that they could access the data files with ../data/shaders/whatever). computeshader crashes for me and instancing is unbelievably slow. Which is sad as it says lots about the expected gain. Or loss of it.

My concern exactly.

For now a buggy shader may prevent rendering some parts of the scene like skin in Assassin's Creed.

Looks awfully but at least you can exit the game.

If the entire desktop hangs up instead (together with unsaved documents and what else), gamers would be not just upset but furious.

In the meantime you may check [these demos](http://vulkan.gpuinfo.org/examples.php) (from [this source](https://github.com/SaschaWillems/Vulkan)).

They require [Vulkan SDK](https://vulkan.lunarg.com) (sign in isn't required, look at the bottom) and the mentioned source repository.

Binaries are supposed to be placed in the subdir of the cloned repo, I named it "binaries" so that they could access the data files with ../data/shaders/whatever). computeshader crashes for me and instancing is unbelievably slow.

Which is sad as it says lots about the expected gain. Or loss of it.

Very good link

Respect vulkan, computerbase* make some test in talos principle on windows with respective amd and nvidia drivers

Original Article by Computerbase

http://www.computerbase.de/2016-02/vulkan-erste-benchmarks-der-neuen-api-in-talos-principle


Results shows improvements compared to opengl but vulkan stay behind DX11 (and DX12 improves compared to DX11)

^_^


Last edited by mrdeathjr on 16 Feb 2016 at 6:33 pm UTC

Vulkan abstraction most likely have some safety measures built in. It is not complete raw access.

From the specification section 2.5:
"... implementations must ensure that incorrect usage by an application does not affect the integrity of
the operating system, the Vulkan implementation, or other Vulkan client applications in the system, and does not allow
one application to access data belonging to another application. Applications can request stronger robustness guarantees
..."

So a misbehaving application should only be able to crash itself assuming there are no OS/driver bugs.

Vulkan does not let you just access the hardware, just because it's closer to it, it's not a direct access. It basically just gives you more control about command queues and buffers, within a few other things. But you still have to get a command buffer by the driver (you request a buffer of a kind and size and the driver supplies you with that), that didn't change :p.

Vulkan applications still have their OWN LOCAL buffers, which the driver better does not get mixed up with other buffers reserved on the GPU. Getting Vulkan to be displayed on X11 and/or keeping different applications not getting in each others way is the responsibility of the driver (still).

But ye, you for sure can kill the driver with Vulkan, as much as you could with OpenGL (locking up the GPU).

I remember someone anticipating for giggles that NVIDIA will beat AMD in Vulkan which was born out of their own spec (Mantle). Props to you sir but I don't know whether to laugh or weep.

Didn't know it was a race.

If it is, it's no marathon, but an endurance run.

And given the fact that current AMD hardware is far better at parallelization... :p