[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[PConly92]

una notizia interessante
http://www.tomshw.it/cont/news/physx...a/24364/1.html

[Bramino]

Originariamente inviato da PConly92

una notizia interessante
http://www.tomshw.it/cont/news/physx...a/24364/1.html

Qualcuno ha avuto il coraggio di scrivere quello che già si sapeva da anni.

[Horizont]

Originariamente inviato da ghiltanas

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

sbaglio o leggo MINUMUM 550W PSU???

[ghiltanas]

Originariamente inviato da Horizont

sbaglio o leggo MINUMUM 550W PSU???

di quello nn c'è da stupirsi, basti pensare che per la 5850 minimum 500w...è un dato che di per se nn dice molto, bisogna vedere quanti ampere sulla 12v chiederà effettivamente

[viper-the-best]

Originariamente inviato da Horizont

sbaglio o leggo MINUMUM 550W PSU???

devono stare larghi, solitamente chi ha queste schede di fascia alta ha anche altri processori e componenti di fascia alta (vedi es. i7 che consuma abbastanza) ma imho se si ha un penryn o un i5, un buon 480w ce la fa senza problemi

[egounix]

Originariamente inviato da Horizont

sbaglio o leggo MINUMUM 550W PSU???

anche nella 275gtx c'è scritto
comunque dipende sempre dalla qualità dell'ali, ma come già detto chi compra queste schede ha alimentatori di qualità, perchè ha già un sistema di fascia alta

può succedere, e c'è un post aperto, che qualcuno compri o riceva una vga di fascia alta o medio-alta e abbia un alimentatore non adeguato anche se questi sia di 500-550w o superiore ai w consigliati

dovrebbero essere più chiari e scrivere la qualità della linea cui necessitano queste schede
se lo facessero, però, rischierebbero di non non vendere a chi magari fa gola una scheda simile, ma che non ha, perchè non conosca, un sistema adeguato

[skizzo99999999]

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

Non è la differenza di efficienza tra gli sp dei due rivali a stabilire quale sia l'approccio migliore. Il confronto si dovrebbe fare tra due schede identiche, una con hull e domain tramite unità dedicate ma con meno sp (un Fermi virtuale) e l'altra con il Fermi attuale. Inoltre bisognerebbe considerare che se ci fossero unità dedicate a hull e domain probabilmente in fermi non si sarebbe optato per l'enorme complicazione portata dalla frammentazione con potenziamento del polymorph engine per "avvicinare" il tessellatore allo shader core, in modo da diminuire le risorse necessarie al travaso di dati fra gli elementi. Questo avrebbe portato sicuramente ad una diminuzione dell'area occupata da queste unità, capace magari di alzare il numero di sp e probabilmente di avvicinarne il numero di quelli presenti nella configurazione attuale.
Quindi fare calcoli precisi è praticamente impossibile, anche investendoci una quantità elevata di tempo. Quello che voglio sottolineare è comunque che non si sottrae niente, perchè gli sp generici che uso per hull e domain non ci sarebbero potuti essere se si fosse optato per unità dedicate.
se non li hai letti e hai pazienza leggiti questi due post precedenti, in cui ho messo dei numeri fittizzi per rendere meglio l'idea (soprattutto nel secondo)

http://www.hwupgrade.it/forum/showpo...ostcount=23307
http://www.hwupgrade.it/forum/showpo...ostcount=23328

Tutto sta a vedere quanto si perde in efficienza a far fare le operazioni di hull e domain a sp generici. Visto i precedenti tra pixel+vertex uniti in unità generiche (e nessuno è tornato indietro) mi sento di ipotizzare che l'approccio unificato dovrebbe essere quello migliore, ma ovviamente non è detto. Certo che se NVIDIA ha deciso di sbattersi in quel modo con il polymorph engine penso che due conti li abbia fatti. Poi può averli sbagliati non ponderando adeguatamente tutte le variabili in gioco. Chi mastica l'inglese può guardare quello scritto dal buon derek (abbastanza semplificato da essere facilmente comprensibile):
http://www.anandtech.com/video/showdoc.aspx?i=3507&p=1
e vedere il "dramma" progettuale del polymorph engine frammentato. Certo, si potrebbe dire che anche ATI avrà fatto le sue valutazioni (avendo già una architettura senza hull e domain) per scegliere diversamente. Ma è possibile che abbia valutato troppo complesso (+tempo di progettazione) fare una scelta simile al polymorph engine oppure che visto il sistema simil VLIW delle sue sp il tutto era troppo penalizzante, mentre nel sistema NVIDIA la penalità è risultata minore in misura tale da rendere redditizio quel sistema. Anche se per ATI avesse prevalso solo il fattore della semplicità progettuale, visto la situazione attuale con milioni di schede già vendute e NVIDIA con il cerino in mano chi può dirgli niente?

Bisogna considerare anche che con l'uso sempre più generalizzato di motori deferred la fase geometrica è non dico trascurabile, ma è molto meno importante in termini di risorse/tempo impiegato rispetto a tutto il resto della pipeline di rendering. Gli algoritmi di illuminazione e post processing sempre più realistici agiscono ormai sempre a livello di fragment e non di vertex, per cui è richiesta una enorme potenza di fragment shader. Per cui anche se perdessi in efficienza durante la tessaellazione per un fattore moderatamente elevato (non dico tempi più elevati, perchè con l'approccio unificato il tempo dipende soltanto da quanti sp gli dedico, è l'efficienza dell'uso degli stessi che diminuisce rispetto ad averli dedicati), avere risorse maggiori anche solo del 5-10% per il fragment shading potrebbe portare a diminuire il tempo totale di generazione del frame.

