[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[Pelvix]

Originariamente inviato da yossarian

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.

Mah, per ora mi sa solo di gran ciofecata, spero comunque di sbagliarmi, sia ben chairo..

[Jackaos]

Originariamente inviato da Legolas84

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

Il mestiere di chi basandosi su sigle che a logica dovrebbero informare compra il nuovo modello e scopre che è vecchio?

[yossarian]

Originariamente inviato da skizzo99999999

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.



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.



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.



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

allora mi sa che hai frainteso tutto: l'oggetto del contendere erano solo le sostituzioni di madd con fma. Tu ritieni che saranno fatte (se saranno fatte) in sede di compilazione dalla cpu, io, in base a quello che so su fermi e a quello che so (riportato dai vari documenti linkati) sul modo di ottimizzare da parte di nVidia e non solo (anche ATi fa lo stesso: compilatore generico, VM, compilatore JIT e ottimizzazioni; lo schema che hai linkato nell'immagine rappresenta degli step teorici ma allo stesso risultato si può arrivare in tanti modi e ti assicuro che nessuno si mette a scrivere compilatori o a modificarne di esistenti quando basta molto meno per fare le ottimizzazioni necessarie), ritengo, invece, che sarà il chip grafico a fare materialmente la sostituzione. So bene che la può fare anche la cpu ma non è affatto conveniente che sia la cpu a farla. Per quael motivo si deve mettere mano ad un compilatore quando bastano poche righe di codice inserite in un optimizer a valle del compilatore, per ottenere lo stesso risultato? Inoltre, come detto, i preephole lavorano su linguaggio binario e quindi sono perfettamente digeribili anche da gpu meno flessibili e programmabili di fermi.
Ripeto, CUDA serve a capire come funziona una gpu (nVidia nella fattispecie) e cosa può fare.
Ora abbiamo appurato che esiste un compilatore standard (OPEN64, HLSL, GLSL) che fa una prima compilazione e sappiamo che le preephole optimizatin sono fatte dall'OCG su linguaggio binario (c'è scritto esplicitamente). l'OCG è a valle della PTX (quindi agisce dopo la compilazione JIT) e le preephole optimization si servono di quelle che sono definite atomic ops sugli interi (and, or, compare) e di salti condizionati. Fermi gestisce alla perfezione entrambe le cose (ha una gestione dei predicate cpu like). Quindi non ha nessuna difficoltà ad effettuare la sostituzione al volo sulla singola istruzione quando viene chiamata. E questo riduce anche il traffico tra cpu e gpu.
Non vedo una sola buona ragione per cui debba essere la cpu ad effettuarla in sede di compilazione JIT.

EDIT
aggiungo, sempre da wikipedia
http://en.wikipedia.org/wiki/Just-in-time_compilation
i vantaggi della compilazione JIT

1. The compilation can be optimized to the targeted CPU and the operating system model where the application runs. For example JIT can choose SSE2 CPU instructions when it detects that the CPU supports them. To obtain this level of optimization specificity with a static compiler, one must either compile a binary for each intended platform/architecture, or else include multiple versions of portions of the code within a single binary.
2. The system is able to collect statistics about how the program is actually running in the environment it is in, and it can rearrange and recompile for optimum performance. However, some static compilers can also take profile information as input.
3. The system can do global code optimizations (e.g. inlining of library functions) without losing the advantages of dynamic linking and without the overheads inherent to static compilers and linkers. Specifically, when doing global inline substitutions, a static compiler must insert run-time checks and ensure that a virtual call would occur if the actual class of the object overrides the inlined method (however, this need not be the case for languages employing a static type discipline).
4. Although this is possible with statically compiled garbage collected languages, a bytecode system can more easily rearrange memory for better cache utilization..


ovviamente cpu va sostituita con gpu. In particolare, i due punti in neretto rappresentano due dei motivi principali per cui è opportuno che sia la gpu a fare le ottimizzazioni, quando possibile. Il punto 2 parla di riarrangiare al volo il codice per meglio ottimizzare l'elaborazione (ce lo vedi il bus pci intasato dall'andirivieni tra cpu e gpu? E i continui load/store tra vram e gpu a botta di 500-600 cicli per volta?). Il punto 4 parla di miglior utilizzo della cache (con ovvio riferimento alla cpu; ma in questo caso è la cpu stessa che gestisce tutto e ottimizza la propria cache. Nel caso in questione, la cpu non ha accesso alcuno alla cache interna della gpu). Quindi, questo tipo di operazioni può farle solo la gpu stessa.
Come vedi, non vale il discorso del codice già bello e pronto da essere usato e, tanto meno, è pensabile la gestione JIT da parte della cpu di buona parte delle ottimizzazioni. Nel caso specifico della sostituzione delle madd con fma ho già detto quello che penso: fa parte di quelle ottimizzazioni a carico delle gpu, anche perchè rientrano tra quelle che obbligano a riarrangiare la gestione dei thread in corso di elaborazione (i dati sono elaborati in maniera dinamica e un insieme di vertici ne può generare uno molto più grande, oppure da un vertice possono venir fuori un gran numero di pixel e solo il thread processor della gpu può decidere in che ordine far eseguire le relative istruzioni e, di conseguenza, come distribuire e allocare le risorse).

In quanto all'ultima frase, mi sa che nessuno ci sta filando e per quanto mi riguarda, possiamo chiuderla, visto che siamo ad un punto morto

[Pelvix]

Originariamente inviato da Jackaos

Il mestiere di chi basandosi su sigle che a logica dovrebbero informare compra il nuovo modello e scopre che è vecchio?

A no caro mio, non ci penso proprio, compro solo se ne vale la pena, non per brand..
Infatti hosempre avuto nvidia dai tempi della TNT perchè secondo me più performante, a parte il periodo ATI 9700-9800 in cui sono passato al rosso perchè nettamente migliore ATI all'epoca...
E mi sa che a sto giro la storia si ripererà con il rapporto 5870 / GT 300: 9700 bis?

[Pike79]

Vivete sereni, siete gli unici che scrivono cose interessanti! Criptiche per i profani, ma interessanti!

