[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[okorop]

Originariamente inviato da persa

e non sarebbe male

contenti voi contenti tutti, sta di fatto che la fascia media nvida non è cambiata da 2 anni a questa parte........
per quanto riguarda la 360 be di 360 per ora c'è ne solo una ed è microsoft

per quanto riguarda il compilatore di fermi volevo dire che non è che lavori cosi bene visto che ci sono artefatti notevoli, ed è proprio sto problema che ha stoppato la produzione e commercializzazione della gtx380

[persa]

Originariamente inviato da okorop

contenti voi contenti tutti, sta di fatto che la fascia media nvida non è cambiata da 2 anni a questa parte........
per quanto riguarda la 360 be di 360 per ora c'è ne solo una ed è microsoft

per quanto riguarda il compilatore di fermi volevo dire che non è che lavori cosi bene visto che ci sono artefatti notevoli, ed è proprio sto problema che ha stoppato la produzione e commercializzazione della gtx380

x la fascia media l'ho scritto pagine fa xchè non l'ha cambiata per lungo tempo.

xchè non c'era bisogno e non gli conveniva neanche. xchè penso che fare un 9600 o un gts250 con architettura gt200, non avrebbe portato nessun miglioramento rispetto al g92. ne come prestazioni e ne come innovazione (sempre dx10)

[Iantikas]

cavolo ma veramente?...


...in effetti era da un pò ke nn l'incontravo ma col fatto ke oramai frequento il forum a periodi, quando spesso quando raramente, nn c'avevo fatto caso...


...di certo il forum senza di lui è un posto + tetro e lugubre

[persa]

cavolo allora avrei voluto conoscerlo

[yossarian]

Originariamente inviato da devAngnew

Innanzitutto io non parlavo di compilare a volo tutti gli shader del gioco intero ma solo del livello eseguito.

innanzitutto fino a poco fa avevi affermato che le sostituzioni avvenivano tutte insieme, senza perdita di prestazioni, prima dell'inizio del gioco; poi, compilare a volo oppure no? Mi sembra che affermavi il contrario. Poi, ammesso che sia come dici ora, quando e dove viene compilato tutto il resto?

Originariamente inviato da devAngnew

Bhe mi sembra alquanto strano che il compilatore sia cosi limitato visto il passaggio da linguaggio HL ad ASM ciò comporta l'uso di una certa quantità di memoria anche perchè tale passaggio non è 1:1 ma avvengono prima dei passaggi intermedi.

e quindi? Intanto un processore non lavora con l'assembly ma con il linguaggio macchina. Poi, cosa comporta a livello di occupazione di memoria il ricorso a passaggi intermedi?

Originariamente inviato da devAngnew

A meno che il compilatore non usi la RAM di sistema e non VRAM come deposito delle istruzioni compilate.

cioè il compilatore accede direttamente alla ram di sistema per tradurre le istruzioni, riordinarle e fare le sostituzioni di cui blateri da ore? Interessante teoria non suffragata dai fatti . Mi fai l'elenco delle gerarchie di accesso alla memoria in una gpu?
Cos'è, stai tentando un'arrampicata sugli specchi o spari frasi a caso dopo che ti sei letto qualcosa su wikipedia, sperando di azzeccarne una giusta?

Originariamente inviato da devAngnew

A questo punto dovresti fornire delle fonti che riportino tali limitazioni.

comincia tu a fornire le tue. Sono ore che te lo sto chiedendo. E cerca di rispondere a delle semplici domande con altrettanto lineari risposte.
Altrimenti ritengo sia inutile continuare questa sterile discussione con qualcuno che non sa neppure di cosa sta parlando

[Wikkle]

ehhhh... il buon vecchio Tarpone
Come lo capisco

[devAngnew]

Originariamente inviato da yossarian

innanzitutto fino a poco fa avevi affermato che le sostituzioni avvenivano tutte insieme, senza perdita di prestazioni, prima dell'inizio del gioco; poi, compilare a volo oppure no? Mi sembra che affermavi il contrario. Poi, ammesso che sia come dici ora, quando e dove viene compilato tutto il resto?

Bha ma parlo Arabo Io ho detto fin dall'inizio che gli shader di un livello di gioco viene caricato (HL) e compilato e ottimizzato (quindi il compile vedendo che lavora su Fermi sostituisce le MADD con FMA) una volta e basta
dopotutto tutti i compilatori lavorano cosi.

e quindi? Intanto un processore non lavora con l'assembly ma con il linguaggio macchina. Poi, cosa comporta a livello di occupazione di memoria il ricorso a passaggi intermedi?

Mai i mie posti li leggi o vuoi fare solo il saccente... mi sembra che ho fatto una premessa te la riporto forse non ricordi [b]il compilatore ad alto livello (HL) traduce il codice in linguaggio macchina (da ora ASM)[b] non ho detto in assembler vuol dire che da ora lo chiamero LM contento .
Apparte il fatto che tra linguaggio macchina e assembler c'è un rapporto 1:1
credo che tu conosca la situazione ma il punto è che io ho fatto una premessa che tu vuoi negare.
Tonando ai passaggi intermedi di un compilatore, mi chiedo ma la tokenizzazzione del sorgente ti risulta o no ? O pensi che i token si memorizzino da soli

cioè il compilatore accede direttamente alla ram di sistema per tradurre le istruzioni, riordinarle e fare le sostituzioni di cui blateri da ore? Interessante teoria non suffragata dai fatti . Mi fai l'elenco delle gerarchie di accesso alla memoria in una gpu?
Cos'è, stai tentando un'arrampicata sugli specchi o spari frasi a caso dopo che ti sei letto qualcosa su wikipedia, sperando di azzeccarne una giusta?
comincia tu a fornire le tue.

Gli specchi mi sà che li stai usando tu, io ti ho fornito la mia teoria come dici, visto che sei cosi sicuro di come lavora il compilatore delle gpu NVIDIA e ATI forniscimi dei link ufficiali sul loro funzionamamento cosi ti prendi la ragione che vuoi e finisce qui e amici come prima. Non credo di chiedere troppo.
O devo credere che le tue risposte siano dovute ad un ragionamento logico e basta.

Sono ore che te lo sto chiedendo. E cerca di rispondere a delle semplici domande con altrettanto lineari risposte.
Altrimenti ritengo sia inutile continuare questa sterile discussione con qualcuno che non sa neppure di cosa sta parlando

Il ragionamento è più che lineare visto che ho ricordato da altrettante ore a grandi linee cosa fa un compilatore.
Ma tu continui a dire che non rispondo.
Se ritieni sterile la discussione fai come vuoi e inserisci pure nella ignore list.
BUona Notte.

P.s: A domani se vuoi.

[Iantikas]

Originariamente inviato da devAngnew

Bha ma parlo Arabo Io ho detto fin dall'inizio che gli shader di un livello di gioco viene caricato (HL) e compilato e ottimizzato (quindi il compile vedendo che lavora su Fermi sostituisce le MADD con FMA) una volta e basta
dopotutto tutti i compilatori lavorano cosi.




Mai i mie posti li leggi o vuoi fare solo il saccente... mi sembra che ho fatto una premessa te la riporto forse non ricordi [b]il compilatore ad alto livello (HL) traduce il codice in linguaggio macchina (da ora ASM)[b] non ho detto in assembler vuol dire che da ora lo chiamero LM contento .
Apparte il fatto che tra linguaggio macchina e assembler c'è un rapporto 1:1
credo che tu conosca la situazione ma il punto è che io ho fatto una premessa che tu vuoi negare.
Tonando ai passaggi intermedi di un compilatore, mi chiedo ma la tokenizzazzione del sorgente ti risulta o no ? O pensi che i token si memorizzino da soli



Gli specchi mi sà che li stai usando tu, io ti ho fornito la mia teoria come dici, visto che sei cosi sicuro di come lavora il compilatore delle gpu NVIDIA e ATI forniscimi dei link ufficiali sul loro funzionamamento cosi ti prendi la ragione che vuoi e finisce qui e amici come prima. Non credo di chiedere troppo.
O devo credere che le tue risposte siano dovute ad un ragionamento logico e basta.



Il ragionamento è più che lineare visto che ho ricordato da altrettante ore a grandi linee cosa fa un compilatore.
Ma tu continui a dire che non rispondo.
Se ritieni sterile la discussione fai come vuoi e inserisci pure nella ignore list.
BUona Notte.

P.s: A domani se vuoi.

nn sono un esperto in materia xò una cosa è certa...hai scritto decine di post con questa presunta tua teoria ma se li riunisci tutti, in tante righe, non hai spiegato niente...


...se riscrivi il tuo pensiero in un unico post senza spezzetarlo quotando gli altri magari ci fai un favore a noi ke stiamo cercando di capirti...ciao

[A.L.M.]

Tanto per alleggerire il thread, posto un tweet ufficiale di NVidia:

Fun fact of the week: The GF100 board pictured in last's week's fun fact is 10.5-inches long -- the same length as GeForce GTX 200 Series graphics cards!

P.S.: la foto cui fanno riferimento è quella famosa dello schermo col benchmark.

Fonte: http://twitter.com/NVIDIAGeForce

[persa]

mmmmmm...., aveva ragione ratatosk quindi, a me invece sembrava più lunga di una gt200!

[yossarian]

Originariamente inviato da devAngnew

Bha ma parlo Arabo Io ho detto fin dall'inizio che gli shader di un livello di gioco viene caricato (HL) e compilato e ottimizzato (quindi il compile vedendo che lavora su Fermi sostituisce le MADD con FMA) una volta e basta
dopotutto tutti i compilatori lavorano cosi.




Mai i mie posti li leggi o vuoi fare solo il saccente... mi sembra che ho fatto una premessa te la riporto forse non ricordi [b]il compilatore ad alto livello (HL) traduce il codice in linguaggio macchina (da ora ASM)[b] non ho detto in assembler vuol dire che da ora lo chiamero LM contento .
Apparte il fatto che tra linguaggio macchina e assembler c'è un rapporto 1:1
credo che tu conosca la situazione ma il punto è che io ho fatto una premessa che tu vuoi negare.
Tonando ai passaggi intermedi di un compilatore, mi chiedo ma la tokenizzazzione del sorgente ti risulta o no ? O pensi che i token si memorizzino da soli



Gli specchi mi sà che li stai usando tu, io ti ho fornito la mia teoria come dici, visto che sei cosi sicuro di come lavora il compilatore delle gpu NVIDIA e ATI forniscimi dei link ufficiali sul loro funzionamamento cosi ti prendi la ragione che vuoi e finisce qui e amici come prima. Non credo di chiedere troppo.
O devo credere che le tue risposte siano dovute ad un ragionamento logico e basta.



Il ragionamento è più che lineare visto che ho ricordato da altrettante ore a grandi linee cosa fa un compilatore.
Ma tu continui a dire che non rispondo.
Se ritieni sterile la discussione fai come vuoi e inserisci pure nella ignore list.
BUona Notte.

P.s: A domani se vuoi.

questo è il tuo primo post sull'argomento

Se ho interpretato bene ciò che volete dire....
Bhe il tutto è fatto all'atto del caricamento dello shader in memoria diciamo durante il caricamento del livello di un ipotetico gioco quindi il driver sostituirebbe le chiamate MADD con delle FMA e poi compilerebbe il tutto ne consegue che Fermi dovrebbe lavorare alla massima velocità possibile.

questo è il tuo secondo

Ovviamente, ci deve essere questo passaggio di replacemente da MADD a FMA ma il tutto avverrà in modalità JIT cioè carico lo shader e sostituisco le istruzioni e successivamente il codice viene compilato quindi questo passaggio avviene una sola volta subito dopo aver caricato lo shader.
Cioè non avviene un interpretazione passo per passo non sò se mi sono spiegato.

poi cìè questo

IMO cambia e come perchè una cosa è interpretare una MADD a runtime come mi sembra di aver capito dalle tue risposte un' altra è fare una compilazione una volta per tutte dello shader (quindi sostituzione MADD con FMA e compilazione finale).

poi questo

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.

questo

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.

questo

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.

questo

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.

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.

questo è significativo

Ma perchè a te risulta che un programma compilato vengo memorizzato tutto nei registri di un processore a me no. Altrimente la memoria a che serve a solo a contenere dati.

Secondo la risposta te la sei data già in parte da solo e se rileggi bene ciò che ho scritto io l'avevo già detto e cioè il compilatore ad alto livello (HL) traduce il codice in linguaggio macchina (da ora ASM) e sostituisce le MAD con FMA. Il fatto è che tu dici che la compilazione avviene mano mano da alto livello ad ASM mentre io sostengo l'opposto cioè una volta per tutte.

A questo punto l'unico vero hit è quello di esecuzione della FMA e basta.
visto che tutto si risolve a compiler time.

Non all'atto del caricamento del 1mo frame ma prima e lo fara il compiler che traduce da HL ad ASM.

Innanzitutto io non parlavo di compilare a volo tutti gli shader del gioco intero ma solo del livello eseguito.
Bhe mi sembra alquanto strano che il compilatore sia cosi limitato visto il passaggio da linguaggio HL ad ASM ciò comporta l'uso di una certa quantità di memoria anche perchè tale passaggio non è 1:1 ma avvengono prima dei passaggi intermedi. A meno che il compilatore non usi la RAM di sistema e non VRAM come deposito delle istruzioni compilate.
A questo punto dovresti fornire delle fonti che riportino tali limitazioni.

In tutti questi post hai continuato a sostenere che la compilazione avviene una volta per tutte, a volte dicendo che avviene prima del caricamento del primo frame, altre volte prima dello shader, altre ancora una tantum (e poi non ci si pensa più ). Ma tralasciamo questi dettagli.
Ti ho chiesto come fa ad agire il compilatore e dove agisce ma non hai risposto (o meglio, hai risposto chiedendo a cosa servono i compilatori se non fanno questo). Ora ti faccio una domanda più semplice: che tipo di architettura ha GT300 o fermi che dir si voglia? La risposta è semplice ed èd è unica: una volta che l'hai trovata, cerca qualche documento on line che ti spieghi come avvengono le operazioni di fetching e decoding delle istruzioni per siffatta architettura. E, soprattutto, se queste avvengono at run time o at compile time.
Poi torni qui e ne riparliamo. E magari parliamo anche di quella ATi

[Kharonte85]

Originariamente inviato da Ratatosk

Come no, devi toglierla e metterci gli stickers

Originariamente inviato da A.L.M.

Fun fact of the week: The GF100 board pictured in last's week's fun fact is 10.5-inches long -- the same length as GeForce GTX 200 Series graphics cards!

Ne sarei molto contento dato che non posso mettere una scheda che sia più di 27cm

[persa]

kharonte che case hai?!? nel mio in firma cmq max 29cm!

[Kharonte85]

Originariamente inviato da persa

kharonte che case hai?!? nel mio in firma cmq max 29cm!

OT/ Cooler Master Centurion 534, ho calcolato che posso incastrarci una scheda da 27cm al massimo

Comunque il fatto che Nvidia rilasci queste informazioni apposta potrebbe significare che non siamo lontani da vedere qualcosa, probabilmente la scheda fotografata è vera.

[A.L.M.]

Originariamente inviato da Kharonte85

OT/ Cooler Master Centurion 534, ho calcolato che posso incastrarci una scheda da 27cm al massimo

Comunque il fatto che Nvidia rilasci queste informazioni apposta potrebbe significare che non siamo lontani da vedere qualcosa, probabilmente la scheda fotografata è vera.

Devono fare qualcosa a breve... Siamo nella christmas season, e se non fanno damage control (leggi qualche mockup qua e là) non appena il livello di fornitura delle ATI sarà sufficiente sarà un disastro commerciale per NVidia (come lo fu per AMD ai tempi di R600).
Continuo invece a credere molto remoto un lancio commerciale entro gennaio. Il lancio a gennaio presupponeva alcuni step che già sono stati confermati come saltati. Mi pare impossibile che riescano ad avere pronte sugli scaffali delle schede A3 tra 2 mesi scarsi quando i partners ancora manco le hanno viste le schede, a quanto si dice.
Se si riusciranno a vedere per fine febbraio sarà già un mezzo miracolo.

[Athlon 64 3000+]

Più che altro non riesco a capire come mai l'unita di tesselazione anche se hardware su RV870 ha un impatto cosi devastante dai benchmark fino ad ora visti.

[M4R1|<]

Originariamente inviato da Athlon 64 3000+

Più che altro non riesco a capire come mai l'unita di tesselazione anche se hardware su RV870 ha un impatto cosi devastante dai benchmark fino ad ora visti.

Tessellation ha si un impatto devastante lato performance ma rende le scene moolto più reali, è il caso dell'unigine. E' invece molto probabile, nel prossimo futuro, che si implementino delle opzioni per avere vari steep di pesantezza poligonale, in modo da permettere anche a schede di fascia mainstream di poterlo eseguire senza scendere sotto le soglie minime a risoluzioni oggi standard (1050p)

[Athlon 64 3000+]

Originariamente inviato da M4R1|<

Tessellation ha si un impatto devastante lato performance ma rende le scene moolto più reali, è il caso dell'unigine. E' invece molto probabile, nel prossimo futuro, che si implementino delle opzioni per avere vari steep di pesantezza poligonale, in modo da permettere anche a schede di fascia mainstream di poterlo eseguire senza scendere sotto le soglie minime a risoluzioni oggi standard (1050p)

Spero che sia solo perchè sono i primi giochi ad implementarle visto che è una freature molto bella,ma vedere che sia cosi pesante non mi fa molto piacere.
Poi vedendo i benchmark in dx9 tra la mia ex HD 4870 e la HD 5850 il distacco è sempre troppo poco visto le caratteristiche di quest'ultima.

[leoneazzurro]

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.

Dipende da come viene utilizzata. Mentre un filtro aggiunge sempre del lavoro in più da fare da parte della GPU, la tessellazione nasce per fare del lavoro in meno rispetto al caso "standard": Per cui si possono avere diverse situazioni: avere lo stesso dettaglio dei giochi DX10 con prestazioni migliorate, avere le stesse prestazioni con un dettaglio maggiore o avere frame rate giocabili con dettaglio parecchio alto. La scelta che si è fatta, dato la sovrabbondanza di potenza di calcolo alle risoluzioni "umane", sembra essere per ora la terza, ma non è detto che in futuro non si utilizzino anche le prime due opzioni (poi ci sono anche altre possibilità aperte dalla tessellazione, per esempio si può andare a vedere il demo "Froblins" di AMD e pensare ad uno strategico che utilizzi un sistema similare...)

Originariamente inviato da Athlon 64 3000+

Più che altro non riesco a capire come mai l'unita di tesselazione anche se hardware su RV870 ha un impatto cosi devastante dai benchmark fino ad ora visti.

Perchè se crei un numero maggiore di poligoni poi lo devi anche renderizzare, il che significa un numero maggiore di calcoli nello shader core (anche se il numero di pixel non cambia, cambiano il numero di vertici, di normali che vanno calcolate, ecc.). E' chiaro che gli "effetti" vanno aggiunti in base anche a ciò che la scheda è in grado di fare: impossibile pensare che una 5770 possa mantenere pur con la stessa capacità di tessellazione di una 5870 lo stesso frame rate. La cosa bella della tessellazione è che si potranno anche aggiustare molto più semplicemente i livelli di dettaglio poligonale in base alle prestazioni della scheda.

Originariamente inviato da Ratatosk

E'

Perché la generazione dei poligoni (triangoli) del wireframe finale è a carico dello shader core. A fare la stessa cosa in DX9 faresti 0.5fps

La generazione dei triangoli è data dal tessellatore e dal setup engine, ma i triangoli vanno poi elaborati, quindi se passo da 1000 a 100000 poligoni anche i calcoli relativi a normali, illuminazione, ecc. aumentano.

[Kharonte85]

Originariamente inviato da leoneazzurro

La generazione dei triangoli è data dal tessellatore e dal setup engine, ma i triangoli vanno poi elaborati, quindi se passo da 1000 a 100000 poligoni anche i calcoli relativi a normali, illuminazione, ecc. aumentano.

Presumo che anche l'applicazione dell'eventuale filtro AA a questi nuovi poligoni non sia gratis...