Genere
ND
Lingua
ND
PEGI
ND
Prezzo
ND
Data di uscita
ND

Radeon X800

Anteprima

Radeon X800: la risposta di ATI

nVidia ha fatto la prima mossa, ma ATI non si è scomposta. Ha semplicemente atteso pochi giorni per definire gli ultimi dettagli ed è oggi pronta a presentare al mondo il suo nuovo chip, Radeon X800. Il prodotto parte da una concezione piuttosto diversa rispetto a quello della concorrenza: performance, prima di tutto, e solo dopo caratteristiche nuove. Vediamo nel dettaglio cosa ci viene proposto.

di Antonino Tumeo, pubblicato il

E dunque, passiamo a vedere le sei unità di vertex shading, decisamente somiglianti a quelle di Radeon 9800XT: nessuna sezione dedicata al texture fetching (come invece è necessario per il supporto ai Vertex Shader 3.0), ma due processori floating point in parallelo per elaborare scalari (a 32 bit) e vettoriali (a 128 bit) con lo stesso livello di supporto per subroutine e controllo di flusso offerto dalle architetture basate su R300. Ricordiamo che lo standard Vertex Shader 2.0 prevede 256 istruzioni statiche con un massimo di 256 costanti e 4 loop per un totale di massimo 1024 istruzioni, con solo branching di tipo statico (non dinamico, cioè non con parti di codice che possa essere completamente saltato), mentre l'hardware ATI arriva a supportare, similmente alle soluzioni NV30 di nVidia, fino a 255 chiamate a sottofunzioni o loop di altrettante 255 istruzioni, per un totale di circa 65.000 istruzioni. Ancora, il numero di registri temporanei è di 32 invece che i 12 prescritti dallo standard 2.0, e nel Radeon X800 è comunque supportato un buon livello di branching, con l'attenzione puntata soprattutto al fatto che il suo uso potesse essere sempre veloce e mai penalizzante. Per paragone lo Shader Model 3.0 prevede invece almeno 512 istruzioni costanti con loop e controllo di flusso statico e dinamico per un totale minimo che raggiunga 65536 istruzioni massime eseguite e 32 registri temporanei, oltre al supporto per Geometry Instancing e Texture fetching visto nell'analisi di GeForce 6800.
Da notare anche che nelle unità geometriche di R420 è stato incluso il supporto nativo per le funzioni trigonometriche, che invece negli hardware precedenti dovevano essere "approssimate" con sviluppi di Taylor per essere utilizzate.
Per quello che riguarda le unità di Pixel Shading, invece, con Radeon X800 possiamo assistere sostanzialmente ad un accurato raffinamento delle opzioni messe a disposizione dalle precedenti architetture. La precisione massima rimane di 24 bit in floating point: come in Radeon 9800, il color processor infatti rimane in grado di operare solo fino a 24 bit, mentre il resto delle unità può arrivare fino a 32 bit. Già questo aspetto lascia intendere il fatto che non sono supportati i Pixel Shader 3.0 (che prevedono giustappunto una precisione completa di 32 bit in virgola mobile), cosa che è evidenziata ulteriormente dal fatto che non viene supportato alcun tipo di branching. Crescono, però, il numero delle istruzioni supportate: si passa dalle 160 istruzioni totali supportate dalle vecchie architetture (96 secondo quanto previsto dallo standard Pixel Shader 2.0 di Microsoft), a ben 1536 istruzioni, suddivise in 512 scalari, 512 vettoriali, e 512 di caricamento texture. Limitati a 4 rimangono i caricamenti di texture dipendenti, ma è stato aggiunto un facing register. Aumentati sono anche i registri temporanei, che passano da 12 a 32. Il supporto per F-Buffer, comunque, ottimizzato per consentire una migliore gestione della memoria, garantisce la possibilità di realizzare abbastanza efficacemente (sfruttando il multipass) shader più lunghi del limite, senza il bisogno di ricorrere al branching (che non è, a differenza di quanto deve avvenire per attenersi alle specifiche dei Pixel Shader 3.0, per nulla supportato). Ricordiamo brevemente che l'F-Buffer è una particolare sezione nella quale vengono salvati solo quei pixel di un frame già composto che necessitano una ulteriore passata nelle unità matematiche di pixel shading, di modo che, se si utilizzano shader più lunghi del limite, non sia necessario dover rielaborare tutti i pixel del fotogramma (come normalmente accade nel multipass, con tutti gli eventuali problemi di visualizzazione del caso) ma solo quelli che veramente necessitino ancora per ulteriori calcoli.
Per supportare le nuove funzionalità introdotte con Radeon X800, il prossimo aggiornamento del kit di sviluppo per le DirectX (la tanto attesa versione 9.0c) presenterà un apposito percorso di compilazione per l'HLSL (High Level Shading Language), denominato con poca fantasia ps_v_2_0_b e che affiancherà i "vecchi" percorsi 2_0 e 2_0_a (quello per GeForce FX), ed il nuovo ps_v_3_0.
Da un punto di vista più prettamente "fisico", in ciascuna delle 12 (o 16, a seconda che si tratti di Radeon X800 PRO o XT), possiamo trovare due ALU (unità logico aritmetiche) vettoriali, due scalari, e l'unica unità per il caricamento delle texture. Sebbene tutte le unità possano operare in parallelo, per un totale massimo di 5 diverse istruzioni in esecuzione contemporaneamente per ciclo di clock, una ALU scalare e una vettoriale sono definite "mini" ALU, in quanto in grado di eseguire un buon numero di istruzioni, ma non tutte quelle che le loro sorelle maggiori "supportano". Vogliamo sottolineare la differente concezione rispetto alle unità di Shading di GeForce 6800: ATi propone innanzitutto l'unità di indirizzamento delle texture indipendente dalle ALU, per cui esse possono teoricamente venire impegnate contemporaneamente anche durante l'esecuzione del fetching delle texture, mentre con il GeForce 6800 se è in corso un caricamento di texture, può venire impegnato solo il secondo shader core. Il prezzo "pagato" da ATi è però, oltre che nella precisione, nel fatto che come evidenziato sopra le unità secondarie, sia scalare che vettoriale, sono piuttosto mini-ALU e che le 4 istruzioni di shading massime che esse permettono di eseguire devono operare in maniera fissa due su valori scalari (che, tramite appunto le due ALU scalari, operano su una sola componente) e due su valori vettoriali (che, con le due ALU vettoriali, operano sulle restanti tre componenti di colore). L'approccio di nVidia è invece un po' più generale, con entrambi gli shader core che possono operare con due istruzioni alla volta ciascuna in qualsiasi combinazione delle quattro componenti, scelta forse anche dettata dalle richieste del supporto per lo Shader Model 3.0.
È però importante notare che l'attenzione di ATI non è stata rivolta tanto al numero di unità matematiche da inserire, quanto al fatto che quelle presenti potessero essere tenute il più impegnate possibile, in modo da mantenere le prestazioni costanti e predicibili in qualsiasi situazione d'uso. La società canadese ha dunque cercato di fare in modo che non ci fossero latenze e penalità dovute, ad esempio, all'uso di più registri e a bilanciamenti non proprio buoni tra operazioni matematiche e operazioni di caricamento texture, per ridurre al minimo la fase di ottimizzazione da parte degli sviluppatori nella creazione degli shader (anche se, naturalmente, non mancherà quella del compilatore integrato nei driver stessi). Insomma, piccole, interessanti novità, non sostanziali, e soprattutto mirate ad un solo, fondamentale aspetto: quello delle prestazioni. E per, forse, evidenziare la continuità rispetto alle tecnologie offerte nelle architetture precedenti, i nuovi shader core sono stati denominati Smartshader HD.

