[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[zorco]

Originariamente inviato da Kharonte85

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

niente è gratis toccà lavorà

[leoneazzurro]

Originariamente inviato da Kharonte85

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

Brào

[A.L.M.]

Originariamente inviato da Ratatosk

E' impossibile

Se è necessario uno step A3 è certo che a gennaio al massimo avranno il teipaut finito e mandato in fabbrica. A quel punto sul mercato nella migliore delle ipotesi troverai le schede tre mesi dopo.

Non è nemmeno detto che non escano con una "GTX380", ovviamente Phantom Edition™ spompatissima basata sull'A2 per poi mandarla in EOL dopo pochissimi mesi uscendo con una "GTX385" A3 meno spompata della precedente che si farà tutta la strada fino alla revisione a 28nm.

Potrebbe essere, sai?
Un po' come ai bei vecchi tempi di FX5800 e poi FX5900...

[devAngnew]

Originariamente inviato da yossarian

questo è il tuo primo post sull'argomento

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).

Grazie per la raccolta
Qui veramente ci vogliamo arrampicare sugli specchi...
E' dal primo post che dico: lo shader ad HL viene caricato dal compilatore e tradotto in LM con tutti i passaggi del caso (speriamo che ti ricordi delle mie associazioni ).
Il compilatore da quando è stato inventato ha sempre funzionato cosi e cioè parto dal sorgente ed ottengo il codice macchina da far girare 1 volta per tutte. Tu invece sostieni che non funziona cosi ma da quello che posso capire dai tuoi post ogni istruzione al HL sarebbe caricata e tradotta nei registri della GPU ma questo non è un compilatore ma un interprete.
A questo punto conviene a te leggere e studiare su Wikipedia cosa sia un compilatore.

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

