[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[eXeS]

Originariamente inviato da yossarian

il problema è proprio il punto 3
Quanto codice pensi si possa caricare su una gpu o, per essere precisi, sugli instruction buffer del thread processor di una gpu?

E che c... ne so

Originariamente inviato da yossarian

Non conta quello presente sulla vram (il thread processor non ha accesso alla vram per compilare il codice) ma solo quello presente nei buffer interni del thread processor. E' solo su quello che si possono fare le sostituzioni.

Ma il thread processor mica lo deve compilare il codice shader, ma piuttosto interpetare/eseguire qualcosa che è gia stato precedenteme compilato (intendendo per compilato codice comprensibile e riconosciuto dalla gpu) a partire dall'lhsl o il glsl.

Se al thread processor passo la sequenza di caratteri contenuti in un sorgente scritto in hsls piuttosto che glsl, che cavolo vuoi che ci capisca.

[Kharonte85]

Originariamente inviato da yossarian

(quindi, anche all'interno degli stessi driver, ci devono essere istruzioni dedicate al solo fermi) e non di tutta la famiglia (driver unificati? ).

Ecco, nella mia ignoranza mentre vi leggevo e davate fuoco alle polveri (continuate please che era una vita che non si leggevano discussioni così interessanti) stavo pensando proprio a questo come ad un'ipotesi verosimile...

[yossarian]

Originariamente inviato da skizzo99999999

Mi dispiace, ma o non capisci o fai finta di non capire. Mettiamo che sia la GPU a fare la compilazione (è possibilissimo che sia così, questo non lo so per cui ti credo). Carico una decina di shader: ci trova millemila potenziali MADD e ci mette millemila ore a traformarle in FMA. Dopo un secolo la compilazione del primo shader è avvenuta. il codice ESCE dai buffer interni o dovunque si debba trovare e la GPU passa a compilare il secondo, poi il terzo ecc..

esce dagli instruction buffer del thread processor e dove va?
Risposta: nelle alu per essere eseguito. Quindi, mentre le alu iniziano ad eseguire il codice compilato, il thread processor caricherà altro codice, eseguirà le stesse operazioni di ottimizzazione, sostituzione, deciderà cosa inviare a chi (perchè nel frattempo riceve informazioni dai vari cluster di alu sullo stato delle elaborazioni) e ripete il ciclo.

Originariamente inviato da skizzo99999999

Alla fine ho i capelli bianchi ma gli shader sono compilati e ci sono già TUTTE le FMA al posto delle MADD

quando si arriva a quello stadio siamo alla fine dell'elaborazione

Originariamente inviato da skizzo99999999

(che in realtà non ci sono mai state: il compilatore ha esaminato il GLSL ed invece di inserire MADD ha inserito FMA).
Ora posso usare gli shader senza nessun hit prestazionale

quale compilatore che si trova dove? nella cpu? NO. Un compilatore generico che fa quest'operazione indipendentemente dal chip su cui il codice deve girare? Glielo dici tu ai possessori di una 295 GTX come mai la loro vga che fino a ieri faceva 150 fps con BAA adesso ne fa 5 o 6?

Tra le altre cose, parliamo di architetture superscalari in cui, si cerca esplicitamente la minor dipendenza possibile dal compilatore (parlo di nVidia, ma le stesse ATi sono di tipo vliw dinamico la cui dipendenza dal compilatore è inferire rispetto a quelle vliw di tipo statico).

[skizzo99999999]

Originariamente inviato da Kharonte85

Ecco, nella mia ignoranza mentre vi leggevo e davate fuoco alle polveri (continuate please che era una vita che non si leggevano discussioni così interessanti) stavo pensando proprio a questo come ad un'ipotesi verosimile...

mi sembra ovvio che all'interno di driver unificati ci siano parti dedicate ognuna ad una famiglia specifica di GPU: sennò che li fanno a fare? mi sembra talmente ovvio che non ci sia da meravigliarsi. Infatti prima di avere driver unificati mi sembra di ricordare che c'erano driver diversi per ogni scheda. Non è che coi driver unificati le diverse schede usano gli stessi, semplicemente il pacchetto d'installazione è lo stesso

[skizzo99999999]

Originariamente inviato da yossarian

esce dagli instruction buffer del thread processor e dove va?
Risposta: nelle alu per essere eseguito. Quindi, mentre le alu iniziano ad eseguire il codice compilato, il thread processor caricherà altro codice, eseguirà le stesse operazioni di ottimizzazione, sostituzione, deciderà cosa inviare a chi (perchè nel frattempo riceve informazioni dai vari cluster di alu sullo stato delle elaborazioni) e ripete il ciclo.

Ed è qui che ti sbagli. Almeno io credo che ti sbagli. Almeno per le opengl il tutto funziona diversamente. La compilazione dello shader avviene PRIMA dell'esecuzione dello stesso come ho spiegato poco prima. E' qui il fraintendimento. E di questo sono sicuro perchè sto programmando anche adesso e funziona esattamente così. Poi ti ripeto non sono sicuro che dalla compilazione escano MADD, MUL, ecc... ma mi sembra altamente probabile (cosa dovrebbe uscire?).
Riguardo all'occupazione degli shader compilati, per loro natura non è che siano di milioni di righe di codice, occupano qualche kbyte ognuno.

[yossarian]

Originariamente inviato da skizzo99999999

mi sembra ovvio che all'interno di driver unificati ci siano parti dedicate ognuna ad una famiglia specifica di GPU: sennò che li fanno a fare? mi sembra talmente ovvio che non ci sia da meravigliarsi. Infatti prima di avere driver unificati mi sembra di ricordare che c'erano driver diversi per ogni scheda. Non è che coi driver unificati le diverse schede usano gli stessi, semplicemente il pacchetto d'installazione è lo stesso

non è solo il pacchetto di installazione ad essere rimasto invariato; ad esmepio, numero e tipologia di registri a parte una pipeline di tipo madd di nv40 ed una di g80 lavorano allo stesso modo. Diverso il discorso, invece, ad esempio, per la gestione dei thread (adesso abbiamo chip che bilanciano dinamicamente i carichi di lavoro e gestiscono il tutto in modalità out of order).

[Kharonte85]

Originariamente inviato da skizzo99999999

mi sembra ovvio che all'interno di driver unificati ci siano parti dedicate ognuna ad una famiglia specifica di GPU: sennò che li fanno a fare? mi sembra talmente ovvio che non ci sia da meravigliarsi. Infatti prima di avere driver unificati mi sembra di ricordare che c'erano driver diversi per ogni scheda. Non è che coi driver unificati le diverse schede usano gli stessi, semplicemente il pacchetto d'installazione è lo stesso

Questo è chiaro pero' forse stavolta "il passo" è troppo grande affinche' possa (convenga più che altro) venire racchiuso tutto in un pacchetto unico come avviene adesso...non so...vedremo.

[skizzo99999999]

Originariamente inviato da Ratatosk

E tutto sto pappone ricompilato nel frattempo dove lo metti?

Non sono un esperto dell'architettura interna delle GPU, per cui non se esattametne dove lo piazzi. Se dovessi azzardare, come ho già detto, penso stiano nella vram, ma cmq sparerei a caso. Comunque qui NVIDIA non deve inventare niente: io sviluppo su una x1600pro e non lo so dove metta tutti gli shader che compila, ma da qualche parte stanno, sono circa una trentina tra fragment e vertex, e li compilo tutti prima di entrare nel loop di rendering durante la fase di caricamento del modello. In tutto occupano 164kb, ma sono i sorgenti GLSL, non ho idea di come valutare l'occupazione del codice compilato

[yossarian]

Originariamente inviato da skizzo99999999

Ed è qui che ti sbagli. Almeno io credo che ti sbagli. Almeno per le opengl il tutto funziona diversamente. La compilazione dello shader avviene PRIMA dell'esecuzione dello stesso come ho spiegato poco prima. E' qui il fraintendimento. E di questo sono sicuro perchè sto programmando anche adesso e funziona esattamente così. Poi ti ripeto non sono sicuro che dalla compilazione escano MADD, MUL, ecc... ma mi sembra altamente probabile (cosa dovrebbe uscire?).
Riguardo all'occupazione degli shader compilati, per loro natura non è che siano di milioni di righe di codice, occupano qualche kbyte ognuno.

torno a ripetere: chi dovrebbe compilare il codice prima e dove? Tu stesso hai detto, correttamente che il compiler è contenuto nei driver. Ora, i driver servono a pilotare il dispositivo, sono delle istruzioni ma non possono agire fisicamente ricompilando qualcosa. La cpu non è pilotata dai driver della gpu (e non si accolla il compito di compilare e ottimizzare il lavoro della gpu). Se il tutto avviene all'interno della gpu (e non può avvenire altrimenti) avviene quando l'unità centrale della gpu ha accesso alle istruzioni (e non può avvenire in un istante diverso) perchè non può sapere cosa deve andare a ricopilare finchè non ha accesso al codice sorgente). Ogni gpu ha il suo compilatore che segue le istruzioni a lui dedicate (non può esistere un compiler generico per tutte o anche solo per una famiglia o una marca di gpu). Quindi ogni gpu procederà alla compilazione del rpoprio codice seguendo le istruzioni che le vengono date.
I milioni di righe di codice sono quelli del programma che deve girare sulla gpu non le 4 righe di una ottimizzazione o di uno shader replacement. E comunque, anche quelle devono essre caricate on chip perchè quando il thread porcessor trova l'istruzione (contenuta nei driver) che, all'atto della compilazione o dell'ottimizzazione o chiamala come vuoi, deve sostituire l'istruzione x con quella y, deve avere accesso all'istruzione y.
Ora, se mi parli di un generico compiler per opengl o d3d, posso essere d'accordo che la compilazione posso farla dovunque: se mi dici che devi fare una specifica ottimizzazione per un determinato chip, ti rispondo che quell'ottimizzazione non può essere affidata al generico compiler e può essere eseguita solo in runtime e on chip.
Il compiler generico per d3d del codice sorgente, restituirà l'equivalente di una madd in linguaggio macchina. L'operazione di sostituzione non è a carico del generico compiler per quel linguaggio di programmazione.

[Yota79]

Vabbè ma in soldoni quando dovrebbero uscire?

Avevo sentito che erano state presentate ma alla fine si era rivelato un fake (cosi mi pare di aver capito) , e le davano per la presentazione prima del 2010... o sbaglio?

[persa]

Originariamente inviato da Yota79

Vabbè ma in soldoni quando dovrebbero uscire?

Avevo sentito che erano state presentate ma alla fine si era rivelato un fake (cosi mi pare di aver capito) , e le davano per la presentazione prima del 2010... o sbaglio?

guarda io ero rimasto che le dovevano presentare a gennaio.

[skizzo99999999]

Originariamente inviato da yossarian

torno a ripetere: chi dovrebbe compilare il codice prima e dove? Tu stesso hai detto, correttamente che il compiler è contenuto nei driver. Ora, i driver servono a pilotare il dispositivo, sono delle istruzioni ma non possono agire fisicamente ricompilando qualcosa. La cpu non è pilotata dai driver della gpu (e non si accolla il compito di compilare e ottimizzare il lavoro della gpu). Se il tutto avviene all'interno della gpu (e non può avvenire altrimenti) avviene quando l'unità centrale della gpu ha accesso alle istruzioni (e non può avvenire in un istante diverso) perchè non può sapere cosa deve andare a ricopilare finchè non ha accesso al codice sorgente). Ogni gpu ha il suo compilatore che segue le istruzioni a lui dedicate (non può esistere un compiler generico per tutte o anche solo per una famiglia o una marca di gpu). Quindi ogni gpu procederà alla compilazione del rpoprio codice seguendo le istruzioni che le vengono date.
I milioni di righe di codice sono quelli del programma che deve girare sulla gpu non le 4 righe di una ottimizzazione o di uno shader replacement. E comunque, anche quelle devono essre caricate on chip perchè quando il thread porcessor trova l'istruzione (contenuta nei driver) che, all'atto della compilazione o dell'ottimizzazione o chiamala come vuoi, deve sostituire l'istruzione x con quella y, deve avere accesso all'istruzione y.
Ora, se mi parli di un generico compiler per opengl o d3d, posso essere d'accordo che la compilazione posso farla dovunque: se mi dici che devi fare una specifica ottimizzazione per un determinato chip, ti rispondo che quell'ottimizzazione non può essere affidata al generico compiler e può essere eseguita solo in runtime e on chip.
Il compiler generico per d3d del codice sorgente, restituirà l'equivalente di una madd in linguaggio macchina. L'operazione di sostituzione non è a carico del generico compiler per quel linguaggio di programmazione.

