[Thread Uff.le] Aspettando le nuove VGA AMD Radeon™

[Pelvix]

Originariamente inviato da Ther0

Mi scuso anche io :P

Beh, puoi mandarmene una pure tu..
Così posso fare un cross..

[appleroof]

Originariamente inviato da Pelvix

Adesso per punizione, appena esce, mi devi comprare un daul caymano da 4GB (quella da 1000 euri, per intenderci)...

dammi solo l'indirizzo

[appleroof]

Will Barts have a 256 bit memory controller?

It's pretty important to remember what the competition looks like for Barts. That would be Nvidia's GTX 460 which has a 256 bit controller. Can AMD compete against this series with just another 128 bit memory controller. Not likely. Even if the speculated DDR5 for the Cayman series was available for Barts at 1600 MHz (x4) we're only looking at 25% more bandwidth. If the net benefit of the extra bandwidth is as high as 40%, we'll end up with only a 10% performance increase due to the memory bandwidth. A 256 bit controller will probably net over 20% of a performance improvement. It's fairly certain that Barts will have other architectural improvements. More bandwidth will be needed to accommodate those improvements. Remember the excellent scaling when both GPU and memory clocks were raised together. The last thing anyone would want is to limit the benefits of the new architecture by limiting the memory bandwidth when the die space cost would be so small. In the end, a bigger memory controller could be the biggest contributor to performance improvements in the the Barts series of GPUs.

il resto qui http://www.semiaccurate.com/2010/09/...islands-barts/

[M4R1|<]

Originariamente inviato da appleroof

Will Barts have a 256 bit memory controller?

It's pretty important to remember what the competition looks like for Barts. That would be Nvidia's GTX 460 which has a 256 bit controller. Can AMD compete against this series with just another 128 bit memory controller. Not likely. Even if the speculated DDR5 for the Cayman series was available for Barts at 1600 MHz (x4) we're only looking at 25% more bandwidth. If the net benefit of the extra bandwidth is as high as 40%, we'll end up with only a 10% performance increase due to the memory bandwidth. A 256 bit controller will probably net over 20% of a performance improvement. It's fairly certain that Barts will have other architectural improvements. More bandwidth will be needed to accommodate those improvements. Remember the excellent scaling when both GPU and memory clocks were raised together. The last thing anyone would want is to limit the benefits of the new architecture by limiting the memory bandwidth when the die space cost would be so small. In the end, a bigger memory controller could be the biggest contributor to performance improvements in the the Barts series of GPUs.

il resto qui http://www.semiaccurate.com/2010/09/...islands-barts/

Interessante soprattutto il grassetto

[okorop]

Originariamente inviato da M4R1|<

Interessante soprattutto il grassetto

be direi di si, il memory controller rivisitato è fondamentale per questa nuova vga....

[G80]

Originariamente inviato da Qetzalcoatl

Non capisco a volte se la gente è oramai così fissata con la tessellation da non vedere bene altre cose più, diciamo, "fondamentali".

Un test al volo (il primo che ho trovato con google, sono di fretta)

http://www.xbitlabs.com/articles/vid...n_8.html#sect0


Nel peggiore dei casi la GTX con Tess on perde un 16% scarso (che rispetto ad altri giochi dx11 è parecchio ma niente di trascendentale), la 5870 un 19%... cioè in pratica tra le due soluzioni c'è un 3% e rotti di differenza tra le implementazioni del tessellator... Ma evidentemente il vantaggio di NVida su AMD in metro 2033 è da ricercarsi altrove (stessa cosa sugli altri giochi ovviamente).
Addirittura una 5830 tra Tess on e Off la differenza è meno incisiva che per la sorella maggiore (segno che la scheda fa fatica in altri settori) ergo un ipotetica 6770 con solo un tessellator molto migliorato... non servirebbe praticamente a nulla.

