[THREAD UFFICIALE] Aspettando R700

[gervi]

Originariamente inviato da HackaB321

La parte in grassetto non è del tutto vera.
Andiamo un pò più in profondità: in R600 ci sono quattro cluster ognuno composto da 16 sp (e quindi da 16*5=80 ALU). Ogni cluster esegue ad ogni ciclo di clock una macroistruzione su 16 thread dello stesso tipo (dove con macroistruzione intendo un'istruzione composta fino a 5 istruzioni semplici indipendenti tra loro). Quindi ad ogni clock, c'è un gruppo di 16 pixel o vertex (o geometry quando ci saranno) thread che viene passato ad un cluster, ed ogni sp di quel cluster esegue la stessa macroistruzione su uno dei 16 pixel/vertex. Per questo R600 è in grado di eseguire 4 macroistruzioni differenti (fino a 20 istruzioni semplici) su 64 thread (16*4) contemporaneamente.
Tuttavia anche se ogni cluster è composto da 16sp , R600 (o meglio il thread processor di R600) indirizza in realtà 64 thread verso lo stesso cluster: detto altrimenti R600 ha una branching granularity di 64 threads (cioè crea dei "pacchetti" di 64 thread l'uno e li fa elaborare dallo stesso cluster). Ora, dato che in ogni cluster ci sono 16 sp (e ogni sp lavora su un pixel/vertex per volta) e dato che R600 "passa" al cluster gruppi di 64 vertex/pixel, saranno necessari 4 cicli di clock (64/16) prima che un intero gruppo venga elaborato.
Tuttavia le cose sono ancora un pò più incasinate di così () perchè (ed eccoci alla parte in grassetto che ho quotato) il thread processor di R600 passa contemporaneamente ad ogni cluster DUE gruppi di thread contemporanemente in modalità interleaving (http://it.wikipedia.org/wiki/Interleaving cioè prima uno e poi l'altro): questo significa che il cluster 1 riceve contemporaneamente 16 thread del gruppo 1 e 16 thread del gruppo 2 e il cluster li eseguirà in questo modo:

-clock 1 macroistruzione "pippo" su 16 thread del gruppo 1
-clock 2 macroistruzione "pluto" su 16 thread del gruppo 2
-clock 3 macroistruzione "pippo" su altri 16 thread del gruppo 1
-clock 4 macroistruzione "pluto" su altri 16 thread del gruppo 2
.....

Alla fine quindi saranno necessari 8 cicli di clock prima che i due gruppi di 64 threads l'uno siano stati elaborati interamente e il thread processor possa passare ad ogni cluster altri 2 gruppi di 64 thread.
A cosa serve tutto sto casino? (a poco visti i bench di R600 direte voi ): in realtà i vantaggi della modalità interleaving in R600 sono 3:

1)Riduzione delle latenze (impacchetto e spedisco e per 8 cicli sono tranquillo che il cluster sarà impegnato )
2)Maggior "tempo" a disposizione per il thread processor: il quale ha teoricamente 8 cicli di clock di tempo per l'arbitraggio dei thread (cioè per stabilre chi sarà il prossimo in coda a venir spedito nello shader core) e maggior tempo per assemblare le macoistruzioni.
3)Risoluzione delle dipendenze tra macroistruzioni diverse: siccome "pippo" e "pluto" sono composti fino a 5 istruzioni fra loro completamente indipendenti, è molto probabile che vi siano delle dipendenze tra i due e che pluto abbia bisogno dei risultati di pippo prima di essere eseguito:in questo modo si ha la certezza che l'esecuzione di due macroistruzioni tra loro dipendenti avvenga in perfetta sequenza.

E quindi in RV770 , questo è stato migliorato o no in definitiva???

Vedremo dei miglioramenti netti in DX 10??

Te lo chiedo poichè dai tuoi post, caro HackaB321, vedo che sei preparato in fatto di chip ati

[A.L.M.]

Originariamente inviato da HackaB321

