[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[yossarian]

Originariamente inviato da Foglia Morta

Magari migliorerà la collaborazione tra nVidia e Epic Games

scherzi? quelli di epic non sono neppure capaci di implementare una path dx10 per il MSAA box su hw dx10 e hanno avuto bisogno dell'intervento dei tecnici di nVidia!

[Andrea deluxe]

Originariamente inviato da Foglia Morta

Hanno ricominciato con i rebrand ?

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

o no!

potrebbe essere la fine delle medie e basse nvidia...

[yossarian]

Originariamente inviato da leoneazzurro

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

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

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

Ditemi se ho cannato qualcosa.

è tutto corretto; anzi, si può aggiungere che le ottimizzazioni si possono fare anche a livello di hal senza arrivare ai driver veri e propri. Tramite hal è possibile, ad esempio, far "credere" ad un determinato hw di avere o non avere determinate funzionalità e farlo agire di conseguenza.
Agendo tramite hal è stato possibile, ad esempio, implementare il MSAA box in BAA solo su hw nVidia (inibendo, in pratica, la rimozione automatica dei poligoni nascosti tipica di un engine deferred in dx9 e facendola precedere dal salvataggio delle geometrie del frame su una texture).
La confusione è nata dal fatto che qui non si parla di compilazione standard ma di eventuali particolari ottimizzazioni per una sola architettura (già per gt200 o g80 sarebbe un disastro) e per specifiche operazioni; le madd in floating point a livello di alu

[skizzo99999999]

Non voglio intromettermi nella diatriba tra devAngnew e yossarian per creare altro casino, quindi spero che quello che dirò cercando di argomentare al mio meglio non generi altro flame, anche se finchè la discussione rimane su toni civili (che mi sembra ci siano ancora) mi sembra sopportabilissima. Premetto che non ho letto l'articolo pluricitato di Rys, ma soltanto i recenti post riguardanti la questione MADD/FMA. Ora io non conosco in modo approfondito l'architettura delle GPU e relative problematiche, e quindi non pretendo di essere la bibbia dell'argomento in questione. Io conosco abbastanza bene l'ambiente OPENGL, che non penso differisca molto (almeno per il problema che ci riguarda al momento) da quello directx.
Quando devo caricare uno shader program (composto, per esempio, sia da fragment che da vertex shader), devo eseguire:

glCreateShader(GL_VERTEX_SHADER);
glCreateShader(GL_FRAGMENT_SHADER);

che servono a "creare" gli shader. Poi un paio di LoadShaderText per caricare i file di testo che contengono il codice GLSL dei 2 shader. Bisogna tenere presente che il GLSL è come il c: è un linguaggio ad alto livello, anche se non così "alto" e così versatile come il c visto che le GPU hanno dei limiti sul codice da poter eseguire. C'è da dire che però le operazioni vettoriali sono molto più semplici in GLSL che in c, ma vabbe... questo è una altro discorso. Tornando in tema, dopo aver caricato i file di testo che contengono i 2 vertex e fragment shader, faccio 2 glCompileShader per compilare gli shader; poi creo un contenitore per per "unire" vertex e fragment in un unico programma tramite la glCreateProgram seguita da 2 glAttachShader (una per il fragment e una per il vertex). Ora mi ritrovo quindi un "programma", compilato, che contiene i 2 shader; rimangono le operazioni di link e validate da eseguire tramite la glLinkProgram e la glValidateProgram, che devono essere eseguite sul nuovo "programma" e non sui 2 shader separati.
Tutta questa sequenza la eseguo soltanto UNA volta durante il caricamento del programma, in cui leggo, compilo, linko, ecc... tutti gli shader che devo eseguire, in modo che se ho sbagliato qualcosa lo so subito e non mi si pianta il programma dopo mezz'ora. Può essere che nei progetti di grosse dimensioni gli shader siano in numero tale che sia preferibile un caricamento differito, ma sicuramente anche se così fosse avverrebbe sempre durante, per esempio, il caricamento di un livello successivo a quello attuale e non quando lo/gli shader li devo effettivamente usare.
Infatti quando li devo utilizzare, mi basta fare una

glUseProgram(GeometryProgram);

per caricare lo shader, già compilato, linkato, ecc... con i passi descritti in precedenza. Se così non fosse, hai voglia a dover ricompilare il GLSL decine di volte durante ogni frame, visto che anche nel mio deferred renderer carico una decina di shader diversi (tramite semplici glUseProgram) a seconda delle fasi di z-culling, geometry stage, light_pass o postprocessing in cui mi trovo...
Concludendo questa lunga introduzione, non mi sembra così impossibile che il compilatore del GLSL, risiedendo nel driver video (di questo ne sono sicuro) e che quindi conosce la scheda video che monta la macchina, possa sostituire durante la compilazione degli shader le MADD con delle FMA. Questo ovviamente tralasciando i problemi relativi alle imprecisioni derivanti dagli arrotondamenti diversi, ma non mi sembra questo il motivo del contendere. Ora (ed è qui il mio dubbio) non so se il codice compilato GLSL corrisponda al codice contenente le MADD MUL, ecc... ma mi sembra ragionevole che se il codice c che viene compilato dal compilatore c (che NON compila anche il codice dello shader, ma solo il sorgente x86, se ovviamente siamo su una macchina x86) diventa un eseguibile, anche il GLSL una volta compilato tramite il compilatore del driver video (tramite i passaggi di cui sopra) diventi un eseguibile per la GPU.
Certo è che come il codice compilato dal c non viene eseguito pari pari dalle CPU, anche il codice compilato dal GLSL non viene eseguito brutalmente, ma viene poi "ottimizzato" per adattarsi meglio all'architettura interna e rendere possibili le esecuzioni fuori sequenza, branch prediction e tutte queste belle cosucce che a livello di compilazione statica sono impossibili o quasi da eseguire.
Quindi non è che se si potesse fare questa benedetta "ottimizzazione" MADD/FMA allora non esisterebbe il problema della ottimizzazione, per esempio, di una architettura per sua natura difficile da struttare in pieno come quella di ATI; devo dire che mi sembrano due problematiche ben differenti. La mera sostituzione di una operazione MADD/FMA è una "ottimizzazione" che coinvolge quella istruzione soltanto, mentre risolvere problemi come la branch prediction, l'esecuzione fuori sequenza oppure gestire il problema di come utilizzare tutte le ALU di rv870 riguarda il trovare le dipendenze fra le istruzioni, il che se mi permettete è tutto un'altro paio di maniche.
Poi per carità un conto è dirlo e un conto è farlo, ma non mi sembra così impossibile che ci riescano senza avere un hit prestazionale.

[Wikkle]

[zorco]

http://www.pctuner.net/news/12560/NV...i-VGA-AMD-ATI/

[eXeS]

Originariamente inviato da yossarian

è tutto corretto; anzi, si può aggiungere che le ottimizzazioni si possono fare anche a livello di hal senza arrivare ai driver veri e propri.

Scusami è, ma l'HAL in quanto strato software è implementato/scritto da qualcuno, questo qualcuno poichè stiamo parlando di DX chi è, la MS, o nVidia ?

Perchè se è la MS mi sembra improbabile che quest'ultima in presenza di fermi ne modifichi l'implementazione, dell'HAL, rimpiazzando la MADD con l'FMA o MUL/ADD, se invece è nVidia allora direi che la cosa dovrebbe essere tecnicamente fattibile ma però ti chiedo, l'HAL per dx quando viene installato, insieme ai driver ?

Originariamente inviato da skizzo99999999

Poi per carità un conto è dirlo e un conto è farlo, ma non mi sembra così impossibile che ci riescano senza avere un hit prestazionale.

Più che altro vien da chiedersi, ammesso che la maggiore precisione risultante da una operazione FMA non rechi problemi, e visto che le due opzioni sono:
-MADD = MUL/ADD
-MADD = FMA
Se c'è un hit prestazionale derivante dalla sostituzione delle operazioni, dovrebbe essere identico a prescindere dal tipo di sostituzione applicata, quindi, perchè si dovrebbe rimpiazzare una MADD con una MUL+ADD, quando la GPU riesce ad eseguire più efficientemente una FMA ?

[devAngnew]

Originariamente inviato da yossarian

ok, ripartiamo da 0 (zero)
Rys butta li una frase in cui afferma che i DRIVER NVIDIA opereranno la trasformazione delle MADD in FMA.
Tu sei partito lancia in resta sostenendo che questa trasformazione sarà for free, dicendo che avverrà una volta per tutte prima del caricamento del gioco e se ne occuperà il compilatore.

Allora
1) io Rys neanche lo leggo al max il nostro forum e poco più tutto è nato dall' articolo e dal grafico di HrdFr. e dalle tue supposizioni.
OK.