Salve ragazzi un buonasera a tutti
E' vero chiedo scusa sono ot,ma la discussione mi piace.
In effetti nessun gioco ora fa uso intenso di tessellator, per cui da quel lato Evergreen non è stato mal ingegnerizzato anzi:la potenza necessaria nel periodo giusto.
Per quanto riguarda Metro sono d'accordo con Qetzalcoatl,il collo di bottiglia delle Gpu non è nella tessellation perchè analizzando il gioco con Nvperfkit (tutto al max, tessellation on e dof off) la parte mediamente più utilizzata erano le TMU (avevo i risultati dei test,ora non ho la 480 montata ) e di una buona percentuale,con gli shaders che arrivavano ad alte percentuali di utilizzo solo attivando il dof.
In definitiva ricordo che il gioco era abbondantemente TMU limited,il problema è che nvperfkit non indica l'utilizzo delle cache,saturazione registri,saturazione tessellator come unità dedicata, ecc...
Ricordo tempo fa che lessi uno speciale sull'engine di Metro,il quale parlava di un buon utilizzo del raytracing con le impostazioni massime in determinate situazioni di illuminazione di stanze o superfici:in questo caso è possibile che le scene a maggior impatto prestazionale siano quelle,in tal caso verrebbe in aiuto la veloce cache messa a disposizione da Fermi per le scene che utilizzano in parte il raytracing.
Purtroppo non posso sapere cosa di preciso venga utilizzato in quanto il programma non lo permette,ma un pò si speculazione non fa male
Chiedo scusa per l'ot,che troppo ot non è dai
Buona serata a tutti
Bye

[Capozz]

Originariamente inviato da G80

Salve ragazzi un buonasera a tutti
E' vero chiedo scusa sono ot,ma la discussione mi piace.
In effetti nessun gioco ora fa uso intenso di tessellator, per cui da quel lato Evergreen non è stato mal ingegnerizzato anzi:la potenza necessaria nel periodo giusto.
Per quanto riguarda Metro sono d'accordo con Qetzalcoatl,il collo di bottiglia delle Gpu non è nella tessellation perchè analizzando il gioco con Nvperfkit (tutto al max, tessellation on e dof off) la parte mediamente più utilizzata erano le TMU (avevo i risultati dei test,ora non ho la 480 montata ) e di una buona percentuale,con gli shaders che arrivavano ad alte percentuali di utilizzo solo attivando il dof.
In definitiva ricordo che il gioco era abbondantemente TMU limited,il problema è che nvperfkit non indica l'utilizzo delle cache,saturazione registri,saturazione tessellator come unità dedicata, ecc...
Ricordo tempo fa che lessi uno speciale sull'engine di Metro,il quale parlava di un buon utilizzo del raytracing con le impostazioni massime in determinate situazioni di illuminazione di stanze o superfici:in questo caso è possibile che le scene a maggior impatto prestazionale siano quelle,in tal caso verrebbe in aiuto la veloce cache messa a disposizione da Fermi per le scene che utilizzano in parte il raytracing.
Purtroppo non posso sapere cosa di preciso venga utilizzato in quanto il programma non lo permette,ma un pò si speculazione non fa male
Chiedo scusa per l'ot,che troppo ot non è dai
Buona serata a tutti
Bye

Non è la tasselation che rende metro 2033 pesante quanto quella immensa cagata del depth of field avanzato, che praticamente non si nota nemmeno ma dimezza i frames.

[sbudellaman]

In the end, a bigger memory controller could be the biggest contributor to performance improvements in the the Barts series of GPUs.

il resto qui http://www.semiaccurate.com/2010/09/...islands-barts/

Ma allora le previsioni sulla tabella di wikipedia in parte ci avevano azzeccato ! Chissà il resto

[Micene.1]

mah secondo me mi sembra che si parli un po troppo della tassellazione....voglio dire sicuramente una nuova tecnica importante etc. etc.....pero insomma per adesso le sv si battono sulla capacita di creare la scena con gli shader, sulla capacita di gestire l'aa, af e cosi via...il tassellatore per quanto interessante nn mi sembra ancora la funzionalita principale richiesta dai giochi (oltre al fatto che solo su alcuni giochi sembra essere determinante ai fine della qualita dell'immagine)...alla fine le 6xxx di amd mi devono mandare crysis 2 con aa4x a 1920 a >30fps (per dire) , questo è il mandato principale poi che tesselezzi bene è ampiamente secondario

