[News] Geforce 7800GTX

[giampa]

facci sognare Claudio....

[AirJ]

Certo Claudio che sei crudele, si sentira' sola quella 7800 senza una compagna!!!

Cosa vuol dire che non potrai provarla decentemente?
In ogni caso sono curioso di sapere le tue impressioni, anche se la proverai col solo dissy stock. Ho letto gia' molte rece in rete ma mi fido sempre di piu' del parere diretto, soprattutto se viene da una persona che conosco per le sue capacita'.

[Mc-Turbo]

ciao a tutti; vecchi amici e nuove conoscenze




Ciao Gennaro; me la ricordo bene quella serata e credo sia doveroso organizzarne un'altra al più presto.

Comunque, già che ci siamo, adesso che sono finalmente note le specifiche di G70 e di Rsx (ops, ho detto RSX?), possiamo anche divertirci a commentarle sul forum. Ognuno dice la sua, mi raccomando, sbilanciatevi pure (Alberto conosce la mia filosofia) senza tema di fare brutte figure; vorrei si trattasse di una tavola rotonda sul tema e non di una specie di "lezione"; non mi piace il ruolo di guru, preferisco definirmi "persona informata sui fatti"

O.T.
Mitico! Mi piace Questa Frase "non mi piace il ruolo di guru,preferisco definirmi "persona informata sui fatti"
Stefano Benvenuto su MemoryExtreme.
/.O.T.

per Claudio,
Aspettiamo News

[yossarian]

O.T.
Mitico! Mi piace Questa Frase "non mi piace il ruolo di guru,preferisco definirmi "persona informata sui fatti"
Stefano Benvenuto su MemoryExtreme.
/.O.T.

per Claudio,
Aspettiamo News

grazie per il benvenuto

[Kam]

Non scherzare!


Sei un guru e lo sai!
Perche non ci illustri in modo tecnico il nuovo pupo di casa Nvidia?
Ce la fai? hai tempo?

Sarebbe anche molto bello da parte tua, ed apprezzatissimo dal forum, un confronto tra r520 e il nuovo nato NV...


DAI DAI!!!!


Kam

[lupacchiotto]

Beh, allora benvenuto anche da parte mia yossiarian
Non ci conosciamo ancora, ma arriverà anche qst momento..
Allora, me lo fai vedere perchè tutti ti chiamano guru? che ci sai dire sulla 7800GTx..
Un saluto



Gianluca

[Kam]

Tutto....ti sa dire TUTTO!

Kam

p.s. aspetta e vedrai!

[lupacchiotto]

Mi fido

[yossarian]

beh, non è che ci sia molto da aggiungere a quanto avete già letto in giro nelle varie recensioni.

Insomma, G70 è un NV40 con una più elevata capacità nel calcolo matematico.
Resta la dipendenza tra alu e tmu nell'elaborazione dei pixel ma, d'altra parte, questa è una caratteristica intrinseca alle pixel pipeline dei chip NV (come si vedrà in seguito).

