
Vulkan – Graphics and computing belong together - scoopr
https://www.khronos.org/vulkan
======
runeks
I applaud this effort. I hope we can get to a point where a GPU requires as
many drivers as a CPU.

I think one of the primary reasons more people don't target GPUs to offload
computation, is because it -- most often -- requires proprietary drivers
running on the host OS, for it to work (at an acceptable speed).

Imagine if putting an AMD of nVidia card in your box was the same as adding a
CPU. If you wanted to write OpenCL to execute on the GPU, thread allocation,
memory management etc. for that would be part of an open source OpenCL
library, that your application links to, and then you can write OpenCL kernels
that execute on the GPU via these libraries. No need for proprietary driver
blobs running on the host machine.

I hope we can get to a point where trying to sell a GPU that requires a
proprietary driver running in the host OS is as viable as trying to sell a CPU
that requires the same.

~~~
moron4hire
I thought CPUs _did_ have binary blob drivers, both in the BIOS and on the
operating system.

~~~
runeks
A driver is always required in order for the OS to speak to hardware. That's
essentially what a driver is: an interface between software and hardware.

With CPUs, the code needed to run in the host OS (the driver) is fairly simple
code that gives access to the CPU hardware more or less as it is: practically
speaking, everything the CPU itself can do, the compiler can output code to do
directly. The output of the compiler (eg. gcc) is sent more or less as-is to
the CPU for execution.

With a GPU, we have a large chunk of proprietary code running in the host OS
(the GPU driver), which provides a 3D API interface, such as OpenGL or
Direct3D, to the GPU hardware. There is a huge difference between what is sent
to this driver code, and what the driver sends to the GPU hardware.

Applications submit, eg., OpenGL instructions to this driver, the driver
compiles these OpenGL instructions into code that will execute on the GPU, and
sends it to the GPU. So the GPU driver essentially acts as a closed source
compiler, that compiles from OpenGL/Direct3D into whatever intermediate
language the GPU accepts, which the GPU may further compile into something
that its processors can execute.

So for a CPU, the compiler does most of the work, while for a GPU, the driver
does most of the work, and actually functions as a closed source compiler. On
top of that the driver handles memory management, and automatically allocates
memory according which OpenGL instructions are executed.

Imagine if Intel provided a CPU that you could only use to execute Python
code. It would require a closed source driver to work. This closed source
driver would compile Python code submitted to it into some unknown
instructions that execute on this CPU. It would also have exclusive control
over an area of memory, that the driver would automatically allocate portions
of, to store data from Python variables. That's essentially what nVidia and
AMD offer, except the hardware is a processing unit that comes with its own
RAM, and the language is OpenGL/Direct3D and not Python.

~~~
nightski
Wasn't this approach taken with good reason though? So the effort to get code
running on multiple GPUs was a reasonable? Remember the days of when games
would only support select GPUs?

Sure you could have a standard like i386. But isn't it the case that there is
a lot more innovation happening in the GPU architecture space making this very
difficult?

~~~
chongli
GCC supports waaaaay more different CPU architectures than these drivers do
for GPU architectures. This argument has no merit. The only purpose for these
closed architectures is vendor lock-in.

~~~
anon4
And every vendor has an HLSL and a GLSL shader compiler. You also usually
don't ship ten different binaries for ten different architectures, which you
would need to do for GPUs.

~~~
gnoway
In this model I think you'd distribute something in an intermediate bytecode,
like .NET does w/ MSIL, and then the target system would be responsible for
precompiling.

Edit: just saw this:

