Khronos Group Announces Vulkan, OpenCL 2.1, SPIR-V

[VanCoding]

Interesting topic

Thanks for the answers! But that throws up even more questions to me :P

Okay, SPIR-V is the language that's supposed to run on every GPU because there will be a VM that translates SPIR-V to the GPU-specific machine code at runtime. Nice!
But one thing that's still a bit unclear to me is the following: Doesn't the VM that translates SPIR-V to GPU code actually need to run directly on the GPU itself? Like the Java VM runs on the CPU?
Or does the VM run on the CPU and then send the GPU code instruction by instruction to the GPU? That's a bit confusing to me...

Is it right that every driver will consist of the following 3 parts:
- SPIR-V-VM
- Vulkan API
- OpenCL API

?

[geearf]

Your SPIR-V VM lives in the driver.

[VanCoding]

Okay, so the VM that converts SPIR-V to GPU specific machine code actually runs on the CPU and then sends the instructions to the GPU.

That leads me to one last question:

Why doesn't Khronos just standardize the API for the SPIR-V VM? This would have the effect that there could be just one Vulkan driver and one OpenCL driver. They could even be in different kernel modules.
Do GPUs provide instructions that a Vulkan driver needs, that cannot be used from SPIR-V, so that the Vulkan driver has to natively execute those instructions on the GPU itself, bypassing the SPIR-V VM?

Thanks for answering! that topic is really interesting for me

[log0]

Okay, so the VM that converts SPIR-V to GPU specific machine code actually runs on the CPU and then sends the instructions to the GPU.

That leads me to one last question:

Why doesn't Khronos just standardize the API for the SPIR-V VM? This would have the effect that there could be just one Vulkan driver and one OpenCL driver. They could even be in different kernel modules.
Do GPUs provide instructions that a Vulkan driver needs, that cannot be used from SPIR-V, so that the Vulkan driver has to natively execute those instructions on the GPU itself, bypassing the SPIR-V VM?

Thanks for answering! that topic is really interesting for me

There is no (need for a) VM, don't know where you guys get this idea from.

They are simply moving compiler frontend out of the driver (as it is not hardware specific, can be shared, replaced by other frontends):

[geearf]

Why doesn't Khronos just standardize the API for the SPIR-V VM?

Isn't that what Vulkan is? or am I missing something from your question?

[VanCoding]

There is no (need for a) VM, don't know where you guys get this idea from.

They are simply moving compiler frontend out of the driver (as it is not hardware specific, can be shared, replaced by other frontends)

Oh, well, that explains a lot Sorry, when I read that it's comparable to Java and jar files, I immediately assumed that SPIR-V has to be some bytecode that's meant to be directly converted to machine code at runtime.
But SPIR-V thus really is a programming language that's readable and writable by humans, exactly like LLVM.

So, if you say that they moved the compiler frontend out of the driver, did you mean that the driver itself now only can handle the IR of SPIR-V, and converts it to machine code which then gets executed on the CPU?
If yes, is Vulkan the API that provides functions to convert IR to machine code & execute it?
If that's also true, I have to ask again: What's OpenCL for then? Doesn't its API provide similar functionality?

[Kano]

@Geri

Is your own engine running too slow or do you think it is fast enough? Many engines that are used for shooters or in future for VR really need maximum speed - did you think of 4k gaming yet? If there is a driver overhead that can be optimized in a better way, why don't use it? Vulkan does not restrict you to use a specific shader languge, for Mantle you would have needed to use HLSL (which is why that API would be a bit useless on Linux imho). GLSL will be most likely supported first, but basically other languages could be supported as well.

Right now there are many games that run much slower with OpenGL compared to DirectX, like Serious Sam 3 - even with a native port. On Windows you can expect that major games got replaced optimized shaders by the main gfx vendors, that means Nvidia or AMD are optimizing your code for free if your game/engine is a success, maybe they help you even with your code directly. I really hate to say that there are only few games with native Linux port which run fast. Some are only fast with Nvidia gfx, not sure what AMD/fglrx does differently (most likely not multithreaded). I expect as soon as SPIR-V is used the optimzation part is much simpler/generic than replacing full high level shader code MANUALLY - AMD did that not for CS:GO binary yet btw. What do you think gives the game related speed boost in (mainly) Windows driver updates?

[dragorth]

Correct

Isn't that what Vulkan is? or am I missing something from your question?

That is indeed what Vulcan is. And yes, graphics chips do indeed provide features that won't be covered by SPIR-V. Its important to note what SPIR-V is targeting. It only deals with the computational units of the graphics processor. The cards themselves have to deal with other things, such as refresh rates, resolution, memory management, video codecs (while you can use the compute units to decode video, most chips provide dedicated silicon to handle different codecs, as this is cheaper to manufacture and implement.)

Vulcan is also where the control logic for an application will be written, since the cpu is better at that task than the gpu. Look at it like this, (yes this is an overly broad simplification), Vulcan answers the question of when and how to get data to the gpu, whereas SPIR-V is what we do to it once it is on there, then Vulcan takes the modified data and outputs it to the screen.

[dragorth]

OpenCL has a different use case.

Oh, well, that explains a lot Sorry, when I read that it's comparable to Java and jar files, I immediately assumed that SPIR-V has to be some bytecode that's meant to be directly converted to machine code at runtime.
But SPIR-V thus really is a programming language that's readable and writable by humans, exactly like LLVM.

So, if you say that they moved the compiler frontend out of the driver, did you mean that the driver itself now only can handle the IR of SPIR-V, and converts it to machine code which then gets executed on the CPU?
If yes, is Vulkan the API that provides functions to convert IR to machine code & execute it?
If that's also true, I have to ask again: What's OpenCL for then? Doesn't its API provide similar functionality?

OpenCL has a different use case. Its intended audience is for high end data crunching, where the result is needed by the program that called it. Picture a spreadsheet, like LibreOffice, computing all the cells in a 1mil x 1mil grid. On a cpu, this could take tens minutes or hours. On a gpu, it could take seconds or a few minutes. Or, you are computing light rays on a 3D object, to compute an image. You are expecting the image in the form of something you an save on the computer back as the output.

GLSL, HLSL and other graphics shading languages are intended to compute something that returns directly for gpu use. So, it is strictly for displaying the computing data on screen. (Yes, anyone can hack around this to do crazy things, but this is the designed purpose.)

These are usually optimized for pixel information, whereas OpenCL is a more general purpose language that does not limit your interactions with the gpu to remain on the gpu, as well as providing a larger array of primitive types geared toward heavily parallel problems.

[erendorn]

Oh, well, that explains a lot Sorry, when I read that it's comparable to Java and jar files, I immediately assumed that SPIR-V has to be some bytecode that's meant to be directly converted to machine code at runtime.
But SPIR-V thus really is a programming language that's readable and writable by humans, exactly like LLVM.

So, if you say that they moved the compiler frontend out of the driver, did you mean that the driver itself now only can handle the IR of SPIR-V, and converts it to machine code which then gets executed on the CPU?
If yes, is Vulkan the API that provides functions to convert IR to machine code & execute it?
If that's also true, I have to ask again: What's OpenCL for then? Doesn't its API provide similar functionality?

SPIR-V, as its name implies, is an IR, ie an "intermediate representation". So it is some byte code, and not human readable.
Compiler front end: programming language to IR
Compiler back end: IR to machine specific code
Using some IR lets you decouple these two steps.
SPIR-V is not some API, it is a machine oriented langage. This part will be handled by the driver.
Vulkan is an API, not a programming language, it will most likely converts function calls to spir-V (machine independent), or directly to GPU actions (machine specific, implemented by/linked to driver).