Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vulkan – Graphics and computing belong together

khronos.org

Post reply on HN
Print view View original

61–70 of 97 posts

Re: Vulkan – Graphics and computing belong together

#61

Post by mattnewport »

runeks wrote: 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…

There have been significant benefits to having a driver / runtime layer between the application and the GPU. It has enabled a competitive ecosystem of GPU vendors and I don't think we would have seen as rapid a pace of innovation and performance improvements if we had had a de facto low level hardware interface proprietary to a particular vendor.

This is not to criticize Vulkan, the trend to lower level APIs like Vulkan, DirectX 12 and Metal is a good one but I don't think the goal should be to eliminate the driver entirely or get rid of any hardware abstraction layer on non console platforms.

Re: Vulkan – Graphics and computing belong together

#62

Post by jsheard »

ixtli wrote: post #55
readstoomuch wrote: post #16

Earlier quoted context omitted.

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

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.

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.

Re: Vulkan – Graphics and computing belong together

#63

Post by shmerl »

runeks wrote: post #36
toxicFork wrote: post #13

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

I'm by no means an expert in the field, but if I understand the role of Vulkan correctly, you -- as an application developer -- won't be writing your programs against the Vulkan API. OpenCL will become a library that is implemented by interacting with the GPU via the Vulkan API, and as an application developer you'd use OpenCL. Or perhaps you'd never again use OpenCL, because someone else develops a better library. P…

> I'm by no means an expert in the field, but if I understand the role of Vulkan correctly, you -- as an application developer -- won't be writing your programs against the Vulkan API.

If I understood correctly, for graphics at least Vulkan gives great flexibility to application developers, giving them to decide how to manage multithreading. If developers care about high efficiency (and games usually do need it), they'll use it.

Of course if developers are using third party engines which already handle it for them, they might not need to deal with Vulkan directly. But engine developers would have to in such case.

Re: Vulkan – Graphics and computing belong together

#64

Post by pjmlp »

datenwolf wrote: post #46
guardian5x wrote: post #43

Earlier quoted context omitted.

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.

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

Re: Vulkan – Graphics and computing belong together

#65

Post by [deleted] »

ixtli wrote: post #55
readstoomuch wrote: post #16

Earlier quoted context omitted.

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

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.

[deleted]

Re: Vulkan – Graphics and computing belong together

#66

Post by gergytree »

graycoder wrote: post #58
moron4hire wrote: post #54

Earlier quoted context omitted.

I'm not really sure what exactly they are. I know I've had to update my BIOS to be able to use newer versions of CPUs that still fit in the old sockets before [1]. I know I've seen Windows updates for both the motherboard's chipset and for the CPU. But what difference any of that has made, I don't know. [1] Actually, that particular instance was a complete pain in the ass, because I had bought all of the parts new, b…

You seem to be mixing up different concepts. The BIOS runs outside of the OS and helps all the parts of your computer speak to each other. This is why the process is a bit more involved than just running an update from your OS's update manager. The "binary blob" that's referred to when talking about GPU's is the huge piece of software that you have to download and install in order to make you graphics card able to us…

> You seem to be mixing up different concepts.

This is oversimplifying but my understand is that graphics programs like games send data and instructions as a job into a queue managed by operating system to the CPU which then has to then quickly decide what to do with it. GPU's function as a sort of co-processor in that the CPU will offload a portion or all of the instructions/data of jobs where GPU processing is indicated in the job instructions. This is why all GPU processing involves CPU overhead. Also GPU's are somewhat bottle-necked by this whole process.

It's my impression that current trends like Mantle, DX12 and Vulkan are trying to reduce the amount of stuff the CPU has to do to process jobs intended for the GPU. But they can never really eliminate the role of the CPU even in something like an ARM chip is embedded on the GPU board that handles most of the processing that the CPU would have done.

tl;dr - CPU is what makes the computer happen but the GPU is like a dedicated graphics co-processor.

Feel free to correct me if I'm wrong.

Re: Vulkan – Graphics and computing belong together

#67

Post by taeric »

pjmlp wrote: post #64
datenwolf wrote: post #46

Earlier quoted context omitted.

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.

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

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.)

Re: Vulkan – Graphics and computing belong together

#68

Post by datenwolf »

jsheard wrote: post #33
datenwolf wrote: post #29

Earlier quoted context omitted.

> 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).

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…

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

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

Re: Vulkan – Graphics and computing belong together

#69

Post by moron4hire »

graycoder wrote: post #58
moron4hire wrote: post #54

Earlier quoted context omitted.

I'm not really sure what exactly they are. I know I've had to update my BIOS to be able to use newer versions of CPUs that still fit in the old sockets before [1]. I know I've seen Windows updates for both the motherboard's chipset and for the CPU. But what difference any of that has made, I don't know. [1] Actually, that particular instance was a complete pain in the ass, because I had bought all of the parts new, b…

You seem to be mixing up different concepts. The BIOS runs outside of the OS and helps all the parts of your computer speak to each other. This is why the process is a bit more involved than just running an update from your OS's update manager. The "binary blob" that's referred to when talking about GPU's is the huge piece of software that you have to download and install in order to make you graphics card able to us…

I took the post to which I originally replied to be more concerned about the proprietary nature of the driver, rather than the size. The BIOS is a type of simplistic set of drivers, even a basic operating system, in essence. My point was that the comparison to CPUs with regards to not needing proprietary drivers was not apt, as there are certainly several layers of proprietary code in between you and your CPU, for most systems.

Re: Vulkan – Graphics and computing belong together

#70

Post by pjmlp »

taeric wrote: post #67
pjmlp wrote: post #64

Earlier quoted context omitted.

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

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.)

Consoles tend to have custom hardware architectures that don't map at all to generic APIs.
Post reply on HN