Would you like to run CUDA-kernels on the OpenCL framework? Or Python or Rust? SPIR-V is the answer! Where source-to-source translations had several limitations, SPIR-V 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 support SPIR-V, making it the first target for the new SPIR-V 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 sPIR-V Really?
So if SPIR-V 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 SPIR-V?
So that’s a big yes for SPIR-V 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++? SPIR-V 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 SPIR-V be the shared language for GPU-kernels. Where do we need OpenCL or CUDA for, if the real work is defined by SPIR-V?
What do you think? Leave your comment below how you see the future of GPGPU with SPIR-V in town. Is 2017 the year of SPIR-V?
And if you worked on a SPIR-V 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?