DLSS 3 Frame Generation: Inventare Frame

Optical flow + motion vector + una rete neurale che produce un frame mai renderizzato.

Tutto fino a questo punto è stato sulla ricostruzione di pixel da campioni sparsi. La DLSS 3 Frame Generation fa qualcosa di fondamentalmente diverso: ricostruisce interi frame che il renderer non ha mai disegnato. L'output di un gioco che gira con Frame Generation a "240 FPS" ha in realtà il renderer che produce 120 frame reali al secondo; gli altri 120 sono interpolati dalla GPU tra di loro.

È un'idea più radicale dell'upscaling, e ha modi di fallire più interessanti. Vediamo esattamente cosa succede.

Il setup

La DLSS 3 Frame Generation è costruita sopra DLSS Super Resolution. La pipeline per ogni frame renderizzato è così:

Il motore renderizza il frame N a risoluzione interna, con jitter, con motion vector. Come prima.
DLSS Super Resolution fa upscaling del frame N alla risoluzione di output. Abbiamo un frame N reale, ad alta risoluzione.
La Frame Generation tiene frame N e frame N+1 (anch'esso renderizzato e upscaled), fa girare l'optical flow accelerator sulla coppia, fonde con i motion vector e sintetizza un frame generato N.5 tra loro.
La sequenza di display diventa: N → N.5 (generato) → N+1 → N+1.5 (generato) → N+2 → …

Nota che questo significa che la Frame Generation ritarda sempre il display di almeno un frame renderizzato. Per produrre N.5 devi già avere N+1. Il gioco non può mostrare N.5 prima di aver renderizzato N+1. Torneremo su questo costo di latenza in un capitolo successivo, perché è il trade-off centrale dell'intera tecnica.

Timeline orizzontale che mostra l'ordine di render rispetto a quello di display. Riga superiore 'Rendered frames': N, N+1, N+2, N+3 con gap regolari tra loro. Riga inferiore 'Displayed frames': N, gen, N+1, gen, N+2, gen, N+3 densità doppia. Le frecce mostrano che ogni frame generato dipende dai due frame renderizzati adiacenti. Caption 'FG doubles displayed frames but delays each by one render interval'. Infografica tecnica pulita. — Ogni frame generato dipende dal prossimo frame renderizzato per questo FG ritarda sempre il display di un intervallo di render.

Le due sorgenti di motion

Produrre il frame generato è, in sostanza, un problema di interpolazione consapevole del movimento: dati due frame e il movimento tra loro, dipingi il frame intermedio. DLSS 3 usa due sorgenti di motion, fuse:

Motion vector del motore

Come per Super Resolution. Accurati per camera e movimento rigido. Ciechi alle ombre, riflessioni, rifrazioni, highlight speculari e (spesso) particelle. Sono i motion vector che ci sono sempre stati nei motori moderni.

Optical flow

Una tecnica di computer vision che prende due immagini e calcola, per pixel, il movimento apparente tra loro solo dai valori dei pixel, senza alcuna conoscenza di cosa c'è nella scena. L'optical flow classico è in giro dagli anni '80 (Horn–Schunck, Lucas–Kanade). Le varianti moderne sono basate su deep learning.

Le GPU NVIDIA Ada e Blackwell hanno un Optical Flow Accelerator (OFA) a funzione fissa che produce un campo di optical flow denso tra due frame high-res in ben meno di un millisecondo. L'OFA non era nuovo su Ada Turing l'aveva già ma su Ada la sua precisione e qualità sono state drasticamente aumentate specificamente per rendere possibile la Frame Generation.

Diagramma a due input e un output. Input superiore 'Engine motion vectors': pulito per personaggio e camera, zero per ombre e riflessi. Input inferiore 'Hardware optical flow': denso, cattura tutto ciò che si muove visivamente, comprese ombre, riflessi e fuoco. Entrambi confluiscono in un blocco 'Fusion Network' che produce un singolo campo di motion completo. Evidenzia aree specifiche dove ciascuna sorgente contribuisce in modo unico. Diagramma tecnico pulito. — I motion vector del motore gestiscono la geometria rigida; l'optical flow hardware gestisce ombre, riflessioni e particelle.

Perché entrambi, non uno solo

I motion vector del motore sono accurati ma incompleti; l'optical flow è completo ma ambiguo (regioni uniformi non hanno flow rilevabile; pattern ripetitivi lo confondono; il movimento sub-pixel è rumoroso). Fonderli dà:

MV del motore dove è sicuro (oggetti rigidi, camera).
Optical flow dove i MV del motore sono ciechi (ombre, riflessioni, speculari, particelle).
Una funzione di blending appresa che sa quando ogni sorgente è affidabile.

Senza optical flow, i frame generati nei giochi path-traced avrebbero ombre fantasma dietro ogni oggetto in movimento un deal-breaker. Con esso, le ombre generalmente si muovono correttamente anche se nessun motion vector del motore le ha mai descritte.

La rete di interpolazione

Una volta disponibile il campo di motion fuso, una seconda rete neurale fa la sintesi vera e propria del frame. Prende:

Frame N (high-res).
Frame N+1 (high-res).
Il campo di motion fuso.
Una maschera di confidenza che descrive dove il campo di motion è affidabile.
(Opzionale) segnali extra: depth da N e N+1, il G-buffer.

E produce il frame N.5 così:

Warpa sia N che N+1 verso il punto a metà strada nel tempo, usando il campo di motion.
Mescola le due immagini warped, con i pesi di blending controllati dalla maschera di confidenza.
Riempie i buchi di disocclusion regioni visibili in solo uno dei due frame reali ma non nell'altro usando contesto dal lato visibile.

Questa è, in termini di image processing, motion-compensated frame interpolation una tecnica che esiste da decenni negli upscaler TV e nei codec ma con reti neurali addestrate specificamente su contenuti di gioco, e con dati di geometria forniti dal motore come input aggiuntivo. Quell'input extra è ciò che la rende drasticamente migliore dell'interpolazione economica nella tua TV.

Diagramma che mostra due frame reali (N e N+1) che entrano in una rete neurale 'warp + blend + inpaint' da sinistra e destra, con un campo di motion fuso che entra dall'alto. L'output è un singolo frame interpolato N.5 al centro. Un piccolo inset mostra una 'disocclusion mask' dove la rete deve inventare contenuto. Infografica tecnica pulita, accenti verde neon in stile NVIDIA. — Due frame reali warpati verso il punto intermedio, mescolati per confidenza, con la rete che inpainta le regioni di disocclusion.

Il problema della UI

La UI del gioco è renderizzata alla fine del frame ed è statica a livello di pixel tra i frame una barra della vita nella stessa posizione sullo schermo sia in N che in N+1. I motion vector del motore per la UI sono zero per definizione.

Quindi se interpoli ingenuamente, la UI sembra OK solo che non si muove. Bene.

Il problema è quando la UI è animata (un contatore numerico che ticchetta, un mirino animato, un effetto di screen-shake). Allora i MV del motore sono zero ma i valori dei pixel cambiano tra i frame. L'optical flow ne cattura una parte, ma il risultato può comunque essere visibilmente sbagliato: testo che ghostha, elementi HUD raddoppiati, mirini sbavati.

Per questo le prime implementazioni di DLSS 3 avevano UI visibilmente rotte in molti giochi. Il fix è o:

Comporre la UI dopo la Frame Generation. Renderizza il mondo, genera frame, poi disegna la UI su ogni frame visualizzato. Ora la UI viene renderizzata a piena FPS e non è mai interpolata. È la risposta giusta, ed è il percorso di integrazione moderno.
Dire a DLSS quali regioni sono UI via una maschera, così la rete può semplicemente farle passare.

Diagramma con due opzioni mostrate fianco a fianco. A sinistra 'UI baked into rendered frame': gli elementi UI ghostano visibilmente nel frame interpolato, marcati con indicatori rossi di problema. A destra 'UI composited after FG': UI pulita su ogni frame mostrato, marcata con checkmark verdi. Una caption spiega la differenza. Comparazione tecnica pulita. — Componi la UI dopo la Frame Generation, non prima l'unico modo per mantenere puliti gli elementi animati dell'HUD.

Perché DLSS 3 richiede Ada (e DLSS 4 no)

DLSS 3 è uscito gated alle GeForce RTX serie 40 (Ada) e successive. La ragione dichiarata di NVIDIA: solo l'OFA ridisegnato di Ada era abbastanza preciso da produrre flow convincenti. Gli scettici hanno sostenuto che fosse un gate di marketing; le persone che hanno provato a farlo girare su Turing/Ampere via hack hanno confermato che l'OFA più vecchio produceva optical flow visibilmente peggiori, con riflessi sbavati e interpolazione di particelle scorretta.

DLSS 4 ha cambiato la matematica. Il nuovo modello transformer-based di Frame Generation dipende meno dall'OFA hardware e usa più componenti appresi, quindi la multi-frame generation è diventata fattibile su una base hardware più ampia anche se NVIDIA gata comunque la variante multi-frame alle RTX serie 50 Blackwell. Quel gate è più difficile da difendere su basi puramente tecniche.

Cosa costa

Il pass di Frame Generation OFA + rete di interpolazione + fusione dei motion vector prende all'incirca 2–3 ms su una RTX 4090 in 4K. Aggiungi il costo di DLSS Super Resolution (~1 ms) e hai un overhead DLSS per frame di circa 3–4 ms.

Sembra poco. Ma: poiché la Frame Generation mostra il frame interpolato tra due frame renderizzati, "recuperi" il costo solo se il frame rate renderizzato è abbastanza alto perché i frame extra di display valgano il loro costo di latenza. Sul lato pratico, FG comincia a sembrare orribile sotto i 40 FPS renderizzati, fluido intorno ai 60+, ed eccellente sopra gli 80. Vedremo perché nel capitolo sulla latenza.

Grafico a barre impilate che mostra il breakdown di tempo GPU per un frame renderizzato e uno generato. Il frame renderizzato include G-buffer, shading, RT, denoiser, DLSS-SR e post-processing. Il frame generato include optical flow accelerator, fusione dei MV e rete di interpolazione. La barra del frame generato è alta circa 3 ms contro 12 ms del frame renderizzato. Chiaramente etichettato. Infografica tecnica pulita. — Una RTX 4090 spende circa 3 ms per frame generato contro 12 ms per uno renderizzato la matematica funziona solo se il renderer è veloce.

Prossimo: come DLSS 4 ha portato questa idea alla sua conclusione logica generando tre frame tra ogni coppia di frame reali.