[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[appleroof]

Fud, ma sembra marketing ufficiale:

“We redesigned GF100 from the ground up to deliver the best performance on DX11. This meant adding dedicated h/w engines in our GPU to accelerate key features like tessellation.

We also made changes on the compute side that specifically benefit gamers like interactive ray-tracing and faster physics performance through things like support for concurrent kernels.

Unfortunately all of these changes took longer than we originally anticipated and that’s why we are delayed.

Do we wish we had GF100 today? Yes. However based on all the changes we made will GF100 be the best gaming GPU ever built. Absolutely.”

http://www.fudzilla.com/content/view/18016/1/

aggiungo solo che è palese che non sono questi i motivi del ritardo

[yossarian]

Originariamente inviato da skizzo99999999

L’esempio dell’antialiasing sarebbe corretto se stessimo valutando l’implementazione via shader del tessellatore e non di hull e domain. MSAA via shader è molto più penalizzante che non domain e hull, perché queste sempre unità programmabili sono.

il resolve consiste in una semplice interpolazione lineare, analoga a quella che le alu fanno per le operazioni di filtraggio delle texture; eppure il calo prestazionale è notevole

Originariamente inviato da skizzo99999999

Sul fatto che i domain possano anche occupare una notevole quantità di risorse non lo metto in dubbio: sono programmabili, e quindi il programmatore può piazzarci un programma arbitrariamente (nei limiti delle scpecifiche) complesso. Ma andare oltre un certo limite non ha senso.
Faccio un esempio che anche se non è molto corretto rende l’idea in modo facilmente comprensibile a tutti.
Io posso tessellare un rettangolo e farne una bandiera che sventola, oppure partire da un parallelepipedo per tirare fuori una ferrari. Il primo esempio è sensato, mentre il secondo no. Utilizzerei molto meglio le risorse (è impiegherei meno tempo) se partissi già da una geometria un poco più somigliante a quello che voglio ottenere (aggiungendo al modello di partenza una manciata di poligoni), per rendere il lavoro più snello negli stadi successivi. Questo non vuol dire fare una tessellazione della geometria più leggera o più pesante, ma diciamo più “intelligente”, che comunque è quello che si fa normalmente (o almeno io ho visto sempre fare così).
Ovvio che se prendesse piede un modo di tessellare brutale tipo parallelepipedo->macchina, allora la tipologia hull-domain via sp potrebbe soffrire. Dico potrebbe perché comunque non possiamo (ancora) quantificare la penalità (secondo me comunque bassa) che intercorre nel portare hull e domain negli sp rispetto ai benefici che si ottengono in tutte le altre fasi di shading.
Sul fatto del rallentamento dell’esecuzione e quindi della sottrazione delle risorse mi sembra di aver già detto e spiegato come la penso e quindi mi ripeterei e basta.
Per carità non voglio convincere a forza nessuno, era solo per portare un punto di vista differente, che si può condividere o meno. Ovvio che, siccome sono io che esprimo la mia opinione, la ritengo valida

i domain shader presentano un piccolo problema: sono quelli che, di fatto, costruiscono la nuova mesh tessellata e si occupano anche del displacement mapping. Il che significa che devono fare accesso a texture e le latenze schizzano alle stelle, indipendentemente da quello che il programmatore decide di scrivere.
Infine, un'ultima cosa sul test unigine; oltre alla scarsa attendibilità dovuta all'utilizzo di 2 versioni differennti di cui quella usata da nVidia con molto meno overdraw dovuto alla più efficiente gestione delle operazioni di culling, la 5870 ha anche un problema, in quello specifico test, nella gestione degli accessi alla LDS (local data share) durante le operazioni di tessellation in particolare che provoca delle latenze anomale che causano un decadimento prestazionale stimabile tra il 10 ed il 15%. Questo problema è risolvibile via driver ma, mettendo a sistema le due cose (non corretta gestione della LDS e differenti versioni del bench), si può concludere che unigine sia un test tutt'altro che attendibile anche ai fini della valutazione delle performance con la tessellation. Resta solo un bel demo di un posto in cui mi piacerebbe vivere

[marco XP2400+]

con questa parte

Originariamente inviato da yossarian

nVidia ha usato una versione differente, la 1.1, che permette un incremento prestazionale del 30% in quanto riduce l'overdraw dovuto alle superfici nascoste grazie ad un uso più aggressivo delle operazioni di culling. Questo incremento, su un'architettura come quella di fermi che si giova in misuta maggiore, della riduzione di tale overdraw perchè scarica gran parte del lavoro delle unità di shading e ha più risorse da dedicate alla tessellation, può avere anche valori superiori al 30%

ed anche quest'altra parte

Originariamente inviato da yossarian

Infine, un'ultima cosa sul test unigine; oltre alla scarsa attendibilità dovuta all'utilizzo di 2 versioni differennti di cui quella usata da nVidia con molto meno overdraw dovuto alla più efficiente gestione delle operazioni di culling, la 5870 ha anche un problema, in quello specifico test, nella gestione degli accessi alla LDS (local data share) durante le operazioni di tessellation in particolare che provoca delle latenze anomale che causano un decadimento prestazionale stimabile tra il 10 ed il 15%. Questo problema è risolvibile via driver ma, mettendo a sistema le due cose (non corretta gestione della LDS e differenti versioni del bench), si può concludere che unigine sia un test tutt'altro che attendibile anche ai fini della valutazione delle performance con la tessellation. Resta solo un bel demo di un posto in cui mi piacerebbe vivere

penso che sei riuscito a rendere l'idea che sia un test, per l'attuale confronto prestazionale tra le due schede, molto meno attendibile di quanto ci si potesse aspettare!! grazie degli interventi sul forum e dell'articolo...

[Andrea deluxe]

so che non ha alcun valore....



gtx 470

[Andrea deluxe]

http://www.youtube.com/watch?v=VpZXhR1ibj8

[aledemo]

Originariamente inviato da Andrea deluxe

so che non ha alcun valore....



gtx 470

continuano a puntare sulla quantita di memoria in piu x risoluzione e aa..

Originariamente inviato da Greifi Grishnackh

è confermata questa notizia??? perchè se cosi fosse sarebbe una bella notizia....almeno non c'è da aspettare il respin 475-485 per avere una scheda al 100% senza problemi

Io ormai ho rimandato la spesa delle vga per giugno quindi ben venga se mi ritroverò tra le mani quanto afferma la notizia.

[Marscorpion]

Originariamente inviato da Nemesis Elite

Io ormai ho rimandato la spesa delle vga per giugno quindi ben venga se mi ritroverò tra le mani quanto afferma la notizia.

Ci credo soltanto se a Giugno vedo ancora in firma le GTX295 !

Originariamente inviato da Marscorpion

Ci credo soltanto se a Giugno vedo ancora in firma le GTX295 !

[zorco]

Originariamente inviato da Nemesis Elite

Io ormai ho rimandato la spesa delle vga per giugno quindi ben venga se mi ritroverò tra le mani quanto afferma la notizia.

[zorco]

Molti si chiedono quale sia la causa del prolungato ritardo di una delle GPU più attese del mercato. Stiamo parlando delle NVIDIA GeForce GTX 480 e 470, basate sulla GPU GF100, conosciuta anche con il nome NVIDIA Fermi.

NVIDIA ha dato una prima risposta a questi ritardi:

“We redesigned GF100 from the ground up to deliver the best performance on DX11. This meant adding dedicated h/w engines in our GPU to accelerate key features like tessellation.

We also made changes on the compute side that specifically benefit gamers like interactive ray-tracing and faster physics performance through things like support for concurrent kernels.

Unfortunately all of these changes took longer than we originally anticipated and that’s why we are delayed.

Do we wish we had GF100 today? Yes. However based on all the changes we made will GF100 be the best gaming GPU ever built. Absolutely.”

Dalle dichiarazioni emerge che NVIDIA sta lavorando duro per avere una scheda che offra le migliori prestazioni in ambiti come la tessellation, il calcolo del ray-tracing e della fisica e a loro detta sarà la migliore GPU per il gaming mai costruita.

Per il momento però tutti gli appassionati vedono solo molte parole ed i ritardi allungarsi di volta in volta, per una storia che ci ricorda molto quanto successo ad ATI con il lancio di R600 (ATI 2900XT). Non ci resta che attendere il lancio ufficiale per scoprire se sono solo parole o se Fermi è veramente la "migliore GPU mai costruita".

http://www.hwstation.net/news/schede_video-4/3033.html

[goten]

Originariamente inviato da halduemilauno

spiegami dovrebbe andare di + di una scheda che costa di +???? per carità magari vado di + e spendo di -.

Costa di piu' cosa? Si parlava del fatto che la 470 potesse costare 350€ andando leggermente peggio della 5870. La 5870 ora la si trova a 350€ tranquillamente. Spiegami tu dove sarebbe il vantaggio di andarsi a comprare una scheda che a parità di prezzo con la concorrenza va meno
Senza considerare prevedibili ribassi della Ati sulle sue schede.

Originariamente inviato da Marscorpion

Se la mettono a quel prezzo e per fare concorrenza alla 5870, perciò andrà + o - uguale. Stai tranquillo che se andrà anche solo 2 fps in più della 5870 la vendono a 400 euro.

Lo spero per Nvidia che vada piu' forte della 5870, altrimenti, ripeto, non ha nessun senso.

Alla fine, tolti i fanboy, tutti cerchiamo di comprare la roba piu' performante al prezzo migliore. Se mi metti due schede che vanno praticamente uguale e una costa meno dell'altra è pacifico che l'utenza si orienterà su quella piu' economica. Senza stare neanche a voler considerare i consumi.

[Marscorpion]

Originariamente inviato da goten

Alla fine, tolti i fanboy, tutti cerchiamo di comprare la roba piu' performante al prezzo migliore. Se mi metti due schede che vanno praticamente uguale e una costa meno dell'altra è pacifico che l'utenza si orienterà su quella piu' economica. Senza stare neanche a voler considerare i consumi.

Penso sia la cosa più logica da fare.......

[Horizont]

Originariamente inviato da Andrea deluxe

http://www.youtube.com/watch?v=VpZXhR1ibj8

AHAHAHHAHAHA ormai sto video lo stanno usando per tutti i tipi di lamentele verso un prodotto/persona ahahah

[Pike79]

http://forum.beyond3d.com/showpost.p...postcount=3181

[ghiltanas]

Originariamente inviato da persa

così il 470, come velocita della ram andrebbe a 4000mhz invece di 3200?
mah vedremo

è decisamente strana l'indicazione delle frequenza delle ram...perchè 2000 e 4000 fra parentesi?
in caso di gddr5 dovrebbero scrivere 1000 ( a 4000 effettivi quindi)

[ghiltanas]

Originariamente inviato da halduemilauno

continuano a far vedere unicamente gtx470...di 480 probabilmente ne avranno prodotte 10 se va bene

[B|4KWH|T3]

Originariamente inviato da skizzo99999999

mi hai chiesto tu di immaginare:

"se immagini un'elaborazione di tipo seriale (...) allora toriniamo al concetto di pipeline classica e si perde gran parte del vantaggio degli shader unificati"

e visto che non ne ero convinto, ho immaginato lo scenario prospettatomi e mostrato che in quel caso gli shader unificati sarebbero stati ancora più avvantaggiati e non più penalizzati. tutto qui. Poi se sono stato io ad aver capito male pazienza.



L’esempio dell’antialiasing sarebbe corretto se stessimo valutando l’implementazione via shader del tessellatore e non di hull e domain. MSAA via shader è molto più penalizzante che non domain e hull, perché queste sempre unità programmabili sono.
Sul fatto che i domain possano anche occupare una notevole quantità di risorse non lo metto in dubbio: sono programmabili, e quindi il programmatore può piazzarci un programma arbitrariamente (nei limiti delle scpecifiche) complesso. Ma andare oltre un certo limite non ha senso.
Faccio un esempio che anche se non è molto corretto rende l’idea in modo facilmente comprensibile a tutti.
Io posso tessellare un rettangolo e farne una bandiera che sventola, oppure partire da un parallelepipedo per tirare fuori una ferrari. Il primo esempio è sensato, mentre il secondo no. Utilizzerei molto meglio le risorse (è impiegherei meno tempo) se partissi già da una geometria un poco più somigliante a quello che voglio ottenere (aggiungendo al modello di partenza una manciata di poligoni), per rendere il lavoro più snello negli stadi successivi. Questo non vuol dire fare una tessellazione della geometria più leggera o più pesante, ma diciamo più “intelligente”, che comunque è quello che si fa normalmente (o almeno io ho visto sempre fare così).
Ovvio che se prendesse piede un modo di tessellare brutale tipo parallelepipedo->macchina, allora la tipologia hull-domain via sp potrebbe soffrire. Dico potrebbe perché comunque non possiamo (ancora) quantificare la penalità (secondo me comunque bassa) che intercorre nel portare hull e domain negli sp rispetto ai benefici che si ottengono in tutte le altre fasi di shading.
Sul fatto del rallentamento dell’esecuzione e quindi della sottrazione delle risorse mi sembra di aver già detto e spiegato come la penso e quindi mi ripeterei e basta.
Per carità non voglio convincere a forza nessuno, era solo per portare un punto di vista differente, che si può condividere o meno. Ovvio che, siccome sono io che esprimo la mia opinione, la ritengo valida

Scusami, se ho capito bene il tuo ragionamento si basa su questo assunto:

Separiamo il tempo T di generazione del frame in N+M, con N tempo di shading ed M tempo di tessellation (considerando per semplicità tutte le altre fasi non significative in termini di tempo).
Poichè N>>M, allora l'impatto della latenza maggiore dello svolgimento della tessellation con ALU generiche anziché che con funzioni fisse sul tempo T diventa trascurabile.

Io però ti rovescio il ragionamento: poichè per fare la fase M sottraggo risorse alla fase N che è >>M, allora è proprio l'approccio ATI ad avvantaggiarsi poichè dedica sempre lo stesso numero di risorse alla fase che occupa il maggior tempo nella generazione del frame. Al contrario l'approccio nVidia sottrae risorse proprio alla fase N.

Tu mi rispondi: sì, ma questo è compensato dal fatto che nella fase N ho più risorse a parità di DIE poichè al posto delle funzioni fisse ho messo unità che possono svolgere shading (fase N) oltre a tessellation (fase M)


Quindi l'invito che faccio è: dovete spostare il ragionamento su come viene bilanciato il lavoro e fare qualche conticino. Per lo meno con la serie ATI 5*** e poi fare una stima su GTX4**
La chiave dovrebbe essere lì.


EDIT: Aggiungo per specificare meglio: la chiave dovrebbe essere l'efficienza nello shading fra sp di ATI e sp di nVidia

[appleroof]

Originariamente inviato da B|4KWH|T3

Scusami, se ho capito bene il tuo ragionamento si basa su questo assunto:

Separiamo il tempo T di generazione del frame in N+M, con N tempo di shading ed M tempo di tessellation (considerando per semplicità tutte le altre fasi non significative in termini di tempo).
Poichè N>>M, allora l'impatto della latenza maggiore dello svolgimento della tessellation con ALU generiche anziché che con funzioni fisse sul tempo T diventa trascurabile.

Io però ti rovescio il ragionamento: poichè per fare la fase M sottraggo risorse alla fase N che è >>M, allora è proprio l'approccio ATI ad avvantaggiarsi poichè dedica sempre lo stesso numero di risorse alla fase che occupa il maggior tempo nella generazione del frame. Al contrario l'approccio nVidia sottrae risorse proprio alla fase N.

Tu mi rispondi: sì, ma questo è compensato dal fatto che nella fase N ho più risorse a parità di DIE poichè al posto delle funzioni fisse ho messo unità che possono svolgere shading (fase N) oltre a tessellation (fase M)


Quindi l'invito che faccio è: dovete spostare il ragionamento su come viene bilanciato il lavoro e fare qualche conticino. Per lo meno con la serie ATI 5*** e poi fare una stima su GTX4**
La chiave dovrebbe essere lì.


EDIT: Aggiungo per specificare meglio: la chiave dovrebbe essere l'efficienza nello shading fra sp di ATI e sp di nVidia

considerando che l'architettura Nvidia è più efficiente (tra l'altro se non sbaglio gli sp possono fare un'operazione per ciclo di clock, ma per questo il clock dell'architettura Nvidia è maggiore che quello dell'Ati) mi pare che tu abbia colto il punto;

cmq credo di essere facile profeta se dico che tutto dipenderà da come i giochi verranno sviluppati, e che come al solito nessuna delle due soluzioni prevarrà sull'altra in maniera netta

sarà piuttosto curioso vedere come Ati implementerà la tasselletion su NI, che in quanto architettura totalmente nuova da quella attuale derivata da R600, potrebbe avere novità anche da questo punto di vista (a differenza di Nvidia che per qualche tempo si affiderà all'architettura vista in Fermi...almeno pare)

[Bramino]

Originariamente inviato da ghiltanas

è decisamente strana l'indicazione delle frequenza delle ram...perchè 2000 e 4000 fra parentesi?
in caso di gddr5 dovrebbero scrivere 1000 ( a 4000 effettivi quindi)

Per confondere meglio la clientela.