Simultaneous Multi-Projection Engine
Sono diverse le parti di GP104 che influenzano le prestazioni dei giochi che testiamo - il maggior numero di core, la frequenza e il lavoro di Nvidia sulla memoria GDDR5X a 10 Gb/s. Altre caratteristiche non possono essere ancora dimostrate ma hanno grandi implicazioni per il futuro. Nondimeno, l'architettura Pascal integra diverse funzionalità che non vediamo l'ora di vedere implementate nei giochi.
La prima si chiama Simultaneous Multi-Projection Engine. Questa tecnologia è offerta tramite un blocco hardware aggiunto ai PolyMorph Engine di GP104. Questa soluzione logica prende il dato geometrico e lo processa tramite un massimo di 16 proiezioni da un solo punto di vista. Oppure può compensare il punto di vista per le applicazioni stereo, replicando la geometria fino a ben 32 volte in hardware e senza il costoso overhead prestazionale in cui s'incappa se si è tentati di ottenere lo stesso effetto senza SMP.
Cerchiamo comunque di riassumere e dare un po' di contesto. In Tom's Hardware giochiamo quasi esclusivamente su tre monitor in configurazione Surround. I nostri monitor sono inclinati verso l'interno per "avvolgerci". I giochi però non sanno tutto questo. Una strada di città che abbraccia tutti e tre i display si piega in presenza di ogni cornice, e il tavolo circolare nella zona periferica appare distorto. Il modo corretto di renderizzare per la nostra configurazione sarebbe una proiezione diretta davanti a noi, una seconda proiezione sulla sinistra (come se si guarda fuori da un abitacolo di un aereo) e una terza proiezione a destra, orientata in modo simile. La strada precedentemente piegata potrebbe così essere raddrizzata, e finiremmo con un campo visivo molto più ampio. L'intera scena deve essere ancora rasterizzata e ombreggiata, ma in questo modo si risparmia alla configurazione, al driver e al front-end della GPU di renderizzarla tre volte.
 |  |
Il problema è che un'applicazione deve supportare impostazioni FOV ampie e usare chiamate API SMP. Ciò significa che gli sviluppatori di giochi devono adottare questa funzione prima che possiate goderne. Non siamo sicuri di quale sforzo sarà necessario per soddisfare le poche persone che giocano in Surround, ma ci sono altre applicazioni in cui ha senso un'implementazione immediata.
Prendete la realtà virtuale, per esempio. Avete già di una proiezione per ogni occhio. Oggi i giochi renderizzano semplicemente verso due schermi separati, incappando nelle inefficienze citate pocanzi. Poiché SMP supporta un paio di centri di proiezione, entrambi si possono renderizzare in un solo passaggio usando una funzione che Nvidia chiama Single Pass Stereo. Il vertex processing avviene una volta e SMP restituisce due posizioni per ogni vertice corrispondente ai vostri occhi sinistro e destro. Da qui SMP può applicare ulteriori proiezioni per abilitare una caratteristica nota come Lens Matched Shading.
 |  |
