24

我刚刚将 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).

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

我想知道的是：

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

[编辑：]

还更新了 Nexus 7，甚至更糟：

在此处输入图像描述

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

[编辑 2：] 我已按照本文执行这些操作以触发 TRIM 约 3 天，因此 N7 应该是“原始的”，因为它不会恢复出厂设置。

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

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

在此处输入图像描述

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

4

1 回答 1

3

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

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

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

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

于 2013-08-12T11:32:04.683 回答