Linux下怎么查看GPU使用率
[问题点数：40分，结帖人zaviichen]
本版专家分：0
结帖率 100%
CSDN今日推荐
本版专家分：23489
2014年9月 CUDA大版内专家分月排行榜第一2010年12月 CUDA大版内专家分月排行榜第一2010年11月 CUDA大版内专家分月排行榜第一2010年10月 CUDA大版内专家分月排行榜第一2010年9月 CUDA大版内专家分月排行榜第一2010年8月 CUDA大版内专家分月排行榜第一2010年7月 CUDA大版内专家分月排行榜第一2010年6月 CUDA大版内专家分月排行榜第一2010年5月 CUDA大版内专家分月排行榜第一2010年4月 CUDA大版内专家分月排行榜第一2010年3月 CUDA大版内专家分月排行榜第一2010年2月 CUDA大版内专家分月排行榜第一2010年1月 CUDA大版内专家分月排行榜第一2009年12月 CUDA大版内专家分月排行榜第一2009年11月 CUDA大版内专家分月排行榜第一2009年10月 CUDA大版内专家分月排行榜第一2009年9月 CUDA大版内专家分月排行榜第一2009年8月 CUDA大版内专家分月排行榜第一2009年7月 CUDA大版内专家分月排行榜第一2009年6月 CUDA大版内专家分月排行榜第一2009年5月 CUDA大版内专家分月排行榜第一2009年4月 CUDA大版内专家分月排行榜第一
本版专家分：0
结帖率 100%
本版专家分：23489
2014年9月 CUDA大版内专家分月排行榜第一2010年12月 CUDA大版内专家分月排行榜第一2010年11月 CUDA大版内专家分月排行榜第一2010年10月 CUDA大版内专家分月排行榜第一2010年9月 CUDA大版内专家分月排行榜第一2010年8月 CUDA大版内专家分月排行榜第一2010年7月 CUDA大版内专家分月排行榜第一2010年6月 CUDA大版内专家分月排行榜第一2010年5月 CUDA大版内专家分月排行榜第一2010年4月 CUDA大版内专家分月排行榜第一2010年3月 CUDA大版内专家分月排行榜第一2010年2月 CUDA大版内专家分月排行榜第一2010年1月 CUDA大版内专家分月排行榜第一2009年12月 CUDA大版内专家分月排行榜第一2009年11月 CUDA大版内专家分月排行榜第一2009年10月 CUDA大版内专家分月排行榜第一2009年9月 CUDA大版内专家分月排行榜第一2009年8月 CUDA大版内专家分月排行榜第一2009年7月 CUDA大版内专家分月排行榜第一2009年6月 CUDA大版内专家分月排行榜第一2009年5月 CUDA大版内专家分月排行榜第一2009年4月 CUDA大版内专家分月排行榜第一
本版专家分：0
本版专家分：0
匿名用户不能发表回复！|
CSDN今日推荐技术成就梦想...
Mali GPU性能调优方法
http://blog.csdn.net/MyArrow/article/details/
1. 使用DS-5 Streamline定位瓶颈
DS-5 Streamline要求GPU驱动启用性能测试，在Mali GPU驱动中激活性能测试对性能影响微不足道。
1.1 DS-5 Streamline简介
可使用DS-5 Streamline从CPU和Mali GPU中实时收集性能计数器，然后以图形方式显示这些计数器，其主要功能如下：
o 收集计数器--从CPU和Mali GPU中
o 保存收集到的计数器数据以供回放
o 查看显示GPU活动、GPU活动和Framebuffer变化的时间线
o 以图形或表格的方式显示指定的性能计数器的值
o 观察计数器值如何变化
o 评估每一帧的性能
o 查看处理器活动的图表
o 查看堆栈跟踪
o 查看应用程序分析(Profiling)
1.2 DS-5 Streamline分析图
查看下面三个图：
o GPU Vertex activity.
o GPU Fragment activity.
o &Application processor& Instruction: Executed.
o 寻找具有最高和最长图形的处理器，它的使用最多；
o 如果很难找到占用太多时间的单个处理器，则问题可能在于带宽过度使用或图形管理被阻塞；
o 如果找到占用太多时间的处理器，则采取更多测量以隔离此问题；
o 如果所有图形都很忙，则应用程序充分利用了Mali GPU。
2. 通过比较定位问题区域
可以通过以下比较来定位问题区域：
o 修改分辨率
修改分辨率，然后测试帧率变化：
如果分辨率增加，而FPS下降(即分辨率增加为原来的2倍，则FPS下降为原来的1/2)，则FP或带宽是性能的瓶颈；
如果FPS不随着分辨率的变化而变化，则CPU或VP是性能的瓶颈。
o 改变纹理大小
逐步减小纹理的大小，如果帧率增加，且纹理Cache命中率太低：则表明纹理太大，带宽是性能的瓶颈。
o 减少Shader的长度
如果Shader太长，它将降低帧率，深度缩短Shader并进行测试。
注：如果分辨率或FPS加倍，则FP可得到的cycles减半。
o 使用空的Fragment Shder
一个null shader什么都不做。如果使用null shader，性能快速上升，则表明Fragment Shader或带宽是性能瓶颈。
o 改变顶点数
如果减少顶点数，则FPS上升，则表明顶点数过多或带宽是性能瓶颈。
o 改变纹理位深度
当减少纹理深度时，如果FPS上升，则表明内存带宽是性能的瓶颈。
o 改变Drawing Surface位深度
当降低surface位深度，如果FPS上升，则表明内存带宽是性能的瓶颈。
o 减少draw调用
优化应用程序以减少draw调用，观察性能变化。
o 减少状态变化
优化应用程序以减少状态变化，观察性能变化。
3. 隔离具体的问题区域
当定位到问题区域之后，下一步就是找到瓶颈的具体原因。其方法如下：
3.1 应用处理器(CPU)限制了应用性能
o 应用逻辑复杂导致性能问题
如果删除draw调用和eglSwapBuffers之后，性能变化很少或没有变化，则表明瓶颈在应用逻辑，可通过OProfile来进行分析，它可区分用户态和Kernel态瓶颈问题。
o 驱动超负荷导致性能问题
如果低分辨率输出表明瓶颈在于CPU，且应用逻辑没有问题，则问题可能在于调用OpenGL ES API的方式：
1) 太多的draw调用
2) 太多的状态变化
3) 管道被阻塞
o 应用程序逻辑与驱动超负荷共同导致了性能问题
可通过DS-5或OProfile分析问题的根源所在。
3.2 顶点处理器(VP)限制了应用性能
如果顶点处理器限制了应用性能，问题可能在于以下方面：
o 太多的顶点
o Vertex Shader太长
o Vertex SHader太复杂
o 三角形设置时间过长
o 多边形列生成器单元时间过长(PLBU: Polygon List Builder Unit)
3.3 像素处理器(FP)限制了应用性能
如果像素处理器(FP)限制了应用性能，则问题可能在以下方面
1) 瓶颈：像素处理器(Fragment Processing)
o 过多的draw调用
o 需要读取太多的纹理
o 纹理cache miss过高
2) 瓶颈：像素处理程序(Fragment Shding)
o Shader太长
o Shader太复杂
o Shader太长且太慢
o Shader分支太多
3.4 内存带宽限制了应用性能
内存带宽影响一切且很难直接测量。如果一个处理器限制了性能，其它优化没有任何效果，则可能量内存带宽导致了此问题，其原因在于：
o 纹理过多或过大
o 太多的draw调用
4. 优化工作总流程
总的优化工作流程如下图所示：
首先对应用进行性能测试，以决定瓶颈所在的区域(CPU、VP、FP或内存带宽)。
o 必须在具有Mali GPU的真实的硬件上测试
o 使用DS-5 Streamline，并观察以下三个值：
1) GPU Vertex activity
2) GPU Fragment activity
3) &Application processor: CPU& Instruction: Executed
比较以上三个，找到占用时间最长且最高的图。
o 判定问题所在的区域
1) 如果能找到占用时间最长且最高的图，则问题可能出在这里
2) 如果不能看出某个处理器特别忙，但可以看到不同处理器间存在间隙，则可能管道被API阻塞了，问题在于CPU
3) 如果以上两种情况都不存在，则问题可能在于带宽问题
5. 应用处理器(CPU)优化工作流程
总的CPU优化工作流程如下图所示：
5.1 Applicatoin bound
如果应用时间太高(DS-5 Streamline中查看对应的应用进程)，应用程序可能导致性能问题，因为它不能足够快地产生命令。
5.2 API bound
如果驱动时间太高(DS-5 Streanline中查看Kernel进程)，驱动可能导致性能问题，因为它不能产生足够的命令。典型的原因是：没有以优化的方式调用OpenGL ES API函数，应用调用了太多的OpenGL ES API函数。
5.3 检查是否太多的draw调用?
通常上千的draw调用将导致性能严重下降，一般每帧在保持在1000次以内的draw调用较佳。使用DS-5 Streamline中的以下counter查看此值：
1) glDrawElements Statistics: Calls to glDrawElements
2) glDrawArrays Statistics: Calls to glDrawArrays
5.4 检查是否使用了VBO?
如何不使用VBO，每一帧都必须传输数据，这将限制应用的性能。在Utgard架构的Mali GPU中，可通过以下counter测量其使用情况：
1) BufferProfiling: VBO Upload Time (ms)
如果以上counter在出现尖峰的几帧之后，变为了0或值很小有一帧或多帧，表明你可能正确地使用了VBO；如果以上counter一直为0或很小，表明没有足够地或根本没有使用VBO。
5.5 检查是否有管道阻塞?
确认CPU和GPU是否同时忙，如果不是，则管道可能被阻塞了。为了避免管道阻塞，避免调用以下OpenGL ES函数：
o glReadPixels()
o glCopyTexImage()
o glTexSubImage()
5.6 检查是否有太多的状态变化?
状态变化开销相对较大，太多状态变化可能使用driver超负荷运行，从而影响性能。可通过查看以下OpenGL ES API的调用情况来查看状态变化：
o glEnable()
o glDisable()
6. GPU(Utgard)优化工作流程
6.1 顶点处理(VP)限制性能
注：在实际应用中，顶点处理(Vertex Processing)很少成为性能瓶颈。
高的顶点处理时间工作流程如下图所示：
6.1.1 检查vertex shader时间是否高?
可查看以下counter的图形是否总是高来确定存在此问题：
o Mali GPU Vertex Processor: Active cycles, vertex shader
为了查找其真正的原因，可分析以下三个counter来确定:
o Mali GPU Vertex Processor: Active cycles
o Mali GPU Vertex Processor: Active cycles, vertex shader
o Mali GPU Vertex Processor: Vertex loader cache misses
1) Shader太长?
如果以下条件都为真，表明Shader太长，需要缩短它。
o Active cycles vertex shader & Active cycles
o Vertex loader Cache misses值过高
2) Shader太复杂?
如果以下条件都为真，则表明Shader太复杂：
o Active cycles vertex shader接近Active cycles
o Vertex loader Cache misses值为低
可采用以下方法解决此问题：
o 简化Shader
o 应用算术优化
o 考虑是否可把部分工作移到CPU或FP(Fragment Processor)
3) Shader有太多的分支?
Mail GPU中的分支代价相对较低，但是太多的分析将导致Shader太长或太复杂。
6.1.2 检查顶点是否太多?
可查看以下counter的图形是否总是高来确定此问题。
oMali GPU Vertex Processor: Vertices processed
6.1.3 检查创建多边形列表(PLBU)时间是否高?
可通过测量以下counter的值来确定Polygon List Builder Unit (PLBU)时间是否为高：
o Mali GPU Vertex Processor: Active cycles, PLBU geometry processing
如果以上counter图形总是高，则应用可能使用了太多的三角形。减少三角形数量的方法如下：
o 使用更少的对象(Use fewer objects)
o 使用简单的对象(Use simpler objects)
o 删除镶嵌的对象(De-tessellate objects)
o 裁剪掉一些三角形(Cull triangles)
6.1.4 检查被裁剪掉(culled)的原语
可以通过裁剪掉在最后的图像中不可见的三角形来减少场景中三角形的数量。可通过以下counter查看被裁剪掉的原语：
o Mali GPU Vertex Processor: Primitives culled
如果“Primitives culled”的图形低，表明应用没有使用足够的裁剪。确认“backface culling”和“depth testing”都被激活。
如果“Primitives culled”的图形高，可能有以下几方面的原因：
o 应用可能使用了太多的三角形
o 应用可能没有使用视锥裁剪
o 应用可能让Mali GPU做了太多的裁剪
6.1.5 检查是否使用了VBO?
参考本文5.4。
6.2 像素处理(FP)限制性能
像素处理器的瓶颈来源于以下两方面：
1) 纹理带宽高
2) Fragment Shader程序长
高的像素处理时间优化流程如下图所示：
纹理带宽高
6.2.1.1 检查纹理带宽
测量以下counters:
o Fragment Processor: Total bus reads
o Fragment Processor: Texture descriptors reads
如果以上两个counters的图形都低，则瓶颈在于Fragment
如果以上两个counters的图形都高，则瓶颈在于纹理。
6.2.1.2 检查超大的纹理
检测以下counters:
o Mali GPU Fragment Processor X: Texture cache hit count.
o Mali GPU Fragment Processor X: Texture cache miss count.
纹理cache脱靶率通常是纹理cache命中率的10％，如果高于此值，可能存在以下问题：
1) 纹理太大
2) 纹理位深度太高
3) 应用没有使用mipmapping
如果以上任意条件为真，则应用可能存在内存带宽问题。
6.2.1.3 检查压缩纹理读取
测量以下counters:
o Mali GPU Fragment Processor X: Texture cache hit count (CountA)
o Mali GPU Fragment Processor X: Compressed texture cache hit count (CountB)
针对以上两个counters比较分析如下：
1) 如果CountB是0，则没有使用压缩纹理
2) CountA-CountB(即未压缩纹理数)远远小于CountB，则表明使用的压缩纹理太少，可以考虑使用更多的压缩纹理
3) 如果压缩纹理的数量远远大于未压缩纹理的数量，则问题可能在于：
o 纹理太大
o 应用没有使用mipmapping
o 纹理太多
纹理使用大量的内存带宽，这可能导致shader不能获取到足够的数据，从而导致性能降低。
6.2.1.4 检查overdraw
检测以下counter:
o Mali GPU Fragment Processor X: Fragment passed z/stensil count (count)
overdraw factor = count/屏幕像素数();
1) 如果factor等于1，表明没有overdraw，但此情况一般很少，其通常为2.5，但依赖具体应用
2) 如果factor大于2.5，则性能将被影响，可使用以下技术减小overdraw：
o 启用深度测试
o 启用“back face culling”以避免渲染不可见的面
o 按照深度排序场景中的对象
o 从前到后的顺序画非透明对象
o 从后到前的顺序画透明对象
6.2.2 Fragment Shader程序长
高的Fragment Shader时间优化流程如下：
6.2.2.1 确认问题在Fragment Shader
测试以下counters:
o Mali GPU Fragment Processor X: Fragment passed z/stensil count. (CountA)
o Mali GPU Fragment Processor X: Instruction completed count.(CountB)
CountB/CountA：其结果为每个Fragment花费的平均指令数。如果此值高，它表明应用程序有较高的fragment shader time。其参考值参见：
6.2.2.2 检查shader是否太长?
测量下面的硬件counters:
o Mali GPU Fragment Processor X: Program cache miss count. (CountA)
o Mali GPU Fragment Processor X: Program cache hit count. (CountB)
通常CountA是非常低的，且不大于CountB的0.01%。如果CountA图形高，表明Fragment Shader程序太长，需要缩短shader程序并验证。
6.2.2.3 检查shader是否太复杂?
测量下面的硬件counters:
o Mali GPU Fragment Processor X: Program cache miss count. (CountA)
o Mali GPU Fragment Processor X: Program cache hit count. (CountB)
通常CountA是非常低的，且不大于CountB的0.01%。如果CountA图形非常低，表明Fragment Shader太复杂，需要尝试以下方法：
1) 简化shader
2) 算法优化
3) 考虑是否可把ahder的部分功能移动CPU或VP
再次验证，如果对改善性能仍然无效，则看看是否shader太长且太复杂。
6.2.2.4 检查shader是否太长且太复杂?
如果已经检查过是否shader太长或复杂，且对优化没什么影响，则shader程序可能又长又复杂。对些，需要简化shader程序且缩短shader长度。
6.2.2.5 检查是否太多分支?
测量以下硬件counters:
o Mali GPU Fragment Processor X: Pipeline bubbles cycle count (CountA)
如果CountA高，表明shader可能有太多分支。
注：在Mali GPU上，分支不是一个大问题，因的它的计算量相对较小。
6.3 带宽限制性能
本节介绍如何确认带宽限制了性能，及如何减少带宽使用。
带宽限制工作流程如下图所示：
6.3.1 测试纹理cache命中与脱靶比率
纹理是内存带宽的最大用户。
测量下面的FP硬件counters:
o Mali GPU Fragment Processor X: Texture cache hit count. (CountA)
o Mali GPU Fragment Processor X: Texture cache miss count.(CountB)
通常CountA/CountB接近10，此比率越高越好，越低越糟糕。
一个低的比率表明cache使用高于正常状态，其原因可能为：
1) 使用了太大的纹理
2) 使用了太多的大纹理
3) 应用没有使用压缩纹理
4) 应用没有使用mipmap纹理
如果应用存在以上问题，则先进行了解决之后，再进行测试。
6.3.2 检查位块传输
位块传输(blitting)使用内存带宽且可能导致带宽过度使用。可查看以下counter:
o Mali EGL Software Counters: Blit Time
如果系统传输一个高分辨率的framebuffer，每秒的带宽需要几百MB。如果系统设置不正确，可能发生位块传输。
注：位块传输可能是显示系统的一部分，如果这样，位块传输是无法避免的。
6.3.3 测量可用最大带宽
为了定位谁过度使用了带宽：
o 计算出可得到的最大带宽
o 与系统的各个部分进行比较，以找到谁过度使用了带宽
如果不清楚设备的最大可用带宽，可使用一个测试程序来测量带宽，测试程序应满足以下要求：
o The highest resolution available.
o Highest bit depth possible.
o Very large, high bit depth textures.
o 16x Anti-aliasing.
o No texture compression.
o No mipmapping.
o No VSYNC.
如果测试程序运行帧率低，表明它充分使用了内存带宽。当运行测试程序时，测量以下counters:
o Mali GPU Vertex Processor: Words read, system bus.
o Mali GPU Vertex Processor: Words written, system bus.
o Mali GPU Fragment Processor X: Total bus reads.
o Mali GPU Fragment Processor X: Total bus writes.
注：如果Mali GPU有多个Fragment Processors，则需要测试每个FP。
把以上所有的测试结果加起来，然后乘以8，此结果为每秒可用的最大带宽，其单位为MB(Megabytes)。此结果包括cache使用，它可能稍稍大于系统中真正可用的最大内存带宽。
6.3.4 比较应用带宽与最大可用带宽
运行应用程序并测量以下counters:
o Mali GPU Vertex Processor: Words read, system bus.
o Mali GPU Vertex Processor: Words written, system bus.
o Mali GPU Fragment Processor X: Total bus reads.
o Mali GPU Fragment Processor X: Total bus writes.
把以上结果加起来并乘以8，其结果为应用程序使用的总带宽，其单位为MB/s。然后与6.3.3中的最大值进行比较，如果比较接近，说明应用使用了大多的内存带宽。
比较这些值，年谁最高：
1) 如果Mali GPU FP使用了太多的带宽，见下面的FP带宽限制性能
2) 如果Mali GPU VP使用了太多的带宽，见下面的VP带宽限制性能
6.3.5 FP带宽限制性能
如果应用的性能被FP带宽限制了，问题可能在于以下几方面：
通常读取纹理占用大量内存带宽，可减少纹理带宽的方法如下：
1) 减小纹理数量
2) 降低纹理分辨率
3) 降低纹理位深度
4) 使用mipmapping
5) 使用压缩纹理
o Overdraw
当像素被绘制在彼此之上，overdraw就发生了。它浪费了带宽，因为被绘制在其上的像素是不可见的。
o Trilinear filtering
三线性过滤需要读取多个纹理生成一个单一的象素，它使用了大量的带宽。
o Fragment Shader太复杂
复杂的Shaders拥有大量的中间状态，这些中间状态可能占满了cache内存，从而导致把中间状态刷新到主内存中。
6.3.6 VP带宽限制性能
如果VP过度占用带宽导致了性能问题，则问题可能在于：
o 太多的三角形
太多的三角形将占用大量带宽，但一般不会发生，除非场景调试复杂
如果不使用culling，也可能占用大量带宽；因为VP将处理一些从不被绘制的三角形
o 顶点Shader太复杂
复杂的Shaders拥有大量的中间状态，这些中间状态可能占满了cache内存，从而导致把中间状态刷新到主内存中。
o 读取非本地数据
如果你把从不使用的数据传递给GPU并cache起来。避免使用稀疏的顶点数组，总是把数据放在一起以提高cache的可能性。
没有更多推荐了，
加入CSDN，享受更精准的内容推荐，与500万程序员共同成长！内容字号：
段落设置：
字体设置：
精准搜索请尝试：
看后秒懂ARM手机GPU：ARM Mali图形处理器产品线图解
来源：作者：达达责编：达达
如今的手机越来越强大，人们将越来越多的娱乐和工作放在手机上完成，人们在手机上能够玩到越来越多的顶级游戏大作，这对手机图形处理能力的要求也在提高。目前，移动领域最常见的3大图形处理器为高通的Adreno、英国PowerVR和ARM的嵌入式图形处理器Mali。今天，我们来看一下Mali目前的全线图形处理器产品。Mali GPU命名方式以年代为单位，目前最新的为Mali T8XX系列，Mali T7XX系列作为架构比较旧的老款依然在列，而T6XX系列已经被淘汰，T4XX系列代表最低端。目前，Mali最顶级的GPU为T880，华为海思麒麟955、联发科X20/X25、三星Exynos 8890三个移动处理器均搭载了Mali T880的图形处理器，其中采用Mali T880 MP12的三星8890处理器号称拥有当前移动平台最强的图形处理能力。其他T8XX系列GPU定位如下：Mali-T860：定位高端，最多16个着色器核心(Shader Core)，取代T760的地位。Mali-T830：中低端，最多4个核心，强调性能与能效的平衡，性能相比T622高最多55%。Mali-T820：入门级，最多4个核心，性能密度比T622高最多40%。而最为低端的Mali-T400少有手机使用，目前很大一部分用于低端的电视盒子等领域。在可穿戴设备领域，Mali-400MP1和Mali-T450MP2成为为主力产品，这类低端产品功耗较低，非常适合并不需要很强图形性能的可穿戴设备。
软媒旗下软件：
IT之家，软媒旗下科技门户网站 - 爱科技，爱这里。
Copyright (C) , All Rights Reserved.stay hungry stay foolish
Mali GPU OpenGL ES 应用性能优化--基本概念
1. 基本概念
1.1 Mali GPU家族
Mali GPU家族都包含以下通用的硬件：
o 基于分块的延迟渲染:
Mali GPU把framebuffer分成许多块(16 x 16像素)，然后一块一块地进行渲染。基于分块的渲染是有效的，因为像素值使用片上内存进行计算。它需要更少的内存带宽和功耗。
o L2 Cache控制器：
一个Mali GPU有一个或多个L2 Cache控制器，它可减少内存带宽(可减少访问主内存)和功耗。Mail GPU使用L2 Cache代替本地内存(Local Memory)。
1.1.1 Utgard架构家族
具有一个顶点处理器(VP)和一个或多个片断处理器(FP)，支持OpenGL ES 1.1 和 2.0。
Mali GPU组件
2) Mali-400 MP GPU架构
o 顶点处理器(Vertex Processor: VP)
VP处理图形管道的顶点处理(vertex processing)阶段的工作，它产生原语(点、线、三角形)列表，并加速创建供像素处理器(Fragment Processors: FP)使用的数据结构(如：多边形列表和打包的顶点数据)。
o 像素处理器(Fragment Processor:FP)
FP处理图形管道的光栅化和像素处理阶段的工作。它使用VP输出的数据结构和原语列表来产生framebuffer中的像素数据，以方便显示在屏幕上。
1.1.2 Midgard架构家族
Midgard的GPU拥有用于执行顶点、片断和计算处理的统一的Shader cores，它支持OpenGL ES 1.1、2.0、3.0，以及OpenCL
1) Mali-T600系列GPU组件
2) Mali-T600系列GPU架构
1.2 图形管道(OpenGL ES Graphics Pipeline)
Mali GPU使用数据结构和硬件功能模块(VP、FP、MMU、PMU、L2 Cache控制器)来实现OpenGL ES图形管道。
1.2.1 初始化处理 (Start processing)
OpenGL ES API级的驱动在内存中为GPU创建数据结构、且为每个场景配置硬件。软件主要功能如下：
1) 为RSWs(Render State Words)和纹理描述产生数据结构
2) 为顶点处理创建命令列表
3) 在需要时编译Shaders
1.2.2 顶点处理操作(Per-vertex processing operations)
顶点处理器为每个顶点运行一次顶点着色器程序(Vertex Shader Program)，顶点着色器程序执行如下操作：
1) 光照(Lighting)
2) 变换(Transforms：平移、旋转、拉伸)
3) 视口变换(Viewport transformation)
4) 透视变换(Perspective transformation)
5) 组装图形顶点原语(Assembles vertices of graphics primitives)
6) 创建多边形列表(Builds polygon lists)
1.2.3 光栅化和片断着色(Rasterization and fragment shading)
片断/像素处理器(FP)执行以下操作：
1) 读取数据(数据--&系数)：
读取状态信息、多边形列表和变换之后的顶点数据。这些数据由【三角形设置单元】进行处理并生成系数。
2) 多边形光栅化(系数--&片断)：
光栅器从【三角形设置单元】中获取系数，然后执行方程式以创建片断。
3) 执行片断着色器(片断--&颜色)：
片断/像素处理器为每一个片断执行一次【片断着色器程序】以计算出每个片断的颜色。
1.2.4 混合和帧缓冲操作(Blending and framebuffer operations)
fragments--& tile buffers --& framebuffer
在处理完tile buffer之后，FP为framebuffer产生最后的显示数据。为了提高处理速度，每一个FP处理不同的tile。
混合单元把fragments与在对应位置的tile buffer中已经存在的颜色数据进行混合。
FP主要功能如下：
1) 测试fragments且更新tile buffer
2) 计算fragments是否可见，且把可见的fragments保存到tile buffers中
3) 在当前tile被完全渲染之后，把tile buffer中的内容写入framebuffer中
2. 优化清单
2.1 检查显示设置
1) 应用程序使用正确的drawing surface，使用支持的surface中的一个。
2) Framebuffer分辨率和颜色格式与显示控制器兼容
3) Framebuffer不要超过屏幕的分辨率
4) Framebuffer不要超过屏幕的的颜色的深度
5) Framebuffer格式应当与drawing surface格式相同
2.2 使用正确的工具和工具设置
1) 使用工具的最新版本
2) 当工具更新之后，重新编译所有代码
3) 创建与硬件结构相对应的版本
4) 充分使用硬件特性：如果硬件支持硬浮点(Vector Floating Point&VFP&)或NEON，使用此特性编译所有相关的代码
5) 最后以Release版本发布
2.3 删除调试信息
1) 尽量少使用printf，但logcat对性能影响不大
2) 尽量不要调用glGetError()，如果需要，每帧不要超过一次，因为它需要占用较多的时间
2.4 避免无限命令列表
1) 如果帧间不清楚buffers，命令列表可能一直增长，它将导致GPU做无用功。
2) 如果App渲染到surface(如：pixmapsurface、pbuffersurface)，在一帧结束时不清除命令列表
3) 如果使用FBO(Framebuffer Objects)，则不存在此问题
4) 如果渲染到eglWindowSurface，每当调用eglSwapBuffers()时，命令列表自动结束
5) 为了防止命令列表无限增长，必须同时清楚这些颜色、深度和模板buffer。调用函数：
glClear( GL_COLOR_BUFFER_BIT | GL_DEPTHBUFFER_BIT | GL_STENCILBUFFER_BIT );
2.5 避免调用阻塞图形管道的函数
1) glReadPixels()
2) glCopyTexImage()
3) glTexSubImage()
2.6 不要每一帧都编译Shaders
尽量在应用程序启动时编译Shaders，或者使用预编译的shaders。预编译的Shaders只能在编译时指定的GPU上运行。
2.7 使用VSYNC
VSYNC(Vertical Synchronization)可使应用的帧率与屏幕的显示速率同步，其功能如下：
1) 它通过消除撕裂改善图像的质量
2) 防止应用产生的帧率大于屏幕可显示的帧率，以降低功耗
2.8 禁止使用24位纹理
可使用16位或32位纹理，而不要使用24位纹理。24位纹理不完全适合高速缓存。采用24位纹理可能会导致数据使用超过一个高速缓存行，这对性能和内存带宽将产生负面影响。
2.9 使用纹理映射(mipmapping)--good
纹理映射：采取高分辨率纹理，并将其伸缩到多个较小的尺寸称为mipmap级别的纹理。这需要比非mipmapped纹理多约33%的内存。
在执行时调用glGenerateMipmap()根据未压缩的纹理产生mipmaps，或使用《Mali GPU Texture Compression Tool》预产生mipmaps。
其好处如下：
1) 改善图像质量
2) 提高性能
3) 减少内存带宽
2.10 使用ETC压缩纹理
压缩纹理可减少纹理的大小，其好处如下:
1) 提高性能
2) 提高纹理的可缓存性
3) 减少内存带宽
可用的ETC(Ericsson Texture Compression)压缩纹理类型如下：
可使用《Mali GPU Texture Compression Tool》创建ETC1、ETC2和ASTC压缩纹理。
2.11 减少内存带宽
内存带宽不仅是性能bottleneck，而且内存带宽越大，功耗越高。
1) 内存带宽是共享资源，如过度使用将导致整个系统性能问题；如图像内存由APP共享，当GPU过度使用带宽时，CPU性能也将下降
2) 访问高速缓存中的将降低功能和提高性能；若APP必须从主内存中读取大量数据，可使用mipmapping或texture compression等技术以确保数据可被高速缓存所缓存
3) 可减少内存带宽的方法：
o Activate back face culling.
o Utilize view frustum culling.
o Ensure textures are not too large.
o Use a texture resolution that fits the object on screen.
o Use low bit depth textures where possible.
o Use lower resolution textures if the texture does not contain sharp detail.
o Only use trilinear filtering on specific objects.
o Utilize Level of Detail (LOD).
2.12 使用顶点Buffer对象(VBO)
VBO(Vertex Buffer Object)是让APP存储和操作GPU内存中数据的一种机制。当GPU处理数据时，不需要从CPU内存中读取，可以节约内存带宽。
2.13 发布时检查列表
3. 优化流程
一般优化流程如下图所示：
3.1 如何评估优化效果?
评估优化效果时使用Frame Time，而不是FPS。
FPS(Frames per Second) 一个基本的性能指标，而Frame Time是最好的性能优化效果指标。Frame Time是一个线性值，而FPS是一个非线性值，线性值计算更加容易。
FPS与Frame Time的差异如下图所示：
3.2 如何计算Fragment Shader的最大cycles?
A = GPU时钟速度 x FP个数 x 0.8;
// 每秒可达到的最大cycles
B = FB_H x FB_W x 期望的FPS x 2.5; //每秒要求的fragments数
C = A/B; // Fragment Shader的平均cycles
通过shader compiler工具可以得知Shader需要的cycles.
注：不要误以为Fragment Processing 周期数(cycles)等于Fragment Processing指令数，Mali GPU中的处理器在每周期可执行许多指令。
3.3 Bottleneck在处理器间移动
o 在优化过程中，性能瓶颈可在图形管理的不同阶段(即不同的处理)间移动。在DS-5 Streamline中可从图形显示中读取瓶颈位置，瓶颈是其负荷最大的地方。
在上图中，为了改善性能，可把应用处理器和Fragment处理器上的部分工作移到Vertex处理器上来做。
理想的负荷状态
理想的负荷状态是：图形管道各个阶段的负荷相当，如下图所示：
没有更多推荐了，
加入CSDN，享受更精准的内容推荐，与500万程序员共同成长！}