Non posso risponderti su cose che non conosco. Ti ripeto quello di cui sono certo ma cercando se possibile di essere più chiaro, visto che SEMBRA che finalmente hai capito il mio/nostro dubbio. L'istruzione che scrivo nel sorgente c (e che quindi compilerà il compilatore c, che esegue la CPU, che la manderà al driver, il quale ci farà quel piffero che vorrà) che compila il sorgente dello shader è eseguita dal driver della GPU. E' spiegato in tutti i libri su cui ho imparato l'opengl (e confermato tutti i giorni dall'uso della glCompileShader) che il fatto che gli shader vengano compilati a runtime e non precompilati prima da una scimmia o quant'altro serve in modo che il compilatore pilotato (o contenuto, non lo so, se tu lo sai che è nella GPU meglio per te) dal driver della scheda video possa ottimizzare il codice per una specifica architettura, in modo che una applicazione scritta prima possa girare in modo ragionevole su una architettura fatta poi. E' evidente che queste ottimizzazioni possono essere di vario genere, e avvengono durante la compilazione, la quale SICURAMENTE avviene prima dell'esecuzione dello shader stesso. Una volta sola. Non ad ogni esecuzione dello shader.
Ora, ripeto per l'ennesima volta, su questo nessuno ha certezze, ma a me sembra ragionevole che una possibile ottimizzazione per fermi possa essere la chiamata di una FMA tutte le volte che il codice richiederebbe una MADD. Questa sostituzione (che ripeto non è neanche una sostituzione, visto che se la cosa funzionasse così le MADD manco sarebbero contemplate) è banale e può essere fatta staticamente dal compilatore del GLSL.
Le ottimizzazioni che invece compie il thread processor/dispatcher o chi per lui sono tutt'altra cosa e presumo contemplino cose tipo il reordino delle istruzioni per l'esecuzione fuori sequenza, in modo da trovarne indipendenti in quantità sufficienti da riempire il più possibile le ALU. Siccome queste cose è evidente che non possono essere fatte a priori prima dell'esecuzione, è ovvio che le deve fare il "silicio" al volo. Ma la FMA invece che la MADD è tutta un'altra storia.
Tra l'altro non penso sia una cosa così speciale. Quando scrivo GLSL non è che scrivo MADD, che di suo è già una ottimizzazsione, visto che è una moltiplicazione seguita da una addizione eseguita in un solo passaggio. Siccome il compilatore che esamina il sorgente guarda le operazioni da svolgere, quando vede una MUl seguita da una ADD dice: "toh, qui visto che ho l'HW per fare una MADD invece che fare una MUL + ADD la faccio" e scrive MADD nel codice compilato. Invece, il compilatore pilotato dai driver del FERMI potrebbe vedere una MUL + ADD e lasciare una MUL + ADD oppure mettere una FMA. Una delle due strade dovrà pur prendere e mi sembra ovvio quale sia la più conveniente.
Poi ci possono essere mille altre ragioni perchè questo non si possa fare, ma sicuramente non è perchè la compilazione avviene al volo durante l'esecuzione dello shader

