2. Tecnologie NVIDIA - Parte prima
Passiamo ora in rassegna le principali novità tecnologiche introdotte con la GPU Pascal, partendo dalle implementazioni effettuate nel silicio per arrivare alle nuove funzionalità software.
Enhanced Memory Compression
Come per le precedenti generazioni di GPU NVIDIA, sono state implementate tecniche di compressione per ridurre il consumo di banda passante, massimizzare le risorse a disposizione e minimizzare le scritture o i trasferimenti di dati tra le varie unità della pipeline di rendering e le porzioni di memoria della scheda.
L'algoritmo più critico è quello relativo al Delta Color Compression, ovvero la capacità della scheda di analizzare blocchi di pixel e differenziarli per colore memorizzando poi le informazioni colore solo per alcuni pixel di riferimento, mentre per i restanti vengono memorizzati solo i valori che li differenziano (delta) dai pixel di riferimento.
Naturalmente, se le differenze tra i pixel di riferimento e quelli vicini sono piccole saranno necessari solo pochi bit e quindi il risultato della compressione (il pacchetto dei pixel di riferimento più i valori di differenza) può avere dimensioni inferiori anche della metà rispetto a quello dei pixel con informazioni colore non compresse.
Se questo accade, l'algoritmo di Delta Color Compression ha svolto correttamente il suo lavoro e i dati possono essere immagazzinati in metà dello spazio, ovvero con un rapporto di compressione 2:1.
Quello che è stato fatto con Pascal è stato rivedere l'algoritmo di Delta Color Compression, giunto alla quarta generazione, rendendolo più efficiente ed introducendo anche nuove e più spinte modalità .
Per prima cosa, quindi, gli ingegneri NVIDIA hanno migliorato l'algoritmo in modo tale che risultasse efficiente molto più spesso garantendo il rapporto 2:1 nella maggior parte delle situazioni.
In seconda battuta è stata introdotta una nuova modalità di compressione 4:1 per gestire le situazioni in cui le differenze per pixel sono molto ridotte e risulta quindi possibile immagazzinare tutte le informazioni in un quarto dello spazio necessario ai dati non compressi.
In terza istanza, infine, è stata introdotta una modalità 8:1 che combina in maniera costante la modalità 4:1 su blocchi di 2x2 pixel che sono a loro volta compressi in modalità 2:1.
La slide rappresenta visivamente il funzionamento dell'algoritmo di Delta Color Compression di quarta generazione.
 Â |  Â |  Â |
