gflops ati e nvidia

[darthrevanri]

ciao a tutti è da un pò che mi chiedevo una cosa ma perche ati ha più gflops e va piu lenta di nvidia nei giochi?
hd 4870 1,2 tflops
gtx 280 900 gflops

[yossarian]

si tratta di architetture completamente differenti e non comparabili sulla sola base delle Gflops. In GT200 e G8x gli stream processor (SP) sono di tipo scalare e hanno alu in grado di svolgere una MADD (moltiplicazione + addizione), una MUL e un'operazione di controllo dei flussi per il dynamic branching (DB) in serie. Questo comporta che la gestione dell'ILP (instruction level parallelism) avvenga in automatico, da parte degli stessi thread dispatch processor (arbiter più sequencer) che si occupano di gestire il bilanciamento dei carichi di lavoro.
In RV770, R600 e RV670, gli SP sono di tipo vliw, ognuno composto da 5 alu in grado di svolgere una MADD e da un circuito di controllo dei flussi per il DB in parallelo. Questo comporta che i thread dispatch processor gestiscono il bilanciamento dei carichi di lavoro tra gli SP ma non l'ILP che viene gestita a livello di compilatore (e quindi via SW e non HW). Quindi, di fatto, i chip nVIDIA sono progettati per lavorare meglio con codice di tipo seriale (ogni sp può operare su più istruzioni in serie) mentre quelli ATi sono più improntati al calcolo parallelo. Oltre a questo ci sono altre difefrenze architetturali che possono influire sul rendimento con i giochi. Ad esempio i chip nVIDIA hanno un maggior numero di unità di texture filtering e ciò comporta che sono in grado di lavorare su più texel per ciclo (anche se lavorano a frequenze più basse rispetto a quelle dei chip ATi e perciò svolgono meno cicli in un secondo). I chip ATi nescondono meglio le latenze relative alle operazioni di texturing (hanno texture cache di tipo fully associative e non set associetive come quelli di nVIDIA, e hanno più unità di texture address). Altra differenza è relativa alle rop's o RBE. I chip nVIDIA sono ottimizzati avere uno z-fillrate molto elevato (utilizzano come punti di uscita verso la z-buffer sia la branca delle rop's deputata a svolgere z-ops che quella deputata e svolgere color ops. I dati dello z-buffer sono utilizzati per calcolare la distanza degli oggetti dall'osservatore e, quindi, per le operazioni di rimozione dei poligoni nascosti. I chip ATi sono ottimizzati per rendere al meglio con le operazioni di antialiasing, sia di tipo box filter (quello svolto all'interno delle rop's) che di tipo custom, con algoritmi non necessariamente di tipo lienare (con le operazioni di resolve svolte a livello di shader core). In particolare, RV670 ed RV770 hanno la possibilità di utilizzare più render target per le operazioni di MSAA box filter (opzione prevista dalle dx10.1), il che permette di avere, ad esempio, MSAA 4x con impatto quasi nullo sulle prestazioni (un esempio si è visto con la patch 1.01 di assassin creed, con cui una RV770 guadagnava quasi il 25% rispetto alle pretazioni attuali e una hd4850 superava, a 1680x1050, con msaa 4x, una GT280; in maniera alquanto misteriosa , la successiva patch 1.02, cancellava la possibilità di utilizzare MRT per fare MSAA con motori che fanno uso di deferred rendering, come l'UE3 o quello di stalker, tornando all'utilizzo di render to texture per rendere i valori contenuti nello z-buffer fruibili per operazioni successive).
Riassumendo, da un lato si ha un'architettura (quella di nVIDIA) che lavora molto bene con codice di tipo seriale (molte operazioni di tipo dependent read, cioè in cui la successiva operazioni dipende dal risultato della precedente), dall'altro un'architettura che lavora molto meglio con codice parallelo, in cui la gestione dell'ILP è affidata al compilatore che non fa altro che raccogliere più istruzioni relative allo stesso thread in una macro istruzione da dare in pasto ad uno SP. A livello di efficienza, l'architettura di nVIDIA è meno dipendente dal codice da elaborare (il delta tra prestazioni massime e minime ottenibili non è molto ampio), quella di ATi può variare da un massimo di 800 flops per ciclo ad un minimo di 160 flops per ciclo (1600 e 320 se consideriamo che una MADD è composta da due operazioni a cui andrebbero aggiunte le operazioni di branching) . Con istruzioni di tipo geometrico che sono strutturate in modo da avere più istruzioni indipendenti relative ad uno stesso thread, i chip ATi sono molto più veloci, con istruzioni relative ai pixel shader, dove è possibile avere sia più istruzioni indipendenti che istruzioni di tipo scalare dipendenti le une dalle altre, sono avvantaggiati i chip nVIDIA.

[massimomarc]

abbastanza esauriente come risposta direi

[Brenta987]

Il ragazzo è preparato.....

ma parla troppo complesso.....

[darthrevanri]

Originariamente inviato da yossarian

si tratta di architetture completamente differenti e non comparabili sulla sola base delle Gflops. In GT200 e G8x gli strem processor (SP) sono di tipo scalare e hanno alu in grado di svolgere una MADD (moltiplicazione + addizione), una MUL e un'operazione di controllo dei flussi per il dynamic branching (DB) in serie. Questo comporta che la gestione dell'ILP (instruction level parallelism) avvenga in automatico, da parte degli stessi thread dispatch processor (arbiter più sequencer) che si occupano di gestire il bilanciamento dei carichi di lavoro.
In RV770, R600 e RV670, gli SP sono di tipo vliw, ognuno composto da 5 alu in grado di svolgere una MADD e da un circuito di controllo dei flussi per il DB in parallelo. Questo comporta che i thread dispatch processor gestiscono il bilanciamento dei carichi di lavoro tra gli SP ma non l'ILP che viene gestita a livello di compilatore (e quindi via SW e non HW). Quindi, di fatto, i chip nVIDIA sono progettati per lavorare meglio con codice di tipo seriale (ogni sp può operare su più istruzioni in serie) mentre quelli ATi sono più improntati al calcolo parallelo. Oltre a questo ci sono altre difefrenze architetturali che possono influire sul rendimento con i giochi. Ad esempio i chip nVIDIA hanno un maggior numero di unità di texture filtering e ciò comporta che sono in grado di lavorare su più texel per ciclo (anche se lavorano a frequenze più basse rispetto a quelle dei chip ATi e perciò svolgono meno cicli in un secondo). I chip ATi nescondono meglio le latenze relative alle operazioni di texturing (hanno texture cache di tipo fully associative e non set associetive come quelli di nVIDIA, e hanno più unità di texture address). Altra differenza è relativa alle rop's o RBE. I chip nVIDIA sono ottimizzati avere uno z-fillrate molto elevato (utilizzano come punti di uscita verso la z-buffer sia la branca delle rop's deputata a svolgere z-ops che quella deputata e svolgere color ops. I dati dello z-buffer sono utilizzati per calcolare la distanza degli oggetti dall'osservatore e, quindi, per le operazioni di rimozione dei poligoni nascosti. I chip ATi sono ottimizzati per rendere al meglio con le operazioni di antialiasing, sia di tipo box filter (quello svolto all'interno delle rop's) che di tipo custom, con algoritmi non necessariamente di tipo lienare (con le operazioni di resolve svolte a livello di shader core). In particolare, RV670 ed RV770 hanno la possibilità di utilizzare più render target per le operazioni di MSAA box filter (opzione prevista dalle dx10.1), il che permette di avere, ad esempio, MSAA 4x con impatto quasi nullo sulle prestazioni (un esempio si è visto con la patch 1.01 di assassin creed, con cui una RV770 guadagnava quasi il 25% rispetto alle pretazioni attuali e una hd4850 superava, a 1680x1050, con msaa 4x, una GT280; in maniera alquanto misteriosa , la successiva patch 1.02, cancellava la possibilità di utilizzare MRT per fare MSAA con motori che fanno uso di deferred rendering, come l'UE3 o quello di stalker, tornando all'utilizzo di render to texture per rendere i valori contenuti nello z-buffer fruibili per operazioni successive).
Riassumendo, da un lato si ha un'architettura (quella di nVIDIA) che lavora molto bene con codice di tipo seriale (molte operazioni di tipo dependent read, cioè in cui la successiva operazioni dipende dal risultato della precedente), dall'altro un'architettura che lavora molto meglio con codice parallelo, in cui la gestione dell'ILP è affidata al compilatore che non fa altro che raccogliere più istruzioni relative allo stesso thread in una macro istruzione da dare in pasto ad uno SP. A livello di efficienza, l'architettura di nVIDIA è meno dipendente dal codice da elaborare (il delta tra prestazioni massime e minime ottenibili non è molto ampio), quella di ATi può variare da un massimo di 800 flops per ciclo ad un minimo di 160 flops per ciclo (1600 e 320 se consideriamo che una MADD è composta da due operazioni a cui andrebbero aggiunte le operazioni di branching) . Con istruzioni di tipo geometrico che sono strutturate in modo da avere più istruzioni indipendenti relative ad uno stesso thread, i chip ATi sono molto più veloci, con istruzioni relative ai pixel shader, dove è possibile avere sia più istruzioni indipendenti che istruzioni di tipo scalare dipendenti le une dalle altre, sono avvantaggiati i chip nVIDIA.

grazie per la risposta diciamo che qualcosina ci ho capito

[Ale985]

Originariamente inviato da massimomarc

abbastanza esauriente come risposta direi

concordo

però se non si ha una laurea in informatica ed ingegneria elettronica non è proprio facilissimo comprendere ciò che ha scritto

[robertogl]

sono in ferie,ho tempo di leggere la risposta di yossarian

Originariamente inviato da yossarian

.....hd4850 superava, a 1680x1050, con msaa 4x, una GT280; in maniera alquanto misteriosa , la successiva patch 1.02, cancellava la possibilità di utilizzare MRT per fare MSAA con motori che fanno uso di deferred rendering, come l'UE3 o quello di stalker..... .

[yossarian]

Originariamente inviato da Brenta987

Il ragazzo è preparato.....

ma parla troppo complesso.....

Originariamente inviato da darthrevanri

grazie per la risposta diciamo che qualcosina ci ho capito

Originariamente inviato da Ale985

concordo

però se non si ha una laurea in informatica ed ingegneria elettronica non è proprio facilissimo comprendere ciò che ha scritto

in realtà sono gli argomenti in sé ad essere molto complessi e quello che ho scritto è solo una grossolana semplificazione che trascura molti aspetti, anche rilevanti, delle differenti architetture e delle loro evoluzioni.
Si tratta, in effetti, di argomenti per addetti ai lavori che se si cerca di semplificare troppo si rischia di essere banali e poco rigorosi, se ci si attiene ad un minimo di rigore si diventa incomprensibili ai più.

[Brenta987]

Originariamente inviato da yossarian

in realtà sono gli argomenti in sé ad essere molto complessi e quello che ho scritto è solo una grossolana semplificazione che trascura molti aspetti, anche rilevanti, delle differenti architetture e delle loro evoluzioni.
Si tratta, in effetti, di argomenti per addetti ai lavori che se si cerca di semplificare troppo si rischia di essere banali e poco rigorosi, se ci si attiene ad un minimo di rigore si diventa incomprensibili ai più.

E per fortuna che hai semplificato...

già ci ho capito poco così...(troppe sigle e abbreviazioni... )

[yossarian]

Originariamente inviato da Brenta987

E per fortuna che hai semplificato...

già ci ho capito poco così...(troppe sigle e abbreviazioni... )

se hai difficoltà a capire qualcosa chiedi pure; cerco di risponderti nel modo più semplice. Purtroppo per parlare di questi argomenti si dovrebbe iniziare a parlare di come funziona gli engine 3D e di come gli stessi si siano evoluti nel tempo, tenendo conto dell'evoluzione delle API di riferimento

[ATi7500]

Yoss, mi sai dire perchè un'azienda dovrebbe preferire un approccio VLIW ad uno standard? Cioè si è consapevoli da subito delle difficoltà che si avranno nel programmare il compilatore a seconda delle applicazioni, o semplicemente si aspetta, sperando in applicazioni "facili" da parallelizzare? Lo dico perchè ATi non ha una grossa penetrazione nel mercato (o almeno non quanto nVidia), e i developer guardano sopratutto alla base di utenza, non all'eleganza di un'architettura..

bYeZ!

[yossarian]

Originariamente inviato da ATi7500

Yoss, mi sai dire perchè un'azienda dovrebbe preferire un approccio VLIW ad uno standard? Cioè si è consapevoli da subito delle difficoltà che si avranno nel programmare il compilatore a seconda delle applicazioni, o semplicemente si aspetta, sperando in applicazioni "facili" da parallelizzare? Lo dico perchè ATi non ha una grossa penetrazione nel mercato (o almeno non quanto nVidia), e i developer guardano sopratutto alla base di utenza, non all'eleganza di un'architettura..

bYeZ!

ci sono alcune ragioni che riguardano le evoluzioni future del SW (shader più lunghi, con più istruzioni per thread che favorirebbero un'architettura più votata al calcolo parallelo; non è un caso che nel test perlin noise che altro non è che l'applicazione di 48 texture con 449 operazioni matematiche, ovvero il massimo previsto dallo sm3.0, RV770, anche in versione 4850, è sopra a gt200 anche in versione 280, e nel test shader math che è l'equivalente del 3dmark vantage, 4870 e 280 sono alla pari e la 4850 leggermente sopra all 260). Nei calcoli geometrici, in cui si fa spesso uso di dati di tipo vettoriale (e quindi sono paralleli per antonomasia) un'architettura con alu di tipo vect risulta la migliore, ma la vliw può ottenere le stesse prestazioni in quanto non è difficil, per il compilatore, mettere insieme 5 istruzioni indipendenti relative allo stesso thread. L'adozione di antialiasing di tipo custom con resolve via shader, aumenterà il numero di istruzioni indipendenti per thread (e favorirà ancora di più un'architettura vliw).
Per quanto riguarda il lato HW, se hai notato, ATi non ha mai adottato architetture di tipo superscalare con alu indipendenti fp32, ma è passata da alu di tipo vect3+scalar ad alu di tipo vliw. Questo perchè la logica di controllo di alu scalari come quelle di nVIDIA è molto più complessa. Ulteriore matovo, un'architettura vliw è più flessibile di una di tipo vect e richiede un minor numero di registri (fino ad 1/3 rispetto ad una scalare tipo quella di nVIDIA); inoltre, ogni singola istruzione richiede meno cicli. Lo svantaggio, ovviamente è la minor efficienza, che però è compensata dal fatto che, avendo uno shader core molto meno ingombrante, è possibile metterci dentro monte più unità di calcolo rispetto a quanto non sia possibile fare con architetture di tipo scalare. Ultimo vantaggio, un'architettura come quella di RV770 non necessità di alu dedicate per eseguire i calcoli in fp64. Questo permette di realiizare chip molto piccoli come die size (e quindi molto economici) con un elevato numero di unità di calcolo all'interno e con un potenziale non ancora del tutto espresso (contrariamente ai chip NV che, proprio in virtù della loro già elevata efficienza, non hanno molto altro da dare a livello prestazionale con codice più complesso)

[ATi7500]

grazie, sempre esaustivo
un'ultima cosa riguardo R600\RV670, il primo con interfaccia di memoria a 512bit, il secondo a 256bit. Un ritorno sui propri passi o una modifica "dovuta"? (la domanda in sottofondo: è un chip bandwidth limited o no, e perchè?)

bYeZ!

[ATi7500]

Originariamente inviato da yossarian

ci sono alcune ragioni che riguardano le evoluzioni future del SW (shader più lunghi, con più istruzioni per thread che favorirebbero un'architettura più votata al calcolo parallelo; non è un caso che nel test perlin noise che altro non è che l'applicazione di 48 texture con 449 operazioni matematiche, ovvero il massimo previsto dallo sm3.0, RV770, anche in versione 4850, è sopra a gt200 anche in versione 280, e nel test shader math che è l'equivalente del 3dmark vantage, 4870 e 280 sono alla pari e la 4850 leggermente sopra all 260). Nei calcoli geometrici, in cui si fa spesso uso di dati di tipo vettoriale (e quindi sono paralleli per antonomasia) un'architettura con alu di tipo vect risulta la migliore, ma la vliw può ottenere le stesse prestazioni in quanto non è difficil, per il compilatore, mettere insieme 5 istruzioni indipendenti relative allo stesso thread. L'adozione di antialiasing di tipo custom con resolve via shader, aumenterà il numero di istruzioni indipendenti per thread (e favorirà ancora di più un'architettura vliw).
Per quanto riguarda il lato HW, se hai notato, ATi non ha mai adottato architetture di tipo superscalare con alu indipendenti fp32, ma è passata da alu di tipo vect3+scalar ad alu di tipo vliw. Questo perchè la logica di controllo di alu scalari come quelle di nVIDIA è molto più complessa. Ulteriore matovo, un'architettura vliw è più flessibile di una di tipo vect e richiede un minor numero di registri (fino ad 1/3 rispetto ad una scalare tipo quella di nVIDIA); inoltre, ogni singola istruzione richiede meno cicli. Lo svantaggio, ovviamente è la minor efficienza, che però è compensata dal fatto che, avendo uno shader core molto meno ingombrante, è possibile metterci dentro monte più unità di calcolo rispetto a quanto non sia possibile fare con architetture di tipo scalare. Ultimo vantaggio, un'architettura come quella di RV770 non necessità di alu dedicate per eseguire i calcoli in fp64. Questo permette di realiizare chip molto piccoli come die size (e quindi molto economici) con un elevato numero di unità di calcolo all'interno e con un potenziale non ancora del tutto espresso (contrariamente ai chip NV che, proprio in virtù della loro già elevata efficienza, non hanno molto altro da dare a livello prestazionale con codice più complesso)

le unità in R6x0/R7x0 sono interamente di tipo vect5, giusto? E che fine hanno fatto le unità scalari presenti in R5x0? Scomparse o sostituite da altre unità?

eh però mò che ci sei approfitto eh..

Quanto occupano unità relative alle texture, in percentuale, in un chip moderno? Esistono dipendenze da rispettare tra SP e TMU, come ad esempio il rapporto 5:1 di ATi? o la loro distribuzione può essere "distribuita" a piacere?

bYeZ!

[yossarian]

Originariamente inviato da ATi7500

grazie, sempre esaustivo
un'ultima cosa riguardo R600\RV670, il primo con interfaccia di memoria a 512bit, il secondo a 256bit. Un ritorno sui propri passi o una modifica "dovuta"? (la domanda in sottofondo: è un chip bandwidth limited o no, e perchè?)

bYeZ!

il discorso sulla limitazione in banda è abbstanza ampio; cerco di rissumerlo in poche parole: il chip (RV670), per le risoluzioni a cui è indirizzato, non è bandwidth limited. Inoltre, nel passaggio da R600 a RV670 si sono adottate le dx10.1 che permettono, proprio nelle situazioni in cui maggiormente si avverte la limitazione della banda passante, ovvero con i filtri attivi, un notevole risparmio di banda. Di ocnseguenza, quando si adotteranno le dx10.1 o le dx11, RV670 riuscirà ad ottimizzare l'utilizzo della banda meglio di quanto non faccia ora con engine di tipo dx9 (alcuni in minima parte dx10)

Originariamente inviato da ATi7500

le unità in R6x0/R7x0 sono interamente di tipo vect5, giusto? E che fine hanno fatto le unità scalari presenti in R5x0? Scomparse o sostituite da altre unità?

probabilmente mi sono espresso male in precedenza: le unità di R600, RV670 e RV770 sono tutte di tipo scalare, ma riunite a gruppi di 5. La differenza rispetto alla precedente architettura delle alu (di tipo vect4+scalar per i vs e vect3+scalar per i ps, entrambe co-issue) sta, per quanto riguarda l'ISA, nel numero di istruzioni che teoricamente possono essere elaborate in parallelo.
Non considerando il caso dei vs, in cui la norma è avere istruzioni di tipo vettoriale con 4 componenti più una funzione speciale (per cui sia l'architattura vettoriale che quella vliw vanno quasi sempre a pieno regime), vediamo cosa succede per i ps. Un'architettura 3+1 co-issue può elaborare 2 istruzioni (una formata dalle componenti rgb e una relativa al canale alpha) dello stesso thread. In effetti, anche nei chip delle serie precedenti (da R3x0 in poi per ATi e da NV4x fino a G7x per nVIDIA), era uso riunire le istruzioni dello stesso thread da inviare alle alu (quindi si può dire che si faceva ricorso ad un approccio di tipo vliw). L'architetura di R600 non fa che estremizzare questo concetto, portando le istruzioni eseguibili in parallelo ad un massimo di 5 (se si escludono le operazioni di branching e quelle di texturing). Per questo motivo ci si riferisce all'architettura degli sp di R600 e seguenti come ad un'architettura di tipo vliw.
Spero di essere stato più chiaro

Originariamente inviato da ATi7500

eh però mò che ci sei approfitto eh..

Quanto occupano unità relative alle texture, in percentuale, in un chip moderno? Esistono dipendenze da rispettare tra SP e TMU, come ad esempio il rapporto 5:1 di ATi? o la loro distribuzione può essere "distribuita" a piacere?

bYeZ!

intendi come spazio? Dipende da tanti fattori, come ad esempio la tipologia di tmu e il loro numero. Comunque, ad occhio, direi tra un 20 e un 25%.
Il rapporto utilizzato da ATi è di 4:1, in realtà e non esiste un canone preciso epr stabilire qual è il rapporto ottimale. Anche qui dipende da tanti fattori: se si punta, in prospettiva futura, più alle operazioni matematiche o a quelle di texturing; se si sono fatte particolari ottimizzazioni per nascondere le latenze relative alle operazioni di texture fetch (il che può permettere di avere un numero inferiore di tmu lavorando più sulla qualità che sulla quantità).

[Brenta987]

[Tidus.hw]

yossarian sei un mito

ps: cos'è l'isa?

[ATi7500]

Originariamente inviato da yossarian

il discorso sulla limitazione in banda è abbstanza ampio; cerco di rissumerlo in poche parole: il chip (RV670), per le risoluzioni a cui è indirizzato, non è bandwidth limited. Inoltre, nel passaggio da R600 a RV670 si sono adottate le dx10.1 che permettono, proprio nelle situazioni in cui maggiormente si avverte la limitazione della banda passante, ovvero con i filtri attivi, un notevole risparmio di banda. Di ocnseguenza, quando si adotteranno le dx10.1 o le dx11, RV670 riuscirà ad ottimizzare l'utilizzo della banda meglio di quanto non faccia ora con engine di tipo dx9 (alcuni in minima parte dx10)

Quindi le differenze prestazionali tra 3850 e 3870, a parita' di framebuffer, vanno ricondotte esclusivamente alla frequenza della GPU?

probabilmente mi sono espresso male in precedenza: le unità di R600, RV670 e RV770 sono tutte di tipo scalare, ma riunite a gruppi di 5. La differenza rispetto alla precedente architettura delle alu (di tipo vect4+scalar per i vs e vect3+scalar per i ps, entrambe co-issue) sta, per quanto riguarda l'ISA, nel numero di istruzioni che teoricamente possono essere elaborate in parallelo.
Non considerando il caso dei vs, in cui la norma è avere istruzioni di tipo vettoriale con 4 componenti più una funzione speciale (per cui sia l'architattura vettoriale che quella vliw vanno quasi sempre a pieno regime), vediamo cosa succede per i ps. Un'architettura 3+1 co-issue può elaborare 2 istruzioni (una formata dalle componenti rgb e una relativa al canale alpha) dello stesso thread. In effetti, anche nei chip delle serie precedenti (da R3x0 in poi per ATi e da NV4x fino a G7x per nVIDIA), era uso riunire le istruzioni dello stesso thread da inviare alle alu (quindi si può dire che si faceva ricorso ad un approccio di tipo vliw). L'architetura di R600 non fa che estremizzare questo concetto, portando le istruzioni eseguibili in parallelo ad un massimo di 5 (se si escludono le operazioni di branching e quelle di texturing). Per questo motivo ci si riferisce all'architettura degli sp di R600 e seguenti come ad un'architettura di tipo vliw.
Spero di essere stato più chiaro

Decisamente E in cosa e' cambiato il lavoro del compilatore, nel passaggio da R600 a RV670, a RV770? si e' semplificato o complicato?

intendi come spazio? Dipende da tanti fattori, come ad esempio la tipologia di tmu e il loro numero. Comunque, ad occhio, direi tra un 20 e un 25%.
Il rapporto utilizzato da ATi è di 4:1, in realtà e non esiste un canone preciso epr stabilire qual è il rapporto ottimale. Anche qui dipende da tanti fattori: se si punta, in prospettiva futura, più alle operazioni matematiche o a quelle di texturing; se si sono fatte particolari ottimizzazioni per nascondere le latenze relative alle operazioni di texture fetch (il che può permettere di avere un numero inferiore di tmu lavorando più sulla qualità che sulla quantità).

Non intendevo esattamente la ricerca del rapporto ottimale, piu' che altro pensavo all'architettura nVidia nella quale il numero di TMU, mi pare, e' legato all'ampiezza del bus (mi sbaglio sicuramente, ma ricordo che fosse legato a qualcosa ).
Si puo' quindi affermare che R600 sia stato "azzoppato" piu' che dall'architettura in se', dalla "primitivita'" del processo produttivo, che non ha permesso di includere grandi quantita' di texture unit?

bYeZ!

[darthrevanri]

Originariamente inviato da yossarian

ci sono alcune ragioni che riguardano le evoluzioni future del SW (shader più lunghi, con più istruzioni per thread che favorirebbero un'architettura più votata al calcolo parallelo; non è un caso che nel test perlin noise che altro non è che l'applicazione di 48 texture con 449 operazioni matematiche, ovvero il massimo previsto dallo sm3.0, RV770, anche in versione 4850, è sopra a gt200 anche in versione 280, e nel test shader math che è l'equivalente del 3dmark vantage, 4870 e 280 sono alla pari e la 4850 leggermente sopra all 260). Nei calcoli geometrici, in cui si fa spesso uso di dati di tipo vettoriale (e quindi sono paralleli per antonomasia) un'architettura con alu di tipo vect risulta la migliore, ma la vliw può ottenere le stesse prestazioni in quanto non è difficil, per il compilatore, mettere insieme 5 istruzioni indipendenti relative allo stesso thread. L'adozione di antialiasing di tipo custom con resolve via shader, aumenterà il numero di istruzioni indipendenti per thread (e favorirà ancora di più un'architettura vliw).
Per quanto riguarda il lato HW, se hai notato, ATi non ha mai adottato architetture di tipo superscalare con alu indipendenti fp32, ma è passata da alu di tipo vect3+scalar ad alu di tipo vliw. Questo perchè la logica di controllo di alu scalari come quelle di nVIDIA è molto più complessa. Ulteriore matovo, un'architettura vliw è più flessibile di una di tipo vect e richiede un minor numero di registri (fino ad 1/3 rispetto ad una scalare tipo quella di nVIDIA); inoltre, ogni singola istruzione richiede meno cicli. Lo svantaggio, ovviamente è la minor efficienza, che però è compensata dal fatto che, avendo uno shader core molto meno ingombrante, è possibile metterci dentro monte più unità di calcolo rispetto a quanto non sia possibile fare con architetture di tipo scalare. Ultimo vantaggio, un'architettura come quella di RV770 non necessità di alu dedicate per eseguire i calcoli in fp64. Questo permette di realiizare chip molto piccoli come die size (e quindi molto economici) con un elevato numero di unità di calcolo all'interno e con un potenziale non ancora del tutto espresso (contrariamente ai chip NV che, proprio in virtù della loro già elevata efficienza, non hanno molto altro da dare a livello prestazionale con codice più complesso)

quindi in futuro per esempio una 2900xt potrebbe battere una 8800gt ??????

[yossarian]

Originariamente inviato da Tidus.hw

yossarian sei un mito

ps: cos'è l'isa?

instruction set architecture, ossia il set di istruzioni ottimale per una data architettura, ovvero l'architettura SW che corrisponde ad una determinata architettura HW. Tra due architetture apparentemente identiche, ad esempio, è sufficiente cambiare il numero di registri per avere ISA differenti.

Originariamente inviato da ATi7500

Quindi le differenze prestazionali tra 3850 e 3870, a parita' di framebuffer, vanno ricondotte esclusivamente alla frequenza della GPU?

dipende, salendo di risoluzione e applicando i filtri conta anche la bandwidth, ma questo vale per qualunque chip. In alcune situazioni si può essre anche frame buffer limited (ad esempio risoluzioni altissime e filtri attivi; se fai caso, con alcune applicazioni la 4870 ha un crollo improvviso passando da una risoluzione ad una più elevata (parlo quasi sempre di risoluzioni da 190 in su e filtri attivi). In quei casi il limite è il FB nella versione da 512 MB.

Originariamente inviato da ATi7500

Decisamente E in cosa e' cambiato il lavoro del compilatore, nel passaggio da R600 a RV670, a RV770? si e' semplificato o complicato?

da R600 a RV 670, al momento, niente; cen le dx10.1 si potranno sfruttare alcune funzionalità presenti in RV670 e non in R600 che faranno risparmiare banda passante e diminuire il numero di passaggi di rendering. Con RV770 il cambiamente maggiore deriva dall'adozione di un differente tipo di MC non più centralizzato, ma "distribuito" e con un canale di retto per la comunicazione tra le gpu ed un altro per le applicazioni non relative al 3D (operazioni prima gestite tutte dal ring bus). Questo ha semplificato la gestione del traffico di dati e gli accessi in memoria.

Originariamente inviato da ATi7500

Non intendevo esattamente la ricerca del rapporto ottimale, piu' che altro pensavo all'architettura nVidia nella quale il numero di TMU, mi pare, e' legato all'ampiezza del bus (mi sbaglio sicuramente, ma ricordo che fosse legato a qualcosa ).

l'ampiezza e la tipologia del bus dipendono da tanti fattori; in pprimo luogo da quante unità di calcolo si devono "foraggiare". Per il crossbar tradizionale di tipo simmetrico, con 8 canali da 64 bit (32+32) sia lato ram che lato gpu, tipo quello adottato da nVIDIA per GT200, l'ampiezza del bus è legata anche al quantitativo di ram che si vuole adottare. Questo giustifica ampiezza di bus "anomale" tipo quelle della 8800 GTX (6 canali per un totale di 768 MB di ram con bus a 385 bit) e della 260 GTX (7 canali per un totale di 448 bit e 896 MB di ram), ad esempio.

Originariamente inviato da ATi7500

Si puo' quindi affermare che R600 sia stato "azzoppato" piu' che dall'architettura in se', dalla "primitivita'" del processo produttivo, che non ha permesso di includere grandi quantita' di texture unit?

bYeZ!

principalmente da quello, in secondo luogo da altri problemi, risolti con RV770, uno dei quali legati proprio alla gestione di task non relativi al 3D che sottraevano risorse utili al ring bus

Originariamente inviato da darthrevanri

quindi in futuro per esempio una 2900xt potrebbe battere una 8800gt ??????

può succedere con R600, con applicazioni shader intensive e che facciano uso massiccio di vertex texturing e ancora di più con RV670, nel momento in cui si inizieranno a sfruttare le feature dx10.1 (già con la patch 1.01 di assassin creed che introduceva l'utilizzo di multi render target per z-ops e color ops, a 1680x1050, con MSAA 4x, una 3879 risulta più veloce di una 8800 GTX ed una 4850 sta davanti ad una 280 GTX, ad esempio