Radeon X1900

Anche se il calendario parla di 2005, non sono passati che tre mesi dal lancio effettivo della famiglia X1000. Di questa famiglia faceva parte, nella fascia alta, anche Radeon X1800, che a causa dei noti problemi produttivi è stato costretto a un'uscita molto ritardata rispetto ai mesi primaverili per i quali era stato previsto. Ciò, però, non ha impedito ad ATI di continuare a lavorare sul suo "refresh", R580, che invece ha pienamente mantenuto la sua tabella di marcia ed è oggi pronto ad arrivare sul mercato con il nome di Radeon X1900. Non deve stupire se il tempo tra la vecchia soluzione di punta e la nuova è rimasto così estremamente limitato: nell'ambito dei circuiti integrati, infatti, una volta partiti con un ritardo temporale, pur con prodotti validi, non ha nessuna convenienza ritardare di proposito le nuove soluzioni per cercare di incamerare più introiti con le vecchie. Il risultato netto sarebbe solo quello di perdere parte dei guadagni che potenzialmente i nuovi prodotti possono portare, anche perchè nulla vieta di continuare a vendere quelli vecchi...
Ma, senza ulteriori indugi, andiamo ad approfondire un poco l'architettura di Radeon X1900 e vediamo come la nuova linea si inserisce nella famiglia X1000 e quali aspetti la differenziano dai prodotti finora acquistabili.

L'ARCHITETTURA

