seguimiento - Perfiles de GPU en pantalla de Android 4.3-tiempo de espera largo de gfx

opciones de desarrollador samsung (1)

Acabo de actualizar un Galaxy Nexus a 4.3 y habilité la nueva función de creación de perfiles GPU en pantalla, y veo el siguiente resultado para la pantalla de configuración de Android:

Según destaca la plataforma :

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

Incluso en una pantalla muy simple, hay muchos casos en que el tiempo de actualización de la pantalla está por encima del umbral para un 60 fps suave (línea verde), y es principalmente porque hay muchos casos en los que una actualización pasaría un tiempo significativo esperando los comandos para completar (línea amarilla *), mientras que otras veces este paso es casi instantáneo. Esto tampoco es algo particular de la aplicación de configuración, pero parece estar presente para todas las aplicaciones que he probado hasta ahora. * me parece más naranja que amarillo

Lo que deseo saber son:

Este tiempo dedicado a "esperar a que se completen los comandos" significa que los comandos de la pantalla se están procesando activamente y, por lo tanto, el tiempo representaría con precisión el tiempo empleado en dibujar la pantalla. O, ¿esta vez incluye el tiempo de espera para la sincronización de video (aunque creo que se usaría el triple búfer para eliminar este requisito)?
El tiempo dedicado a "esperar a que se completen los comandos" fluctuaría enormemente incluso al dibujar la misma pantalla (desplazarse ligeramente hacia arriba y hacia abajo en el mismo ScrollView), ¿hay alguna guía sobre cómo reducir esta fluctuación (o si podría reducirse en todos)?

[Editar:]

Actualizado Nexus 7 también, y es aún peor:

Se omitieron hasta 5 cuadros "en espera de que se completen los comandos" y realmente se mostró en uso, la aplicación fue muy entrecortada y no responde.

[Edición 2:] He realizado estos por este artículo para activar TRIM durante aproximadamente 3 días, por lo que el N7 debería ser tan "prístino" como se va a quedar corto de un restablecimiento de fábrica.

El dispositivo ha estado inactivo durante más de una hora.
No se ha realizado ningún evento de ventana de mantenimiento inactivo en las últimas 24 horas
El dispositivo se está cargando con una batería del 30 por ciento o tiene una batería del 80 por ciento

Ahora, Google Maps parece comportarse un poco mejor (ver más abajo), por lo que algunos de los problemas pueden estar relacionados con la velocidad de acceso de flash, aunque no sé cómo.

Sin embargo, dado que el Galaxy Nexus se ha restablecido de fábrica, su largo tiempo de "espera a que se completen los comandos" no se puede relacionar con la falta del comando TRIM y, de hecho, seguir los pasos anteriores no produjo mejoras. Así que estamos de vuelta en la plaza uno ...

"En espera de que se completen los comandos" indica que hay dependencias en los marcos renderizados. Por ejemplo, la aplicación podría estar usando glReadPixels para leer desde el marco renderizado. Esto significa que después de que el marco se haya enviado a la GPU para su procesamiento, la aplicación se bloquea hasta que finalice ese marco (mientras que normalmente podría continuar de inmediato). Android intenta permitir que la aplicación ponga en cola la mayor cantidad posible de comandos de representación, por lo que la introducción repentina de una espera puede significar que la aplicación tiene que esperar a que se dibujen varios marcos previamente en cola antes de que se renderice el marco que está esperando.

glReadPixels no es el único comando que causa este tipo de dependencia. Si una aplicación desea escribir en una textura que se está utilizando actualmente, tiene que esperar hasta que todos los marcos que dependen de la textura hayan terminado. Esto es plausible lo que está sucediendo con Google Maps: si cada mosaico de mapa es una textura, podría estar reutilizando un mosaico antiguo fuera de pantalla escribiendo un nuevo mosaico en él listo para mostrar. Una vez que la aplicación ha puesto en cola un marco que no usa el mosaico anterior, intenta escribir en esa textura, pero en realidad la textura todavía se está utilizando para renderizar marcos en cola previamente. La aplicación tiene que esperar hasta que se terminen esos marcos (y la GPU ya no lee de la textura ''no utilizada'') antes de que pueda escribir.

En teoría, es posible hacer que un subproceso de trabajo escriba en la textura, permitiendo que el subproceso principal empiece a poner en cola los nuevos marcos sin problemas. Pero el complejo modelo de subprocesos de GL hace que sea muy difícil conseguir algo así, y el subproceso principal finalmente tendrá que esperar a que se complete la carga de la textura de todos modos.

En cuanto a la aplicación Configuración, podría ser que el backend GL de Android esté haciendo el mismo truco de reutilización de la textura para los íconos, pero eso es solo una suposición. Tal vez el Galaxy Nexus esté usando un compositor 2D para hacer la composición de cuadros, lo que ahorra energía pero a costa de introducir una espera en el controlador. No sé si ese tipo de dependencia se mediría en la tabla.