Vulkan 1.0 specification and SDK have been released

Quoting: skinnyraf

Quoting: rkfgI'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?

Quoting: rkfg

Quoting: skinnyraf

Quoting: rkfgI'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.

Quoting: EikeThe 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...

Quoting: minjThe 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 (from this source. They require Vulkan SDK (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.

Quoting: rkfgMy 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 (from this source.

They require Vulkan SDK (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 February 2016 at 6:33 pm UTC

Quoting: PeciskVulkan 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).

Quoting: Pecisk

Quoting: minjI 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