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

51–60 of 97 posts

Re: Vulkan – Graphics and computing belong together

#51

Post by pjmlp »

datenwolf wrote: post #48
pjmlp wrote: post #45

Earlier quoted context omitted.

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.

Sure, but like PTX/CUDA it will mean you can write shaders in other languages with a better hardware mapping, instead of compiling them to GLSL/OpenCL C source, which is currently one advantage of CUDA.

Re: Vulkan – Graphics and computing belong together

#52

Post by a-priori »

moron4hire wrote: post #50
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…

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

Are you referring to the microcode updates that operating systems apply on startup? Those are binary blobs, but they're only to correct CPU errata.

Re: Vulkan – Graphics and computing belong together

#53

Post by datenwolf »

pjmlp wrote: post #51
datenwolf wrote: post #48

Earlier quoted context omitted.

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.

Sure, but like PTX/CUDA it will mean you can write shaders in other languages with a better hardware mapping, instead of compiling them to GLSL/OpenCL C source, which is currently one advantage of CUDA.

Oh yes, I've been waiting to do that with OpenGL for a looong time. As a matter of fact I preferred working with the ARB_vertex_program and ARB_fragment_program extensions; I even designed (but never fully implemented) a custom, Lisp inspired language that compiles into the ARB_???_program assembly.

Re: Vulkan – Graphics and computing belong together

#54

Post by moron4hire »

a-priori wrote: post #52
moron4hire wrote: post #50

Earlier quoted context omitted.

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

Are you referring to the microcode updates that operating systems apply on startup? Those are binary blobs, but they're only to correct CPU errata.

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, but the motherboard didn't have the latest BIOS on it, and I didn't have a compatible CPU on hand. This was also before the liberal return policies that online vendors now have, so I ended up just ordering a different motherboard completely.

Re: Vulkan – Graphics and computing belong together

#55

Post by ixtli »

readstoomuch wrote: post #16
saschispatzi wrote: post #11

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?

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.

Re: Vulkan – Graphics and computing belong together

#56

Post by runeks »

moron4hire wrote: post #50
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…

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

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.

Re: Vulkan – Graphics and computing belong together

#57

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

#58

Post by graycoder »

moron4hire wrote: post #54
a-priori wrote: post #52

Earlier quoted context omitted.

Are you referring to the microcode updates that operating systems apply on startup? Those are binary blobs, but they're only to correct CPU errata.

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 use all of its features. Some graphics cards won't even use a display's full resolution without the correct driver.

This is different to the CPU in that there is no big downloaded driver sitting between you and it.

If you really want to understand where everything sits, you should check out a book or search for information on Computer Architecture.

Re: Vulkan – Graphics and computing belong together

#59

Post by nightski »

runeks wrote: post #56
moron4hire wrote: post #50

Earlier quoted context omitted.

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

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

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?

Post reply on HN