Asynchronous TimeWarp: cos'è, come migliora la VR e quali sono le sue limitazioni

[Redazione di Hardware Upg]

Link all'Articolo: http://www.hwupgrade.it/articoli/skv...oni_index.html

La VR ha comportato una serie di problematiche per le modalità di rendering delle immagini, specificamente in termini di adattamento rispetto ai movimenti della testa dell'utente. Oculus ha studiato in dettaglio il fenomeno.

Click sul link per visualizzare l'articolo.

[lucusta]

...e cosi' si capisce chiaramente che il Simultaneous Multi-Projection Engine di Pascal non serve poi a granche, se usi piu' di un asse di traslazione, e quindi che l'1.5X nel Pixel throughput ed il 2x nel geometry throughput si vanno a perdere immediatamente.
che le pipeline lunghe a 32 stadi sono ancora troppo lunghe rispetto alle 16 stadi di Polaris e alle 4 stadi di Fuji e che quindi il preemption diventa piu' difficoltoso.
che ACE e AC hanno un senso pratico in almeno questa applicazione...

ecco, la differenza nel farsi convincere delle cose rispetto a capirle realmente.
buone DX12 a tutti.

[Blake86]

Originariamente inviato da lucusta

...e cosi' si capisce chiaramente che il Simultaneous Multi-Projection Engine di Pascal non serve poi a granche, se usi piu' di un asse di traslazione, e quindi che l'1.5X nel Pixel throughput ed il 2x nel geometry throughput si vanno a perdere immediatamente.
che le pipeline lunghe a 32 stadi sono ancora troppo lunghe rispetto alle 16 stadi di Polaris e alle 4 stadi di Fuji e che quindi il preemption diventa piu' difficoltoso.
che ACE e AC hanno un senso pratico in almeno questa applicazione...

ecco, la differenza nel farsi convincere delle cose rispetto a capirle realmente.
buone DX12 a tutti.

Non ho capito la questione delle pipeline, puoi spiegarni meglio?

[lucusta]