In breve, Lens Matched Shading cerca di rendere la VR più efficiente, evitando molto del lavoro che di norma sarebbe richiesto per il rendering di una proiezione planare tradizionale, prima che questa sia piegata per adeguarsi alla distorsione delle lenti di un visore - sprecando così pixel dove la curva è più pronunciata. Usando SMP per dividere la regione dello schermo in quadranti, questo effetto può essere approssimato. Quindi anziché renderizzare una proiezione quadrata e manipolarla, la GPU crea immagini che si adattano al filtro di distorsione delle lenti. Questo impedisce di generare più pixel di quelli necessari. E fintanto gli sviluppatori possono pareggiare o superare il sampling rate dell'HMD richiesto per ogni occhio, non sarete in grado di trovare una differenza qualitativa. Nvidia ha detto che sta per rendere disponibile un SDK, quindi dovremo aspettare per vedere quanto si diffonderanno queste caratteristiche.
È possibile vedere prestazioni due volte maggiori in VR rispetto alle GPU senza supporto SMP combinando Single Pass Stereo e Lens Matched Shading. Parte di questo miglioramento è legato ai progressi con il pixel throughput - usando Lens Matched Shading per evitare di lavorare su pixel che non è necessario renderizzare, l'impostazione conservativa di Nvidia porta il carico di lavoro da 4,2 MPix/s (Oculus Rift) fino a 2,8 MPix/s, liberando una potenza di shading della GPU fino a 1,5 volte. Poi, processando la geometria una volta e spostandola nell'hardware (anziché rieffettuare tutto per il secondo occhio), Single Pass Stereo allevia in modo efficace metà del lavoro geometrico che è svolto in questo momento.
Asynchronous Compute
L'architettura Pascal integra alcuni cambiamenti legati ad Asynchronous Compute, una caratteristica a cui si lega il vantaggio delle precedenti architetture di AMD in DirectX 12 e VR.
Con l'architettura Maxwell Nvidia supportava un partizionamento statico della GPU per accogliere la sovrapposizione dei carichi di lavoro legati a grafica e calcolo. Teoricamente era un buon modo per massimizzare l'uso, fintanto che entrambi i segmenti erano attivi. Se mettete da parte il 75% del processore per la grafica e quel segmento entra in idle in attesa che il lato calcolo termini, potete bruciare qualsivoglia guadagno che potrebbe essere possibile facendo lavorare queste operazioni contemporaneamente. Pascal sistema questo problema con una forma dinamica di bilanciamento del carico. Le risorse della GPU possono ancora essere allocate, ma se il driver determina che una partizione è sottoutilizzata, permetterà all'altra di subentrare e terminare, impedendo uno stallo che impatti negativamente sulle prestazioni.
Nvidia ha migliorato anche le capacità preemption di Pascal - la possibilità d'interrompere un'operazione al fine di occuparsi di un carico più sensibile al tempo con una latenza molto bassa. Come sapete, le GPU sono "macchine" altamente parallele con grandi buffer pensati per mantenere queste risorse simili occupate una accanto all'altra. Uno shader inattivo non è per niente una buona cosa, quindi è necessario mettere in coda il lavoro tramite la pipeline grafica. Ma non tutto quello che fa una GPU, specialmente oggi, è così tollerante dei ritardi.
Un esempio perfetto è la funzione asynchronous timewarp che Oculus ha attivato al debutto del Rift. Nel caso in cui la vostra scheda video non riesca a riprodurre un nuovo frame ogni 11 ms su uno schermo a 90 Hz, ATW può generare un frame intermedio usando il lavoro più recente del thread di rendering, correggendo per la posizione della testa. Questo però richiede di avere un tempo sufficiente per creare un frame timewarped, e sfortunatamente la preemption (prelazione) grafica non è particolarmente granulare. Infatti le architetture Fermi, Kepler e Maxwell supportano la draw-level preemption, ossia può switchare solo ai confini delle chiamate, potenzialmente sostenendo ATW. Le richieste preemption devono perciò essere fatte prima, in modo da garantire controllo sulla GPU al fine di avere un frame warped prima che lo schermo esegua il refresh. Si tratta di un problema perché è desiderabile che ATW compia il suo lavoro il più tardi possibile, prima che avvenga quel refresh.
Pascal implementa una preemption a livello pixel più granulare per la grafica, quindi GP104 può bloccare ciò che sta facendo a livello pixel, salvare lo stato off-die della pipeline e cambiare contesto. Anziché una preemption nella classe dei millisecondi che abbiamo visto con Oculus, Nvidia parla di meno di 100µs.
L'architettura Maxwell supportava l'equivalente della preemption a livello pixel sul lato calcolo abilitando la granularità a livello thread. Anche Pascal offre questa funzionalità, ma aggiunge il supporto per la preemption a livello istruzione nelle operazioni di calcolo CUDA. I driver di Nvidia non includono tale funzionalità al momento, ma questa, insieme alla preemption a livello pixel, saranno accessibili a breve.