Kai*_*Kai 24 performance android android-4.3-jelly-bean
我刚刚将Galaxy Nexus更新为4.3并启用了新的屏幕GPU分析功能,并在Android设置屏幕中看到以下结果:

根据平台亮点:
[With] colors indicating time spent creating drawing commands (blue), issuing the commands (orange), and waiting for the commands to complete (yellow).
Run Code Online (Sandbox Code Playgroud)
即使在非常简单的屏幕上,有很多情况下屏幕刷新时间高于平滑60 fps(绿线)的阈值,这主要是因为有很多情况下刷新会花费大量时间等待命令完成(黄线*),而其他时间这一步几乎是瞬间的.这也不是设置应用程序特有的东西,但似乎存在于我到目前为止测试的所有应用程序.*对我来说,看起来比黄色更黄
我想知道的是:
[编辑:]
更新了Nexus 7,情况更糟:

多达5帧被跳过"等待命令完成"并且它在使用中真正显示,该应用程序非常不稳定且无响应.
[编辑2:] 我已经根据这篇文章执行了这些以触发TRIM约3天,因此N7应该是"原始的",因为它将缺乏恢复出厂设置.
现在谷歌地图似乎表现得更好(见下文),所以一些问题可能与闪存访问速度有关,虽然我不知道如何.

尽管如此,由于Galaxy Nexus出厂重置,其长时间"等待命令完成"的时间与缺少TRIM命令无关,并且遵循上述步骤确实没有产生改进.所以我们又回到了原点......
“等待命令完成”表示存在对渲染帧的依赖性。例如,应用程序可能正在使用glReadPixels读取渲染的帧。这意味着在帧被发送到 GPU 进行渲染后,应用程序将被阻止,直到渲染该帧完成(而通常它可以立即继续)。Android 尝试让应用程序对尽可能多的渲染命令进行排队,因此突然引入等待实际上可能意味着应用程序必须等待几个先前排队的帧被绘制,然后才能渲染它正在等待的帧。
glReadPixels不是导致这种依赖性的唯一命令。如果应用程序想要写入当前正在使用的纹理,则必须等到所有依赖于该纹理的帧都完成。这似乎是 Google 地图正在发生的情况:如果每个地图图块都是一个纹理,它可能会通过将新图块写入其中以准备显示来重用旧的屏幕外图块。一旦应用程序将不使用旧图块的帧排队,它就会尝试写入该纹理,但实际上该纹理仍用于渲染先前排队的帧。应用程序必须等到这些帧完成(并且 GPU 不再从“未使用的”纹理读取)才能写入。
理论上,可以让工作线程写入纹理,从而允许主线程继续顺利地对新帧进行排队。但是 GL 复杂的线程模型使得完成这样的事情变得非常棘手,并且主线程最终必须等待纹理上传完成。
至于“设置”应用程序,Android 的 GL 后端可能正在对图标执行相同的纹理重用技巧,但这只是猜测。也许 Galaxy Nexus 使用 2D 合成器进行帧合成,这可以节省电量,但代价是在驱动程序中引入等待。我不知道这种依赖性是否会在图表中得到衡量。
| 归档时间: |
|
| 查看次数: |
5622 次 |
| 最近记录: |