Ok, allora immagino saprai che un compilatore C quando trova un'istruzione di tipo MADD la traduce nell'equivalente in linguaggio macchina (MADD non FMA). Quello che deve avvenire è, invece, che queste MADD siano trasformate in FMA. E non è neppure sempre possibile che ciò avvenga perchè in alcuni casi può generare errori.
Allora, mi spieghi chi si occupa di manipolare il codice sorgente per modificare una particolare istruzione e a quale livello avviene questa manipolazione?

Primo un compilatore C se gli dai in input un istruzione o più istruzioni tipo MADD ti restituisce in output una lista di errori che neanche immagini.
Il compilatore accetta solo un sorgente ad HL.
Ma forse intendevi un Assemblatore.

Io tenderei ad escludere un compilatore C generico e, immagino, che se provi a forzare una FMA al posta di una MADD un compilatore ti restituisca un errore (sono due operazioni diverse, nonostante si tratti sempre di moltiplicazioni e addizioni)
Il compilatore di cui parli è quello tipico del linguaggio C (valido per tutte le architetture) che si occupa di tradurre da linguaggio ad alto livello le istruzioni in un linguaggio a basso livello (una madd resta una madd, per intenderci). Questo significa che se ho 1 milione di righe di codice in C il compilatore le avrà trasformate in n milioni di righe in LM. Ma non mi fa ottimizzazioni per quella determinata architettura. Se devo riordinare le istruzioni o devo sostituirle devo intervenire con ottimizzazioni ad hoc in un secondo momento. Ossia devo indicare al chip che quando incontra una determinata istruzione (compilata in LM) la trasformi in un'altra determinata istruzione.

