Live data from Hacker News

Vulkan – Graphics and computing belong together

khronos.org

41–50 of 97 posts

Re: Vulkan – Graphics and computing belong together

#41
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.

Re: Vulkan – Graphics and computing belong together

#42
post #2

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 pa…

Speaking of path tracing, I hope Khronos keeps an eye to the future for Vulkan in regards to supporting path tracing. I don't think we're too many years away from seeing gaming engines or graphics card makers support path tracing in a big way (mainly because I think it's the future of gaming, especially for VR gaming - which is also the future of gaming itself). Vulkan should be optimized for that from the beginning and not tacked-on later.

Re: Vulkan – Graphics and computing belong together

#44
post #38

Earlier quoted context omitted.

> I had a long debate on multiple forums recently regarding the almost uselessness of OpenGL in presence of something like OpenCL, > (...) > I realized this very strongly when I considered doing graphics using OpenGL but with a photorealistic renderer like a path tracer. Well, then you're going be disappointed by Vulkan as well. OpenGL (and modern GPUs) are built around screen space rasterization of points, lines and…

>It's much more low level. And there's no strong type safety remaining. It seems from the Vulkan Language Ecosystem graphic that they expect new languages to be developed that translate to Vulkan, for those who want to work at a higher level.

> It seems from the Vulkan Language Ecosystem graphic that they expect new languages to be developed that translate to Vulkan, for those who want to work at a higher level.

Actually no, because Vulkan itself is just a API. But what you can do it create high-level bindings, similar to, say, the Haskell X bindings that immediately leverage the asynchronous execution, lazy evaluation and built-in concurrent parallelism.

Also typesafety regarding the buffer contents can be mapped into a Hindley-Miller system as well, by looking at the tuple `(memory handle, descriptor)`; in Haskell (e.g.) that'd nicely map into a type constructor.

Re: Vulkan – Graphics and computing belong together

#45
post #38

Earlier quoted context omitted.

>It's much more low level. And there's no strong type safety remaining. It seems from the Vulkan Language Ecosystem graphic that they expect new languages to be developed that translate to Vulkan, for those who want to work at a higher level.

> It seems from the Vulkan Language Ecosystem graphic that they expect new languages to be developed that translate to Vulkan, for those who want to work at a higher level. Actually no, because Vulkan itself is just a API. But what you can do it create high-level bindings, similar to, say, the Haskell X bindings that immediately leverage the asynchronous execution, lazy evaluation and built-in concurrent parallelism.…

I think he/she meant targeting SPIR-V with your language of choice.

Re: Vulkan – Graphics and computing belong together

#46
post #40

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

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

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.

Re: Vulkan – Graphics and computing belong together

#47
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.

Re: Vulkan – Graphics and computing belong together

#48
post #45

Earlier quoted context omitted.

> It seems from the Vulkan Language Ecosystem graphic that they expect new languages to be developed that translate to Vulkan, for those who want to work at a higher level. Actually no, because Vulkan itself is just a API. But what you can do it create high-level bindings, similar to, say, the Haskell X bindings that immediately leverage the asynchronous execution, lazy evaluation and built-in concurrent parallelism.…

I think he/she meant targeting SPIR-V with your language of choice.

SPIR-V is on a completely different level. The Vulcan API is called by the binary running on the CPU. The binary generated from SPIR-V is executed on the compute device, which in 99% or all cases that Vulkan is concerned with will be the GPU.

In the same way you don't use GLSL to program OpenGL, you don't use SPIR-V to program Vulkan. GLSL/SPIR are to OpenGL/Vulkan what browser-side JavaScript is to a webserver.

Re: Vulkan – Graphics and computing belong together

#49

Earlier quoted context omitted.

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?

I'm a cynic, but don't get me wrong, I'd be delighted if Vulkan or OpenCL 2.1 show up in OS X 10.11. Khronos is a funny beast, a bit like the United Nations. Just because these companies are all part of it doesn't mean they actually like each other and want to cooperate! Apple has famously lagged far behind with their implementation of OpenGL. They only support OpenGL 4.1, the spec for which was released in 2010 [1].…

> Khronos is a funny beast, a bit like the United Nations. Just because these companies are all part of it doesn't mean they actually like each other and want to cooperate!

It seems to me that this is an accurate description for any technology focused consortium or work group.

Re: Vulkan – Graphics and computing belong together

#50
post #32

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 O…

I thought CPUs did have binary blob drivers, both in the BIOS and on the operating system.
Post reply on HN