La parte in grassetto non è del tutto vera.
Andiamo un pò più in profondità: in R600 ci sono quattro cluster ognuno composto da 16 sp (e quindi da 16*5=80 ALU). Ogni cluster esegue ad ogni ciclo di clock una macroistruzione su 16 thread dello stesso tipo (dove con macroistruzione intendo un'istruzione composta fino a 5 istruzioni semplici indipendenti tra loro). Quindi ad ogni clock, c'è un gruppo di 16 pixel o vertex (o geometry quando ci saranno) thread che viene passato ad un cluster, ed ogni sp di quel cluster esegue la stessa macroistruzione su uno dei 16 pixel/vertex. Per questo R600 è in grado di eseguire 4 macroistruzioni differenti (fino a 20 istruzioni semplici) su 64 thread (16*4) contemporaneamente.
Tuttavia anche se ogni cluster è composto da 16sp , R600 (o meglio il thread processor di R600) indirizza in realtà 64 thread verso lo stesso cluster: detto altrimenti R600 ha una branching granularity di 64 threads (cioè crea dei "pacchetti" di 64 thread l'uno e li fa elaborare dallo stesso cluster). Ora, dato che in ogni cluster ci sono 16 sp (e ogni sp lavora su un pixel/vertex per volta) e dato che R600 "passa" al cluster gruppi di 64 vertex/pixel, saranno necessari 4 cicli di clock (64/16) prima che un intero gruppo venga elaborato.
Tuttavia le cose sono ancora un pò più incasinate di così () perchè (ed eccoci alla parte in grassetto che ho quotato) il thread processor di R600 passa contemporaneamente ad ogni cluster DUE gruppi di thread contemporanemente in modalità interleaving (http://it.wikipedia.org/wiki/Interleaving cioè prima uno e poi l'altro): questo significa che il cluster 1 riceve contemporaneamente 16 thread del gruppo 1 e 16 thread del gruppo 2 e il cluster li eseguirà in questo modo:

-clock 1 macroistruzione "pippo" su 16 thread del gruppo 1
-clock 2 macroistruzione "pluto" su 16 thread del gruppo 2
-clock 3 macroistruzione "pippo" su altri 16 thread del gruppo 1
-clock 4 macroistruzione "pluto" su altri 16 thread del gruppo 2
.....

Alla fine quindi saranno necessari 8 cicli di clock prima che i due gruppi di 64 threads l'uno siano stati elaborati interamente e il thread processor possa passare ad ogni cluster altri 2 gruppi di 64 thread.
A cosa serve tutto sto casino? (a poco visti i bench di R600 direte voi ): in realtà i vantaggi della modalità interleaving in R600 sono 3:

1)Riduzione delle latenze (impacchetto e spedisco e per 8 cicli sono tranquillo che il cluster sarà impegnato )
2)Maggior "tempo" a disposizione per il thread processor: il quale ha teoricamente 8 cicli di clock di tempo per l'arbitraggio dei thread (cioè per stabilre chi sarà il prossimo in coda a venir spedito nello shader core) e maggior tempo per assemblare le macoistruzioni.
3)Risoluzione delle dipendenze tra macroistruzioni diverse: siccome "pippo" e "pluto" sono composti fino a 5 istruzioni fra loro completamente indipendenti, è molto probabile che vi siano delle dipendenze tra i due e che pluto abbia bisogno dei risultati di pippo prima di essere eseguito:in questo modo si ha la certezza che l'esecuzione di due macroistruzioni tra loro dipendenti avvenga in perfetta sequenza.

Io però parlavo di capacità teorica (anche se ho usato "reale" per contrapporla alla famosa missing, o almost-missing MUL di G80) di calcolo, mentre tu hai (in maniera molto corretta, mi pare) descritto come funzionano nella pratica le ALU di R600.
Se devi calcolare i Flops teorici di R600 e derivati fai clock*ALU*2, mentre nel caso di G80 moltiplico shader clock*SP*3.
Questo perchè 1 operazione MADD = 2 Flops, mentre una operazione MUL o una ADD = 1 Flop.
Ecco perchè dico che le alu di R600 possono calcolare fino a 2 flops per ciclo di clock, mentre in teoria G80 ha un'ALU MADD (2 Flops) ed una MUL (1 Flop).