poi magari chissa tra qualche anno fare un aa 16x sarà banale e collo di botttiglia saranno le unita adibite al tasseletion

[arwar]

la tassellazione è ancora acerba..io penso che prima di 2 generazioni future (diciamo fino ad ati 8xxx) non si userà molto.

Ma vabbè io penso al presente.

Mi basta che la 6850 con un pò di oc faccia andare TUTTO a 60 fps con aa8x af16x e 1920*1080

[ghiltanas]

Originariamente inviato da appleroof

Will Barts have a 256 bit memory controller?

It's pretty important to remember what the competition looks like for Barts. That would be Nvidia's GTX 460 which has a 256 bit controller. Can AMD compete against this series with just another 128 bit memory controller. Not likely. Even if the speculated DDR5 for the Cayman series was available for Barts at 1600 MHz (x4) we're only looking at 25% more bandwidth. If the net benefit of the extra bandwidth is as high as 40%, we'll end up with only a 10% performance increase due to the memory bandwidth. A 256 bit controller will probably net over 20% of a performance improvement. It's fairly certain that Barts will have other architectural improvements. More bandwidth will be needed to accommodate those improvements. Remember the excellent scaling when both GPU and memory clocks were raised together. The last thing anyone would want is to limit the benefits of the new architecture by limiting the memory bandwidth when the die space cost would be so small. In the end, a bigger memory controller could be the biggest contributor to performance improvements in the the Barts series of GPUs.

il resto qui http://www.semiaccurate.com/2010/09/...islands-barts/

very

http://www.hwupgrade.it/forum/showpo...postcount=5700

continuate pure a ignorarmi

[Andrea deluxe]

Originariamente inviato da arwar

Mi basta che la 6850 con un pò di oc faccia andare TUTTO a 60 fps con aa8x af16x e 1920*1080

lol ma ti accontenti di poco....

[KoDen78]

Comunque è anche divertente che dopo decenni spesi a ottimizzare la tassellazione dei modelli poligonali, si inizi a pensare al contrario e a buttare via performance per una tassellazione iper-esagerata. Tra l'altro, se il modello non è stato disegnato all'origine con una tassellazione elevata, checcacchio va ad aumentare questa benedetta tassellazione "moderna"(directx11)? Qualcosa che di fatto non c'è e che comunque non si può ricostruire? forse ammorbidisce gli spigoli dei modelli? Non so, ditemi voi...

[John_Mat82]

Originariamente inviato da KoDen78

Comunque è anche divertente che dopo decenni spesi a ottimizzare la tassellazione dei modelli poligonali, si inizi a pensare al contrario e a buttare via performance per una tassellazione iper-esagerata. Tra l'altro, se il modello non è stato disegnato all'origine con una tassellazione elevata, checcacchio va ad aumentare questa benedetta tassellazione "moderna"(directx11)? Qualcosa che di fatto non c'è e che comunque non si può ricostruire? forse ammorbidisce gli spigoli dei modelli? Non so, ditemi voi...

Simula all'incirca in maniera indiscriminata un aumento del numero di poligoni dei modelli (emulandoli, ma a quanto vedo dal calo prestazionale, tra un po' si farebbe prima a fare semplicemente modelli con + poligoni fin dall'inizio ), il punto è che lo fa su tutto.. che io abbia capito non c'è controllo.
Prova ad aprire unigine e farlo andare con tessellazione spenta o accesa; tu magari modelli un angolo e con la tesselazione ti fa una punta che magari tu non volevi; imho è una semi-boiata per vendere le dx11.

L'idea può aiutare molto nell'aumentare il numero e qualità dei dettagli dei modelli, ma se non si ha controllo su dove e su quanta tessellazione va su un modello, a mio avviso è un po' inutile; finisce che si deve modellare in modo tale che poi la tessellazione vada a mettere i poligoni come si vuole, mah..

[M4R1|<]

Originariamente inviato da okorop

be direi di si, il memory controller rivisitato è fondamentale per questa nuova vga....

Ciao caro,

Già

Originariamente inviato da ghiltanas

very

http://www.hwupgrade.it/forum/showpo...postcount=5700

continuate pure a ignorarmi