[https://news.ycombinator.com/item?id=9140001](https://news.ycombinator.com/item?id=9140001)

------
fizixer
I had a long debate on multiple forums recently regarding the almost
uselessness of OpenGL in presence of something like OpenCL, especially when
OpenGL does its job (as a graphics library) in a very crappy manner by trying
to be part-framework, part-library, and not doing either properly, and making
the life of a graphics programmer a living hell, who has to code 80% of the
graphics pipeline by hand or using third party matrix libraries anyway. I
realized this very strongly when I considered doing graphics using OpenGL but
with a photorealistic renderer like a path tracer.

Currently the only reason for OpenGL over GPU being inevitable is that GPU
vendors don't provide access to "non-GPGPU" parts (like TMU, ROP) directly to
OpenCL (or CUDA), which is clearly a matter of design rather then
technicality.

Unsurprisingly, people were offended or upset (you either don't use OpenGL, or
you end up defending it against criticism, subconsciously, because you have
invested so much time learning it).

I hope something good comes out of this initiative.

~~~
jamesfmilne
I've spent 15 years working on OpenGL, but I'd kick it to the kerb in a
heartbeat.

AMD and NVIDIA are free to implement Vulkan on Windows and Linux, but the
problem is that we will probably be stuck with OpenGL 4.0 on Mac OS X for the
foreseeable future.

~~~
saschispatzi
I don't know too much about the topic (I wish I did), but how what makes you
think so? I see that it says "Will work on any platform that supports OpenGL
ES 3.1 and up" and Apple platforms seem not to support that (as of now).
However Apple is part of the working group, doesn't that make it very likely
they are working on an implementation, too?

~~~
readstoomuch
Apple are traditionally tardy when it comes to OpenGL. Yosemite is still on
4.1 (2010 release), lacking support for things like compute shaders.

~~~
ixtli
It seems like it's unfair to say "Apple are late with OpenGL features." The
third parties could put the same effort into making drivers for OS X that they
do into making them (and their crapware frontends) for Windows, but they
don't. I may be wrong, but it appears to me that it's Apple doing most of the
work.

~~~
jsheard
There's not much hard information on how Apple deals with graphics drivers,
but from what I gather they use a unified in-house OpenGL frontend for the
hardware-independent layer, then defer to a modified version of the vendors
driver for the low-level stuff.

Their frontend only implements up to GL 4.1, so even if the vendors were to
release drivers independently there would be no way for an app to access the
newer functionality through the OS X frameworks.

------
ErikBjare
I noticed the very significant working group members at the bottom of the
page. If that is nearly as good as it looks, I'm very hopeful.

Here is the press release: [https://www.khronos.org/news/press/khronos-
reveals-vulkan-ap...](https://www.khronos.org/news/press/khronos-reveals-
vulkan-api-for-high-efficiency-graphics-and-compute-on-gpus)

It seems Valve will work hard on it:

“Industry standard APIs like Vulkan are a critical part of enabling developers
to bring the best possible experience to customers on multiple platforms,”
said Valve’s Gabe Newell. “Valve and the other Khronos members are working
hard to ensure that this high-performance graphics interface is made available
as widely as possible and we view it as a critical component of SteamOS and
future Valve games.”

Technical previews will be shown at GDC this week.

------
jacobolus
So it looks like this is the Khronos answer to Mantle/Metal. Does anyone have
a quick summary comparing the three? Is Vulkan just targeting game developers
or is there a wider set of use cases they want to hit? Is there any current
guess about when hardware/software support will come? Can we expect a
WebVulkan sometime before 2025?

~~~
Vanayad
Vulkan is the evolution of Mantle (get it... get it :)) ?) AMD contributed a
lot to the development of this API and then collaborated with Microsoft to
create DX12. Mantle will remain as a testbed of future technologies

~~~
MrBuddyCasino
I get that AMD wants this because it will make CPU performance less important
for gamers, as they can't currently compete against Intel here. AMDs APU
concept would become more attractive that way.

Valve etc. want this because OpenGL sucks, but DX is Win only.

Microsoft will want to defend its DX stronghold - can they, on a technical
level? Will Nvidia play along?

~~~
datenwolf
> Valve etc. want this because OpenGL sucks

Actually Valve labeled OpenGL to be "shockingly efficient" in one of their
presentations (postmortem of porting the Source Engine to Linux).

~~~
jsheard
I went back and checked, it was actually an nVidia guy who said that. Rich
Geldreich from Valve was also there but he's expressed nothing but disdain for
OpenGL since he left the company:

> "I know it's possible for Linux ports to equal or outperform their Windows
> counterparts, but it's hard. At Valve we had all the driver devs at our beck
> and call and it was still very difficult to get the Source engine's perf.
> and stability to where it needed to be relative to Windows. (And this was
> with a ~8 year old engine - it must be even harder with more modern
> engines.)"