[Drakogian]

Originariamente inviato da skizzo99999999

... cut ...

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

Originariamente inviato da yossarian

... cut...

In quanto all'ultima frase, mi sa che nessuno ci sta filando e per quanto mi riguarda, possiamo chiuderla, visto che siamo ad un punto morto

Io vi leggo... anzi molte volte vi "rileggo"... indovinate perchè...
Sempre in rispettoso silenzio....
Scherzi a parte... l'argomento è ostico però qualcosa si imparara sempre... andate avanti.

[Dieghen620]

Originariamente inviato da Drakogian

Io vi leggo... anzi molte volte vi "rileggo"... indovinate perchè...
Sempre in rispettoso silenzio....
Scherzi a parte... l'argomento è ostico però qualcosa si imparara sempre... andate avanti.

Quotone anche da parte mia... non ci capisco na mazza, ma ogni tanto qualche concetto lo afferro...

Vorrei che però si arrivaste ad un punto in cui sono tutti d'accordo... in fondo è naturale che sia così se si discute tra persone ragionevoli, no? Soprattutto visto che si parla di questioni tecniche e quindi dimostrabili...

[yossarian]

Originariamente inviato da Dieghen620

Quotone anche da parte mia... non ci capisco na mazza, ma ogni tanto qualche concetto lo afferro...

Vorrei che però si arrivaste ad un punto in cui sono tutti d'accordo... in fondo è naturale che sia così se si discute tra persone ragionevoli, no? Soprattutto visto che si parla di questioni tecniche e quindi dimostrabili...

anche i problemi tecnici si possono risolvere in tanti modi differenti; tutto sta a vedere quale sia meglio in quello specifico contesto.

[Diobrando_21]

Originariamente inviato da yossarian

allora mi sa che hai frainteso tutto: l'oggetto del contendere erano solo le sostituzioni di madd con fma. Tu ritieni che saranno fatte (se saranno fatte) in sede di compilazione dalla cpu, io, in base a quello che so su fermi e a quello che so (riportato dai vari documenti linkati) sul modo di ottimizzare da parte di nVidia e non solo (anche ATi fa lo stesso: compilatore generico, VM, compilatore JIT e ottimizzazioni; lo schema che hai linkato nell'immagine rappresenta degli step teorici ma allo stesso risultato si può arrivare in tanti modi e ti assicuro che nessuno si mette a scrivere compilatori o a modificarne di esistenti quando basta molto meno per fare le ottimizzazioni necessarie), ritengo, invece, che sarà il chip grafico a fare materialmente la sostituzione. So bene che la può fare anche la cpu ma non è affatto conveniente che sia la cpu a farla. Per quael motivo si deve mettere mano ad un compilatore quando bastano poche righe di codice inserite in un optimizer a valle del compilatore, per ottenere lo stesso risultato? Inoltre, come detto, i preephole lavorano su linguaggio binario e quindi sono perfettamente digeribili anche da gpu meno flessibili e programmabili di fermi.
Ripeto, CUDA serve a capire come funziona una gpu (nVidia nella fattispecie) e cosa può fare.
Ora abbiamo appurato che esiste un compilatore standard (OPEN64, HLSL, GLSL) che fa una prima compilazione e sappiamo che le preephole optimizatin sono fatte dall'OCG su linguaggio binario (c'è scritto esplicitamente). l'OCG è a valle della PTX (quindi agisce dopo la compilazione JIT) e le preephole optimization si servono di quelle che sono definite atomic ops sugli interi (and, or, compare) e di salti condizionati. Fermi gestisce alla perfezione entrambe le cose (ha una gestione dei predicate cpu like). Quindi non ha nessuna difficoltà ad effettuare la sostituzione al volo sulla singola istruzione quando viene chiamata. E questo riduce anche il traffico tra cpu e gpu.
Non vedo una sola buona ragione per cui debba essere la cpu ad effettuarla in sede di compilazione JIT.

In quanto all'ultima frase, mi sa che nessuno ci sta filando e per quanto mi riguarda, possiamo chiuderla, visto che siamo ad un punto morto

no xké dovete chiuderla? Io vi sto seguendo, a stento ma vi seguo e qualche cosa la sto anche capendo (a grandi linee )...e a quanto pare nn sono l'unico, continuate pure

[BebeMatley]

Originariamente inviato da yossarian

In quanto all'ultima frase, mi sa che nessuno ci sta filando e per quanto mi riguarda, possiamo chiuderla, visto che siamo ad un punto morto

Anche io vi seguo in silenzio, riesco a seguire abbastanza il ragionamento ma non mi sento in grado di appoggiare una o l'altra tesi.
Sottolineo come altri che una discussione così sul forum non si vedeva da un bel pò.

Ciao e grazie

[maurilio968]

Originariamente inviato da maurilio968

Vorrei comunque ringraziare sia Yossarian che skizzo per questa discussione che a me sembra molto interessante.

mi autoquoto, è da un bel po che vi seguo.

Molti di noi non intervengono attivamente semplicemente perchè...non possono.
A stento vio seguiamo ma è l'occasione giusta per avvicinarsi a temi ostici che ci appassionano.

[Psyco89]

scusate non so se avete notato ma nel sito tutti gli stream processor sono stai rinominati come cuda core, perciò chi vi ha detto che questi stream siano diversi e non solo una rinominazione.

[A.L.M.]

Originariamente inviato da Psyco89

scusate non so se avete notato ma nel sito tutti gli stream processor sono stai rinominati come cuda core, perciò chi vi ha detto che questi stream siano diversi e non solo una rinominazione.

Cosa cambia lo ha già detto in maniera ufficiale NVidia...
Stiamo parlando di quello da n pagine...

[Psyco89]

l'articolo dice : "Sviluppiamo ora quelle che sono le caratteristiche architetturali della nuova architettura Fermi di NVIDIA, alla luce di quello che il produttore ha sino ad ora reso disponibile per il pubblico. Partiamo dal numero di stream processors, passato dai precedenti 240 delle achitetture GT200 agli attuali 512; NVIDIA ha scelto di chiamare questi componenti come CUDA Cores e non più come stream processors, ma di fatto sono la stessa cosa in termini di architettura della GPU ".