Vedo che inizi ad essere meno sicuro delle tue affermazioni, allora mai sentito parlare degli ottimizzatori (fanno parte del calderone chiamato compilatore) ?
Allora questi ottimizzatori di solito lavorano a livello Assembler ed hanno il compito di ottimizzare il codice generato fino a quel momento per determinate architetture ad es. un codice assembler generico può essere ottimizzato per una data architettura non solo cambiando l'ordine delle istruzione dove possibile ovviamente ma può anche ottimizzare proprio a livello di codice assembler.
Ad esempio un' architettura sa fare solo MUL e ADD mentre un'altra sa fare ADD, MUL e MAD l'ottimizzatore Assembler cosa farà:
Controlla il processore su cui stà lavorando se è il primo
il codice sarà:
ADD
MUL
ecc.

Nel secondo caso invece:

MAD
ecc.

Successivamente avverrà il passaggio finale cioè il codice in LM.
Come vedi la cosa non è cosi immediata e c'è bisogno di memoria per fare ciò.(ricordati dei registri interni della GPU che secondo te compilano)
Ricordati pure che nel mio ragionamento ho detto di tralasciare eventuali problemi di arrotondamento.

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)

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.

Concludo e mi ripeto poichè sei cosi sicuro di come lavora il compilatore delle gpu NVIDIA e ATI forniscimi dei link ufficiali sul loro funzionamamento cosi ti prendi la ragione che vuoi e finisce qui e amici come prima. Non credo di chiedere troppo.
Altrimenti ogniuno rimarrà sulle proprie teorie.