Come "applicazione pratica" andiamo a visionare tre frame di un gioco ...
Le tre immagini di Project Cars ci fanno apprezzare i nuovi limiti raggiunti da questo algoritmo in confronto alla terza generazione implementata in Maxwell: dal frame non compresso vengono evidenziate in magenta le aree che possono essere compresse con Maxwell prima e con Pascal oggi: praticamente quasi tutto il frame.
A detta di NVIDIA questa quarta iterazione dell'algoritmo di Delta Color Compression consente un risparmio di bytes per frame che si traduce in un incremento di banda a disposizione o, se preferite, riduzione di banda utilizzata, di circa il 20%.
Questo dato, unito all'incremento di banda passante garantito dalle GDDR5X, ha portato NVIDIA a dichiarare un fattore 1.7X di incremento di banda passante disponibile per le nuove GPU Pascal GP104 rispetto alle soluzioni GM204.
Asynchronous Compute
Funzionalità introdotta con le librerie DirectX 12 su cui sia Microsoft che gli sviluppatori punteranno molto, soprattutto per i benefici in termini di opportunità di utilizzo dell'hardware, l'Async Compute permette l'esecuzione di task multipli indipendenti che concorrono alla generazione della scena finale.
Si tratta quindi di una tecnologia molto appetibile per gli sviluppatori dei moderni titoli con scenari molto complessi e carichi di lavoro sempre più elevati per la gestione della fisica e degli effetti audio svolti in GPU, il post processing dei frame e le operazioni specifiche per VR come l'Asyncronous Timewarp.
Pascal supporta ovviamente Async Compute, come da specifiche Microsoft, e introduce alcune migliorie per venire incontro ai possibili scenari generati dalla sovrapposizione di più task sulla GPU.
Task simultanei/sovrapposti
Data l'attuale potenza di calcolo delle moderne GPU è più che probabile che un singolo task, come ad esempio i calcoli della fisica di un oggetto che rotola sulla scena, non impieghi tutte le risorse a disposizione ed è quindi possibile fare eseguire alla stessa altri compiti sfruttandone le risorse rimaste libere.
Per gestire al meglio i compiti concorrenti Pascal introduce una funzionalità di bilanciamento dinamico dei carichi di lavoro in grado di gestire le risorse a disposizione allocandole autonomamente nella maniera più efficiente.
Nello specifico, i due task saranno eseguiti insieme e, se uno termina prima dell'altro, Pascal reindirizza automaticamente le risorse disponibili per l'esecuzione del task incompleto.
Si tratta indubbiamente di un notevole balzo in avanti rispetto alla modalità statica implementata in Maxwell, in cui era lo sviluppatore a dover decidere quante risorse allocare per ogni task con il rischio di "sprecare" potenza elaborativa in caso di errata valutazione dei tempi necessari ai carichi grafici e a quelli computazionali concorrenti.
Dalla slide vediamo la modalità statica di Maxwell e quella dinamica di Pascal: il processo grafico termina prima di quello computazionale ma, essendo il partizionamento di tipo statico, la parte di GPU dedicata va semplicemente in Idle costituendo quindi uno spreco di risorse.
In Pascal, invece, finito il task grafico la GPU reindirizza immediatamente tutte le risorse a quello computazionale: nessuna di queste viene sprecata ed entrambi i compiti sono portati a termine in un tempo inferiore.
Task time critical
Ci sono invece situazioni in cui la velocità di esecuzione è la chiave di tutto e la GPU deve saper gestire e "discernere" quali siano i compiti "time critical", che devono essere portati a termine prima di qualsiasi altro processo concorrente, e deve essere in grado di passare dall'uno all'altro nel minor tempo possibile.
La gestione di queste situazioni risulta estremamente importante in ambiente VR, sopratutto per il menzionato Asyncronous Timewarp (ATW).
Questo processo gestisce infatti la generazione di un frame intermedio, basato sul processo di rendering più recente della scheda con le opportune correzioni per la posizione della testa dell'utente, qualora il nostro dispositivo non fosse in grado di generare il frame corretto dopo il normale intervallo di refresh del display (11ms su uno schermo a 90Hz) evitando, quindi, un frame drop.
Risulta ovvio che per poter essere eseguito è necessario che la GPU riceva una richiesta da parte del processo, nello specifico una prelazione (preemption) delle risorse che ovviamente necessita di un tempo tecnico di esecuzione.
Tecnicamente anche Maxwell è in grado di gestire questo processo ma, dato che la preemption è qui implementata solo a livello di chiamata, è necessario che qualunque richiesta da parte di ATW sia inoltrata con "largo anticipo", situazione non ideale in quanto sarebbe bene che il processo entrasse in funzione il meno possibile e, nel caso, il più tardi possibile.
Per queste situazioni NVIDIA ha lavorato in maniera massiccia sugli algoritmi di prelazione aumentandone la granularità a livello di pixel e riducendone i tempi di latenza in modo tale da permettere alle GPU Pascal di interrompere i compiti meno "time critical", dando la priorità a quelli più critici in qualunque fase del processo di rendering.
A differenza quindi di una GPU tradizionale con preemption ad alto livello, Pascal non deve attendere che tutte queste operazioni finiscano prima di cambiare task.
Come si evince dall'immagine, Pascal, con la sua Pixel level preemption, può bloccare i processi di rendering in qualunque momento dato che è in grado di tenere traccia dei progressi fatti e poi riprenderli esattamente dove li aveva interrotti dopo aver soddisfatto una richiesta di prelazione più sensibile al tempo di esecuzione.
Lo stesso livello di granularità è stato applicato per i carichi di tipo computazionale come Thread Level Preemption.
I carichi computazionali sono costituiti da griglie contenenti blocchi di thread e, quando arriva una richiesta di prelazione, quelli in esecuzione negli SM vengono completati e la loro posizione salvata in modo tale che l'operazione possa riprendere appena soddisfatta la richiesta ricevuta.
Sempre sul lato dei carichi computazionali, per quello che concerne in particolare il calcolo CUDA, segnaliamo che Pascal introduce anche qui un ulteriore livello di granularità se confrontato con Maxwell (che era in grado soddisfare richieste di prelazione solo a livello di thread), potendo arrivare a livello di singola istruzione.
NVIDIA dichiara che l'intero processo di passaggio tra il task in corso e quello più "time critical" può essere effettuato in meno di 100 microsecondi dal termine della fase di shading del pixel in elaborazione o del thread in esecuzione al momento della chiamata.
Pascal, grazie alla combinazione del Pixel Level Preemption e del Thread Level Preemption, è in grado di cambiare workload molto velocemente e con un overhead minimo sulle richieste di prelazione.
Per tornare quindi al nostro esempio di ATW, ecco la differenza tra Maxwell e Pascal: a sinistra un'operazione ATW con una GPU di vecchia generazione e preemption ad alto livello, a destra la stessa operazione su Pascal che dispone di preemption altamente granulare.
Dato che nel primo caso il tempo di prelazione non è facilmente quantificabile e, quindi, non è certo quando il processo ATW partirà , è necessario inviare la richiesta con largo anticipo rubando del tempo al normale calcolo del frame, mentre, nel secondo caso, essendo molto più breve e facilmente quantificabile, i calcoli necessari per ATW possono essere inoltrati molto più tardi avendo comunque la sicurezza che siano completati prima del refresh del display in caso di necessità .