Ma cosa centra studiati come avvengono le operazione di fetch-decode-execute della GPU io stò parlando di compilatori (qest'ultimo adatta il codice intermedio generato alla macchina su cui girerà il compilato) e ricordati che un compilatore può anche girare su un architettura completamente diversa e compilare per un'altra. Spero di essermi spiegato.
Qui non c'è da fare nessuna lezione delle fasi fetch-decode-execute del funzionamento della GPU a basso livello ma mi sà di compilatori.
Visto le tue "nuove" teorie sui compilatori fornisci dei documenti ufficiali sul funzionamento dei compilatori di NVIDIA o ATI (a te la scelta).
Concludo e mi ripeto poichè 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.
Altrimenti ogniuno rimarrà sulle proprie teorie.

[Severnaya]

devAngnew mi sembri tanto un parente di spiderman

[Maury]

Originariamente inviato da devAngnew

Grazie per la raccolta
Qui veramente ci vogliamo arrampicare sugli specchi...

A me sembra palese che sia tu ad arrampicarti, senza contare che alla fine della fiera non stai spiegando nulla tecnicamente, cosa più e più volte richiesta.

[Elendil_1]

Originariamente inviato da devAngnew

Ma i compilatori cosa sono stati inventati a fare ... secondo te uno shader SM 3 ha diversi path per architetture 68xx e G80 e derivati.
Io dico di no, ma cade tutto nelle mani del compilatore che ottimizza per ogni gpu (ovviamente fino ad un certo punto).

Guarda,
io di schede video e compilatori non ne capisco granché (anche se ho una formazione scientifica, ma in altri ambiti), eppure ho capito benissimo il discorso di Yossarian che è lampante e cristallino. Tu continui a scrivere la stessa cosa da pagine e pagine senza capire cosa ti vien detto, e non so come faccia Yossarian a non averti ancora mandato a quel paese.
Fermati, prendi un bel respiro e prova a capire cos'ha scritto lui, perché ti sei impelagato in un discorso dal quale non puoi uscire.

[devAngnew]

Originariamente inviato da Ratatosk

Più semplicemente non hai idea di quello che stai scrivendo, infatti stai scrivendo cose prive di ogni senso.

L'ottimizzazione non in real-time è possibile solo se il software ha un code-path specifico per Fermi, cosa che ovviamente non accadrà.

La "traduzione" in real time delle chiamate MADD in FMA è sicuramente onerosa e non può essere fatta prima. Per farla prima serve la programmazione specifica a priori che dicevo.

Certo a meno che lo stesso JHH con la sola imposizione delle mani non renda ogni GPU Fermi magicamente in grado di fare cose impossibili.

Non credo proprio mi sà che non conosci i compilatori. Altrimenti mi diresti il perchè un compilatore non può fare ciò che dico.

[Iantikas]

Originariamente inviato da devAngnew

Grazie per la raccolta
Qui veramente ci vogliamo arrampicare sugli specchi...
E' dal primo post che dico: lo shader ad HL viene caricato dal compilatore e tradotto in LM con tutti i passaggi del caso (speriamo che ti ricordi delle mie associazioni ).
Il compilatore da quando è stato inventato ha sempre funzionato cosi e cioè parto dal sorgente ed ottengo il codice macchina da far girare 1 volta per tutte. Tu invece sostieni che non funziona cosi ma da quello che posso capire dai tuoi post ogni istruzione al HL sarebbe caricata e tradotta nei registri della GPU ma questo non è un compilatore ma un interprete.
A questo punto conviene a te leggere e studiare su Wikipedia cosa sia un compilatore.



Ma cosa centra studiati come avvengono le operazione di fetch-decode-execute della GPU io stò parlando di compilatori (qest'ultimo adatta il codice intermedio generato alla macchina su cui girerà il compilato) e ricordati che un compilatore può anche girare su un architettura completamente diversa e compilare per un'altra. Spero di essermi spiegato.
Qui non c'è da fare nessuna lezione delle fasi fetch-decode-execute del funzionamento della GPU a basso livello ma mi sà di compilatori.
Visto le tue "nuove" teorie sui compilatori fornisci dei documenti ufficiali sul funzionamento dei compilatori di NVIDIA o ATI (a te la scelta).
Concludo e mi ripeto poichè 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.
Altrimenti ogniuno rimarrà sulle proprie teorie.

io nn so se ti rendi conto ke gli rispondi senza dir niente e dai a yossarian dell'arrampicatore di spekki quando tu stai in free climbing già da un bel pò...

...lui domanda cuori e tu rispondi pikke...ti kiede dei dati a suffraggio della tua teoria e tu gli rispondi kiedendo dati sul funzionamento di compilatori e quant'altro...funzionamento ke è stato kiesto a te di spiegare appunto x dimostrare ke ciò ke affermi sia possibile...

...se continui su questa linea praticamente ti comporti da troll...ciao

[Foglia Morta]

Hanno ricominciato con i rebrand ?

GeForce 310 : http://h10010.www1.hp.com/wwpc/uk/en...7-4015770.html

[devAngnew]

Originariamente inviato da Iantikas

io nn so se ti rendi conto ke gli rispondi senza dir niente e dai a yossarian dell'arrampicatore di spekki quando tu stai in free climbing già da un bel pò...

...lui domanda cuori e tu rispondi pikke...ti kiede dei dati a suffraggio della tua teoria e tu gli rispondi kiedendo dati sul funzionamento di compilatori e quant'altro...funzionamento ke è stato kiesto a te di spiegare appunto x dimostrare ke ciò ke affermi sia possibile...

...se continui su questa linea praticamente ti comporti da troll...ciao

Parli di prove di ciò che dico vai a leggerti testi universitari che parlano del funzionamento di un compilatore poi mi dici se ho ragione o meno chiarendomi dove e perchè sbaglio.
Ciò di cui parla yossarian del funzionamento di un compilatore non esiste in letteratura.
E il Troll vale anche per lui visto che continua a non rispondere sul funzionamento del compilatore di una GPU.
Concludo qui o fornisca delle prove circa la sua teoria circa la pseudo-compilazione-interpretazione delle istruzioni di uno shader altrimenti il discorso è chiuso.

Ciao

[Foglia Morta]

L' articolo di yoss sulle ALU : http://www.appuntidigitali.it/5025/e...na-gpu-le-alu/

[Severnaya]

ora risponderà che è solo chiacchiere e distintivo

[Maury]

Originariamente inviato da Severnaya

ora risponderà che è solo chiacchiere e distintivo

senza dubbio farà così

[Maury]

Originariamente inviato da Foglia Morta

L' articolo di yoss sulle ALU : http://www.appuntidigitali.it/5025/e...na-gpu-le-alu/

Spaventoso Yoss, come sempre del resto

[yossarian]

Originariamente inviato da devAngnew

Grazie per la raccolta
Qui veramente ci vogliamo arrampicare sugli specchi...
E' dal primo post che dico: lo shader ad HL viene caricato dal compilatore e tradotto in LM con tutti i passaggi del caso (speriamo che ti ricordi delle mie associazioni ).
Il compilatore da quando è stato inventato ha sempre funzionato cosi e cioè parto dal sorgente ed ottengo il codice macchina da far girare 1 volta per tutte. Tu invece sostieni che non funziona cosi ma da quello che posso capire dai tuoi post ogni istruzione al HL sarebbe caricata e tradotta nei registri della GPU ma questo non è un compilatore ma un interprete.
A questo punto conviene a te leggere e studiare su Wikipedia cosa sia un compilatore.



Ma cosa centra studiati come avvengono le operazione di fetch-decode-execute della GPU io stò parlando di compilatori (qest'ultimo adatta il codice intermedio generato alla macchina su cui girerà il compilato) e ricordati che un compilatore può anche girare su un architettura completamente diversa e compilare per un'altra. Spero di essermi spiegato.
Qui non c'è da fare nessuna lezione delle fasi fetch-decode-execute del funzionamento della GPU a basso livello ma mi sà di compilatori.
Visto le tue "nuove" teorie sui compilatori fornisci dei documenti ufficiali sul funzionamento dei compilatori di NVIDIA o ATI (a te la scelta).
Concludo e mi ripeto poichè 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.
Altrimenti ogniuno rimarrà sulle proprie teorie.

ok, ripartiamo da 0 (zero)
Rys butta li una frase in cui afferma che i DRIVER NVIDIA opereranno la trasformazione delle MADD in FMA.
Tu sei partito lancia in resta sostenendo che questa trasformazione sarà for free, dicendo che avverrà una volta per tutte prima del caricamento del gioco e se ne occuperà il compilatore.
Ok, allora immagino saprai che un compilatore C quando trova un'istruzione di tipo MADD la traduce nell'equivalente in linguaggio macchina (MADD non FMA). Quello che deve avvenire è, invece, che queste MADD siano trasformate in FMA. E non è neppure sempre possibile che ciò avvenga perchè in alcuni casi può generare errori.
Allora, mi spieghi chi si occupa di manipolare il codice sorgente per modificare una particolare istruzione e a quale livello avviene questa manipolazione?
Io tenderei ad escludere un compilatore C generico e, immagino, che se provi a forzare una FMA al posta di una MADD un compilatore ti restituisca un errore (sono due operazioni diverse, nonostante si tratti sempre di moltiplicazioni e addizioni)
Il compilatore di cui parli è quello tipico del linguaggio C (valido per tutte le architetture) che si occupa di tradurre da linguaggio ad alto livello le istruzioni in un linguaggio a basso livello (una madd resta una madd, per intenderci). Questo significa che se ho 1 milione di righe di codice in C il compilatore le avrà trasformate in n milioni di righe in LM. Ma non mi fa ottimizzazioni per quella determinata architettura. Se devo riordinare le istruzioni o devo sostituirle devo intervenire con ottimizzazioni ad hoc in un secondo momento. Ossia devo indicare al chip che quando incontra una determinata istruzione (compilata in LM) la trasformi in un'altra determinata istruzione. Oppure che raggruppi un certo tipo di istruzioni o ne separi altre. Con nv30 si arrivava a sostituire codice dx9 (hlsl) con codice dx8 (assembly); chi se ne occupava, il compilatore C?
Ora, a meno che non abbia a disposizione una path specifica per fermi che contiene FMA al posto di MADD, mi spieghi un compilatore C come fa a tradurre le MADD come FMA? Sto parlando di qualcuno (in senso figurato) che dica materialmente alla gpu che non deve eseguire una madd, come risulterebbe dal linguaggio compilato, ma una fma.
Mi spieghi come avviene questo passaggio a priori su un codice sorgente "sconosciuto" di cui si sa solo che è compilato in C (per cui c'è il compiler standard che traduca mul con moltiplicazione add con addizione e madd con moltiplicazione con troncamento e addizione con arrotondamento).
Magari capisci anche perchè ti ho chiesto dove avvengono le operazioni di fetch and decode (e, in questo caso, di replace)

[Wikkle]

ancora le k
ma non erano estinti gli utilizzatori?

[The_SaN]

Originariamente inviato da Wikkle

ancora le k
ma non erano estinti gli utilizzatori?

Dai, non fanno nulla di male WiCCle

[Foglia Morta]

Originariamente inviato da yossarian

Ora, a meno che non abbia a disposizione una path specifica per fermi che contiene FMA al posto di MADD

Magari migliorerà la collaborazione tra nVidia e Epic Games

[leoneazzurro]

Credo ci sia un po' di confusione e di incomprensione: pur non essendo io un programmatore, se non erro mi pare di ricordare che la struttura di esecuzione di una applicazione 3D sotto Windows è la seguente:

Applicazione 3D
|
API DirectX
|
HAL
|
Driver
|
Linguaggio macchina (GPU)

Ora uno shader scritto in HLSL, essendo HLSL un linguaggio ad alto livello, dovrà essere "tradotto" in un linguaggio comprensibile alla GPU ed il primo passo quindi è interfacciarsi con lo "strato" DirectX. Tuttavia, a meno di non creare un path specifico per ogni GPU (è possibile, ma non so quanti sviluppatori lo facciano o lo faranno, dato che la maggior parte dell'installato anche DX10 non può eseguire FMA o le può eseguire a velocità non tollerabili) la "compilazione" dello shader (ma non è esattamente una compilazione, in quanto non viene creato direttamente del linguaggio macchina nativo per la GPU, bensì ci si interfaccia con le librerie DirectX e con l'HAL) sarà la medesima per tutte le GPU. Poi Le API tramite l'HAL si interfacciano mediante con il driver e quindi con la GPU. La "traduzione" delle MADD in FMA se nell'applicazione non esiste un path specifico Fermi può avvenire solo a livello di driver, e comporta in effetti la sostituzione di ogni MADD con una FMA con gli stessi operandi. Poi bisogna vedere prestazionalmente ciò cosa comporta, del resto di simili "traduzioni" ed ottimizzazioni i driver attuali ne fanno parecchie ed anche più complesse di così.

Ditemi se ho cannato qualcosa.