1. 程序员的烦恼：Debug
调试（debug），大概是所有程序员的噩梦。而不幸的是，对一个Shader进行调试更是噩梦中的噩梦。这也是造成Shader难写的原因之一——如果发现得到的效果不对，我们就可能花非常多的时间来找到问题所在。造成这种现状的原因就是在Shader中可以选择的调试方法非常有限，甚至连简单的输出都不行。
2. 最新利器：帧调试器
Unity5除了带来全新的UI系统外，还为我们带来了一个新的针对渲染的调试器——帧调试器（Frame Debugger）。与其它调试工具的复杂性相比，Unity原生的帧调试器非常简单快捷。我们可以用它来看到游戏图像的某一帧是如何一步步渲染出来的。
要使用帧调试器，我们首先需要在Window->Frame Debugger中打开帧调试器窗口，如下图所示：
帧调试器可以用于查看渲染该帧时进行的各种渲染事件（event），这些事件包含了Draw Call序列，也包括了类似清空缓存等操作。帧调试器窗口大致可分为3个部分：最上面的区域可以开启/关闭（单击Enable按钮）帧调试功能，当开启了帧调试时，通过移动窗口最上方的滑动条（或单击前进和后退按钮），我们就可以重放这些渲染事件；左侧区域显示了所有事件的树状图，在这个树状图中，每个叶子节点就是一个事件，而每个父节点的右侧显示了该节点下的事件数目。我们可以从事件的名字了解这个事件的操作，例如以Draw开头的事件通常就是一个Draw Call；当单击了某个事件时，在右侧的窗口就会显示该事件的细节，例如几何图形的细节以及使用了哪个Shader等。同时在Game视图中我们也可以看到它的效果。如果该事件是一个Draw Call并且对应了场景中的一个GameObject，那么这个GameObject也会在Hierarchy视图中被高亮显示出来，下图显示了单击渲染某个对象的深度图事件的结果。
如果被选中的Draw Call是一个对渲染纹理（RenderTexture）的渲染操作，那么这个渲染纹理就会显示在Game视图中。而且，此时右侧面板上方的工具栏中也会出现更多的选项，例如在Game视图中单独显示R、G、B和A通道。
Unity5提供的帧调试器实际上并没有实现一个真正的帧拾取（frame capture）的功能，而是仅仅使用了停止渲染的方法来查看渲染事件的结果。例如我们想要查看第4个Draw Call的结果，那么帧调试器就会在第4个Draw Call调用完毕后停止渲染。这种方法虽然简单，但得到的信息也有限。
3. 小心渲染平台的差异
我们以前提到过OpenGL和DirectX的屏幕空间坐标的差异，如下图所示：
需要注意的是，我们不仅可以把渲染结果输出到屏幕上，还可以输出到不同的渲染目标（Render Target）中。这时，我们需要使用渲染纹理（Render Texture）来保存这些渲染结果。我们将在后面学习如何实现这样的目的。
大多数情况下，这样的差异并不会对我们造成任何影响。但当我们要使用渲染到纹理技术，把屏幕图像渲染到一张渲染纹理时，如果不采取任何措施的话，就会出现纹理翻转的情况。幸运的是，Unity在背后为我们处理了这种翻转问题——当在DirectX平台使用渲染到纹理技术时，Unity会为我们翻转屏幕图像纹理，以便在不同平台上达到一致性。
在一种特殊情况下Unity不会为我们进行这个翻转操作，这种情况就是我们开启了抗锯齿（在Edit->Project Setting->Quality->Anti Aliasing中开启）并在此时使用了渲染到纹理技术。在这种情况下，Unity首先渲染得到屏幕图像，再由硬件进行抗锯齿处理后，得到一张渲染纹理来供我们进行后续处理。此时，在DirectX平台下，我们得到的输入屏幕图像并不会被Unity翻转，也就是说，此时对屏幕图像的采样坐标是需要符合DirectX平台规定的。如果我们的屏幕特效只需要处理一张渲染图像，我们仍然不需要在意纹理的翻转问题，这是因为我们在调用Graphics.Blit函数时，Unity已经为我们对屏幕图像的采样坐标进行了处理，我们只需要按照正常的采样过程处理屏幕图像即可。但如果我们需要同时处理多张渲染图像（前提是开启了抗锯齿），例如需要同时处理屏幕图像和法线纹理，这些图像在竖直方向的朝向可能是不同的（只有在DirectX这样的平台上才有这样的问题）。这种时候，我们就需要自己在顶点着色器中翻转某些渲染纹理（例如深度纹理或其它由脚本传递过来的纹理）的纵坐标，使之都符合DirectX平台的规则。例如：
#if UNITY_UV_STARTS_AT_TOP
if（_MainTex_TexelSize.y<0）
uv.y = 1- uv.y;
#endif其中，UNITY_UV_STARTS_AT_TOP用于判断当前平台是否是DirectX类型的平台，而在这样的平台下开启了抗锯齿后，主纹理的纹理大小在竖直方向上会变成负值，以方便我们对主纹理进行采样。因此，我们可以通过判断_MainTex_TexelSize.y是否小于0来检验是否开启了抗锯齿。如果是，我们就需要对主纹理外的其他纹理的采样进行竖直方向上的翻转。
4. Shader的整洁之道
4.1 float、half还是fixed
我们使用Cg/HLSL来编写UnityShader中的代码。而在Cg/HLSL中，有三种精度的数值类型：float，half和fixed。这些精度将决定计算结果的数值范围。下表给出了这3种精度在通常情况下的数值范围。
Cg/HLSL中3种精度的数值类型
类型 | 精度 |
float | 最高精度的浮点值。通常用32位来存储 |
half | 中精度的浮点值。通常用16位来存储，精度范围是-60000~+60000 |
fixed | 最低精度浮点值。通常用11位来存储，精度范围是-2.0~+2.0 |
上面的精度范围并不是绝对正确的，尤其是在不同平台和GPU上，它们的实际精度可能和上面给出的范围不一致。通常来讲： （1）大多数现代的桌面GPU会把所有计算都按最高的浮点精度进行计算，也就是说，float、half、fixed在这些平台上实际是等价的。这意味着，我们在PC上很难看出因为half和fixed精度而带来的不同。 （2）但在移动平台GPU上，它们的确会有不同的精度范围，而且不同精度的浮点值的运算速度也会有所差异。因此，我们应该确保在真正的移动平台上验证我们的Shader。 （3）fixed精度实际上只在一些较旧的移动平台上有用，在现在大多数现代的GPU上，它们内部把fixed和half当成同精度来对待。 尽管由上面的不同，但一个基本的建议是，尽可能使用精度较低的类型，是因为这可以优化Shader的性能，这一点在移动平台上尤为重要。从它们大体的值域范围来看，我们可以使用fixed类型来存储颜色和单位矢量，如果要存储更大范围的数据可以选择half类型，最差的情况下再选择float。如果我们的目标平台是移动平台，一定要确保在真实的手机上测试我们的Shader，这一点非常重要。 ### 4.2 避免不必要的计算 如果我们毫不节制的在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来消除这些错误。下表给出了Unity目前支持的一些
Shader Target。
Unity支持的Shader Target
指令 | 描述 |
#pragma target 2.0 | 默认的Shader Target等级。相当于Direct3D 9上的Shader Model1.0，不支持对顶点纹理的采样，不支持显示的LOD纹理采样等 |
#pragma target 3.0 | 相当于Direct3D上的Shader Model 3.0，支持对顶点纹理的采样等 |
#pragma target4.0 | 相当于Direct3D10上的Shader Model4.0，支持几何着色器等 |
#pragma target 5.0 | 相当于Direct3D 11上的Shader Model5.0 |
