[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[Greifi Grishnackh]

azz stare appresso a questo 3d è diventata una cosa impossibile lol

sia sa qualcosa di cosa accadrà nei prossimi giorni? si prevede che ci saranno un po di informazioni in piu?? oppure nuovamente tutto tace fino a marzo?

[Kharonte85]

Originariamente inviato da mapoetti

non sò se posso postare mi è appena arrivato per posta le news solite di hardware upgrade

http://www.hwupgrade.it/articoli/skv...ura_index.html

Postarlo puoi postarlo...solo che è un filino ne parliamo da 2gg

Originariamente inviato da Greifi Grishnackh

azz stare appresso a questo 3d è diventata una cosa impossibile lol

sia sa qualcosa di cosa accadrà nei prossimi giorni? si prevede che ci saranno un po di informazioni in piu?? oppure nuovamente tutto tace fino a marzo?

Vallo a sapere...qualcosa forse trapelerà, di solito un mesetto prima le specifiche si sanno per vie non ufficiali.

[luX0r.reload]

Originariamente inviato da Greifi Grishnackh

azz stare appresso a questo 3d è diventata una cosa impossibile lol

sia sa qualcosa di cosa accadrà nei prossimi giorni? si prevede che ci saranno un po di informazioni in piu?? oppure nuovamente tutto tace fino a marzo?

Per Marzo spero abbiano anche sistemato un po' i consumi... così sarebbe perfetta! Già me la immagino la 360 che ruggisce dentro il mio case mentre mi sparo qualche oretta di Alien Vs Predator

[luX0r.reload]

Originariamente inviato da Ratatosk

Ma non era già in produzione durante il CES? Come fanno a sistemare i consumi su un chip in produzione?

[eXeS]

Un baco nei nuovi WHQL, in pratica non si riesce più ad occare con rivatuner e derivati, potrebbe suggerire la presenza di più clock domain in GF100
http://forums.guru3d.com/showpost.ph...08&postcount=7

[Greifi Grishnackh]

Originariamente inviato da Ratatosk

Tutto tace no, a marzo, alla presentazione, ci saranno già altre 100 pagine di thread.

io ne prevedo almeno 200...sono un ottimista

Originariamente inviato da luX0r.reload

Per Marzo spero abbiano anche sistemato un po' i consumi... così sarebbe perfetta! Già me la immagino la 360 che ruggisce dentro il mio case mentre mi sparo qualche oretta di Alien Vs Predator

a chi lo dici...

EDIT:

Originariamente inviato da eXeS

Un baco nei nuovi WHQL, in pratica non si riesce più ad occare con rivatuner e derivati, potrebbe suggerire la presenza di più clock domain in GF100
http://forums.guru3d.com/showpost.ph...08&postcount=7

azz è vero li ho installati questo pomeriggio e ora provando con evga precision non occa piu
non legge lo shader clock

Originariamente inviato da Greifi Grishnackh

io ne prevedo almeno 200...sono un ottimista

a chi lo dici...

EDIT:

azz è vero li ho installati questo pomeriggio e ora provando con evga precision non occa piu
non legge lo shader clock

l'unico programma a leggere correttamente lo shader clock è il FIRESTORM DI ZOTAC (funziona anche con altre marche a patto ti tener premuto il tasto shift quando lo si avvia)....ma comunque non si puo' overcloccare al momento.In attesa di un fix.

[yossarian]

Originariamente inviato da eXeS

Un baco nei nuovi WHQL, in pratica non si riesce più ad occare con rivatuner e derivati, potrebbe suggerire la presenza di più clock domain in GF100
http://forums.guru3d.com/showpost.ph...08&postcount=7

ci saranno di sicuro se è vero che si parla, ad esempio, di "sole" 64 tmu.

[Foglia Morta]

Originariamente inviato da yossarian

ci saranno di sicuro se è vero che si parla, ad esempio, di "sole" 64 tmu.

La frequenza delle tmu è la metà di quella delle alu quindi era lecito aspettarsi un clock molto elevato per quest'ultime ( come ipotizzava Rys ), dopo che è scaduto l' nda sul forum di b3d ha detto che non è più dell' opinione di mesi fa e secondo lui non raggiungeranno le frequenze sperate.

[yossarian]

Originariamente inviato da Foglia Morta

La frequenza delle tmu è la metà di quella delle alu quindi era lecito aspettarsi un clock molto elevato per quest'ultime ( come ipotizzava Rys ), dopo che è scaduto l' nda sul forum di b3d ha detto che non è più dell' opinione di mesi fa e secondo lui non raggiungeranno le frequenze sperate.

che non avrebbero raggiunto le frequenze sperate non l'ho mai messo in dubbio (se le frequenze sperate erano 1700, 1800 MHz per lo shader core). Che le tmu viaggino a frequenze pari a metà di quelle dello shader core non ne sarei così sicuro, ormai, Con lo shader core a 1400-1500 MHz (tanto per fare un esempio), la capacità di fare texture sampling di gf100 sarebbe inferiore a quella di GT200.

Molto più probabile che impostino un clock per lo shader core, uno per il resto del chip ed uno per le tmu (il più alto possibile) che rischiano di diventare uno dei colli di bottiglia del sistema.

[Foglia Morta]

Originariamente inviato da yossarian

che non avrebbero raggiunto le frequenze sperate non l'ho mai messo in dubbio (se le frequenze sperate erano 1700, 1800 MHz per lo shader core). Che le tmu viaggino a freuquenze pari a metà di quelle dello shader core non ne sarei così sicuro, ormai, Con lo shader core a 1400-1500 MHz (tanto per fare un esempio), la capacità di fare texture sampling di gf100 sarebbe inferiore a quella di GT200.

Molto più probabile che impostino un clock per lo shader core, uno per il resto del chip ed uno per le tmu (il più alto possibile) che rischiano di diventare uno dei colli di bottiglia del sistema.

Penso siano le informazioni date da nVidia:

http://www.anandtech.com/video/showdoc.aspx?i=3721&p=2

Speaking of performance, we’ll get to that in a bit, but for now we’ll finish our discussion of GF100’s graphics units. Each SM has 4 texture units, which have changes somewhat from the GT200. In GT200, the texture units were at the TPC level; here they are per SM. The texture units are also affected by the cache reorganization of GF100; for L1 cache they still have the same 12KB of texture cache per set of 4 texture units, while they all share GF100’s 768KB L2 cache, which is now used by all execution units and not just textures. Each unit can compute 1 texture address and fetch 4 texture samples per clock, a significantly higher texture fetch rate than on the GT200. Furthermore in conjunction with DX11, NVIDIA’s texture units now support DX11’s new compressed texture formats. Finally, texture units are now tied to the shader clock and not the core clock. They run at 1/2 the shader clock speed of GF100.

[Caterpillar86]

Funzionerà su schede madri con pci express 1.0?

[yossarian]

Originariamente inviato da Foglia Morta

Penso siano le informazioni date da nVidia:

http://www.anandtech.com/video/showdoc.aspx?i=3721&p=2

Speaking of performance, we’ll get to that in a bit, but for now we’ll finish our discussion of GF100’s graphics units. Each SM has 4 texture units, which have changes somewhat from the GT200. In GT200, the texture units were at the TPC level; here they are per SM. The texture units are also affected by the cache reorganization of GF100; for L1 cache they still have the same 12KB of texture cache per set of 4 texture units, while they all share GF100’s 768KB L2 cache, which is now used by all execution units and not just textures. Each unit can compute 1 texture address and fetch 4 texture samples per clock, a significantly higher texture fetch rate than on the GT200. Furthermore in conjunction with DX11, NVIDIA’s texture units now support DX11’s new compressed texture formats. Finally, texture units are now tied to the shader clock and not the core clock. They run at 1/2 the shader clock speed of GF100.

ok, quindi hanno abbandonato lo schema tipico delle tmu nVIDIA e hanno adottato quello visto sui chip ATi a partire da R600, con un 1 TAU e 4 TSU per TMU. E l'operazione di interpolazione affidata allo shader core (come su rv870).

[Iantikas]

Originariamente inviato da mapoetti

non sò se posso postare mi è appena arrivato per posta le news solite di hardware upgrade

http://www.hwupgrade.it/articoli/skv...ura_index.html

ma quest'articolo cambia sempre?...


...ieri dicevano di prendere con le pinze i risultati perchè internamente la GTX285 aveva fatto registrare di meno...


....ora invece dice che la GTX285 internamente ha fatto segnare risultati in linea con quelli di nvidia...


...e poi c'è la svista del test sulle ati...


boh

Originariamente inviato da Foglia Morta

Penso siano le informazioni date da nVidia:

http://www.anandtech.com/video/showdoc.aspx?i=3721&p=2

Speaking of performance, we’ll get to that in a bit, but for now we’ll finish our discussion of GF100’s graphics units. Each SM has 4 texture units, which have changes somewhat from the GT200. In GT200, the texture units were at the TPC level; here they are per SM. The texture units are also affected by the cache reorganization of GF100; for L1 cache they still have the same 12KB of texture cache per set of 4 texture units, while they all share GF100’s 768KB L2 cache, which is now used by all execution units and not just textures. Each unit can compute 1 texture address and fetch 4 texture samples per clock, a significantly higher texture fetch rate than on the GT200. Furthermore in conjunction with DX11, NVIDIA’s texture units now support DX11’s new compressed texture formats. Finally, texture units are now tied to the shader clock and not the core clock. They run at 1/2 the shader clock speed of GF100.

ma magari quei clock così impostati son nel caso tutto vada liscio come nvidia ha inizilamente progettato...


...se però non riescono a clocckare gli shader intorno ai 1700mhz ma dovranno inzialmente tenerli intorno ai 1400mhz magari i componenti che girano al "GPC clock" possono viaggiare più veloci e li terrano a più della metà del clock degli shader...


...ciao

[eXeS]

Originariamente inviato da yossarian

si, succedeva anche con gli shader dedicati

Quindi in questa pipeline http://msdn.microsoft.com/en-us/library/dd835170.aspx internamente alla gpu, tutta la parte tra Vertex Shader e Pixel Shader è parallelizzata, e questo spiega perchè gli shader possono agire sui vertici e pixel contemporaneamente, purchè i secondi non derivino dai primi, che figata

Però in tal caso e tornando al tessellator, potendo avere flussi paralleli di vertici che richiedono vertex shading->(hull->tessellation->domain)->geometry shading, se abbiamo una sola unità che fa da hull->tessellation->domain, questa rischia di bloccare l'elaborazione di altri vertici che richiedono la tessellatura, quindi, è vero che hull e domain impegnano shader, ma è anche vero che se la durata della sola tessellatura è predominante rispetto all'hull e domain, la soluzione implementata in fermi potrebbe essere vincente.

Vabbè, solo i primi giochi che useranno la tessellation, ci potranno dare qualche indicazione in più

[yossarian]

Originariamente inviato da eXeS

Quindi in questa pipeline http://msdn.microsoft.com/en-us/library/dd835170.aspx internamente alla gpu, tutta la parte tra Vertex Shader e Pixel Shader è parallelizzata, e questo spiega perchè gli shader possono agire sui vertici e pixel contemporaneamente, purchè i secondi non derivino dai primi, che figata

Però in tal caso e tornando al tessellator, potendo avere flussi paralleli di vertici che richiedono vertex shading->(hull->tessellation->domain)->geometry shading, se abbiamo una sola unità che fa da hull->tessellation->domain, questa rischia di bloccare l'elaborazione di altri vertici che richiedono la tessellatura, quindi, è vero che hull e domain impegnano shader, ma è anche vero che se la durata della sola tessellatura è predominante rispetto all'hull e domain, la soluzione implementata in fermi potrebbe essere vincente.

Vabbè, solo i primi giochi che useranno la tessellation, ci potranno dare qualche indicazione in più

le operazioni di hull e domain shader richiederanno più tempo della tessellatin vera e propria; la tessellation è affidata a fixed function dedicate mentre hull e domain shader sono emulati via vertex e geometry shader (come avviene in RV770). Le differenze nei due approcci sono sostanzialemte che da un lato hai un HW dedicato alle sole operazioni di tessellation (compresi hull e domain shader) che non sottraggono risorse ad altri tipi di elaborazione ma sono, comunque, circuiti che, quando non si fa tessellation restano inutilizzati. Dall'altra si ha un approccio che dedica solo una parte di spazio alle operazioni di tessellation preferendo utilizzare pr la parte rpogrammabile unità che pososno emulare quelle restanti. Questo secondo approccio prevede, tra l'altro, un continuo flusso di dati tra polymorph engine e cluster di fpu, in quanto, nell'ordine, hai vertex fetch (lo fa il primo) hull shading (il secondo) tessellation (il primo) domain shading (il secondo) triangle setup (il primo). Quindi sarà da vedere anche come hanno dimensionato il bus tra i due blocchi funzionali.
Insomma, è troppo presto per dire quale approccio sarà migliore e non è detto che non se ne esca con un "no contest".

[Defragg]

Originariamente inviato da Defragg

Secondo i dati forniti da NVIDIA, le prestazioni geometriche che le nuove schede video GeForce GF100 sono in grado di garantire rispetto a quelle di GeForce GTX 285 sono circa di 8 volte superiori: è un incremento di fondamentale importanza, estremamente significativo se pensiamo che nel passaggio da NV30 a GT200 la potenza di elaborazione in termini di shader è aumentata di 150 volte, mentre quella poligonale solo di 3 volte.

Quindi da NV30 a GF100 la potenza di elaborazione poligonale è aumentata di 24 volte? Se non sbaglio a calcolare
Mentre da R580 a RV870?

Up

[Pihippo]

Originariamente inviato da yossarian

se intendi migliorare il trasferimento verso la vram, di fatto già avviene; i dati sono traferiti in batch da migliaia di vertici, ad esempio; lo stesso si fa per le texture. Anche nelle operazioni di load da parte della gpu avviene la stessa cosa; ci sono istruzioni come texture array a cube map array che prevedono il trasferimento di un'intera matrice di texture 2D o di cube map con un'unica istruzione. Insomma, si sta tentando di risolvere sia il problema del traferimento dati dalla cpu alla vram sia quello dalla vram alla gpu.

Ciao
Grazie per la risposta, chiaro come sempre.

A quando prevedi che usciranno gpu che si auto-feddano, cioè si vanno a caricare direttamente loro stesse vertici e geometrie varie nella ram e se li portano nella vram in modo che la cpu si giri vistosamente i pollici?
Grazie ancora comunque

[mapoetti]

Originariamente inviato da Nemesis Elite

l'unico programma a leggere correttamente lo shader clock è il FIRESTORM DI ZOTAC (funziona anche con altre marche a patto ti tener premuto il tasto shift quando lo si avvia)....ma comunque non si puo' overcloccare al momento.In attesa di un fix.

io comunque non capisco come si fà a fare lavori del genere....resto senza parole....i beta vanno benissimo e adesso questi

fine ot scusate ma ....

[yossarian]

Originariamente inviato da Pihippo

Ciao
Grazie per la risposta, chiaro come sempre.

A quando prevedi che usciranno gpu che si auto-feddano, cioè si vanno a caricare direttamente loro stesse vertici e geometrie varie nella ram e se li portano nella vram in modo che la cpu si giri vistosamente i pollici?
Grazie ancora comunque

i chip ATi da RV770 hanno già la possibilità teorica di accedere direttamente alla vram ed anche alla ram di sistema per operazioni di load e store (da R5x0 solo per quelle di store) ma la cosa è altamente sconsigliata a causa delle latenze elevate introdotte da questo tipo di operazione. Parliamo di accesso diretto ai dati senza passaggio intermedio attraverso i registri.
In futuro non è da escludere che questa funzionalità sia migliorata e potenziata ma, la momento, il paradigma di programmazione delle gpu resta quello tradizionale con le alu che lavorano tramite registri e la gpu che carica i dati dalla vram su registri e cache interne