HLSL & CG 与glsl着色器编译及其原理

导言：公司旧的渲染引擎用的结构无语了，要写一个渲染特效现在Unity 用shaderlab实现调试好，Unity插件导出GLTF格式（shader等已经包含在材质信息中），然后再导到自研引擎（用的OPENGL、OPENGLES），又要人为的写一遍GLSL（翻译或者说平台特性需要改，比如Unity移动端 SIGGRAPH2015 的PBR）

Shader简介：

Shader Language的发展方向是设计出在便携性方面可以和C++、Java等相比的高级语言，“赋予程序员灵活而方便的编程方式”，并“尽可能的控制渲染过程”同时“利用图形硬件的并行性，提高算法效率”。
Shader Language目前主要有3种语言：

• 基于 OpenGL 的 OpenGL Shading Language，简称 GLSL;
• 基于 DirectX 的 High Level Shading Language, 简称 HLSL;
• 还有 NVIDIA 公司的 C for Graphic，简称 Cg 语言。

GLSL、HLSL、CG异同点：

GLSL的优点是跨平台！卡友在Windows 、Linux、Mac、Web、移动端跑，但是这种跨平台是由于OPENGL没有提供编译器，而是由显卡驱动来完成的着色器的编译工作；也就是说显卡驱动支持OPENGL它就可以运行。这种做法的好处在于依赖硬件，由于提供商完全了解自己硬件架构，能知道怎么样发挥到最大作用。GLSL是依赖于硬件而非操作系统，所以硬件不一样结果可能不一样；

HLSL由微软控制的着色器，就算有不同的硬件，同一个着色器编译是一样的（前提是版本一样），但是缺点是只能在微软的平台，当然HLSL相比GLSL渲染什么的走得更前面。

CG才是真正意义上的跨平台。它会根据平台的不同编译成相应的中间语言，CG语言的跨平台性很大程度取决于与微软的合作，这也导致CG和HLSL非常相似，CG可以无缝移植到HLSL平台上，但是缺点是无法完全发挥OPENGL的新特性。

shader 编译平台：

shader线上转换编译平台

Shader运行机制：

GPU架构的shader运行机制

编译着色器：

Windows创建一个compile.bat文件，它的内容如下：

C:/VulkanSDK/1.0.17.0/Bin32/glslangValidator.exe -V shader.vert
C:/VulkanSDK/1.0.17.0/Bin32/glslangValidator.exe -V shader.frag

pause
读者需要将上面代码中glslangValidator.exe的文件路径替换为自己的glslangValidator.exe所在的文件路径。双击运行这个文件，就可以完成着色器代码的编译。Linux
创建一个compile.sh文件，它的内容如下：

/home/user/VulkanSDK/x.x.x.x/x86_64/bin/glslangValidator -V shader.vert
/home/user/VulkanSDK/x.x.x.x/x86_64/bin/glslangValidator -V shader.frag

读者需要将上面代码中glslangValidator的文件路径替换为自己的glslangValidator所在的文件路径。然后在终端中使用chmod +x compile.sh给予它可执行的权限，最后运行它。
使用两行代码使用-V选项调用编译器，将GLSL着色器代码文件转换为SPIR-V字节码格式。运行脚本后，读者可以在当前文件夹下看到两个新的文件vert.spv和frag.spv。这两个文件的文件名由编译器自动推导出来，读者可以使用自己喜欢的名称重命名这两个文件。编译脚本的执行过程中可能出现一些缺少特性的警告，读者可以放心地忽略掉这些警告。
如果着色器代码存在语法错误，编译器会报告语法错误所在的行，以及错误出现的原因。读者可以尝试去掉某行着色器代码的分号，让编译器检查这一语法错误，熟悉编译器的报错信息的。也可以尝试不使用任何选项调用编译器来查看编译器支持的选项种类。此外，编译器还支持将SPIR-V格式的字节码反向编译为便于人类阅读的代码格式。载入着色器已经得到了SPIR-V格式的着色器字节码文件，现在需要在应用程序中载入字节码文件。为了完成这项工作，首先编写一个用于载入二进制文件的辅助函数。

shaderlab的转换：

unity里面本来就可以写glsl，相关互转工具也都是开源的，shaderlab编译之后是可以看到对应的glsl代码
unity选对应的平台，点一下shader上那个compile按钮，就看得到glsl代码了：
但是翻译出来的代码不是人看的：

着色器编译后都是spirit-v. risc-v的，

shader转换新增额外的代码

这里主要是回复知乎底下评论问我的，文章中我自己把unity shader转换成GLSL的例子我都没变成了“不是人看的代码”，增加了非常多的代码或者变量的问题；

主要是基于以下几个点导致增加额外的代码：

1. 兼容性（主要）
   Unity是跨平台的，基于我们图形后端开发的经验告诉我们：为了确保Shader在不同的设备上都能正确运行，编译器会插入特定的代码来处理不同硬件和驱动程序的兼容性问题！

2. 抽象层
   Unity使用抽象层ShaderLab来简化Shader开发。这种抽象层允许开发者写出更可维护、更易于理解的高级Shader代码。比如unity
   shader实现多pass,只需要写一个然后其余配置即可。但是当编译这些Shader时，Unity需要将它们转换为实际的GLSL代码，包括临时变量的生成，用以确保代码运行效率。

3. 预处理器和宏定义的展开
   Unity允许在Shader中使用预处理器指令和宏，以控制Shader的编译过程。展开这些宏可能导致大量的重复代码或额外的逻辑，从而增加了最终GLSL代码的长度（跟多pass的类似）。

4. 性能优化
   作为一个强大而且主流的游戏引擎为了提升性能，Unity Shader编译器会进行很多底层的优化。这可能涉及到添加中间变量用于缓存计算结果，展开循环，内联函数，以及对代码进行重新排序等。这些优化会导致更多的代码生成。

5. 语法差异的代码移植（主要）
   Unity Shader在编写时往往采用类似HLSL的语法，编译器需要将其转换成适用于OpenGL的GLSL代码。由于这两种shader语法等的差异这个过程可能引入额外的类型转换和中间变量，以确保功能和行为的一致性。

6. 驱动程序工作规避 （较少）
   不同的GPU和驱动程序可能存在特定的bug或限制。为了规避这些问题，Unity的Shader编译器可能会添加额外的代码，甚至是在知道某些代码路径不会被执行的情况下也要添加，以确保在所有目标平台上的稳定性。

参考资料：

opengl 着色器的编译
《OpenGL编程指南》一2.5　着色器的编译
HLSL 交叉编译器
DirectX 着色器字节码交叉编译器。
vulkan shader编译