E se ora non capisci, hai ragione, ma per sfinimento. Spero almeno sia stato utile a qualcun'altro

[yossarian]

Originariamente inviato da skizzo99999999

Non sono un esperto dell'architettura interna delle GPU, per cui non se esattametne dove lo piazzi. Se dovessi azzardare, come ho già detto, penso stiano nella vram, ma cmq sparerei a caso. Comunque qui NVIDIA non deve inventare niente: io sviluppo su una x1600pro e non lo so dove metta tutti gli shader che compila, ma da qualche parte stanno, sono circa una trentina tra fragment e vertex, e li compilo tutti prima di entrare nel loop di rendering durante la fase di caricamento del modello. In tutto occupano 164kb, ma sono i sorgenti GLSL, non ho idea di come valutare l'occupazione del codice compilato

allora, fammi capire; tu sti lavorando su una trentina di shader che hai compilato a manina (pardon hai fatto compilare dal compiler GLSL) e hai fatto girare il codice così compilato su una 1600pro.
Se ho capito male correggimi pure.
Se le cose stanno così, parliamo di poche righe di codice e di un compilatore standard (che non effettua operazioni di replacement). Giustamente dici: se volessi far fare una sostituzione potrei pianificarla a tavolino e inviare al chip il codice già ottimizzato.
Fin qui ok. Ora prova a fare lo stesso ragionamento per tutti i giochi passati, presenti e futuri. Cioè, per ognuno devi far ricompilare il codice facendo le dovute ottimizzazioni. Ogni volta che esce un'espansione faccio la stessa operazione; per una patch idem, ecc ecc. Ovvero, riscrivo tutto il codice dei giochi a beneficio di una sola architettura video? E dove metto questo nuovo codice? Nei driver (da quanti GB)? e dove carico i driver? Nella ram video?
Non è molto più funzionale inserire all'interno dei driver una istruzione del tipo:"ehi ciccio, quando trovi una madd non eseguirla perchè non sei capace; piuttosto pprova con una fma".
In questo modo ho la certezza che qualunque madd, di qualunque gioco presente, passato e futuro, compresnivo di patch, add on e espansioni, sarà rimpiazzata da una fma. Il tutto il poche righe si codice che possono essere caricate on chip (magari nell'instruction cache) all'avvio.
Unico inconveniente è che l'operazione può farla solo la gpu e solo in run time (perdendo un po' di tempo)

