Streaming Multiprocessors
Nonostante il loro numero superiore, ogni multiprocessore è stato ottimizzato. La prima ottimizzazione è il numero superiore di thread gestibili da ogni multiprocessore - da 768 a 1024 (da 24 32-thread warps a 32). Un maggior numero di thread è molto utile per mascherare la latenza delle operazioni texture. In totale la GPU aumenta il numero di thread attivi da 12288 a 30720.
Il numero di registri per multiprocessore è duplicato - da 8192 registri a 16384. In concomitanza con l'incremento del numero di thread, il numero di registri utilizzabili simultaneamente da ogni thread passa da 10 a 16. Con il G8x/G9x, il nostro algoritmo di test usa il 67% delle unità di processo; con il GT200 usa il 100%. Combinato con due unità texture, le prestazioni dovrebbero essere sostanzialmente più elevate rispetto a quelle del G80 che abbiamo usato per la prova. Sfortunatamente, CUDA 2.0 necessita un driver ancora in versione beta, che non riconosce la GeForce GTX 200.
Questo non è l'unico miglioramento apportato ai multiprocessori: Nvidia ha annunciato alcune ottimizzazioni in modalità dual-issue. Ricordiamo che sin dal G80, i multiprocessori avrebbero dovuto eseguire due istruzioni per ciclo: una MAD e un floating MUL. Abbiamo usato il condizionale perché in quel momento non siamo stati in grado di testare questa situazione con dei test sintetici - non sappiamo se per limitazione dell'hardware o dei driver. Molti mesi dopo e molte versioni driver dopo, sappiamo che tale tipologia di istruzione non è semplice da isolare sul G80, il che ci lascia immaginare che il problema è da ricondurre a livello hardware.
Ma come opera la modalità dual-issue? Ai tempi del G80 nVidia non ha fornito dettagli, tuttavia, studiando i brevetti, ora sappiamo di più sul modo in cui le istruzioni sono eseguite dai multiprocessori. Prima di tutto, il brevetto specifica che i multiprocessori possono eseguire una singola istruzione per ogni ciclo di GPU. Quindi, dov'è questa famosa modalità dual-issue? Si tratta di una specificità dell'hardware: un'istruzione usa due cicli GPU (quattro cicli ALU) per essere eseguita su un warp (32 thread eseguita da un'unità SIMD 8-way), ma il front end del multiprocessore può lanciare l'esecuzione di un istruzione in ogni ciclo, a patto che le istruzioni siano di tipo differente: MAD in un caso, SFU nell'altro.
Assieme a operazioni trascendentali e interpolazioni di valori di ogni vertex, la SFU è in grado di eseguire una moltiplicazione floating-point. Per alternare l'esecuzione di istruzioni MAD e MUL, c'è un overlap della durata delle istruzioni. In questo modo, ogni ciclo di GPU produce un risultato di un MAD o MUL su un warp - 32 valori scalari. Se dalla descrizione di Nvidia possiamo aspettarci di avere il risultato di un MAD e un MUL ogni due cicli di GPU, in pratica, il risultato è lo stesso, ma da un punto di vista hardware il processo è semplificato, e permette di gestire l'esecuzione delle istruzioni a ogni ciclo.
Quello che limitava le G8X/G9X in questo contesto è stato corretto con il GT200? Nvidia, sfortunatamente, non lo specifica. Semplicemente dice che hanno lavorato sull'allocazione dei registri, lo scheduling e il lancio delle istruzioni.
Ora vediamo se questi cambiamenti hanno, in pratica, migliorato la situazione con un test sintetico - GPUBench.
Per offrire un confronto, abbiamo aggiunto al grafico i risultati ottenuti con una 9800 GTX. Questa volta la situazione è chiara; potete vedere il maggior numero di istruzioni MUL rispetto a quelle MAD. Ma siamo ancora lontani dal vedere i valori duplicati, con un guadagno del 32% rispetto al valore delle istruzioni MAD. Dobbiamo anche tenere in considerazione i risultati DP3 o DP4, poiché sono inconsistenti. La stessa cosa vale per le istruzioni POW, risultato molto probabilmente da imputare ai driver.
L'ultimo cambiamento apportato agli Streaming Multiprocessor è il supporto per la doppia precisione (numeri floating-point a 64 bit anzichè 32). Cerchiamo di chiarire: l'addizionale precisione è solo moderatamente utile per gli algoritmi grafici. Tuttavia, come sappiamo, il fattore GPGPU sta diventando più importante per nVidia e, per le applicazioni scientifiche, la doppia precisione è una necessità non negoziabile.
Nvidia non è la prima a considerare questo fattore. IBM ha recentemente modificato il suo processore Cell per incrementare le prestazioni dell'SPU per questo tipo di dati. In termini di prestazioni, l'implementazione nel GT200 lascia però a desiderare - i calcoli double precision floating-point sono gestiti da un'unità Streaming Multiprocessor dedicata. Con un'unità in grado di eseguire un calcolo double-precision MAD per ciclo, abbiamo un picco prestazionale: 1.296 x 10 (TPC) x 3 (SM) x 2 (Multiply+Add) = 77.78 Gflops, o tra 1/8 e 1/12 delle prestazioni single-precision. AMD ha introdotto questo supporto usando le stesse unità processuali su più cicli di clock, con un risultato migliore - dalle due alla quattro volte meno veloce dei calcoli single-precision.
Come abbiamo visto, il numero di ROP è aumentato, ma non hanno guadagnato alcuna nuova funzionalità. Ma ammettiamolo, le ROP del G8x erano già abbastanza complete, con il supporto 16 e 32 bit floating point frame buffer, con blending e anti-aliasing; antialiasing fino a 8x o 16 in modalità CSAA; Z rendering otto volte più veloce; etc. Non c'era molto da aggiungere. Nvidia ha solo cercato di migliorare le prestazioni. Per il blending in frame buffer RGBA8, il G8X/G9x offriva prestazioni pari alla metà, con 12 pixel per ciclo. Con il GT200, questa limitazione è stata eliminata, grazie al bus a 512 bit - con un bandwidht di oltre 140 GB/sec, le nuove ROP dovrebbero rendere le schede GeForce incontrastabili per quanto riguarda il fill rate. Ecco i risultati del Z pixel rate:
Riguardo alle prestazioni grezze, i risultati non sono male, e segnano un nuovo record: 75537 Mpixel/sec!