[THREAD UFFICIALE] ATI Radeon X1800XT/XL

[yossarian]

Originariamente inviato da Vifani

Si però yossarian ti invito a non sminuire l'importanza dell'HDR. E' vero che alla fine il numero di colori visualizzati sono sempre 8 bit per canale, però è altrettanto vero che l'HDR non è un banale calcolo dell'illuminazione in floating point. Quella avviene anche adesso, basta fare una banale illuminazione per pixel via pixel shaders. Il discorso è un altro. L'HDR consente di avere una "distribuzione" dell'illuminazione dinamica e differente a seconda della scena visualizzata, della posizione delle camera rispetto alle fonti di luce, ecc... Nel complesso anche se il numero di colori è lo stesso, l'HDR riesce a rendere l'illuminazione estremamente più realistica perché la gestione dinamica del range gli consente di emulare il comportamento dell'occhio umano e di esaltare determinate zone chiare e/o scure. Insomma l'effetto è un decisivo passo in avanti rispetto alle tecniche classiche. Di fatto i 16,8 milioni di colori a disposizione per la visualizzazione finale della scena sono più che sufficienti a livello gaming ed è la gestione dinamica interna in floating point a fare la differenza. Poi naturalmente aggiungendo i vari effetti di blooming, si aggiunge un tocco di spettacolarità al tutto.

lungi da me l'intenzione di sminuire l'importanza dell'HDR. Mi limito, semplicemente, a prendere atto di una serie di cose. Innanzitutto del fatto che, tecnicamente parlando, il vero HDR è ancora lontano dall'essere realizzato (si può parlare di HDR quando si hanno almeno 32 bit per colore, cosa che del resto prevede anche l'algoritmo ideato da OpenEXR e utilizzato da nVIDIA e ATi; solo che le operazioni di blending a 32 bit non sono compatibili con l'HW attuale; quindi sarebbe più corretto parlare di half HDR); in secondo luogo, che, a causa delle limitazioni imposte dalle periferiche di visualizzazione (o di acquisizione, in caso di HDR ralizzato su immagini "reali"), più che la rappresentazione a fp16 per canale, che sicuramente fornisce un range più ampio di valori e quindi la possibilità di rappresentare in maniera più dettagliata un'immagine, oltre a quella di avere una più ampia gamma di valori di luminanza (cosa fondamentale per quello che dirò in seguito), assumono un'importanza preponderante gli algoritmi di tone mapping scelti per la compressione delle immagini a 8 bit. Questo perchè l'occhio umano non è facilmente rappresentabile mediante una semplice funzione matematica e, di conseguenza, non esiste un solo algoritmo di compressione del range, ma ne esistono diversi, in base a ciò che si vuole rappresentare e mettere in risalto. In particolare, questi algoritmi di compressione si basano sul principio che l'occhio è molto sensibile ai contrasti e molto poco alle sfumature di uno stesso colore. Quindi, per cercare di mantenere il massimo realismo visivo, si tende, nel momento in cui un'immagine a 64 bit si riduce a 32, a comprimere il più possibile lo spazio dedicato alle sfumature di uno stesso colore, per dedicare uno spazio più ampio alle transizioni di colore (operazione che coinvolge anche la luminanza, motivo per cui, le immagini trattate in HDR presentano anche un maggior contrasto tra zone illuminate e zone d'ombra).
In pratica, si fa un'operazione inversa rispetto a quella dei filtri di AA e AF, in cui, invece, si tende a ridurre l'impatto delle "scalettature" o delle "transizioni" da texture a maggior dettaglio a texture a minor dettaglio aumentando la scala delle sfumature di uno stesso colore e riducendo, di conseguenza il contrasto tra una zona e l'altra.
Per quanto possano essere efficaci, però, gli algoritmi di tone mapping non permetteranno mai una rappresentazione veramente realistica, in quanto, comunque, nell'operazione di compressione si deve sacrificare qualcosa a vantaggio di qualcos'altro.

[yossarian]

Originariamente inviato da Ren

x yoss

Secondo te come saranno ripartite le unità del futuro r580 ?
1. 3vec3+scalar(2 mul/mad e 1 add/input) + unità di branch.
2. Mini-alu "MAD" stile g70.

3vect3+scalar + una minialu (3MUL/MAD + 1 ADD/input) + unità di branching