COMPRESSIONE 3DC

Strettamente legata alle pixel pipeline, però, vi è anche quella che, probabilmente, si configura come la più importante novità introdotta con Radeon X800, e che ha la particolarità di essere una tecnologia liberamente distribuita a tutti coloro che volessero farne uso nel loro hardware. Si tratta di una nuova tecnica di compressione studiata per risultare utilizzabile efficacemente soprattutto con le cosiddette normal map.
Una normal map altro non è se una particolare texture che, invece di contenere le "immagini" che poi dovranno essere applicate ai poligoni, contiene per ciascun pixel le informazioni sull'orientamento delle normali rispetto alla superficie sulla quale applicare la texture. Difatti, se non c'è sufficiente dettaglio geometrico, l'applicazione di una texture ad una superficie la farebbe risultare piuttosto piatta: ad esempio, rappresentando il piano di un tavolo di legno con due semplici triangoli e applicando su di essi le relative texture, sarebbe piuttosto difficile dare una corretta rappresentazione delle increspature e delle venature che potrebbero caratterizzarlo. Sarebbe semplicemente come mettere un pezzetto di carta sopra un altro pezzetto di carta colorato: diventa magari più bello da vedere, ma non permette di avere un'idea corretta di come incidono, sul volume dell'oggetto stesso, dettagli come avvallamenti e sporgenze che per essere correttamente rappresentati necessiterebbero di geometria generata appositamente (con conseguente, e spropositato, aumento del numero di poligoni dell'oggetto).
In sostanza, quello che succede è che per quanto alta possa essere la risoluzione delle texture (e quindi alto il dettaglio) mancherebbero sempre quelle "informazioni" sul modo in cui la luce colpisce precise sezioni della superficie che, come nella realtà, permettono al nostro occhio di riconoscere una piccola variazione nella sua "uniformità", ed essa non può dunque far altro se non continuare ad apparire sempre piatta.
La soluzione, se non si vuole aumentare indefinitamente il dettaglio geometrico, la conosciamo già tutti: utilizzare tecniche di bump mapping, come il dot3 bump mapping. E per realizzare queste tecniche nella maniera migliore possibile ci si avvale appunto delle normal map, speciali mappe dove ciascun pixel rappresenta quella che, in un modello ad altissimo dettaglio geometrico, sarebbe l'effettiva normale (vettore perpendicolare, a 90 gradi) della zona di superficie relativa a quel pixel. Tali informazioni sono richieste per calcolare come appare la superficie quando illuminata dalle fonti di luce effettivamente presenti, e dare appunto la sensazione dei tipici avvallamenti e sporgenze della superficie. La necessità di usare texture è anche dettata dal fatto che, per rendere il procedimento completamente dinamico, è necessario anche elaborarle e modificarle in tempo reale per adattarsi alla posizione relativa delle fonti di luce. Il tutto, tramite pixel shader che si preoccupano di gestire tutto ciò che riguarda l'illuminazione per pixel.
Ora, tali mappe vengono generate con appositi tool calcolando la differenza tra i modelli ad alto dettaglio poligonale e quelli "base" che poi verranno effettivamente usati nei motori grafici, e poi conservate né più né meno come texture a 32 bit nello spazio di colore RGB (8 bit per ciascuna componente, rosso, verde, blu, più altri 8 bit per l'alpha channel). La differenza con una normale texture è che però le tre componenti di colore sono interpretate come informazioni sulla posizione spaziale del vettore, dove la coordinata x corrisponde al canale del rosso, la y a quella del verde e la z a quella del blu rispettivamente, mentre il canale alpha non è utilizzato. E' subito evidente quanto elevata possa essere l'occupazione di una normal map: maggiore risoluzione significa maggiore dettaglio e quindi una rappresentazione molto più realistica della superficie, ma significa anche dover conservare un'immagine a 32 bit più grande. C'è chi, desideroso di farne un uso intensivo, ha pensato di provare a comprimere le normal map utilizzando tecniche di compressione standard per le texture, come i vari livelli di DXTC incluse nell'API Microsoft. Il fatto è che, pur funzionando, la natura delle informazioni rappresentate è troppo diversa perché i risultati siano di alta qualità. Sicché ATI, pressata dalle richieste degli sviluppatori di avere un metodo efficace per comprimere le proprie normal map e, a parità di occupazione, poter utilizzare livelli di dettaglio molto più elevati, ha pensato di provvedere realizzando 3Dc e includendo il supporto hardware per questo sistema in Radeon X800, oltre a garantire che potesse essere adottato facilmente nelle DirectX 9.0c e in OpenGL con apposite estensioni.