[Marko91]

Originariamente inviato da HackaB321

La parte in grassetto non è del tutto vera.
Andiamo un pò più in profondità: in R600 ci sono quattro cluster ognuno composto da 16 sp (e quindi da 16*5=80 ALU). Ogni cluster esegue ad ogni ciclo di clock una macroistruzione su 16 thread dello stesso tipo (dove con macroistruzione intendo un'istruzione composta fino a 5 istruzioni semplici indipendenti tra loro). Quindi ad ogni clock, c'è un gruppo di 16 pixel o vertex (o geometry quando ci saranno) thread che viene passato ad un cluster, ed ogni sp di quel cluster esegue la stessa macroistruzione su uno dei 16 pixel/vertex. Per questo R600 è in grado di eseguire 4 macroistruzioni differenti (fino a 20 istruzioni semplici) su 64 thread (16*4) contemporaneamente.
Tuttavia anche se ogni cluster è composto da 16sp , R600 (o meglio il thread processor di R600) indirizza in realtà 64 thread verso lo stesso cluster: detto altrimenti R600 ha una branching granularity di 64 threads (cioè crea dei "pacchetti" di 64 thread l'uno e li fa elaborare dallo stesso cluster). Ora, dato che in ogni cluster ci sono 16 sp (e ogni sp lavora su un pixel/vertex per volta) e dato che R600 "passa" al cluster gruppi di 64 vertex/pixel, saranno necessari 4 cicli di clock (64/16) prima che un intero gruppo venga elaborato.
Tuttavia le cose sono ancora un pò più incasinate di così () perchè (ed eccoci alla parte in grassetto che ho quotato) il thread processor di R600 passa contemporaneamente ad ogni cluster DUE gruppi di thread contemporanemente in modalità interleaving (http://it.wikipedia.org/wiki/Interleaving cioè prima uno e poi l'altro): questo significa che il cluster 1 riceve contemporaneamente 16 thread del gruppo 1 e 16 thread del gruppo 2 e il cluster li eseguirà in questo modo:

-clock 1 macroistruzione "pippo" su 16 thread del gruppo 1
-clock 2 macroistruzione "pluto" su 16 thread del gruppo 2
-clock 3 macroistruzione "pippo" su altri 16 thread del gruppo 1
-clock 4 macroistruzione "pluto" su altri 16 thread del gruppo 2
.....

Alla fine quindi saranno necessari 8 cicli di clock prima che i due gruppi di 64 threads l'uno siano stati elaborati interamente e il thread processor possa passare ad ogni cluster altri 2 gruppi di 64 thread.
A cosa serve tutto sto casino? (a poco visti i bench di R600 direte voi ): in realtà i vantaggi della modalità interleaving in R600 sono 3:

1)Riduzione delle latenze (impacchetto e spedisco e per 8 cicli sono tranquillo che il cluster sarà impegnato )
2)Maggior "tempo" a disposizione per il thread processor: il quale ha teoricamente 8 cicli di clock di tempo per l'arbitraggio dei thread (cioè per stabilre chi sarà il prossimo in coda a venir spedito nello shader core) e maggior tempo per assemblare le macoistruzioni.
3)Risoluzione delle dipendenze tra macroistruzioni diverse: siccome "pippo" e "pluto" sono composti fino a 5 istruzioni fra loro completamente indipendenti, è molto probabile che vi siano delle dipendenze tra i due e che pluto abbia bisogno dei risultati di pippo prima di essere eseguito:in questo modo si ha la certezza che l'esecuzione di due macroistruzioni tra loro dipendenti avvenga in perfetta sequenza.

