[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[Maury]

Originariamente inviato da devAngnew

visto che in linea di massima ho spiegato cosa fa un compilatore (soprattuto il modulo ottimizzatore) ma tu semplicemente ignori il tutto.



P.S: skizzo99999999 ti consiglio di lasciar perdere.

Tu hai spiegato, per l'ennesima volta, ben poco (o nulla)

[yossarian]

Originariamente inviato da skizzo99999999

Che la chiamata alla glCompileShader richiami un fantomatico compilatore generico lo dici tu ma io sono sicuro che non è così. La chiamata viene gestita dai driver che compilano una versione ottimizzata per la scheda su cui si sta facedo l'esecuzione. E' solo questo il problema tu dici che c'è un "compilatore standard" cha la fa, io no. E' inutile continuare a parlarne. Mi sembra che sia solo questo il tuo problema nel comprendere il mio ragionamento. Di questo ti ripeto ne sono sicuro perchè lo utilizzo tutti i giorni. Se vuoi saperne di più pappati l'orange book oppure un libro un po più leggero come "OpenGL SuperBible (4th Edition)". Poi può essere che con le directx la situazione sia difefrente, e da come parli mi sembra che tu sia più ferrato su queste. Ma mi sembra francamente poco credibile che le directx gestiscano in maniera tanto imbecille la compilazione del codice, visto che le opengl sono storicamente sempre indietro riguardo a feature implementate.

non esiste un fantomatico compilatore generico (il compilatore l'ha tirato in ballo il tuo compare). Si chiamano ottimizzazioni e non vengono fatte dal compilatore standard o della cpu o chiamalo come ti pare.
Intanto non hai risposto alla domanda: è la cpu che si occupa di effettuare la sostituzione? Perchè dovrebbe farlo e chi glielo dovrebbe dire? I driver nVidia? Non pilotano un chip di cui non conoscono l'architettura; sai che per scrivere un driver devi conoscere a fondo l'architettura del chip per il quale lo scrivi? Significa che se nVidia scrive un driver che dica al compilatore di una cpu intel di ottimizzare il codice per fermi, nVidia deve conoscere a menadito l'rchitettura intel (non solo fermi).
Poichè continui a darmi dell'ignorante, più e meno velatamente, farò lo stesso e in maniera esplicita. Stai ripetendo che tu fai ciò di cui parli tuti i giorni. Io ti dico che non lo hai mai fatto e non sai neppure di cosa stai parlando.
Non si tratta di compilare 4 righe in croce per far cambiare colore a una palla rotante, ma di fare ottimizzazioni per una architettura che devi conoscere ALLA PERFEZIONE. Tu hai ammesso di non conoscere l'architetutra del chip su cui programmi (e da come parli non lo metto in dubbio) e neppure l'architetutre dei chip grafici in generale. Quindi tu non saresti in grado di scrivere una sola riga di codice per ottimizzare il codice per il chip della tua scheda video. Però, ripeti che è quello che fai tutti i giorni.

Hai affermato che una chiamata mul seguita da una add lascia libera interpretazione al chip; sbagliato, una chiamata del genere, in nessun linguaggio, permetterà l'esecuzione di una fma (ma tu ssai di cosa parli, perchè ci lavori tutti i giorni).
Hai affermato che è la cpu ad occuparsi della compilazione prima di inviare il codice alla vram. Sbagliato la cpu non si occupa di afre le ottimizzazioni e neppure le sostituzioni; la cpu scrive addizione dove trova addizione e non interpreta a uso e consumo di fermi (di cui non conosce neppure l'esistenza, altro particolare che ti sfugge).
Hai affermato che se ne occupa una non ben precisata entità una volta che l'intero codice è nella vram. Sbagliato, perchè nessuna entità, astrale o meno, va ad operare nella vram direttamente (d'altra parte, non sai come lavora una gpu, però sai come vanno queste cose perchè ci lavori tutti i giorni).

Poi affermi che sono i driver a gestire le chiamate. Ok, cominci ad avivcinarti. A che livello? Risposta: l'intero codice viene compilato prima che vada in esecuzione. Ammettiamo che sia così; allora dove e da chi? Boh, non conosco l'architettura delle gpu, forse dalla cpu o dalla gpu stessa all'interno della vram (e risiamo al punto precedente).
Il problema non sono le dx o le opengl; il problema è che state parlando di cose di cui non sapete nulla. Vi riempite la bocca con le ottimizzazioni fatte a livello di driver ma non sapete chi gestisce e dove queste ottimizzazioni.
Ora, poichè non ho tempo da perdere con queste stupidaggini e quello che ho scritto è tutto sul forum, vi saluto e vi lascio con la vostra convinzione che sia come dite, anche se non sapete come, quando e dove tutto avvenga. Ma sai com'è, l'importante è avere fede

[yossarian]

Originariamente inviato da devAngnew

Innazitutto ringrazio skizzo99999999 a quanto pare qualcuno che ragiona c'è non è che qui sul forum si risponde solo per partito preso.

Yossarian mi spiace ma ti stai arrampicando sugli specchi ma orami gli specchi sono finiti.











Mi quoto e aggiungo a quanto pare inizi a non rispodere a ciò che ti viene chiesto.


Scusami una domanda banale ma da quando una GPU nata per fare calcoli altamente paralleli tipo moltiplicazioni matriciali ecc. ecc. è diventata una CPU ?
Sai un compilatore gira su CPU è la letteratura scentifica universitaria che lo dice non il primo devAngnew che posta su un forum.
Il compilatore HLSL gira sulla CPU e guarda caso fa uso della memoria centrale per effettuare tutti i passaggi del caso e vale per NVIDIA ma anche per ATI sia chiaro.
Concludo Solo e ripeto Solo il codice Macchina sarà passato alla GPU.

Io considero il discorso chiuso visto che in linea di massima ho spiegato cosa fa un compilatore (soprattuto il modulo ottimizzatore) ma tu semplicemente ignori il tutto.



P.S: skizzo99999999 ti consiglio di lasciar perdere.

ciccio evidentemente, oltre a non sapere di cosa parli, non distingui neppure una domanda da un'affermazione. Quotati quanto ti pare ma in quella frase c'è la domanda: chi gestiva quelle sostituzioni, il compilatore HLSL? DOMANDA ciccio non AFFERMAZIONE. Risposta, ovvia, NO. Quindi era qualcun altro.
Ora, posso capire che tu non conosca l'architetutra di un chip, mi riesce difficile, però, interfacciarmi con qualcuno che ha difficoltà a capire la lingua italiana.
A questo punto crogiolatevi nella vostra ignorabnza sperando che non abbiate altri emuli.

[Maury]

Originariamente inviato da yossarian

l'importante è avere fede

Ah beh a giudicare dai loro post questa componente non gli manca di certo

però sai come vanno queste cose perchè ci lavori tutti i giorni

Yoss m'hai fatto morire con questa frase

[yossarian]

Originariamente inviato da Jackaos

A me non pare che tu abbia spiegato molto, mi pare che yossarian abbia cercato di spiegare molto di più dettagliando il discorso, anche skizzo lo ha dettagliato, ammettendo però di non avere una conoscenza specifica delle gpu. Voi due state affermando che un determinato processo avviene in un certo modo, mentre yossarian afferma che non avviene nel modo che voi descrivete, quindi, il discorso non si può certo chiudere perchè non c'è compresione, ma soltanto perchè voi rimanete sulle vostre posizioni, e yossarian sulla sua. A questo punto chi vi legge, o si fa una ricerca approfondita su documentazione che parli di queste cose, o aspetta fermi. Oppure voi continuate a discuterne portando altri esempi dettagliati, prove diciamo, e cose così, che per me è più comodo e divertente oltrechè probabilmente meglio assimilabile...spero. Ciao!

quando uscirà fermi non avrai la soluozine del problema perchè anche ammesso che riescano a trasformare le madd in fma, non ti verranno a dire chi come dove e quanfdo lo ha fatto.
Le posizioni sono molto semplici: da un lato c'è chi afferma che poichè esistono i compilatori, basta scrivere uno shader, effettuare una chiamata a quello shader e il compilatore si occuperà di tutto. Il problema è che questo qualcuno si limita a vedere le cose a livello di linguaggio di programmazione e non si preoccupa di chi deve fare cosa, quando e perchè. Per questo motivo nessuno dei due è iin grado di fornire uno straccio di risposta a domande elementari come ad esempio, dove si trova il compilatore. O meglio, uno dei due ha risposto a questa domanda, ma si è perso strada facendo.
La risposta corretta è: il compilatore (ma non volgio chiamarlo in quel modo), diciamo il tool che si occupa di effetuare le sostituzioni e le ottimizzazioni di qualunque natura è all'interno dei driver. Dei driver di chi? Di nVidia, ovviamente, nello specifico. Allora, se questo tool è nei driver di nVidia, come può essere che a fare le sostituzioni ci pensa la cpu prima di inviare il tutto alla vram? Non mi risulta che nVidia abbia cpu x86 e anche se le avesse, parliamo comunque del driver della gpu. Quindi, non può essere la cpu. Allora la gpu (escludiamo l'ipotesi che il codice sorgente arrivi già compilato per fermi). Ok, lo fa la gpu (d'altro canto il driver è suo). Quando lo fa? Risposta prima che lo shader venga elaborato. Domanda: lo shader o tutto il programma? Qui le risposte sono confuse: qualche shader, tutto il programma, boh, sicuramente avviene prima; semmai prendo il raccordo ecc. . Domanda: dove avviene? Boh, nella ram video, prima di arivare nella ram video (magari nel bus pci ex.) o piuttosto se ne occupa il northbridge. Sicuramemte, però, avviene at compile time.
Insomma, mi pare che ci siano poche idee ma ben confuse. Poi, se si scambiano anche delle domande per delle affermazioni, allora stiamo freschi


comunque, per chi non va con i paraocchi, le cose sono piuttosto semplici. Ci sono vari layer
applicazione, api, sistema operativo, hardware abstaction layer, driver.
La prima è, ipotesi, il gioco; la seconda non ha bisogno di presentazione. La terza è un'interfaccia tra il S.O. e i driver. Ogni S.O: ha più hal (a seconda di quanti sono i tipi di hw con cui si deve interfacciare) e ha anche un compilatore standard per ciascuna delle api di riferimento con cui si interfaccia; anche molte applicazioni hanno una o più hal a seconda del target di riferimento a livello hw. In pratica l'hal è scritto o dal produttore dell'hw o in collaborazione con esso e contiene una serie di ottimizzazioni che servono a migliorare la compatibilità e a implementare qualche funzionalità extra compatibilmente con le capacità dell'hw stesso. Poi ci sono i driver che contengono tutti i tool che servono a ottimizzare i chip (nello specifico quelli grafici).
I compiler contenuti nel S.O. sono uguali per tutti, perchè lo stesso s.o. deve interfacciarsi con hw ati dx11 o dx7, oppure nvidia a shader dedicati o unificati, ecc. Quindi non possono contenere ottimizzazioni per un particolare tipo di hw o, peggio, per un solo chip. Di conseguenza, le ottimizzazioni si possono fare solo ad un livello inferiore rispetto a quello del s.o., ossia a livello di hal o di driver. In ciascuno dei due casi, non è la cpu di sistema che si occupa di gestire queste ottimizzazioni ma il chip a cui sono dedicate le ottimizzaioni, ovvero la gpu (nel caso specifico). Qui subentra il "come funziona una gpu" che i nostri baldi arrampicamuri dimostrano (e confessano) di ignorare. E qui mi fermo, perchè queste cose le ho già ripetute più volte. Di una cosa sono certo: i clipping plane e lo shader replacemnt di NV30 non erano gestiti dalla cpu e non avvenivano at compile time

[Jackaos]

Originariamente inviato da yossarian

quando uscirà fermi non avrai la soluoizne del problema perchè anche ammesso che riescano a trasformare le madd in fma, non ti verranno a dire chi come dove e quanfdo lo ha fatto.
Le posizioni sono molto semplici: da un lato c'è chi afferma che poichè esistono i compilatori, basta scrivere uno shader, effettuare una chiamata a quello shader e il compilatore si occuperà di tutto. Il problema è che questo qualcuno si limita a vedere le cose a livello di linguaggio di programmazione e non si preoccupa di chi deve fare cosa, quando e perchè. Per questo motivo nessuno dei due è iin grado di fornire uno straccio di risposta a domande elementari come ad esempio, dove si trova il compilatore. O meglio, uno dei due ha risposto a questa domanda, ma si è perso strada facendo.
La risposta corretta è: il compilatore (ma non volgio chiamarlo in quel modo), diciamo il tool che si occupa di effetuare le sostituzioni e le ottimizzazioni di qualunque natura è all'interno dei driver. Dei driver di chi? Di nVidia, ovviamente, nello specifico. Allora, se questo tool è nei driver di nVidia, come può essere che a fare le sostituzioni ci pensa la cpu prima di inviare il tutto alla vram? Non mi risulta che nVidia abbia cpu x86 e anche se le avesse, parliamo comunque del driver della gpu. Quindi, non può essere la cpu. Allora la gpu (escludiamo l'ipotesi che il codice sorgente arrivi già compilato per fermi). Ok, lo fa la gpu (d'altro canto il driver è suo). Quando lo fa? Risposta prima che lo shader venga elaborato. Domanda: lo shader o tutto il programma? Qui le risposte sono confuse: qualche shader, tutto il programma, boh, sicuramente avviene prima; semmai prendo il raccordo ecc. . Domanda: dove avviene? Boh, nella ram video, prima di arivare nella ram video (magari nel bus pci ex.) o piuttosto se ne occupa il northbridge. Sicuramemte, però, avviene at compile time.
Insomma, mi pare che ci siano poche idee ma ben confuse. Poi, se si scambiano anche delle domande per delle affermazioni, allora stiamo freschi

Chiara sintesi della discussione fin'ora avvenuta. Ipotesi scherzosa: forse dovremo dotarci di schede madri con molti slot PCIex 16x per giocare con nVidia, una o due schede per il lavoro primario, una per la fisica, e una per far meglio digerire a fermi i dati da processare, il nuovo sistema RuminantSLI.

[skizzo99999999]

Io ho detto che non conosco a menadito l'architettura delle GPU (come evidentemente conosci te) perchè programmo in opengl e quindi non mi occupo di ottimizzazioni che effettuano i compilatori. L'ho detto subito. Tutto è partito da questa fantomatica penalizzazione per questa maledetta FMA. Siccome conosco come viene gestito il codice degli shader, ho solo ipotizzato che si potesse fare questa "sostituzione" durante la compilazione degli shader (che avviene come da te e da me più volte detto a runtime). Poi ci possono essere altre ragioni tecniche come la questione degli arrotondamenti che lo impediscono, ma la storia che alla GPU arrivi un codice compilato "generalista" e ridicola. Il driver è fatto per gestire bene una certa architettura ed il driver di fermi sarà fatto per gestirla al meglio. Quando faccio doppio click sull'eseguibile di un gioco, a quel punto gli shader non sono compilati, sono dei bei sorgenti di testo che la GPU non saprebbe interpretare. Quando dal codice del gioco arrivano alla CPU le istruzioni di caricamento e compilazione degli shader il driver gestisce la compilazione che non so se fa la cpu o la gpu. Questo l'ho detto più volte. Si su questo passo sono ignorante lo ammetto. E allora? Mi devo suicidare? Se mi dici che gira su GPU bene ho imparato qualcosa di nuovo. In ogni caso è sempre un compilatore, cioè è esso stesso un software che gira su un hardware. il compilatore è "compilato" e scritto per dove deve girare, è lui che sa cosa deve fare e lo fa, sia che giri sulla GPU che sulla CPU. Io di primo acchito direi che gira sulla CPU (visto che mi sembra più semplice scrivere un compilatore con un set di istruzioni di una CPU che di una GPU) ma se con tanta veemenza dici che gira sula GPU ci credo, non è che devi insultarmi per questo. Questo compilatore lo ha programmato NVIDIA che conosce bene l'architettura per cui uscirà lo shader compilato. L'operazione di sostituzione non è una operazione che deve considerare dipendenze o quant'altro, ma è solo "vedo una istruzione, ci metto questa". Non capisco dove stia il problema. Non vedo cosa deve conoscere NVIDIA di così profondo dell'architettura INTEL per poter scrivere un compilatore che non deve generare codice per intel ma che da uno shader testuale tiri fuori un pezzo di codice interpretabile dalle sue GPU. I driver servono anche a questo.
Non vedo perchè non si possa ammettere nemmeno la possibilità che si possa non conoscere tutto lo scibile umano su un argomento, anche se lo si padroneggia molto bene come te e lo si affronta da anni.

[skizzo99999999]

Originariamente inviato da yossarian

Allora, se questo tool è nei driver di nVidia, come può essere che a fare le sostituzioni ci pensa la cpu prima di inviare il tutto alla vram? Non mi risulta che nVidia abbia cpu x86 e anche se le avesse, parliamo comunque del driver della gpu. Quindi, non può essere la cpu. Allora la gpu (escludiamo l'ipotesi che il codice sorgente arrivi già compilato per fermi). Ok, lo fa la gpu (d'altro canto il driver è suo). Quando lo fa? Risposta prima che lo shader venga elaborato. Domanda: lo shader o tutto il programma? Qui le risposte sono confuse: qualche shader, tutto il programma, boh, sicuramente avviene prima; semmai prendo il raccordo ecc. . Domanda: dove avviene? Boh, nella ram video, prima di arivare nella ram video (magari nel bus pci ex.) o piuttosto se ne occupa il northbridge. Sicuramemte, però, avviene at compile time.
Insomma, mi pare che ci siano poche idee ma ben confuse. Poi, se si scambiano anche delle domande per delle affermazioni, allora stiamo freschi

Beh in questo mi sembra di essere stato coerente, la so bene la differenza tra il codice del programma (che gira sulla CPU) e lo shader (che una volta compilato gira sulla GPU). Quello che viene compilato a runtime sono soltanto gli shader e non tutta o parte dell'applicazione.

[skizzo99999999]

Originariamente inviato da Ratatosk

Esattamente. E "vedo una istruzione, ci metto questa", è qualcosa che richiede un tempo T>0, come non lo è "vedo un pixel viola, lo coloro di giallo".

L'unico modo per non avere inefficienze è che il software sia pensato per girare usando FMA al posto di MADD, o che abbia due path diversi per gestire entrambe le possibilità, cosa che ovviamente non avverrà per supportare UNA scheda video che fa le cose diversamente da tutte le altre.

L'alternativa è prerenderizzare tutto, cosa impossibile, ovviamente, con un gioco.

MA infatti non ho MAIIIIIIIIIII datto che non richiede tempo, è che questo tempo lo "sprechi" quando chiami la compilazione dello shader, che è si durante il runtime del gioco/applicazione ma non durante il loop del rendering. Lo si fa di solito nel caricamento, almeno così è come faccio io e come ho letto in tutti i tutorial/testi/corsi che ho letto/frequentato. Se poi c'è qualcuno che ad ogni frame si ricompila gli shader peggio per lui...
Comunque ho trovato una parte initeressante nel testo che avevo già indicato in precedenza (per chi vuola approfondire, sappia che è un libro di 1200 pagine un po caruccio e oramai non + aggiornatissimo):

"Unlike some other shading language APIs out there, GLSL is designed to accept shader text rather than precompiled binaries. This makes it possible for the application to provide a single universal shader regardless of the underlying OpenGL implementation. The OpenGL device driver can then proceed to compile and optimize for the underlying hardware. Another benefit is that the driver can be updated with improved optimization methods, making shaders run faster over time, without any burden on application vendors to patch their applications." Superbible pag 528

C'erano anche altre fonti dove era spiegato con + precisione e più dettagliatamente, ma tra i tanti libri che ho faccio fatica a trovarle. Almeno una sufficienza per l'impegno la merito suvvia...

[yossarian]

Originariamente inviato da skizzo99999999

Io ho detto che non conosco a menadito l'architettura delle GPU (come evidentemente conosci te) perchè programmo in opengl e quindi non mi occupo di ottimizzazioni che effettuano i compilatori. L'ho detto subito. Tutto è partito da questa fantomatica penalizzazione per questa maledetta FMA. Siccome conosco come viene gestito il codice degli shader, ho solo ipotizzato che si potesse fare questa "sostituzione" durante la compilazione degli shader (che avviene come da te e da me più volte detto a runtime).

fin qui ok

Originariamente inviato da skizzo99999999

Poi ci possono essere altre ragioni tecniche come la questione degli arrotondamenti che lo impediscono,

argomento non toccato finora

Originariamente inviato da skizzo99999999

ma la storia che alla GPU arrivi un codice compilato "generalista" e ridicola. Il driver è fatto per gestire bene una certa architettura ed il driver di fermi sarà fatto per gestirla al meglio. Quando faccio doppio click sull'eseguibile di un gioco, a quel punto gli shader non sono compilati, sono dei bei sorgenti di testo che la GPU non saprebbe interpretare. Quando dal codice del gioco arrivano alla CPU le istruzioni di caricamento e compilazione degli shader il driver gestisce la compilazione che non so se fa la cpu o la gpu.

qui c'è da puntualizzare una cosa; a questo livello, il driver non è ancora entrato in gioco. E' la cpu che gestisce la compilazione ma lo fa utilizzando un compiler generico per quel determinato tipo di api, contenuto nel sistema operativo. Quindi, a questo livello, non viene fatta ancora nessuna ottimizzazione (e non può essere altrimenti visto che il sistema operativo conosce la gpu con cui si interfaccia tramite hal ma la cpu no. Tramite hal, però, è possibile che il sistema operativo dica alla cpu di inviare, insieme al codice, l'istruzione che, in presenza di una determinata operazione ci si deve comportare in un ben preciso modo.

Originariamente inviato da skizzo99999999

Questo l'ho detto più volte. Si su questo passo sono ignorante lo ammetto. E allora? Mi devo suicidare?

te ne do atto infatti e apprezzo l'onestà intellettuale

Originariamente inviato da skizzo99999999

Se mi dici che gira su GPU bene ho imparato qualcosa di nuovo. In ogni caso è sempre un compilatore, cioè è esso stesso un software che gira su un hardware. il compilatore è "compilato" e scritto per dove deve girare, è lui che sa cosa deve fare e lo fa, sia che giri sulla GPU che sulla CPU. Io di primo acchito direi che gira sulla CPU (visto che mi sembra più semplice scrivere un compilatore con un set di istruzioni di una CPU che di una GPU) ma se con tanta veemenza dici che gira sula GPU ci credo, non è che devi insultarmi per questo.

siamo arrivati alla vrma, con il codice compilato dalla cpu, non ottimizzato, ma con delle raccomandazioni. Quello che ho cercato di farvi capire dall'inizio è che la cpu non si può fare carico di eseguire delle ottimizzazioni per un altro chip. Il compito di ciò è del chip stesso istruito da chi lo ha progettato, costruito e programmato.
Quindi, la vram contiene codice digeribile per una gpu e, in più, ci sono delle "istruzioni aggiuntive" che indicano come comportarsi in presenza di una derminata operazione.
Ti chiedo scusa per gli insulti

Originariamente inviato da skizzo99999999

Questo compilatore lo ha programmato NVIDIA che conosce bene l'architettura per cui uscirà lo shader compilato. L'operazione di sostituzione non è una operazione che deve considerare dipendenze o quant'altro, ma è solo "vedo una istruzione, ci metto questa". Non capisco dove stia il problema. Non vedo cosa deve conoscere NVIDIA di così profondo dell'architettura INTEL per poter scrivere un compilatore che non deve generare codice per intel ma che da uno shader testuale tiri fuori un pezzo di codice interpretabile dalle sue GPU. I driver servono anche a questo.

Infatti non ho detto che è un problema, ho detto che l'operazione è fattibile a determinate condizioni, ovvero che non si creino problemi con i mancati troncamenti.
Comunque, completiamo l'esecuzione. La gpu inizia a caricare il codice all'interno della instruction cache del dispatch processor; da li, una parte va nei registri assegnati alle istruzioni. Il thread porcessor legge prende le istruzioni, le legge, decide a quale cluster di alu mandarle in esecuzione. Devi vedere il thread processor come un vero e proprio processorre a cui mancano solo le pipeline di calcolo. Nel afre questa operazione, quando trova una sequenza di mul e add, in pratica una madd, la sostituisce con una fma e la invia alle alu per l'esecuzione. Qui viene caricata all'interno degli instruction buffer insieme a lle altre istruzioni. In questa fase le istruzioni sono eseguite in modalità FIFO, mentre il thread processor gestisce i thread in modalità out of order facendo anche renaming e reordering dei registri contenuti nei buffer. Quindi la alu manda in esecuzione direttamente una fma (ma la trasformazione è avvenuta in run time dentro la gpu).
Perchè non se ne può occupare intel o amd? Perchè i driver nVidia non si interfacciano con la cpu. La cpu è un'entità del tutto generica: può essere un quad core, un mono core, una cpu di 15 anni fa, può essere in order o out of order e basta che varino il numero di registri o la loro dimensioni che cambia l'isa. Il driver si può interfacciare solo con ciò che conosce bene (ovvero la gpu) ma, attraverso la hal, può far si che la cpu comunichi al thread processor il da farsi.
QUOTE=skizzo99999999;29836549]
Non vedo perchè non si possa ammettere nemmeno la possibilità che si possa non conoscere tutto lo scibile umano su un argomento, anche se lo si padroneggia molto bene come te e lo si affronta da anni.[/quote]

non pretendo che lo si conosca. Non credo che qualcuno di noi possa vantarsi di qualcosa del genere. L'unica cosa che chiedo è che si stiano a sentire anche le ragioni dell'altro, senza ragionare per partito preso.
Discutendo con calma, tra persone intelligenti, si trova sempre un punto di incontro

[A.L.M.]

Originariamente inviato da yossarian

il problema è proprio il punto 3
Quanto codice pensi si possa caricare su una gpu o, per essere precisi, sugli instruction buffer del thread processor di una gpu? Non conta quello presente sulla vram (il thread processor non ha accesso alla vram per compilare il codice) ma solo quello presente nei buffer interni del thread processor. E' solo su quello che si possono fare le sostituzioni.

Se ho capito bene, è questo il fulcro di tutto il contendere (e credetemi, è un bel contendere: se non ci si stuzzica troppo, finalmente da un thread tecnico si riesce ad imparare qualcosa).

Cerco di ricapitolare...
Il problema sta nel fatto che diverse persone (Rys compreso, credo) credono che la sostituzione venga fatta a compilation time e non "on the fly". Ossia mentre il pc carica un livello di un gioco e la cpu fa la normale compilazione degli shaders che la gpu si troverà ad usare in quel livello, il thread processor si occuperà di sostituire tutte le operazioni MADD che troverà in FMA.
Ed è il motivo per cui parlano di operazione "for free". Esiste un costo, ma viene mascherato dal fatto che nessuno si accorgerà di un caricamento di qualche secondo più lento, al peggio.
Quello che sostiene yossarian è che però tale operazione non può essere fatta in maniera così massiccia, perchè il thread processor può operare le sostituzioni solo sulle porzioni di codice (suppongo porzioni molto limitate) che si trovano nei suoi buffer.
Questo comporta che in realtà tale sostituzione venga fatta quasi "on the fly", comportando un costo prestazionale di un certo rilievo, che può essere mascherato in qualche modo, come anche no.

yoss non fustigarmi se ho sbagliato...

[yossarian]

Originariamente inviato da skizzo99999999

MA infatti non ho MAIIIIIIIIIII datto che non richiede tempo, è che questo tempo lo "sprechi" quando chiami la compilazione dello shader, che è si durante il runtime del gioco/applicazione ma non durante il loop del rendering. Lo si fa di solito nel caricamento, almeno così è come faccio io e come ho letto in tutti i tutorial/testi/corsi che ho letto/frequentato. Se poi c'è qualcuno che ad ogni frame si ricompila gli shader peggio per lui...
Comunque ho trovato una parte initeressante nel testo che avevo già indicato in precedenza (per chi vuola approfondire, sappia che è un libro di 1200 pagine un po caruccio e oramai non + aggiornatissimo):

"Unlike some other shading language APIs out there, GLSL is designed to accept shader text rather than precompiled binaries. This makes it possible for the application to provide a single universal shader regardless of the underlying OpenGL implementation. The OpenGL device driver can then proceed to compile and optimize for the underlying hardware. Another benefit is that the driver can be updated with improved optimization methods, making shaders run faster over time, without any burden on application vendors to patch their applications." Superbible pag 528

C'erano anche altre fonti dove era spiegato con + precisione e più dettagliatamente, ma tra i tanti libri che ho faccio fatica a trovarle. Almeno una sufficienza per l'impegno la merito suvvia...

il problema è proprio questo: non è che il codice viene ricompilato ogni volta: è quella specifica sostituzione che deve essere eseguita ognivolta che ti trovi una madd. Il codice arriva compilato dalla cpu (come ti ho spiegato nell'altro post); la gpu si deve occupare solo di fare le ottimizzazioni necessarie e tra questa la sostituzione in questione. Purtroppo, il thread processor, prma dell'avvio del gioco può operare solo sulla porzione di codice che ha caricato nei suoi registri e non su quello ancora da caricare. Quando parte l'elaborazione e i registri del thread processor iniziano a svuotarsi ed a riempirsi, arriva nuovo codice con nuove madd da sostituire (codice sempre già compilato in precedenza).
Quello di cui avevo parlato dall'inizio era il fatto che questa sostituzione, per quanto possa essre mascherata dal fatto che la gpu gestisce migliaia di thread in simultanea, avrà sempre un impatto sulle prestazini e non potrà essere for free come qualcuno sostiene. Nota bene che ho parlato di sostituzione non di ricompilazione di tutto il programma o di un gruppo di shader.

[devAngnew]

Originariamente inviato da skizzo99999999

Io non dico che la sostituzione non comporti nessun rallentamento nella compilazione, anche se non credo sarà rilevante, ma questo non è il punto. Mettiamo che il rallentamento ci sia e non sia trascurabile. E allora? mica lo fa la GPU durante il rendering della scena, lo fa il driver (o chi per lui all'interno del driver) durante la glCompileShader o glLinkProgram o similari, che non penso esegue la GPU ma la CPU istruita dal driver, ma comunque non farebbe nessuna differenza anche se lo eseguisse la GPU. Una volta che sarà finita questa traduzione, lo shader è compilato, caricato nella vram (o dovunque vengano messi gli shader compilati e pronti per essere usati) con le sue belle FMA invece che MADD.
Ripeto, non ho la presunzione di sapere con certezza se si può fare, ma dire che per farlo SICURAMENTE bisogna farlo fare "al volo" (e quindi ogni volta) alla GPU mi sembra azzardato.
Provo a fare un esempio. Prendiamo un pezzo di codice GLSL

vec4 a;
vec4 b;
a=b+3;

se b è un vettore di 4 float che valgono tutti 50, a diverrà un vettore di 4 float che varrà 53. Penso che qui qualche madd ci sia...
Il codice GLSL non contiene MADD, ma istruzioni ad alto livello. il compilatore del driver lo compilerà UNA VOLTA SOLA e li si che ci saranno le madd. Ora è così difficile che invece che le MADD il compilatore metta le FMA? francamente mi sembra di no. Poi non dico che non ci siano altri impedimenti, ma dire che il compilatore deve per forza tradurre in MADD che poi la GPU al volo dovrà "trasformare" in FMA ogni volta mi sembra contro la logica.

Quoto.

E' proprio questo che non capisco, e penso che sia quello che non capisce nemmeno devAngnew (anche se è difficile interpretare il pensiero altrui).

No, probabilmente non ci siamo semplicemente capiti.
In pratica la sostituzione di cui parli lo farà il modulo ottimizzatore del compilatore.


Per il resto il discorso è chiuso punto e basta.

[ippo.g]

totale: la scheda video servirà ancora o no?

[yossarian]

Originariamente inviato da A.L.M.

Se ho capito bene, è questo il fulcro di tutto il contendere (e credetemi, è un bel contendere: se non ci si stuzzica troppo, finalmente da un thread tecnico si riesce ad imparare qualcosa).

Cerco di ricapitolare...
Il problema sta nel fatto che diverse persone (Rys compreso, credo) credono che la sostituzione venga fatta a compilation time e non "on the fly". Ossia mentre il pc carica un livello di un gioco e la cpu fa la normale compilazione degli shaders che la gpu si troverà ad usare in quel livello, il thread processor si occuperà di sostituire tutte le operazioni MADD che troverà in FMA.
Ed è il motivo per cui parlano di operazione "for free". Esiste un costo, ma viene mascherato dal fatto che nessuno si accorgerà di un caricamento di qualche secondo più lento, al peggio.
Quello che sostiene yossarian è che però tale operazione non può essere fatta in maniera così massiccia, perchè il thread processor può operare le sostituzioni solo sulle porzioni di codice (suppongo porzioni molto limitate) che si trovano nei suoi buffer.
Questo comporta che in realtà tale sostituzione venga fatta quasi "on the fly", comportando un costo prestazionale di un certo rilievo, che può essere mascherato in qualche modo, come anche no.

yoss non fustigarmi se ho sbagliato...

non hai sbagliato, anche se non so per quale ragione Rys pensi che sia for free. Non credo che sia convinto che le sostituzioni siano fatte at compile time quanto piuttosto che il massiccio multithresding potrà mascherare le latenze delle operazioni di sostituzione. Se è così, dicimao che non ha tutti i toriti nel senso che l'operazione non sarà comunque for free ma la gestione di tanti thread in sìimultanea e la latenza di altre operazioni (penso a quelle di texturing, ad esempio) renderà meno evidenti questi ritardi.
Il fatto è che si tende spesso a parlare a sproposito di operazioni for free e ho voluto puntualizzare che le cose non stanno così (d'altra parte, anche nell'ultimo articolo ho criticato la tesi che una madd equivale ad una moltiplicazione e ad un'addizione in un singolo ciclo. Le cose non stanno proprio così (visto che un'addizione può richiedere da 5 a 7 cicli ad esempio )

[Jackaos]

Quindi, dando per buoni i calcoli fatti da HW.fr basati sulle informazoni architetturali che nVidia ha rilasciato fin'ora e che ipotizzano una moderata potenza computazionale di fermi in single precision, considerando che anche ad alte frequenze di lavoro da parte dei CUDA cores questa potenza non aumenti di molto o perlomeno non come vorremmo augurarci che sia, considerando inoltre che benchè nVidia abbia portato avanti più di tutto il resto l'argomento GPGPU e che abbia parlato della prossima propria scheda come un mostro di potenza calcolatrice per quest'ambito ha anche promosso in continuazione le sue tecnologie per i videogiochi ( Physx e 3DVision) e secondo alcune recenti dichiarazioni ha precisato che non abbandonerà i videogiocatori e che questi potranno stare tranquilli e divertirsi cone le sue nuove schede video, e considerando ancora che non stanno di sicuro riprogettando tutto e che grosso modo la frittata è fatta, quale potrebbe essere la soluzione affinchè "Fermi" non si trasformi in un avvertenza per i videogiocatori che stanno frugando nel portafoglio per comprarsi le suddette schedozze? Insomma, so che non siete ingegneri nVidia, e nemmeno avete la sfera di cristallo, ma pensate davvero che questa generazione di gpu sarà un mezzo flop per questa società? Che abbiano davvero sbagliato tutto? o che siano partiti per crerare qualcosa che poi si sono accorti non potrà andare come speravano?

[skizzo99999999]

Originariamente inviato da yossarian

non pretendo che lo si conosca. Non credo che qualcuno di noi possa vantarsi di qualcosa del genere. L'unica cosa che chiedo è che si stiano a sentire anche le ragioni dell'altro, senza ragionare per partito preso.
Discutendo con calma, tra persone intelligenti, si trova sempre un punto di incontro

Beh almeno concedimi che ti abbia sempre ascoltato, è tutta la sera che posto!
Quello che non capisco è, tanto per fare un'altro esempio, che cosa NVIDIA debba conoscere di approfondito sulla CPU per scrivere un compilatore (che esegue quindi le istruzioni e le ottimizzazione per cui è stato programmato) che compili dei sorgenti che dovranno poi essere eseguiti non sulla CPU intel, ma su una GPU NVIDIA.
Andando ancora + sul pratico: ho uno shader composto da a.fs e a.vs (fragment e vertex), ovviamente testuali, che do in pasto ad un compilatore che ho scritto io (facendo una ipotesi assurda che potessi scrivere un compilatore), per esempio gpu.exe, e che restituisce un codice out.dat che sia il linguaggio della mia GPU che ho progettato. Cosa c'è di difficoltoso (a parte l'ovvio...)? non mi sembra che per scrivere un programma x86 i programmatori di mezzo mondo conoscnao la cpu intel come un igegnere intel, ed un compilatore che deve generare codice NON per l'architettura INTEL non mi sembra diverso da un qualsiasi altro software...

EDIT: hai letto la citazione dal libro che ho scritto poco sopra?

[yossarian]

Originariamente inviato da Jackaos

Quindi, dando per buoni i calcoli fatti da HW.fr basati sulle informazoni architetturali che nVidia ha rilasciato fin'ora e che ipotizzano una moderata potenza computazionale di fermi in single precision, considerando che anche ad alte frequenze di lavoro da parte dei CUDA cores questa potenza non aumenti di molto o perlomeno non come vorremmo augurarci che sia, considerando inoltre che benchè nVidia abbia portato avanti più di tutto il resto l'argomento GPGPU e che abbia parlato della prossima propria scheda come un mostro di potenza calcolatrice per quest'ambito ha anche promosso in continuazione le sue tecnologie per i videogiochi ( Physx e 3DVision) e secondo alcune recenti dichiarazioni ha precisato che non abbandonerà i videogiocatori e che questi potranno stare tranquilli e divertirsi cone le sue nuove schede video, e considerando ancora che non stanno di sicuro riprogettando tutto e che grosso modo la frittata è fatta, quale potrebbe essere la soluzione affinchè "Fermi" non si trasformi in un avvertenza per i videogiocatori che stanno frugando nel portafoglio per comprarsi le suddette schedozze? Insomma, so che non siete ingegneri nVidia, e nemmeno avete la sfera di cristallo, ma pensate davvero che questa generazione di gpu sarà un mezzo flop per questa società? Che abbiano davvero sbagliato tutto? o che siano partiti per crerare qualcosa che poi si sono accorti non potrà andare come speravano?

dalle informazioni che ho, pare che nVidia abbia implementato pipleine di tipo fma, il che significa che per eseguire una madd tradizionale ha bisogno di 2 passate, il che dimezza la potenza disponibile. C'è la possibilità tutta da esplorare, di sostituire le madd con le fma (in passato ha fatto di peggio; con nv30 ha sostituito intere righe di codice passando da dx9 a dx8), in questo caaso si tratta solo di cambiare il modo di fare una moltiplicazione seguita da una divisione. E' un'operazione che può presentare delle incognite. Non si sa se sarà sempre possibile e, in caso contrario, si rischia di vedere un frame rate ballerino. Diciamo che questo e la presenza o meno del tessellatro in hardware sembrerebbero le uniche due incognite di fermi.
Dalle scelte fatte, se fossero confermate, mi sentirei di dire che è un chip molto più votato al gpgpu che non al gaming ma che si può difendere bene anche negli altri ambiti.
Altra incignita, ovviamente, il prezzo

[Kharonte85]

Originariamente inviato da Jackaos

Quindi, dando per buoni i calcoli fatti da HW.fr

Veramente è proprio qui il problema...

Originariamente inviato da Jackaos

basati sulle informazoni architetturali che nVidia ha rilasciato fin'ora e che ipotizzano una moderata potenza computazionale di fermi in single precision, considerando che anche ad alte frequenze di lavoro da parte dei CUDA cores questa potenza non aumenti di molto o perlomeno non come vorremmo augurarci che sia, considerando inoltre che benchè nVidia abbia portato avanti più di tutto il resto l'argomento GPGPU e che abbia parlato della prossima propria scheda come un mostro di potenza calcolatrice per quest'ambito ha anche promosso in continuazione le sue tecnologie per i videogiochi ( Physx e 3DVision) e secondo alcune recenti dichiarazioni ha precisato che non abbandonerà i videogiocatori e che questi potranno stare tranquilli e divertirsi cone le sue nuove schede video, e considerando ancora che non stanno di sicuro riprogettando tutto e che grosso modo la frittata è fatta, quale potrebbe essere la soluzione affinchè "Fermi" non si trasformi in un avvertenza per i videogiocatori che stanno frugando nel portafoglio per comprarsi le suddette schedozze? Insomma, so che non siete ingegneri nVidia, e nemmeno avete la sfera di cristallo, ma pensate davvero che questa generazione di gpu sarà un mezzo flop per questa società? Che abbiano davvero sbagliato tutto? o che siano partiti per crerare qualcosa che poi si sono accorti non potrà andare come speravano?

A parte che ho rischiato di soffocare mentre leggevo il tuo post (la punteggiatura!)

Mi sbaglierò anche ma personalmente credo semplicemente che alla Nvidia non siano esattamente così sprovveduti come questi ritardi e come queste speculazioni ci porterebbero a pensare...fanno GPU da decenni, sono i leader (fino a prova contraria) del mercato GPU desktop non credo vogliano abbandonare con tanta leggerezza questo mercato.

Se invece all'uscita di gf100 si dimostrerà che hanno sbagliato davvero tutto (anche se rimarrebbero intatte le potenzialità del chip in GPUcomputing), pazienza...vedremo di meglio al prossimo giro (è già successo).


@yoss: hanno cancellato la costituzione! (il link in firma non va)

[Jackaos]

Ah ah, scusa per il soffocamento. Di sicuro volevano prendere due piccioni con una fava, speriamo che non ne abbiano presi solo uno e mezzo e che ci tocchi il mezzo o peggio la fava .