
Khronos Vulkan API 1.0 release iminant-OSS hetero computing and graphics API - gnarbarian
http://wccftech.com/khronos-group-vulkan-api-release-imminent/
======
gnarbarian
I am super excited for this. It's a key piece missing to the puzzle of modern
high performance computing. It should allow for much more flexible and
portable implementations that will make the most of whatever hardware it is
currently running on. It will be easier to share memory between compute and
graphics threads and it will not be bound to vendor specific hardware.

~~~
mrec
> It should allow for much more flexible and portable implementations

I wish I shared your optimism, but without any support on Mac/iOS and Windows
support only for desktop apps (I don't think Vulkan will be available for
Windows Store apps, though I'd love to be wrong) I don't know how portable
Vulkan is going to be in practice.

Once the middleware matures I'm hoping it'll be a good thing for
predictability, though. And I'll be surprised and disappointed if tooling to
compile DX12 and Metal shaders to SPIR-V doesn't appear in fairly short order,
so if you're using an API abstraction layer then _apps_ should be getting more
portable.

~~~
gnarbarian
My optimism may be getting the best of me. I don't really see this as a silver
bullet that will solve all our problems in a single stroke, but I think it's a
place to start for a sane approach for heterogeneous computing.

when I say "much more flexible and portable implementations" I'm mostly
talking about GPGPU code.

I hear what you're saying, here's to hoping that SPIR-V will be able to fill
in the gaps.

------
dang
There have been several recent threads about the Vulkan API:
[https://hn.algolia.com/?query=vulkan%20points%3E10&sort=byDa...](https://hn.algolia.com/?query=vulkan%20points%3E10&sort=byDate&dateRange=all&type=story&storyText=false&prefix&page=0)

The current article falls in the "announcement of an announcement" category,
which is basically always fluff. If the release is imminent, we can have a
discussion when it exists.

~~~
gnarbarian
Sorry about that. I missed the other discussions. I am pretty pumped to give
this a spin.

------
robbies
An open standard is not OSS, so using those terms here is pretty disingenuous.
You might get AMD to release an open source driver. Not sure if they actually
intend to release a real, performany driver, or just a launcher with hooks
into an ICD

------
douche
What's up with this title? "Khronos Vulkan API 1.0 release iminant-OSS hetero
computing and graphics API" Is OSS hetero computing a new buzzword?

Actual article title is: "Release of Next Generation, Vulkan API is Imminent –
Khronos Group Confirms, API Getting Final Polishes"

~~~
gnarbarian
trying to add some more context but I was limited to 80 characters.

These guys can explain it much better than me:

[https://www.khronos.org/vulkan](https://www.khronos.org/vulkan)

my excited fanboyish rant:

It's an open source cross-platform performance oriented heterogeneous
computing API that enables you to build fast low level code that does a good
job of supporting massive GPU style concurrency as well as CPU style threads
and switch between them at runtime.

With this API it will be easier to write fast parallel code that will make the
most of whatever hardware is available while breaking down the barriers that
arise when managing threads on both system and GPU memory.

In my opinion it is the foundation for the next generation of HPC. I am
interested in this from a performance and from a language perspective. I'd
like to see things like PyCuda and PyOpenCL for vulkan and hooks into other
higher level languages like Go.

Maybe even whole new languages/runtimes built using the vulkan API as the
foundation.

I know I sound a little crazy here but this is something I've been waiting for
for many years. Ever since I ran into issues with cuda and opencl.

~~~
douche
Ah, that 80-char limit is irritating...

I would love to see Vulkan take off and get good adoption. Ultimately, though,
it's going to come down to how good the driver support is, I think. If there
is a serious effort and buy-in from the major vendors and OS providers, then
it might take off. Otherwise, it might just be another thing, and contribute
to the fragmentation in the GPU space.

Will Apple continue with their Metal platform, instead of, or in addition to
Vulkan? Microsoft will back DirectX 12 by default, and if it is a situation
where NVidia or AMD or Intel have to provide decent Windows Vulkan drivers,
we're back to the same situation OpenGL is in. I don't know enough about the
situation in Android-land. General-purpose GPU usage is interesting, but if
Vulkan is going to gain mindshare, game developers are the ones that are going
to have to pick it over any of the alternatives.

~~~
gnarbarian
Game devs are always the first ones aren't they?

Valve is on board:

[http://wccftech.com/vulkan-reason-create-dx12-backend-
valves...](http://wccftech.com/vulkan-reason-create-dx12-backend-valves-
ginsburg/)

Nvidia is on board:

[https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-V...](https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-
Vulkan-Nearing-Release)

Google is onboard for Android:

[http://arstechnica.com/gadgets/2015/08/android-to-support-
vu...](http://arstechnica.com/gadgets/2015/08/android-to-support-vulkan-
graphics-api-the-open-answer-to-metal-and-dx12/)

Of course it's too early to know if it will get traction but I am stoked to
get a chance to play around with the API. I have a few simulations that no
longer work in PyOpenCL and I'm dying to try porting them to something like
vulkan.

[https://www.youtube.com/watch?v=lnOmy1ly6M0&list=PLCN-
Ml6vUJ...](https://www.youtube.com/watch?v=lnOmy1ly6M0&list=PLCN-Ml6vUJ-
JTiqdvcHd0vZVSXDpw_RcW)

~~~
jevinskie
That n-body simulation is very cool.

~~~
gnarbarian
thanks! Here's the archived google code project page containing everything:

[https://code.google.com/p/stableorbit/](https://code.google.com/p/stableorbit/)

But I suspect you'd be more interested in the Github branch if you felt like
taking a look at how I and a friend butchered some pyopencl example code and
got it working:

[https://github.com/ubernaut/stableorbit/tree/pyopencl-
nbody](https://github.com/ubernaut/stableorbit/tree/pyopencl-nbody)