Ciao

[yossarian]

Originariamente inviato da skizzo99999999

Non voglio intromettermi nella diatriba tra devAngnew e yossarian per creare altro casino, quindi spero che quello che dirò cercando di argomentare al mio meglio non generi altro flame, anche se finchè la discussione rimane su toni civili (che mi sembra ci siano ancora) mi sembra sopportabilissima. Premetto che non ho letto l'articolo pluricitato di Rys, ma soltanto i recenti post riguardanti la questione MADD/FMA. Ora io non conosco in modo approfondito l'architettura delle GPU e relative problematiche, e quindi non pretendo di essere la bibbia dell'argomento in questione. Io conosco abbastanza bene l'ambiente OPENGL, che non penso differisca molto (almeno per il problema che ci riguarda al momento) da quello directx.
Quando devo caricare uno shader program (composto, per esempio, sia da fragment che da vertex shader), devo eseguire:

glCreateShader(GL_VERTEX_SHADER);
glCreateShader(GL_FRAGMENT_SHADER);

che servono a "creare" gli shader. Poi un paio di LoadShaderText per caricare i file di testo che contengono il codice GLSL dei 2 shader. Bisogna tenere presente che il GLSL è come il c: è un linguaggio ad alto livello, anche se non così "alto" e così versatile come il c visto che le GPU hanno dei limiti sul codice da poter eseguire. C'è da dire che però le operazioni vettoriali sono molto più semplici in GLSL che in c, ma vabbe... questo è una altro discorso. Tornando in tema, dopo aver caricato i file di testo che contengono i 2 vertex e fragment shader, faccio 2 glCompileShader per compilare gli shader; poi creo un contenitore per per "unire" vertex e fragment in un unico programma tramite la glCreateProgram seguita da 2 glAttachShader (una per il fragment e una per il vertex). Ora mi ritrovo quindi un "programma", compilato, che contiene i 2 shader; rimangono le operazioni di link e validate da eseguire tramite la glLinkProgram e la glValidateProgram, che devono essere eseguite sul nuovo "programma" e non sui 2 shader separati.
Tutta questa sequenza la eseguo soltanto UNA volta durante il caricamento del programma, in cui leggo, compilo, linko, ecc... tutti gli shader che devo eseguire, in modo che se ho sbagliato qualcosa lo so subito e non mi si pianta il programma dopo mezz'ora. Può essere che nei progetti di grosse dimensioni gli shader siano in numero tale che sia preferibile un caricamento differito, ma sicuramente anche se così fosse avverrebbe sempre durante, per esempio, il caricamento di un livello successivo a quello attuale e non quando lo/gli shader li devo effettivamente usare.
Infatti quando li devo utilizzare, mi basta fare una

glUseProgram(GeometryProgram);