[skizzo99999999]

Mi sembra di essere su scherzi a parte... ma dai che adesso ci capiamo. Mi sento che è la volta buona. Tu dici:

Originariamente inviato da yossarian

allora, fammi capire; tu sti lavorando su una trentina di shader che hai compilato a manina (pardon hai fatto compilare dal compiler GLSL) e hai fatto girare il codice così compilato su una 1600pro.
Se ho capito male correggimi pure.

NON HO COMPILATO A MANO GLI SHADER. Ho fatto semplicemente nel codice c del programma, come fanno tutti e nell'unico modo in cui si può fare, una o più chiamate alla glCompileShader con cui si compilano gli shader. Gli shader si usano così non è colpa mia. Giuro.

Originariamente inviato da yossarian

Se le cose stanno così, parliamo di poche righe di codice e di un compilatore standard (che non effettua operazioni di replacement). Giustamente dici: se volessi far fare una sostituzione potrei pianificarla a tavolino e inviare al chip il codice già ottimizzato.
Fin qui ok. Ora prova a fare lo stesso ragionamento per tutti i giochi passati, presenti e futuri. Cioè, per ognuno devi far ricompilare il codice facendo le dovute ottimizzazioni. Ogni volta che esce un'espansione faccio la stessa operazione; per una patch idem, ecc ecc. Ovvero, riscrivo tutto il codice dei giochi a beneficio di una sola architettura video? E dove metto questo nuovo codice? Nei driver (da quanti GB)? e dove carico i driver? Nella ram video?