Quello che cambierebbe sarebbe, essenzialmente, il numero di unità MAd, che passerebbe da 4 per gruppo di 128 thread (o una per ciascuna delle 16 pp, se vogliamo mantenere la notazione a pipeline) a 12 per gruppo di 128 thread (3 per pp)

[halduemilauno]

Originariamente inviato da belin

...vorrei dire due cose che mi sono venute in mente leggendo alcuni post.
...in questa sezione si parla di schede video, scannarsi e prendersi in giro per un argomento del genere è pura follia infantile. ci sono cose ben più importanti nella vita che un componente di un pc. ho aperto questo ed altri thread perchè sono un appassionato di pc, in particolare di schede video, e dato che la vita e gli studi mi hanno portato a fare cose ben diverse, cerco di soddisfare la mia passione e le mie curiosità partecipando a forum come questi. chi viene qui per scatenare flame non ha capito nulla. proprio nulla...
...da certi inutili post si capisce che c'è gente che non ha letto nulla su R520.
...gente che non si è accorta che l'architettura di R520 è la più tecnologicamente avanzata in questo momento.
...gente (e mi ripeto) che non si è accorta che il concetto di pipeline è stato superato da R520, introducendo i Quad Pixel Shader Core e gli Ultra-Threading Dispatch Processor, che non si è accorta dei 0.09 micron, dell'anisotropico per ogni angolazione, dell'HDR e AAA simultanei, del rig bus a 512 bit, del nuovo controllo di memoria configurabile da driver, di AVIVO, del 3DC+, delle caratteristiche che riconducono al futuro R500.
...ci sono persone "molto vicine" ad nVIDIA, come halduemilauno, che hanno capito tutte queste cose e partecipano a questo thread facendo commenti intelligenti o battute simpatiche; ci sono altre persone che si divertono a scatenare flame o prendere in giro chi si limita a dare giudizi tecnici... a queste persone chiedo, se ce la fanno, di smetterla di inquinare il thread, grazie.

...ciao!

concordo su tutto.
non a caso io non ho mai toccato l'argomento tecnologico perchè mi è parso evidente fin d'all'inizio che l'R520 era molto più avanzato dei suoi predecessori.
poi basta riflettere su un aspetto il G70 in origine si chiamava NV47 e questo fa capire ancor di più lo stretto legame di parentela tra i due chip nVidia NV40 NV47(G70). invece come gia detto tra l'R420/480 e l'R520 magari non sono nemmeno parenti.
io ho sempre parlato di ritardo commerciale. e se ho insistito su questo punto è perchè alcuni utenti lo ignoravano, lo minimizzavano, lo negavano.
certo la scheda ora è stata presentata a fra una mesata sarà in vendita ma quell'aspetto credo che non andava ne trascurato e ne sottaciuto . IHMO.
sul lato prestazionale le due schede x1800xt/7800gtx stanno sul livello che ciascuno di noi ha potuto vedere attraverso le decine di rece.
ciao.


Grazie per i miei commenti e le mie battute. qualcuno le ha notate.

[yossarian]

Originariamente inviato da Athlon 64 3000+

io ormai non posso più tornare indietro perchè mi dovrebbero spedire in questi giorni la 7800GTX della Point of View.
Però dico che Ati con R520 ha fatto un gran bel lavoro riuscendo a fare una architettura davvero ottima e efficiente meglio di G70 e questo mi ricorda quello che Ati fece con R300 che ritengo il miglior progetto fatto da Ati e il più rivoluzionario.
Certamente è molto innovativo R520 ma non rivoluzionario come è stato R300.
Io poi vedo Ati in vantaggio per lo sviluppo della gpu directx 10 visto che ha già una solida basa di partenza chiamata R500.
Domanda per Yoss,spero di spiegarmi bene.
L'HDR per essere eseguito nelle specifiche SM 3.0 deve essere calcolato in floating point a fp16?

