darthrevanri
02-08-2008, 10:00
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?:confused:
hd 4870 1,2 tflops
gtx 280 900 gflops
hd 4870 1,2 tflops
gtx 280 900 gflops
View Full Version : gflops ati e nvidia
yossarian
02-08-2008, 13:07
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 :rolleyes: , 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.
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 :rolleyes: , 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
02-08-2008, 13:57
abbastanza esauriente come risposta direi :asd:
Brenta987
02-08-2008, 17:16
:mbe:
Il ragazzo è preparato.....:mano:
ma parla troppo complesso.....:eek:
:sbonk:
Il ragazzo è preparato.....:mano:
ma parla troppo complesso.....:eek:
:sbonk:
darthrevanri
02-08-2008, 20:06
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 :rolleyes: , 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:sofico: :D
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 :rolleyes: , 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:sofico: :D
Ale985
02-08-2008, 22:05
abbastanza esauriente come risposta direi :asd:
concordo :sbavvv:
però se non si ha una laurea in informatica ed ingegneria elettronica non è proprio facilissimo comprendere ciò che ha scritto :ave:
concordo :sbavvv:
però se non si ha una laurea in informatica ed ingegneria elettronica non è proprio facilissimo comprendere ciò che ha scritto :ave:
robertogl
02-08-2008, 22:19
sono in ferie,ho tempo di leggere la risposta di yossarian :Perfido:
.....hd4850 superava, a 1680x1050, con msaa 4x, una GT280; in maniera alquanto misteriosa :rolleyes: , 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..... .
:asd:
.....hd4850 superava, a 1680x1050, con msaa 4x, una GT280; in maniera alquanto misteriosa :rolleyes: , 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..... .
:asd:
yossarian
03-08-2008, 17:25
:mbe:
Il ragazzo è preparato.....:mano:
ma parla troppo complesso.....:eek:
:sbonk:
grazie per la risposta diciamo che qualcosina ci ho capito:sofico: :D
concordo :sbavvv:
però se non si ha una laurea in informatica ed ingegneria elettronica non è proprio facilissimo comprendere ciò che ha scritto :ave:
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ù.
Il ragazzo è preparato.....:mano:
ma parla troppo complesso.....:eek:
:sbonk:
grazie per la risposta diciamo che qualcosina ci ho capito:sofico: :D
concordo :sbavvv:
però se non si ha una laurea in informatica ed ingegneria elettronica non è proprio facilissimo comprendere ciò che ha scritto :ave:
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
03-08-2008, 21:07
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...:stordita: );)
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...:stordita: );)
yossarian
03-08-2008, 21:24
E per fortuna che hai semplificato...
già ci ho capito poco così...(troppe sigle e abbreviazioni...:stordita: );)
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
già ci ho capito poco così...(troppe sigle e abbreviazioni...:stordita: );)
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
04-08-2008, 17:24
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!
bYeZ!
yossarian
04-08-2008, 22:18
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)
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
04-08-2008, 23:07
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è?) :sofico:
bYeZ!
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è?) :sofico:
bYeZ!
ATi7500
04-08-2008, 23:13
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.. :D
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!
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.. :D
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
05-08-2008, 02:01
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è?) :sofico:
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)
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
eh però mò che ci sei approfitto eh.. :D
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à).
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è?) :sofico:
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)
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
eh però mò che ci sei approfitto eh.. :D
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
05-08-2008, 08:10
:eek: :eek: :eek:
:eek: :eek: :eek:
:eek: :eek: :eek:
:eek: :eek: :eek:
:eek: :eek: :eek:
Tidus.hw
05-08-2008, 08:27
yossarian sei un mito :fagiano:
ps: cos'è l'isa?
ps: cos'è l'isa?
ATi7500
05-08-2008, 09:29
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 :fagiano: ).
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!
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 :fagiano: ).
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
05-08-2008, 09:47
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 ??????
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
05-08-2008, 11:59
yossarian sei un mito :fagiano:
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.
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.
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.
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 :fagiano: ).
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.
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
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
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.
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.
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.
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 :fagiano: ).
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.
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
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
Mister Tarpone
05-08-2008, 12:06
quindi in futuro per esempio una 2900xt potrebbe battere una 8800gt ??????
Imho continuerà a starle sotto ;)
almeno con le ati successive ci potrebbe essere il vantaggio del supporto dx10.1, che le farebbero andare un pò meglio del normale nei giochi che le sfruttano (c'è da dire che purtroppo non esiste manco un gioco che le sfrutta.. e neanche le dx10.. :asd: ).. ma r600 non è manco dx10.1...
Imho continuerà a starle sotto ;)
almeno con le ati successive ci potrebbe essere il vantaggio del supporto dx10.1, che le farebbero andare un pò meglio del normale nei giochi che le sfruttano (c'è da dire che purtroppo non esiste manco un gioco che le sfrutta.. e neanche le dx10.. :asd: ).. ma r600 non è manco dx10.1...
darthrevanri
05-08-2008, 15:32
yossarian quindi sul portatile quale scheda mi cosigleresti dato che ho tutti e due: una 8600m gt e una 2600 radeon mobility?:)
yossarian
05-08-2008, 15:34
yossarian quindi sul portatile quale scheda mi cosigleresti dato che ho tutti e due: una 8600m gt e una 2600 radeon mobility?:)
per giocare te ne fai poco di tutte e due. Sono gpu con supporto teorico alle dx10 ma hanno, in pratica, poca potenza di calcolo
per giocare te ne fai poco di tutte e due. Sono gpu con supporto teorico alle dx10 ma hanno, in pratica, poca potenza di calcolo
darthrevanri
05-08-2008, 16:52
per giocare te ne fai poco di tutte e due. Sono gpu con supporto teorico alle dx10 ma hanno, in pratica, poca potenza di calcolo
però data la risoluzione del notebook qualcosina parte e volevo sapere qualè meglio tutto qua (per ottenere 2 3 fps in più):)
però data la risoluzione del notebook qualcosina parte e volevo sapere qualè meglio tutto qua (per ottenere 2 3 fps in più):)
yossarian
05-08-2008, 17:10
però data la risoluzione del notebook qualcosina parte e volevo sapere qualè meglio tutto qua (per ottenere 2 3 fps in più):)
in tal caso un po' meglio la 8600 GT
in tal caso un po' meglio la 8600 GT
darthrevanri
05-08-2008, 17:41
in tal caso un po' meglio la 8600 GT
grazie per la risp (io gioco ancora con le directx 9):D
grazie per la risp (io gioco ancora con le directx 9):D
appleroof
05-08-2008, 17:42
grazie per la risp (io gioco ancora con le directx 9):D
in realtà lo facciamo tutti, finora :sofico: :stordita:
in realtà lo facciamo tutti, finora :sofico: :stordita:
yossarian
05-08-2008, 17:45
grazie per la risp (io gioco ancora con le directx 9):D
per quello ti ho detto di tenere la 8600 :D
per quello ti ho detto di tenere la 8600 :D
appleroof
05-08-2008, 17:47
per quello ti ho detto di tenere la 8600 :D
già...almeno quella in dx9 se la cavicchia, l'altra sia in dx9 che in dx10....:D :D
già...almeno quella in dx9 se la cavicchia, l'altra sia in dx9 che in dx10....:D :D
Mister Tarpone
05-08-2008, 17:48
l'altra sia in dx9 che in dx10....:D :D
.... fa cagare :D :D :D
.... fa cagare :D :D :D
appleroof
05-08-2008, 17:52
.... fa cagare :D :D :D
:asd: :asd:
:asd: :asd:
Ale985
07-09-2008, 16:04
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 :rolleyes: , 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.
Ciao, leggendo le pzioni sull'utility catalyst della mia 4870, volevo chiedervi alcune cose:
- Nella sezione "Display option", è meglio abilitarlo il 3D Refresh Rate overdrive
- In digital panel 4 (DVI), cosa comporta attivare "Enable GPU scaling" ?
- Che cosa è l'Adaptive anti aliasing?
- Il vertical refresh sarebbe la sincronizzazione verticale?
- Nella sottosezione "openGL", può aiutare attivare lo z-buffer display e in "Direct3D" l'alternate pixel center?
Grazie in anticipo
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 :rolleyes: , 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.
Ciao, leggendo le pzioni sull'utility catalyst della mia 4870, volevo chiedervi alcune cose:
- Nella sezione "Display option", è meglio abilitarlo il 3D Refresh Rate overdrive
- In digital panel 4 (DVI), cosa comporta attivare "Enable GPU scaling" ?
- Che cosa è l'Adaptive anti aliasing?
- Il vertical refresh sarebbe la sincronizzazione verticale?
- Nella sottosezione "openGL", può aiutare attivare lo z-buffer display e in "Direct3D" l'alternate pixel center?
Grazie in anticipo
giuseppe73
09-09-2008, 13:40
salve a tutti,volevo approfittare dalla disposizione di un utente molto preparato (troppo)per fare una domanda.
fin ora si e parlato delle relative architetture e le consequenze dipendenze sia sul framerate o sulla dipendenza di ram o meno. dalla mia esperienza persolale dal passagio da una 1950 pro a una 8800gt ed ora usando un muletto con una 9250, ho notato una differenza sia di colore (trascurabile e obbiettiva secondo i gusti ) ma anche di scalettature a livello deskop (2d ) , come se l`architettura ati a default imposti un aa 1x ,e un impressione mia ,o dietro si nascondono arcani progetti per prediligere meglio una o l'altra nei giochi,pesantezza driver e benckmark.
questa mia domanda non e',la classica meglio una o l'altra ma veramente per capirci se questa mia impressiona ,persolale e non so' se condivisa da altri utenti,a delle fondamente progettuali al livello hardware. grazie per un eventuale risposta ,non troppo tecnica eh! :D
fin ora si e parlato delle relative architetture e le consequenze dipendenze sia sul framerate o sulla dipendenza di ram o meno. dalla mia esperienza persolale dal passagio da una 1950 pro a una 8800gt ed ora usando un muletto con una 9250, ho notato una differenza sia di colore (trascurabile e obbiettiva secondo i gusti ) ma anche di scalettature a livello deskop (2d ) , come se l`architettura ati a default imposti un aa 1x ,e un impressione mia ,o dietro si nascondono arcani progetti per prediligere meglio una o l'altra nei giochi,pesantezza driver e benckmark.
questa mia domanda non e',la classica meglio una o l'altra ma veramente per capirci se questa mia impressiona ,persolale e non so' se condivisa da altri utenti,a delle fondamente progettuali al livello hardware. grazie per un eventuale risposta ,non troppo tecnica eh! :D
yossarian
09-09-2008, 15:20
Ciao, leggendo le pzioni sull'utility catalyst della mia 4870, volevo chiedervi alcune cose:
- Nella sezione "Display option", è meglio abilitarlo il 3D Refresh Rate overdrive
si; il refresh rate ovverride permette di impostare, in 3D, frequenze di refresh superiori ai canonici 60 Hz del 2D (vale solo epr monitor LCD); accertati che il tuo monitor supporti la eventuale maggiore frequenza che vai ad impostare per il 3D
- In digital panel 4 (DVI), cosa comporta attivare "Enable GPU scaling" ?
è lo scaling della gpu che permette di impostare risoluzioni differenti rispetto a quelle native. Se, come molto probabile, il tuo monitor ha un suo scaling interno, lascia quello della gpu disabilitato (in alcuni casi può creare conflitti con quello del monitor)
- Che cosa è l'Adaptive anti aliasing?
è un antialiasing che si applica sulle texture trasparenti (quelle che devono simulare oggetti attraverso i quali si vede o si intravede qualcosa, come ad esempio una rete o le foglie di un albero). Si affianca al MSAA canonico che opera solo sui contorni deio poligoni, per migliorare la qualità dell'immagine senza dover ricorrere al supersampling.
- Il vertical refresh sarebbe la sincronizzazione verticale?
è la frequenza di refresh del monitor
- Nella sottosezione "openGL", può aiutare attivare lo z-buffer display
si; se forzi lo z-buffer a 16 bit ottieni migliori prestazioni, a 32 bit maggior qualità
e in "Direct3D" l'alternate pixel center?
Grazie in anticipo
no. In teoria serve per risolvere alcuni problemi con giochi con i quali compaiono linee orizzontali o verticali lungo tutto lo schermo; in caso contrario (cioè se non hai problemi problemi di quel tipo) potrebbe a sua volta creare qualche problema di visualizzazione oppure non dare alcun risultato.
salve a tutti,volevo approfittare dalla disposizione di un utente molto preparato (troppo)per fare una domanda.
fin ora si e parlato delle relative architetture e le consequenze dipendenze sia sul framerate o sulla dipendenza di ram o meno. dalla mia esperienza persolale dal passagio da una 1950 pro a una 8800gt ed ora usando un muletto con una 9250, ho notato una differenza sia di colore (trascurabile e obbiettiva secondo i gusti ) ma anche di scalettature a livello deskop (2d ) , come se l`architettura ati a default imposti un aa 1x ,e un impressione mia ,o dietro si nascondono arcani progetti per prediligere meglio una o l'altra nei giochi,pesantezza driver e benckmark.
questa mia domanda non e',la classica meglio una o l'altra ma veramente per capirci se questa mia impressiona ,persolale e non so' se condivisa da altri utenti,a delle fondamente progettuali al livello hardware. grazie per un eventuale risposta ,non troppo tecnica eh! :D
che io sappia, l'unica ad avere una forma di antialiasing per le applicazioni di tipo desktop 2D è la Matrox Parhelia. Per il resto, credo si tratti di una tua percezione personale
- Nella sezione "Display option", è meglio abilitarlo il 3D Refresh Rate overdrive
si; il refresh rate ovverride permette di impostare, in 3D, frequenze di refresh superiori ai canonici 60 Hz del 2D (vale solo epr monitor LCD); accertati che il tuo monitor supporti la eventuale maggiore frequenza che vai ad impostare per il 3D
- In digital panel 4 (DVI), cosa comporta attivare "Enable GPU scaling" ?
è lo scaling della gpu che permette di impostare risoluzioni differenti rispetto a quelle native. Se, come molto probabile, il tuo monitor ha un suo scaling interno, lascia quello della gpu disabilitato (in alcuni casi può creare conflitti con quello del monitor)
- Che cosa è l'Adaptive anti aliasing?
è un antialiasing che si applica sulle texture trasparenti (quelle che devono simulare oggetti attraverso i quali si vede o si intravede qualcosa, come ad esempio una rete o le foglie di un albero). Si affianca al MSAA canonico che opera solo sui contorni deio poligoni, per migliorare la qualità dell'immagine senza dover ricorrere al supersampling.
- Il vertical refresh sarebbe la sincronizzazione verticale?
è la frequenza di refresh del monitor
- Nella sottosezione "openGL", può aiutare attivare lo z-buffer display
si; se forzi lo z-buffer a 16 bit ottieni migliori prestazioni, a 32 bit maggior qualità
e in "Direct3D" l'alternate pixel center?
Grazie in anticipo
no. In teoria serve per risolvere alcuni problemi con giochi con i quali compaiono linee orizzontali o verticali lungo tutto lo schermo; in caso contrario (cioè se non hai problemi problemi di quel tipo) potrebbe a sua volta creare qualche problema di visualizzazione oppure non dare alcun risultato.
salve a tutti,volevo approfittare dalla disposizione di un utente molto preparato (troppo)per fare una domanda.
fin ora si e parlato delle relative architetture e le consequenze dipendenze sia sul framerate o sulla dipendenza di ram o meno. dalla mia esperienza persolale dal passagio da una 1950 pro a una 8800gt ed ora usando un muletto con una 9250, ho notato una differenza sia di colore (trascurabile e obbiettiva secondo i gusti ) ma anche di scalettature a livello deskop (2d ) , come se l`architettura ati a default imposti un aa 1x ,e un impressione mia ,o dietro si nascondono arcani progetti per prediligere meglio una o l'altra nei giochi,pesantezza driver e benckmark.
questa mia domanda non e',la classica meglio una o l'altra ma veramente per capirci se questa mia impressiona ,persolale e non so' se condivisa da altri utenti,a delle fondamente progettuali al livello hardware. grazie per un eventuale risposta ,non troppo tecnica eh! :D
che io sappia, l'unica ad avere una forma di antialiasing per le applicazioni di tipo desktop 2D è la Matrox Parhelia. Per il resto, credo si tratti di una tua percezione personale
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.