[游戏开发]Shader入门学习记录⑤——平台差异及语法规范

1. 渲染平台差异

考虑到Unity	其极强的跨平台性，大多时候Unity为我们隐藏实现了很多细节，
但是有时候还是需要我们自己处理他们。

因为OpenGL 和DirectX 的屏幕空间坐标的差异。在水平方向上，两者的数值变化方向是相同的，但是在竖直方向上，两者是相反的。在OpenGL 中，原点（0,0）对应了屏幕的左下角，而在DirectX 中，原点（0,0）对应了屏幕的左上角。

需要注意的是，我们不仅可以吧渲染结果输出到屏幕上，还可以输出到不同的渲染目标中。这时，我们需要使用渲染纹理来保存这些渲染结果。
大多情况下，这样的差异并不会对我们造成任何影响，但当我们需要使用渲染纹理技术，把屏幕图像渲染到一张渲染纹理中时，如果不采取任何措施的话，就会出现纹理翻转的情况。好在Unity在背后为我们处理了这种翻转问题——当在DirectX平台上使用渲染到纹理技术时，Unity会为我们翻转屏幕图像纹理，以便在不同平台上达到一致。
但在一种特殊情况下，Unity是不会为我们进行翻转操作，这种请求就是我们开启了抗锯齿，并在此时使用了渲染到纹理技术。这种情况下，Unity 首先渲染得到的图像，再由硬件进行抗锯齿后，得到一张渲染纹理来供我们进行后续处理。此时，在DirectX 平台规定的。如果我们的屏幕特效只需要处理一张渲染图像，我们仍然不需要在意纹理的旋转问题，这是因为在我们调用Graphics.Blit函数时，Unity 已经为我们对屏幕图像的采样坐标进行了处理，我们只需要按照正常的采样过长处理平面图像即可。但如果我们需要同时处理多张渲染图像（前提是开启抗锯齿），例如需要同事处理屏幕图像和法线纹理，这些图像在竖直方向的朝向就可能是不同的（只有在DirectX这样的平台上才有这样的问题）。这种时候，我们需要自己在顶点着色器中翻转某些渲染纹理的纵坐标，使其符合DirectX平台的规则。

//开启 抗锯齿 ，且同时处理多张渲染图像时，DX平台需要翻转
// UNITY_UV_STARTS_AT_TOP 判断是处于DX平台
#if UNITY_UV_STARTS_AT_TOP   
    if(_MainTex_TexelSize.y < 0)// 判断是否开启抗锯齿
        uv.y = 1-uv.y;
#endif

2. Shader 的语法差异

在DirectX9/11中，对语法的要求相对OpenGL会更加的严格

// v是float4 类型，但在我们构造器中我们仅提供一个参数
float4 v = float4(0.0);

例如在OpenGL 平台上，上面的代码是合法的，它将得到的一个4个分量都是0.0的float4类型的变量。但在DirectX 11 平台上，我们必须提供和变量类型相匹配的参数数目。也就是说我们应该输入写下面的代码格式：

float4 v = float4(0.0,0.0,0.0,0.0);

此外，一些语义在某些平台上是等价的，例如SV_POSITION 和 POSITION 。但是在另一个平台上，这些语义是不等价的。为了让Shader能够在所有平台上正常工作，我们应该尽可能的使用下面的语义来描述Shader的输入输出变量：

• 使用SV_POSITION 来描述顶点着色器输出的顶点位置。一些Shader 使用了POSITION 语义，但这些Shader 无法在索尼PS4平台上或使用了细分着色器上正常工作。
• 使用SV_Target 来描述片元着色器的颜色。一些Shader使用了COLOR 和 COLOR0 语义，同样的，这些Shader 无法在索尼PS4 上正常工作。

3. 规范语法

float、half和fixed

表 3.1 常用数据类型精度

上面的精度范围并不是绝对正确的，尤其是在不同的平台和GPU上，它们实际的精度可能和上面给出的范围不一致。通常来讲。

• 大多数现代的桌面GPU会把所有计算都按最高的浮点数进行计算，也就是说，float、half和fixed这些平台上实际是等价的。这意味着，我们在PC上很难看出因为half和fixed精度儿带来的不同。
• 但在移动平台的GPU上，它们的确会有不同的精度范围，而且不同精度的浮点数的运算速度也会有差异。因此，我们应该确保在真正的移动平台上验证我们的Shader。
• fixed精度实际上只在一些较旧的移动平台上有用，在大多数现在的GPU上，它们的内部把fixed和half当成同精度来对待。

尽管有上面的不同，但一个基本建议是，尽可能使用精度较低的类型，因为这可以优化Shader的性能，这一点在移动平台上尤其重要。从它们大体的值域范围来看，我们可以使用fixed类型来存储颜色和单位矢量，如果要存储更大范围的数据可以选择half类型，最差情况下再选择使用float。如果我们的目标平台是移动平台，一定要确保手机上测试我们的Shader。

避免不必要的计算

如果我们毫无节制的在Shader中进行大量计算，那么我们可能很快就会收到Unity的错误提示：

temporary register limit of 8 exceeded

或

Arithmetic instruction limit of 64 exceeded; 65 arithmetic instructions needed to compile program

出现这些错误信息大多是因为我们在Shader 中进行了过多的运算，使得需要的临时寄存器数目或指令数目超过了当前可支持的数目。需要知道，不同的 Shader Target 、不同的着色器阶段，可使用的临时寄存器和指令的数目都是不相同的。
通常，我们可以通过指定更高等级的 Shader Target 来消除这些错误。

表 3.2 Unity支持的 Shader Target

需要注意的是，所有类型OPenGL的平台（包括移动平台）被当成是支持到Shader Model 3.0的。
Shader Model 是由微软提出的一套规范，通俗地理解就是它们决定了Shader中各个特性的能力。这些特性和能力体现在Shader能使用的运算指令数、寄存器个数等各个方面。Shader Model 等级越高，Shader的能力越大。
虽然更高等级的Shader Target 可以让我们使用更多的临时寄存器和运算指令，但一个更好的方法是尽可能减少Shader中的运算，或者通过预计算的方法来提供更多的数据。

慎用分支和循环语句

在常见的编程语言中，类似分支、循环语句这样的流程控制语句最基本的语法之一。但在编写Shader的时候，我们要对它们格外的小心。
在Shader中使用大量的流程控制语句，那么这个Shader的性能可能会成倍的下降，因为它们会降低GPU的并行处理操作。一个解决办法是，我们应该尽量把计算向流水线上端移动，例如把放在片元着色器中的计算放到顶点着色器中，或者直接在CPU中进行预计算，在把结果传输给Shader。如果有时候我们避不可免地要使用分支语句来进行运算，那么一些建议是：

• 分支判断语句中使用条件变量最好是常数，即在Shader运行过程中不会发生变化；
• 每个分支中包含的操作指令数尽可能少；
• 分支的嵌套层数尽可能少。

不要除以0