per caricare lo shader, già compilato, linkato, ecc... con i passi descritti in precedenza. Se così non fosse, hai voglia a dover ricompilare il GLSL decine di volte durante ogni frame, visto che anche nel mio deferred renderer carico una decina di shader diversi (tramite semplici glUseProgram) a seconda delle fasi di z-culling, geometry stage, light_pass o postprocessing in cui mi trovo...
Concludendo questa lunga introduzione, non mi sembra così impossibile che il compilatore del GLSL, risiedendo nel driver video (di questo ne sono sicuro) e che quindi conosce la scheda video che monta la macchina, possa sostituire durante la compilazione degli shader le MADD con delle FMA. Questo ovviamente tralasciando i problemi relativi alle imprecisioni derivanti dagli arrotondamenti diversi, ma non mi sembra questo il motivo del contendere. Ora (ed è qui il mio dubbio) non so se il codice compilato GLSL corrisponda al codice contenente le MADD MUL, ecc... ma mi sembra ragionevole che se il codice c che viene compilato dal compilatore c (che NON compila anche il codice dello shader, ma solo il sorgente x86, se ovviamente siamo su una macchina x86) diventa un eseguibile, anche il GLSL una volta compilato tramite il compilatore del driver video (tramite i passaggi di cui sopra) diventi un eseguibile per la GPU.
Certo è che come il codice compilato dal c non viene eseguito pari pari dalle CPU, anche il codice compilato dal GLSL non viene eseguito brutalmente, ma viene poi "ottimizzato" per adattarsi meglio all'architettura interna e rendere possibili le esecuzioni fuori sequenza, branch prediction e tutte queste belle cosucce che a livello di compilazione statica sono impossibili o quasi da eseguire.
Quindi non è che se si potesse fare questa benedetta "ottimizzazione" MADD/FMA allora non esisterebbe il problema della ottimizzazione, per esempio, di una architettura per sua natura difficile da struttare in pieno come quella di ATI; devo dire che mi sembrano due problematiche ben differenti. La mera sostituzione di una operazione MADD/FMA è una "ottimizzazione" che coinvolge quella istruzione soltanto, mentre risolvere problemi come la branch prediction, l'esecuzione fuori sequenza oppure gestire il problema di come utilizzare tutte le ALU di rv870 riguarda il trovare le dipendenze fra le istruzioni, il che se mi permettete è tutto un'altro paio di maniche.
Poi per carità un conto è dirlo e un conto è farlo, ma non mi sembra così impossibile che ci riescano senza avere un hit prestazionale.

finalmente, al termine della vicenda, è venuto fuori dove si trova questo benedetto compilatore
Quello che hai detto è tuto giusto e infatti è quello che avviene. Ma un conto è scrivere codice dicendo:"al posto dell'istruzione x esegui l'istruzione y", un altro è fare in modo che questo avvenga senza hit prestazionali.
Tu hai descritto quello che si fa quando si opera uno shader replacement o anche la semplice sostituzione di un'istruzione, a livello di compilatore. Però il codice che arriva alla gpu non è scritto, nel caso specifico con l'istruzione y ma arriva con l'istruzione x; la gpu si accorge che gli è arrivata l'istruzione x solo dopo che l'ha prelevata, l'ha letta e l'ha decodificata. Finchè non capisce di cosa si tratta non può operare nessun tipo di sostituzione. Però sa che non deve eseguire l'istruzione x, quindi quando legge x la rimpiazza con y e questo deve farlo per tutte le x presenti nel programma. Ora, ragionando terra terra, all'interno di un chip ogni step richiede almeno un ciclo di clock. Quindi se "prelevo l'istruzione x dal registro, e la decodifico" ho impiegato almeno due cicli (uno per prendere l'istruzione e l'atro per leggerla). Se devo mandarla in esecuzione impiegherò almeno un altro ciclo. Se devo sostituirla anche (perchè quello che leggo è x non y e la trasformazione di x in y non è gratuita).
Quindi, un hit prestazionale per effettuare la sostituzione dell'istruzione comunque ci sarà.

[yossarian]

Originariamente inviato da eXeS

Scusami è, ma l'HAL in quanto strato software è implementato/scritto da qualcuno, questo qualcuno poichè stiamo parlando di DX chi è, la MS, o nVidia ?

Perchè se è la MS mi sembra improbabile che quest'ultima in presenza di fermi ne modifichi l'implementazione, dell'HAL, rimpiazzando la MADD con l'FMA o MUL/ADD, se invece è nVidia allora direi che la cosa dovrebbe essere tecnicamente fattibile ma però ti chiedo, l'HAL per dx quando viene installato, insieme ai driver ?

l'HAL è scritto da nVidia perchè presuppone la conoscenza dell'hardware a cui fa riferimento ed è uno strato intermedio che si installa insieme ai driver. Serve proprio per fare una serie di ottimizzazioni per una specifica architettura senza dover intervenire a livello di driver.

[yossarian]

Originariamente inviato da devAngnew

