[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[yossarian]

Originariamente inviato da Foglia Morta

Ho interpretato male io ?

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

1° pagina:

Fermi now has single-SM clusters, although each SM is effectively a pair of 16-way vector sub blocks. Sub-block configuration is the key to Fermi implementation configuration. GF100, the high-end part that Nvidia outlines in the whitepaper, uses two different sub blocks in each of its sixteen SMs.

4° pagina:

Going back to the sub-block discussion, it should be clear how Nvidia might scale Fermi down to smaller variants and create derivatives. Nvidia could simply (and we use that term with all due respect to the actual difficulty involved) replace the DP-capable sub block with another of the simpler blocks. They could retain everything else about the SM, including the same scheduler, near pools, register file and even the operand gather logic.

That lets them create non-DP variants, losing some of the fearsome integer rate in the process as well (some of the integer hardware is shared with the DP silicon, necessitating that), for derivatives that don't require it, because they're addressing different markets.

Double-precision floating point is almost exclusively a non-graphics feature of GPUs, at least at this point in time (although, of course, extended-precision computation takes place all over the chip in non-programmable forms), and so it still makes sense to remove it from derivative, smaller, cheaper parts.

This modularity might also let Nvidia attempt a part with two DP sub blocks, with fairly minimal changes to the SM front end, if they so wish. Doing so will cost them area and power, but it's something they could take on. Overtaking the per-FPU, per-clock DP rate of Intel's microprocessors has to be appealing on some level.

mi sa di si
secondo l'articolo ogni cluster è composto da 16 alu fp64 divise in due sub-blocchi fp32 (il concetto è lo stesso epsresso da me prima ma partendo dall'assunto che si tratta di unità fp64 che possono lavorare a fp32 raddoppiando la capacità di calcolo teorica invece del contrario). Si sostiene che nVidia possa ricavare chip di fasci più bassa utilizzando, invece di cluster di 16 alu fp64 (ovvero 32 alu fp32) cluster di 16 alu fp32. (in tal caso, sembrerebbe che questi chip derivati non siano in grado di eseguire calcoli a fp64).
La cosa mi lascia piuttosto perplesso in quanto intanto non mi risulta che la alu di GT300 siano di tipo fp64 native me che, come in larrabee, si utilizzino 2 alu fp32 per eseguire calcoli a fp64. In secondo luogo, mi suona strano che per passare ad un chip derivato si modifichi la struttura del singolo cluster (cosa mai avvenuta finora).

[yossarian]

Originariamente inviato da devAngnew

Lasciando per ora da parte il problema della propagazione dell'errore quindi possibili artefatti, IMO lo shader viene caricato (shader scritto ad alto livello) successivamente (viene compilato) questo vale sia per ATI che NVIDIA ora si avrà il codice in ASSEMBLER a questo punto dovrebbero partire eventuali ottimizzazioni nel caso NVIDIA sostituitirebbe alla MADD la FMA ma questo lo fà solo una volta prima dell'esecuzione (dello shader) perdendo questo tempo all'inizio prima che una scena venga renderizzata.

ripeto, non cambia assolutamente nulla: se hai 20 madd in uno shader devi eseguire 20 volte la sostituzione, che sia all'interno del buffer o in runtime. Non basta eseguire una sostituzione che valga per 20 o 50 istruzioni. La sostituzione avviene ogni volta che si incontra un'istruzione di tipo madd

[okorop]

Originariamente inviato da Psyco89

Ma scusa lo sai che la 4870 ha una potenza in SP di 1.3TFlop/s ?
& la GTX 285 0.78 Tflop/s in SP ?

Eppure fra GTX 285 e 4870 c'è un bel distacco.
Ripeto che dai dati sembra che Nvidia abbia migliorato più di ATI e ha anche una banda passante, più ROPS ecc, bisogna vedere poi come vengono gestite le cose.


Come mai la 4870 non è stata in grado di battere la GTX 285 ? nonostante la differenza netta in SP ? quella potenza in più dove è finita ?



.

l'uso degli stream processors in fermi è diverso da quello di gt200, ati è andata molto vicina alle prestazioni in singola scheda della gtx285 con la 4890

[Severnaya]

Originariamente inviato da Psyco89

