安卓4.3屏幕上的GPU性能分析 - 长GFX等待时间 [英] Android 4.3 On-screen GPU profiling - long gfx waiting time
问题描述
我刚刚更新了Galaxy Nexus的4.3并启用新的屏幕上的GPU分析功能，看到以下结果为Android设置屏幕：
I have just updated a Galaxy Nexus to 4.3 and enabled the new On-screen GPU profiling function, and see the following result for Android setup screen:
按照平台亮点的：
[With] colors indicating time spent creating drawing commands (blue), issuing the commands (orange), and waiting for the commands to complete (yellow).
即使在一个非常简单的屏幕，有许多情况下，该屏幕刷新时间大于该阈值的平滑每秒60帧（绿线），并且它主要是因为有许多情况，其中一个刷新会花费一显著时间等待供的命令完成（黄线*），而此步骤其他时间几乎是瞬间的。这是不是特别的设置应用程序要么，但似乎是$ P $ psent所有我到目前为止测试的应用程序。 *看起来比黄色鲜橙多给我
Even on a very simple screen, there are many instances that the screen refresh time is above the threshold for a smooth 60 fps (green line), and it's mostly because there are many instances where a refresh would spend a significant time waiting for the commands to complete (yellow line*), while other times this step is almost instantaneous. This is not something particular to the Setting app either, but seem to be present for all the apps I've tested so far. *looks more orange than yellow to me
我想知道的是：
- 这是所花费的时间等待命令完成是指，在屏幕的命令正在积极地处理，因而将时间准确重新present所花费的时间绘制在屏幕上。 或的确实这个时候有时间等待视频同步（不过我倒是觉得三重缓冲将用于删除此要求） ？
- 的时间花在等待命令完成绘制同一画面时，会大起大落甚至（滚动小幅向上和在同一滚动型下），有没有就如何减少这种波动的任何指导意见（或者如果它可以减少的话）？
- Is this time spent "waiting for the commands to complete" means that the screen commands are being actively process and thus the time would accurately represent the time spent drawing the screen. OR does this time include the time waiting for video-sync (though I'd think triple buffer would be used to remove this requirement)?
- The time spent "waiting for the commands to complete" would fluctuate wildly even when drawing the same screen (scroll slightly up & down on the same ScrollView), is there any guidance on how to reduce this fluctuation (or if it could be reduced at all)?
更新的Nexus 7，以及，它甚至更糟：
Updated Nexus 7 as well, and it's even worse:
多达5帧被跳过等待命令完成，它确实显示，使用，应用程序是非常不连贯，反应迟钝。
As many as 5 frames are being skipped "waiting for the commands to complete" and it really showed in usage, the app was very choppy and unresponsive.
我已经按<一个执行了这些href="http://www.examiner.com/article/android-4-3-adds-trim-support-alleviating-nexus-7-slowdown-over-time-woes">this文章触发TRIM为〜3天，因此N7应为质朴，因为它会得到短暂恢复出厂设置的。
I have performed these per this article to trigger TRIM for ~3 days, so the N7 should be as "pristine" as it's going to get short of a factory reset.
- 设备已经闲置了一个多小时
- 在没有空闲的维护窗口事件已过去24小时内已执行
- 在该设备是充电30％的电池或有80％的电池
现在谷歌地图似乎表现得更好一点（见下文），所以有些问题可能与闪存存取速度，虽然我不知道怎么办。
Now Google Maps seem to behave a bit better (see below), so some of the issues may be related to flash access speed though I don't know how.
不过，由于Galaxy Nexus的是恢复出厂设置，其漫长的等待命令完成时间不能与缺乏TRIM命令，并按照上面的步骤，确实没有产生改进。所以，我们又回到了起点......
Still, since the Galaxy Nexus is factory reset, its long "waiting for the commands to complete" time can't be related to the lack of TRIM command, and following the above steps indeed didn't produce improvements. So we are back at square one...
推荐答案
正在等待命令完成表明有上渲染的帧的依赖性。例如，应用程序可能会使用 glReadPixels 从渲染帧阅读。这意味着，在帧已经发送到GPU进行渲染，应用程序被阻塞，直到渲染帧完成（而通常这将是能够继续的时候了）。 Android的尝试让应用程序队列尽可能多的渲染指令越好，这样突然引入等待实际上可能意味着应用程序必须等待数previously排队的帧它等待渲染的帧之前绘制。
"Waiting for commands to complete" indicates that there are dependencies on rendered frames. For example, the app might be using glReadPixels to read from the rendered frame. This means that after the frame has been sent to the GPU for rendering, the app is blocked until rendering that frame finishes (whereas normally it would be able to continue right away). Android tries to let the app queue up as many rendering commands as possible, so suddenly introducing a wait might actually mean the app has to wait for several previously queued frames to be drawn before the frame it's waiting for is rendered.
glReadPixels 不是导致这种依赖的唯一的命令。如果一个应用程序想写入该真实当前正在使用的质地，它必须等待，直到所有的依赖于该纹理帧已经完成。这是振振有词正在发生的事情与谷歌地图：如果每个地图瓷砖纹理，它可能是通过写一个新的瓷砖到它准备好展示重复使用旧关屏瓦。一旦应用程序已排队，不使用旧砖的框架，它试图写入纹理，但是真正的质感仍然被用来渲染previously排队的帧。该应用程序必须等待，直到这些帧结束（和GPU不再从未使用纹理读取），才可以写。
glReadPixels isn't the only command that causes this kind of dependency. If an app wants to write to a texture that's currently being used, it has to wait until all the frames that depend on the texture have finished. This is plausibly what is happening with Google Maps: if each map tile is a texture, it might be reusing an old off-screen tile by writing a new tile into it ready to show. Once the app has queued a frame that doesn't use the old tile, it tries to write into that texture, but really the texture is still being used to render previously queued frames. The app has to wait until those frames are finished (and the GPU is no longer reading from the 'unused' texture) before it can write.
在理论上，它可能有一个工作线程写入的质感，让主线程顺利进行排队的新框架。但是GL复杂的线程模型使得它非常棘手得到这样的权利，而主线程最终将不得不等待纹理上传反正来完成。
In theory, it's possible to have a worker thread write to the texture, allowing the main thread to go on queueing new frames smoothly. But GL's complex thread model makes it very tricky to get something like this right, and the main thread would eventually have to wait for the texture upload to complete anyway.
对于设置应用程序，这可能是因为Android的GL后端做同样的纹理，再用绝招的图标，但是这只是一个猜测。或许Galaxy Nexus的是使用二维合成器做框架组成，从而节省电力，但在引进的司机等待的成本。我不知道是不是那种依赖将在图表中进行测量。
As for the Settings app, it could be that Android's GL backend is doing the same texture-reuse trick for the icons, but that's just a guess. Perhaps the Galaxy Nexus is using a 2D compositor to do frame composition, which saves power but at the cost of introducing a wait in the driver. I don't know whether that kind of dependency would be measured in the chart.
这篇关于安卓4.3屏幕上的GPU性能分析 - 长GFX等待时间的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