l'hdr non c'entra con le specifiche sm3.0; si tratta semplicemente di una tecnica che permette di ampliare il range di valori dedicabili alla rappresentazione dei tra colori RGB e della luminanza. E' nato molto prima delle DX (addirittura, i primi esperimenti risalgono agli anni '80 e l'algoritmo di OPenEXR utilizzato da ATi e nVIDIA) è del 1999, anche se è stato ufficialmente presentato nel 2003 al SIGGRAPH).
Esistono varie tecniche per realizzare HDR; una delle più comune è una compressione/decompressione di tipo logaritmica; ce ne sono altre che utilizzano algoritmi di tipo lineare (ma sono meno precisi e affidabili). Alcuni prevedono l'utilizzo di interi, altri di valori in floating point.
In particolare, quello di OPenEXR, prevede 3 modalità: fp32 (il vero e proprio HDR che, però, non è compatibile con l'HW attuale che può eseguire blending solo a fp16); fp16 (quello che, comunemente, viene definito HDR ma che sarebbe più corretto definire halfHDR); una modalità a 32 bit INT per canale.
C'è la possibilità, comunque, di fare HDR anche utilizzando 12 bit o 16 bit INT per canale

[Athlon 64 3000+]

Originariamente inviato da yossarian

lungi da me l'intenzione di sminuire l'importanza dell'HDR. Mi limito, semplicemente, a prendere atto di una serie di cose. Innanzitutto del fatto che, tecnicamente parlando, il vero HDR è ancora lontano dall'essere realizzato (si può parlare di HDR quando si hanno almeno 32 bit per colore, cosa che del resto prevede anche l'algoritmo ideato da OpenEXR e utilizzato da nVIDIA e ATi; solo che le operazioni di blending a 32 bit non sono compatibili con l'HW attuale; quindi sarebbe più corretto parlare di half HDR); in secondo luogo, che, a causa delle limitazioni imposte dalle periferiche di visualizzazione (o di acquisizione, in caso di HDR ralizzato su immagini "reali"), più che la rappresentazione a fp16 per canale, che sicuramente fornisce un range più ampio di valori e quindi la possibilità di rappresentare in maniera più dettagliata un'immagine, oltre a quella di avere una più ampia gamma di valori di luminanza (cosa fondamentale per quello che dirò in seguito), assumono un'importanza preponderante gli algoritmi di tone mapping scelti per la compressione delle immagini a 8 bit. Questo perchè l'occhio umano non è facilmente rappresentabile mediante una semplice funzione matematica e, di conseguenza, non esiste un solo algoritmo di compressione del range, ma ne esistono diversi, in base a ciò che si vuole rappresentare e mettere in risalto. In particolare, questi algoritmi di compressione si basano sul principio che l'occhio è molto sensibile ai contrasti e molto poco alle sfumature di uno stesso colore. Quindi, per cercare di mantenere il massimo realismo visivo, si tende, nel momento in cui un'immagine a 64 bit si riduce a 32, a comprimere il più possibile lo spazio dedicato alle sfumature di uno stesso colore, per dedicare uno spazio più ampio alle transizioni di colore (operazione che coinvolge anche la luminanza, motivo per cui, le immagini trattate in HDR presentano anche un maggior contrasto tra zone illuminate e zone d'ombra).
In pratica, si fa un'operazione inversa rispetto a quella dei filtri di AA e AF, in cui, invece, si tende a ridurre l'impatto delle "scalettature" o delle "transizioni" da texture a maggior dettaglio a texture a minor dettaglio aumentando la scala delle sfumature di uno stesso colore e riducendo, di conseguenza il contrasto tra una zona e l'altra.
Per quanto possano essere efficaci, però, gli algoritmi di tone mapping non permetteranno mai una rappresentazione veramente realistica, in quanto, comunque, nell'operazione di compressione si deve sacrificare qualcosa a vantaggio di qualcos'altro.

Ottima spiegazione.
Secondo te le architetture directx 10 che usciranno a fine 2006 potranno eseguire L'HDR con precisione a 32 bit?

[yossarian]

Originariamente inviato da Athlon 64 3000+

Ottima spiegazione.
Secondo te le architetture directx 10 che usciranno a fine 2006 potranno eseguire L'HDR con precisione a 32 bit?