Come mai la 4870 non è stata in grado di battere la GTX 285 ? nonostante la differenza netta in SP ? quella potenza in più dove è finita ?

io da profano confronterei la 4870 con la 280 e nn con la 285

[okorop]

Originariamente inviato da Severnaya

io da profano confronterei la 4870 con la 280 e nn con la 285

quoto ed aggiungo che la gtx280 andava un 20% in piu' della 4870 proprio per gli shader unificati in cui gt200 riusciva a trarre maggior vantaggio rispetto alla soluzione ati, lo scenario che si prospetta con gt100 potrebbe anche essere completamente diverso, con ati che dovrà svolgere meno ottimizzazione dei driver rispetto a nvida

[yossarian]

Originariamente inviato da Psyco89

Ma scusa lo sai che la 4870 ha una potenza in SP di 1.3TFlop/s ?
& la GTX 285 0.78 Tflop/s in SP ?

Eppure fra GTX 285 e 4870 c'è un bel distacco.
Ripeto che dai dati sembra che Nvidia abbia migliorato più di ATI e ha anche una banda passante, più ROPS ecc, bisogna vedere poi come vengono gestite le cose.


Come mai la 4870 non è stata in grado di battere la GTX 285 ? nonostante la differenza netta in SP ? quella potenza in più dove è finita ?



.

facciamo un'altra precisazione; i dati riportati in tabella riguardano le madd per gt200 e non le flops; gt200 può eseguire una madd e una mul per ciclo, quindi la potenza di calcolo teorica è di 1,063 Tflops e non di 708. Invece, GT300 pare non abbia la capacità di eseguire mul aggiuntive ma solo madd (o fma).
Inoltre, con codice dx10.1 la 4890 riesce a battere la 285 gtx. Se prorpio vuoi fare un confronto fallo completo: la 4890 è dx10.1 la 285 gtx no.

http://www.hwupgrade.it/articoli/skv...a-media_9.html

ad esempio, per hawx leggo 91/77/67 per la 285 gtx in dx10 e 102/86/78 per la 4890 in dx10.1. Peccato che i driver acerbi non facciano avere gli stessi incrementi percentuali alle vga con rv870

[A.L.M.]

Originariamente inviato da yossarian

ripeto, non cambia assolutamente nulla: se hai 20 madd in uno shader devi eseguire 20 volte la sostituzione, che sia all'interno del buffer o in runtime. Non basta eseguire una sostituzione che valga per 20 o 50 istruzioni. La sostituzione avviene ogni volta che si incontra un'istruzione di tipo madd