[http://richg42.blogspot.co.uk/2014/11/state-of-linux-
gaming....](http://richg42.blogspot.co.uk/2014/11/state-of-linux-gaming.html)

~~~
datenwolf
> I went back and checked, it was actually an nVidia guy who said that.

Hmm, makes sense. But then NVidia really _loves_ OpenGL.

------
shmerl
From this diagram[1] it looks like they didn't get rid of the single thread
bottleneck for submitting commands to the GPU (which can handle commands in
parallel). Didn't Mantle allow parallel submission for that instead of using a
single thread with one queue? DX12 supposedly allows that as well. If Vulkan
won't allow it, it will be at a disadvantage.

1\. [https://i.imgur.com/x1CJO96.png](https://i.imgur.com/x1CJO96.png)

~~~
kllrnohj
The idea that it's a bottleneck is wrong. Just because it's one thread doesn't
make it a bottleneck. Draining from N queues into 1 queue and posting that
work off to the GPU is never going to be a bottleneck. Even an arduino can
handle that task fast enough to saturate the latest & greatest from Nvidia or
AMD.

Also fwiw in DX12 even if parallel submission is supported, what's going to
happen is N user threads are going to submit to 1 driver thread that then
submits to the actual GPU.

~~~
shmerl
I understood it that GPU itself can handle multiple commands concurrently, no?
So if hardware supports it and there is just one thread submitting them,
hardware isn't used to full capacity. Or that's wrong? And what's the point of
making one thread do it, if multiple can? Queuing through one usually makes
sense if you need some ordering.

~~~
kllrnohj
Most GPUs cannot handle multiple arbitrary commands concurrently, but even if
they can you're still going to easily saturate that with a single thread
pushing over command buffers. The command buffers in this case are large,
complex work units, not small microtransactions like the APIs of old.

And yes, ordering is needed here.

~~~
shmerl
So how exactly then DX12 and Mantle do it? They don't appear to have such
single queue manager thread. You said driver does that task. So if it does,
can't it do it for Vulkan as well? Or their point is to reduce driver
complexity here?

I can see that it might be not a major issue if time that takes it to fetch
from the queue is way smaller than time it takes to execute some command
[buffer]. I.e if queue manager will fetch and push commands to the queue,
returning to fetch another without waiting for the first to finish, then it
will work fine (it will have to handle GPU saturation though). But if it will
be blocking - it will be some bottleneck which won't let using hardware fully.

~~~
kllrnohj
Graphics APIs are almost universally non-blocking, this won't be blocking
either.

Vulkan is basically a rebranded Mantle. I suspect you're just mistaken about
Mantle, but as that API is not (yet?) open we don't really know if this was a
change Khronos made when adopting Mantle or if this is just how Mantle works
as well.

DX12 works the same as Vulkan, though, with a single submission thread ("The
only serial process necessary is the final submission of command lists to the
GPU via the command queue, which is a highly efficient process."
[http://blogs.msdn.com/b/directx/archive/2014/03/20/directx-1...](http://blogs.msdn.com/b/directx/archive/2014/03/20/directx-12.aspx))

~~~
shmerl
About Mantle, I saw this: [http://techreport.com/review/25683/delving-deeper-
into-amd-m...](http://techreport.com/review/25683/delving-deeper-into-amd-
mantle-api/2)

It shows that multiple queues can be used for one GPU. I guess Vulkan can
allow the same but it's not clear from that diagram.

~~~
kllrnohj
Take a look at that again. There's one queue per type. One queue for graphics,
one queue for compute, and one queue for DMA. Note that multiple threads are
all feeding the _single_ graphics queue.

~~~
shmerl
I found the answer:
[https://www.youtube.com/watch?v=EUNMrU8uU5M&t=19m50s](https://www.youtube.com/watch?v=EUNMrU8uU5M&t=19m50s)

Vulkan does support multiple command queues. And there can be several queues
of the same type for one GPU.

------
pjmlp
Looks quite nice, actually.

I thought it might have turned into a LongPeaks 2.0, but from the initial
overview it is quite interesting.

And I really like it seems to be moving forward into a more language agnostic
friendly API and better tooling support.

------
toxicFork
Very exciting! I wonder: when will we be able to start making projects with
this? It would be interesting to see how it compares with OpenCL when it comes
to doing things like Bullet physics' GPU rigid body solver and so on. Also, of
course, ray tracing! :D

~~~
yuumei
Maybe there isn't a spec yet, but it seems there are demos running through
vulkan: [http://blog.imgtec.com/powervr/trying-out-the-new-vulkan-
gra...](http://blog.imgtec.com/powervr/trying-out-the-new-vulkan-graphics-api-
on-powervr-gpus)

~~~
toxicFork
Thanks, this article has some really useful comments. Here's another thread on
r/gamedev about it[1]. Not much discussion as of now but hopefully as people
wake up it may have interesting comments too.

[1]:
[http://www.reddit.com/r/gamedev/comments/2xrobv/an_overview_...](http://www.reddit.com/r/gamedev/comments/2xrobv/an_overview_of_vulkan_the_new_graphics_and/)

------
knappador
The headline made me expect several things until I saw that it was Khronos,
the group that gives us, among other things, OpenGL API's. Looks like the Next
Generation OpenGL is getting more ready to show off.

With Metal and Mantle, it was clear that graphics programmers were wanting to
use GPU's at lower levels of abstraction to more efficiently utilize the
design of GPU's, which have a much different architecture than a decade ago.
Without a corresponding option that is standards compliant, low-level API's
are threatening to fragment GPU programming.

One operation I didn't see any mention of that seems to have some future role,
albeit completely uncertain, is the Heterogeneous System Architecture
Foundation spear-headed by AMD and having seemingly every chip-maker except
Nvidia and Intel on-board.

As GPU stream processors get more CPU-like but are natural at parallel
processing, it is a matter of time before we get the right abstractions so
that map gets scheduled across many stream processors and is reduced by a
higher-single-thread performance CPU and suddenly computer vision and many
other naturally parallel data synthesis workloads are programmed in a less
heterogeneous software environment and executed on chips where the stream
processors and CPU's share a large amount of commonalities, possibly down to
micro-op compatibility through something Nvidia could be pushing towards in
their Denver architecture (as yet highly speculative).

To somewhat less than enthusiastic coverage, Nvidia has been building up their
partnerships with automakers like crazy. Computer vision is obviously one of
the applications that will be required in self-driving cars. Tango and other
projects are also quiet beneficiaries of Nvidia tech maturing into the Tegra
platform.

We have far from conquered programming and CPU design just because JIT's are
good, 8GB of RAM is expected or GPU's can mine MHashes/s etc. We're in some
future's bad-old-days. The idea that Khronos is involved in the unification of
graphics and computing API's as well only makes the exciting question of who
will drive our cars more intriguing.

------
nercury
I find another aspect of this announcement VERY interesting: the SPIR-V
immediate language.

I haven't finished reading the PDF [0] yet, but it looks like LLVM, but for
hardware.

[0]:
[https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf](https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf)

------
sunfish
It is surprising how much semantic significance is placed on whether a
language is encoded in text or binary format.

SPIR-V looks to be a completely new format, not evolved from previous versions
of SPIR. This new version is being described as a "fully specified Khronos-
defined standard", which is great to hear.

------
abalone
_" Rapid progress since June 2014"_

Gee, I wonder what happened in June 2014 to inspire this....

~~~
wodenokoto
What did happen?

~~~
Alphasite_
I think he's reffering to mantle at WWDC.

~~~
kllrnohj
Mantle is from AMD and dates back to 2013. It has nothing to do with Apple or
WWDC.

You're thinking of Metal.

------
iand675
I noticed that it says "the first shading language" to be supported will be
GLSL. Does that imply that there will be a new shading language or extensible
shading language facilities?

------
higherpurpose
Direct access to the GPU...is that done in some kind of sandbox at least? How
do Mantle/Metal/DX12 do it?

~~~
ygra
»Direct« as in »a very thin layer around the GPU's capabilities and workings«,
instead of what OpenGL does currently with massive amounts of state that the
driver has to handle and a movel that doesn't at all work like the GPU does.
This removes a quite hefty translation layer between your software and the
GPU, leading to better performance, fewer hacks and workarounds (hopefully),
etc.

------
shmerl
Now let's hope lock-in proponents won't sabotage this effort.

------
tormeh
Will Playstation 4 support this? That would benefit it a lot. I'm assuming
Xbox One won't.

~~~
guardian5x
The PS4 doesn't even support standard OpenGL, why would they support Vulcan?

~~~
datenwolf
Because Vulcan is very much like the APIs you use on console development to
talk to the GPU. With the main difference that it's been designed to be GPU
vendor neutral.

~~~
pjmlp
Console vendors have always designed their own APIs why change now?

~~~
taeric
I would imagine it comes down to costs. If this api does a good job, why spend
the effort (read: money) to create a new one with all of the tooling around
it?

Though, I should note I doubt this will really save much. Just, on paper it is
a costs savings. (Unless, as usual, I'm wrong on something.)

~~~
pjmlp
Consoles tend to have custom hardware architectures that don't map at all to
generic APIs.

~~~
taeric
I think that was a more true statement before MS enterred the game.

Also, for something as low level as this api sounds, it probably mapped
decently, while still requiring another set of primitives for processor and
memory control.

That is, I think the point of this api is to be a subset that can remain a bit
more common between platforms. Not the all inclusive api that rules
everything.

