Android 4.3 Creación de perfiles de GPU en pantalla-largo tiempo de espera gfx
Acabo de actualizar un Nexus Galaxy a 4.3 y habilitó la nueva función de perfil de GPU en pantalla, y ver el siguiente resultado para la pantalla de configuración de Android:
De acuerdo con la plataforma puntos destacados :
[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 los que el tiempo de actualización de la pantalla está por encima del umbral para una suave 60 fps (línea verde), y es principalmente porque hay muchos casos en los que una actualización pasaría un tiempo significativo esperando a que se completen los comandos (línea amarilla*), mientras que otras veces este paso es casi instantáneo. Esto no es algo particular para la aplicación de configuración tampoco, pero parece estar presente para todas las aplicaciones que he probado hasta ahora. * se ve más naranja que amarillo para mí
Lo que quiero saber son:
- Este tiempo dedicado a "esperar a que los comandos se completen" significa que los comandos de pantalla se están procesando activamente y, por lo tanto, el tiempo representaría con precisión el tiempo dedicado dibujando la pantalla. O ¿esta vez incluye el tiempo de espera para la sincronización de video (aunque creo que se usaría triple buffer para eliminar este requisito)?
- El tiempo dedicado a "esperar a que se completen los comandos" fluctuaría enormemente incluso cuando se dibuja la misma pantalla (desplácese ligeramente hacia arriba y hacia abajo en el mismo ScrollView), ¿hay alguna guía sobre cómo reducir esta fluctuación (o si se podría reducir en absoluto)?
[Editar:]
Nexus 7 actualizado también, y es aún peor:
Se están omitiendo hasta 5 fotogramas "esperando que se completen los comandos" y realmente se mostró en el uso, la aplicación era muy entrecortada y no respondía.
[Editar 2:] He realizado estos por este artículo para activar TRIM durante ~3 días, por lo que el N7 debe ser tan "prístino" como se va a conseguir corto de un restablecimiento de fábrica.
- El dispositivo ha estado inactivo durante más de una hora
- Sin mantenimiento inactivo el evento window se ha realizado en las últimas 24 horas
- El dispositivo está cargado con 30 por ciento de batería o tiene 80 por ciento de batería
Ahora Google Maps parece comportarse un poco mejor (ver a continuación), por lo que algunos de los problemas pueden estar relacionados con la velocidad de acceso flash, aunque no se cómo.
Aún así, ya que el Nexus Galaxy se restablece de fábrica, su largo "esperando a que los comandos para completar" tiempo no puede estar relacionado con la falta de comando TRIM, y de hecho, seguir los pasos anteriores no produjo mejoras. Así que estamos de vuelta en el punto de partida...
1 answers
"Esperando 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 fotograma se haya enviado a la GPU para su procesamiento, la aplicación se bloqueará hasta que finalice el procesamiento del fotograma (mientras que normalmente podría continuar de inmediato). Android intenta dejar que la aplicación ponga en cola tantos comandos de renderizado como sea posible, por lo que de repente introducir una espera podría significar que la aplicación tiene que esperar a que se dibujen varios fotogramas previamente en cola antes de que se renderice el fotograma que está esperando.
glReadPixels no es el único comando que causa este tipo de dependencia. Si una aplicación quiere 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 plausiblemente lo que está sucediendo con Google Maps: si cada mosaico de mapa es una textura, podría estar reutilizando un mosaico antiguo fuera de la pantalla escribiendo un mosaico nuevo en él listo para Mostrar. Una vez que la aplicación ha puesto en cola un marco que no utiliza el mosaico antiguo, intenta escribir en esa textura, pero en realidad la textura todavía se utiliza para renderizar marcos previamente puestos en cola. La aplicación tiene que esperar hasta que esos fotogramas hayan terminado (y la GPU ya no esté leyendo la textura "no utilizada") antes de poder escribir.
En teoría, es posible que un hilo de trabajo escriba en la textura, lo que permite que el hilo principal siga poniendo en cola nuevos marcos sin problemas. Pero el modelo de hilo complejo de GL hace que sea muy difícil hacer algo como esto bien, y el hilo principal eventualmente tendría que esperar a que la carga de textura se complete de todos modos.
En cuanto a la aplicación de configuración, podría ser que el backend de Android GL está haciendo el mismo truco de reutilización de texturas para los iconos, pero eso es solo una suposición. Tal vez el Nexus Galaxy está utilizando un compositor 2D para hacer la composición del marco, lo que ahorra energía, pero a costa de la introducción de una espera en el controlador. No se si ese tipo de dependencia se medirá en el gráfico.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-08-12 11:32:04