dovrei scriverti un papiro...
sai come funziona una pipeline?
conta che maxwell e' efficiente e veloce perche' la sua pipeline di calcolo riesce a trattare una matrice a 3 variabili tutta di fila.
sono 64 step di calcolo, senza interruzioni.
questo modo di operare e' pero' deleterio se la matrice e' di entita' inferiore (o se la interrompi, la metti da parte, e poi la riprendi, perche' aspetti altri dati).
se fai 36 step e poi il calcolo si deve fermare sei comunque costretto a fare tutti i 64 step, indifferentemente; da 36 a 64 sono cicli vuoti di calcolo.
arrivati alla fine della pipeline devi fare le 2 canoniche azioni, ossia metterle nei registri e in caches (o riveicolare il dato in altra unita').
Pascal non ha null'altro che pipeline da 32 step.
in DX11 conviene sempre produrre matrici da 64 step, che servono per trovare le coordinate di un punto in traslazione (cambiamento di base).
sei limitato dal fatto di poter procede con solo 4 calcoli all'unisono (ed e' anche il motivo per cui e' inutile avere oltre un quad core), e se li incominci a spezzettare, diventa complicato, anche perche' devi mantenere l'identificativo dell'informazione e dello step di calcolo.
Pascal in Dx11 per fare un cambiamento di base prima si fa' una passata da 32, poi mette nei reg e ripassa ad un'altra unita' libera per fare gli altri 2 (piu' le 2 canoniche operazioni finali).
quindi perde almeno 2 cicli per fare la stessa cosa di maxwell (ma ha un clock 1,5 volte superiore per una perdita di IPC di 66/68... il 3%).
in altri frangenti la sua "mezza pipeline" garantisce la non esecuzione di cicli a vuoto, quindi hai un netto vantaggio (la prelazione di calcolo e' presente anche in DX11, ma non ha un effettivo senso utile).
in DX12 puoi operare matrici da 32 step senza perdita di calcolo (quando maxwell si troverebbe in difficolta').
d'altra parte AMD ha avuto per lungo tempo sub pipeline da 4 step.
per fare una 64 step doveva sommare 16 sub pipeline e quindi anche 2 cicli a vuoto per rimettere in calcolo in un'altra unita' libera.
questo costa 96 step in DX11 (16 x 4 step = 64 step attivi + 16 x 2 step vuoti = 32 step non utili al calcolo. totale 96).
in DX12 vanno molto di piu' a seconda della frammentazione di codice.
se il codice e a molto frammentato, come matrice, a netti vantaggi operativi.
Polaris ha unita' da 16 step, ma ha un'architettura che gli consente di poter eseguire un calcolo a 4 step aggiungendo i canonici 2 cicli, ma anche di eseguire matrici da 16, 32, 48, 64 e 72 step aggiungendo un ciclo vuoto ogni 16 (in effetti ancora non e' chiaro se aggiunge un ciclo vuoto o no, in quanto e' un processo diagonalizzato sul rast delle unita', mentre fino ad oggi era o colonne o righe... fatto sta' che risparmia molto in confronto a GCN gen3).
quindi Polaris puo' giocare bene sia in DX11 che DX12.
la tecnica di peemption e' praticamente la base di AC... e qui puoi interrompere il ciclo di calcolo dal 4° a multipli di 4.
maxwel non ha prelazione;
Pascal a prelazione a 32 stadi.
AMD generalizzata a 4 step.

quello che fa' pascal in VR e' di usare una semimatrice da 32 step per la prima coordinata del cambio di base, per poi mandarla al SMP e dividere in calcolo in 2 filoni, in cui poi si potra' ottenere le altre 2 variabili, pero' per 2 visuali differenti; una per occhio.
facendo cosi' hai 2 opzioni, una leggere ed una profonda.
la leggera e' che fai una divisione di calcolo e basta, e ti fai 32 step per tutte e due le visuali, mandi a SMP, dividi il calcolo e fai gli altri 32 step per 2 filoni di calcolo differenti.
facendo cosi' pero' leghi il grado di liberta' ad un solo asse.
il risultato e che puoi girare la testa a destra e sinistra, ma non in alto e basso o peggio ancora in diagonale.
l'altra e' che fai la prima passata da 32, vai in smp, dividi in 2 il calcolo e fai altri 16 step (piu' 16 a vuoto per uscire dalla pipeline), e poi questi nuovamente in altri 2 calcoli da 16 step (piu' 16 step per uscire dalla pipeline). generi cosi' 6 passaggi nelle pipeline da 32 e hai tutti i gradi di liberta' (nell'altro caso ne generi solo 3, ma ad un solo grado di liberta').
da qui i fantomatici guadagni in VR prodotti da nvidia.
6 matrici contro 3 sono un x2 (ma non ti dicono che hai i vincoli di visuale).
le matrici che puo' eseguire polaris, invece, sono direttamente da 72 step, quindi le puo' tranquillamente eseguire indipendentemente.
nella peggiore ipotesi dovrai ramificare il dato, ma tanto hai pipeline da 16, quindi non hai cicli vuoti.
questo approccio diventa utile nel momento in cui hai 2 schede video, una per visuale.
nvidia non puo' perare questa divisione nel momento in cui usa SMP (produrrebbe un overhead assurdo).

l'architettura di AMD e' per un intenso uso di HSA, e li' i calcoli sono generalmente corti, ma molto intensi.

avere una pipeline da 64 step, con il registro solo alla fine, comporta che hai anche molti meno registi in totale sul die, e sono spazio.
un die hawaii, fugi, tonga o pitcrain hanno un registro ogni 4 step, una sub pipeline; ti ci vogliono 16 pipeline per fare una da 64; basta che conti le ROPs per capire quanti registri in piu' ha sempre avuto ma mai sfruttati adeguatamente in DX11.
da qui il consumo e le prestazioni e dimensione die.
in DX12 pero' le cose cambiano un po' e non conviene programmare un VR senza usare questa tecnologia, perche' senno' dovresti avere propriamente 2 maxwell da gestire, uno per occhio... ma anche cosi' non avrebbe proprieta' tipiche di DX12 quando sei nel 3D normale, con una sola visuale, e quindi perderebbe il confronto miseramente, gia' con Pascal.

all'una di notte non credo che possa essere un discorso facile da digerire.
spero che tu abbia compreso almeno a grandi linee..


essenzialmente nvidia ti dona un'architettura ottima al momento, ma poco espressiva in ottica futura, mentre le AMD maturano solo perche' la tecnologia cammina verso un approccio di elevata parallelizzazione.
questo e' dovuto al fatto che i limiti imposti in DX11 sono essenzialmente quelli di poter produrre al massimo 4 calcoli all'unisono, per evitare anche di usare i registri id dei singoli sub calcoli.
ma 4 calcoli girano bene su un quad core, e questo e' limitato in frequenza; se ti serve computazione non puoi ottenerla, perche' non esistono quad core a 6ghz, e non conviene farli.
conviene invece aggiungere core, con tutto quello che ne consegue (DX12, ACE, AC e architettura HW della GPU).

i giochi diventano pesanti?
per farli girare dovranno usare le DX12, perche' dovranno puntare a multicore sopra i quad core.
i giochi raddoppiano il computo perche' diventano VR... stesso ordine.
quindi nei prossimi 2 anni vedrai sempre piu' giochi nascere sulle DX12, per questioni di puro computo CPU e per il VR (che poi a rimetterli con i vincoli DX11 non ci vuole tanto; e' difficile dividere, non accorpare i threads).

poi ci sono i trucchetti, come quello di farti usare il VR come se avessi un collare al collo... ma sono altre considerazioni.

con l'HW AMD non c'e' nemmeno necessita' di dare un nome a SMP... lo potevano implementare da GNC gen1 (e forse, a cercare bene, lo hanno anche fatto).

[Nenco]

Originariamente inviato da lucusta

dovrei scriverti un papiro...

Beh alla fine lo hai fatto, però complimenti

[Blake86]

Mamma mia, si, nn è facile da digerire ma penso di aver colto i concetti importanti, ti ringrazio

[Noir79]

Come hai raggiunto questo livello di conoscenza dell'architettura software dei driver di una scheda grafica? É solo per hobby o combacia parzialmente con il tuo lavoro?

[lucusta]

lavoro nel campo chimico, ma per hobby faccio ingegneria informatica.
la matrici non si usano solo nei giochi, ed oggi, ormai, l'informatica e' la base di ogni scienza applicata.
sapere come finzionano le cose aiuta sempre...

[OttoVon]

Grazie, post da incorniciare.

Quindi il mio i5 comincerà ad arrancare.

[lucusta]

ad oggi? con qualche cosa di nuova generazione superiore ad una 1070 (ergo solo 1080).
prossimamente, con i giochi in DX12? qualcosa in piu' sarebbe meglio.
se avevi un dual core era un problema, quindi fate attenzione a cosa vi mettono dentro i portatili, i piu' semsibili da questo punto di vista.