probabilmente organizzati in modo differente ma allora perchè dite che l'efficienza di questi CUDA core sono incerti rispetto a quelli di GT200 ? da quel che mi è smebrato è parsa più un evoluzione del Gt200.

[yossarian]

Originariamente inviato da Psyco89

scusate non so se avete notato ma nel sito tutti gli stream processor sono stai rinominati come cuda core, perciò chi vi ha detto che questi stream siano diversi e non solo una rinominazione.

sono diversi

Originariamente inviato da A.L.M.

Cosa cambia lo ha già detto in maniera ufficiale NVidia...
Stiamo parlando di quello da n pagine...

è stato detto qualcosa, qualcos'altro si può leggere tra le righe

Originariamente inviato da Psyco89

l'articolo dice : "Sviluppiamo ora quelle che sono le caratteristiche architetturali della nuova architettura Fermi di NVIDIA, alla luce di quello che il produttore ha sino ad ora reso disponibile per il pubblico. Partiamo dal numero di stream processors, passato dai precedenti 240 delle achitetture GT200 agli attuali 512; NVIDIA ha scelto di chiamare questi componenti come CUDA Cores e non più come stream processors, ma di fatto sono la stessa cosa in termini di architettura della GPU ".

probabilmente organizzati in modo differente ma allora perchè dite che l'efficienza di questi CUDA core sono incerti rispetto a quelli di GT200 ? da quel che mi è smebrato è parsa più un evoluzione del Gt200.

fermi è un'altra architettura. GT200 è l'ultimo step della vecchia, GT300 il primo della nuova

[Psyco89]

CUDA core è solo una rinominazione da quanto ho capito ma sono quasi i medesimi o dei derivati degli stream da GT200.

Quindi se sono dichiarati 512 stream effettivamente potrebbe voler dire molto a livello di prestazione.

[eXeS]

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.

Che è quello che parzialmente sostengo anch'io, e mi sembrava d'averlo già scritto ovvero:

- Il gioco fa indirettamente una chiamata ai driver per inviare lo shader alla gpu
- Il driver nell'ambito dell'esecuzione della chiamata usando codice assembler x86/x64, rimpiazza le madd con le fma e prepara le istruzioni per la gpu che conterranno quindi le ottimizzazioni.
- Il driver invia le istruzioni ottimizzate alla gpu.

Parzialmente in quanto la teoria che i driver contengano staticamente già le istruzioni per la gpu ottimizzate mi sembra poco probabile, e, perchè richiederebbe che i driver conoscano gli shader di tutti i giochi sviluppati, e, perchè questo replace non vedo perchè non si possa far eseguire alla cpu

Originariamente inviato da yossarian

interessante, ma l'utilità ai fini di ciò di cui si discute?

Quando hai descritto cosa i driver possono e non possono fare sembrava che non ti fosse chiaro il concetto che fossero binari x86/x64, poichè non ho la presunzione che chi mi legge debba credermi sulla parola, dalla lettura di quel tutorial anche chi ha una scarsa conoscenza del software ma comunque sa cosa è un compilatore ed un linker, avrebbe compreso che effettivamente i driver sono alla stregua dei binari eseguibili che tutti conosciamo, binari particolari ma non direttamente eseguibili con doppio click.

Originariamente inviato da yossarian

infatti yossarian (e pare anche nVidia, il cui parere, ritengo sia più autorevole, in quanto si parla di Fermi), continua a non condividere la tesi delle ottimizzazioni fatte dalla stessa cpu in fase di compilazione e ritiene improbabili quelle JIT fatte dalla cpu. Insomma, nVidia pensa che meno traffico ci sia nel bus pci-express e meno la cpu (e, addirittura, la vram) interviene e meglio è per tutti. Voi, liberi di pensarla come volete

Non ho seguito le ultime news ma continuo a pensarla come detto sopra, anche perchè un'ottimizzazione fatta dalla cpu che fa un replace di una madd con una fma non genera traffico nel bus, userà qualche ciclo di clock (della cpu), pazienza.

Non è detto che poi questa sarà la strada seguita da nVidia, quest'ultima come farebbe chiunque attuerà le ottimizzazioni compatibilmente con il miglior rapporto costi/benefici, e se il rapporto migliore deriverà adottando una soluzione simile a quella da te prospettata sceglierà quella, altrimenti ne sceglierà una simile a quella prospettata dal sottoscritto o un'altra ancora.

Il punto è che comunque sono ambedue tecnicamente fattibili, mentre seguendo il dibattito sembrava che l'unica verosimile fosse un replace eseguito dalla gpu durante la decodifica delle istruzioni.

[skizzo99999999]

Originariamente inviato da yossarian

allora mi sa che hai frainteso tutto: l'oggetto del contendere erano solo le sostituzioni di madd con fma. Tu ritieni che saranno fatte (se saranno fatte) in sede di compilazione dalla cpu, io, in base a quello che so su fermi e a quello che so (riportato dai vari documenti linkati) sul modo di ottimizzare da parte di nVidia e non solo (anche ATi fa lo stesso: compilatore generico, VM, compilatore JIT e ottimizzazioni; lo schema che hai linkato nell'immagine rappresenta degli step teorici ma allo stesso risultato si può arrivare in tanti modi e ti assicuro che nessuno si mette a scrivere compilatori o a modificarne di esistenti quando basta molto meno per fare le ottimizzazioni necessarie), ritengo, invece, che sarà il chip grafico a fare materialmente la sostituzione. So bene che la può fare anche la cpu ma non è affatto conveniente che sia la cpu a farla. Per quael motivo si deve mettere mano ad un compilatore quando bastano poche righe di codice inserite in un optimizer a valle del compilatore, per ottenere lo stesso risultato? Inoltre, come detto, i preephole lavorano su linguaggio binario e quindi sono perfettamente digeribili anche da gpu meno flessibili e programmabili di fermi.