Bello. Ad Ati piace farlo complicato
Una cosa non ho capito. Se le 5 ALU sono super-scalari e indipendenti l'una dall'altra, perchè non possono elaborare 5 pixel singoli a ciclo di clock?
Se non sbaglio , le 5 istruzioni devono appartenere allo stesso pixel o allo stesso vertex. Ed è qui il problema di efficienza di tale architettura, che nel migliore dei casi è molto performante ma nel peggiore è come se avesse solo 64ALU.

[leoneazzurro]

Originariamente inviato da Marko91

Bello. Ad Ati piace farlo complicato
Una cosa non ho capito. Se le 5 ALU sono super-scalari e indipendenti l'una dall'altra, perchè non possono elaborare 5 pixel singoli a ciclo di clock?
Se non sbaglio , le 5 istruzioni devono appartenere allo stesso pixel o allo stesso vertex. Ed è qui il problema di efficienza di tale architettura, che nel migliore dei casi è molto performante ma nel peggiore è come se avesse solo 64ALU.

Perchè non sono realmente indipendenti, sono superscalari.
Anzi, in realtà i processori "reali" di R600 sono soltanto 4, ed infatti sono referenziati 4 SIMD da 16 "SP" superscalari di ampiezza 5.
Ma occhio, perchè anche G80 e derivati, nonostante siano spacciate per architetture "scalari pure", in realtà sono costituiti da unità SIMD; in particolare G80 e G92 hanno 16 SIMD di ampiezza 8, 2 per cluster (GT200 sembra ne avrà 3 per cluster).

[appleroof]

Originariamente inviato da Ratatosk

Guarda, che non possa far testo in quanto caso singolo posso essere daccordo, ma non è nebuloso (il passo mancante, non si è mai parlato di effetto, manca perché in DX10.1 non è necessario eseguirlo, non perché sia un errore non eseguirlo) e soprattutto il miglioramento è effettivamente mirabolante (35% su RV670).