Allora
1) io Rys neanche lo leggo al max il nostro forum e poco più tutto è nato dall' articolo e dal grafico di HrdFr. e dalle tue supposizioni.
OK.



Primo un compilatore C se gli dai in input un istruzione o più istruzioni tipo MADD ti restituisce in output una lista di errori che neanche immagini.
Il compilatore accetta solo un sorgente ad HL.
Ma forse intendevi un Assemblatore.





Vedo che inizi ad essere meno sicuro delle tue affermazioni, allora mai sentito parlare degli ottimizzatori (fanno parte del calderone chiamato compilatore) ?
Allora questi ottimizzatori di solito lavorano a livello Assembler ed hanno il compito di ottimizzare il codice generato fino a quel momento per determinate architetture ad es. un codice assembler generico può essere ottimizzato per una data architettura non solo cambiando l'ordine delle istruzione dove possibile ovviamente ma può anche ottimizzare proprio a livello di codice assembler.
Ad esempio un' architettura sa fare solo MUL e ADD mentre un'altra sa fare ADD, MUL e MAD l'ottimizzatore Assembler cosa farà:
Controlla il processore su cui stà lavorando se è il primo
il codice sarà:
ADD
MUL
ecc.

Nel secondo caso invece:

MAD
ecc.

Successivamente avverrà il passaggio finale cioè il codice in LM.
Come vedi la cosa non è cosi immediata e c'è bisogno di memoria per fare ciò.(ricordati dei registri interni della GPU che secondo te compilano)
Ricordati pure che nel mio ragionamento ho detto di tralasciare eventuali problemi di arrotondamento.



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.

Concludo e mi ripeto poichè sei cosi sicuro di come lavora il compilatore delle gpu NVIDIA e ATI forniscimi dei link ufficiali sul loro funzionamamento cosi ti prendi la ragione che vuoi e finisce qui e amici come prima. Non credo di chiedere troppo.
Altrimenti ogniuno rimarrà sulle proprie teorie.

Ciao

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

[eXeS]

Originariamente inviato da yossarian

l'HAL è scritto da nVidia perchè presuppone la conoscenza dell'hardware a cui fa riferimento ed è uno strato intermedio che si installa insieme ai driver. Serve proprio per fare una serie di ottimizzazioni per una specifica architettura senza dover intervenire a livello di driver.

Ok, allora aggangiandomi al post di leoneazzurro quale vantaggio si avrebbe nell'implementare il replace della MADD a livello di HAL piuttosto che a livello di driver ?
Un'altra domanda, ma qual'è la differenza tra HAL e driver, visto che di fatto forniscono ambedue gli strati un'interfaccia con l'hardware sottostante ?

[yossarian]

Originariamente inviato da eXeS

Più che altro vien da chiedersi, ammesso che la maggiore precisione risultante da una operazione FMA non rechi problemi, e visto che le due opzioni sono:
-MADD = MUL/ADD
-MADD = FMA
Se c'è un hit prestazionale derivante dalla sostituzione delle operazioni, dovrebbe essere identico a prescindere dal tipo di sostituzione applicata, quindi, perchè si dovrebbe rimpiazzare una MADD con una MUL+ADD, quando la GPU riesce ad eseguire più efficientemente una FMA ?

infatti l'hit prestazionale derivante dalla sostituzione è identico. Nel caso di fermi, a parità di qualità (ovvero qualora le fma non generino artefatti) è sicuramente conveniente la sostituzione con fma che non con mul+add (che richiederebbero due passate mentre una fma si fa in single pass)

[Iantikas]

Originariamente inviato da eXeS

Scusami è, ma l'HAL in quanto strato software è implementato/scritto da qualcuno, questo qualcuno poichè stiamo parlando di DX chi è, la MS, o nVidia ?

Perchè se è la MS mi sembra improbabile che quest'ultima in presenza di fermi ne modifichi l'implementazione, dell'HAL, rimpiazzando la MADD con l'FMA o MUL/ADD, se invece è nVidia allora direi che la cosa dovrebbe essere tecnicamente fattibile ma però ti chiedo, l'HAL per dx quando viene installato, insieme ai driver ?


