由于图形引擎的复杂性，瓶颈可能发生在CPU、GPU、，也可能发生在CPU与GPU的传输数据与交互之中。这里我们只假设瓶颈在GPU上，讨论GPU的优化方法。
Premature optimization is the root of all evil. -- Donald Knuth 这告诉我们过早优化程序是不可取的，我觉得有两方面的意思：
1、在没有找到高效的算法前就开始优化。
2、在没有找到真正的瓶颈关就开始优化。
正确的流程大概是这样的
1、使功能能工作，程序能跑起来。
2、功能正确的工作。
3、让整个程序能工作。
4、让整个程序能正确工作。
5、使用这个程序并找到性能瓶颈。
6、使用性能分析工具找到瓶颈所在。
7、使程序高效正确的运行。[1]
还有一个原则就是80~20原则，即只有百分之二十的代码是常用的，所以要集中优化这些代码，而不是一些很少执行的代码上花些时间。
既然直接谈GPU优化，那我们就假设上面流程中的前五条已经满足，我们假定GPU有瓶颈了，这时我们可以借助一些工具或其它方法来找到程序的瓶颈所在，然后根据这些分析结果来有目的的优化程序。
GPU可能存在的瓶颈主要在以下几个部分：
1、纹理传输带宽限制 （显存到高速缓冲区）
2、光栅操作完成后帧传输带宽限制（高速缓冲区到显存）
3、顶点着色处理能力限制（VS）
4、像素着色处理能力限制（PS）在新的硬件中使用统一着色处理单元时，可以动态调整VS PS使用的数量。
5、光栅化限制。
6、显卡显存过小。
7、算法本身不够高效。
8、Shader指令使用不合理。
具体查找瓶颈的方法如下：[2]
1、如果改变纹理尺寸，帧率有明显变化，则瓶颈可能在纹理传输带宽限制或纹理AGP传输能力限制。若改变纹理过滤方式帧率提高了，则可能是纹理传输带宽限制。此时可通过减小纹理分辨率或纹理过滤方式来解决。
2、若改变窗口大小，帧率有明显变化，则可能是由于光栅化或像素着色Shader限制，或者帧缓冲区带宽限制。此时减少PS指定数量，若FPS有明显变化，则说明是PS是瓶颈。否则此时改变后台缓冲区位宽，若帧率有明显变化则说明是帧缓冲区带宽限制，否则光栅化是瓶颈。
3、若改变颜色位宽帧率有明显变化，则说明瓶颈在帧缓冲区，此时可以通过改变帧缓冲区带宽来提高帧率，这在帧缓冲区带宽小的低端显卡止效果很明显。
4、减少VS指令数量，如果帧率有明显变化，则说明瓶颈在VS上，这种情况一般不会出现，如果在VS中访问纹理会比较慢,瓶颈可能会出现（Shader Model 3.0）。
5、如果减少顶点数量，帧率有明显提升，则说明瓶颈可能在顶点过多，或顶点AGP传输限制，此时可能通过模型LOD来解决问题。
6、使用Perfhud等GPU分析工具来查找瓶颈，尤其是GPA可以实时修改查看效果，这样就可以比较高效的优化Shader。
7、如果本身算法有问题，则可以找更高效的方法来实现同样的效率，或者有时为了效率也是可以牺牲一些效果的，也可以做Shader的LOD，不同配置下采用不同的Shader，这样在低端和高端显卡上都会有一个不错的帧率。
优化方法：
1、纹理带宽限制。
（1）减少不必要的大纹理。
（2）可以动态修改纹理分辨率，去掉纹理前面几级Mip map。
（3）尽量使用DXT格式的纹理。
（4）避免使用非二次方的纹理。
（5）如果不需要写颜色，那就把颜色写关闭。（Pre-z 阴影贴图等。）
2、帧缓冲区带宽限制。
（1）减少颜色位宽，如使用16位颜色。
（2）减小后台缓冲区和Render Target大小。
（3）对于特效比较多的情况，可以先渲染到一张小的纹理上去然后再Up-Sampling到主Render Target上。
3、AGP传输瓶颈
（1）顶点尽量使用索引条带或索引列表。
（2）对顶点进行排序，这样可以减少顶点重复计算的次数（对结果进行Cache），使用NVTriStrip这个工作。
（3）顶点大小应该是32(bit)的整数倍。
（4）使用模型LOD。
4、VS处理能力限制，一般不会成为瓶颈
（1）使用模型LOD，减少顶点数量。
（2）尽量减少VS指令的数量。
（3）控制顶点纹理的使用。
（4）能在CPU计算的在CPU计算完成后再传给VS。
（5）方法3 中的优化也合适。
（6）尽量使用低版本的Profile。
5、PS处理能力限制。
（1）尽量减少指令的长度。
（2）尽量使用低版本的Profile。（如PS_2_a）等。
（3）尽量使用低精度half进行计算。
（4）利用硬件的特性来减少开销，比如如果要对纹理进行降采样，可以利用GPU的双线性来插值来实现，这样可以明显减少纹理访问的次数。
（5）能在CPU计算的在CPU计算完成后再传给PS。
（6）做Pre-Z。
（7）做Shader LOD，可以在不同配置下切换。
6、算法本身不够高效
（1）尽量寻找更高效的算法代替，这样比一条条指令压榨要提升太多效率。
7、Shader指令不合理，对GPU工作不是特别了解，导致写出低效的代码。[]
（1）使用代数化简指令来减少不必要的计算。
（2）使用能工作的最小Profile版本。
（3）尽量使用half。
（4）尽量不要写太通用的函数，这样可能会产生一些无用的指令。
（5）不要乱用normalize，比如在PS中需要normalize，那么在VS中就没有必要使用。
（6）normalize过的向量不需要计算长度（就是1）。
（7）不要把向量放到多个Interpolator里面。
（8）能在CPU计算的就放到CPU计算。
（9）如果一个参数永远不变，则没必要从CPU传进来。
（10）如果是结果是线性的，则这些计算可以放到VS计算，而没必要在PS计算。
（11）使用下标小的interpolants。比如首先使用TEXCOORD0,再使用TEXCOORD1等。
（12）使用纹理查找来取代复杂的函数。（目前是至少是6条算数指令：1条取纹理的关系）
（13）Pre-z，尽量避免Pre-Z失效。具体参见NVIDIA编程指南。
（14） 动态分支要谨慎使用，只有在大多数情况都走同一个分支时使用才有比较好的效果。
（15）产生阴影时可以使用tex2DProj来利用硬件特性加速。
（16）了解GPU的汇编指令，写出正确的代码。
（17）纹理指令和算术指令交叉使用。
GPU的指令：[]
1、mad 是一条指令 (x + 1) * 0.5 = x * 0.5 + 0.5 前面是一条add+mul指定，后面是一条mad指令，编译器并不会为我们优化。
2、括号不要乱加，比如 x + y * 0.5 + z * 0.2 是两条指令 mad-->mad而x + （y* 0.5 + z * 0.2)是mul-->mad-->add三条指令。
3、代数化简 (x + c) * (x-c) 三条指令 ---> x * x + (-c * c)两条指令
4、减少不必要的mov指令。
float4 vPos = float4(0,0,0,0); for (int i = 0; i < 4; ++i) vPos += float4 (mul (vMat[i], vInputPos), 1.0); ---> float4 vPos = float4(0,0,0,1); for (int i = 0; i < 4; ++i) vPos .xyz+= mul (vMat[i], vInputPos);
这样减少了3条mov指令。
5、a/b 是用a * rcp(b)实现。D3D也可能使用div指定，但显式使用cp可能会产生更好的代码。(x + a) / x --> 1.0 + a * rcp(x)
6、正确使用[branch] [flatten] [loop] [unroll]。[branch]在分支友好的情况下效率才会比较高。[unroll]在指令限制未到使用可提高效率。
7、线性的运算放到VS里面去算，插值到PS即可。
8、更多优化方法请参考引用[4]。
总结：
游戏引擎是一个复杂的系统，瓶颈在不同机器上出现可能不一样，可能在CPU也可能在GPU，GPU上的瓶颈又可能出现在不同的环节。工欲善其事，必先利其器！我们要借助工具或上面提到的方法来找到程序的瓶颈，对症下药，不要盲目去优化，找到那20%的代码，首先是在算法上找优化的方法，如果确定算法是好的了，那才要开始指令级别的优化，否则是徒劳的。然后根据上面的方法基本上可以解决大多数的性能问题，当然我们还可以把多个效果结合到一起处理，因为可能有些中间结果是共用的，这样又可以省去一些额外的开销。尽最大限度的优化，做到在不同配置机器上都能流畅运行，还要在高端机器上有次世代的画面效果。
引用：
[1] http://c2.com/cgi/wiki?PrematureOptimization
[2] http://www.cnblogs.com/lancidie/archive/2011/03/29/1998830.html
[3] NVIDIA GPU Programming Guide version 2.5.0
[4] Low-level thinking in high-level shading languages
来源：博客园 http://www.cnblogs.com/ghl_carmack/
作者： 风恋残雪
原文链接：http://www.cnblogs.com/ghl_carmack/p/4107042.html
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文链接，否则保留追究法律责任的权利。