In breve, le unità VS sono rimaste immutate rispetto a NV40; nelle pixel pipeline è stata aggiunta la possibilità di esguire operazioni di tipo MAD anche alla prima delle due ALU che in NV40 eseguiva solo operazioni MUL o di tipo generico (è l'unità di calcolo principale). In più sono state aggiunte altre due unità, definite minialu, in grado di compiere operazioni su grandezze scalari; in poche parole, è stata replicata l'architettura delle alu presente nei vs con una unità full vect in parallelo ad una scalare; solo che nelle pixel pipeline ci sono 4 unità complessive, in parallelo a due a due. A valle della alu principale c'è un circuito che si occupa di normalizzazioni su grandezze vettoriali; questo circuito funziona, però, solo in fp16: per questo motivo, anche G70, come NV40 (anch'esso dotato dello stesso circuito), in fp16 ha prestazioni superiori che non in fp32 (per effettuare operazioni di normalizzazioni su un vettore in floating point, occorrono un'operazione di tipo RCP, che calcola il reciproco di un numero, e 4 moltiplicazioni; in fp16, tanto G70, quanto NV40, eseguono queste due operazioni in un solo ciclo, mentre in fp32 ne occorrono almeno un paio e le operazioni sono svolte dalle alu e non dal circuito di normalizzazione).
L'aumento di unità di calcolo nelle pixel pipeline ha portato il numero totale delle operazioni logiche (escluse operazioni di texture fetch) a 5 contro le 3 di NV40.
Le flops, o miniops che dir si voglia, ovvero le singole operazioni in floating point che sono eseguite in un singolo passaggio all'interno della pipeline sono in totale 27 e si possono schematizzare nel modo seguente:
4 MAD, ossia 4 MUL+4 ADD nella prima alu
4 MAD nella seconda alu (e siamo già a 8+8 operazioni)
1 RCP + 4 MUL nel circuito di normalizzazione
1 MAD nella prima delle due minialu
1 MAD nella seconda minialu
2 operazioni relative a operazioni di ingresso e uscita deio dati dalla pipeline.

Le ROP's, invece, sono rimaste identiche a quelle di NV40, sia nel nuemro che nelle funzionalità. La scelta è dettata dal fatto che, allo stato attuale, le pixel operations sono quelle che richiedono elaborazioni più complesse; quindi un numero ridotto di ROP's non incide più di tanto (in negativo, ovviamente) nella velocità di elaborazione, ma permette di ridurre lo spazio delle stesse, a vantaggio di altre unità di calcolo.

Vorrei parlare, adesso, della "filosofia" seguita da ATi e nVIDIA a livello di elaborazione nelle pixel pipeline; questo, probabilmente, servirà a spiegare il perchè della capacità dei chip NV di eseguire un numero enorme di operazione di dependent read e, al contrario, per quale motivo i chip ATi gestiscono meglio i registri sia temporanei che costanti.

Nei chip NV (parlo a livello di pixel shader), si fa ricorso a uno schema del tipo che segue; durante la prima fase, in base alle indicazioni del microcodice dell'istruzione da eseguire, sono configurate tmu e alu; quindi si rintracciano e si collegano tra loro tutti i quad presenti nella coda, ordinandoli in base a quanto indicato; quindi, il singolo quad entra nella pipeline, passando attraverso i vari stadi, fino ad elaborazione terminata. Mentre viene elaborato, genera aggiornamento del microcodice (che si trasforma in una variazione dei dati allocati in una tabella, nota come look up table, che tiene a mente tutte le operazioni da eseguire e tutte quelle esguite su ogni singolo pixel in circolo) da inviare al controller che lo legge e organizza le operazioni relative al secondo quad che entra nella pipeline e così via (naturalmente l'ingresso del quad successivo non è subordinato all'uscita di quello precedente; in tal modo si può avere un gran numero di quad, almeno in teoria, che circolano all'interno della pipeline)
Supponiamo di avere un gruppo di quad in ingresso. Il primo quad arriva all'ingresso della pixel pipeline; passa attraverso un'unità che legge una sorta di microcodice recante informazioni sul tipo di elaborazione da fare; la pixel pipeline viene organizzata di conseguenza, predisponendo le alu e la tmu per quello specifico tipo di elaborazione. Ovvio che mi sto riferendo a elaborazioni che richiedono più cicli di clock (le altre sono molto poco interessanti); il microcodice contiene informazioni sul numero e sul tipo di operazioni che devono essere eseguite su quello specifico quad; quindi, ad esempio, se devono essere eseguiti calcoli che richiedono l'utilizzo della tmu per n volte con in più m calcoli matematici, si può partire, ipoteticamente, con un rapporto 1:1 tra math ops e texture fetch (ho sparato a caso, quindi potrebbe non essere così e, comunque, sicuramente, il rapporto iniziale è fortemente dipendente da quanto è grande m rispetto a n); una volta fatto ciò, il quad entra nella pipeline e inizia a essere elaborato; una volta che il quad 1 ha passato i primi stadi di elaborazione, entra il quad 2 e si ripete il procedimento; di conseguenza, il primo blocco di unità di calcolo viene riorganizzato per accogliere il secondo quad; questo procedimento si ripete fino al momento dell'uscita del quad 1 dalla pixel pipeline; a questo punto, il quad 1 è dirottata all'interno di un quad buffer (che si trova dentro la pixel pipeline) e viene messo in attesa; nel compiere le varie operazioni all'interno della pixel pipeline, il microcodice (che non è altro che un registro delle operazioni da eseguire e di quelle eseguite) viene aggiornato e le informazioni sono inviate all'ingresso della pixel pipeline, dove vengono confrontate con il microcodice del quad che si trova in quel momento, per la prima volta, all'ingresso della stessa. Dal confronto delle operazioni da eseguire immediatamente sui due quad e dai dati risultanti sullo stato di occupazione delle unità di calcolo all'interno della pipeline, nonchè del numero di quad che sono, in quel momento in elaborazione, un controller decide quale quad far entrare (se il n°1 per il secondo ciclo o quello che si è presentato in quel momento, per la prima volta, all'ingresso). In questo tipo di elaborazione, le unità di calcolo vengono ogni volta riconfigurate e lo stesso vale per i dati caricati all'interno dei registri.