E' proprio questo lo scopo per cui è nata la compilazione degli shader, cioè NON dover riscrivere il codice. In tutti i giochi (almeno quelli OPENGL) ci saranno chiamate alla glCompileShader. Così se uno gioca ad un gioco di qualche anno fa su una architettura nuova che richiede una particolare ottimizzazione che possa essere fatta staticamente dal compiler, sarà il nuovo driver della scheda (visto che fermi non utilizarà i driver di G80, come G80 non ha utilizzato i driver delle 6800, ecc...) che riceve la chiamata di compilazione ed agisce di conseguenza. Quindi nessuno riscrive niente e siamo tutti felici. E' una idea intelligente. Ovviamente agisce solo sugli shader e non sul codice c/c++ o chi per lui del gioco, ma di schede video stiamo parlando.

[yossarian]

Originariamente inviato da skizzo99999999

Non posso risponderti su cose che non conosco. Ti ripeto quello di cui sono certo ma cercando se possibile di essere più chiaro, visto che SEMBRA che finalmente hai capito il mio/nostro dubbio. L'istruzione che scrivo nel sorgente c (e che quindi compilerà il compilatore c, che esegue la CPU,

ok, quindi siamo arrivati a dire che la cpu compila gli shader ottimizzando per fermi? Perchè dovrebbe? Si tratta di un compiler generico e dove trova mul e add traduce mul e add (che diventa una madd ti dico dopo perchè).

Originariamente inviato da skizzo99999999

