前面说了对我这一年多的工作进行一个总结,由于工作比较紧,加上本人比较懒,一直没能抽出时间来写,最近稍微闲下来了。先写一篇GPU优化的,后续的文章希望能慢慢补齐。这些基本都是我个人优化的实际经验,也参考了一些文章,我都放在后面引用 部分了,感兴趣的可以深入研究。个人理解可能有问题,如有不正确的还请指正,下面进入正题。
由于图形引擎的复杂性,瓶颈可能发生在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有瓶颈了,这时我们可以借助一些工具如Perfhud、Intel GPA、NSight(替代Perfhud的工具)或其它方法来找到程序的瓶颈所在,然后根据这些分析结果来有目的的优化程序。
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指令。
1 float4 vPos = float4(0,0,0,0); 2 3 for (int i = 0; i < 4; ++i) 4 5 vPos += float4 (mul (vMat[i], vInputPos), 1.0); 6 7 ---> 8 9 float4 vPos = float4(0,0,0,1); 10 11 for (int i = 0; i < 4; ++i) 12 13 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.