[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[maurilio968]

Originariamente inviato da Defragg

Ci stiamo prendendo solo limoni

OT

e continueremo a prenderne se non cambia la proprietà di questa squadra.

Per lo stato attuale potremmo adottare nvidia come sponsor ufficiale ed
andare in giro con la scitta "FERMI" sulle magliette.

Fine OT

[skizzo99999999]

Originariamente inviato da yossarian

nessuno ha mai negato che il driver contenga istruzioni per la cpu. Semmai è il contrrio; quello che sostengo è che la cpu non fa una cippa di ottimizzazione all'atto della compilazione e che il driver contiene anche istruzioni per la gpu e sono questa a contenere le ottimizzazioni.

ah si? veramente qui

Originariamente inviato da yossarian

il driver della gpu che agisce sulla cpu? Non credo proprio . La cpu non si occupa di rendering ma solo di inviare i dati iniziali sui vertici del frame e, al massimo, di fisica e IA; e poi non ha senso anche solo pensare che il driver di una periferica agisca su un'altra.

e qui

Originariamente inviato da yossarian

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

e qui

Originariamente inviato da yossarian

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

e qui

Originariamente inviato da yossarian

Tornando a quanto detto prima, nVidia non si prenderà mai la briga di scrivere un compilatore per hlsl di tipo, diciamo "standard", di quelli integrati nel s.o. e basati sulle api di riferimento, Non potrà mai scrivere un tool che "faccia lavorare" per le sue gpu le cpu intel o amd ottimizzando per loro (dovrebbe conoscerne le architetture e scriverne uno per ciascuna; in pratica dovrebbe scrivere dei driver per cpu

e soprattutto qui

Originariamente inviato da yossarian

A questo punto, le ottimizzazioni per il chip grafico può farle solo il chip grafico guidato dai suoi driver (driver significa, appunto, conducente, guidatore, colui che guida, ecc). Ora, salvo pensare che questi driver (del chip grafico) non pilotino anche la cpu, verrebbe spontaneo immaginare che, in questo universo e in questo tempo (cosa accada in universi paralleli sfugge al controllo dei nostri sensi) sia la gpu a fare le ottimizzazioni relative.

sicuramente me ne sono sfuggite altre ma queste bastano e avanzano. Può anche darsi che ti sei spiegato male, tutte le volte. Ritornando al nostro solito (...) argomento, per prima cosa linko il documento in modo che chi se lo voglia leggere integralmente lo possa fare facilmente:

http://www.capsl.udel.edu/conference...Papers/101.doc

Mi sembra buona norma linkare le fonti, in modo che se c'è qualche volenteroso che ha voglia/tempo/capacità per capire lo possa fare senza sbattersi. Tanto se ho le citazioni vuol dire che ho il documento, per cui linkarlo non mi costa nulla.
Bisogna dire subito che questo paper è riferito a CUDA, e quindi con la grafica non centra nulla. Proprio nulla no ma ci siamo capiti. Conseguenza diretta di questo è che tutte le considerazioni sono riferite alla programmazione general purpose e non ai linguaggi di shading. Infatti già nella prima citazione questa caratteristica emerge subito; se invece di partire da quel punto si legge anche la frase prima, già molte cose risultano più chiare a chi legge:

"CUDA provides a few simple extensions to C/C++ that enables users to specify what part of their program they want to run in parallel on a GPU. The CUDA compiler driver splits an application into two parts, one which is run on the host CPU, and the other which is run on the GPU."

Qua si sta parlando di codice c/c++, quindi assolutamente impossibile da eseguire per qualsiasi GPU. Infatti NVIDIA a fatto delle estensioni al c grazie alle quali il programmatore definisce le parti di codice che, adottando comunque sempre una sintassi c-like, possano essere possibili da eseguire dalle GPU. E quindi il codice viene diviso in 2 parti: quello "normale" che il programmatore ha deciso che sarà eseguito dalla CPU e che segue una via più tradizionale, e quello da dare in pasto tramite CUDA alla GPU.
Anche questo codice però non è gestibile direttamente così com'è (e non sto parlando del fatto che sia un sorgente e non compilato), a causa del possibile/probabile uso di strutture dati/costrutti che la GPU non può eseguire. L'esempio più banale che mi viene in mente è, ad esempio che il GLSL supporta soltanto (almeno fino alle opengl 2.1, ma non credo che dopo la situazione cambi radicalmente, e anche se cambiasse visto che gli shader c'erano anche con le directx9 e opengl 2.1, il discorso deve essere valido) vettori di 4 elementi o matrici fino a 4x4. Dimensioni ridicole per codice general purpose. Ovviamente ci sono le texture, che presumo siano, come negli shader, la via maestra per passare i dati alla GPU; però siccome in c le texture non ci sono e nella GPU "lavorano" in maniera diversa rispetto a semplici array, bisogna usarle in modo adeguato. Da questo derivano considerazioni circa l'inadeguatezza del compilatore usato finora per la grafica e quindi gli shader:

"NVIDIA already had a well-tuned low-level compiler for graphics codes, called OCG (Optimized Code Generator). This handles register allocation, scheduling, and peephole optimizations. This compiler is built into the graphics driver for doing just-in-time compilation of graphic codes. Because graphics codes tend to be relatively simple compared to general purpose C code (control flow has only recently been added to DirectX), and due to the compile-time limitations of needing to compile at runtime, it was decided that CUDA needed a high-level optimizer to handle the compute codes."

Infatti dice che essendo il "graphics code" semplice rispetto al "general purpose C code" (fa riferimento pure al fatto che solo recentemente nel HLSL delle directx è stato inserito l'if-then-else, questo per farvi capire di che dimensione di semplicità stiamo parlando), il compilatore risulta inadeguato e quindi hanno dovuto piazzarci in mezzo qualcosa d'altro. Veniamo ora a due belle cosette: la prima è Il riferimento alla compilazione just-in-time che di primo acchito può essere fourviante, ma anche qui basta ragionarci un po per capire meglio. Il primo dubbio può venire già dal nome just-in-time (al volo), che sembra non lasciare scampo. Per questo è forse sufficiente anche una lettura da wikipedia (inglese) che però non so se basta se si parte a digiuno con l'argomento. Questi compilatori sono utilizzati solitamente per migliorare le prestazioni dei linguaggi INTERPRETATI, cioè che non sono compilati nativamente per la macchina su cui l'applicazione viene eseguita, ma che vengono compilati in, ad esempio, bytecode. Questo codice viene quindi letto dall'interprete che, al volo, lo traduce in linguaggio macchina da eseguire. Che vantaggi comporta tutto ciò? semplice: se scrivo un programma e lo compilo in bytecode, basta avere un interprete di bytecode per ogni piattaforma su cui vorrò fare girare il programma che esso potrà girare senza bisogno di ricompilarlo. Quindi è possibilie scrivere un programma che giri su osx, linux windows, ecc... Un esempio è JAVA. Problemi? prestazioni pestilenziali. E allora? arriva in aiuto la compilazione just-in-time che provvede, durante l'avvio del programma, a compilare il programma da bytecode a codice macchina in modo che, dopo un primo avvio più lento rispetto con un interprete classico, il programma risulti moooolto più svelto (vi ricorda qualcosa questo comportamento?). Assodato che quindi il termine just-in-time non significa quello che può sembrare ad un primo sguardo, passo ora ala seconda considerazione, in cui si fa riferimento ai limiti della compilazione a run-time. Anche qui la questione è chiara: gli shader hanno pochi tipi di dati e semplici, pochi costrutti e sono PICCOLI, cioè composti da poche righe, il tutto ovviamente rapportato a quante linee di codice potrebbe contenere un normale programma, magari commerciale/professionale in ambito, per esempio, di calcolo scientifico. Nei giochi infatti si parla di programmi che devono terminare il loro ciclo di esecuzione anche un centinaio di volte al secondo (i nostri cari fps) di cui per giunta non tutto il tempo è speso in calcoli della GPU, mentre in un classico programma una "operazione" può richiedere un tempo nettamente più lungo, e qui mi sento che di esempi non ne servono. Chiunque poi abbia programmato in linguaggi tipo c/c++ visual basic ecc... sa che in progetti anche di piccole dimensioni la compilazione non è assolutamente una operazione istantanea. Quindi ci si può immaginare se sia di buon auspicio per un cliente avere un tempo di attesa nel lanci dell'applicativo che non si misura certo in frazioni di secondo...
Per cui si è reso necessario un ulteriore stadio di compilazione che potesse rendere il lavoro per il compilatore del Just-in-time del driver sopportabile (quindi in tempi "ragionevoli"). E' da qui che nasce tutto il discorso su Open64 e via discorrendo cosa che quindi non centra assolutamente nulla con il tema del contendere. Tra l'altro in questo caso si tratta proprio di cercare di compilare in maniera "definitiva" la maggior parte del codice (cioè lo fa una volta lo sviluppatore e poi basta), in modo che il grosso del lavoro venga fatto prima di dover utilizzare, ad ogni avvio, il compilatore Just-in-time del driver.
Risulta ora anche chiaro il riferimento alla difficoltà di farlo questo compilatore, con la scelta di optare per implementare una derivazione di Open64: bisogna infatti adattare il dataset del linguaggio c-like a quello per forza di cose ridotto delle GPU. E' sempre riguardo a questo è anche il riferimento a PTX:

"The GPU input is then processed by our Open64 compiler (called nvopencc), which emits an assembly language that we created called PTX (Parallel Thread Execution). PTX provides a virtual machine model that multiple tools can target, and which is independent of the underlying processor. Some important features of PTX are that it has:
• unlimited virtual registers of different sizes,
• explicit memory segments for different levels of sharing between threads,
• no stack or heap,
• strongly typed instructions,
• vector support for memory accesses,
• predication for branching,
• C-like syntax for calls."

Serve infatti come interfaccia al nostro Just-in-time per rendergli il tutto digeribile.

Concludendo (...), non mi sembra che ci sia niente di nuovo su cui discutere. Adesso spero che se qualcuno avesse avuto delle difficoltà a capire la differenza tra interprete e compilatore ora abbia le idee più chiare.

[Sealea]

ragazzi, news importanti su date?

[yossarian]

Originariamente inviato da skizzo99999999

ah si? veramente qui



e qui



e qui



e qui



e soprattutto qui



sicuramente me ne sono sfuggite altre ma queste bastano e avanzano. Può anche darsi che ti sei spiegato male, tutte le volte. Ritornando al nostro solito (...) argomento, per prima cosa linko il documento in modo che chi se lo voglia leggere integralmente lo possa fare facilmente:

http://www.capsl.udel.edu/conference...Papers/101.doc

Mi sembra buona norma linkare le fonti, in modo che se c'è qualche volenteroso che ha voglia/tempo/capacità per capire lo possa fare senza sbattersi. Tanto se ho le citazioni vuol dire che ho il documento, per cui linkarlo non mi costa nulla.
Bisogna dire subito che questo paper è riferito a CUDA, e quindi con la grafica non centra nulla. Proprio nulla no ma ci siamo capiti. Conseguenza diretta di questo è che tutte le considerazioni sono riferite alla programmazione general purpose e non ai linguaggi di shading. Infatti già nella prima citazione questa caratteristica emerge subito; se invece di partire da quel punto si legge anche la frase prima, già molte cose risultano più chiare a chi legge:

"CUDA provides a few simple extensions to C/C++ that enables users to specify what part of their program they want to run in parallel on a GPU. The CUDA compiler driver splits an application into two parts, one which is run on the host CPU, and the other which is run on the GPU."

Qua si sta parlando di codice c/c++, quindi assolutamente impossibile da eseguire per qualsiasi GPU. Infatti NVIDIA a fatto delle estensioni al c grazie alle quali il programmatore definisce le parti di codice che, adottando comunque sempre una sintassi c-like, possano essere possibili da eseguire dalle GPU. E quindi il codice viene diviso in 2 parti: quello "normale" che il programmatore ha deciso che sarà eseguito dalla CPU e che segue una via più tradizionale, e quello da dare in pasto tramite CUDA alla GPU.
Anche questo codice però non è gestibile direttamente così com'è (e non sto parlando del fatto che sia un sorgente e non compilato), a causa del possibile/probabile uso di strutture dati/costrutti che la GPU non può eseguire. L'esempio più banale che mi viene in mente è, ad esempio che il GLSL supporta soltanto (almeno fino alle opengl 2.1, ma non credo che dopo la situazione cambi radicalmente, e anche se cambiasse visto che gli shader c'erano anche con le directx9 e opengl 2.1, il discorso deve essere valido) vettori di 4 elementi o matrici fino a 4x4. Dimensioni ridicole per codice general purpose. Ovviamente ci sono le texture, che presumo siano, come negli shader, la via maestra per passare i dati alla GPU; però siccome in c le texture non ci sono e nella GPU "lavorano" in maniera diversa rispetto a semplici array, bisogna usarle in modo adeguato. Da questo derivano considerazioni circa l'inadeguatezza del compilatore usato finora per la grafica e quindi gli shader:

"NVIDIA already had a well-tuned low-level compiler for graphics codes, called OCG (Optimized Code Generator). This handles register allocation, scheduling, and peephole optimizations. This compiler is built into the graphics driver for doing just-in-time compilation of graphic codes. Because graphics codes tend to be relatively simple compared to general purpose C code (control flow has only recently been added to DirectX), and due to the compile-time limitations of needing to compile at runtime, it was decided that CUDA needed a high-level optimizer to handle the compute codes."

Infatti dice che essendo il "graphics code" semplice rispetto al "general purpose C code" (fa riferimento pure al fatto che solo recentemente nel HLSL delle directx è stato inserito l'if-then-else, questo per farvi capire di che dimensione di semplicità stiamo parlando), il compilatore risulta inadeguato e quindi hanno dovuto piazzarci in mezzo qualcosa d'altro. Veniamo ora a due belle cosette: la prima è Il riferimento alla compilazione just-in-time che di primo acchito può essere fourviante, ma anche qui basta ragionarci un po per capire meglio. Il primo dubbio può venire già dal nome just-in-time (al volo), che sembra non lasciare scampo. Per questo è forse sufficiente anche una lettura da wikipedia (inglese) che però non so se basta se si parte a digiuno con l'argomento. Questi compilatori sono utilizzati solitamente per migliorare le prestazioni dei linguaggi INTERPRETATI, cioè che non sono compilati nativamente per la macchina su cui l'applicazione viene eseguita, ma che vengono compilati in, ad esempio, bytecode. Questo codice viene quindi letto dall'interprete che, al volo, lo traduce in linguaggio macchina da eseguire. Che vantaggi comporta tutto ciò? semplice: se scrivo un programma e lo compilo in bytecode, basta avere un interprete di bytecode per ogni piattaforma su cui vorrò fare girare il programma che esso potrà girare senza bisogno di ricompilarlo. Quindi è possibilie scrivere un programma che giri su osx, linux windows, ecc... Un esempio è JAVA. Problemi? prestazioni pestilenziali. E allora? arriva in aiuto la compilazione just-in-time che provvede, durante l'avvio del programma, a compilare il programma da bytecode a codice macchina in modo che, dopo un primo avvio più lento rispetto con un interprete classico, il programma risulti moooolto più svelto (vi ricorda qualcosa questo comportamento?). Assodato che quindi il termine just-in-time non significa quello che può sembrare ad un primo sguardo, passo ora ala seconda considerazione, in cui si fa riferimento ai limiti della compilazione a run-time. Anche qui la questione è chiara: gli shader hanno pochi tipi di dati e semplici, pochi costrutti e sono PICCOLI, cioè composti da poche righe, il tutto ovviamente rapportato a quante linee di codice potrebbe contenere un normale programma, magari commerciale/professionale in ambito, per esempio, di calcolo scientifico. Nei giochi infatti si parla di programmi che devono terminare il loro ciclo di esecuzione anche un centinaio di volte al secondo (i nostri cari fps) di cui per giunta non tutto il tempo è speso in calcoli della GPU, mentre in un classico programma una "operazione" può richiedere un tempo nettamente più lungo, e qui mi sento che di esempi non ne servono. Chiunque poi abbia programmato in linguaggi tipo c/c++ visual basic ecc... sa che in progetti anche di piccole dimensioni la compilazione non è assolutamente una operazione istantanea. Quindi ci si può immaginare se sia di buon auspicio per un cliente avere un tempo di attesa nel lanci dell'applicativo che non si misura certo in frazioni di secondo...
Per cui si è reso necessario un ulteriore stadio di compilazione che potesse rendere il lavoro per il compilatore del Just-in-time del driver sopportabile (quindi in tempi "ragionevoli"). E' da qui che nasce tutto il discorso su Open64 e via discorrendo cosa che quindi non centra assolutamente nulla con il tema del contendere. Tra l'altro in questo caso si tratta proprio di cercare di compilare in maniera "definitiva" la maggior parte del codice (cioè lo fa una volta lo sviluppatore e poi basta), in modo che il grosso del lavoro venga fatto prima di dover utilizzare, ad ogni avvio, il compilatore Just-in-time del driver.
Risulta ora anche chiaro il riferimento alla difficoltà di farlo questo compilatore, con la scelta di optare per implementare una derivazione di Open64: bisogna infatti adattare il dataset del linguaggio c-like a quello per forza di cose ridotto delle GPU. E' sempre riguardo a questo è anche il riferimento a PTX:

"The GPU input is then processed by our Open64 compiler (called nvopencc), which emits an assembly language that we created called PTX (Parallel Thread Execution). PTX provides a virtual machine model that multiple tools can target, and which is independent of the underlying processor. Some important features of PTX are that it has:
• unlimited virtual registers of different sizes,
• explicit memory segments for different levels of sharing between threads,
• no stack or heap,
• strongly typed instructions,
• vector support for memory accesses,
• predication for branching,
• C-like syntax for calls."

Serve infatti come interfaccia al nostro Just-in-time per rendergli il tutto digeribile.

Concludendo (...), non mi sembra che ci sia niente di nuovo su cui discutere. Adesso spero che se qualcuno avesse avuto delle difficoltà a capire la differenza tra interprete e compilatore ora abbia le idee più chiare.

invece io non sto a perdere tempo a quotare tutte le vollte che hai asserito che il compilatore si occupa di effettuare le sostituzioni di cui si sta parlando e che sono l'oggetto del contendere (basta tornare indietro di qualche pagina) né quante volte hai affermato che gli hw vendor si scrivono compilatori ottimizzati per i loro device (nVidia ti dimostra che neppure per cuda, un loro "sistema" proprietario, si sono fatti un compilatore ad hoc ma si appogginao a compilatori standard) e neppure quante volte hai affermato che non aveva senso un doppio stadio di compilazione con ottimizzazioni a valle quando si poteva fare tutto insieme. Dal link che hai riportato è evidente che nVidia non ha modificato o scritto compilatori ad hoc né per cuda né per le gpu ante dx10 ma che ha semplicemente introdotto delle ottimizzazioni a valle delle operazioni di complazione, utilizzndo compilatori standard (cosa che hai ripetutamente negato, arrivando persino a prospettare modifiche al compilatore hlsl di windows).
CUDA non c'entra niente con la grafica? CUDA non è solo GPGPU ma un insieme di architettura SW e microarchitettura HW e serve per ottimizzare anche le operazioni grafiche su gpu (mi spieghi cosa c'entrerebbe, ad esempio, la gestione delle operazioni su texture e la loro allocazione in memoria con applicazioni di tipo gpgpu?). E comunque, grazie ai tool messi a disposizione con cuda ci si può fare un'idea di quelle che sono le operazioni possibili su una gpu (e le preephole optimization rientrano tra queste).
Inoltre, visto che l'oggetto del contendere sono le ottimizzazioni e non la compilazione (mi dici, ripeto, dove avrei scritto che la compilazione è a carico della gpu?) e, in particolare le sostituzioni di MADD con FMA e che queste si effettuano facendo uso di preephole e su linguaggio binario (la cpu può effettuare la traduzione del codice dei prephole, semmai), ti invito a dare un'occhiata a questo link, con l'avvertenza che si tratta di una versione vecchia di cuda e non si quella destinata a girare su Fermi (che non è detto che sia retrocompatibile e, sicuramente, non lo sarà in toto con le gpu dx10).
http://moss.csc.ncsu.edu/~mueller/cl...a/GPU+CUDA.pdf

dove, a pagina 30, riporta, tra le operazioni svolte a runtime dal device (GPU) le atomic ops, tra cui and, or e confronti tra interi, che servono per eseguire preephole optimization. Le atomic operation sono state introdotte con l'adozione dei compute shader 4.0 (DX10).
Qui, invece, parla dell'adozione di vere e proprie cache (non le L1 e L2 dei chip fino a GT200 che sono solo texture cache) per poter eseguire atomic operations direttamente on chip senza dover accedere continuamente alla vram
http://www.behardware.com/articles/7...evolution.html
e qui dell'adozione di puntatori (con CUDA 3.0 e PTX2.0, scritti appositamente per Fermi).
http://www.behardware.com/articles/7...evolution.html

Dalla tua invocata wikipedia
http://it.wikipedia.org/wiki/Compilatore_just-in-time

riporto testualmente

In un ambiente JIT la prima fase è costituita dalla compilazione del bytecode, in cui si trasforma il codice sorgente in una rappresentazione intermedia portabile e ottimizzabile, detta appunto bytecode. Successivamente il codice bytecode viene installato sul sistema di destinazione. Quando il codice viene eseguito, il compilatore dell'ambiente di esecuzione lo traduce in codice macchina nativo. La traduzione in codice macchina può avvenire per file o per funzione: le funzioni possono essere compilate solo quando stanno per essere eseguite, da qui il nome just-in-time, ovvero "appena in tempo".

La compilazione just-in-time permette di ottenere un buon compromesso tra velocità d'esecuzione e portabilità del codice. Nella fase di compilazione del bytecode è eseguita la maggior parte del "lavoro pesante", ovvero tutte quelle operazioni che richiedono molto tempo per essere eseguite, come l'analisi sintattica e semantica del codice sorgente e una prima fase di ottimizzazione; la compilazione da bytecode a codice nativo è invece molto più veloce. I compilatori da bytecode a codice macchina (tra cui, appunto, i sistemi JIT) sono più semplici da scrivere perché la maggior parte del lavoro è già stata compiuta dal compilatore che ha prodotto il bytecode; questo, inoltre, rende i programmi in bytecode più facilmente portabili su nuove architetture.

Insomma, secondo le schema di nVidia, c'è un compilatore STANDARD che fa la compilazione in bytecode (chi ha detto che non c'è il compilatore standard?). In questa fase si suole fare le ottimizzazioni ma, abbiamo visto, secondo lo schema adottato da nVidia le cose non stanno così, dato che l'OCG che si occupa delle ottimizzazioni, è a valle della PTX che fa traduzione JIT.
Infine la traduzione JIT prevede che le funzioni siano tradotte al momento in cui stanon essere eseguite (e nel caso di nVidia tradotte e ottimizzate, aggiungerei). Questo significa che la cpu non invia codice già bello e pronto prima dell'esecuzione, perchè il codice bello e pronto arriva solo dopo la compilazione JIT. Se se ne occupa la cpu significa che ciò comporta un traffico continuo tra cpu, ram di sistema, vram e gpu che è prorpio quello che i progettisti di gpu stanno cercando da alcuni anni di evitare come la peste (trasferimento in batch di migliaia di vertici invece di singoli triangoli, texture e cube map array, ecc). Sai cosa me ne frega di quant'è veloce una cpu a fare la sostituzione se poi quell'istruzione arriva alla gpu dopo due giorni? Non si può teorizzare senza avere bene in mente il sistema fisico su cui si deve operare e i suoi colli di bottiglia (e il canale tra cpue gpu, nonostante il pci-express, è uno dei peggiori).
Quindi la sostituzione di madd con fma, semmai si farà e se sarà possibile, sarà fatta in runtime dalla gpu e direttamente on chip. (come sto dicendo da 10 pagine), dal momento che fermi, a detta della stessa nVidia, pare perfettamente in grado di fare preephole optimizzation direttamente on chip.

[ilcose]

Originariamente inviato da Sealea

ragazzi, news importanti su date?

mmm non credo se non si trovano sui maggiori siti di hw.. (quindi escluso fudzilla che la dava x gennaio in step A3) XD

in effetti è qualche settimana che non si hanno notizie.

[Andrea deluxe]

Originariamente inviato da Ratatosk

nVidia dice Gennaio.

Se lo stepping A2 funziona è possibile con disponibilità irrisorie giusto per la stampa e reale disponibilità in febbraio.

Se come si dice da alcune fonti non confermate è nessaria una versione A3 è possibile che la presentazione venga comunque fatta per la stampa con la A2 a gennaio, ma per vederle sugli scaffali toccherà aspettare almeno fine marzo nella migliore delle ipotesi, giugno nella peggiore, obiettivamente fra aprile e maggio sempra l'ipotesi più consistente.

e perché ci vorrebbe tutto sto tempo?

[Sealea]

Originariamente inviato da Ratatosk

nVidia dice Gennaio.

Se lo stepping A2 funziona è possibile con disponibilità irrisorie giusto per la stampa e reale disponibilità in febbraio.

Se come si dice da alcune fonti non confermate è nessaria una versione A3 è possibile che la presentazione venga comunque fatta per la stampa con la A2 a gennaio, ma per vederle sugli scaffali toccherà aspettare almeno fine marzo nella migliore delle ipotesi, giugno nella peggiore, obiettivamente fra aprile e maggio sempra l'ipotesi più consistente.

ok grazie... nvidia, ci vediamo al prossimo giro

[dj883u2]

Oggi a Milano.....ore 16.00.....Nvidia....speriamo bene.

[konzendoji]

Originariamente inviato da Sealea

ok grazie... nvidia, ci vediamo al prossimo giro

io mi tengo la mia giusto perchè ho 1gb di ram
cmq fai bene...sono d'accordo con te...nVidia se lo merita di perdere fette di mercato!
I propri clienti li considera meno di quella cosa che si pesta accidentalmente ai giardinetti...

E poi è l'ora che perda un po', giusto per rimboccarsi le maniche e per mettere prezzi decenti

[Bastoner]

Originariamente inviato da Ratatosk

PhysX, 3DVision, FTW, KickAss?

Lol
Kickass fa ridere

[konzendoji]

Originariamente inviato da Ratatosk

PhysX, 3DVision, FTW, KickAss?

In effetti non so cosa possa presentare nvidia oggi alle 16:00 a milano

Originariamente inviato da konzendoji

In effetti non so cosa possa presentare nvidia oggi alle 16:00 a milano

fanno una presentazione sulle vecchie glorie fino alla 8800!

[Pelvix]

Originariamente inviato da atomo37

fanno una presentazione sulle vecchie glorie fino alla 8800!

Si, test in anteprima della NUOVISSIMA nvidia TNT con 16 MB di sdram onboard!!!
A sto giro ha fatto veramente una figura da cioccolataia che metà basta...

[Psyco89]

Originariamente inviato da Ratatosk

PhysX, 3DVision, FTW, KickAss?

bisogna vedere cosa succede se poi alla fine esce e fa il sedere a tutti come reagirà la clientela ?

[Pelvix]

Originariamente inviato da Psyco89

bisogna vedere cosa succede se poi alla fine esce e fa il sedere a tutti come reagirà la clientela ?

Si, vabbè, ma se vanno avanti così ora che esce sarà diventato obsoleto proprio il concetto di VGA...

Non è che se arrivano un anno dopo c'è poi da stupirsi che vada più forte, e ci mancherebbe altro...

No no, per me sto giro hanno fatto proprio una gran bella figuraccia, e da nvidia-ista da ani, mi sa che stavolta li mollo..

[paolox86]

E' si, che vuoi che presentino a Milano.... Probabilmente dimostreranno che, basandosi sulle configurazioni hardware medie degli italiani, il loro prodotto che si addice meglio per non essere CPU limited è il Geforce 4 Ti 4600

[Legolas84]

Originariamente inviato da Pelvix

Si, vabbè, ma se vanno avanti così ora che esce sarà diventato obsoleto proprio il concetto di VGA...

Non è che se arrivano un anno dopo c'è poi da stupirsi che vada più forte, e ci mancherebbe altro...

No no, per me sto giro hanno fatto proprio una gran bella figuraccia, e da nvidia-ista da ani, mi sa che stavolta li mollo..

nvidia-ista da ani...... lol chissà che mestiere è

[Pelvix]

Originariamente inviato da Legolas84

nvidia-ista da ani...... lol chissà che mestiere è

AZZ!! Che erroraccio..
Sorry....
Comunque no, non è quel mestiere li...
Vabbè che in sto periodo va di moda eh, però però...

[skizzo99999999]

Originariamente inviato da yossarian

invece io non sto a perdere tempo a quotare tutte le vollte che hai asserito che il compilatore si occupa di effettuare le sostituzioni di cui si sta parlando e che sono l'oggetto del contendere (basta tornare indietro di qualcje pagina) né quante volte hai affermato che gli hw vendor si scrivono compilatori ottimizzati per i loro device.

io ho quotato perchè tu avevi negato di avere detto che il driver non poteva pilotare la CPU. Io invece non nego affatto quello che ho riportato sopra, anzi è proprio questo (come hai detto) l'oggetto del contendere, quindi che significato ha negarlo da parte mia? se lo negassi, automaticamente sarei daccordo con te e non posterei più. Quindi confermo, che il compilatore all'interno del driver si occupa di fare le sostituzioni e che gli hw vendor si scrivono compilatori ottimizzati per i loro device (quello che nei post precendenti abbiamo chiamato il compilatore just-in-time). Non mi sembra necessario ribadirlo tutte le volte, visto che non ho cambiato idea.

Originariamente inviato da yossarian

Dal link che hai riportato è evidente che nVidia non ha modificato o scritto compilatori ad hoc né per cuda né per le gpu ante dx10 ma che ha semplicemente introdotto delle ottimizzazioni a valle delle operazioni di complazione, utilizzndo compilatori standard (cosa che hai ripetutamente negato, arrivando persino a prospettare modifiche al compilatore hlsl di windows).

Dal link che ho riportato (che è solo il documento completo da cui avevi prima perso le citazioni tu in precedenza) è spiegato che NVIDIA ha modificato adattato open64. Non so se sono i termini più appropriati, ma non penso che gli sia andato perfetto open64, visto che viene detto "We use a subset of Open64" e quindi almeno un taglia e cuci lo hanno fatto, ma non mi sembra che per i nostri scopi si debba andare in dettaglio su questo aspetto, visto che tra l'altro nelle operazioni grafiche tutta sta roba descritta nel documento non si usa (come ho cercato di spiegare nel post precedente già kilometrico abbastanza), ma essa deriva dal fatto che in cuda vengono utilizzate strutture dati che non ci sono in HLSL e GLSL, per cui per i relativi compilatori nei driver sarebbe tutto inutilizzabile, e a modificarli per digerire il tutto a runtime (perchè appunto il JIT del driver va a run-time) renderebbe l'operazione ovviamente troppo lenta. Si è quindi operata questa scelta di piazzare questo ulteriore strato software tra il jit ed il codice che facesse gran parte del lavoro e snellire quello necessario a a run-time. Ma ste cose le ho spiegate meglio nel post precedente per cui mi sembra già di essermi ripetuto a sufficienza. Poi ovvio che NVIDIA non avesse fatto un lavoro del genere per GPU precedenti alle directx10 (per g80), perchè, non essendoci CUDA e interesse verso il GPGPU, non serviva.

Voglio però ritornare velocemente alla questione del compilatore standard HLSL. riporto nuovamente i 2 grafici che ho già linkato:

HLSL (directx)
http://img109.imageshack.us/img109/2233/grafico.jpg

GLSL (opengl, il discorso continua poi nelle altre 2 pagine seguenti)
http://img69.imageshack.us/img69/5382/45128354.jpg

siccome quando la discussione è partita pensavo di dover solo fare una puntualizzazione veloce e non sta opera enciclopedica, ho parlato solo (l'ho specificato quasi subito) di opengl visto che è l'ambito che conosco bene. Andando poi a pescare le fonti di quello che stavo spiegando sono incappato in una breve descrizione dello schema delle directx che è leggermente diverso ma non sposta in modo sostanziale il problema. Qualche post fa sono sicuro di avere accennato alla questione ma vedendo questa domanda o non è stata letto il pezzo in questione o non sono stato abbastanza chiaro.
In entrambi i mondi è sempre nel driver che avviene la compilazione dello shader, infatti la frecetta del graphics hardware viene dubito dopo. Quello che è diverso, è che in opengl il source dello shader GLSL arriva direttamente nel driver, l'operazione di compilazione in linguaggio macchina avviene tutta li. In HLSL invece c'è "l'HLSL translator" che effettua una prima traduzione, ma che ovviamente non può essere in linguaggio macchina perchè essendo quel modulo uguale per tutti non può compilare per tutti (la compilazione è una operazione "su misura"). In pratica fa qualcosa tipo il bytecode del JAVA. Questo codice passa al driver (che come nel caso dell'opengl è prodotto dal "graphics hardware vendor") che si preoccupa di compilare lo shader nel linguaggio macchina. Alla fine il risultato è il medesimo in entrambi i casi. In una delle pagine successive (mi sembra in quella dopo) si fa un ragionamento su quale approccio sia preferibile. Essendo il libro di riferimento delle opengl, non ci sono dubbi su quale sia l'approccio che venga reputato migliore (ognuno tira l'acqua al suo mulino), ma i concetti hanno validità generale. L'approccio opengl è sicuramente più oneroso per quanto riguarda il compilatore del driver, visto che deve eseguire a run-time la completa conversione dalle istruzioni ad alto livello al linguaggio macchina. Quindi o risulta più lento (il che non comporta frame-rate minori visto che viene fatta una volta sola, ma comunque non può essere lento oltre un certo limite) oppure "ottimizza" meno (anche se è un termine troppo semplicistico ma ci siamo capiti). In HLSL invece il compito del driver è molto più leggero perchè il grosso del lavoro lo ha fatto l'HLSL translator (che può metterci quanto gli pare visto che può non essere eseguito a runtime e quindi rentere il codice più compatto possibile). Il difetto di questo approccio è che se l'architettura della GPU diverge troppo dal generico modello di calcolo previsto dal codice "intermedio" che gli arriva al driver, allora quest'ultimo lo adatterebbe sicuramente peggio che in opengl, non avendo le informazioni del sorgente ma solo il codice uscito dal translator (si perde parecchia informazione).
Se quindi non ci fossero limiti di tempo, sicuramente l'approccio GLSL sarebbe nettamente superiore, ma visto che non può metterci ore (è una battuta) per compilare, allora il risultato dipende appunto dal bilanciamento complessità della GPU/tempo a disposizione.
Quindi nessuno dei due approcci è in modo totale migliore dell'altro.
Ritornando all'argomento del quote, io non ho mai detto (e se l'ho detto mi sono sbagliato) che viene modificato il traduttore HLSL di windows, ho fatto sempre riferimento a quello del driver, responsabile in entrambni i casi della generazione del codice macchina.

Originariamente inviato da yossarian

(mi spieghi cosa c'entrerebbe, ad esempio, la gestione delle operazioni su texture e la loro allocazione in memoria con applicazioni di tipo gpgpu?)

http://www.mathematik.uni-dortmund.d.../tutorial.html

il GPGPU si faceva anche prima dell'avvento degli shader unificati quindi di cuda, il quale ha solo aggiunto un livello di astrazione e reso + semplice per il programmatore non perdersi in tecnicismi prettamente grafici (come appunto le texture) ma che sono la via privilegiata per la GPU di ricevere i dati. Non penso che cuda "internamente" lavori molto diversamente, ma rende più semplice la vita allo sviluppatore, oltre certamente, vista la maggiore attenzione delle nuove GPU al mondo general purpose, a offrire qualcosa in più ma che non dipende da cuda ma dall'HW sottostante. Non conosco però dettagliatamente CUDA per esprimere giudizi definitivi in merito, ma non capisco perchè inserire tutto nel caldernone di questa discussione che ha un argomento ben preciso e focalizzato. Alla fine il risultato è solo confondere le idee a chi ci legge.

Originariamente inviato da yossarian

Inoltre, visto che l'oggetto del contendere sono le ottimizzazioni e non la compilazione (mi dici, ripeto, dove avrei scritto che la compilazione è a carico della gpu?)

Visto che prima hai detto che ho perso tempo a quotare tutte le volte che hai detto/negato un certo fatto, stavolta passo. Comunque così papale papale non so se l'hai mai detto, ma io ho capito così dai tuoi numerosi post. L'oggetto del contendere però è proprio la fase di compilazione, in cui vengono svolte le prime "ottimizzazioni" e che viene fatta dal compiler del driver (che non fa niente di generico o standard). Siccome tra tutto quello che mi viene in mente una eventuale brutale sostituzione MADD->FMA è la cosa più semplice possibile e per giusta senza nessun problema di analisi del flusso o balle varie (tipo: sto compilando una riga in cui ci sono moltiplicazioni e somme di vec4, quindi ci saranno fiumi di madd. Il compilatore sarà quindi stato programmato per produrre in uscita assembler con FMA invece che MADD), sicuramente se si farà la si farà a questo livello. Quindi come vedi la questione è la compilazione.
Le due pagine dell'articolo che hai linkato e il pdf riguardano sempre la questione CUDA-GPGPU di cui ho già parlato sopra e, meglio, nel post precedente, e che non centra nulla con quello di cui stiamo discutendo.

Comunque oltre a yoss qualcuno legge quello che scrivo? sennò tutto sto casino per una persona sola lo rende spam e basta

[yossarian]

Originariamente inviato da Pelvix

Si, vabbè, ma se vanno avanti così ora che esce sarà diventato obsoleto proprio il concetto di VGA...

Non è che se arrivano un anno dopo c'è poi da stupirsi che vada più forte, e ci mancherebbe altro...

No no, per me sto giro hanno fatto proprio una gran bella figuraccia, e da nvidia-ista da ani, mi sa che stavolta li mollo..

in realtà fermi rappresenta il primo step di un progetto che si propne proprio di rendere obsoleto il concetto di vga e di chip grafico.