che la manderà al driver, il quale ci farà quel piffero che vorrà) che compila il sorgente dello shader è eseguita dal driver della GPU. E' spiegato in tutti i libri su cui ho imparato l'opengl (e confermato tutti i giorni dall'uso della glCompileShader)

cioè la cpu manda al driver gli shader già ottimizzati con la sotituzione? Ma anche no; la cpu manderà il codice compilato senza alcuna ottimizzazione per una particolare architettura: 1) perchè dovrebbe fare la sosittuzione e non, ad esempio, il riordino degli shader? 2) perchè dovrebbe ottimizzare per fermi e non, ad esempio, per GT200 (se lo fa per l'uno non lo fa per l'altro, a meno che non vogliamo pensare che le cpu intel o amd siano gestite dai driver nVidia, ma trovo la cosa talmente ridicola che evito di prenderla in considerazione ).

Originariamente inviato da skizzo99999999

che il fatto che gli shader vengano compilati a runtime e non precompilati prima da una scimmia o quant'altro serve in modo che il compilatore pilotato (o contenuto, non lo so, se tu lo sai che è nella GPU meglio per te) dal driver della scheda video possa ottimizzare il codice per una specifica architettura, in modo che una applicazione scritta prima possa girare in modo ragionevole su una architettura fatta poi. E' evidente che queste ottimizzazioni possono essere di vario genere, e avvengono durante la compilazione,

stai facendo una enorme confuzione tra compilazione da parte di un compiler standard e ricompilazione con ottimizzazioni da parte di un compilatore dedicato; il primo non fa nessuna ottimizzazione e le istruzioni del secondo possono essre caricate SOLO SUL CHIP a cui è destinato E NON SU ALTRI. L'ottimizzazione può avvenire solo in run time.

Originariamente inviato da skizzo99999999

la quale SICURAMENTE avviene prima dell'esecuzione dello shader stesso. Una volta sola. Non ad ogni esecuzione dello shader.

qualcuno ha detto che avviene dopo l'esecuzione?
Avviene prima ma non all'atto della compilazione del compiler standard ma dopo che lo shader è stato caricato all'interno della gpu e la stessa ha potuto leggere le relative istruzioni. Solo allora sa dove intervenire e in che modo (ogni mul e add dello shader deve essere sostituita con una fma). Mi sembra un concetto tanto elementare che mi pare assurdo che si stia a parlarne da due giorni. Un chip non ha nessuna cognizione di ciò che deve fare fino a che qualcuno non gli dice che deve fare qualcosa.

Originariamente inviato da skizzo99999999

Ora, ripeto per l'ennesima volta, su questo nessuno ha certezze, ma a me sembra ragionevole che una possibile ottimizzazione per fermi possa essere la chiamata di una FMA tutte le volte che il codice richiederebbe una MADD.

l'avrai ripetuto cento volte ma mi è sfuggito CHI DOVREBBE FARE LA SOStITUZIONE QUANDO. La cpu in fase di compilazione? Come e perchè? Chi istruisce la cpu sul fatto che deve ottimizzare per fermi ma soprattutto, e mi metto nei panni della cpu, è lecito chiedersi: chi ca@@o è questo fermi per cui mi dovrei sbattere?

Originariamente inviato da skizzo99999999

Questa sostituzione (che ripeto non è neanche una sostituzione, visto che se la cosa funzionasse così le MADD manco sarebbero contemplate) è banale e può essere fatta staticamente dal compilatore del GLSL.
Le ottimizzazioni che invece compie il thread processor/dispatcher o chi per lui sono tutt'altra cosa e presumo contemplino cose tipo il reordino delle istruzioni per l'esecuzione fuori sequenza, in modo da trovarne indipendenti in quantità sufficienti da riempire il più possibile le ALU. Siccome queste cose è evidente che non possono essere fatte a priori prima dell'esecuzione, è ovvio che le deve fare il "silicio" al volo. Ma la FMA invece che la MADD è tutta un'altra storia.
Tra l'altro non penso sia una cosa così speciale. Quando scrivo GLSL non è che scrivo MADD, che di suo è già una ottimizzazsione, visto che è una moltiplicazione seguita da una addizione eseguita in un solo passaggio. Siccome il compilatore che esamina il sorgente guarda le operazioni da svolgere, quando vede una MUl seguita da una ADD dice: "toh, qui visto che ho l'HW per fare una MADD invece che fare una MUL + ADD la faccio" e scrive MADD nel codice compilato. Invece, il compilatore pilotato dai driver del FERMI potrebbe vedere una MUL + ADD e lasciare una MUL + ADD oppure mettere una FMA. Una delle due strade dovrà pur prendere e mi sembra ovvio quale sia la più conveniente.

