Che cos'è "Scanline Racing"

Ho sentito un sacco di persone che lavorano su VR parlare delle corse di scanline e che dovrebbe aiutare a migliorare la latenza per il movimento da fotone a fotone. Tuttavia, non mi è chiaro come ciò possa essere fatto con OpenGL. Qualcuno potrebbe spiegare come funziona la scanline racing e come può essere implementato su GPU moderne.

Quando la GPU visualizza un nuovo frame sullo schermo, trasferisce l'immagine tramite il cavo HDMI (o qualsiasi altro tipo) in un processo chiamato "scanout". I pixel vengono inviati in ordine lineare, generalmente da sinistra a destra e dall'alto verso il basso. Il processo è programmato in modo tale da richiedere la maggior parte della durata di un intervallo di aggiornamento. Ad esempio, a 60Hz, un frame è ~ 17 ms. Ogni scanout richiederà probabilmente circa 15-16 ms, con 1-2 ms di vblank in mezzo (i valori esatti variano in base al display e alla modalità video).

Tradizionalmente, il rendering è a doppio buffer, il che significa che ci sono due buffer memorizzati nella memoria GPU: uno che è attualmente sottoposto a scansione ("buffer anteriore") e uno a cui viene eseguito il rendering ("buffer posteriore"). Ogni fotogramma, i due vengono scambiati. La GPU non esegue mai il rendering sullo stesso buffer che viene scansionato, il che impedisce artefatti a causa della potenziale visualizzazione di parti di un frame incompleto. Tuttavia, un effetto collaterale di ciò è l'aumento della latenza, poiché ogni frame può rimanere nel buffer per diversi ms prima che inizi la scansione.

La realtà virtuale è molto sensibile alla latenza, quindi non è desiderabile. Un approccio alternativo è il rendering diretto al buffer anteriore, ma il timeout delle cose con molta attenzione in modo da aver reso ogni riga dell'immagine poco prima che lo scanout arrivi lì. Si chiama "scanline racing" o "racing the beam" (il "fascio" che si rifà ai tempi di CRT di un tempo). Ciò richiede più o meno il rendering dell'immagine nell'ordine di scanline, ovvero nello stesso ordine di scansione dei pixel. Non deve essere letteralmente reso una riga alla volta: potrebbe essere reso in strisce sottili alte pochi pixel, ma deve essere fatto in ordine, poiché non è possibile tornare indietro e modificare i pixel che hanno già stato scansionato.

Ci sono molti svantaggi di questo approccio; ha requisiti di prestazione molto rigorosi, deve essere cronometrato con molta attenzione rispetto a vsync e complica notevolmente il processo di rendering. Ma in linea di principio può radere millisecondi dalla tua latenza, motivo per cui le persone VR sono interessate a questo.

Il bello è che possiamo finalmente prevedere la precisione raster della linea di scansione senza accesso a una query per linea di scansione:

https://www.youtube.com/watch?v=OZ7Loh830Ec

Ho elaborato le esatte formule accurate al microsecondo come offset VSYNC, per prevedere la posizione di una linea di lacrima. Le tearline durante VSYNC OFF sono sempre esatte per il raster, quindi è possibile evitarle dalla visibilità durante il "rendering simulato del buffer frontale" a livello di striscia tramite lo scambio ripetuto di buffer VSYNC OFF.

Presta attenzione al thread del forum: viene continuamente aggiunto del codice open source: https://forums.blurbusters.com/viewtopic.php?f=10&p=32002

Se è interessante, il Dreamcast ha una modalità di rendering "racing the beam", per cui è stato in grado di dedicare una frazione relativamente piccola di memoria ai pixel del framebuffer (ad esempio 64 linee di scansione) e renderebbe a sua volta righe di 32, sincronizzate con l'aggiornamento del display. Questo, tuttavia, è stato utilizzato solo per risparmiare memoria. Dubito che qualcuno stesse generando una geometria "modificata" per le ultime parti del display.