使用 Streamline 针对 Mali GPU 优化应用程序针对基于 Mali? Midgard 和 Utgard 的 GPU 对应用程序进行优化时，ARM? DS-5 Streamline 将成为工作流中很有用的一部分。您可借助 Streamline 查看进行了哪些 API 调用、API 函数调用了多少次以及在 API 函数上花费了多少时间。 本指南精选了使用 Streamline 性能分析器可发现的常见问题和瓶颈。这些信息可帮助您对代码或纹理资源进行诊断，找到可改进之处。要获取完整的 Mali GPU 优化指南，请阅读 Mali 开发人员 OpenGL ES 应用程序优化指南。 此外还提供了一些经过实践检验的衡量方法，它们能让您了解 Streamline 中的计数器值是否有可能会在您的应用程序中引发性能问题。 但是，您也需要了解 GPU 本身的规格和限制，这很重要，只有这样您才能开始创建您自己的测试和规则。 何时需要使用 Streamline？Streamline 性能分析器能提供完整的系统性能情况，对于找到问题所在 非常有帮助。但要找出导致该问题的原因，您需要使用 Mali 图形调试器（在 malideveloper. 处提供）等工具。 设置 StreamlineStreamline 需要您对您的设备具有 root 用户访问权限，以便安装 gator（Streamline 用来收集系统信息的守护程序）和插入内核模块。对于 Android 设备，您还需要 Android SDK 和 NDK。 我们精选了以下有关在特定设备上设置 Streamline 的博客和演示： Midgard 优化本节针对基于高端 Midgard 架构的图形处理器进行优化。此范围中的处理器是 Mali-T604、Mali-T622、Mali-T624、Mali-T628、Mali-T678 和 Mali-T760 以及中端 Mali-T720。 片段限制 GPU如果片段着色器产生了主要的 GPU 工作负载，我们就可以说应用程序受片段限制。这是造成移动游戏性能低下的常见原因。造成这种现象的常见原因有以下几个： 造成片段限制应用程序的可能原因过度绘制从前到后绘制对象的概念应为游戏开发人员所熟知，但是在移动游戏中还是值得重申其重要性。在屏幕上将每个像素绘制多次就是过度绘制，产生主要 GPU 工作负载的片段着色器便是一例。在场景中过多使用透明度也会造成片段限制应用程序。 分辨率是否太高？智能手机分辨率非常高，在很多情况下超过了控制台，上一代产品中通常采用 720p。将此分辨率与 Google Nexus 10 等设备对比，后者具有 2500 的原生分辨率。如果您尝试以原生分辨率运行应用程序，则可能导致性能显著下降。 纹理带宽是否过高？由于纹理要使用大量的内存带宽，片段着色器可能无法获得足够的数据，因而会停顿。 着色器中特效或周期过多每一条光线和每一个特效都会增加着色器所占用的周期数。 我们还是来说说 Google Nexus 10 的例子： Nexus 10 原生分辨率 = 2560 x 1600 = 4,096,000 像素 四核 GPU 533MHz ≈ 520 个周期/像素 对应于着色器中 30 FPS = 17 周期 在 Streamline 中测试片段限制应用程序选择 JS0 （作业槽 0）活动作为计数器并运行一轮 Streamline 捕获。选择一个 1 秒窗口（使用蓝色滑块）并将它放在可要关注的中心位置。N.B.最好避开 Streamline 捕获的第一秒，以获得稳定的结果。
使用捕获窗口右侧的数字（在此例中为 447,709,960）可以计算片段百分比： 片段百分比 = (JS0 活动 / GPU 频率) * 100 我们可以看出，在我们的例子中，片段百分比为 84%。如果片段着色器占用了如此大比例的 GPU 活动，则这很可能是造成任何瓶颈的主要原因，因此我们应该从此处着手调查如何提高性能。 一般来说，如果片段着色器使用超过 90% 的 GPU，则几乎可以肯定，这就是限制应用程序性能的主要问题。 使用已启动的片段线程数计数器，我们可以测试过度绘制（这次仍然使用 1 秒窗口）：
过度绘制 = (已启动的片段线程数 * 内核数) / (分辨率 * FPS) 过度绘制值大于 3 时，也同样表明片段着色器占用了过多 GPU 时间。 顶点限制 GPU您的应用程序在 Mali-T600 系列中产生顶点限制的可能性比在中端 Mali-400 系列中小得多，因为这个系列提供了多个顶点着色器。但是，如以下所解释，它有时也可能是造成性能下降的原因。 造成顶点限制应用程序的可能原因几何图形中有过多顶点游戏工作室的艺术家在开发游戏时通常习惯于认为游戏将运行于 PC 图形卡上。他们往往使用过多顶点，这就会导致顶点着色器产生主要的 GPU 工作负载。这个问题可以通过一些技术（如严格控制预算和限制顶点数量，详细级别 (LOD) 切换和筛选）来解决。 顶点着色器计算负载过于繁重顶点数量和着色器周期之间存在一定的关联。假设对执行顶点渲染的周期数有限制，则您需要使用上述技术来减少此数量。 在 Streamline 中测试顶点限制应用程序选择 JS1 （作业槽 1）计数器并开始运行新一轮 Streamline 捕获。JS1 是代表顶点作业的硬件计数器。使用蓝色滑块选择一个 1 秒采样窗口：
顶点百分比 = (JS1 活动 / 频率) * 100 在此示例中，我们的顶点百分比计算结果是 13%，这个数据相当低，说明我们不存在顶点限制。 测量每条指令的加载/存储周期（Mali 加载/存储流水线：LS 指令）可表明您是否使用了过多顶点：
加载存储 CPI = 完全流水线指令执行数 / 已完成加载存储指令数 在我们的示例中，此值是 2.02。超过 2 的任何值都被视为存在值得调查的问题。 带宽限制 GPU简单地说，如果应用程序尝试使用的带宽超过可用带宽，则说明应用程序受到带宽限制。确定应用程序是否受带宽限制可能很困难，因为这种情况会影响应用程序和图形流水线的各个方面。 造成带宽限制应用程序的可能原因通常，智能手机或平板电脑 GPU 具备 5 GBps 左右的带宽。对于习惯桌面 PC 游戏（通常带宽超过 100 GBps）的开发人员来说，这是一个主要的障碍。 尽管移动设备上的屏幕大小和分辨率在不断增加，但仍然可以使用主流的纹理压缩格式（如 ASTC 或 ETC）来大大减少所需带宽。ARM 提供了 Mali 纹理压缩工具来帮助实现此目标。 测试带宽限制应用程序要查看带宽利用率，您需要了解 L2 高速缓存中的外部总线读取频率和外部总线写入频率。此外，您还需要知道总线的宽度（多少个字节）。我们再来看看 1 秒窗口：
带宽（字节数） = (外部总线读取频率 + 外部总线写入频率) * 总线宽度 我们的示例（使用 16 字节的总线宽度）提供了 967 MBps 的带宽。 CPU 限制造成 CPU 限制应用程序的可能原因在有些情况下，优化您的图形并不会提高性能，因为造成低帧率的源头是 CPU。这通常是由于未能利用大多数现代智能手机和平板电脑所拥有的多核优势导致的。如果一个应用程序未使用多线程，您可能会看到（例如在四核 CPU 上）“25%”的 CPU 利用率，这通常意味着有一个内核的使用率达到了 100%。 这可能看起来是常见意义上的优化，但是不支持多线程已经成为在一些知名桌面 PC 游戏中导致性能低下的原因，所以对于移动游戏来说，还是很值得检查一下的。 由于 Mali GPU 是一个延后的架构，它有助于减少您所发出的绘制调用，并且能够合并绘制调用。您还可以利用 OpenCL 1.1 支持将 CPU 工作负载分流到 GPU 上。 测试 CPU 限制性能此测试很简单：只需要查看 CPU 活动即可。请确保您展开了图表使之显示所有核心，以便测试是否缺乏前面所述的对多线程的支持。 Streamline 中有一个功能可帮助定位所占 CPU 活动份额，那就是“每个应用程序”活动。在活动栏中单击一个线程或一个应用程序（如下面的屏幕截图所示），Streamline 会筛选活动，以显示有多少 CPU 工作负载是该应用程序造成的。
Utgard 优化本节针对基于中端 Utgard 架构的图形处理器进行优化。这个范围内的处理器是 Mali-300、Mali-400 MP 和 Mali-450 MP。 在一轮捕获过程中，可以对 Mali-400 GPU 使用很多个计数器。但是，对于每个“单元”您最多只能使用 2 个硬件计数器，其中的“单元”代表不同的组件，可以是 L2 高速缓存。 片段限制 GPU片段限制应用程序的可能原因和测试与更强大的 Mali-T600 系列 GPU 的情况类似，您的应用程序可能由于多种原因受到片段限制。 过大且未压缩的纹理片段处理器的读取负载很大：总的总线读取数和片段处理器：纹理描述符读取数计数器表明您的应用程序是否受到纹理限制。 要检查是否存在过大的纹理，请测量 Mali GPU 片段处理器 X：纹理高速缓存命中计数和 Mali GPU 片段处理器 X：纹理高速缓存未命中计数这两个计数器，然后计算其比率。常见的命中与未命中比率为 10:1，如果比率更高，说明纹理位深过高，或纹理总体而言过大。 使用 Mali GPU 片段处理器 X：压缩纹理高速缓存命中计数和 Mali GPU 片段处理器 X：压缩纹理高速缓存未命中计数这两个计数器可进行一个类似的测试，可帮助您确定是否使用了未压缩的纹理。 过度绘制正如在 Midgard 架构中所述的情况一样，过度绘制可能是造成片段限制应用程序的一个因素。 要测试是否存在过度绘制因素，请测量 Mali GPU 片段处理器 X：片段传递的 z/stensil 计数计数器： 过度绘制因子 = 片段经过的 z/stensil 数 / 一帧中的像素数 典型的结果在 2.5 左右。正如在 Midgard 优化中一样，在不包含大量透明度的场景中，此值大于 3 时表明性能不佳。按深度对场景对象进行排序，并从前到后绘制不透明对象，这样将有助于改善这种情况。 片段着色器问题若要合理判断片段着色器时间是否过长，需要依据 GPU 配置而定。您需要知道着色器核心的数量及其时钟速度，才能计算出每个片段可用的周期数。 每个片段完成的指令数 = 已完成的指令计数 / 片段经过的 z/stensil 计数 片段着色器长度与复杂度程序高速缓存未命中计数百分比 = (程序高速缓存未命中计数 / 程序高速缓存命中计数) * 100 此值通常在 0.01% 左右。如果图形对应的此值很高，可能表示片段着色器过长。如果图形的程序高速缓存命中计数很低，可能表示片段着色器过于复杂。 分支过多在 Mali GPU 中，分支不太可能成为问题，因为分支的计算成本很低。但是，您也可以使用 Mali GPU 片段处理器 X：流水线气泡周期计数计数器来测试分支，如果值较高，则表明存在过多分支。 顶点限制 GPU虽然顶点处理不常成为应用程序中的瓶颈，但不习惯移动 GPU 的开发人员还是有可能使用过多三角形。 顶点限制应用程序的可能原因和测试顶点着色器长度与复杂度如果顶点着色器过于复杂，则可通过将某些工作负载分给片段着色器，或者进行算数优化来简化着色器。同样，如果着色器过长，请尝试将其缩短。使用 Mali GPU 顶点处理器：活动周期数、Mali GPU 顶点处理器：活动周期数、顶点着色器和 Mali GPU 顶点处理器：顶点加载器高速缓存未命中数计数器来测试这些问题。 如果活动周期数、顶点着色器与活动周期数的值相比较低，且顶点加载器高速缓存未命中数很高，则着色器可能过长。 如果活动周期数、顶点着色器接近于活动周期数的值，且顶点加载器高速缓存未命中数很低，则着色器可能过于复杂。 顶点过多测量 Mali GPU 顶点处理器：已处理的顶点数，并查看图表是不是一直很高。如果是，请检查应用程序是否使用了过多三角形。这可通过测量 Mali GPU 顶点处理器：活动周期数、PLBU 几何图形处理计数器来测试多边形列表生成器单元 (PLBU) 时间。图表持续走高也意味着三角形过多。此问题可通过降低对象复杂性、在一个场景中使用较少对象或剔除三角形来解决。剔除三角形之后，您可以通过测量 Mali GPU 顶点处理器：剔除的基元数计数器来测试 GPU 所剔除的量。 顶点缓冲区对象 (VBO) 利用率不高使用 VBO 可减少每个帧中必须传输的数据量，从而提高应用程序的性能。通过缓冲区分析：VBO 上传时间 (ms) 计数器来检查您是否充分利用了 VBO。 如果 VBO 使用得当，则图表会在大量帧后攀上高峰，然后在一个或多个帧中回落到零（或接近于零）。如果图表持续走低，则可能意味着您没有使用 VBO。 带宽限制带宽限制的应用程序会对各个方面造成影响，因此要确定根本原因可能很困难。 带宽限制的应用程序的可能原因和测试纹理带宽过大纹理所使用的内存带宽是最多的，而纹理使用过多带宽所带来的负面效应就是纹理高速缓存使用率很高。这通常都是由于过大、未压缩或未使用 mipmap 的纹理导致的。 通过测量 Mali GPU 片段处理器 X：纹理高速缓存命中计数和 Mali GPU 片段处理器 X：纹理高速缓存未命中计数并计算比率来对此进行测试。比率通常为 10:1，如果小于此值则表示情况变糟。 位块传输位块传输可能造成使用过多带宽，如果您在传输高分辨率的帧缓冲区则更是如此。 使用 EGL 计数器：位块传输时间软件计数器来进行测量。 其他因素片段处理和顶点处理也可导致应用程序带宽受限。三线性过滤、复杂片段着色器、三角形过多（未使用剔除）、复杂顶点着色器或读取非相邻的数据也都可能是造成带宽受限的因素。请参阅有关如何处理片段和顶点着色器的部分了解相关测试。 要了解您的应用程序的性能情况以及最大可用带宽，请将以下计数器相加： Mali GPU 顶点处理器：已读取字数、系统总线、Mali GPU 顶点处理器：已写入字数、系统总线、Mali GPU 片段处理器 X：总的总线读取数和 Mali GPU 片段处理器 X：总的总线写入数，确保将所有可用片段处理器的测量数据都计算进来。最后，将计算出的总和乘以 8 即可获得字节数值。 如果您不知道系统的最大可用带宽，运行一个会使用最多带宽的测试应用程序将有助于您确定此值。 更多参考读物Mali 博客由于 Streamline 在我们自己的开发流程中经常使用，您可找到大量的 ARM Connected Community 博客，通过这些博客可深入了解 Mali 驱动程序开发。 宏观尺度流水线我们 Mali OpenGL ES 驱动程序团队的首席性能工程师 Pete Harris 汇集了一个 指南，介绍如何调试与宏观尺度流水线相关的问题。 Cocos2d-x 引擎优化了解如何使用 Streamline 来优化主流的 Cocos2d-x 游戏引擎。 Epic Citadel 性能分析要获得比 1080p 更大的分辨率，对游戏和应用程序进行优化比以往任何时候都更加重要。Mali GPU 工具产品经理 Lorenzo Dal Col 编写了 Epic Citadel 分析演示指南，其中就如何确定 GPU 使用率较高的方面包含了大量切实的建议和简单的计算。 此处提供了有关如何将 Streamline 用于 Google Nexus 10（在 Epic Citadel 示例中使用）的设置信息。 |
|
|
来自： 老匹夫 > 《Graphics》