certo, come no; peccato che se un chip si trova di fronta un'istruzione mul seguita da una add, in qualunque linguaggio, esegue una moltiplicazione con troncamento e una addizione con arrotondamento finale. Proviamo a indovinare perchè?
Vediamo...... forse perchè le pipeline di tipo mul hanno lo stadio che esegue il troncamento alla fine della moltiplicazione e quelle di tipo add hanno quello che esegue l'arrotondamento; e lo fanno automaticamente (basta chiamare l'istruzione: incredibile vero?). E magari anche perchè una istruzione mul seguita da una add non sarà mai interpretata come una fma che richiede una istruzione dedicata (ossia proprio fma). Cercare per credere

Originariamente inviato da skizzo99999999

Poi ci possono essere mille altre ragioni perchè questo non si possa fare, ma sicuramente non è perchè la compilazione avviene al volo durante l'esecuzione dello shader

qualcuno ha detto che non si può fare? Io ho parlato di hit prestazionale dovuto alla necessità di effettuare la sosittuzione in run time (e ribadisco il concetto).

Originariamente inviato da skizzo99999999

E se ora non capisci, hai ragione, ma per sfinimento. Spero almeno sia stato utile a qualcun'altro

mi pare che qui a non capire sia qualcun altro. Eppure sono concetti piuttosto semplici. Non mi interessa avere ragione e non ho tempo da perdere a parlare di cose su cui ho lavorato fino all'altro ieri

[yossarian]

Originariamente inviato da skizzo99999999

Mi sembra di essere su scherzi a parte... ma dai che adesso ci capiamo. Mi sento che è la volta buona. Tu dici:



NON HO COMPILATO A MANO GLI SHADER. Ho fatto semplicemente nel codice c del programma, come fanno tutti e nell'unico modo in cui si può fare, una o più chiamate alla glCompileShader con cui si compilano gli shader. Gli shader si usano così non è colpa mia. Giuro.



E' proprio questo lo scopo per cui è nata la compilazione degli shader, cioè NON dover riscrivere il codice. In tutti i giochi (almeno quelli OPENGL) ci saranno chiamate alla glCompileShader. Così se uno gioca ad un gioco di qualche anno fa su una architettura nuova che richiede una particolare ottimizzazione che possa essere fatta staticamente dal compiler, sarà il nuovo driver della scheda (visto che fermi non utilizarà i driver di G80, come G80 non ha utilizzato i driver delle 6800, ecc...) che riceve la chiamata di compilazione ed agisce di conseguenza. Quindi nessuno riscrive niente e siamo tutti felici. E' una idea intelligente. Ovviamente agisce solo sugli shader e non sul codice c/c++ o chi per lui del gioco, ma di schede video stiamo parlando.

visto che ci siamo capiti (quella della compilazione a manina era una battuta) allora mi dici chi dovrebbe prendersi la briga di effettuare la sostituzione e quando? Escludendo la cpu all'atto della compilazione standard, mi dici cosa resta? O devo pensare che le cpu si prendano la briga di compilare ottimizzando per tutte le architetture possibili e immaginabili, oppure devo pensare che nVidia è fortemente raccomandata. In realtà c'è una terza via, che lo faccia nVidia stessa, quindi non sarà il phenom II o l'I7 a farle questo favore, ma dovrà occuparsene qualcun altro (indovina chi e quando)?
D'altra parte, la situazione non è dissimile da quella dei tempi di NV30, quando si faceva shader replacement sostituendo condice dx9 con codice dx8. Indovina un po' chi si occupava della sostituzione e quando? Il compiler HLSL della cpu prima che il codice fosse inviato alla vga? Sbagliato.

[skizzo99999999]

Originariamente inviato da yossarian

visto che ci siamo capiti (quella della compilazione a manina era una battuta) allora mi dici chi dovrebbe prendersi la briga di effettuare la sostituzione e quando? Escludendo la cpu all'atto della compilazione standard, mi dici cosa resta? O devo pensare che le cpu si prendano la briga di compilare ottimizzando per tutte le architetture possibili e immaginabili, oppure devo pensare che nVidia è fortemente raccomandata. In realtà c'è una terza via, che lo faccia nVidia stessa, quindi non sarà il phenom II o l'I7 a farle questo favore, ma dovrà occuparsene qualcun altro (indovina chi e quando)?
D'altra parte, la situazione non è dissimile da quella dei tempi di NV30, quando si faceva shader replacement sostituendo condice dx9 con codice dx8. Indovina un po' chi si occupava della sostituzione e quando? Il compiler HLSL della cpu prima che il codice fosse inviato alla vga? Sbagliato.

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

