Android 4.3 su schermo GPU profiling - lungo gfx tempo

Question

di attesa ho appena aggiornato un Galaxy Nexus a 4,3 e ha permesso la nuova funzione GPU profiling su schermo, e vedere il seguente risultato schermata di configurazione Android:

Secondo il platform highlights:

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

Anche su uno schermo molto semplice, ci sono molti casi che il tempo di aggiornamento dello schermo è superiore alla soglia per un liscio 60 fps (linea verde), ed è in gran parte beca uso ci sono molti casi in cui un aggiornamento passerebbe un tempo significativo in attesa del completamento dei comandi (linea gialla *), mentre altre volte questo passaggio è quasi istantaneo. Anche questo non è qualcosa di particolare nell'app Impostazioni, ma sembra che sia presente per tutte le app che ho provato finora. * sembra più arancione che giallo a me

Ciò che mi preme sapere sono:

1. È questo il tempo trascorso "in attesa di comandi per completare" significa che i comandi dello schermo sono attivamente processo e quindi la il tempo rappresenterebbe con precisione il tempo trascorso a disegnare lo schermo. O questa volta include il tempo di attesa per la sincronizzazione video (anche se penso che il buffer triplo verrà utilizzato per rimuovere questo requisito)?
2. Il tempo trascorso "in attesa dei comandi per completare" fluttuerebbe selvaggiamente anche quando si disegna lo stesso schermo (scorrere leggermente su & sullo stesso ScrollView), c'è qualche indicazione su come ridurre questa fluttuazione (o se potrebbe essere ridotto del tutto)?

[Edit:]

Aggiornato Nexus 7 come pure, ed è ancora peggio:

ben 5 fotogrammi vengono saltati "in attesa che i comandi per completo "e ha mostrato davvero nell'uso, l'app era molto mossa e non rispondente.

[Edit 2:] ho eseguito questi per this article per innescare TRIM per ~ 3 giorni, in modo che il N7 dovrebbe essere il più "puro", come si sta per arrivare a corto di un reset di fabbrica.

• Il dispositivo è stato inattivo per oltre un'ora
• n inattivo evento finestra di manutenzione è stata eseguita nelle ultime 24 ore
• Il dispositivo è o alimentazione con batteria 30 per cento o ha batteria 80 per cento

Ora Google Maps sembra comportarsi un po 'meglio (vedi sotto), quindi alcuni dei problemi potrebbero essere legati alla velocità di accesso flash anche se non so come.

Eppure, dal momento che il Galaxy Nexus è reset di fabbrica, la sua lunga "in attesa di comandi per completare" il tempo non può essere correlato alla mancanza di comando TRIM, e seguendo la procedura di cui sopra in effetti didn' t produrre miglioramenti. Quindi siamo di nuovo al punto di partenza ...

Answer 1

"L'attesa dei comandi da completare" indica che ci sono delle dipendenze sui frame renderizzati. Ad esempio, l'app potrebbe utilizzare glReadPixels per leggere dalla cornice renderizzata. Ciò significa che dopo che il frame è stato inviato alla GPU per il rendering, l'app è bloccata fino al termine del rendering di quel frame (mentre normalmente sarebbe in grado di continuare immediatamente). Android cerca di lasciare che l'app acceda quanti più comandi di rendering possibili, quindi improvvisamente introdurre un'attesa potrebbe significare che l'app deve attendere che vengano disegnati più fotogrammi in coda prima che il frame che sta aspettando venga reso.

glReadPixels non è l'unico comando che causa questo tipo di dipendenza. Se un'app desidera scrivere su una trama attualmente in uso, deve attendere che tutti i fotogrammi dipendenti dalla trama siano terminati. Questo è plausibilmente quello che sta succedendo con Google Maps: se ogni tessera mappa è una trama, potrebbe riutilizzare una vecchia tessera fuori schermo scrivendo una nuova tessera in essa pronta per essere mostrata. Una volta che l'app ha messo in coda un frame che non usa il vecchio tile, tenta di scrivere in quella texture, ma in realtà la texture è ancora in uso per il rendering di frame precedentemente accodati. L'app deve attendere fino a quando quei fotogrammi sono finiti (e la GPU non sta più leggendo dalla trama 'inutilizzata) prima che possa scrivere.

In teoria, è possibile scrivere una trama di lavoro sulla trama, consentendo al thread principale di accodare i nuovi frame senza problemi. Ma il complesso modello di thread di GL rende molto difficile ottenere qualcosa del genere giusto, e il thread principale dovrebbe attendere il completamento del caricamento della trama.

Per quanto riguarda l'app Impostazioni, potrebbe essere che il backend GL di Android stia facendo lo stesso trucco di riutilizzo delle texture per le icone, ma è solo un'ipotesi. Forse il Galaxy Nexus sta usando un compositore 2D per fare la composizione del frame, il che risparmia energia ma al costo di introdurre un'attesa nel driver. Non so se quel tipo di dipendenza verrebbe misurato nel grafico.