[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[Marko91]

Originariamente inviato da Kharonte85

Non sono io che ho scritto l'articolo:

Rough performance estimates

Given everything we talked about above, we can start to draw some rough comparisons from GF100 to GT200 and RV870—and maybe estimate performance. We've got a clock estimate we're pretty confident in, and we've puts flags in the ground for the graphics-specific units, in terms of counts, so here goes nothing.

We'll consider Radeon HD 5870 for the RV870 implementation and the GeForce GTX 285 for the GT200 product. Obviously, GT200's SP rate is for MADD, since it doesn't have support for SP FMA.



The GF100's architecture means the SKU we've described (the GeForce GTX 380, possibly) comfortably outruns the GeForce GTX 285 in every way, to the point that (and we really generalize here, sorry) it should usually be at least twice as fast. Of course, you can engineer situations, usually in the middle of a frame, where the GF100 won't outpace the GT200 all that much, but in the main, it should be a solid improvement. The GF100 will outpace the Radeon HD 5870 as the top single-chip graphics product of all time, assuming AMD doesn't release anything else in the interim, between now and January. Look for the margins there to be a bit more slender, and we refer you to our Radeon HD 5870 review for the figures that'll let you imagine performance versus AMD's product.

http://techreport.com/articles.x/17815/4

Con quelle specifiche dovrebbe essere tra il 20% e il 30% più veloce di una HD5870.

[Judicator]

E poi andrebbe aggiunta una cosa: il test del tassellatore Unigine, a quanto pare, non si limita alla tasselazione, mi sembra che, parecchia geometria sia dislocata, quindi c'è un ulteriore carico per la GPU.

http://www.legitreviews.com/images/r...igine_dx9a.jpg
http://www.legitreviews.com/images/r...x11a_large.jpg

[leoneazzurro]

Originariamente inviato da Kharonte85

Non sono io che ho scritto l'articolo:

Rough performance estimates

Given everything we talked about above, we can start to draw some rough comparisons from GF100 to GT200 and RV870—and maybe estimate performance. We've got a clock estimate we're pretty confident in, and we've puts flags in the ground for the graphics-specific units, in terms of counts, so here goes nothing.

We'll consider Radeon HD 5870 for the RV870 implementation and the GeForce GTX 285 for the GT200 product. Obviously, GT200's SP rate is for MADD, since it doesn't have support for SP FMA.



The GF100's architecture means the SKU we've described (the GeForce GTX 380, possibly) comfortably outruns the GeForce GTX 285 in every way, to the point that (and we really generalize here, sorry) it should usually be at least twice as fast. Of course, you can engineer situations, usually in the middle of a frame, where the GF100 won't outpace the GT200 all that much, but in the main, it should be a solid improvement. The GF100 will outpace the Radeon HD 5870 as the top single-chip graphics product of all time, assuming AMD doesn't release anything else in the interim, between now and January. Look for the margins there to be a bit more slender, and we refer you to our Radeon HD 5870 review for the figures that'll let you imagine performance versus AMD's product.

http://techreport.com/articles.x/17815/4

E' proprio quello che non torna. In pratica dice in tutto l'articolo che le capacità teoriche di GF100 lo renderebbero due volte più veloce di una GTX285, ma dimentica di dire che se fosse per le capacità teoriche anche la 5870 sarebbe due volte più veloce di una HD4890 (90, non 70).
Insomma, è una risposta troppo "alla carlona", e non me lo aspetto da uno come Rys. Tralascia le limitazioni del setup (e GF100 a differenza di Cypress non sembra avere il doppio rasterizzatore), della banda (che non è il doppio della GTX285), del fillrate (che non è il doppio delle GTX285), senza contare che non solo non sappiamo nulla del texel fill rate, ma che anche con le CPU dell'anno prossimo schede come le 5970 e le GF100 rischiano di essere limitate in molti scenari dalla CPU.

[yossarian]

Originariamente inviato da leoneazzurro

E' proprio quello che non torna. In pratica dice in tutto l'articolo che le capacità teoriche di GF100 lo renderebbero due volte più veloce di una GTX285, ma dimentica di dire che se fosse per le capacità teoriche anche la 5870 sarebbe due volte più veloce di una HD4890 (90, non 70).
Insomma, è una risposta troppo "alla carlona", e non me lo aspetto da uno come Rys. Tralascia le limitazioni del setup (e GF100 a differenza di Cypress non sembra avere il doppio rasterizzatore), della banda (che non è il doppio della GTX285), del fillrate (che non è il doppio delle GTX285), senza contare che non solo non sappiamo nulla del texel fill rate, ma che anche con le CPU dell'anno prossimo schede come le 5970 e le GF100 rischiano di essere limitate in molti scenari dalla CPU.

a me sembra un articolo del tipo: alcuni dati certi (quelli forniti da nVidia e riportati da tutti) e tante sue speculazioni (ad iniziare dalle frequenze, passando per l'emulazione del tessellator e per la sostituzione delle madd con le fma senza incontrare problemi e senza incorrere in hit prestazionali, per finire con le previsioni circa le prestazioni e il periodo di lancio). Insomma, "costruiamo il nostro fermi ideale"
Io aspetterei notizie più precise da fonti ufficiali

[devAngnew]

Originariamente inviato da yossarian

e l'overhead per la compilazione e l'ottimizzazione dello shader non lo calcoli? O quelle sono gratis?

Ma se è 3 pagine di thread che dico che l'overhead è solo all'atto della compilazione e ho fatto pure l'esempio che ciò avvine quando viene caricato un livello di gioco in tal momento la gpu può compilare e ottimizzare lo shader.

La sostituzione o la fai prima o dopo non cambia nulla;

Ma vedi bene che la differenza c'è è come basta considerare la differenza tra un linguaggio che compila ed un altro che interpreta istruzione per istruzione.
il primo (compilato) è nettamente superiore ad uno interpretato.

se l'esecuzione inizia con n cicli di ritardo perchè si devono sosittuire le madd con fma hai lo stesso sprecato dei cicli. Cosa non ti torna?

Si sprecano dei cicli durate il chaching dello shader ma cosa vuoi che importi ad un giocatore se inizia a giocare 1/2 secondo dopo aver caricato un livello di gioco.

[yossarian]

Originariamente inviato da devAngnew

Ma se è 3 pagine di thread che dico che l'overhead è solo all'atto della compilazione e ho fatto pure l'esempio che ciò avvine quando viene caricato un livello di gioco in tal momento la gpu può compilare e ottimizzare lo shader.



Ma vedi bene che la differenza c'è è come basta considerare la differenza tra un linguaggio che compila ed un altro che interpreta istruzione per istruzione.
il primo (compilato) è nettamente superiore ad uno interpretato.




Si sprecano dei cicli durate il chaching dello shader ma cosa vuoi che importi ad un giocatore se inizia a giocare 1/2 secondo dopo aver caricato un livello di gioco.

quindi, secondo il tuo ragionamento, ci si ferma al frame iniziale. Ok, allora si gioca per un solo frame che parte in ritardo, ma tanto cosa importa al giocatore, e finisce dopo 1/60 di secondo.
E quelli successivi? Quando vengono caricati? E quando viene fatta l'operazione di sostituzione? Sempre prima dell'inizio del frame? Magari prima dell'inizio del primo frame? Oppure per gli altri la sostituzione è gratis?
Interessante 'sta cosa
Ti sfugge che dati e istruzioni sono caricati di continuo una volta partita l'elaborazione e che ogni volta deve essere fatta l'operazione di sostituzione che fa perdere, comunque, cicli di clock, per cui non si può eseguire una madd alla massima velocità possibile?

[Athlon 64 3000+]

Qua hanno fatto con Dirt 2 un benchmark dove ci i test delle hd 5000 series(non la HD 5970) sulle dx9 e dx11 e il frame rate con quest'ultime attivate fa calare di non poco il frame rate.
http://www.pcgameshardware.com/aid,7...X-11/Practice/

Spero di non essere andato troppo off topic.

[devAngnew]

Originariamente inviato da yossarian

quindi, secondo il tuo ragionamento, ci si ferma al frame iniziale. Ok, allora si gioca per un solo frame che parte in ritardo, ma tanto cosa importa al giocatore, e finisce dopo 1/60 di secondo.
E quelli successivi? Quando vengono caricati? E quando viene fatta l'operazione di sostituzione? Sempre prima dell'inizio del frame? Magari prima dell'inizio del primo frame? Oppure per gli altri la sostituzione è gratis?
Interessante 'sta cosa
Ti sfugge che dati e istruzioni sono caricati di continuo una volta partita l'elaborazione e che ogni volta deve essere fatta l'operazione di sostituzione che fa perdere, comunque, cicli di clock, per cui non si può eseguire una madd alla massima velocità possibile?

Bha semmai i dati sono caricati di continuo ma il codice shader dovrebbe essere caricato prima di partire con il livello, altrimenti non ci sarebbe compilatore che tenga si ATI che NVIDIA.

[yossarian]

Originariamente inviato da devAngnew

Bha semmai i dati sono caricati ma il codice shader dovrebbe essere caricato prima di partire con il livello, altrimenti non ci sarebbe compilatore che tenga si ATI che NVIDIA.

questa non l'ho capita; cosa intendi dire? Che la sostituzione avviene prima che si sappia quali istruzioni si devono elaborare? E dove avverrebbe? Il chip sa quali istruzioni deve eseguire solo dopo averle caricate e non ha modo di caricare tutti gli shader di un gioco nello stesso tempo e il compilatore ha bisogno di girare su qualcosa (non agisce al di fuori di un supporto fisico a meno che per compilatore non intendii un coder che si metta a fare la traduzione a manina di tutto il programma ). Il compilatore serve a istruire il chip su come riordinare ed eventualmente sostiture delle istruzioni ma solo dopo che il chip le ha incontrate. Ovvero il compilatore gli dice: guarda che quando trovi questo tipo di istruzione devi sostituirlo con quest'altra. Ma la condizione è che prima il chip incontri quell'istruzione e poi che la sostituisca. Altrimenti nisba. Non esiste un compilatore che "affidi al chip il codice originario già interamente ricompilato". Se fosse possibile caricare tutte le istruzioni relative ad un gioco sul chip e fosse possibile procedere al riordino delle stesse prima dell'inizio del rendering, i chip ATi avrebbero un rendimento prossimo al 100% e una 4850 sarebbe pari ad una 285 gtx in tutte le situazioni. Invece ci si deve acocntentare di quello che si riesca a caricare negli instruction buffer
L'unico modo per non avere overhead è che il codice originario faccia uso di fma invece che di madd. Gli shader che si trovano nei giochi hanno istruzioni di tipo madd e sono quelle che arrivano alla gpu e non le fma (ti sfugge questo piccolo particolare).
Comunque, sto ancora aspettando che mi linki un documento in cui si mostri come sia possibile questa operazione di sostituzione, magari senza issue o performance hit.

[devAngnew]

Originariamente inviato da yossarian

questa non l'ho capita; cosa intendi dire? Che la sostituzione avviene prima che si sappia quali istruzioni si devono elaborare? E dove avverrebbe? Il chip sa quali istruzioni deve eseguire solo dopo averle caricate e non ha modo di caricare tutti gli shader di un gioco nello stesso tempo e il compilatore ha bisogno di girare su qualcosa (non agisce al di fuori di un supporto fisico a meno che per compilatore non intendii un coder che si metta a fare la traduzione a manina di tutto il programma ). Il compilatore serve a istruire il chip su come riordinare ed eventualmente sostiture delle istruzioni ma solo dopo che il chip le ha incontrate. Ovvero il compilatore gli dice: guarda che quando trovi questo tipo di istruzione devi sostituirlo con quest'altra. Ma la condizione è che prima il chip incontri quell'istruzione e poi che la sostituisca. Altrimenti nisba. Non esiste un compilatore che "affidi al chip il codice originario già interamente ricompilato".
L'unico modo per non avere overhead è che il codice originario faccia uso di fma invece che di madd. Gli shader che si trovano nei giochi hanno istruzioni di tipo madd e sono quelle che arrivano alla gpu e non le fma (ti sfugge questo piccolo particolare).

Ma secondo te uno shader scritto in HLSL o in GLSL viene eseguito cosi com'è dalla GPU al volo io dico di no...

[yossarian]

Originariamente inviato da devAngnew

Ma secondo te uno shader scritto in HLSL o in GLSL viene eseguito cosi com'è dalla GPU al volo io dico di no...

io dico che non hai capito niente di tutto il discorso.
Rileggiti tutto con calma

[appleroof]

Originariamente inviato da Athlon 64 3000+

Qua hanno fatto con Dirt 2 un benchmark dove ci i test delle hd 5000 series(non la HD 5970) sulle dx9 e dx11 e il frame rate con quest'ultime attivate fa calare di non poco il frame rate.
http://www.pcgameshardware.com/aid,7...X-11/Practice/

Spero di non essere andato troppo off topic.

La mia "paura", nata in realtà solo dall'unigine che mostra una "tassellazione massiccia" è che queste prime vga dx11 non saranno in grado di gestire la nuova feature al massimo (e si che pure io avevo capito che tassellazione= sempre maggiore qualità a parità di prestazioni complessive, ma evidentemente ho capito male )

d'altra parte sarebbe sempre la solita storia, basta vedere le vga dx9 dove le prime si sognavano cmq le prestazioni delle ultime e pur sempre vga dx9 erano

cmq vedremo, ma ripeto, mi faccio poche illusioni


p.s.: cmq se è vero che g100 emulerà il tassellatore direi che giocoforza andrà peggio rispetto ad una vga con unità dedicata come rv 870 nei giochi con tassellazione, anche se nel complesso avrà più potenza di quest'ultimo....correggetemi se sbaglio.

[devAngnew]

Originariamente inviato da yossarian

io dico che non hai capito niente di tutto il discorso.
Rileggiti tutto con calma

Allora siamo in due....
Io invece penso che forse ti sfugge qualcosa sui compilatori....
E' risaputo che qualunque processore una volta compilato il codice originario ad alto livello (HLSL o GLSL) e ottimizzato lo esegue e basta che poi non è detto che il codice venga eseguito al massimo delle sue possibilità come nel caso ATi è quasi impossibile ottimizzare lo shader compilato di modo che vengano usate tutte e 5 le sue unità VLIW.

[Kharonte85]

Originariamente inviato da appleroof

La mia "paura", nata in realtà solo dall'unigine che mostra una "tassellazione massiccia" è che queste prime vga dx11 non saranno in grado di gestire la nuova feature al massimo (e si che pure io avevo capito che tassellazione= sempre maggiore qualità a parità di prestazioni complessive, ma evidentemente ho capito male )

eh sì...

Originariamente inviato da appleroof

p.s.: cmq se è vero che g100 emulerà il tassellatore direi che giocoforza andrà peggio rispetto ad una vga con unità dedicata come rv 870 nei giochi con tassellazione, anche se nel complesso avrà più potenza di quest'ultimo....correggetemi se sbaglio.

Senza dubbio peggio, ma se hai ragione nella prima parte difficilmente il tesselatore sarà sfruttato a questo giro se non nei soliti 2-3 giochi altamente sponsorizzati o come diceva qualcuno più indietro come lo "zafferano sul risotto".

[yossarian]

Originariamente inviato da devAngnew

Allora siamo in due....
Io invece penso che forse ti sfugge qualcosa sui compilatori....
E' risaputo che qualunque processore una volta compilato il codice originario ad alto livello (HLSL o GLSL) e ottimizzato lo esegue e basta che poi non è detto che il codice venga eseguito al massimo delle sue possibilità come nel caso ATi è quasi impossibile ottimizzare lo shader compilato di modo che vengano usate tutte e 5 le sue unità VLIW.

allora spiega nel dettaglio come funziona la compilazione del codice ad alto livello e come il processore, una volta compilato il codice, esegue le istruzioni tenendo conto del flusso di istruzioni e non di quelle poche caricate nei registri interni del chip. E magari spiegaci anche perchè con ATi è impossibile ottimizzare lo shader (ma evidentemente lo è anche con nVidia visto che neppure gt200 raggiunge un rendimento del 100%). Infine, se come pare di capire dalle tue parole, una volta compilato il codice ad alto livello il chip ha a disposizione tutte le istruzioni del sw che deve far girare e può gestirlo a suo piacimento, spiegaci a cosa servono le operazioni di branching
Così vediamo chi non ha le idee chiare

[persa]

in effetti il tessellator sembrerebbe proprio una mazzata che aumenta si la qualità, ma poi ti toglie anche 20-30frames.

ora, immagino che sui giochi che ne faranno 80-70 si potrà utilizzarlo con frames di 50-60.. ma se esce un giocho che già senza fa 50-60 frames, addio tessellator.

[Kharonte85]

Originariamente inviato da leoneazzurro

E' proprio quello che non torna. In pratica dice in tutto l'articolo che le capacità teoriche di GF100 lo renderebbero due volte più veloce di una GTX285, ma dimentica di dire che se fosse per le capacità teoriche anche la 5870 sarebbe due volte più veloce di una HD4890 (90, non 70).
Insomma, è una risposta troppo "alla carlona", e non me lo aspetto da uno come Rys. Tralascia le limitazioni del setup (e GF100 a differenza di Cypress non sembra avere il doppio rasterizzatore), della banda (che non è il doppio della GTX285), del fillrate (che non è il doppio delle GTX285), senza contare che non solo non sappiamo nulla del texel fill rate, ma che anche con le CPU dell'anno prossimo schede come le 5970 e le GF100 rischiano di essere limitate in molti scenari dalla CPU.

Forse voleva riferirsi a gt200 in configurazione doppia ovvero alla gtx 295, altrimenti il discorso del "doppio" della gtx 285 non ha senso alcuno (non ci sono nemmeno i numeri teorici) e su questo sono d'accordo...non è mai successo e mai succederà di avere un incremento del 100%, mentre invece è già successo che la dual GPU di generazione precedente venisse battuta dalla single GPU di generazione successiva.

[appleroof]

Originariamente inviato da Kharonte85

eh sì...


Senza dubbio peggio, ma se hai ragione nella prima parte difficilmente il tesselatore sarà sfruttato a questo giro se non nei soliti 2-3 giochi altamente sponsorizzati o come diceva qualcuno più indietro come lo "zafferano sul risotto".

già hai ragione...c'è da dire però che un motore che prevede la tassellazione potrebbe "regolarla" su vari livelli in modo da essere scalabile da questo punto di vista specifico,,,,vediamo

[halduemilauno]

Originariamente inviato da appleroof

La mia "paura", nata in realtà solo dall'unigine che mostra una "tassellazione massiccia" è che queste prime vga dx11 non saranno in grado di gestire la nuova feature al massimo (e si che pure io avevo capito che tassellazione= sempre maggiore qualità a parità di prestazioni complessive, ma evidentemente ho capito male )

d'altra parte sarebbe sempre la solita storia, basta vedere le vga dx9 dove le prime si sognavano cmq le prestazioni delle ultime e pur sempre vga dx9 erano

cmq vedremo, ma ripeto, mi faccio poche illusioni


p.s.: cmq se è vero che g100 emulerà il tassellatore direi che giocoforza andrà peggio rispetto ad una vga con unità dedicata come rv 870 nei giochi con tassellazione, anche se nel complesso avrà più potenza di quest'ultimo....correggetemi se sbaglio.

la tessellazione va vista come un filtro se lo applichi, lo usi, ecco che l'immagine è migliore ma a scapito delle prestazioni. magari l'emulato non rende quanto l'altro sul piano della qualità ma rende meglio sul piano delle prestazioni quindi tocca vedere il rapporto qualità/prezzo ovvero decadimento prestazionale una volta applicato. ovviamente son solo ipotesi, tutte da verificare.

[Kharonte85]

Originariamente inviato da Marko91

Con quelle specifiche dovrebbe essere tra il 20% e il 30% più veloce di una HD5870.

E' quello che mi aspetto anche io...ad Hemlock non ci arriva imho.

Originariamente inviato da halduemilauno

la tessellazione va vista come un filtro se lo applichi, lo usi, ecco che l'immagine è migliore ma a scapito delle prestazioni.

magari l'emulato non rende quanto l'altro sul piano della qualità ma rende meglio sul piano delle prestazioni quindi tocca vedere il rapporto qualità/prezzo ovvero decadimento prestazionale una volta applicato. ovviamente son solo ipotesi, tutte da verificare.

Io direi piuttosato che probabilmente l'emulato rendebbe uguale come qualità ma perdebbe parecchio come prestazione...vuoi mettere avere un hardware dedicato che fa solo quello? Naa...anche ad essere molto molto ottimisti non ci si puo' sperare (se è vero che non c'è perchè non è ancora detto).