Più che altro vien da chiedersi, ammesso che la maggiore precisione risultante da una operazione FMA non rechi problemi, e visto che le due opzioni sono:
-MADD = MUL/ADD
-MADD = FMA
Se c'è un hit prestazionale derivante dalla sostituzione delle operazioni, dovrebbe essere identico a prescindere dal tipo di sostituzione applicata, quindi, perchè si dovrebbe rimpiazzare una MADD con una MUL+ADD, quando la GPU riesce ad eseguire più efficientemente una FMA ?

MADD = MUL/ADD si, ma MADD nn'è uguale a FMA...FMA è anke + preciso xkè arrotonda alla fine ma il problema è ke il risultato è diverso (almeno questo è quello ke ho capito )...


...l'articolo di hardware.fr alla fine dava la metà delle prestazioni in FP32 MADD a fermi xkè doveva stostituire le madd in mul e add in modo da ottenere un risultanto equivalente e questo appunto xkè fermi x scelta di nvidia (x contenere i costi di produzione) perde la capacità di elaborare le madd in favore delle fma...


...l'articolo di rys nn ho capito in base a cosa afferma ke le madd vengono sostituite in fma, il diverso risultato nn comporta alcun problema e questa sostituzione nn ha alcun impatto prestazionale...


...da qui mi sembra nata l'intera discussione...e ke dire...spero riusciate a risolvere l'annoso dilemma

[yossarian]

Originariamente inviato da eXeS

Ok, allora aggangiandomi al post di leoneazzurro quale vantaggio si avrebbe nell'implementare il replace della MADD a livello di HAL piuttosto che a livello di driver ?
Un'altra domanda, ma qual'è la differenza tra HAL e driver, visto che di fatto forniscono ambedue gli strati un'interfaccia con l'hardware sottostante ?

l'HAL è uno strato che viene aggiunto dal sw installato anche se è scritto dal produttore dell'hardware. Ad esempio, un sistema operaztivo conterrà di versi HAL per ciascun tipo di dispositivo con cui è destinato a interfacciarsi. Il produttore di hw può fornire le specifiche del proprio prodotto alla swhouse, oppure collaborare con essa o scrivere per lei la parte relativa all'hal dei propri prodotti. Lo stesso dicasi per eventuali SW che girano su un determinato hw; anche questi pososno essere dotati di hal per aumentare la compatibilità con lo stesso hw o di più hal per migliorarne la portabilità.
In pratica tutte le operazioni di un OS, anche le più semplici, sono svolte tramite il ricorso agli hal contenuti al suo interno.
A livello di ottimizzazione, si può forzare un hal a fare o non fare determinate cose.
Questo senza intervenire a livello più basso (cioè di driver)

[eXeS]

Originariamente inviato da yossarian

infatti l'hit prestazionale derivante dalla sostituzione è identico. Nel caso di fermi, a parità di qualità (ovvero qualora le fma non generino artefatti) è sicuramente conveniente la sostituzione con fma che non con mul+add (che richiederebbero due passate mentre una fma si fa in single pass)

Mi sa che non hai letto attentamente il post di skizzo99999999

1) Il gioco parte
2) Carica il codice shader
3) Compila lo shader

A questo punto il codice di un gioco è tipicamente un loop di questo tipo

a) Interpreta input
b) Sposta oggetti, telecamere ecc...
c) Renderizza scena (usando fra le altre cose lo shader compilato al punto 3)
d) Torna al punto a

Poichè Il replace verrebbe fatto al punto 3), e lo shader compilato contiene già le istruzioni che la GPU è in grado di interpretare, l'hit prestazionale si avrebbe solamente durante l'avvio del gioco.

[skizzo99999999]

Originariamente inviato da yossarian

