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

Question

我刚刚将 Galaxy Nexus 更新到 4.3 并启用了新的屏幕显示 GPU 分析功能，然后在 Android 设置屏幕上看到以下结果:

根据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. “等待命令完成”所花费的时间是否意味着正在积极处理屏幕命令，因此该时间将准确地表示绘制屏幕所花费的时间。 或这个时间是否包括等待视频同步的时间(尽管我认为三重缓冲区将用于消除此要求)？
2. 即使在绘制同一个屏幕(在同一个 ScrollView 上略微上下滚动)时，“等待命令完成”所花费的时间也会大幅波动，是否有任何关于如何减少这种波动的指导(或者是否可以完全减少)？

[编辑:]

还更新了 Nexus 7，而且更糟:

“等待命令完成”跳过了多达 5 帧，它在使用中确实显示出来，应用程序非常不稳定且无响应。

[编辑 2:]我已经按照 this article 执行了这些操作。触发 TRIM 约 3 天，因此 N7 应该像“原始”一样“原始”，因为它不会恢复出厂设置。

• 设备已闲置超过一个小时
• 过去 24 小时内未执行任何空闲维护窗口事件
• 设备正在以 30% 的电量或 80% 的电量充电

现在谷歌地图的表现似乎好一点(见下文)，所以有些问题可能与闪存访问速度有关，虽然我不知道如何。

不过，由于 Galaxy Nexus 已恢复出厂设置，其长时间的“等待命令完成”时间不能与缺少 TRIM 命令有关，并且按照上述步骤确实没有产生改进。所以我们回到了第一方......

Answer 1

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

glReadPixels 并不是导致这种依赖的唯一命令。如果应用程序想要写入当前正在使用的纹理，它必须等到依赖于纹理的所有帧都完成。这似乎是谷歌地图正在发生的事情:如果每个 map 图 block 都是一个纹理，它可能会通过在其中写入一个新的图 block 来重用一个旧的屏幕外图 block 以供显示。一旦应用程序将不使用旧图 block 的帧排队，它会尝试写入该纹理，但实际上纹理仍用于渲染先前排队的帧。应用必须等到这些帧完成(并且 GPU 不再从“未使用”纹理中读取)才能写入。

理论上，可以让工作线程写入纹理，从而允许主线程顺利地继续对新帧进行排队。但是 GL 复杂的线程模型使得正确处理这样的事情变得非常棘手，而且主线程最终还是不得不等待纹理上传完成。

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