Android 4.3 On-screen GPU profiling - long gfx waiting time

Question

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:

Answer 1

"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 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.

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.

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.