[devAngnew]

Originariamente inviato da yossarian

tu insisti a parlare dei compilatori io ti continuo a chiedere: sai come funziona il tutto all'interno di un chip? Il compilatore si trova installato sul chip e può solo dire allo stesso di non eseguire una determinata operazione e sostituirla con un'altra. Ma questo può avvenire solo e soltanto quando il chip incontra quel tipo di operazione. La sostituzione non avviene a priori. Questo significa che l'alu deve prelevare l'istruzione, leggerla (e sono almeno due cicli) e mandarla in esecuzione.......ops, non può perchè deve sostituirla (almeno un altro ciclo). L'alu questa operazione deve farla per tutte le madd che fanno parte del codice che deve elaborare e non la fa una tantum su tutto il gioco. Questo perchè l'alu non sa neppure quante madd ci sono e dove si trovano e, per di più, non è così intelligente da dire; ok, mi ha fregato una volta a ma adesso ogni volta che incontro una madd eseguo una fma senza che nessuno me lo dica .
L'alu sa solo eseguire calcoli; qualcun altro deve dirle che calcoli eseguire e questo qualcun altro deve prima leggere le istruzioni e poi, eventualmente sostituirle prima di mandarle in esecuzione. Il problema è proprio che i registri non compilano perchè altrimenti potrebbero sostituire autonomamente e automaticamente le MADD con le FMA. Qualcun altro deve farlo e lo fa a manina, operazione per operazione e all'interno della gpu. Questo qualcun altro è il thread processor e pure lui deve leggere l eistruzioni una per una prima di decidere cosa farne e a chi affidarle. E se deve effettuare una sostituzione il procedimento è lo stesso (lo sapevi che anche l'unità di controllo centrale lavora con i registri?); preleva un'istruzione così come gli arriva (madd) la legge la sostituisce e la invia ai registri della alu che la deve mandare in esecuzione.
Togliti dalla testa che al chip arrivi il programma già compilato e con le fma al posto delle madd .
Ripeto: questa operaziona va fatta sempre, con tutte le operazioni dello stesso tipo, non è affatto gratuita e non viene eseguita a priori su tutto una tantum

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

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

Oppure che raggruppi un certo tipo di istruzioni o ne separi altre. Con nv30 si arrivava a sostituire codice dx9 (hlsl) con codice dx8 (assembly); chi se ne occupava, il compilatore C For GPU?
Ora, a meno che non abbia a disposizione una path specifica per fermi che contiene FMA al posto di MADD, mi spieghi un compilatore C come fa a tradurre le MADD come FMA? Sto parlando di qualcuno (in senso figurato) che dica materialmente alla gpu che non deve eseguire una madd, come risulterebbe dal linguaggio compilato, ma una fma.
Mi spieghi come avviene questo passaggio a priori su un codice sorgente "sconosciuto" di cui si sa solo che è compilato in C (per cui c'è il compiler standard che traduca mul con moltiplicazione add con addizione e madd con moltiplicazione con troncamento e addizione con arrotondamento).
Magari capisci anche perchè ti ho chiesto dove avvengono le operazioni di fetch and decode (e, in questo caso, di replace)

A questo ho gia risposto nel post precedente (sorry un quote di troppo).

devAngnew

Tu stesso lo hai detto in nv30 era il compilatore per HLSL che traduceva il tutto attraverso vari passaggi in LM adatto all'architettura.
altrimenti se la gpu avesse fatto questa sorta di interpretazione a volo che tu dici avremmo avuto su schermo delle slide e non un video gioco interattivo.

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


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

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



P.S: skizzo99999999 ti consiglio di lasciar perdere.

[Severnaya]

Originariamente inviato da devAngnew

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

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











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


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

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



P.S: skizzo99999999 ti consiglio di lasciar perdere.

http://www.youtube.com/watch?v=4o29VoxtsFk

[Jackaos]

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