può anche darsi; non è detto che ci si arrivi con i primi chip wgf2.0, però, sicuramente, uno degli obiettivi futuri sarà quello (se ti interessa, si stanno già studiando soluzioni a 48 bit per canale, che propongono una gamma infinitamente più ampia di sfumature). Il principale problema da affrontare sarà quello della banda passante e dell'occupazione di spazio in memoria. Oltre, naturalmente, al problema relativo ai dispositivi di visualizzazione. Se non si sbrigano a far uscire monitor che utilizzano più di 8/12 bit per canale, va da sé che maggiore è il range a disposizione per la "costruzione" delle immagini, maggiori saranno i sacrifici, in fase di comressione dati a cui si dovrà andare incontro. Se già si perde qualcosa nel passaggio da fp16 a INT8, immagina quanto si potrebbe perdere nel passaggio da 32 a 8 bit (anche alla luce del fatto che gli attuali algoritmio permettono una compressione lossless solo in casi specifici e con rapporto di 2:1

[belin]

...per chi è interessato all'aspetto commerciale (in poche parole, dove comprare le X1K) consiglio di tenere d'occhio questa nuova pagina comparsa sul sito ATI: Where to buy (c'è anche l'Italia tra le nazioni disponibili).

...ciao!

edit: ho inserito il link in prima pagina.

[yossarian]

Originariamente inviato da bartolino3200

Per il resto avete ragione voi, parlo a vanvera.
Ma sai che 00 se non ci fossi io, tutti ad elogiare Ati e la sua nuova creatura:
" ohh che bella " di qua " ma quanto è potente di là " ecc. ecc.
In fondo vi infervoro gli animi, e vi ci faccio appassionare ancora di più
Ad ognuno la sua.