A differenza di Radeon 9800 e Radeon X850, rispettivamente "refresh" di Radeon 9700 e di Radeon X800, questa volta le variazioni di Radeon X1900 rispetto al diretto predecessore sembrano più rilevanti. Il tutto però si lega perfettamente alla grande scalabilità con cui la struttura dei chip della famiglia X1000 è stata pensata. Ricordiamo infatti che, oltre al disaccoppiamento dei Render Back End (come già visto nelle architetture NVIDIA), cioè delle componenti che si occupano dell'accesso ai diversi buffer in memoria (frame buffer, Z buffer e stencil buffer), nelle nuove soluzioni ATI anche Pixel Shader Processor e Texture Unit sono stati completamente disaccoppiati e integrati da un efficiente Dispatch Processor UltraThreaded per lo scheduling dei "thread" con le sequenze dei pixel via via da elaborare. Le unità geometriche, invece, rimangono ancora separate e sono una diretta derivazione di quelle di X800. Ciò, come ricorderete, permise ad ATI di lanciare inizialmente tre prodotti: le X1300, con 3 unità geometriche, 4 Render Back End, in grado di eseguire ciascuno una operazione di Z, 4 Texture Unit e 4 Pixel Shader Processor, le X1600, con 5 unità geometriche, 4 Render Back End in grado però di eseguire ciascuno 2 operazioni di Z, 4 Texture Unit e 12 Pixel Shader Processor, e infine X1800, con 8 unità geometriche, 16 Render Back End ciascuno in grado di eseguire 1 operazione di Z, 16 Texture Unit e 16 Pixel Shader Processor.
X1300 e X1600 sono caratterizzate da un Dispatch Processor in grado di accodare fino a 128 thread, mentre X1600 e X1800 possono vantare l'utilizzo di un controller di memoria programmabile evoluto che centralizza le richieste ma distribuisce l'invio dei dati lungo due anelli "controrotanti" rispettivamente di 128 e 256 bit e cerca di massimizzare l'efficienza localizzando al meglio i dati.
Ora, non è un caso se in X1600 il rapporto tra Pixel Shader Processor, cioè le unità matematiche, e le Texture Unit, cioè di fatto le unità che in una scheda grafica sono preposte al caricamento dei dati (le texture, appunto) è di 3:1. Questo rapporto, che esiste anche in Xenos, il chip grafico di Xbox 360 (che presenta 16 Texture Unit e 48 ALU), è visto da ATI come quello ottimale per gli ultimi titoli (F.E.A.R. e Call of Duty 2 su tutti, al momento) e soprattutto per i titoli del prossimo futuro.
A seguito di questa breve dissertazione, appare dunque chiaro quale sia stata l'unica importante modifica nell'architettura di Radeon X1900 rispetto a X1800: il numero di Pixel Shader Processor è passato da 16 a 48, cosa che, con un esiguo aumento del numero di transistor (da 320 a circa 384 milioni) ha portato alla triplicazione delle prestazioni matematiche, pur lasciando praticamente invariato il resto. Rimangono infatti invariate il numero di unità geometriche (sempre 8), il numero di Texture Unit (sempre 16) e il numero di Render Output (ancora 16), sempre in grado di gestire una operazione di Stencil o Z Compare per ciclo di clock ciascuno.
Le motivazioni di questo approccio, che sotto forma diversa abbiamo potuto vedere già in G70 (con le funzionalità matematiche, per ciascuna pipeline, incrementate, seppure senza il disaccoppiamento della texture unit), sono da ricercarsi nel fatto che se le operazioni di texturing e dei Render Back End comportano accessi in memoria, la cui banda è principalmente limitata dalla relativa (se paragonata alla velocità di evoluzione dei processori grafici) attuale stasi delle tecnologie GDDR, le operazioni matematiche non soffrono di queste problematiche. Il meccanismo di gestione di threading di ATI si adatta perfettamente a questa situazione, essendo in grado di "sostituire" molto rapidamente ai thread in esecuzione sulle unità matematiche che però a un certo punto richiedano un dato mancante (cioè, appunto, una operazione di texturing con alta latenza) un altro thread pronto a venire eseguito, mentre quello precedente verrà accodato a quelli da mandare in esecuzione sulle unità di texturing. In questa maniera l'efficienza viene sempre mantenuta elevata.
L'organizzazione delle unità matematiche è quella classica di ATI, e cioè per ciascun pixel processor sono a disposizione una ALU vettoriale (3 elementi) ed una ALU scalare "complete", cioè in grado di eseguire operazioni di addizione (ADD), moltiplicazione (MADD), e addizione dopo moltiplicazione (MADD), precedute da una coppia di ALU scalare e vettoriale più limitate, in grado di gestire solo ADD e modificatori. Operazioni su vettori e operazioni su scalari possono essere lanciate contemporaneamente, e con la serie X1000, grazie all'unità dedicata al branching, parallelamente ad esse possono essere eseguite istruzioni di salto. Volendo dare qualche numero, i 48 pixel processor, alle frequenze alle quali sono proposti i diversi membri della linea X1900, possono fornire potenza computazionale nell'ordine dei 500 GFLOPS.
Non perfettamente chiarite da ATI sono state al momento alcune informazioni relative al Dispatch Processor/Scheduler. Le immagini architetturali riportate sembrerebbero infatti far riferimento a una unità costituita da ben 12 dei 4 moduli presenti in R520. Ciò significherebbe che la granularità dei "singoli thread" gestibili da R580 rimane la stessa di R520 (16 pixel, 4x4), e che, semplicemente, aumenti quindi il numero totale di thread gestibili. D'altra parte, il nuovo nato ha più di qualche somiglianza con Radeon X1600, per via del rapporto 3:1 tra operazioni di texture e matematiche, e la soluzione di fascia media utilizza una singola unità in grado di gestire 128 thread ma di granularità più grossa (48 pixel, 12 x 4), sicché è alta la probabilità che siano stati utilizzati quattro di questi elementi, lasciando di fatto invariato il numero totale di thread gestibili rispetto a R520 (512).
L'utilizzo di thread più grossi, se da un lato sarebbe comprensibile appunto con il fatto che adesso per ogni texture unit sono a disposizione tre shader processor e può essere conveniente far sì che di volta in volta i dati possano essere pronti per tre di essi, dall'altro limiterebbe comunque un po' l'approccio all'esecuzione di thread "indipendenti" e potrebbe nuocere alle prestazioni del branching, visto che se anche solo un pixel di ogni gruppo dovesse eseguire un ramo diverso del salto, il tempo di esecuzione per quel gruppo risulterebbe uguale alla somma dei due rami.
Una parte della documentazione sembrerebbe confermare l'utilizzo di thread di 48 pixel, facendo propendere per la seconda ipotesi, ma alcuni responsabili durante la presentazione hanno confermato il fatto che è stata mantenuta la granularità di 16 pixel, indicando quindi chiaramente la prima soluzione. Noi al momento ci riserviamo di approfondire meglio questo aspetto in un prossimo futuro, eventualmente istituendo dei test appositi.
Un'ulteriore variazione, in verità una feature già presente in Radeon X1300 e in Radeon X1600 ma non implementata in Radeon X1800 (che del resto avrebbe dovuto uscire prima delle soluzioni di fascia media e bassa), è stata però introdotta nelle texture unit, in grado di eseguire la cosiddetta operazione di Fetch4. Quando una texture viene campionata, solitamente vengono campionati quattro diversi valori: le componenti Red, Green e Blue e la componente di Alpha (la trasparenza). Questo significa però, che quando si deve campionare da texture "speciali" che contengono effettivamente una sola componente di colore, per ottenere quattro campioni dello stesso tipo si debbano eseguire quattro operazioni diverse. Fetch4 permette, con un'unica operazione di campionamento, di catturare quattro valori dello stesso tipo, cosa che di fatto permette di quadruplicare la velocità di campionamento. Una funzionalità del genere risulta, ad esempio, molto utile nel caso delle shadow map, appunto texture che contengono valori a singola componente, e che possono venire efficacemente usate nella generazione delle soft shadow. Poiché la generazione di una soft shadow prevede l'utilizzo di un valore variabile di campioni dalla shadow map a seconda della distanza dall'oggetto combinati attraverso un pixel shader, fetch4 permette di migliorare in maniera sensibile le prestazioni per la loro realizzazione. Un approccio differente, ma con gli stessi esiti, è quello di NVIDIA con il Percenteage Close Filtering (PCF).
Da annotare anche l'aumento del 50% della memoria on chip per la gestione dello Z culling (funzione che ATI denomina Hierarchical Z) e che consente di scartare i pixel coperti da altri pixel prima di elaborarli con una rapida analisi dello Z buffer: memorie ampie sono necessarie per mantenere elevata l'efficienza di questa funzionalità a elevate risoluzioni.