[THREAD UFFICIALE] ATI Radeon X1800XT/XL

[yossarian]

Originariamente inviato da Ren

Ma nell'r500(xenos) il branching è così efficiente ?
Se non sbaglio nel chip microsoft si hanno 48 unità mad/mul, inoltre il rapporto texture-unit_pixel-unit è di 3:1 come nel presunto R580...

http://www.ati.com/developer/eg05-xe...gett-final.pdf (regalo x yoss)

il branching di R500 è al livello di quello di un ipotetico R580 (leggermento meno di quello di R520, ma nettamente superiore a quello di G70)

Grazie per il regalo, ho apprezzato molto

[yossarian]

Originariamente inviato da shodan

Perfetto... allora ci siamo!
E' solo che prima ha accennato a RV530, dicendo che ha 12 unità in un'unica pipeline... allora ho pensato che parlassi di quad. Ma ora credo di aver capito cosa intendi: ha 12 unità che sharano tutte lo stesso gruppo di thread.

esatto

Originariamente inviato da shodan

Ma questo batch è slegato dal numero di unità PS? Ti chiedo questo perchè mi domando come mai R520 abbia un batch di 4x4 pixel, mentre RV530 e probabilmente R580 hanno/avranno un batch di 4x12...

Ciao grazie mille!

non è slegato: 4x4 in R520 = 4 gruppi di quad, ognuno con 4 unità di shading; 4x12 in R580 = 4 gruppi di quad, ognuno formato da tre quad e, di conseguenza, con 12 unità di shading. Non può essere altrimenti per essere certi di introdurre sempre all'interno della "pipeline" o del gruppo di quad, il numero minimo di pixel necessario a tenere occupate tutte le unità di calcolo.

La logica del dynamic branching è tarata sulle dimensioni delle tessere in cui è suddivisa l'immagine. La scelta di nVIDIA è stata quella di utilizzare tessere di grandi dimensioni (non meno di 32x32) quella di ATi di spezzettare l'immagine in tessere molto piccole (della dimensione minima indispensabile).

p.s.: quello di RV530 è 12x1 (o meglio, 3x4 , come è probabile che quello di R580, che ho definito 4x12, possa essere un 6x8 (quello che conta è il nhumero complessivo di pixel per tile))

[shodan]

Originariamente inviato da yossarian

esatto



non è slegato: 4x4 in R520 = 4 gruppi di quad, ognuno con 4 unità di shading; 4x12 in R580 = 4 gruppi di quad, ognuno formato da tre quad e, di conseguenza, con 12 unità di shading. Non può essere altrimenti per essere certi di introdurre sempre all'interno della "pipeline" o del gruppo di quad, il numero minimo di pixel necessario a tenere occupate tutte le unità di calcolo.

La logica del dynamic branching è tarata sulle dimensioni delle tessere in cui è suddivisa l'immagine. La scelta di nVIDIA è stata quella di utilizzare tessere di grandi dimensioni (non meno di 32x32) quella di ATi di spezzettare l'immagine in tessere molto piccole (della dimensione minima indispensabile).

p.s.: quello di RV530 è 12x1 (o meglio, 3x4 , come è probabile che quello di R580, che ho definito 4x12, possa essere un 6x8 (quello che conta è il nhumero complessivo di pixel per tile))

Ho capito, ma quindi ogni pixel elaborato dallo stesso quad è soggetto necessariamente alle stesse operazioni, giusto? Non è possibile quindi, all'interno dello stesso quad, applicare un "calcolo" a 2 pixel mentre ai restanti 2 si applica qualche altro algoritmo. Corretto?

Ciao.

PS: se passi a Pescara e ti senti solo, fammi un fischio! Così potrò rubarti in anteprima qualche segreto su R500...

[yossarian]

Originariamente inviato da shodan

Ho capito, ma quindi ogni pixel elaborato dallo stesso quad è soggetto necessariamente alle stesse operazioni, giusto? Non è possibile quindi, all'interno dello stesso quad, applicare un "calcolo" a 2 pixel mentre ai restanti 2 si applica qualche altro algoritmo. Corretto?

Ciao.

non necessariamente; una volta effettuato il branching e verificato il realizzarsi o meno della condizione di salto, i 4 pixel sono caricati nel quad; a quel punto, molto dipende dalla coerenza all'interno del quad 2x2 di pixel. E' molto probabile che per pixel contenuti all'interno di una tessera di dimensioni 2x2, molte operazioni siano in comune o siano soggetti a trattamenti analoghi; ma non è una regola: per ogni pixel possono anche essere avviati uno o più thread differenti, fino ad un massimo di 128 per un gruppo di 4 pixel. Addirittura, se il numero di operazioni relative ad un singolo pixel (o a 2 o 3, ecc) dovesse eccedere il limite dei 128 thread, il controller può riprogrammarsi e impedire che altri pixel entrino nel quad, finchè quel pixel non è stato completamente elaborato (i dati relativi alle successive elaborazioni finiscono all'interno dell'array di registri).
In ogni caso, la coerenza richiesta per le operazioni di branching va distinta da quella relativa al gruppo di pixel all'interno di un quad. Si tratta di due fasi successive e distinte.

http://www.xbitlabs.com/misc/picture...ing_bg.png&1=1

il modello di R520 e derivati, rientra nella prima categoria (ogni quadratino rappresenta una tessera di 16 pixel); il modello di NV40 e G70 è a cavallo tra la seconda (256 pixel) e la terza (4096), essendo di 1024 pixel.

Originariamente inviato da shodan

PS: se passi a Pescara e ti senti solo, fammi un fischio! Così potrò rubarti in anteprima qualche segreto su R500...

