Would be interesting to see engines using Vulkan both for graphics and compute at the same time (like physics and etc.).

Can Vulcan be used for Deep Learning?

Short answer: Yes. But, it's pretty new. So, don't expect much pre-existing work today.

Long answer: Vulkan is a foundation for high-performance computing on GPU's. It includes SPIR-V which is intended as a compile target for higher level compute languages. https://www.khronos.org/spir

What does Vulkan Compute get you over CUDA?

Zero cost interoperability with your graphics API is a big one. Using CUDA for compute, and then mapping that data into OpenGL to draw it is way slower than it should be.

Not to mention NVidia did not allow simultaneous compute and graphics workloads on the same SM until the newest 10 series GPUs while AMD had this since, at least, the very first GCN (2011?)

http://www.tomshardware.com/reviews/nvidia-geforce-gtx-1080-...

Support on things not running nVidia chips. And it's supported on Android N, so you get a good chunk of mobile.

8% of Android users are on N, it's not much of a chunk.

That's tens of millions of devices and probably growing - that's a decent chunk IMO

Android N is the upcoming release

I think you're referring to Marshmallow, which was released last year. N is still in Beta Preview and Vulkan support is landing only in N.

Wong question (CUDA isn't cross platform). I'd ask, how Vulkan compares to OpenCL? I think both intersect in some way, but Vulkan only focuses on GPU (compute and graphics), while OpenCL focuses only on compute but has more generic approach (GPU + CPU).

Vulkan and OpenCL also support the same intermediate format SPIR-V, which allows you to run the exact same kernels on both APIs.

Compatibility with other GPU companies?

Yeah, it's a bit strange how relaxed people are about tying themselves to a single vendor.

It runs on AMD and Intel.

Isn't CUDA evil?

"simple"

Simple is not the same as easy.

Vulkan is not the convenience library. Vulkan is the ugly guts of the next twenty years of convenience libraries. If you enjoy Python, thank the systems programmers who implemented it in C. When you start enjoying some future SciPy-like system, thank the systems programmers who worked through 500 lines of this stuff before they could Hello Vulkan for your convenience.

Compared to the current situation of writing a few lines and then having to wait for a vendor specific day one graphics driver update to have your game actually running at halfway decent speed, it is simple.

The current APIs are a giant collection for graphics vendor specific driver "fixes" which had been implemented initially to cheat in benchmarks, and then later had to be implement to fix issues which arose from those initial cheats. It is a giant, ugly mess.

Also 95% of game developers will never ever touch a single line of vulkan because the engine developers of Unreal/Frostbite/CryEngine etc. will handle all of the "dirty work" for their abstractions to run on top of vulkan. All without the need of trying wo workaround vendor specific bug fixes etc.

This sounds completely agreeable in GPU programming.

It's not feasible to provide elegant one liner solutions. It's about managing a state for a quite complex piece of hardware and the exact point of Vulkan was to provide a bare-metal low-overhead API without complicated utility routines. So yes, it's supposed to be like that.

It is not acceptable, it is simply needed.

Yeah, I agree. Though, Vulkan is meant to be low-level, kind of like an ASM for Graphics Cards. The euphemism of the article's title is too much though imho.