Would you like to run CUDA-kernels on the OpenCL framework? Or Python or Rust? SPIRV is the answer! Where source-to-source translations had several limitations, SPIRV 1.1 even supports higher level languages like C++.
SPIRV is the strength of OpenCL and it will only get bigger.
Currently Intel drivers best supports SPIRV, making it the first target for the new SPIRV-frontends. It is unknown which vendor will be next – probably one which (almost) has OpenCL 2.0 drivers already, such as AMD, ARM, Qualcomm or even NVidia.
How interesting is SPIRV really?
So if SPIRV is really that important a reason to choose for OpenCL, I thought of framing it towards CUDA-devs on twitter in a special way:
Should CUDA 9 support SPIRV?
So that’s a big yes for SPIRV-support on CUDA. And why not? Don’t we want to program in our own language and not be forced to use C or C++? SPIRV makes it possible to quickly add support in any language out there without official support of the vendor. Let wrappers handle the differences per vendor and let SPIRV be the shared language for GPU-kernels. Where do we need OpenCL or CUDA for, if the real work is defined by SPIRV?
What do you think? Leave your comment below how you see the future of GPGPU with SPIRV in town. Is 2017 the year of SPIRV?
And if you worked on a SPIRV-frontend, get in touch to continue your project on https://github.com/spirv. Yes, it’s empty right now, but you don’t know what’s hidden.
What do you mean by “where do we need…CUDA for”? Cuda is a much higher level API than SPIRV, and includes a slew of high-performance libraries that can be used with it. Do you mean to simply compile other languages to SPIR V and run them on the GPU? How would you take advantage of the parallelism without dedicated parallel APIs? Please elaborate.
“Cuda is a much higher level API than SPIRV”
Are you sure your statement is right?
Cuda can be written in C or C++. SPIR-V is an IR language that resembles assembly code. Typically, higher-level languages are compiled directly to SPIR-V byte-code, and not to assembly text. Perhaps I”m just misunderstanding what you’re saying here, which is why I asked the question.
SPIRV is a different representation, and as you can interchange between RV and OpenCL C++/CUDA/GLSL/HLSL/etc, they’re same level.
About the remark. Say we want GPU-support in every programming language, which is going to happen (and that will end the special languages OpenCL, CUDA, Metal, etc). Then SPIRV would be a good target for all these languages to export to.
I assume what you’re saying is that the other languages can be compiled to SPIRV, right? I supposed I was just a bit confused, because it seemed you were saying it could replace them as a language in its own right.
I imagine there will be a convergence between CPU and GPU programming at some point. Until then, though, you would still need an API designed for parallel processing on a GPU architecture. SPIRV doesn’t provide that by itself. And then there’s the numerous optimized NVIDIA libraries. There are a lot of devils in the details.
Surely those nvidea libraries can (and presumably will) be recompiled to generate SPIR-V intermediate code, making them callable on all architectures supporting SPIR-V, and by all languages supporting SPIR-V?