E' che tu hai postato il link mentre Apple ha estrappolato il succo, se uno ha fretta (come me) spesso e volentieri nn legge tutti i link soprattutto se riconducono ad articoli lunghi...

Originariamente inviato da Andrea deluxe

lol ma ti accontenti di poco....

Già perchè tra 60 e 100 minimi c'è differenza?
Che sensibilità hai?

[Micene.1]

Originariamente inviato da John_Mat82

Simula all'incirca in maniera indiscriminata un aumento del numero di poligoni dei modelli (emulandoli, ma a quanto vedo dal calo prestazionale, tra un po' si farebbe prima a fare semplicemente modelli con + poligoni fin dall'inizio ), il punto è che lo fa su tutto.. che io abbia capito non c'è controllo.

no perche altrimenti i giochi diventano pesanti (con molti poligoni) e adatti solo a sv aggiornate - l'obiettivo è quello di fare sv leggeri e con pochi poligoni (lasciami dire cosi) che all'occorrenza possono avere molti poligoni (o meglio simulare di avere molti poligoni) se l'hardware lo permette - ovviamente come dici tu questo porta enormi inefficienze...la tasselazione sotto questo profilo è in effetti un po una cretinata

[John_Mat82]

Originariamente inviato da Micene.1

no perche altrimenti i giochi diventano pesanti (con molti poligoni) e adatti solo a sv aggiornate - l'obiettivo è quello di fare sv leggeri e con pochi poligoni (lasciami dire cosi) che all'occorrenza possono avere molti poligoni (o meglio simulare di avere molti poligoni) se l'hardware lo permette - ovviamente come dici tu questo porta enormi inefficienze...la tasselazione sotto questo profilo è in effetti un po una cretinata

Si, resto dell'idea che se poi si deve fare un livello/modello con 4 poligoni in croce e poi sperare nella bontà divina che i dettagli escano come si vuole.. di certo è meglio che avere tonnellate di texture space spesi in normal e/o displacement maps, ma quando ormai si hanno buffer da 512mb ormai molto diffusi e il 1gb di vram che sta diventando uno standard (e non mi meraviglierei tra 1 annetto o 2 cominciare a vedere 2gb sempre + standard) imho è un sistema relativamente opinabile. Boh, chi vivrà vedrà io ragiono ancora a texture e normals

[Wing_Zero]

Originariamente inviato da Micene.1

no perche altrimenti i giochi diventano pesanti (con molti poligoni) e adatti solo a sv aggiornate - l'obiettivo è quello di fare sv leggeri e con pochi poligoni (lasciami dire cosi) che all'occorrenza possono avere molti poligoni (o meglio simulare di avere molti poligoni) se l'hardware lo permette - ovviamente come dici tu questo porta enormi inefficienze...la tasselazione sotto questo profilo è in effetti un po una cretinata

La tessellazione NON E' una cretinata per definizione -.-"
Non è un semplice aumento dei poligoni: ma attivando la tessellazione, in sostanza, la gpu invece di avere in pasto 2 milioni di poligoni ne prende 200.000 e per i restanti li crea al volo il tessellatore, avendo la stessa risultante visiva ma un impatto molto minore sulle prestazioni.

Se metro 2033 con la tessellazione attiva su una 480gtx fa 20 fps, lo stesso numero di poligoni senza il supporto software ed hardware alla tessellazione avrebbe fatto 1 frame al minuto.

[ShineOn]

Originariamente inviato da ShineOn

Visto che questa nuova scheda avrà due mini display port oltre all'hdmi e alle due DVI, si sa se questa volta usando tre schermi sarà possibile usare le 2 DVI + l'HDMI risparmiando l'acquisto dell'adattatore display port?

Daii nessuno che mi risponde? pazienza i novellini, ma qualche senatore...altrimenti si parla sempre e solo di fps e soldi

[Matalf]

Originariamente inviato da ShineOn

Daii nessuno che mi risponde? pazienza i novellini, ma qualche senatore...altrimenti si parla sempre e solo di fps e soldi

ati a presentato un mesetto fà i nuovi adattatori dp-->dvi a 29€ quindi non penso proprio