[Greifi Grishnackh]

Originariamente inviato da Pike79

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

ottimo....quindi venerdi si vedrà qualcosa

[Greifi Grishnackh]

Originariamente inviato da Ratatosk

**fixed**

....beh il "forse" e il "presumibilmente" è d'obbligo sempre

[luX0r.reload]

Originariamente inviato da Ratatosk

L'hai detto tu che i rumors parlano di prestazioni sconvolgenti del tessellator, non io. Non c'è alcun rumor al riguardo, solo notizie ufficiali (sì, ufficiali) non replicabili in un sistema di test e il rumor sul 5%. Il rumor che dici te lo sei inventato.

Fino ad una settimana fa di ufficiale non c'era niente... il thread al 90% è composto da rumors e tu ora mi dici che non c'è nessun rumors a riguardo

... hai ragione... "then you win"!

[eXeS]

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

E che aspetta AMD a risolverlo, visto che Unigine è stato preso da chiunque in modo proprio o improprio come il bench definitivo, per valutare le prestazioni delle schede DX11 con tessellation attiva.

Originariamente inviato da yossarian

, 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

Quindi, quando AMD avrà sistemato lato driver gli accessi alla LDS, e la 1.1 sarà pubblica i risultati saranno più indicativi, o Unigine continuerà ad essere ancora un bench favorevole a Fermi ?

Ma poi, favorevole perchè ?

Ci sono forse dati che dicono che l'operazione di tessellation, e non gli effetti collaterali derivanti dall'aumento della complessità delle geometrie, è l'operazione che nel tempo complessivo necessario alla rasterizzazione del singolo frame, ha maggior peso ?

Oppure qualcuno ha fatto un profiling dell'uso delle alu su Fermi, ed ha rilevato che in Unigine le alu sono impegnate soprattutto a tessellare ?

[yossarian]

Originariamente inviato da eXeS

E che aspetta AMD a risolverlo, visto che Unigine è stato preso da chiunque in modo proprio o improprio come il bench definitivo, per valutare le prestazioni delle schede DX11 con tessellation attiva.

un bench definitivo basato su versioni differenti? I risultati del 3dmark2001 e quelli del 3dmark2003 sono comparabili? La versione 1.0 ha chiari problemi di overdraw, per ammissione degli stessi sviluppatori di unigine.

Originariamente inviato da eXeS

Quindi, quando AMD avrà sistemato lato driver gli accessi alla LDS, e la 1.1 sarà pubblica i risultati saranno più indicativi, o Unigine continuerà ad essere ancora un bench favorevole a Fermi ?

Ma poi, favorevole perchè ?

dove ho scritto che è un bench favorevole a fermi?

Originariamente inviato da eXeS

Ci sono forse dati che dicono che l'operazione di tessellation, e non gli effetti collaterali derivanti dall'aumento della complessità delle geometrie, è l'operazione che nel tempo complessivo necessario alla rasterizzazione del singolo frame, ha maggior peso ?

ci sono dati che dicono che lo stesso test ripetuto a diverse risoluzioni dà, qualitativamente, gli stessi risultati; il che significa che il calo di prestazioni se è imputabile all'aumento della complessità poligonale in seguito alla tessellation lo è solo in minima parte.

Originariamente inviato da eXeS

Oppure qualcuno ha fatto un profiling dell'uso delle alu su Fermi, ed ha rilevato che in Unigine le alu sono impegnate soprattutto a tessellare ?

se fossero impegnate solo a tessellare le prestazioni di fermi sarebbero ben misere. Tanto varrebbe fare un test in wireframe

[Rsdj]

Ancora a perdere tempo con l'Unigine?

E' vero è molto bello ma come già detto e ridetto la tessellation non sarà mai applicata in quel modo nei giochi, ovvero negli oggetti in lontanza dove non serve... si andrebbe contro il principio stesso della tessellation, che non è nata per essere applicata ovunque, ma solamente dove è tangibile la differenza cercando di limitare l'utilizzo di risorse.

[persa]

[persa]

ancora con sto catalytic

[persa]

infatti.. anche a me interessano di + i test @ 1920x1200.

[persa]

Originariamente inviato da Ratatosk

Probabilmente questi recensori sono un po' catatonic

[Rsdj]

Infatti hanno rotto co sti Catalityc

Originariamente inviato da Ratatosk

Si vedono solo leak (veri o falsi che siano) in cui Cypress è bandwidth limited... sarà molto interessante vedere i test in semplice FullHD...

Come già dicevo da gennaio, si vedranno finalmente le recensioni con AA8x, da tutte quelle redazioni che seguiranno pedissequamente la review guide di nVIDIA.

Non vedo l'ora di leggere la review di Anand

Vedo che per la NVIDIA sono stati usati i 196.78 ,ovvero i driver successivi al famoso bug driver (196.75)che ha fatto fuori diverse vga tra gli utenti.

Originariamente inviato da Ratatosk

Probabilmente non sarà comunque la versione di lancio... vedremo...

Si ne sono quasi certo anche io che non saranno quelli...magari al lancio vedremo un bel pacchetto driver siglato 200 giusto per marcare l'entrata di Fermi...