finalmente, al termine della vicenda, è venuto fuori dove si trova questo benedetto compilatore
Quello che hai detto è tuto giusto e infatti è quello che avviene. Ma un conto è scrivere codice dicendo:"al posto dell'istruzione x esegui l'istruzione y", un altro è fare in modo che questo avvenga senza hit prestazionali.
Tu hai descritto quello che si fa quando si opera uno shader replacement o anche la semplice sostituzione di un'istruzione, a livello di compilatore. Però il codice che arriva alla gpu non è scritto, nel caso specifico con l'istruzione y ma arriva con l'istruzione x; la gpu si accorge che gli è arrivata l'istruzione x solo dopo che l'ha prelevata, l'ha letta e l'ha decodificata. Finchè non capisce di cosa si tratta non può operare nessun tipo di sostituzione. Però sa che non deve eseguire l'istruzione x, quindi quando legge x la rimpiazza con y e questo deve farlo per tutte le x presenti nel programma. Ora, ragionando terra terra, all'interno di un chip ogni step richiede almeno un ciclo di clock. Quindi se "prelevo l'istruzione x dal registro, e la decodifico" ho impiegato almeno due cicli (uno per prendere l'istruzione e l'atro per leggerla). Se devo mandarla in esecuzione impiegherò almeno un altro ciclo. Se devo sostituirla anche (perchè quello che leggo è x non y e la trasformazione di x in y non è gratuita).
Quindi, un hit prestazionale per effettuare la sostituzione dell'istruzione comunque ci sarà.

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

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

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

[yossarian]

Originariamente inviato da eXeS

Mi sa che non hai letto attentamente il post di skizzo99999999

1) Il gioco parte
2) Carica il codice shader
3) Compila lo shader

A questo punto il codice di un gioco è tipicamente un loop di questo tipo

a) Interpreta input
b) Sposta oggetti, telecamere ecc...
c) Renderizza scena (usando fra le altre cose lo shader compilato al punto 3)
d) Torna al punto a

Poichè Il replace verrebbe fatto al punto 3), e lo shader compilato contiene già le istruzioni che la GPU è in grado di interpretare, l'hit prestazionale si avrebbe solamente durante l'avvio del gioco.

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

[yossarian]

Originariamente inviato da skizzo99999999

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

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

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

il driver della gpu che agisce sulla cpu? Non credo proprio . La cpu non si occupa di rendering ma solo di inviare i dati iniziali sui vertici del frame e, al massimo, di fisica e IA; e poi non ha senso anche solo pensare che il driver di una periferica agisca su un'altra. Inoltre questo tipo di operazione deve essere selettiva. Immagina che si convertano tutte la madd in fma e si faccia girare il tutto su g80 . Perchè sia selettiva si deve operare a livello di hal o di dirver del chip specifico (quindi, anche all'interno degli stessi driver, ci devono essere istruzioni dedicate al solo fermi) e non di tutta la famiglia (driver unificati? ).
L'unico modo è farlo all'interno della gpu; non propriammente al volo ma su quella porzione di codice chge di volta in volta si carica negli instruction buffer del thread processor. Non c'è altro modo. In tal caso si riduce l'hit prestazionale, a parte il blocco iniziale, perchè si maschera in parte grazie al multithraeding (ma questo lo sto dicendo da un pezzo)

Capisco che sia tu che devAngnew troviate strano tutto ciò, ma le cose stanno proprio così. Il motivo per cui ho citato le difficoltà di ottimizzazione per i chip ATi è anche questo. Tu pensi che se si possa avere accesso all'intero codice e lo si possa ottimizzare tutto insieme, sia così difficile trovare 5 istruzioni indipendenti facenti parte di uno stesso thread che tengano impegnate le 5 alu vliw di RV770 o RV870? Immagina come lo è quando devi fare la stessa operazione lavorando solo su una porzione ridotta di codice.

[skizzo99999999]

Originariamente inviato da yossarian

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

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.. Alla fine ho i capelli bianchi ma gli shader sono compilati e ci sono già TUTTE le FMA al posto delle MADD (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