il fatto che possa trovarmi a passare dalle parti di Pescara è un'eventualità tutt'altro che remota molto meno probabile che porti con me qualcosa relativo a R500

[T3d]

Originariamente inviato da yossarian

l'ufficio è chiuso

sei troppo buono yossarian

eeheheheh

[Ren]

Grazie per il regalo, ho apprezzato molto

Parlando sempre di r500 non ho capito bene le capacità di color fillrate...
Dallo schema pare che il main-chip sia capace di inviare solo 8pixel o 16z-pixel al Dcore che però può eseguire più calcoli del necessario.

Perchè il setup dei triangoli è limitato solo a 500mil di trinagoli ?
Un'unità 4+1 come si comporta nel calcolo dei pixel shader ? (le situzioni + frequenti non sono 3+1 o 1+1+1+1?)

[Maury]

9:24 e qua non si vede nulla

[Jedi_Master]

Originariamente inviato da Vifani

Tra un paio d'ore vi faccio un piccolo report e vi saprò dire di più

Siamo cosi' giunti a mercoledi' mattina e.....
l'attesa continua!!

[Vifani]

Originariamente inviato da Jedi_Master

Siamo cosi' giunti a mercoledi' mattina e.....
l'attesa continua!!

Ho completato il tutto intorno alle 5 del mattino (senza andare a dormire). L'articolo arriverà oggi

[DjLode]

Originariamente inviato da Vifani

Ho completato il tutto intorno alle 5 del mattino (senza andare a dormire). L'articolo arriverà oggi

P.S. A che ora?

[Vifani]

Originariamente inviato da DjLode

P.S. A che ora?

Adesso

[Maury]

Commento tecnico post lettura recensione: che scheda della bestia, nVidia asfaltata sotto un metro di catrame

Rece favolosa complimenti

[wiltord]

spettacolo!!!

[Milotto]

Complimenti al Vifani per la rece: ricca di shoots per una accurata analisi qualitativà e mai eccessivamente tecnica..
Però mi domando che senso abbia proporre come bench UT2004 e tralasciare HL2 , Fear , SS2 etc....

[Eddie666]

Ottima rece! ho potuto dargli solo una letturina veloce,perche' devo uscire,ma mi sembra davvero bene fatta e soprattutto tesa ad analizzare tutti i molteplici aspetti della scheda.
complimenti alla redazione!

[Jedi_Master]

Originariamente inviato da Vifani

Ho completato il tutto intorno alle 5 del mattino (senza andare a dormire). L'articolo arriverà oggi

Vista adesso!!
Ottimo lavoro, complimenti e.......Buona notte.

Se nn hai dormito fino alle 5 ne avrai bisogno!

[Vifani]

Originariamente inviato da Milotto

Complimenti al Vifani per la rece: ricca di shoots per una accurata analisi qualitativà e mai eccessivamente tecnica..
Però mi domando che senso abbia proporre come bench UT2004 e tralasciare HL2 , Fear , SS2 etc....

Half-Life 2 purtroppo lo abbiamo dovuto escludere a causa dell'ultimo aggiornamento fatto da Valve attraverso Steam che mandava sempre in crash il gioco, con qualsiasi scheda video. Nel forum di Steam ci sono tantissime persone con questo problema e fino a quando non lo risolvono, non lo possiamo utilizzare.

Fear non è stato usato perché ci è stato sconsigliato da NVIDIA: le prestazioni della demo che gira non sono indicative del gioco finale secondo loro e quindi abbiamo preferito attendere il gioco finale.

Per il resto la quantità di benchmark mi sembra sufficiente.

[halduemilauno]

Originariamente inviato da Vifani

Half-Life 2 purtroppo lo abbiamo dovuto escludere a causa dell'ultimo aggiornamento fatto da Valve attraverso Steam che mandava sempre in crash il gioco, con qualsiasi scheda video. Nel forum di Steam ci sono tantissime persone con questo problema e fino a quando non lo risolvono, non lo possiamo utilizzare.

Fear non è stato usato perché ci è stato sconsigliato da NVIDIA: le prestazioni della demo che gira non sono indicative del gioco finale secondo loro e quindi abbiamo preferito attendere il gioco finale.

Per il resto la quantità di benchmark mi sembra sufficiente.

lo ribadisco anche qui. ottima rece e ottima scheda.

[Milotto]

Originariamente inviato da Vifani

Half-Life 2 purtroppo lo abbiamo dovuto escludere a causa dell'ultimo aggiornamento fatto da Valve attraverso Steam che mandava sempre in crash il gioco, con qualsiasi scheda video. Nel forum di Steam ci sono tantissime persone con questo problema e fino a quando non lo risolvono, non lo possiamo utilizzare.

Fear non è stato usato perché ci è stato sconsigliato da NVIDIA: le prestazioni della demo che gira non sono indicative del gioco finale secondo loro e quindi abbiamo preferito attendere il gioco finale.

Per il resto la quantità di benchmark mi sembra sufficiente.

Non vi era vena polemica nelle mie valutazioni..
A questo punto , presumo ,che da qui a un mese sarà possibile riproporre la review con HL Lost Coast , Q4 , Fear e lo stesso Serious Sam2....
Ciao ciao

[Jedi_Master]

Originariamente inviato da Vifani

Fear non è stato usato perché ci è stato sconsigliato da NVIDIA: le prestazioni della demo che gira
non sono indicative del gioco finale secondo loro

Peccato sarebbe stato interessante vedere un prima e dopo.
Spero cmq che la final viaggi meglio del demo con TUTTE le skede!