Stream Processor – SIMD’s e accesso alla memoria interna
Passiamo adesso ad analizzare il cuore vero e proprio di R600, dove troviamo tutte le unità stream processor in numero di 320 divisi in 4 blocchi, chiamati Matrici SIMD (Single Intruction Multiple Data), da 80SP’s ciascuno. Come già menzionato R600 usa nelle matrici VLIW (Very Large intruction Words) con lunghezza variabile da 64 a 128bit visto l’approccio adottato sulla costituzione degli stream processor che impiega per ogni operazione di lettura/scrittura 32bit che possono essere combinati per arrivare a 64 o 128bit.

Per massimizzare l’efficienza ogni stream processor deve essere indipendente dalle altre SP’s e lavorare in modo SuperScalare, cioè lavorare su informazioni scalari raggruppate in gruppi di 5.
Ogni Stream Processor è formato da 5 processori shader (ALU), un branch execution units e un registro generico (GPR) dove vengono mantenuti i dati di input/output e i valori temporanei.

AMD dal vecchio progetto ha preso le 5 ALU per la gestione dei Vec4+1 (vettore più scalare) mantenendo la stessa sistemazione ma rendendola superscalare e indipendente abbandonando l’approccio vettoriale. Di 5 processori shader presenti all’interno dello stream processor, uno è adibito a svolgere oltre alle normali elaborazioni delle funzionalità aggiuntive come il float to fixed o altre operazioni trascendentali. Il fatto che ce ne sia solo una per ogni stream processor è dato dal fatto che questi calcoli “speciali” sono in numero molto minore rispetto al numero di elaborazioni che può fare ogni unità shader.

AMD continua ad usare anche una unità di branch Execution, visto che ci sono 2 tipi di branch possibili. Branch molto pesanti a cui serve che tutto lo stream processor elabori una nuova parte di codice e viene gestito direttamente da arbitri e sequenze. Altre volte invece il branch viene eseguito tramite predizione e può quindi essere gestito internamente dall’ALU. All’interno della matrice troviamo anche una cache general porpuse dove vengono immagazzinati tutte le variabili dei thread dormienti, i risultati dei calcoli fatti e i dati per i calcoli da effettuare.

Ogni cache all’interno di R600 è virtualizzata e anche la GPR non fa eccezione visto che con l’introduzione delle DX10 si tende a virtualizzare ogni risorsa per renderla teoricamente illimitata.
La virtualizzazione della GPR viene fatta tramite una cache bidirezionale read/write in parallelo con la cache vertex e texture permettendo allo shader di scrivere e leggere contemporaneamente dalla memoria. Si può anche usare la scrittura combinata raggruppando prima tutti dati e inviarli una sola volta alla memoria risparmiando cicli di clock. In questo modo ogni pixel può accedere a 4k di vettori a 128bit o 64k di dati pixel rendendo essenziale la virtualizzazione della cache visto il volume elevato di dati che ogni shader può gestire.

Unità Texture – Architettura
All’interno di R600 a fianco del blocco SIMD vengono associate 4 unità texture.

Ogni unità texture è composta da 20 unita texture sampler per un totale di 80 su tutte e 4 le texture units che prelevano e restituiscono dati sia in virgola mobile che interi. Affianco alle texture units troviamo anche delle cache  per l’archiviazione di dati a seconda del tipo. La vertex cache serve appunto per l’archiviazione di dati vertex ma essendo flessibile può ospitare anche texture non filtrate o displacement molto usati con le DX10.

La texture cache, che deve lavorare in accordo con la vertex cache, e molto complessa e divisa in più cache suddivise in cache di primo livello L1 da 32k unificate per tutte le matrici  SIMD’s e cache di secondo livello L2 da 256k che permettono di archiviare e conservare strutture di dati molto grosse. Il tutto viene in ogni caso gestito a livello hardware e non più tramite driver utilizzando gli arbitri e i sequencing per la codifica dei dati entranti sincronizzando gli accessi alle risorse nel miglior modo possibile sgravando la CPU di sistema da questo compito.