secondo me invece tutti (e ripeto tutti) i documenti linkati invece danno la certezza (e alcuni lo dicono esplicitamente, ma ne abbiamo già parlato) che il compilatore generico non esiste o se ce n'è uno che fa qualcosa di simile (tipo in HLSL) il suo codice viene comunque poi compilato anche lui dal driver. Come ho quindi già ampiamente spiegato prima in entrambi i casi il codice viene sempre compilato dal compilatore JIT del driver (che non è per niente standard ed è diverso per ogni scheda).
Io quando dico compilatore del driver indico tutta la fase che dal codice sorgente (opengl) o dal codice restituito dall'HLSL translator (directx) restituisce il codice macchina per la GPU. Che poi la compilazione JIT e ottimizzazione sia composta da più passi è ovvio ma mi sono sempre limitato a dire il compilatore "ottimizza" per cercare di rendere la discussione più digeribile. Il succo del discorso è che partendo dallo shader, dal "blocco" software del driver esce il codice macchina che la GPU quando lo esegue non lo tocca più. E' appunto per questo che le sostituzioni si fanno a questo livello e non a run-time, sennò le dovrei fare tutte le volte invece così le faccio una volta sola. Tra l'altro se non si facesse in questo modo il codice non sarebbe compilato, ma richiederebbe una ulterirore interpretazione, cosa assolutamente priva di ogni significato visto che si sta parlando di ambiti dove la prestazione pura è quello che conta e se si può risparmiare qualcosa lo si fa. Quindi visto che nel driver si sa già molto di quello che si deve fare (almeno, lo ripeto, per operazioni prettamente statiche come appunto lasostituzione e la compilazione in generale) lo si fa li e basta. Perchè se lo si fa prima che lo shader passi a run-time, lo si fa una volta sola e basta.
Forse non riesco a spiegarmi bene sul concetto di run-time: è ovvio che gli shader vengono compilati a run-time (da qui il nome di compiler just-in-time) ma il run-time è riferito all'applicazione e non agli shader; cioè per quanto riguarda la GPU siamo "fermi" (verbo e non l'architettura NVIDIA). Ad un certo punto nell'applicazione si arriva alla chiamata di caricamento degli shader che vengono compilati e installati all'interno della GPU pronti per essere eseguiti. Ed è quindi prima di arrivare all'esecuzione che alcune ottimizzazioni "statiche" (cioè come già detto che non riguardano l'esame del flusso delle istruzioni) come le sostituzioni possono venire eseguite dal JIT (o comunque subito dopo, ma prima di arrivare all'esecuzione sulla GPU, ci siamo capiti su cosa voglio dire), in modo da non dover essere fatte tutte le volte dalla GPU al volo; saranno pure rapide e mascherabili, ma sarà ben meglio non farle no? è questo il senso dei compilatori just-in-time che parlando in generale sono stati creati per velocizzare i linguaggi interpretati e che qui hanno lo stesso significato, cioè traducono "al volo" prima della prima esecuzione il codice degli shader. E' per questo che è assolutamente conveniente fare tutto il possibile qui invece che farle mentre gli shader sono in esecuzione sulla GPU. Spero di essere stato abbastanza chiaro nel non identificare queste ottimizzazione con tutto quello che si fa a runtime (qua intendo il run-time degli shader, cioè mentre la GPU lavora) per sfruttare l'enorme potenziale parallelo delle GPU. Ma ste cose le ho già ripetute a sufficienza e la mia posizione ritengo sia abbastanza chiara.

Originariamente inviato da yossarian

Ripeto, CUDA serve a capire come funziona una gpu (nVidia nella fattispecie) e cosa può fare.

secondo me invece rende molto più complicate le cose, perchè cuda non ha lo stesso linguaggio dei 2 linguaggi di shading che abbiamo considerato (che tra di loro sono si diversi ma le differenze non sono importanti). E' un "quasi c" che quindi è molto più complesso da compilare e che richiede tutta quella pletora di moduli software (tipo OPEN64) che senza di esso non servono e non vengono usati.

Originariamente inviato da yossarian

Ora abbiamo appurato che esiste un compilatore standard (OPEN64, HLSL, GLSL) che fa una prima compilazione e sappiamo che le preephole optimizatin sono fatte dall'OCG su linguaggio binario (c'è scritto esplicitamente). l'OCG è a valle della PTX (quindi agisce dopo la compilazione JIT) e le preephole optimization si servono di quelle che sono definite atomic ops sugli interi (and, or, compare) e di salti condizionati. Fermi gestisce alla perfezione entrambe le cose (ha una gestione dei predicate cpu like). Quindi non ha nessuna difficoltà ad effettuare la sostituzione al volo sulla singola istruzione quando viene chiamata. E questo riduce anche il traffico tra cpu e gpu.
Non vedo una sola buona ragione per cui debba essere la cpu ad effettuarla in sede di compilazione JIT.

una parte standard è solo per hlsl (ma una parte, e per motivi che ho spiegato in un post precedente), per GLSL nulla e per open64 si ma non c'entra nulla con quello di cui stiamo parlando, è uno strato aggiuntivo per il codice c-like (e poi come per l'interprete HLSL è tutta "roba" che avviene in stadi precedenti, e che deve sempre passare dal compilatore "custom" JIT del driver NVDIA). Parlare di compilatore standard mi sembra proprio una contraddizione: se compila, compila per una certa architettura (es: nelle cpu x86, mips, ecc...). Non può essre standard, se il codice che esce deve essere diverso da GPU a GPU, e non può essere altrimenti sennò è una operazine che fa perdere tempo e basta, visto che bisognerebbe rimediare al volo nella GPU.
Fai poi un riferimento al OCG ed al JIt come se fossero due entità distinte ma sono la stessa cosa (riporto sempre da un documento precedente):

"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"

Magari ho frainteso cosa volevi dire, è stata una giornata pazzesca e sono un po' cotto...
Poi non vedo il problema del traffico tra CPU e GPU visto che il JIT è nel driver e fino a che non ha finito la GPU non lavora (almeno a quello che sta lavorando il JIT in compilazione). Magari sta eseguendo un altro shader, ma ritengo sia difficile in quanto è buona norma in qualsiasi gioco/applicazione compilare tutti gli shader prima di qualsivoglia operazione di rendering