abbiamo assistito a miglioramenti del genere grazie a driver ottimizzati su un singolo gioco decine di volte, eppure, pur essendo estremamente soddisfatti riguardo a quel gioco, non abbiamo gridato al miracolo (mi pare inoltre di ricordare che in quel gioco rv670 non applicasse l'AF per problemi di driver)

sai meglio di me che cose del genere devono essere costanti per poter dire con certezza che "quella vga và meglio dell'altra" sempre, e finora per r600 e soci solo teoria, è obiettivamente così, non è una opinione.

[tra l'altro qui vedo un miglioramento medio tra il 9.15% ed il 18,69%, non il 35%

http://www.rage3d.com/articles/assas.../index.php?p=3 ]

quanto al "mai parlato di effetto", evidentemente pur seguendo il forum e queste cose come me assiduamente, hai la memoria corta

http://hwupgrade.it/forum/showpost.p...postcount=1904

cmq forse è un effetto di post-processing, forse un passaggio di rendering mancante, non trovo nulla che dice che in dx10.1 non sia necessario, ma se mi passi un link sarei felice di impararlo

infine, non solo io lo definisco "nebuloso", il bug in questione

The good news is that the dust-bug......

http://www.rage3d.com/articles/assas.../index.php?p=3

[leoneazzurro]

http://techreport.com/discussions.x/14707

[appleroof]

Originariamente inviato da leoneazzurro

http://techreport.com/discussions.x/14707

Va bene, diamo per buono allora che il path dx10.1 in AC dia un 20% di prestazioni in più a rv670 in quel gioco, e che il cattivone Nvidia con i suoi dollars sonanti abbia soppresso questo fantastico exploit
possiamo stare ore a discutere sulla moralità o meno di questo aspetto, su questo ognuno di noi avrà la sua opinione ma

può questo far affermare che il chip sia più performante di g80 in assoluto? Parliamo poi di dx10.1, che non è supportato da g80. Siamo più precisi: esistono allora almeno 5 applicazioni dx10 che girano meglio, a parità di condizioni, su rv670 piuttosto che su g92? Si può dunque affermare senza ombra di dubbio, ora come ora, che le gpu Ati siano migliori di quelle Nvidia in applicazioni dx10?

[leoneazzurro]

Originariamente inviato da appleroof

Va bene, diamo per buono allora che il path dx10.1 in AC dia un 20% di prestazioni in più a rv670 in quel gioco, e che il cattivone Nvidia con i suoi dollars sonanti abbia soppresso questo fantastico exploit
possiamo stare ore a discutere sulla moralità o meno di questo aspetto, su questo ognuno di noi avrà la sua opinione ma

può questo far affermare che il chip sia più performante di g80 in assoluto? Parliamo poi di dx10.1, che non è supportato da g80. Siamo più precisi: esistono allora almeno 5 applicazioni dx10 che girano meglio, a parità di condizioni, su rv670 piuttosto che su g92? Si può dunque affermare senza ombra di dubbio, ora come ora, che le gpu Ati siano migliori di quelle Nvidia in applicazioni dx10?

No, anzi in genere è vero il contrario. il discorso però è un altro, ossia: se una GPU ha una possibilità che può venire utilizzata senza troppi problemi per migliorare le sue performances e/o la qualità visiva, perchè i suoi possessori devono vedersi privati della possibilità di avere il proprio prodotto funzionare al meglio delle proprie possibilità, a prescindere da sterili confronti prestazionali con prodotti di altra marca?

[The_SaN]

Originariamente inviato da leoneazzurro

No, anzi in genere è vero il contrario. il discorso però è un altro, ossia: se una GPU ha una possibilità che può venire utilizzata senza troppi problemi per migliorare le sue performances e/o la qualità visiva, perchè i suoi possessori devono vedersi privati della possibilità di avere il proprio prodotto funzionare al meglio delle proprie possibilità, a prescindere da sterili confronti prestazionali con prodotti di altra marca?

É proprio questo il succo del discorso.
Non si parla di chi vince o chi perde...o di barrette piú lunghe.
Si parla di features di una scheda che possono essere utilizzate per incrementare le performanceo la qualitá.
E che non possono essere usate a causa di un motivo non molto moralmente corretto.

[A.L.M.]

Originariamente inviato da Marko91

Bello. Ad Ati piace farlo complicato
Una cosa non ho capito. Se le 5 ALU sono super-scalari e indipendenti l'una dall'altra, perchè non possono elaborare 5 pixel singoli a ciclo di clock?
Se non sbaglio , le 5 istruzioni devono appartenere allo stesso pixel o allo stesso vertex. Ed è qui il problema di efficienza di tale architettura, che nel migliore dei casi è molto performante ma nel peggiore è come se avesse solo 64ALU.

Non è proprio detto. Come ho scritto prima, in teoria, se driver ed i giochi venissero programmati in modo adeguato, si potrebbe fare in modo da far "accodare" le istruzioni in modo da evitare i tempi morti, se non mi sbaglio.
Il problema è proprio quello. R600 è solo in teoria self-balancing, mentre un'architettura più tendente alla scalare pura come G80 lo è per natura (tutte le unità sono perfettamente uguali ed indipendenti, seppur gruppate in arrays).
ATI e NVidia hanno scelto 2 strade molto diverse, a partire dalla scorsa generazione di schede. In precedenza le architetture, soprattutto in termini di ALU, erano più comparabili. Ora, invece:
- Nvidia ha perseguito l'idea di shader unificati fino in fondo, rendendo le unità completamente indipendenti: questo di fatto è uno stacco netto rispetto al passato (da un certo punto di vista maggiore rispetto ad R600) ed enfatizza i benefici di avere shaders unici per tutti i tipi di operazioni di shading. Vantaggi: si è sempre molto vicini allo sfruttamento del throughput massimo di capacità di calcolo.
Svantaggi: tale percentuale di sfruttamento decresce al crescere della lunghezza degli shaders, nel caso di operazioni su funzioni trascendentali diventa molto inefficiente, necessita di molto spazio in termini di die-size.
- ATI invece, se da un lato si è mantenuta più fedele alla tradizione (shader più tendenti al parallelismo) dall'altro ha cercato di rendere il più possibile indipendenti le alu all'interno di ogni shader unit. Ha quindi esasperato il parallelismo di ogni shader unit, lanciando la prima gpu non RISC (infatti R600 è VLIW), credo.
Vantaggi: in teoria parecchi. Spazio richiesto inferiore (perchè si può fare lo stesso lavoro con meno unità), clocks inferiori, efficienza che cresce con l'aumentare delle dimensioni dei vettori da "maneggiare", ecc...
Svantaggi: altrettanti. Necessità di un fine-tuning pazzesco sui drivers, perchè senza si rischia di essere spesso in situazione di svantaggio rispetto ad archietture come quella di G80, variabilità forte delle prestazioni a seconda delle applicazioni per lo stesso motivo di cui sopra, difficoltà nel caso di operazioni scalari dipendenti tra di loro, ecc...

Un esempio che credo possa essere d'aiuto:


Fonte: B3D


Fonte: mia elaborazione su dati B3D

Penso si noti come in effetti la varianza in termini di throughput di calcolo tra diverse operazioni sia in genere, eccezion fatta per le special operations, molto più bassa in G80.

[HackaB321]

Originariamente inviato da gervi

E quindi in RV770 , questo è stato migliorato o no in definitiva???

Vedremo dei miglioramenti netti in DX 10??

Te lo chiedo poichè dai tuoi post, caro HackaB321, vedo che sei preparato in fatto di chip ati

ancora nulla si sa su come sarà organizzato internamente RV770. Tra l'altro in RV670 esiste una parità tra il numero di sp per cluster (16) e il numero di TMU (16) che non si capisce come avranno potuto mantenere in RV770 con 32 TFU, 96 sp totali e la braching granularity di 64. Vedremo.
Per quanto riguarda i veri giochi dx10 sono curioso anche di vedere quali saranno le prestazioni di R600 e figli specie quando verranno usati i gs, shaders nei quali l'architettura ATi eccelle.

Originariamente inviato da A.L.M.

Io però parlavo di capacità teorica (anche se ho usato "reale" per contrapporla alla famosa missing, o almost-missing MUL di G80) di calcolo, mentre tu hai (in maniera molto corretta, mi pare) descritto come funzionano nella pratica le ALU di R600.
Se devi calcolare i Flops teorici di R600 e derivati fai clock*ALU*2, mentre nel caso di G80 moltiplico shader clock*SP*3.
Questo perchè 1 operazione MADD = 2 Flops, mentre una operazione MUL o una ADD = 1 Flop.
Ecco perchè dico che le alu di R600 possono calcolare fino a 2 flops per ciclo di clock, mentre in teoria G80 ha un'ALU MADD (2 Flops) ed una MUL (1 Flop).

Ah ok . L'importante era per me specificare che le due operazioni per ALU/clock sono solo teoriche (e di conseguenza i 475Gflop)

Originariamente inviato da Marko91

Bello. Ad Ati piace farlo complicato
Una cosa non ho capito. Se le 5 ALU sono super-scalari e indipendenti l'una dall'altra, perchè non possono elaborare 5 pixel singoli a ciclo di clock?
Se non sbaglio , le 5 istruzioni devono appartenere allo stesso pixel o allo stesso vertex. Ed è qui il problema di efficienza di tale architettura, che nel migliore dei casi è molto performante ma nel peggiore è come se avesse solo 64ALU.

Perchè, come dice leoneazzurro, in R600 "l'indipendenza" assoluta di calcolo esiste solo a livello di cluster (come in G80). Solo cluster diversi possono eseguire istruzioni diverse su thread diversi nello stesso clock (come in G80). In più gli sp di R600, a differenza di quelli di G80, possono anche eseguire in parallelo più istruzioni ma sempre su uno stesso pixel o vertex. G80 esegue le istruzioni in parallelo (stessa istruzione su thread diversi) solo a livello di cluster e all'interno di questo esegue sempre le istruzioni una di seguito all'altro (sfruttando la sua velocità di clock), R600 estrapola il parallelismo sia a livello di cluster (stessa istruzione su tanti dati) sia a livello di sp (più istruzioni sullo stesso dato).

Originariamente inviato da appleroof

quanto al "mai parlato di effetto", evidentemente pur seguendo il forum e queste cose come me assiduamente, hai la memoria corta

http://hwupgrade.it/forum/showpost.p...postcount=1904

E' un qualcosa che quando manca nessuno se ne accorge. Mi sembra che questo sia più importante di come lo vogliamo chiamare.

[leoneazzurro]

in R600 e derivati le istruzioni possono anche essere eseguite in "serie" anzichè in "parallelo", ossia invece di avere una serie di dati che arrivain parallelo sui 5 componenti dell'ALU superscalare, arrivano 5 componenti presi da 5 serie di dati (con limiti di dipendenza, ovviamente). Questo sempre per migliorare il grado di utilizzo delle ALU ma che va acomplicare la schedulazione delle istruzioni.

[A.L.M.]

Originariamente inviato da HackaB321

Ah ok . L'importante era per me specificare che le due operazioni per ALU/clock sono solo teoriche (e di conseguenza i 475Gflop)

Ma questo vale per tutte le architetture.

[HackaB321]

Originariamente inviato da A.L.M.

- Nvidia ha perseguito l'idea di shader unificati fino in fondo, rendendo le unità completamente indipendenti: questo di fatto è uno stacco netto rispetto al passato (da un certo punto di vista maggiore rispetto ad R600) ed enfatizza i benefici di avere shaders unici per tutti i tipi di operazioni di shading.

L'indipendenza degli shaders di G80 non è "assoluta", solo i cluster sono unità completamente indipendenti (in G80 come e più che in R600).
Questo perchè anche in G80, sp dello stesso cluster lavorano sullo stesso batch quindi sempre su thread dello stesso tipo per ciclo di clock : non succederà mai, in altre parole, che 1 sp di un cluster lavora su un vertex e un sp dello stesso cluster lavora su un pixel nello stesso clock (come nel caso di unità realmente indipendenti).

[HackaB321]

Originariamente inviato da A.L.M.

Ma questo vale per tutte le architetture.

certo , ma se scrivi "reale" io capisco qualcosa di diverso da "teorico". Adesso ho capito che cosa intendevi

[A.L.M.]

Originariamente inviato da HackaB321

L'indipendenza degli shaders di G80 non è "assoluta", solo i cluster sono unità completamente indipendenti (in G80 come e più che in R600).
Questo perchè anche in G80, sp dello stesso cluster lavorano sullo stesso batch quindi sempre su thread dello stesso tipo per ciclo di clock : non succederà mai, in altre parole, che 1 sp di un cluster lavora su un vertex e un sp dello stesso cluster lavora su un pixel nello stesso clock (come nel caso di unità realmente indipendenti).

Stavo sempre parlando di operazioni matematiche (e quindi di flops), e non di shader ops.

[Kharonte85]

Originariamente inviato da The_SaN

É proprio questo il succo del discorso.
Non si parla di chi vince o chi perde...o di barrette piú lunghe.
Si parla di features di una scheda che possono essere utilizzate per incrementare le performanceo la qualitá.
E che non possono essere usate a causa di un motivo non molto moralmente corretto.

"E' scorretto per chi paga...ma non per chi incassa..." Cit.

AMD/ATI a parti invertite se ne avesse l'opportunità farebbe lo stesso...io ho sempre pensato che la forte partnership che è stata in grado di creare Nvidia attorno a se sia comunque un merito, in questo caso indubbiamente danneggia si' la diretta concorrente e chi ha creduto nelle dx10.1...ma altrettanto onestamente non mi pare un balzo tecnologico o un miglioramento di qualità tale da generare vergogna in senso generale (non credo che rallenti lo sviluppo grafico di un fico secco, anche perche' a quello ci pensano gia' le console... )...inoltre non è affatto detto che con altri giochi le performance aumentino in quel modo, io credo che come si puo' notare (come stiamo facendo) che la faccenda non quadri affatto si dovrebbe anche ammettere pero' che non è abbastanza chiara per emettere sentenze.

in ogni caso alle aziende caritatevoli non ci ho mai creduto e meno che meno mi faccio problemi su cio' che sta dietro ad un prodotto commerciale, altrimenti dovrei smettere di andare in giro in macchina dato che la benzina è sporca di sangue.

In questo sono un fottuto egoista

[<^MORFEO^>]

Originariamente inviato da leoneazzurro

No, anzi in genere è vero il contrario. il discorso però è un altro, ossia: se una GPU ha una possibilità che può venire utilizzata senza troppi problemi per migliorare le sue performances e/o la qualità visiva, perchè i suoi possessori devono vedersi privati della possibilità di avere il proprio prodotto funzionare al meglio delle proprie possibilità, a prescindere da sterili confronti prestazionali con prodotti di altra marca?

Questo discorsetto bisognerebbe spedirlo per e-mail direttamente a nVidia!

[The_SaN]

Originariamente inviato da Kharonte85

"E' scorretto per chi paga...ma non per chi incassa..." Cit.

AMD/ATI a parti invertite se ne avesse l'opportunità farebbe lo stesso...io ho sempre pensato che la forte partnership che è stata in grado di creare Nvidia attorno a se sia comunque un merito, in questo caso indubbiamente danneggia si' la diretta concorrente e chi ha creduto nelle dx10.1...ma altrettanto onestamente non mi pare un balzo tecnologico o un miglioramento di qualità tale da generare vergogna in senso generale (non credo che rallenti lo sviluppo grafico di un fico secco, anche perche' a quello ci pensano gia' le console... )...inoltre non è affatto detto che con altri giochi le performance aumentino in quel modo, io credo che come si puo' notare (come stiamo facendo) che la faccenda non quadri affatto si dovrebbe anche ammettere pero' che non è abbastanza chiara per emettere sentenze.

in ogni caso alle aziende caritatevoli non ci ho mai creduto e meno che meno mi faccio problemi su cio' che sta dietro ad un prodotto commerciale, altrimenti dovrei smettere di andare in giro in macchina dato che la benzina è sporca di sangue.

In questo sono un fottuto egoista

Certo, con quello che ho detto non intendo che AMD é buona e nvidia é cattiva...
Sono aziende che lottano per la sopravvivenza e per la leadership di un mercato molto ampio.
In questi casi (purtroppo) tutto é valido, visti i soldi che girano...

Piú che altro a me questa situazione sta un po' sui cosiddetti per il fatto che mi piace tutto quello che puó apportare un miglioramento (come nel caso delle performance dell' AA con le dx10.1), e vedere il tutto sfumare a causa di un gruzzolo di soldi (per quanto grande) da un certo dispiacere.

Poi vabbé, di sicuro non compro una scheda solo per quello...se nVidia va di piú a paritá di costo piglio quella
Ma a paritá di performance e prezzo prendo la dx10.1

[The_SaN]

http://www.forumpcs.com.br/noticia.php?b=237680

Dalla piú importante fonte brasiliana di informatica, la migliore del sudamerica dopo chile hardware.
In pratica conferma il cancellamento della 4850 gddr5.
Il motivo sarebbe uno solo: le gddr5 costano troppo per quello che danno alla 4850. Il che le metterebbe troppo vicine come prezzo alla 4870 senza peró superare di molto la gemella gddr3.

Confermata anche la data di lancio delle 4850 e 4870, il 16 giugno. Mentre un non meglio specificato "piú tardi" per le 4870x2.