io non dico che parli a vanvera; ti sto solo chiedendo di motivare le tue affermazioni. Se dici che l'R520 è overclockato e overvoltato di fabbrica per permettergli di raggiungere e superare la GTX e poi si scopre che è alimentato a 1,3 V e che in o/c può salire di oltre 200 Mhz ad aria, vuol dire che hai fatto due affermazioni smentite dai fatti.
Se vuoi fare delle critiche, qualunque sia il motivo (fosse anche anipatia verso ATi o simpatia verso nVIDIA), falle motivate.
Se, ad esempio, avessi detto che R520 ha prestazioni inferiori a G70 nel calcolo dei ps, nessuno avrebbe avuto niente da obiettare, perchè è un dato di fatto che risulta evidente da tutti i bench sintetici (e c'è una motivazione tecnica ben precisa sotto)

[hIRoShIMa]

Scusate ma la rece a quando?


byz

[Ricky78]

Originariamente inviato da hIRoShIMa

Scusate ma la rece a quando?


byz

al 2025...

[Jedi_Master]

Originariamente inviato da hIRoShIMa

Scusate ma la rece a quando?

deve tardare tanto quanto le schede.....quindi qualche mese!!

[T3d]

Originariamente inviato da yossarian

può anche darsi; non è detto che ci si arrivi con i primi chip wgf2.0, però, sicuramente, uno degli obiettivi futuri sarà quello (se ti interessa, si stanno già studiando soluzioni a 48 bit per canale, che propongono una gamma infinitamente più ampia di sfumature). Il principale problema da affrontare sarà quello della banda passante e dell'occupazione di spazio in memoria. Oltre, naturalmente, al problema relativo ai dispositivi di visualizzazione. Se non si sbrigano a far uscire monitor che utilizzano più di 8/12 bit per canale, va da sé che maggiore è il range a disposizione per la "costruzione" delle immagini, maggiori saranno i sacrifici, in fase di comressione dati a cui si dovrà andare incontro. Se già si perde qualcosa nel passaggio da fp16 a INT8, immagina quanto si potrebbe perdere nel passaggio da 32 a 8 bit (anche alla luce del fatto che gli attuali algoritmio permettono una compressione lossless solo in casi specifici e con rapporto di 2:1

ma nella realtà avere dei monitor che utilizzano più di 8bit per canale può migliorare notevolmente la qualità e il realismo delle immagini? se si che progressi si stanno facendo in questo senso? cioè... quando li potremo comprare ?

grazie

[emax81]

Originariamente inviato da belin

...per chi è interessato all'aspetto commerciale (in poche parole,
...ciao!

edit: ho inserito il link in prima pagina.

Ottima idea.

[picard88]

Originariamente inviato da yossarian

Se, ad esempio, avessi detto che R520 ha prestazioni inferiori a G70 nel calcolo dei ps, nessuno avrebbe avuto niente da obiettare, perchè è un dato di fatto che risulta evidente da tutti i bench sintetici (e c'è una motivazione tecnica ben precisa sotto)

yoss..mi sono sempre chiesto qual'è questa motivazione tecnica...nn è che puoi farmi luce?? grazie in anticipo

[DevilMalak]

raga ma la rece ?? sto facendo continuamente F5

[~Mr.PartyHut~]

Originariamente inviato da DevilMalak

raga ma la rece ?? sto facendo continuamente F5

Io ho un picchio che col becco schiaccia F5 in automatico che si muove col moto perpetuo



Ciao
~» Mr.Party`Hut «~

[picard88]

VOGLIAMO LA RECEEEEE!!!!!!

[yossarian]

Originariamente inviato da T3d

ma nella realtà avere dei monitor che utilizzano più di 8bit per canale può migliorare notevolmente la qualità e il realismo delle immagini? se si che progressi si stanno facendo in questo senso? cioè... quando li potremo comprare ?

grazie

si? Ci sono già alcuni monitor che utilizzano 12 bit al posto degli 8 consueti (il che fa salire il numero di livelli a 4096, contro i 256 degli 8 bit); altra tecnologia interessante è quella che prevede l'utilizzo di 8 bit per canali scelti, tra un frame e il successivo, in modalità random, tra 16 possibili valori (in maniera simile a quanto accade per il temporal antialiasing); questo permette di simulare l'impiego di 16 bit, sfruttando i limiti della capacità di risoluzione spazio-temporale dell'occhio umano.

[yossarian]

Originariamente inviato da picard88

yoss..mi sono sempre chiesto qual'è questa motivazione tecnica...nn è che puoi farmi luce?? grazie in anticipo

la motivazione è che R520 ha molte meno unità matematiche rispetto a G70.
Computendo le sole MAD, R520 ha 16 unità di calcolo, raggruppate a 4 a 4, mentre G70 ne ha 48. L'architettura ideata da ATi è molto flessibile anche in fatto di "configurazione" della pipeline. Ad esempio, RV530 ha 12 unità raggruppate in una unica "pipeline" (con un potenziale di calcolo matematico superiore a quello di G70, se si fa riferimento al singolo quad (ossia 4 pipeline), in quanto si hanno 12 MAD contro 8 (2 per pipeline) di G70. L'avere un solo quad per gruppo di thread è vantaggioso ai fini del dynamic branching (una granularità di soli 4x4 pixel risulta estremamente vantaggiosa rispetto alla coerenza minima richiesta da G70, di 32x32 pixel), però rende meno veloce l'elaborazione dei calcoli matematici. Con R580 si dovrebbe avere un'architettura del tipo di quella di RV530, moltplicata per 4; il che significa 48 MAD, raggruppate a 12 a 12. Questo permette di avere un potenziale, per gruppo di thread, superiore a quello di G70 (12 contro 8), però riduce un po' l'efficienza nelle operazioni di branching (granularità pari a 4x12 pixel), rispetto a quella di R520

[picard88]

Originariamente inviato da yossarian

la motivazione è che R520 ha molte meno unità matematiche rispetto a G70.
Computendo le sole MAD, R520 ha 16 unità di calcolo, raggruppate a 4 a 4, mentre G70 ne ha 48. L'architettura ideata da ATi è molto flessibile anche in fatto di "configurazione" della pipeline. Ad esempio, RV530 ha 12 unità raggruppate in una unica "pipeline" (con un potenziale di calcolo matematico superiore a quello di G70, se si fa riferimento al singolo quad (ossia 4 pipeline), in quanto si hanno 12 MAD contro 8 (2 per pipeline) di G70. L'avere un solo quad per gruppo di thread è vantaggioso ai fini del dynamic branching (una granularità di soli 4x4 pixel risulta estremamente vantaggiosa rispetto alla coerenza minima richiesta da G70, di 32x32 pixel), però rende meno veloce l'elaborazione dei calcoli matematici. Con R580 si dovrebbe avere un'architettura del tipo di quella di RV530, moltplicata per 4; il che significa 48 MAD, raggruppate a 12 a 12. Questo permette di avere un potenziale, per gruppo di thread, superiore a quello di G70 (12 contro 8), però riduce un po' l'efficienza nelle operazioni di branching (granularità pari a 4x12 pixel), rispetto a quella di R520

capito..grazie