Originariamente inviato da yossarian

Il punto 2 parla di riarrangiare al volo il codice per meglio ottimizzare l'elaborazione (ce lo vedi il bus pci intasato dall'andirivieni tra cpu e gpu? E i continui load store tra vram e gpu a botta di 500-600 cicli per volta?). Il punto 4 parla di miglior utilizzo della cache (con ovvio riferimento alla cpu; ma in questo caso è la cpu stessa che gestisce tutto e ottimizza la propria cache. Nel caso in questione, la cpu non ha accesso alcuno alla cache interna della gpu). Quindi, questo tipo di operazioni può farle solo la gpu stessa.
Come vedi, non vale il discorso del codice già bello e pronto da essere usato e, tanto meno, è pensabile la gestione JIT da parte della cpu di buona parte delle ottimizzazioni. Nel caso specifico della sostituzione delle madd con fma ho già detto quello che penso (fa parte di quelle ottimizzazioni a carico delle gpu, anche perchè rientrano tra quelle che obbligano a riarrangiare la gestione dei thread in corso di elaborazione (i dati sono elaborati in maniera dinamica e un insieme di vertici ne può generare uno molto più grande, oppure da un vertice possono venir fuori un gran numero di pixel e solo il thread processor della gpu può decidere in che ordine far eseguire le relative istruzioni e, di conseguenza, come distribuire e allocare le risorse).

In quanto all'ultima frase, mi sa che nessuno ci sta filando e per quanto mi riguarda, possiamo chiuderla, visto che siamo ad un punto morto

Anche qui mi sembra di essere stato chiaro oltre ogni ragionevole dubbio che con ottimizzazioni che si eseguono a compile-time (degli shader, run-time dell'appplicazione) si intendono solo quelle che non riguardano la gestione, come hai giustamente fatto notare (ma sono sicuro di averlo detto chiaramente diverse volte), dei thread o per esempio dell'ordine delle istruzioni. Sono cose che "staticamente" sono per ragioni più che evidenti impossibili da prevedere e che vengono gestite a run-time (sia dell'applicazione che degli shader). Rifaccio il parallelo che ho gia fatto cn le CPU: se ho un programma in sorgente c, lo compilo, per esempio in architettura x86 per un processore intel core i7. Ora intel fa degli ottimi compilatori che ottimizzano e compattano tutto l'ottimizzabile, ovviamente di quello che si può a compile-time, per le proprie architetture. Se invece utilizzo un compilatore c del visual studio 6, il risultato sarà sicuramente peggiore in termini di prestazioni. Abbiamo quindi il codice assembler nativo x86 pure "ottimizzato" per la propria cpu. Ma adesso non è che quando viene eseguito la cpu non ci lavora su, lo so bene che deve fare un gran lavoro! è dal pentium pro che è stata introdotta per esempio l'esecuzione fuori sequenza: visto che i processori moderni possono elaborare più istruzioni per volta, se l'istruzine successiva deve necessariamente aspettare il risultato di quella precedente per essere eseguita, il processore la "salta" mettendola in attesa ed eseguendo quella dopo. E' ovvio che questo non può essere fatto a compile time, visto che non so quando e in che "condizioni" si trovaranno le unità di esecuzione al raggiungimento di quella situazione. C'è poi la predizione dei salti in base a tabelle statistiche che vengono riempite in base ai risultati precedenza e mille (si fa per dire) altre cose che incidono notevolmente sulle prestazioni. Risulta altrettanto ovvio che questo tipo di ottimizzazioni non possono che essere a carico che della CPU (gran parte del silicio dei processori è destinato a robe del genere), e di conseguenza alle GPU se si gira tutto il discorso e ci si riferisce agli shader.
Ma la sostituzione è una cosa che non implica nessuna analisi che non si possa fare a compile-time, per cui la si fa li, dal compilatore nel driver.

Originariamente inviato da eXeS

Parzialmente in quanto la teoria che i driver contengano staticamente già le istruzioni per la gpu ottimizzate mi sembra poco probabile, e, perchè richiederebbe che i driver conoscano gli shader di tutti i giochi sviluppati, e, perchè questo replace non vedo perchè non si possa far eseguire alla cpu

Certo che non è così, quando parlavo di ottimizzare non specificavo perchè l'unica ottimizzazione di cui si stava discutendo era quella della sostituzione. Spero che con il discorso del paragrafo precedente di essere stato, se possibile, più chiaro. Per il resto concordo con il tuo post, anche se...

Originariamente inviato da eXeS

Non è detto che poi questa sarà la strada seguita da nVidia, quest'ultima come farebbe chiunque attuerà le ottimizzazioni compatibilmente con il miglior rapporto costi/benefici, e se il rapporto migliore deriverà adottando una soluzione simile a quella da te prospettata sceglierà quella, altrimenti ne sceglierà una simile a quella prospettata dal sottoscritto o un'altra ancora.

...non vedo nessuna possibile convenienza a non eseguire la sostituzione nel driver, visto che anche se la penalità di tempo non fosse trascurabile, vista la "zona" non avrebbe nessun peso (caricamento) e sicuramente anche un piccolo rallentamento durante l'esecuzione dello shader sarebbe peggio.

[yossarian]

Originariamente inviato da skizzo99999999

secondo me invece tutti (e ripeto tutti) i documenti linkati invece danno la certezza (e alcuni lo dicono esplicitamente, ma ne abbiamo già parlato) che il compilatore generico non esiste o se ce n'è uno che fa qualcosa di simile (tipo in HLSL) il suo codice viene comunque poi compilato anche lui dal driver. Come ho quindi già ampiamente spiegato prima in entrambi i casi il codice viene sempre compilato dal compilatore JIT del driver (che non è per niente standard ed è diverso per ogni scheda).
Io quando dico compilatore del driver indico tutta la fase che dal codice sorgente (opengl) o dal codice restituito dall'HLSL translator (directx) restituisce il codice macchina per la GPU. Che poi la compilazione JIT e ottimizzazione sia composta da più passi è ovvio ma mi sono sempre limitato a dire il compilatore "ottimizza" per cercare di rendere la discussione più digeribile.

il compilatore generico c'è per hlsl, per open64 e c'è anche per glsl. Secondo te, ora che stanno per lanciare fermi, nVidia si mette a scrivere un nuovo compilatore per opengl? Oppure, secondo te, nei driver unificati c'è una parte comune o abbiamo tanti compilatori quante sono le architetture dei chip supportati? Sai che due chip che hanno identica architettura ma, ad esmepio, differente numero dei registri, hanno differenti ISA? Ad esempio, G80 è differente da G70 che è diverso da NV40 che non è neppure parente di NV30 e tutti sono diversi da G92, da GT200 ecc. E tutti saranno molto diversi da fermi. Non esiste un compilatore ottimizzato per una determinata architettura con nessun tipo di API. Ogni compilatore è diviso in due partI: una standard che genera bytecode e una che fa compilazione JIT e gira, per i chip dx10 o successivi, su una VM.
Inoltre, tutti i documenti linkati hanno parlato di ottimizzazioni a valle del compilatore JIT (la certezaz è che lo si fa con cuda e con hlsl; tu sostieni che ciò non avvenga in opengl e io sono convinto del contrario e, comunque, la cosa risulta del tutto irrilevante, visto che si parla di giochi e, quindi, quasi esclusivamente, di DirectX). In quanto alle ottimizzazioni in questione, è chiaro che quando nVidia, parlando di cuda, dice: un buon ottimizzatore già lo avevamo (OCG) intende dire che questo ottimizzatore esisteva già prima di cuda ed era usato in altri ambiti. E la cosa non mi stupisce: ho un ottimizzatore che funziona bene per le mie architetture, l'unica cosa di cui mi devo preoccupare è di migliorare il più possibile la sua portabilità in modo da poterlo usare in tutti gli ambiti. Questo OCG agisce su codice binario e fa preephole optimization.

Originariamente inviato da skizzo99999999

Il succo del discorso è che partendo dallo shader, dal "blocco" software del driver esce il codice macchina che la GPU quando lo esegue non lo tocca più. E' appunto per questo che le sostituzioni si fanno a questo livello e non a run-time, sennò le dovrei fare tutte le volte invece così le faccio una volta sola.

allora avevo capito bene! Il modello che proponi è con le sostituzioni at compile time? Esattamente quello che nVidia non vuole. Grosso spreco di risorse, più traffico nel bus. E, comunque, le sostituzioni si possono fare solo su codice binario.

Originariamente inviato da skizzo99999999

Tra l'altro se non si facesse in questo modo il codice non sarebbe compilato, ma richiederebbe una ulterirore interpretazione, cosa assolutamente priva di ogni significato visto che si sta parlando di ambiti dove la prestazione pura è quello che conta e se si può risparmiare qualcosa lo si fa.

ma anche no. Parliamo di ambiti dove il problema principale è fare le ottimizzazioni il più in fretta possibile e non perdere tempo a ottimizzare, magari per anni, per una determinata architettura. Questo perchè cambiano le architetture e queste si devono adeguare rapidamente alle applicazioni vecchie e nuove. Inoltre, lo schema indicato da nVidia è piuttosto eloquente: da un parte il codice compilato che non deve essre ottimizzato (la stragrande maggioranza) che è quello indicato con "codice pr la cpu"; dall'altro quello che richiede la compilazione JIT che è una piccola parte ed è anche quello che viene ottimizzato. Quindi non si fa la ricompilazione di tutto ma solo quello destinato alla gpu diventa bytecode per girare su VM. Inoltre, l'utilità di scindere il due parti l'operazione di compilazione permette di unire i vantaggi della compilazione at compile time (con compiler standard) e dell'ottimizzazione at run time per architetture che, con ottimizzazione dinamica arrivano a guadagnare, statisticamente, anche un 30-40% in più rispetto ad una fatta at compile time (quindi ci sono anche evidennti vantaggi prestazionali)

Originariamente inviato da skizzo99999999

Quindi visto che nel driver si sa già molto di quello che si deve fare (almeno, lo ripeto, per operazioni prettamente statiche come appunto lasostituzione e la compilazione in generale) lo si fa li e basta. Perchè se lo si fa prima che lo shader passi a run-time, lo si fa una volta sola e basta.

nVIdia dice che le ottimizzazioni si fanno JIT. Ora, seguendo lo schema visto per CUDA, è evidente che il "ramo cpu" non presenta alcun optimizer e non riconosce neppure l'architettura del chip. Quindi non può in alcun modo fare ottimizzazioni per fermi. Immagina un driver che faccia la sostituzione di cui dici at compile time nel "ramo cpu". La sostituzione avviene indiscriminatamente per tutti i chip e, così, fermi lavora in maniera ottimale, GT200 diventa un chiodo e tutti gli altri neppure partono . Viceversa, se le ottimizzazioni i fanno nel "ramo gpu", PTX ricinisce l'architettura, sa che sta girando su fermi e effettua la sostituzione, oppure che si tratta di GT200 e lascia invariate le MADD. Però, come specificato e più volte ripetuto, le ottimizzazioni avvengono JIT e non at compile time.

Originariamente inviato da skizzo99999999

Forse non riesco a spiegarmi bene sul concetto di run-time: è ovvio che gli shader vengono compilati a run-time (da qui il nome di compiler just-in-time) ma il run-time è riferito all'applicazione e non agli shader; cioè per quanto riguarda la GPU siamo "fermi" (verbo e non l'architettura NVIDIA).

skizzo, mi sei simpatico e sei anche preparato, ma questo non l'ho proprio capito. Gli shader sono una cosa avulsa dall'applicazione?

Ok, torniamo seri (i complimenti sono sentiti, però).

Originariamente inviato da skizzo99999999

Ad un certo punto nell'applicazione si arriva alla chiamata di caricamento degli shader che vengono compilati e installati all'interno della GPU pronti per essere eseguiti. Ed è quindi prima di arrivare all'esecuzione che alcune ottimizzazioni "statiche" (cioè come già detto che non riguardano l'esame del flusso delle istruzioni) come le sostituzioni possono venire eseguite dal JIT (o comunque subito dopo, ma prima di arrivare all'esecuzione sulla GPU, ci siamo capiti su cosa voglio dire), in modo da non dover essere fatte tutte le volte dalla GPU al volo; saranno pure rapide e mascherabili, ma sarà ben meglio non farle no? è questo il senso dei compilatori just-in-time che parlando in generale sono stati creati per velocizzare i linguaggi interpretati e che qui hanno lo stesso significato, cioè traducono "al volo" prima della prima esecuzione il codice degli shader.

io ho capito quello che vuoi dire, ma non è possibile farlo; non in questo caso. Non stiamo parlando della sostituzione dell'istruzione che si fa una tantum: ad esempio, forzare l'AA in un gioco da driver. In quel caso, il tutto avviene all'inizio, modificando una sola impostaizone all'atto del caricamento del gioco. A tutto il resto pensa la gpu che ha il suo algortmo di edge detect che entra in funzione in automatico quando viene forzato il MSAA. Qui parliamo di una sostituzione che si deve fare su tutte le istruzioni di pixel, vertex e geometry shader e texture blending, tenendo conto anche di eventuali operazioni di tessellatin che generano un numero molto più elevato di vertici su cui si devono applicare le stesse operazioni, di shader procedurali e di vertex e geometry shader che generano un gran numero di pixel su cui si devono operare delle madd. E il tutto avviene all'interno della gpu e non al suo esterno e non è neppure pensabile che, alla bisogna, le istruzioni che si rendono necessarie vengono ottimizzate dalla cpu e caricate al volo (passerebbero secoli). In realtà è la prima volta che ci si trova di fronte ad una situazione in cui si potrebbe rendere necessaria una sostituzione di istruzioni su vastissima scala.
Per risolvere il problema tu proponi un'ottimizzazione, di fatto, at compile time che nVidia (ma non solo lei) non gradisce, che mal si adatta ad un'architettura superscalare (che necessità di un compilatore dinamico per poter meglio ottimizzare) e che comporta un notevole dispendio di risorse. Inoltre, ripeto, la stessa nVidia parla di ottimizzazini JIT e non at compile time.

Originariamente inviato da skizzo99999999

E' per questo che è assolutamente conveniente fare tutto il possibile qui invece che farle mentre gli shader sono in esecuzione sulla GPU. Spero di essere stato abbastanza chiaro nel non identificare queste ottimizzazione con tutto quello che si fa a runtime (qua intendo il run-time degli shader, cioè mentre la GPU lavora) per sfruttare l'enorme potenziale parallelo delle GPU. Ma ste cose le ho già ripetute a sufficienza e la mia posizione ritengo sia abbastanza chiara.

invece è molto più conveniente sfruttare l'enorme potenziale della gpu mentre gli shader sono in esecuzione, sia per diminuire le latenze delle operazioni, sia per rendere più agevoli le altre ottimizzazini (quelle che può fare solo la gpu) sia aumentare l'efficienza della gpu facendo girare più thread (aumentare la pressione sui registri e sulla cache interna significa fare offload rispetto a cpu e vram, situazione ottimiale, se ben gestita a livello di distribuzione dei carichi di lavoro, per aumentare l'efficienza del chip.

Originariamente inviato da skizzo99999999

secondo me invece rende molto più complicate le cose, perchè cuda non ha lo stesso linguaggio dei 2 linguaggi di shading che abbiamo considerato (che tra di loro sono si diversi ma le differenze non sono importanti). E' un "quasi c" che quindi è molto più complesso da compilare e che richiede tutta quella pletora di moduli software (tipo OPEN64) che senza di esso non servono e non vengono usati.

CUDA è c-like come hlsl e glsl e non ha nulla di complesso: è open64 con qualche ottimizzazione per chip nVidia. Studiarlo è utile per capire come funzionano i chip, quali sono le loro potenzialità e qual è la strategia di nVidia (anche in relazione alle ottimizzazioni).

Originariamente inviato da skizzo99999999

una parte standard è solo per hlsl (ma una parte, e per motivi che ho spiegato in un post precedente), per GLSL nulla e per open64 si ma non c'entra nulla con quello di cui stiamo parlando, è uno strato aggiuntivo per il codice c-like (e poi come per l'interprete HLSL è tutta "roba" che avviene in stadi precedenti, e che deve sempre passare dal compilatore "custom" JIT del driver NVDIA). Parlare di compilatore standard mi sembra proprio una contraddizione: se compila, compila per una certa architettura (es: nelle cpu x86, mips, ecc...). Non può essre standard, se il codice che esce deve essere diverso da GPU a GPU, e non può essere altrimenti sennò è una operazine che fa perdere tempo e basta, visto che bisognerebbe rimediare al volo nella GPU.
Fai poi un riferimento al OCG ed al JIt come se fossero due entità distinte ma sono la stessa cosa (riporto sempre da un documento precedente):

"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"

Magari ho frainteso cosa volevi dire, è stata una giornata pazzesca e sono un po' cotto...

le cose stanno in maniera molto semplice, come spiegato dai documenti postati. Il codice è scisso in due parti: una standard, che è la stragrande maggioranza del codice, è compilata dalla cpu secondo il compilatore delle API di riferimento; questa non contiene alcuna ottimizzazione. Un'altra è destinata alla gpu; la cpu compila un bytecode da far girare su una VM. Questa provvede ad effettuare le ottimizzazioni riconoscendo l'architettura del chip e procedendo, di conseguenza, alle ottimizzazioni necessarie per quell'architettura. Queste ultime sono eseguite JIT e su linguaggio binario; ad occuparsene può essere la cpu (in caso di interventi possibili prima del lancio dell'applicazione) o la gpu (in caso di interventi che è opportuno demandare al device). Le sostituzioni in questione rientrano in questa seconda categoria,

Originariamente inviato da skizzo99999999

Poi non vedo il problema del traffico tra CPU e GPU visto che il JIT è nel driver e fino a che non ha finito la GPU non lavora (almeno a quello che sta lavorando il JIT in compilazione). Magari sta eseguendo un altro shader, ma ritengo sia difficile in quanto è buona norma in qualsiasi gioco/applicazione compilare tutti gli shader prima di qualsivoglia operazione di rendering

A me risulta che una compilazione JIT prevede, invece, proprio la compilazione mentre l'applicazione sta girando. Se si compila prima tutto il codice e lo si ottimizza parliamo di compile time. Semmai può essere che si tratti di un aparte del codice e, mentre la gpu lavora su questo, la cpu ottimizza un'altra porzione, ma, allora, il traffico si crea eccome e si crea anche una gran confusione. Chi dà alla cpu le informazioni sulle istruzioni chiamate sulla gpu? Come sa quale parte del codice ottimizzare se non sa su cosa sta lavorando la gpu perchè non ha accesso al suo interno? Come fa a sapere che un'istruzione non abbia generato dati che devono essere processati prima di altri già schedulati? In parole povere, in base a quale criterio decide l'ordine in cui procedere?
se, poi, parliamo di compile time, allora è un altro paio di maniche (ma nVidia dice JIT e un'architettura superscalare ha bisogno di compilazione dinamica).

Originariamente inviato da skizzo99999999

Anche qui mi sembra di essere stato chiaro oltre ogni ragionevole dubbio che con ottimizzazioni che si eseguono a compile-time (degli shader, run-time dell'appplicazione) si intendono solo quelle che non riguardano la gestione, come hai giustamente fatto notare (ma sono sicuro di averlo detto chiaramente diverse volte), dei thread o per esempio dell'ordine delle istruzioni. Sono cose che "staticamente" sono per ragioni più che evidenti impossibili da prevedere e che vengono gestite a run-time (sia dell'applicazione che degli shader).

si tratta di ottimizzazioni fortemente dipendenti dall'ordine delle istruzioni che arriverebbero già ottimizzate. Vedi punto sopra: la cpu non può sapere su cosa sta lavorando la gpu e non può, di conseguenza, fare sostituzine JIT delle istruzioni necessarie. La gestione dei thread è un processo dinamico e non statico; ripeto, qui non parliamo di forzare l'AA via driver all'atto del lancio dell'applicazione.

Originariamente inviato da skizzo99999999

Rifaccio il parallelo che ho gia fatto cn le CPU: se ho un programma in sorgente c, lo compilo, per esempio in architettura x86 per un processore intel core i7. Ora intel fa degli ottimi compilatori che ottimizzano e compattano tutto l'ottimizzabile, ovviamente di quello che si può a compile-time, per le proprie architetture. Se invece utilizzo un compilatore c del visual studio 6, il risultato sarà sicuramente peggiore in termini di prestazioni. Abbiamo quindi il codice assembler nativo x86 pure "ottimizzato" per la propria cpu. Ma adesso non è che quando viene eseguito la cpu non ci lavora su, lo so bene che deve fare un gran lavoro! è dal pentium pro che è stata introdotta per esempio l'esecuzione fuori sequenza: visto che i processori moderni possono elaborare più istruzioni per volta, se l'istruzine successiva deve necessariamente aspettare il risultato di quella precedente per essere eseguita, il processore la "salta" mettendola in attesa ed eseguendo quella dopo. E' ovvio che questo non può essere fatto a compile time, visto che non so quando e in che "condizioni" si trovaranno le unità di esecuzione al raggiungimento di quella situazione. C'è poi la predizione dei salti in base a tabelle statistiche che vengono riempite in base ai risultati precedenza e mille (si fa per dire) altre cose che incidono notevolmente sulle prestazioni. Risulta altrettanto ovvio che questo tipo di ottimizzazioni non possono che essere a carico che della CPU (gran parte del silicio dei processori è destinato a robe del genere), e di conseguenza alle GPU se si gira tutto il discorso e ci si riferisce agli shader.
Ma la sostituzione è una cosa che non implica nessuna analisi che non si possa fare a compile-time, per cui la si fa li, dal compilatore nel driver.

ti ho già spiegato perchè non è possibile fare una "semplice sostituzione" at compile time: perchè si parla di migliaia di semplici sostituzioni che devono servire ad elaborare dati che ancora non sono stati creati e di cui non si conosce nè il numero né gli altri parametri tra cui l'ordine in cui dovranno essere processati. (la cpu conosce solo i valori iniziali dei vertici di un frame). Inoltre, ripeto per l'ennesima volta, un'architetura superscalare vuole un compiler dinamico (pena pessima ottimizzazione) e nVdia non parla di preephole optimization at compile time (ci sarà un motivo)?

Originariamente inviato da skizzo99999999

...non vedo nessuna possibile convenienza a non eseguire la sostituzione nel driver, visto che anche se la penalità di tempo non fosse trascurabile, vista la "zona" non avrebbe nessun peso (caricamento) e sicuramente anche un piccolo rallentamento durante l'esecuzione dello shader sarebbe peggio.

invece io ritengo, per quanto esposto, che la sostituzione, ammesso che sia possibile e che si farà, avverrà sulla gpu.

E mi pare che siamo di nuovo ad un punto morto e, poichè ho un avita sociale, un lavoro e un articolo da scrivere (tranquilli non è su fermi, anche se ci sarebbe materiale per una serie completa degna di beautiful ), ritengo poco costruttivo contìnuare una discussione in cui ognuno ha espresso i suoi concetti (anche più volte) senza arrivare ad una conclusione di sorta.

[Bastoner]

Originariamente inviato da yossarian

E mi pare che siamo di nuovo ad un punto morto e, poichè ho una vita sociale, un lavoro e un articolo da scrivere (tranquilli non è su fermi, anche se ci sarebbe materiale per una serie completa degna di beautiful ), ritengo poco costruttivo contìnuare una discussione in cui ognuno ha espresso i suoi concetti (anche più volte) senza arrivare ad una conclusione di sorta.

Allora aspettiamo la prima puntata della Fermi-soap