Nei chip ATi, invece, si ha qualcosa del genere: si collegano e si ordinano tutti i quad nella coda in base all'elaborazione da fare; si caricano nei registri delle texture le 8 texture che si prevede di usare per prime; tra queste si seleziona quella relativa al primo dato da elaborare; infine, vengono caricati tutti i dati relativi alle operazioni matematiche da eseguire (massimo 128); infine si procede all'elaborazione, adoperando i dati caricati nei registri, fino a svuotamento degli stessi.

Quello scelto da NV è un approccio di tipo dinamico (reso possibile anche dal controllo dinamico del flusso di dati), in cui ogni elaborazione fornisce indicazioni per l'elaborazione successiva; quello di ATi è un approccio "statico", in cui, una volta stabilito il dato da processare, si predispone tutto, caricando i registri costanti e assegnando gli indirizzi alle texture; in tal modo, quando parte l'elaborazione, è già tutto pronto, non solo per quanto riguarda il primo quad, ma anche i successivi, fino ad esaurimento della coda o allo svuotamento dei registri. In poche parole, secondo l'appoccio di ATi, nel momento in cui parte l'elaborazione, ogni stadio della pipeline "sa già cosa fare", mentre nel caso di nVIDIA, le operazioni vengono programmate di volta in volta.
L'approccio di ATi è migliore per quanto riguarda la gestione dei registri temporanei, richiede un minor numero di transistor (pipeline più corte) e permette di svincolare il texture processor dalle alu. Però è limitato dalla capacità dei registri costanti e quindi nel numero di elaborazioni dipendenti le une dalle altre (nel caso di nvidia si potrebbero avere, teoricamente, infinite elaborazioni l'una dipendente dall'altra, e mi riferisco in particolare alle texture, mentre per ATi il numero è limitato alla quantità di dati contenuti nelle cache: infatti, ad esempio, i chip R4x0 e R3x0, hanno 8 texture register da 16 bit per un totale di massimo 4 dependent texture read a 32 bit, anche se, stando a quanto detto da ATi, l'ideale, per avere le migliori prestazioni, si ha non superando le due; nel caso di NV40 non c'è un limite teorico alle operazioni di dependent texture read). OT (il texture processor di ATi lavora a 16 e 32 bit) FINE OT
ATi ha superato questo limite con il ricorso al'f-buffer, che però richiede l'impiego di ulteriori cicli di clock nella migliore delle ipotesi (quando si tratta di una cache on chip).


per ora credo possa bastare

[yossarian]

p.s. per R520 ho come l'impressione che abbiano cambiato approccio