[转] 8 reasons why SPIR-V makes a big difference
2015-11-08 16:56
211 查看
转另一篇SPIR-V的文章。
8 reasons why SPIR-V makes a big difference
From all the news that came out of GDC, I’m most eager to talk about SPIR-V. This intermediate language
will
make a big difference for the compute-industry. In this article I’d like to explain why. If you need a technical explanation of what SPIR-V is, I suggest you first read gtruc’s
article on SPIR-V and then return here to get an overview of the advantages.
Currently there are several shader and c ompute languages, which SPIR-V tries to replace/support. We have GLSL, HLSL for graphics shaders, SPIR (without the V), OpenCL, CUDA and many others for compute shaders.
If you have questions after reading this article, feel free to ask them in a comment or to us directly.
Yes, this is the number one reason. This will make SPIR-V a big standard for compute, probably bigger than OpenCL (in its current form). That’s a reason we will go big on this here at StreamComputing.
Vulkan is the stateless version of OpenGL – not even fully released, but now already the future de-facto cross-platform standard for modern graphics. Seems support for it is very complete. As it uses SPIR-V as shader language, this will greatly push SPIR-V.
You have to understand, this is quite aggressive pushing. It unfortunately is needed with all those big corporations having their me-too languages everywhere. Once SPIR-V is everywhere, all languages that compile to SPIR-V are also supported – that probably
will include HLSL, GLSL and various OpenCL languages.
In theory also OpenGL could accept SPIR-V next to GLSL on modern graphics cards – this would avoid the need to have GLSL and SPIR-V next to each other. Same for DirectX and HLSL. There is always demand for writing one single code-base and have support for many
platforms, so expect many languages and tools that can export to and import from SPIR-V.
Lots of input possibilities from GLSL and OpenCL to complete new languages. Currently only two main driver targets. “Other languages” where SPIR-V can export to, includes LLVM.
Even CUDA-kernels or HLSL could get compiled to SPIR. This means that porting can even go faster, if the host-code isn’t too complex.
SPIR-V is the base, not for only OpenCL-C, but also OpenCL-C++, OpenCL-Python, OpenCL-C#, OpenCL-Julia, OpenCL-Java and many more. Creating a single source language
is a simple next step, by making splitting a part of the compile-phase or even using JIT.
See what is already coming
around on Github. I already see Python, dotNET/Linq and GLSL! No HLSL or CUDA yet – ask
us for more info…
Flexibility is key. LLVM has it’s own agenda, which seemed to be too different from what Khronos wanted with SPIR. A few years I wrote “SPIR
by example” where you already see the limits of LLVM for the purposes of SPIR – important data was put in comments. SPIR-V is SPIR without limits.
Many, many languages a problem? Not at all – tools just have to focus on SPIR, and the frontend-compilers need to make sure the mapping to the original source is fluent. This makes it possible to have tool-support for new kernel-languages for free.
SPIR-V is a clean language to have as a frontend-language for LLVM. SPIR-V is expected to get an official LLVM frontend soon. For now there is LunaGLASS’s
project.
As Vulkan has the same API for embedded processors, SPIR-V is also the same for mobile and desktop. There is only the checking of the GPU-capabilities, as we know from OpenCL (memories, compute capabilities), which is simpler to code.
There are two options for handling SPIR-V. First is using an adapted version of the GLSL-compiler, but that won’t be able to use the full spectrum of V’s capabilities without a lot of fixing. The better solution is to adapt the OpenCL-compiler built for that
platform – and that’s what Khronos also had in mind. Above is an image of the flow – as you see OpenCL 2.1 is the minimum version needed.
Where OpenCL kernels could “accidentally” be read, when hidden in the code, SPIR-V gives better legal protection. SPIR-V has to be decoded and falls under the same laws that protect decoding of JAVA or dotNET code.
8 reasons why SPIR-V makes a big difference
From all the news that came out of GDC, I’m most eager to talk about SPIR-V. This intermediate language
will
make a big difference for the compute-industry. In this article I’d like to explain why. If you need a technical explanation of what SPIR-V is, I suggest you first read gtruc’s
article on SPIR-V and then return here to get an overview of the advantages.
Currently there are several shader and c ompute languages, which SPIR-V tries to replace/support. We have GLSL, HLSL for graphics shaders, SPIR (without the V), OpenCL, CUDA and many others for compute shaders.
If you have questions after reading this article, feel free to ask them in a comment or to us directly.
1. It’s used by Vulkan
Yes, this is the number one reason. This will make SPIR-V a big standard for compute, probably bigger than OpenCL (in its current form). That’s a reason we will go big on this here at StreamComputing.Vulkan is the stateless version of OpenGL – not even fully released, but now already the future de-facto cross-platform standard for modern graphics. Seems support for it is very complete. As it uses SPIR-V as shader language, this will greatly push SPIR-V.
You have to understand, this is quite aggressive pushing. It unfortunately is needed with all those big corporations having their me-too languages everywhere. Once SPIR-V is everywhere, all languages that compile to SPIR-V are also supported – that probably
will include HLSL, GLSL and various OpenCL languages.
2.It supports OpenCL C, C++ and more
In theory also OpenGL could accept SPIR-V next to GLSL on modern graphics cards – this would avoid the need to have GLSL and SPIR-V next to each other. Same for DirectX and HLSL. There is always demand for writing one single code-base and have support for manyplatforms, so expect many languages and tools that can export to and import from SPIR-V.
Lots of input possibilities from GLSL and OpenCL to complete new languages. Currently only two main driver targets. “Other languages” where SPIR-V can export to, includes LLVM.
Even CUDA-kernels or HLSL could get compiled to SPIR. This means that porting can even go faster, if the host-code isn’t too complex.
SPIR-V is the base, not for only OpenCL-C, but also OpenCL-C++, OpenCL-Python, OpenCL-C#, OpenCL-Julia, OpenCL-Java and many more. Creating a single source language
is a simple next step, by making splitting a part of the compile-phase or even using JIT.
See what is already coming
around on Github. I already see Python, dotNET/Linq and GLSL! No HLSL or CUDA yet – ask
us for more info…
3. It’s better than the LLVM-based SPIR
Flexibility is key. LLVM has it’s own agenda, which seemed to be too different from what Khronos wanted with SPIR. A few years I wrote “SPIRby example” where you already see the limits of LLVM for the purposes of SPIR – important data was put in comments. SPIR-V is SPIR without limits.
4. Tools can do (static) analysis on SPIR-code
Many, many languages a problem? Not at all – tools just have to focus on SPIR, and the frontend-compilers need to make sure the mapping to the original source is fluent. This makes it possible to have tool-support for new kernel-languages for free.
5. It integrates very well with the existing LLVM too-chain
SPIR-V is a clean language to have as a frontend-language for LLVM. SPIR-V is expected to get an official LLVM frontend soon. For now there is LunaGLASS’sproject.
6. It is the same on mobile processors
As Vulkan has the same API for embedded processors, SPIR-V is also the same for mobile and desktop. There is only the checking of the GPU-capabilities, as we know from OpenCL (memories, compute capabilities), which is simpler to code.
7. It is handled by the OpenCL Runtime
There are two options for handling SPIR-V. First is using an adapted version of the GLSL-compiler, but that won’t be able to use the full spectrum of V’s capabilities without a lot of fixing. The better solution is to adapt the OpenCL-compiler built for that
platform – and that’s what Khronos also had in mind. Above is an image of the flow – as you see OpenCL 2.1 is the minimum version needed.
8. Better IP protection
Where OpenCL kernels could “accidentally” be read, when hidden in the code, SPIR-V gives better legal protection. SPIR-V has to be decoded and falls under the same laws that protect decoding of JAVA or dotNET code.
相关文章推荐
- 用css实现各种导航栏
- js中闭包的理解
- jquery简单的选项卡
- 使用JSON格式传递数据,获取JSON的值
- 超实用的JavaScript代码段 Item5 --图片滑动效果实现
- 超实用的JavaScript代码段 Item5 --图片滑动效果实现
- 前端引擎初步设计稿 -通过配置生成动态页面 ,LandaSugar平台 .NET-C#-MVC
- Jackson和fastjson简单用法及性能对比
- chart.js绘制精美的数据化图形--入门示例
- CSS3扁平化风格博客(笔记)
- CSS-扩展选择器
- CSS-基本选择器
- bootstrap如何把表单select input button弄在一行
- javascript遍历JSON
- position的用法
- Sublime text代码补全插件(支持Javascript、JQuery、Bootstrap框架)
- jsp乱码问题
- jsp 按钮颜色
- 表达式和运算符学习笔记
- DOM 与Jquery模拟表单提交