La progettazione del R600 è iniziata nel 2003 in contemporanea con lo sviluppo della GPU Xenos di X-BOX 360 da cui eredita molte interessanti caratteristiche e ne estende notevolmente le capacità.
L’architettura di R600 è unificata, completamente basata su thread con bilanciamento automatico del carico sulle varie unità di shader, rispettando in pieno le specifiche DirectX Shader Model 4.0. L’uso degli shader core permette di generare un alto throughput dalle ALU in abbinamento con basse latenze di accesso alla memoria.
Le unità principali di R600 sono il Command Processor, il Setup Engine, l’Ultra Threaded Dispatch e le Stream Processing Units.
| |
| Schema a blocchi dell'architettura di R600 |
Command Processor
È l’unità di elaborazione che si occupa di gestire le chiamate da parte del driver e indicare all’hardware quali operazioni eseguire. È anche compito del Command Processor di validare lo stato della GPU e modificarlo in base alle necessità ; questa funzionalità è stata introdotta per seguire le specifiche DX10 che prevedono di delegare alla GPU questa operazione, riducendo l’overhead indotto dalla stessa elaborazione eseguita via software dalla CPU. Le applicazioni DX9 possono a loro volta trarre vantaggio da questa nuova funzionalità riducendo, secondo dati forniti da ATI, l’overhead fino al 30%.
Setup Engine
Dopo la validazione dello stato e del codice da parte del Command processor, le istruzioni vengono passate al Setup Engine che si occupa di allocare le risorse (shader unit e spazio di memoria), i dati vengono organizzati per ottimizzare l’accesso alla memoria inoltre i vertex sono preparati per essere inviati all’unità di “tassellazione” che si occupa di suddividere le immagini in modo da aumentare la qualità finale e ridurre il carico di lavoro. L’unità di tassellazione è derivata da Xenos.
Al termine di questo processo, il Setup Engine assembla le instruzioni geometry e pixel sharder, discriminando quali parti della scena saranno visualizzate e quali no. Il risultato è inviato al “Ultra Threaded Dispatch Processor”.
Ultra Threaded Dispatch Processor
L’ Ultra Threaded Dispatch non è altro che che lo scheduler di R600. Gestisce tre code separate per ognuno dei tre componenti grafici (vertex, geometry e shader) e permette di riorganizzare le istruzioni in modo da ridurre le latenze di accesso alla memoria. Per ogni shader cluster sono presenti due “Arbiter” e due “Sequencer” che rispettivamente decidono e sequenzializzano le operazioni da eseguire. Texture e Vertex beneficiano di unità di elaborazione dedicati.
| |
| Schema a blocchi del Ultra Threaded Dispatch Processor |
Stream Processing Units
All’interno di R600 sono presenti 4 cluster da 16 shader units, ognuna delle quali può svolgere 5 operazioni contemporanee.
Le 5 ALU incluse in ogni shader unit non sono tutte uguali, la quinta infatti è potenziata rispetto alle altre e può svolgere operazioni matematiche più complesse anche in modo indipendente rispetto alle altre 4. Se le istruzioni sono ordinate in modo opportuno, da parte del compilatore, a gruppi di 5, si può sfruttare tutta la potenza di R600 senza sprechi, altrimenti una sola delle 5 unità di elaborazione sarà effettivamente attiva durante l’elaborazione.
R600 può svolgere 5 istruzioni per ciclo di clock (64 Alu per ogni istruzione), invece G80 di Nvidia esegue una singola istruzione nelle 128 Alu disponibili.
Memory controller in R600
Il particolare memory controller denominato Ring Bus, era già apparso in R520 e R580. In R600 è stato ulteriormente migliorato. Il nome Ring Bus, deriva dalla sua struttura che ricorda un anello che congiunge GPU, bus PCI-e e memoria video in una rete totalmente distribuita. L'uscita (o l'ingresso) di dati in questo bus è gestita dalla presenza di nodi all'interno di questa rete.
| |
| Architettura Ring Bus |
Il Ring Bus di R600 è ampio 1024 bit, suddivisi in due componenti da 512 bit uno per la scrittura e l'altro per la lettura dei dati. I nodi di stop sono in corrispondenza di un doppio canale della memoria video, ciascuno dei quali ampio 64 bit, e del bus PCI-e. Quindi, complessivamente, ci sono quattro nodi di stop per quanto riguarda la memoria video e uno per il bus PCI-e. Al centro di questa struttura, troviamo infine il core di R600, che quindi è in grado di dialogare con il bus di sistema e con il bus della memoria video tramite l'interposizione di questo anello.
Che tipo di problemi può compoprtare un tale approccio nei confronti, ad esempio, di una soluzione Crossbarr Switch adottata da G80? In primis, i dati che circolano nell'anello devono continuare a girare finchè non trovano il giusto nodo di stop. Questo inevitabilmente può portare ad un aumento della latenza con cui una data istruzione viene immessa o viene letta da una cella di memoria video. Tuttavia dato il basso numero si stop e la quantità di thread che uno stesso stop può gestire, il problema latenza non dovrebbe essere rilevante. In secondo luogo, questo tipo di anello è decisamente più difficile da ottimizzare rispetto ad un tradizionale Crossbar Switch, per cui si corre il rischio che non tutta l'ampiezza di banda sia sfruttata a pieno.
R600: questione Antialiasing
Fin dall'uscita del R600, è immediatamente emerso il notevole impatto sulle prestazioni dell'Antialiasing applicato alla scena renderizzata, se confrontato con le soluzioni nVidia.
La perdita di prestazioni è da ricercarsi, essenzialmente, nella mancanza del circuito di resolve nelle rop's. Tale circuito normalmente si occupa di effettuare i calcoli di interpolazione per l'applicazione dei campioni dell'antialiasing alla scena visiva. L'assenza di questo componente porta l'R600 a caricare lo shader core di questo compito, così facendo, nel rendering di una scena con l'antialiasing parte dello shader core risulta impegnato nelle operazioni sui vertex e sui pixel mentre un'altra parte è occupata nei calcoli di interpolazione.
La scelta di AMD di eliminare questo circuito può essere stata decisa inseguito ad uno o più dei seguenti motivi:
-
Mancanza di spazio: R600 è una gpu estremamente complessa, composta da oltre 700 milioni di transistor ad 80 nm, per cui la mancanza del circuito di resolve nelle rop's potrebbe essere imputata ad una precisa scelta progettuale dettata da delle difficoltà nell'implementazione nella gpu stessa.
-
Volontà di slegarsi dall'interpolazione lineare: Applicare l'antialiasing nelle rop's, significa applicarlo a "giochi fatti", ovvero a scena praticamente quasi già renderizzata. Questo implica l'utilizzo del solo metodo di interpolazione lineare per il calcolo dei campioni. Facendo i calcoli a monte, R600 è in grado di slegarsi da questo schema, potendo effettuare calcoli di interpolazione non lineare. Questo sarà molto utile in quei motori grafici che sfrutteranno l'antialiasing via shader (vedi Unreal 3 Engine).
-
Grande capacità matematica di R600: Questa gpu presenta delle capacità matematiche davvero notevoli che, che sotto alcuni aspetti si sono dimostrate maggiori di quelle del diretto concorrente nVidia. La scelta di affidare allo shader core i calcoli di interpolazione, potrebbe essere quindi figlia di questa capacità matematica.
Probabilmente queste tre ipotesi sono tutte in parte vere. Solo con RV670 e seguenti si potrà capire se il sacrificio architetturale è stato preponderante in questa scelta, infatti essendo costruito a 55 nm, ci sarà più spazio di manovra per i progettisti.