Interessante, non ho capito se però Rys (che scrive l'articolo) sia della stessa idea.

Originariamente inviato da yossarian

facciamo un'altra precisazione; i dati riportati in tabella riguardano le madd per gt200 e non le flops; gt200 può eseguire una madd e una mul per ciclo, quindi la potenza di calcolo teorica è di 1,063 Tflops e non di 708. Invece, GT300 pare non abbia la capacità di eseguire mul aggiuntive ma solo madd (o fma).

Mah, sulle missing MUL io non farei molto affidamento...
Erano talmente utili che alla prima occasione utile se le sono levate dai piedi...

Originariamente inviato da Psyco89

Ma scusa lo sai che la 4870 ha una potenza in SP di 1.3TFlop/s ?
& la GTX 285 0.78 Tflop/s in SP ?

Eppure fra GTX 285 e 4870 c'è un bel distacco.
Ripeto che dai dati sembra che Nvidia abbia migliorato più di ATI e ha anche una banda passante, più ROPS ecc, bisogna vedere poi come vengono gestite le cose.


Come mai la 4870 non è stata in grado di battere la GTX 285 ? nonostante la differenza netta in SP ? quella potenza in più dove è finita ?

Per essere più chiari, la potenza teorica delle ATI è più teorica di quella delle NVidia...

Solo se si riescono a tenere occupati tutti e 5 i core di ogni shader unit si raggiunge la potenza teorica max. Dato che questo non avviene, ma al massimo se ne occupano 2-3, questo porta ad un primo ridimensionamento delle prestazioni. Dipende molto da come è scritto il gioco. E' il prezzo che si deve pagare per avere shaders che occupano poco spazio nella gpu.
Un altro limite che hanno le ATI è nel texturing power, che a partire da R600 in poi è più limitato che nelle NVidia. Considera però che Fermi avrà lo stesso rapporto tra numero di shaders e numero di TMU di RV870, quindi questo vantaggio è andato.

[devAngnew]

Originariamente inviato da yossarian

ripeto, non cambia assolutamente nulla: se hai 20 madd in uno shader devi eseguire 20 volte la sostituzione, che sia all'interno del buffer o in runtime. Non basta eseguire una sostituzione che valga per 20 o 50 istruzioni. La sostituzione avviene ogni volta che si incontra un'istruzione di tipo madd

Secondome stiamo parlano due lingue diverse
Bha allora i compilatori e gli ottimizzatori a cosa servono a nulla da quello che dici tu.
Questo non ha senso.

[yossarian]

Originariamente inviato da A.L.M.

Interessante, non ho capito se però Rys (che scrive l'articolo) sia della stessa idea.

quale sia l'idea di Rys conta relativamente: innanzitutto è da vedere se è possibile eseguire la sostituzione; poi è da vedere quando è possibile. Infine, a livello di driver, l'unico modo in cui si può agire è quello che ho descritto: il driver può solo indicare all'hw di effettuare una determinata operazione quando si trova di fronte ad un certo tipo di chiamata. Ad esempio, di fronte ad una madd, il driver indica all'hw di eseguire una mull un troncamento ed una add con arrotondamento. Il processo è questo: il thread processor preleva l'istruzione, la legge, la interpreta e la manda in esecuzione in base a quelli che sono i parametri della programmazione a basso livello. Il driver può intervenire su questi parametri andando a modificare l'esecuzione dell'istruzione. In tal caso può suggerire al chip di sostituire una madd con una fma. Il thread processor, quindi preleva la istruzione la decodifica e, una volta capito che si tratta di una madd la sostituisce con una fma (uno step in più rispetto all'esecuzione standard) e poi la manda in esecuzione.
Un ulteriore problema sorge nel momento in cui questo tipo di operazioni non sono sempre possibili (ed è il caso di shader molto lunghi o che richiedono una particolare precisione). Questo significa che l'operazione deve essere analizzata caso per caso e non si può effettuare indiscriminatamente l'operazione di sostituzione dell'istruzione.
Può sembrare strano parlare di precisione quando sappiamo che le fma restituiscono risultati più precisi delle madd, ma le cose stanno propio così. Quando un coder dà una certa istruzione è perchè si aspetta un determinato risultato che tiene conto anche degli eventuali arrotondamenti o troncamenti. L'assenza di uno qualsiasi dei passaggi previsti può dar luogo a risultati diversi da quelli desiderati o attesi.

[yossarian]

Originariamente inviato da devAngnew

Secondome stiamo parlano due lingue diverse
Bha allora i compilatori e gli ottimizzatori a cosa servono a nulla da quello che dici tu.
Questo non ha senso.

stai suggerendo che i chip nVidia, con architettura superscalare, operino at compile time? Oppure non hai idea di come funzioni internamente un chip? O, magari, pensi che la sostituzione avvenga, come per incanto, istantaneamente, in tutto lo shader o, magari, in tutti gli shader caricati?
Visto che sei così sicuro, ti invito a trovarmi un documento in cui si spieghi come effettuare la sostituzione o un documento in cui si spieghi come eseguire delle madd su pipeline di tipo fma

[devAngnew]

Originariamente inviato da yossarian

stai suggerendo che i chip nVidia, con architettura superscalare, operino at compile time? Oppure non hai idea di come funzioni internamente un chip

Se non ricordo male già dai tempi di NV30 Nvidia faceva uso di un compilatore di shader e se non erro in G80 e derivati quindi G200 fanno lo stesso ed hanno ottimizzato la cosa ancor di più in Fermi con JIT compiler performante però ora non ricordo dove lo lessi.

[yossarian]

Originariamente inviato da devAngnew

Se non ricordo male già dai tempi di NV30 Nvidia faceva uso di un compilatore di shader e se non erro in G80 e derivati quindi G200 fanno lo stesso ed hanno ottimizzato la cosa ancor di più in Fermi con JIT compiler performante però ora non ricordo dove lo lessi.

tutti fanno uso di compilatori, spesso si fanno anche operazioni di shader reordering e, talvolta, di shader replacement (molto frequenti ai tempi di nv30).
Il principio è sempre lo stesso: quando incontri quel tipo di istruzione sostituiscila con quest'altra. Che questo valga per una singola istruzione o per un intero shader (con nv30 si sotituivano interi pezzi di codice dx9 con codice dx8) la cosa non cambia.
State montando un caso per una battuta di Rys (ed è quello che dovranno fare i driver) buttata li senza spiegare come o quando e se la stessa sarà possibile senza problemi (e non credo che neppure lui sia in grado di rispondere)
Questa fa il paio con quella del tessellator che "tanto sarà emulato via sw senza alcun problema" (poi magari ci spiegherà come e perchè si perde tempo a implementare funzioni in hw se possono essere emulate via sw senza problemi) o con quella sulle alu fp64 che su chip di fascia bassa diventano fp32
Forse, prima di avventurarsi in previsioni, sarebbe opportuno avere qualche informazione in più anche a livello di benchmark.

[Foglia Morta]

Nel caso di nVidia è questo: http://developer.nvidia.com/object/cg_toolkit.html . edit. risolto

[okorop]

Originariamente inviato da Foglia Morta

Nel caso di nVidia è questo: http://developer.nvidia.com/object/cg_toolkit.html . edit. risolto

http://developer.amd.com/Pages/default.aspx

[devAngnew]

Originariamente inviato da yossarian

tutti fanno uso di compilatori, spesso si fanno anche operazioni di shader reordering e, talvolta, di shader replacement (molto frequenti ai tempi di nv30).

Ovviamente

Il principio è sempre lo stesso: quando incontri quel tipo di istruzione sostituiscila con quest'altra. Che questo valga per una singola istruzione o per un intero shader (con nv30 si sotituivano interi pezzi di codice dx9 con codice dx8) la cosa non cambia.

Appunto non cambia, una volta compilato e ottimizzato lo shader è eseguito alla max velocità possibile dalla GPU quindi l'overhead di sostituzione delle istruzione non persiste più ma ci sarà solo quello dovuto all'exe dell' FMA.

[Foglia Morta]

Originariamente inviato da yossarian

tutti fanno uso di compilatori, spesso si fanno anche operazioni di shader reordering e, talvolta, di shader replacement (molto frequenti ai tempi di nv30).
Il principio è sempre lo stesso: quando incontri quel tipo di istruzione sostituiscila con quest'altra. Che questo valga per una singola istruzione o per un intero shader (con nv30 si sotituivano interi pezzi di codice dx9 con codice dx8) la cosa non cambia.
State montando un caso per una battuta di Rys (ed è quello che dovranno fare i driver) buttata li senza spiegare come o quando e se la stessa sarà possibile senza problemi (e non credo che neppure lui sia in grado di rispondere)
Questa fa il paio con quella del tessellator che "tanto sarà emulato via sw senza alcun problema" (poi magari ci spiegherà come e perchè si perde tempo a implementare funzioni in hw se possono essere emulate via sw senza problemi) o con quella sulle alu fp64 che su chip di fascia bassa diventano fp32
Forse, prima di avventurarsi in previsioni, sarebbe opportuno avere qualche informazione in più anche a livello di benchmark.

Penso sia perchè JHH pone fiducia nel compilatore. Secondo lui NV30 è una bella architettura ma rimasta incompresa... e non vuole che anche Fermi resti una gpu incompresa , almeno da questa intervista pare così: http://tech.tbreak.com/2009/11/nvidi...-hsun-huang/3/

[okorop]

Originariamente inviato da devAngnew

Ovviamente




Appunto non cambia, una volta compilato e ottimizzato lo shader è eseguito alla max velocità possibile dalla GPU quindi l'overhead di sostituzione delle istruzione non persiste più ma ci sarà solo quello dovuto all'exe dell' FMA.

ma scusa una cosa la gpu compila le fma poi deve sostituirle in madd tutte le volte e quindi gli exe dell'fma si presenteranno sempre creando overhead, oppure sbaglio qualcosa?

Originariamente inviato da Foglia Morta

Penso sia perchè JHH pone fiducia nel compilatore. Secondo lui NV30 è una bella architettura ma rimasta incompresa... e non vuole che anche Fermi resti una gpu incompresa , almeno da questa intervista pare così: http://tech.tbreak.com/2009/11/nvidi...-hsun-huang/3/

mi metto le mani nei capelli allora, ci sarà da piangere........

[leoneazzurro]

Originariamente inviato da Kharonte85

In realtà lui fa riferimento proprio a quelle in quasi tutto l'articolo...per il resto credo che lo scenario che disegni sia molto credibile, dubito fortemente anche io che riesca a superare hemlock.

Sul fatto del tesselatore mi rende perplesso che siano così sicuri in quell'articolo...sbaglio o il tesselatore via hardware è espressamente richiesto come requisito delle dx11? In questo caso come farebbe nvidia a dichiararsi dx11 se non ce l'ha?

Non so, non c'è nemmeno un accenno a quanti fps "faccia" GF100, le speculazioni sono tutte sul lato delle prestazioni teoriche (quanti FLOPs, quanti texel, il fill rate, ecc.) che come sappiamo spesso non si traducono in prestazioni pure. Per esempio, lo SLI di GTX285 avrà sempre più banda passante e più triangoli/s rispetto a GF100. Se si tende ad essere limitati da questi fattori ci si ritrova esattamente nella situazione della 5870 rispetto alla 4870x2. Per il tessellatore, basta che si rispettino le chiamate dell'API.

Originariamente inviato da Psyco89

Ma scusa lo sai che la 4870 ha una potenza in SP di 1.3TFlop/s ?
& la GTX 285 0.78 Tflop/s in SP ?

Eppure fra GTX 285 e 4870 c'è un bel distacco.
Ripeto che dai dati sembra che Nvidia abbia migliorato più di ATI e ha anche una banda passante, più ROPS ecc, bisogna vedere poi come vengono gestite le cose.

Come mai la 4870 non è stata in grado di battere la GTX 285 ? nonostante la differenza netta in SP ? quella potenza in più dove è finita ?

.

Ci sono diversi fattori che influenzano le prestazioni oltre ai FLOPS: le capacità di texturing, la banda passante, il fill rate e lo z-rate delle ROPs, le capacità di elaborazione geometrica, ecc. Quindi dire che la 4870 avesse più FLOPS della GTX285 è poco significativo se non si ricorda che fill rate, Z rate, banda passante e capacità di texturing erano maggiori nelle GTX285.
Poi una cosa è la capacità di calcolo di picco, un'altra è quella effettivamente raggiungibile nelle applicazioni. RV770 da alcuni dati emersi in rete ha su applicazioni grafiche una utilizzazione media delle unità shader del 70%, mentre GT200 tende a superare il 90%. Per cui le capacità di calcolo -pratiche- di tali chip sono pressappoco sullo stesso piano e le differenze riguardano gli altri fattori visti prima. Infine viene la programmazione: se il codice tende a sfruttare meglio le unità di RV770 allora questo sarà più veloce, se invece ad esempio si utilizza codice con parecchie istruzioni scalari e dipendenti GT200 è favorito.

[yossarian]

Originariamente inviato da devAngnew

Appunto non cambia, una volta compilato e ottimizzato lo shader è eseguito alla max velocità possibile dalla GPU quindi l'overhead di sostituzione delle istruzione non persiste più ma ci sarà solo quello dovuto all'exe dell' FMA.

e l'overhead per la compilazione e l'ottimizzazione dello shader non lo calcoli? O quelle sono gratis?
La sostituzione o la fai prima o dopo non cambia nulla; 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?

[Ren]

Yoss, volevo chiederti una cosa slegata dal discorso fermi.

Vedo che le moderne GPU possono indirizzare solo 16 vertici per ciclo di clock.

Quante unità simd possono essere allocate per il calcolo dei vertex ?

Mi verrebbe spontaneo pensare che al massimo un solo stream cluster possa essere allocato, dato che ogni vettore fp32 gestisce un triangolo.

Le animazioni impegnano i geometry o i vertex shader ?
In che misura rispetto alla mera generazione della scena tridimensionale ?

Scusa OT.