Mail GPU Counter模块自上线后受到了广泛好评，已经有不少项目通过查看GPU着色和带宽信息，定位到GPU的高压场景和性能瓶颈。基于GPU优化越来越强烈的需求，UWA在新版本测评报告中新增的了几项重要参数，以便开发者对项目的GPU压力进行更全面的认识和高效的定位。
即日起，使用UWA SDK 2.4.3版本进行GOT Online Overview模式测试，便可在Mail GPU Counter模块下查看项目运行时的GPU图元处理和GPU Shader Cycles情况。
一、GPU图元处理
渲染面是产生GPU压力的重要因素之一，我们可以通过 Overview 模式里的 Triangle 指标来查看和分析哪些画面的渲染面较多。
渲染面过多，一方面可能是模型过于复杂，一般可以通过 LOD、HLOD 等常用技术来简化远距离的模型，在不影响画质的情况下显著降低渲染面；另一方面，可能是地形、大建筑物等大面积模型没有进行适当的拆分，导致进入视域体的面片可能不多，但提交GPU的渲染面依然很多。
对于第二种情况，我们可以通过新功能“GPU图元”来进行初步的判断。
总图元数：提交到GPU端的图元总数，该数值基本等同于引擎端统计的渲染面片总数。
可见图元数：在GPU端通过各种裁剪之后，留下的参与渲染的三角面。
可见图元不包括：因为在视域体外而被裁剪的三角面，因为朝向而被裁剪的三角面。因此，在3D场景中，比较理想的情况下，可见图元的数量应该接近或高于 50%（对于大部分模型，有一半三角面会因为朝向被裁剪）。如果某些角度下，可见图元的比例非常低，则很可能存在上文提到的第二种情况，从而可以针对性地检查和优化场景中，这个角度下，被提交到GPU的大面积模型。
GPU图元处理数量过多会对设备的带宽和能耗造成较大的影响，应尽量在程序端完成剔除，并减小送往GPU的图元数。此外，总图元数数值基本等同于引擎端统计的渲染面片总数，开发者也可以通过这一数值侧面评估处理的渲染面片数是否合理。
二、GPU Shader Cycles
Shader复杂度过高是GPU压力较大的主要原因之一，后处理、大地形、水体、人物建模、还有粒子特效都容易存在Shader复杂度过高的情况。
为了帮助大家排查Shader复杂度过高的问题，在UWA的报告中针对这部分参数做了支持和细化。Shader Cycles数表示GPU在Shader处理上占用的Cycles数，展示测试过程中的Shader复杂度情况。
除了总Shader Cycles数外，GPU Shader Cycles还列出了Shader Arithmetic Cycles、Shader Interpolator Cycles、Shader LoadStore Cycles、Shader Texture Cycles四项数据。用户可以快速定位到高Shader复杂度场景下，数学计算、顶点到像素插值、寄存器读取、纹理处理相关Cycles数中，哪一个单元是Shader复杂度过高的瓶颈，以便针对性地对项目的Shader复杂度情况进行排查和优化。
三、其他参数指标细化
除了Mail GPU Counter模块外，这次更新中，UWA还对一些数据项进行了细化。
1、增加温度显示
Overview模式硬件信息下的温度模块新增CPU温度、GPU温度和电池温度三项数据，以助于定位设备发热原因。
2、Timeline支持显示线程名，如主线程、渲染线程等。
3、Resource模式新增AssetBundle驻留信息
在我们排查内存问题的时候，会发现Unity内存总值偏高，但主流资源和Mono占用并不高，这时候就需要留意是否可能其他内存造成的，例如AssetBundle的驻留内存。
在GOT Online Resource模式下，我们可以看到项目运行过程中的资源驻留情况。当驻留内存比较大时，就可以通过优化缓存策略的方式减少驻留数量，从而达到降低Unity内存的效果。
以上就是这次的新功能介绍了，希望这次的支持可以帮助研发团队在优化过程中更高效精准地定位项目GPU压力的痛点，事半功倍。您可以注册并激活UWA账号即可获得UWA SaaS服务的免费试用权限，快来体验吧～
