Android 4.3屏幕GPU分析 - 长gfx等待时间

时间:2013-07-25 09:29:55

标签: android performance android-4.3-jelly-bean

我刚刚将Galaxy Nexus更新为4.3并启用了新的屏幕GPU分析功能,并在Android设置屏幕中看到以下结果:

enter image description here

根据platform highlights

[With] colors indicating time spent creating drawing commands (blue), issuing the commands (orange), and waiting for the commands to complete (yellow).

即使在一个非常简单的屏幕上,有很多情况下屏幕刷新时间高于平滑60 fps(绿线)的阈值,这主要是因为很多情况下刷新会花费大量时间等待要完成命令(黄线*),而其他时候这一步几乎是瞬间完成的。这也不是设置应用程序特有的东西,但似乎存在于我到目前为止测试的所有应用程序。 *对我来说,看起来比黄色更橙色

我想知道的是:

  1. 花费这些时间“等待命令完成”意味着屏幕命令正在被主动处理,因此时间将准确地表示绘制屏幕所花费的时间。这次 OR 包括等待视频同步的时间(虽然我认为三重缓冲区将用于删除此要求)?
  2. 即使在绘制相同的屏幕(在同一个ScrollView上稍微向上和向下滚动),“等待命令完成”花费的时间也会大幅波动,是否有关于如何减少这种波动的指导(或者如果它可以减少吗?
  3. [编辑:]

    更新了Nexus 7,情况更糟:

    enter image description here

    多达5帧被跳过“等待命令完成”并且它在使用中显示,该应用程序非常不稳定且无响应。

    [编辑2:] 我已经按this article执行了这些操作以触发TRIM约3天,因此N7应该是“原始的”,因为它将缺少恢复出厂设置。

    • 设备闲置一个多小时
    • 过去24小时内未执行任何空闲维护时段事件
    • 设备正在使用30%的电池充电,或者使用80%的电池充电

    现在谷歌地图似乎表现得更好(见下文),因此有些问题可能与闪存访问速度有关,但我不知道如何。

    enter image description here

    尽管如此,由于Galaxy Nexus出厂重置,其漫长的“等待命令完成”时间与缺乏TRIM命令无关,并且遵循上述步骤确实没有产生改进。所以我们回到原点......

1 个答案:

答案 0 :(得分:3)

“等待命令完成”表示对渲染帧存在依赖性。例如,应用可能正在使用glReadPixels从渲染帧中读取。这意味着在将帧发送到GPU进行渲染之后,应用程序将被阻止,直到呈现该帧结束(而通常它将能够立即继续)。 Android尝试让应用程序排队尽可能多的渲染命令,因此突然引入等待可能实际上意味着应用程序必须等待几个先前排队的帧在它等待的帧被渲染之前被绘制。

glReadPixels不是导致此类依赖性的唯一命令。如果某个应用想要写入当前正在使用的纹理,则必须等到所有依赖于纹理的帧都已完成。这似乎是Google地图发生的事情:如果每个地图图块都是一个纹理,它可能会重新使用旧的屏幕外图块,将新图块写入其中以备展示。一旦应用程序排队了一个不使用旧磁贴的帧,它就会尝试写入该纹理,但实际上纹理仍然用于渲染以前排队的帧。应用程序必须等到这些帧完成(并且GPU不再从'未使用的'纹理中读取)才能写入。

理论上,可以让工作线程写入纹理,允许主线程顺利地排队新帧。但GL的复杂线程模型使得这样的东西变得非常棘手,并且主线程最终还是必须等待纹理上传完成。

至于设置应用程序,可能是Android的GL后端正在为图标执行相同的纹理重用技巧,但这只是猜测。也许Galaxy Nexus正在使用2D合成器来进行帧组合,这样可以节省功耗,但代价是在驱动程序中引入等待。我不知道是否会在图表中衡量这种依赖性。