Graphics Core Next: architettura della famiglia Southern Islands
La Radeon HD 7970 rappresenta il primo prodotto commerciale basato su architettura Graphics Core Next, un progetto che non è più un segreto già da qualche tempo. Per dare agli sviluppatori il tempo per capire le potenzialità del nuovo hardware, l'azienda ha parlato di Graphics Core Next a giugno, durante il Fusion Developer Summit. Secondo Eric Demers, capo tecnologico della divisione grafica AMD, l'architettura VLIW che è stata usata dalla serie HD 2000 è in grado di offrire maggiori prestazioni grafiche, ma è limitata nella gestione dei calcoli generali. Perciò anziché rimaneggiare la precedente tecnologia, AMD ha optato per un'architettura completamente nuova.
Avere maggiori prestazioni di calcolo e flessibilità è sempre gradito, ma per una scheda di questo genere le prestazioni con i giochi e la qualità grafica rimangono gli aspetti principali. La sfida è quindi stata quella di creare una GPU più flessibile, migliorando simultaneamente l'esperienza 3D. Per raggiungere questo obiettivo l'azienda ha abbandonato l'architettura Very Long Instruction Word in favore della Graphics Core Next.
Graphics Core Next, più efficiente
L'architettura VLIW di AMD è molto efficiente nella gestione delle istruzioni grafiche. Il suo compilatore è ottimizzato per calcoli mapping dot product, che sono il cuore delle operazioni grafiche 3D. Le debolezze di questo progetto emergono quando deve gestire istruzioni scalari con applicazioni general-purpose. Il compilatore deve fare molto lavoro per gestire determinate operazioni e anche alcune ipotesi. A volte emerge che un set d'istruzioni, chiamato wavefront, non si può eseguire fino a quando un altro wavefront non è risolto. Tutto ciò si chiama dipendenza. Il problema è che il compilatore non cambia la coda delle istruzioni wavefront dopo che questa è stata programmata, quindi il potenziale delle ALU è spesso disperso perché le istruzioni devono aspettare che le dipendenze siano indirizzate.
Qui vedete un esempio teorico di come un engine SIMD VLIW4 sulla Radeon HD 6970 e i suoi 16 banchi di processori shader (ogni SP ha quattro ALU, per un totale di 64 ALU per engine SIMD), dovrebbe gestire una coda wavefront che include dipendenze:
Come potete vedere l'architettura VLIW non gestisce le dipendenze in modo ideale. I wavefront aspettano inutilmente in coda mentre le ALU libere sono in idle.
Come ottimizzare la quantità di lavoro scalare che si può effettuare per ciclo di clock? Date il benvenuto alla Compute Unit, o CU. Questa unità ha un proprio scheduler hardware in grado di assegnare i wafefront alle unità vettoriali disponibili con limitate capacità out-of-order in modo da evitare i colli di bottiglia dovuti alle dipendenze.
Le Compute Unit rimpiazzano gli engine SIMD che siamo abituati a conoscere. Ogni CU ha quattro unità vettoriali (VU), ognuna con 16 ALU per un totale di 64 ALU per CU. Perciò il numero delle ALU per SIMD/CU è lo stesso. La differenza principale è che, a differenza dei processori shader in un SIMD Engine, ognuna delle quattro unità vettoriali può essere programma in modo indipendente.
Questa è la chiave per avere migliori prestazioni di calcolo generale perché dà a ogni VU l'abilità di lavorare su differenti wafefront se c'è una dipendenza in coda:
Nel nostro esempio la stessa coda d'istruzioni wavefront che impiega sei cicli di clock per completarsi su un engine SIMD VLIW4, può essere eseguita con quattro cicli di clock sull'architettura Graphics Core Next, raggiungendo quindi un'efficienza superiore nei calcoli generali. AMD suggerisce che la Radeon HD 7970 offre un miglioramento teorico nelle prestazioni di picco di 7.5 volte rispetto alla HD 6970. La differenza con le applicazioni reali dipende dall'efficienza sul compilatore, e in alcune operazioni di calcolo la HD 7970 è appena migliore della HD 6970 su basi "per ALU" e "per clock". Nelle nostre prove abbiamo visto molte differenze, tuttavia possiamo dire che basandoci sui test sintetici il potenziale dell'architettura Graphics Core Next è superiore a VLIW4.
All'interno della Compute Unit
Come scritto in precedenza, le Compute Unit rimpiazzano gli engine SIMD. Abbiamo già detto che ogni CU è composta da quattro unità vettoriali che, a loro volta, hanno 16 ALU e un file di registro ciascuna. Sappiamo anche che le unità vettoriali operano indipendentemente l'una dall'altra.
Entriamo nei dettagli di queste unità vettoriali. A differenza del ciclo di clock semplificato usato nel primo esempio, ogni unità vettoriale può elaborare un quarto di un wavefront per ciclo. Equipaggiata con quattro VU, ogni CU può di conseguenza gestire quattro wavefront ogni quattro cicli, l'equivalente di un wavefront per ciclo, per CU. Potete programmare le unità vettoriali in modo scalare e ognuna opererà in modalità vettoriale.
Non abbiamo ancora parlato dell'unità CU scalare, che è la principale responsabile del branching code e della pointer arithmetic. Le unità vettoriali sono in grado di gestire anche questi compiti, ma la forza di questo co-processore è nello scaricare il lavoro scalare in modo da consentire alle unità vettoriali di mostrare i muscoli.
Ogni CU ha quattro unità texture legate a una cache L1 di lettura/scrittura da 16 KB, due volte più grande di quella di sola lettura dell'architettura VLIW4. Storicamente la cache L1 era usata solo per le texture in lettura. Ora, tuttavia, possono puntare a piacimento nella stessa cache.