Comprendere la necessità dei segnali VSYNC Android

Question

Sto cercando di ottenere una migliore comprensione del sottosistema di display Android, ma un elemento che mi confonde ancora è come vengono gestiti i segnali VSYNC e perché esistono così tanti in primo luogo.

Android è progettato per utilizzare VSYNC nel suo nucleo, ma ci sono più segnali VSYNC che impiega. Via https://source.android.com/devices/graphics/implement.html nella sezione "VSYNC Offset", c'è un diagramma di flusso che illustra tre segnali VSYNC: HW_VSYNC_0, VSYNC e SF-VSYNC. Capisco che HW_VSYNC sia usato per aggiornare i tempi in DispSync e che VSYNC e SF-VSYNC siano utilizzati dalle app e dal surfaceflinger, ma perché sono necessari questi segnali individuali? Inoltre, in che modo le compensazioni influiscono su questi segnali? C'è un diagramma di temporizzazione disponibile ovunque che spieghi meglio questo?

Grazie per l'aiuto che puoi offrire.

Answer 1

Per comprendere queste cose, è meglio iniziare con il documento System-Level Graphics Architecture, prestando particolare attenzione alle La necessità di Triple-buffer sezione e il diagramma associato (che idealmente sarebbe una GIF animata). La frase che inizia, "Se l'app inizia a eseguire il rendering a metà strada tra i segnali VSYNC", parla specificamente di DispSync. Una volta letto questo, si spera che la sezione DispSync del doc di grafica del dispositivo abbia più senso.

La maggior parte dei dispositivi non dispone di offset DispSync configurati, quindi c'è davvero solo un segnale VSYNC. In quanto segue presumo che DispSync sia abilitato.

L'hardware fornisce solo un segnale VSYNC, corrispondente all'aggiornamento del display principale. Gli altri sono generati nel software dal codice DispSync di SurfaceFlinger, sparando a offset fissi dall'attuale VSYNC. Alcuni software intelligenti vengono utilizzati per impedire che i tempi scivolino fuori fase.

I segnali vengono utilizzati per attivare la composizione di SurfaceFlinger e il rendering dell'app. Se segui la sezione nel documento di architettura, puoi vedere che questo stabilisce due frame di latenza tra quando l'app esegue il rendering del suo contenuto e quando il contenuto viene visualizzato sullo schermo. Pensalo in questo modo: date tre occorrenze di VSYNC, l'app disegna su V0, il sistema esegue la composizione su V1 e il frame composto viene inviato al display su V2.

Se si sta tentando di tenere traccia dell'input tattile, magari spostando una mappa intorno al dito dell'utente, qualsiasi latenza verrà vista dall'utente come risposta al tocco lenta. L'obiettivo è ridurre al minimo la latenza per migliorare l'esperienza dell'utente. Supponiamo di ritardare leggermente gli eventi, quindi l'app si disegna su V0.5, ci si compone sulla V1.2, e poi si passa al display in V2. Compensando l'app e l'attività SF riduciamo la latenza totale da 2 fotogrammi a 1,5, come mostrato di seguito.

Questo è ciò che è per DispSync. Nel diagramma di feedback sulla pagina che hai collegato, HW_VSYNC_0 è l'aggiornamento hardware per il display fisico, VSYNC fa sì che l'app esegua il rendering e SF_VSYNC fa sì che SurfaceFlinger esegua la composizione. Riferirsi a loro come "VSYNC" è un po 'improprio, ma su un pannello LCD che si riferisce a qualcosa come "VSYNC" è probabilmente un termine improprio.

I "timestamp di recesso" annotati nel diagramma del circuito di retroazione si riferiscono ad un'ottimizzazione intelligente. Dal momento che non stiamo lavorando sul VSYNC hardware attuale, possiamo essere leggermente più efficienti se disattiviamo il segnale di aggiornamento. Il codice DispSync userà invece i timestamp ritirati dalle recinzioni (che è un'intera discussione di altri) per vedere se non sta andando fuori sincrono e riabiliterà temporaneamente il segnale hardware finché non sarà di nuovo in pista.

Modifica: è possibile vedere come i valori sono configurati nello Nexus 5 boardconfig. Notare le impostazioni per VSYNC_EVENT_PHASE_OFFSET_NS e SF_VSYNC_EVENT_PHASE_OFFSET_NS.