[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[ironman72]

Sto seguendo con interesse questo thread , siete tutti molto competenti, e le varie ipotesi su come andra' Fermi sono interessantissime!
Ma alla fine lo sapremo solo vivendo.....!!!
Spero alla fine sia il mostro che tutti si aspettano, anche se la mia gtx275 avra' vita ancora mooolto lunga nel mio case!!!!!!!
ciao

[devAngnew]

non c'è da aprire un bel niente e non è una battaglia: tu sostieni che il compilatore sia in grado di fare una volta per tutte il lavoro di traduzione del codice, per cui, tornando in topic, una volta caricato il primo frame GT300 ha già tutte le madd del sw trasformate in fma e non c'è overhead se non all'atto del caricamento del primo frame. Evidentemente a te risulta che tutto il programma venga memorizzato nei registri interni, perchè se così non fosse, il processore non avrebbe alcuna informazione su ciò che è immagazzinato nella memoria centrale o nella vram.
Poi, tiri in ballo i compilatori per i linguaggi ad alto livello che hanno la funzione principale di fare da interfaccia tra linguaggi strutturato e linguaggio macchina, ossia, man mano che arrivano le istruzioni, ad esempio, il hlsl, le traducono in linguaggio macchina (la cosa non è così immediata ma sto semplificando).
E ancora non vedo in che modo possa avvenire la trasformazione simultanea di tutte le madd in fma.


Bhe stavo scherzando a quanto pare tu la presa troppo sul serio...

Secondo la risposta te la sei data già in parte da solo e se rileggi bene ciò che ho scritto io l'avevo già detto e cioè il compilatore ad alto livello (HL) traduce il codice in linguaggio macchina (da ora ASM) e sostituisce le MAD con FMA. Il fatto è che tu dici che la compilazione avviene mano mano da alto livello ad ASM mentre io sostengo l'opposto cioè una volta per tutte.


Ti ho chiesto di spiegare in dettaglio come funziona un'elaborazione da parte di un chip e, soprattutto, come è gestito il flusso di dati (ma non mi pare di aver ottenuto risposte). Ti ho chiesto per quale motivo, se le cose stanno come dici, i chip ATi, ma anche quelli nVidia, non raggiungono il 100% del loro potenziale di calcolo teorico (ma non hai risposto).


I chip Ati ed Nvidia non raggiungeranno mai il 100% dell'utilizzo ma ciò vale anche per le CPU Intel ed AMD non esiste ovvero non può esistere un processore che si adatti a qualunque codice è una questione strutturale del/dei chip e non c'è compilatore che tenga.


Ti ho chiesto di linkarmi un solo documento in cui si dica che l'operazione di cui continui a parlare sia possibile e soprattutto che lo sia senza problemi e senza performance hit ma ti sei guardato bene dal farlo (forse perchè non ne esistono :D ).


Sul fatto modifica codice ed esecuzione del codice senza problemi io stesso ho detto di mettere da parte tutto ciò rilleggi pagine precedenti :read:
A questo punto l'unico vero hit è quello di esecuzione della FMA e basta.
visto che tutto si risolve a compiler time.



A questo punto ti faccio una domanda secca: secondo te è possibile trasformare tutte la madd di un intero programma in fma in un solo passaggio all'atto del caricamento del primo frame di un gioco e se si come e dove avverrebbe questa trasformazione?
E' una domanda semplice che richiede una risposta altrettanto elementare e per nulla articolata (come vedi non serve un thread apposito) :D

Non all'atto del caricamento del 1mo frame ma prima e lo fara il compiler che traduce da HL ad ASM.

[yossarian]

Potrei anche azzardarmi a dire: appunto.

L'unico modo per ottenere quello che dici è che il software venga scritto con due codepath distinti, di cui uno per tutte le VGA e uno per il solo Fermi. Siamo più vicini a "impossibile" che a "improbabile" nella mia personale classificazione delle assurdità...

è quello che sto cercando di spiegargli da un pezzo; ossia che per avere le stesse performance senza perdita di cicli per la trasformazione delle istruzioni, il codice deve essere nativamente compilato in fma; il che significa che, a parte le nuove gpu dx11, esclude tutte il resto del parco macchine dalla possibilità di elaborarlo (ci sarebbe GT200 ma andrebbe come una riva tnt :D ). Oppure, come dici, qualcuno si dovrebbe prendere la briga di creare un code path apposito per fermi che sarebbe sfruttata anche da rv870

[devAngnew]

Potrei anche azzardarmi a dire: appunto.

L'unico modo per ottenere quello che dici è che il software venga scritto con due codepath distinti, di cui uno per tutte le VGA e uno per il solo Fermi. Siamo più vicini a "impossibile" che a "improbabile" nella mia personale classificazione delle assurdità...

Ma i compilatori cosa sono stati inventati a fare ... secondo te uno shader SM 3 ha diversi path per architetture 68xx e G80 e derivati.
Io dico di no, ma cade tutto nelle mani del compilatore che ottimizza per ogni gpu (ovviamente fino ad un certo punto).

[PConly92]

tutta questa potenza in ambito gaming sarà INUTILE, visto che tutti i giochi pc sono solo porting con qualche effetto in più.
vi ricordate la gpu di x360, cioè una simile a radeon 1950xt:mad:
invece se parliamo di gpu computing è un altro discorso.
ps. secondo me una 5850 bastera fino alla prossima gen di console;)
tutto secondo il mio modesto parere, correggettemi se sbaglio...

[Iantikas]

cmq pare ke l'attesa sarà inferiore del marzo di cui si parlava prima...magari nn x avere realmente le gpu in commercio ma almeno x un lancio con soli i benchmarck forse basta aspettare fino a fine gennaio...


...x allora tra gioki e bench dx11 ce ne sarà una buona manciata e vedremo come se la caverà fermi con dx11 e tasselation e anke con gli attuali titoli dx9/dx10...


...aldilà di tutte le perplessità nate in questi giorni se fermi uscirà (se nn lo ritardano ulteriormente dato ke alcuni siti danno anke la data di marzo come ampiamente ottimistica) credo sarà superiore ad una hd5870 così come una gtx280 lo era nei confronti di una hd4870 o magari qualcosina in +...


...già così nn sarebbe grankè come risutato e meno di così sarebbe totalmente inaccettabile sia x il ritardo accumulato ke x la complessità e i costi del chip...


...ciao

[yossarian]

Ma i compilatori cosa sono stati inventati a fare ... secondo te uno shader SM 3 ha diversi path per architetture 68xx e G80 e derivati.
Io dico di no, ma cade tutto nelle mani del compilatore che ottimizza per ogni gpu (ovviamente fino ad un certo punto).

mi riquoto: rispondi a questa semplice domanda, senza girarci troppo attorno?

secondo te è possibile trasformare tutte la madd di un intero programma in fma in un solo passaggio all'atto del caricamento del primo frame di un gioco e se si come e dove avverrebbe questa trasformazione?

[ippo.g]

allora?
sarà tutto emulato via software? :asd:
faranno tutto i driver? potremo fare a meno della scheda video finalmente? :sofico:

[Kharonte85]

allora?
sarà tutto emulato via software? :asd:
faranno tutto i driver? potremo fare a meno della scheda video finalmente? :sofico:
Sì, le ultime voci dicono che Fermi verrà commercializzato con un software su DVD che traduce in tempo reale i MAD in FMA.


PS: cronometriamo quanto ci mette Fud a riportare la notizia...:asd:

[persa]

PS: cronometriamo quanto ci mette Fud a riportare la notizia...:asd:

:rotfl:

[Kharonte85]

:rotfl:

Tu ridi ma una volta successe davvero...il mai abbastanza compianto Mister Tarpone (:( ) creo' un grafico fake e dopo poco tempo la notizia era su Fudzilla...che risate :asd:

A proposito dato che lo nominaimo:



Nvidia believes ATI doesn't ship many HD 5xx0 chips

Written by Fuad Abazovic
Tuesday, 24 November 2009 10:11

Same supplier

http://www.fudzilla.com/images/stories/Logos/nvidia.gif

Sources close to Nvidia believe that ATI is not shipping enough Radeon HD 5xx0 series cards to make any big impact on the intended market. Nvidia's pride is hurt as ATI is the fastest kid on the block, but Nvidia still insists that its sales are good and that it sells everything it has.

It appears that Nvidia had sold all its old chips and because it wants to clear inventories before Fermi comes out, it plans to keep quiet until the launch date. It is important to keep in mind that Nvidia and ATI are both ordering from TSMC and both firms know many wafers the other gets.

Nvidia also faces major shortages of its 55nm GT200b cards, but the supply and sales of 40nm Geforce GT 240 are showing in quite a few pre-holiday details, at least in European OEM sales numbers. We have also learned that Nvidia's 40nm mobile chip sales are doing fine at this point.

Part of the story is that Nvidia claims ATI is facing the shortages. However, judging by the company's already announced Fermi spec, if it can bring good quantities at the right clock speeds, then Fermi GF100 may just lever it the winning hand. However, this would only happen in January 2010 if Fermi doesn't get delayed any further.

http://www.fudzilla.com/content/view/16547/65/



:D

[persa]

cavolo :rotfl: e ma se questo sito le fonti le pesca così allora veramente, attendibilità 0 :sofico:

[Gabriyzf]

Tu ridi ma una volta successe davvero...il mai abbastanza compianto Mister Tarpone (:( ) creo' un grafico fake e dopo poco tempo la notizia era su Fudzilla...che risate :asd:



:D

giura! :eek: :sofico:

non ci credo :ciapet: :fagiano:

[devAngnew]

Bhe stavo scherzando a quanto pare tu la presa troppo sul serio...

Secondo la risposta te la sei data già in parte da solo e se rileggi bene ciò che ho scritto io l'avevo già detto e cioè il compilatore ad alto livello (HL) traduce il codice in linguaggio macchina (da ora ASM) e sostituisce le MAD con FMA. Il fatto è che tu dici che la compilazione avviene mano mano da alto livello ad ASM mentre io sostengo l'opposto cioè una volta per tutte.



I chip Ati ed Nvidia non raggiungeranno mai il 100% dell'utilizzo ma ciò vale anche per le CPU Intel ed AMD non esiste ovvero non può esistere un processore che si adatti a qualunque codice è una questione strutturale del/dei chip e non c'è compilatore che tenga.



Sul fatto modifica codice ed esecuzione del codice senza problemi io stesso ho detto di mettere da parte tutto ciò rilleggi pagine precedenti :read:
A questo punto l'unico vero hit è quello di esecuzione della FMA e basta.
visto che tutto si risolve a compiler time.




Non all'atto del caricamento del 1mo frame ma prima e lo fara il compiler che traduce da HL ad ASM.

mi riquoto: rispondi a questa semplice domanda, senza girarci troppo attorno?




Bhe penso di aver risposto vedi sopra.
Altrimenti se pensi che ho dei concetti errati sui compilatori spiega dove sbaglio.

[devAngnew]

Tu ridi ma una volta successe davvero...il mai abbastanza compianto Mister Tarpone (:( ) creo' un grafico fake e dopo poco tempo la notizia era su Fudzilla...che risate :asd:





:D

Ma come mai Mister Tarpone non è più sul forum ?

[yossarian]

Bhe penso di aver risposto vedi sopra.
Altrimenti se pensi che ho dei concetti errati sui compilatori spiega dove sbaglio.

l'operazione di decode avviene on chip; a meno che non si carichi tutto il codice negli instruction buffer della gpu è impossibile che la traduzione e la sostituzione avvengano nello stesso istante per tutte le righe di codice del programma. Hai idea di quanto dovrebbero essere grandi questi buffer per contenere tutte le righe di codice di un gioco? Il compilatore è caricato sulla gpu, per la cronaca e non ha accesso diretto alla vram

[okorop]

Questo per la versione high-end. La versione mainstream consiste invece in un CD con i driver e un BIOS più un etichetta con scritto sopra GeForce 360 da attaccare sulla propria 8800GT, 8800GTS 512, 9800GT, 9800GTX, 9800GTX+ o GTS250.

:asd:

ma lol questa era cattiva e mi auguro che non sia cosi

[Iantikas]

Questo per la versione high-end. La versione mainstream consiste invece in un CD con i driver e un BIOS più un etichetta con scritto sopra GeForce 360 da attaccare sulla propria 8800GT, 8800GTS 512, 9800GT, 9800GTX, 9800GTX+ o GTS250.

:asd:

LOL...con questa mi sto ancora rotolando a terra :rotfl:

[cristch]

Tu ridi ma una volta successe davvero...il mai abbastanza compianto Mister Tarpone (:( ) creo' un grafico fake e dopo poco tempo la notizia era su Fudzilla...che risate :asd:

A proposito dato che lo nominaimo:



:D

perchè che è successo a Mister Tarpone??effettivamente è un pò che non lo vedo sul forum

[devAngnew]

l'operazione di decode avviene on chip; a meno che non si carichi tutto il codice negli instruction buffer della gpu è impossibile che la traduzione e la sostituzione avvengano nello stesso istante per tutte le righe di codice del programma. Hai idea di quanto dovrebbero essere grandi questi buffer per contenere tutte le righe di codice di un gioco? Il compilatore è caricato sulla gpu, per la cronaca e non ha accesso diretto alla vram

Innanzitutto io non parlavo di compilare a volo tutti gli shader del gioco intero ma solo del livello eseguito.
Bhe mi sembra alquanto strano che il compilatore sia cosi limitato visto il passaggio da linguaggio HL ad ASM ciò comporta l'uso di una certa quantità di memoria anche perchè tale passaggio non è 1:1 ma avvengono prima dei passaggi intermedi. A meno che il compilatore non usi la RAM di sistema e non VRAM come deposito delle istruzioni compilate.
A questo punto dovresti fornire delle fonti che riportino tali limitazioni.

[Kharonte85]

cavolo :rotfl: e ma se questo sito le fonti le pesca così allora veramente, attendibilità 0 :sofico:

giura! :eek: :sofico:

non ci credo :ciapet: :fagiano:
Yes :D
Ma come mai Mister Tarpone non è più sul forum ?
perchè che è successo a Mister Tarpone??effettivamente è un pò che non lo vedo sul forum
Si è fatto cancellare l'account credo per una sospensione che non riteneva giusta. Non posta più.
Questo per la versione high-end. La versione mainstream consiste invece in un CD con i driver e un BIOS più un etichetta con scritto sopra GeForce 360 da attaccare sulla propria 8800GT, 8800GTS 512, 9800GT, 9800GTX, 9800GTX+ o GTS250.

:asd:
:rotfl: A me direbbe bene potrei passare ad una 360 senza nemmeno aprire il case...:asd:

[Bastoner]

Si è fatto cancellare l'account credo per una sospensione che non riteneva giusta. Non posta più.



Veramente poi si è riscritto ed è stato bannato.

[persa]

:rotfl: A me direbbe bene potrei passare ad una 360 senza nemmeno aprire il case...:asd:

e non sarebbe male :sofico:

[okorop]

e non sarebbe male :sofico:

contenti voi contenti tutti, sta di fatto che la fascia media nvida non è cambiata da 2 anni a questa parte........ :rolleyes:
per quanto riguarda la 360 be di 360 per ora c'è ne solo una ed è microsoft :asd:

per quanto riguarda il compilatore di fermi volevo dire che non è che lavori cosi bene visto che ci sono artefatti notevoli, ed è proprio sto problema che ha stoppato la produzione e commercializzazione della gtx380

[persa]

contenti voi contenti tutti, sta di fatto che la fascia media nvida non è cambiata da 2 anni a questa parte........ :rolleyes:
per quanto riguarda la 360 be di 360 per ora c'è ne solo una ed è microsoft :asd:

per quanto riguarda il compilatore di fermi volevo dire che non è che lavori cosi bene visto che ci sono artefatti notevoli, ed è proprio sto problema che ha stoppato la produzione e commercializzazione della gtx380

x la fascia media l'ho scritto pagine fa xchè non l'ha cambiata per lungo tempo.

xchè non c'era bisogno e non gli conveniva neanche. xchè penso che fare un 9600 o un gts250 con architettura gt200, non avrebbe portato nessun miglioramento rispetto al g92. ne come prestazioni e ne come innovazione (sempre dx10)

[Iantikas]

cavolo ma veramente?...


...in effetti era da un pò ke nn l'incontravo ma col fatto ke oramai frequento il forum a periodi, quando spesso quando raramente, nn c'avevo fatto caso...


...di certo il forum senza di lui è un posto + tetro e lugubre :(

[persa]

cavolo allora avrei voluto conoscerlo :D

[yossarian]

Innanzitutto io non parlavo di compilare a volo tutti gli shader del gioco intero ma solo del livello eseguito.


innanzitutto fino a poco fa avevi affermato che le sostituzioni avvenivano tutte insieme, senza perdita di prestazioni, prima dell'inizio del gioco; poi, compilare a volo oppure no? Mi sembra che affermavi il contrario. Poi, ammesso che sia come dici ora, quando e dove viene compilato tutto il resto?


Bhe mi sembra alquanto strano che il compilatore sia cosi limitato visto il passaggio da linguaggio HL ad ASM ciò comporta l'uso di una certa quantità di memoria anche perchè tale passaggio non è 1:1 ma avvengono prima dei passaggi intermedi.
e quindi? Intanto un processore non lavora con l'assembly ma con il linguaggio macchina. Poi, cosa comporta a livello di occupazione di memoria il ricorso a passaggi intermedi?


A meno che il compilatore non usi la RAM di sistema e non VRAM come deposito delle istruzioni compilate.

cioè il compilatore accede direttamente alla ram di sistema per tradurre le istruzioni, riordinarle e fare le sostituzioni di cui blateri da ore? Interessante teoria non suffragata dai fatti :D . Mi fai l'elenco delle gerarchie di accesso alla memoria in una gpu?
Cos'è, stai tentando un'arrampicata sugli specchi o spari frasi a caso dopo che ti sei letto qualcosa su wikipedia, sperando di azzeccarne una giusta?



A questo punto dovresti fornire delle fonti che riportino tali limitazioni.

comincia tu a fornire le tue. Sono ore che te lo sto chiedendo. E cerca di rispondere a delle semplici domande con altrettanto lineari risposte.
Altrimenti ritengo sia inutile continuare questa sterile discussione con qualcuno che non sa neppure di cosa sta parlando

[Wikkle]

ehhhh... il buon vecchio Tarpone :D
Come lo capisco :read:

[devAngnew]

innanzitutto fino a poco fa avevi affermato che le sostituzioni avvenivano tutte insieme, senza perdita di prestazioni, prima dell'inizio del gioco; poi, compilare a volo oppure no? Mi sembra che affermavi il contrario. Poi, ammesso che sia come dici ora, quando e dove viene compilato tutto il resto?

Bha ma parlo Arabo :eek: :D Io ho detto fin dall'inizio che gli shader di un livello di gioco viene caricato (HL) e compilato e ottimizzato (quindi il compile vedendo che lavora su Fermi sostituisce le MADD con FMA) una volta e basta
dopotutto tutti i compilatori lavorano cosi.



e quindi? Intanto un processore non lavora con l'assembly ma con il linguaggio macchina. Poi, cosa comporta a livello di occupazione di memoria il ricorso a passaggi intermedi?


Mai i mie posti li leggi o vuoi fare solo il saccente...:rolleyes: mi sembra che ho fatto una premessa te la riporto forse non ricordi [B]il compilatore ad alto livello (HL) traduce il codice in linguaggio macchina (da ora ASM)[B] non ho detto in assembler vuol dire che da ora lo chiamero LM contento :D.
Apparte il fatto che tra linguaggio macchina e assembler c'è un rapporto 1:1
credo che tu conosca la situazione ma il punto è che io ho fatto una premessa che tu vuoi negare. :read:
Tonando ai passaggi intermedi di un compilatore, mi chiedo ma la tokenizzazzione del sorgente ti risulta o no ? :mbe: O pensi che i token si memorizzino da soli :asd: :D


cioè il compilatore accede direttamente alla ram di sistema per tradurre le istruzioni, riordinarle e fare le sostituzioni di cui blateri da ore? Interessante teoria non suffragata dai fatti :D . Mi fai l'elenco delle gerarchie di accesso alla memoria in una gpu?
Cos'è, stai tentando un'arrampicata sugli specchi o spari frasi a caso dopo che ti sei letto qualcosa su wikipedia, sperando di azzeccarne una giusta?
comincia tu a fornire le tue.


Gli specchi mi sà che li stai usando tu, io ti ho fornito la mia teoria come dici, visto che 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.
O devo credere che le tue risposte siano dovute ad un ragionamento logico e basta.


Sono ore che te lo sto chiedendo. E cerca di rispondere a delle semplici domande con altrettanto lineari risposte.
Altrimenti ritengo sia inutile continuare questa sterile discussione con qualcuno che non sa neppure di cosa sta parlando

Il ragionamento è più che lineare visto che ho ricordato da altrettante ore a grandi linee cosa fa un compilatore.
Ma tu continui a dire che non rispondo.
Se ritieni sterile la discussione fai come vuoi e inserisci pure nella ignore list.
BUona Notte.

P.s: A domani se vuoi.

[Iantikas]

Bha ma parlo Arabo :eek: :D Io ho detto fin dall'inizio che gli shader di un livello di gioco viene caricato (HL) e compilato e ottimizzato (quindi il compile vedendo che lavora su Fermi sostituisce le MADD con FMA) una volta e basta
dopotutto tutti i compilatori lavorano cosi.




Mai i mie posti li leggi o vuoi fare solo il saccente...:rolleyes: mi sembra che ho fatto una premessa te la riporto forse non ricordi [B]il compilatore ad alto livello (HL) traduce il codice in linguaggio macchina (da ora ASM)[B] non ho detto in assembler vuol dire che da ora lo chiamero LM contento :D.
Apparte il fatto che tra linguaggio macchina e assembler c'è un rapporto 1:1
credo che tu conosca la situazione ma il punto è che io ho fatto una premessa che tu vuoi negare. :read:
Tonando ai passaggi intermedi di un compilatore, mi chiedo ma la tokenizzazzione del sorgente ti risulta o no ? :mbe: O pensi che i token si memorizzino da soli :asd: :D



Gli specchi mi sà che li stai usando tu, io ti ho fornito la mia teoria come dici, visto che 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.
O devo credere che le tue risposte siano dovute ad un ragionamento logico e basta.



Il ragionamento è più che lineare visto che ho ricordato da altrettante ore a grandi linee cosa fa un compilatore.
Ma tu continui a dire che non rispondo.
Se ritieni sterile la discussione fai come vuoi e inserisci pure nella ignore list.
BUona Notte.

P.s: A domani se vuoi.




nn sono un esperto in materia xò una cosa è certa...hai scritto decine di post con questa presunta tua teoria ma se li riunisci tutti, in tante righe, non hai spiegato niente...


...se riscrivi il tuo pensiero in un unico post senza spezzetarlo quotando gli altri magari ci fai un favore a noi ke stiamo cercando di capirti...ciao

[A.L.M.]

Tanto per alleggerire il thread, posto un tweet ufficiale di NVidia:

Fun fact of the week: The GF100 board pictured in last's week's fun fact is 10.5-inches long -- the same length as GeForce GTX 200 Series graphics cards!

P.S.: la foto cui fanno riferimento è quella famosa dello schermo col benchmark. ;)

Fonte: http://twitter.com/NVIDIAGeForce

[persa]

mmmmmm...., aveva ragione ratatosk quindi, a me invece sembrava più lunga di una gt200!

[yossarian]

Bha ma parlo Arabo :eek: :D Io ho detto fin dall'inizio che gli shader di un livello di gioco viene caricato (HL) e compilato e ottimizzato (quindi il compile vedendo che lavora su Fermi sostituisce le MADD con FMA) una volta e basta
dopotutto tutti i compilatori lavorano cosi.




Mai i mie posti li leggi o vuoi fare solo il saccente...:rolleyes: mi sembra che ho fatto una premessa te la riporto forse non ricordi [B]il compilatore ad alto livello (HL) traduce il codice in linguaggio macchina (da ora ASM)[B] non ho detto in assembler vuol dire che da ora lo chiamero LM contento :D.
Apparte il fatto che tra linguaggio macchina e assembler c'è un rapporto 1:1
credo che tu conosca la situazione ma il punto è che io ho fatto una premessa che tu vuoi negare. :read:
Tonando ai passaggi intermedi di un compilatore, mi chiedo ma la tokenizzazzione del sorgente ti risulta o no ? :mbe: O pensi che i token si memorizzino da soli :asd: :D



Gli specchi mi sà che li stai usando tu, io ti ho fornito la mia teoria come dici, visto che 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.
O devo credere che le tue risposte siano dovute ad un ragionamento logico e basta.



Il ragionamento è più che lineare visto che ho ricordato da altrettante ore a grandi linee cosa fa un compilatore.
Ma tu continui a dire che non rispondo.
Se ritieni sterile la discussione fai come vuoi e inserisci pure nella ignore list.
BUona Notte.

P.s: A domani se vuoi.


questo è il tuo primo post sull'argomento
Se ho interpretato bene ciò che volete dire....
Bhe il tutto è fatto all'atto del caricamento dello shader in memoria diciamo durante il caricamento del livello di un ipotetico gioco quindi il driver sostituirebbe le chiamate MADD con delle FMA e poi compilerebbe il tutto ne consegue che Fermi dovrebbe lavorare alla massima velocità possibile.

questo è il tuo secondo
Ovviamente, ci deve essere questo passaggio di replacemente da MADD a FMA ma il tutto avverrà in modalità JIT cioè carico lo shader e sostituisco le istruzioni e successivamente il codice viene compilato quindi questo passaggio avviene una sola volta subito dopo aver caricato lo shader.
Cioè non avviene un interpretazione passo per passo non sò se mi sono spiegato.

poi cìè questo
IMO cambia e come perchè una cosa è interpretare una MADD a runtime come mi sembra di aver capito dalle tue risposte un' altra è fare una compilazione una volta per tutte dello shader (quindi sostituzione MADD con FMA e compilazione finale).

poi questo
Lasciando per ora da parte il problema della propagazione dell'errore quindi possibili artefatti, IMO lo shader viene caricato (shader scritto ad alto livello) successivamente (viene compilato) questo vale sia per ATI che NVIDIA ora si avrà il codice in ASSEMBLER a questo punto dovrebbero partire eventuali ottimizzazioni nel caso NVIDIA sostituitirebbe alla MADD la FMA ma questo lo fà solo una volta prima dell'esecuzione (dello shader) perdendo questo tempo all'inizio prima che una scena venga renderizzata.

questo
Appunto non cambia, una volta compilato e ottimizzato lo shader è eseguito alla max velocità possibile dalla GPU quindi l'overhead di sostituzione delle istruzione non persiste più ma ci sarà solo quello dovuto all'exe dell' FMA.

questo
Ma se è 3 pagine di thread che dico che l'overhead è solo all'atto della compilazione e ho fatto pure l'esempio che ciò avvine quando viene caricato un livello di gioco in tal momento la gpu può compilare e ottimizzare lo shader.

questo
Bha semmai i dati sono caricati di continuo ma il codice shader dovrebbe essere caricato prima di partire con il livello, altrimenti non ci sarebbe compilatore che tenga si ATI che NVIDIA.



E' risaputo che qualunque processore una volta compilato il codice originario ad alto livello (HLSL o GLSL) e ottimizzato lo esegue e basta che poi non è detto che il codice venga eseguito al massimo delle sue possibilità come nel caso ATi è quasi impossibile ottimizzare lo shader compilato di modo che vengano usate tutte e 5 le sue unità VLIW.

questo è significativo
Ma perchè a te risulta che un programma compilato vengo memorizzato tutto nei registri di un processore a me no. Altrimente la memoria a che serve a solo a contenere dati.

Secondo la risposta te la sei data già in parte da solo e se rileggi bene ciò che ho scritto io l'avevo già detto e cioè il compilatore ad alto livello (HL) traduce il codice in linguaggio macchina (da ora ASM) e sostituisce le MAD con FMA. Il fatto è che tu dici che la compilazione avviene mano mano da alto livello ad ASM mentre io sostengo l'opposto cioè una volta per tutte.


A questo punto l'unico vero hit è quello di esecuzione della FMA e basta.
visto che tutto si risolve a compiler time.

Non all'atto del caricamento del 1mo frame ma prima e lo fara il compiler che traduce da HL ad ASM.

Innanzitutto io non parlavo di compilare a volo tutti gli shader del gioco intero ma solo del livello eseguito.
Bhe mi sembra alquanto strano che il compilatore sia cosi limitato visto il passaggio da linguaggio HL ad ASM ciò comporta l'uso di una certa quantità di memoria anche perchè tale passaggio non è 1:1 ma avvengono prima dei passaggi intermedi. A meno che il compilatore non usi la RAM di sistema e non VRAM come deposito delle istruzioni compilate.
A questo punto dovresti fornire delle fonti che riportino tali limitazioni.

In tutti questi post hai continuato a sostenere che la compilazione avviene una volta per tutte, a volte dicendo che avviene prima del caricamento del primo frame, altre volte prima dello shader, altre ancora una tantum (e poi non ci si pensa più :D ). Ma tralasciamo questi dettagli.
Ti ho chiesto come fa ad agire il compilatore e dove agisce ma non hai risposto (o meglio, hai risposto chiedendo a cosa servono i compilatori se non fanno questo). Ora ti faccio una domanda più semplice: che tipo di architettura ha GT300 o fermi che dir si voglia? La risposta è semplice ed èd è unica: una volta che l'hai trovata, cerca qualche documento on line che ti spieghi come avvengono le operazioni di fetching e decoding delle istruzioni per siffatta architettura. E, soprattutto, se queste avvengono at run time o at compile time.
Poi torni qui e ne riparliamo. E magari parliamo anche di quella ATi :)

[Kharonte85]

Come no, devi toglierla e metterci gli stickers :read:
:doh:


Fun fact of the week: The GF100 board pictured in last's week's fun fact is 10.5-inches long -- the same length as GeForce GTX 200 Series graphics cards!


Ne sarei molto contento dato che non posso mettere una scheda che sia più di 27cm :fagiano:

[persa]

kharonte che case hai?!? nel mio in firma cmq max 29cm!

[Kharonte85]

kharonte che case hai?!? nel mio in firma cmq max 29cm!
OT/ Cooler Master Centurion 534, ho calcolato che posso incastrarci una scheda da 27cm al massimo :asd:

Comunque il fatto che Nvidia rilasci queste informazioni apposta potrebbe significare che non siamo lontani da vedere qualcosa, probabilmente la scheda fotografata è vera.

[A.L.M.]

OT/ Cooler Master Centurion 534, ho calcolato che posso incastrarci una scheda da 27cm al massimo :asd:

Comunque il fatto che Nvidia rilasci queste informazioni apposta potrebbe significare che non siamo lontani da vedere qualcosa, probabilmente la scheda fotografata è vera.

Devono fare qualcosa a breve... Siamo nella christmas season, e se non fanno damage control (leggi qualche mockup qua e là) non appena il livello di fornitura delle ATI sarà sufficiente sarà un disastro commerciale per NVidia (come lo fu per AMD ai tempi di R600).
Continuo invece a credere molto remoto un lancio commerciale entro gennaio. Il lancio a gennaio presupponeva alcuni step che già sono stati confermati come saltati. Mi pare impossibile che riescano ad avere pronte sugli scaffali delle schede A3 tra 2 mesi scarsi quando i partners ancora manco le hanno viste le schede, a quanto si dice.
Se si riusciranno a vedere per fine febbraio sarà già un mezzo miracolo.

[Athlon 64 3000+]

Più che altro non riesco a capire come mai l'unita di tesselazione anche se hardware su RV870 ha un impatto cosi devastante dai benchmark fino ad ora visti.:confused:

[M4R1|<]

Più che altro non riesco a capire come mai l'unita di tesselazione anche se hardware su RV870 ha un impatto cosi devastante dai benchmark fino ad ora visti.:confused:

Tessellation ha si un impatto devastante lato performance ma rende le scene moolto più reali, è il caso dell'unigine. E' invece molto probabile, nel prossimo futuro, che si implementino delle opzioni per avere vari steep di pesantezza poligonale, in modo da permettere anche a schede di fascia mainstream di poterlo eseguire senza scendere sotto le soglie minime a risoluzioni oggi standard (1050p)

[Athlon 64 3000+]

Tessellation ha si un impatto devastante lato performance ma rende le scene moolto più reali, è il caso dell'unigine. E' invece molto probabile, nel prossimo futuro, che si implementino delle opzioni per avere vari steep di pesantezza poligonale, in modo da permettere anche a schede di fascia mainstream di poterlo eseguire senza scendere sotto le soglie minime a risoluzioni oggi standard (1050p)

Spero che sia solo perchè sono i primi giochi ad implementarle visto che è una freature molto bella,ma vedere che sia cosi pesante non mi fa molto piacere.
Poi vedendo i benchmark in dx9 tra la mia ex HD 4870 e la HD 5850 il distacco è sempre troppo poco visto le caratteristiche di quest'ultima.

[leoneazzurro]

la tessellazione va vista come un filtro se lo applichi, lo usi, ecco che l'immagine è migliore ma a scapito delle prestazioni. magari l'emulato non rende quanto l'altro sul piano della qualità ma rende meglio sul piano delle prestazioni quindi tocca vedere il rapporto qualità/prezzo ovvero decadimento prestazionale una volta applicato. ovviamente son solo ipotesi, tutte da verificare.
;)

Dipende da come viene utilizzata. Mentre un filtro aggiunge sempre del lavoro in più da fare da parte della GPU, la tessellazione nasce per fare del lavoro in meno rispetto al caso "standard": Per cui si possono avere diverse situazioni: avere lo stesso dettaglio dei giochi DX10 con prestazioni migliorate, avere le stesse prestazioni con un dettaglio maggiore o avere frame rate giocabili con dettaglio parecchio alto. La scelta che si è fatta, dato la sovrabbondanza di potenza di calcolo alle risoluzioni "umane", sembra essere per ora la terza, ma non è detto che in futuro non si utilizzino anche le prime due opzioni (poi ci sono anche altre possibilità aperte dalla tessellazione, per esempio si può andare a vedere il demo "Froblins" di AMD e pensare ad uno strategico che utilizzi un sistema similare...)


Più che altro non riesco a capire come mai l'unita di tesselazione anche se hardware su RV870 ha un impatto cosi devastante dai benchmark fino ad ora visti.:confused:

Perchè se crei un numero maggiore di poligoni poi lo devi anche renderizzare, il che significa un numero maggiore di calcoli nello shader core (anche se il numero di pixel non cambia, cambiano il numero di vertici, di normali che vanno calcolate, ecc.). E' chiaro che gli "effetti" vanno aggiunti in base anche a ciò che la scheda è in grado di fare: impossibile pensare che una 5770 possa mantenere pur con la stessa capacità di tessellazione di una 5870 lo stesso frame rate. La cosa bella della tessellazione è che si potranno anche aggiustare molto più semplicemente i livelli di dettaglio poligonale in base alle prestazioni della scheda.

E'

Perché la generazione dei poligoni (triangoli) del wireframe finale è a carico dello shader core. A fare la stessa cosa in DX9 faresti 0.5fps :)



La generazione dei triangoli è data dal tessellatore e dal setup engine, ma i triangoli vanno poi elaborati, quindi se passo da 1000 a 100000 poligoni anche i calcoli relativi a normali, illuminazione, ecc. aumentano.

[Kharonte85]

La generazione dei triangoli è data dal tessellatore e dal setup engine, ma i triangoli vanno poi elaborati, quindi se passo da 1000 a 100000 poligoni anche i calcoli relativi a normali, illuminazione, ecc. aumentano.
Presumo che anche l'applicazione dell'eventuale filtro AA a questi nuovi poligoni non sia gratis...:fagiano:

[zorco]

Presumo che anche l'applicazione dell'eventuale filtro AA a questi nuovi poligoni non sia gratis...:fagiano:
niente è gratis toccà lavorà :D

[leoneazzurro]

Presumo che anche l'applicazione dell'eventuale filtro AA a questi nuovi poligoni non sia gratis...:fagiano:

Brào :O

[A.L.M.]

E' impossibile ;)

Se è necessario uno step A3 è certo che a gennaio al massimo avranno il teipaut finito e mandato in fabbrica. A quel punto sul mercato nella migliore delle ipotesi troverai le schede tre mesi dopo.

Non è nemmeno detto che non escano con una "GTX380", ovviamente Phantom Edition™ spompatissima basata sull'A2 per poi mandarla in EOL dopo pochissimi mesi uscendo con una "GTX385" A3 meno spompata della precedente che si farà tutta la strada fino alla revisione a 28nm.

Potrebbe essere, sai? ;)
Un po' come ai bei vecchi tempi di FX5800 e poi FX5900... :O

[devAngnew]

questo è il tuo primo post sull'argomento

In tutti questi post hai continuato a sostenere che la compilazione avviene una volta per tutte, a volte dicendo che avviene prima del caricamento del primo frame, altre volte prima dello shader, altre ancora una tantum (e poi non ci si pensa più :D ). Ma tralasciamo questi dettagli.
Ti ho chiesto come fa ad agire il compilatore e dove agisce ma non hai risposto (o meglio, hai risposto chiedendo a cosa servono i compilatori se non fanno questo).


Grazie per la raccolta :D :sofico:
Qui veramente ci vogliamo arrampicare sugli specchi... :asd:
E' dal primo post che dico: lo shader ad HL viene caricato dal compilatore e tradotto in LM con tutti i passaggi del caso (speriamo che ti ricordi delle mie associazioni :asd:).
Il compilatore da quando è stato inventato ha sempre funzionato cosi e cioè parto dal sorgente ed ottengo il codice macchina da far girare 1 volta per tutte. Tu invece sostieni che non funziona cosi ma da quello che posso capire dai tuoi post ogni istruzione al HL sarebbe caricata e tradotta nei registri della GPU ma questo non è un compilatore ma un interprete. :read:
A questo punto conviene a te leggere e studiare su Wikipedia cosa sia un compilatore.


Ora ti faccio una domanda più semplice: che tipo di architettura ha GT300 o fermi che dir si voglia? La risposta è semplice ed èd è unica: una volta che l'hai trovata, cerca qualche documento on line che ti spieghi come avvengono le operazioni di fetching e decoding delle istruzioni per siffatta architettura. E, soprattutto, se queste avvengono at run time o at compile time.
Poi torni qui e ne riparliamo. E magari parliamo anche di quella ATi :)

Ma cosa centra studiati come avvengono le operazione di fetch-decode-execute della GPU io stò parlando di compilatori (qest'ultimo adatta il codice intermedio generato alla macchina su cui girerà il compilato) e ricordati che un compilatore può anche girare su un architettura completamente diversa e compilare per un'altra. Spero di essermi spiegato.
Qui non c'è da fare nessuna lezione delle fasi fetch-decode-execute del funzionamento della GPU a basso livello ma mi sà di compilatori. :read:
Visto le tue "nuove" teorie sui compilatori fornisci dei documenti ufficiali sul funzionamento dei compilatori di NVIDIA o ATI (a te la scelta).
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.

[Severnaya]

devAngnew mi sembri tanto un parente di spiderman :asd:

[Maury]

Grazie per la raccolta :D :sofico:
Qui veramente ci vogliamo arrampicare sugli specchi... :asd:


A me sembra palese che sia tu ad arrampicarti, senza contare che alla fine della fiera non stai spiegando nulla tecnicamente, cosa più e più volte richiesta. :rolleyes:

[Elendil_1]

Ma i compilatori cosa sono stati inventati a fare ... secondo te uno shader SM 3 ha diversi path per architetture 68xx e G80 e derivati.
Io dico di no, ma cade tutto nelle mani del compilatore che ottimizza per ogni gpu (ovviamente fino ad un certo punto).

Guarda,
io di schede video e compilatori non ne capisco granché (anche se ho una formazione scientifica, ma in altri ambiti), eppure ho capito benissimo il discorso di Yossarian che è lampante e cristallino. Tu continui a scrivere la stessa cosa da pagine e pagine senza capire cosa ti vien detto, e non so come faccia Yossarian a non averti ancora mandato a quel paese.
Fermati, prendi un bel respiro e prova a capire cos'ha scritto lui, perché ti sei impelagato in un discorso dal quale non puoi uscire.

[devAngnew]

Più semplicemente non hai idea di quello che stai scrivendo, infatti stai scrivendo cose prive di ogni senso.

L'ottimizzazione non in real-time è possibile solo se il software ha un code-path specifico per Fermi, cosa che ovviamente non accadrà.

La "traduzione" in real time delle chiamate MADD in FMA è sicuramente onerosa e non può essere fatta prima. Per farla prima serve la programmazione specifica a priori che dicevo.

Certo a meno che lo stesso JHH con la sola imposizione delle mani non renda ogni GPU Fermi magicamente in grado di fare cose impossibili.

Non credo proprio mi sà che non conosci i compilatori. Altrimenti mi diresti il perchè un compilatore non può fare ciò che dico.

[Iantikas]

Grazie per la raccolta :D :sofico:
Qui veramente ci vogliamo arrampicare sugli specchi... :asd:
E' dal primo post che dico: lo shader ad HL viene caricato dal compilatore e tradotto in LM con tutti i passaggi del caso (speriamo che ti ricordi delle mie associazioni :asd:).
Il compilatore da quando è stato inventato ha sempre funzionato cosi e cioè parto dal sorgente ed ottengo il codice macchina da far girare 1 volta per tutte. Tu invece sostieni che non funziona cosi ma da quello che posso capire dai tuoi post ogni istruzione al HL sarebbe caricata e tradotta nei registri della GPU ma questo non è un compilatore ma un interprete. :read:
A questo punto conviene a te leggere e studiare su Wikipedia cosa sia un compilatore.



Ma cosa centra studiati come avvengono le operazione di fetch-decode-execute della GPU io stò parlando di compilatori (qest'ultimo adatta il codice intermedio generato alla macchina su cui girerà il compilato) e ricordati che un compilatore può anche girare su un architettura completamente diversa e compilare per un'altra. Spero di essermi spiegato.
Qui non c'è da fare nessuna lezione delle fasi fetch-decode-execute del funzionamento della GPU a basso livello ma mi sà di compilatori. :read:
Visto le tue "nuove" teorie sui compilatori fornisci dei documenti ufficiali sul funzionamento dei compilatori di NVIDIA o ATI (a te la scelta).
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.

io nn so se ti rendi conto ke gli rispondi senza dir niente e dai a yossarian dell'arrampicatore di spekki quando tu stai in free climbing già da un bel pò...

...lui domanda cuori e tu rispondi pikke...ti kiede dei dati a suffraggio della tua teoria e tu gli rispondi kiedendo dati sul funzionamento di compilatori e quant'altro...funzionamento ke è stato kiesto a te di spiegare appunto x dimostrare ke ciò ke affermi sia possibile...

...se continui su questa linea praticamente ti comporti da troll...ciao

[Foglia Morta]

Hanno ricominciato con i rebrand ?

GeForce 310 : http://h10010.www1.hp.com/wwpc/uk/en/sm/WF06c/A1-329290-64268-348724-348724-4015767-4015770.html

[devAngnew]

io nn so se ti rendi conto ke gli rispondi senza dir niente e dai a yossarian dell'arrampicatore di spekki quando tu stai in free climbing già da un bel pò...

...lui domanda cuori e tu rispondi pikke...ti kiede dei dati a suffraggio della tua teoria e tu gli rispondi kiedendo dati sul funzionamento di compilatori e quant'altro...funzionamento ke è stato kiesto a te di spiegare appunto x dimostrare ke ciò ke affermi sia possibile...

...se continui su questa linea praticamente ti comporti da troll...ciao

Parli di prove di ciò che dico vai a leggerti testi universitari che parlano del funzionamento di un compilatore :read: poi mi dici se ho ragione o meno chiarendomi dove e perchè sbaglio.
Ciò di cui parla yossarian del funzionamento di un compilatore non esiste in letteratura.
E il Troll vale anche per lui visto che continua a non rispondere sul funzionamento del compilatore di una GPU.
Concludo qui o fornisca delle prove circa la sua teoria circa la pseudo-compilazione-interpretazione delle istruzioni di uno shader altrimenti il discorso è chiuso.

Ciao
:)

[Foglia Morta]

L' articolo di yoss sulle ALU : http://www.appuntidigitali.it/5025/elementi-funzionali-di-una-gpu-le-alu/

[Severnaya]

ora risponderà che è solo chiacchiere e distintivo :asd:

[Maury]

ora risponderà che è solo chiacchiere e distintivo :asd:

senza dubbio farà così :asd:

[Maury]

L' articolo di yoss sulle ALU : http://www.appuntidigitali.it/5025/elementi-funzionali-di-una-gpu-le-alu/

Spaventoso Yoss, come sempre del resto :)

[yossarian]

Grazie per la raccolta :D :sofico:
Qui veramente ci vogliamo arrampicare sugli specchi... :asd:
E' dal primo post che dico: lo shader ad HL viene caricato dal compilatore e tradotto in LM con tutti i passaggi del caso (speriamo che ti ricordi delle mie associazioni :asd:).
Il compilatore da quando è stato inventato ha sempre funzionato cosi e cioè parto dal sorgente ed ottengo il codice macchina da far girare 1 volta per tutte. Tu invece sostieni che non funziona cosi ma da quello che posso capire dai tuoi post ogni istruzione al HL sarebbe caricata e tradotta nei registri della GPU ma questo non è un compilatore ma un interprete. :read:
A questo punto conviene a te leggere e studiare su Wikipedia cosa sia un compilatore.



Ma cosa centra studiati come avvengono le operazione di fetch-decode-execute della GPU io stò parlando di compilatori (qest'ultimo adatta il codice intermedio generato alla macchina su cui girerà il compilato) e ricordati che un compilatore può anche girare su un architettura completamente diversa e compilare per un'altra. Spero di essermi spiegato.
Qui non c'è da fare nessuna lezione delle fasi fetch-decode-execute del funzionamento della GPU a basso livello ma mi sà di compilatori. :read:
Visto le tue "nuove" teorie sui compilatori fornisci dei documenti ufficiali sul funzionamento dei compilatori di NVIDIA o ATI (a te la scelta).
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.

ok, ripartiamo da 0 (zero) :D
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.
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?
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. 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?
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)

[Wikkle]

ancora le k :muro: :muro: :muro:
ma non erano estinti gli utilizzatori? :muro:

[The_SaN]

ancora le k :muro: :muro: :muro:
ma non erano estinti gli utilizzatori? :muro:Dai, non fanno nulla di male WiCCle :D

[Foglia Morta]

Ora, a meno che non abbia a disposizione una path specifica per fermi che contiene FMA al posto di MADD

Magari migliorerà la collaborazione tra nVidia e Epic Games :asd:

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

[yossarian]

Magari migliorerà la collaborazione tra nVidia e Epic Games :asd:

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! :sofico:

[Andrea deluxe]

Hanno ricominciato con i rebrand ?

GeForce 310 : http://h10010.www1.hp.com/wwpc/uk/en/sm/WF06c/A1-329290-64268-348724-348724-4015767-4015770.html

o no!

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

[yossarian]

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]

:ops2:

[zorco]

http://www.pctuner.net/news/12560/NVIDIA-dice-la-sua-sulle-vendite-di-VGA-AMD-ATI/

[eXeS]

è 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 ?


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 ? :confused:

[devAngnew]

ok, ripartiamo da 0 (zero) :D
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. :D :)
Il compilatore accetta solo un sorgente ad HL.
Ma forse intendevi un Assemblatore.
:D



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) :read:
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]

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 :D
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]

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]

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. :D :)
Il compilatore accetta solo un sorgente ad HL.
Ma forse intendevi un Assemblatore.
:D




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) :read:
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 :D .
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 :D .
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]

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]

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 ? :confused:

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]

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 ? :confused:

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


...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 :D

[yossarian]

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]

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]

finalmente, al termine della vicenda, è venuto fuori dove si trova questo benedetto compilatore :D
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]

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 :D
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]

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 :D . 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 :D . 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? :ciapet: ).
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. :D

[skizzo99999999]

il problema è proprio il punto 3 :D
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

[eXeS]

il problema è proprio il punto 3 :D
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 :D

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]

(quindi, anche all'interno degli stessi driver, ci devono essere istruzioni dedicate al solo fermi) e non di tutta la famiglia (driver unificati? :ciapet: ).
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...:fagiano:

[yossarian]

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.

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 :D

(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? :D

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]

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...:fagiano:

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]

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]

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]

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]

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]

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? :D

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]

Vabbè ma in soldoni quando dovrebbero uscire? :D

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]

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]

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". :D
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) :p

[skizzo99999999]

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

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.


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]

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

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

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.

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? :confused:
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.


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? :sofico:


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......:rolleyes: 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 :D


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


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]

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.:p

[skizzo99999999]

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.:p

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]

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 :D .
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 :D .
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]

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.


:asd:


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!

[Maury]

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



P.S: skizzo99999999 ti consiglio di lasciar perdere.

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

[yossarian]

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

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

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

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

[yossarian]

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

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











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


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

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



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

[Maury]

l'importante è avere fede :sofico:

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


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

Yoss m'hai fatto morire con questa frase :D

[yossarian]

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

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


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

[Jackaos]

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

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

[skizzo99999999]

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

[skizzo99999999]

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


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

[skizzo99999999]

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

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

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

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

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

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

[yossarian]

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

fin qui ok

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

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

qui c'è da puntualizzare una cosa; a questo livello, il driver non è ancora entrato in gioco. E' la cpu che gestisce la compilazione ma lo fa utilizzando un compiler generico per quel determinato tipo di api, contenuto nel sistema operativo. Quindi, a questo livello, non viene fatta ancora nessuna ottimizzazione (e non può essere altrimenti visto che il sistema operativo conosce la gpu con cui si interfaccia tramite hal ma la cpu no. Tramite hal, però, è possibile che il sistema operativo dica alla cpu di inviare, insieme al codice, l'istruzione che, in presenza di una determinata operazione ci si deve comportare in un ben preciso modo.
Questo l'ho detto più volte. Si su questo passo sono ignorante lo ammetto. E allora? Mi devo suicidare?
te ne do atto infatti e apprezzo l'onestà intellettuale :)

Se mi dici che gira su GPU bene ho imparato qualcosa di nuovo. In ogni caso è sempre un compilatore, cioè è esso stesso un software che gira su un hardware. il compilatore è "compilato" e scritto per dove deve girare, è lui che sa cosa deve fare e lo fa, sia che giri sulla GPU che sulla CPU. Io di primo acchito direi che gira sulla CPU (visto che mi sembra più semplice scrivere un compilatore con un set di istruzioni di una CPU che di una GPU) ma se con tanta veemenza dici che gira sula GPU ci credo, non è che devi insultarmi per questo.
siamo arrivati alla vrma, con il codice compilato dalla cpu, non ottimizzato, ma con delle raccomandazioni. Quello che ho cercato di farvi capire dall'inizio è che la cpu non si può fare carico di eseguire delle ottimizzazioni per un altro chip. Il compito di ciò è del chip stesso istruito da chi lo ha progettato, costruito e programmato.
Quindi, la vram contiene codice digeribile per una gpu e, in più, ci sono delle "istruzioni aggiuntive" che indicano come comportarsi in presenza di una derminata operazione.
Ti chiedo scusa per gli insulti :)
Questo compilatore lo ha programmato NVIDIA che conosce bene l'architettura per cui uscirà lo shader compilato. L'operazione di sostituzione non è una operazione che deve considerare dipendenze o quant'altro, ma è solo "vedo una istruzione, ci metto questa". Non capisco dove stia il problema. Non vedo cosa deve conoscere NVIDIA di così profondo dell'architettura INTEL per poter scrivere un compilatore che non deve generare codice per intel ma che da uno shader testuale tiri fuori un pezzo di codice interpretabile dalle sue GPU. I driver servono anche a questo.

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

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

[A.L.M.]

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

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

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

yoss non fustigarmi se ho sbagliato... :ave: :D

[yossarian]

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

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

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

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

[devAngnew]

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

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

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


Quoto.


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

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

Per il resto il discorso è chiuso punto e basta.

[ippo.g]

totale: la scheda video servirà ancora o no? :confused:

[yossarian]

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

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

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

[Jackaos]

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

[skizzo99999999]

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

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

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

[yossarian]

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

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

[Kharonte85]

Quindi, dando per buoni i calcoli fatti da HW.fr
Veramente è proprio qui il problema...:asd:


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

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

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

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


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

[Jackaos]

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

[konzendoji]

Signori? una domanda...
Dopo 451 pagine di thread quali certezze ci sono?
Forse proprio che per ora non c'è nessuna certezza? :rolleyes:

[Kharonte85]

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

Signori? una domanda...
Dopo 451 pagine di thread quali certezze ci sono?
Forse proprio che per ora non c'è nessuna certezza? :rolleyes:
Ci mancava Socrate...:sofico:


Si scherza eh :D ...le certezze sono quelle scritte nel white paper che nvidia ha diffuso: http://www.nvidia.com/content/PDF/fermi_white_papers/NVIDIA_Fermi_Compute_Architecture_Whitepaper.pdf le incognite e le domande che solleva invece rimangono ampiamente dibattute: per diletto, per hobby e per fortuna! :D

[yossarian]

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

allora, diciamo che abbiamo fatto tutti, me compreso, un po' di confusione con i termini. :D
Innanzitutto, né nVidia né intel si prendono la briga di scrivere compilatori in senso stretto. Il compilatore è, infatti, un elemento tipico di un linguaggio di programmazione e non di un componente hardware. Quelli che chiamiamo in gergo compilatori, riferendoci a componenti hardware, sono più delle interfacce tra i veri compilatori e i layer sottostanti e servono a ottimizzare il funzionamento dell'hardware per cui sono scritti. Quindi, nVidia non può scrivere un compilatore "standard" ossia, ad esempio, per HLSL, che ottimizzi per le sue gpu (c'è già uno standard fissato dalle api di riferimento per quello) ma può creare un layer sottostante che adatti il linguaggio compilato alle sue gpu. Detto questo, se faccimao riferimento proprio a questo ulteriore layer, ovvero quello che consente l'ottimizzazione, ovvero quello che permette di forzare un determinato componente hardware ad assumere determinati comportamenti (ad esmepio a forzare una cpu intel ad otimizzare codice per gpu nVidia), capisci bene che è necessario conoscere l'architettura del chip di cui si vuole manipolare il comportamento.
Diverso il dioscorso dello scrivere un programma per una determinata architettura: scrivere un programma per cpu x86 non comporta una conoscanza approfondita diell'architettura x86 come scrivere un gioco in dx10 non comporta la conoscenza di tutti i chip dx10 prsenti sul mercato. Basta conoscere le api di riferimento (che esistono per quello). Però, avere accesso a dettagli del chip sconosciuto ai più, può aiutare a ottimizzare per per quel particolare tipo di chip.
Un esempio classico, tornando a nVidia e a NV30, è stato fornito da ID software che ha scritto il codice di doom con l'architettura di NV30 come riferimento. A detta dello stesso Carmack, in arb2 standard, R300 era esattamente il doppio più veloce di nv30 (situazione analoga a quella vista in d3d). Quando è uscito doom3, nv30 ed r300 erano pressochè pari come prestazioni. Per ottenere ciò è bastato far leva sui punti di forza di nv30 (calcolo per interi, z fill rate elevato, ombre dinamiche con l'utilizzo di shadow buffer) evitando o riducendo al minimo i punti deboli (calcoli in virgola mobile ed istruzioni matematiche insieme ad operazioni di texture fetch).
Tornando a quanto detto prima, nVidia non si prenderà mai la briga di scrivere un compilatore per hlsl di tipo, diciamo "standard", di quelli integrati nel s.o. e basati sulle api di riferimento, Non potrà mai scrivere un tool che "faccia lavorare" per le sue gpu le cpu intel o amd ottimizzando per loro (dovrebbe conoscerne le architetture e scriverne uno per ciascuna; in pratica dovrebbe scrivere dei driver per cpu :D ). L'unica cosa che pò fare è scrivere driver e tool che ottimizzino il sw per i propri chip facendo tutto ciò che è necessario.
Oppure spingere gli sviluppatori del sw a scrivere codice ottimizzato per i propri chip (come l'esempio che ho citato)

[yossarian]

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

:eek:
mi hai fatto prendere un colpo; un giorno che non sento notizie al tg e tu fai un'uscita de genere!?! Vuoi farmi morire? :mbe: :D

[Kharonte85]

allora, diciamo che abbiamo fatto tutti, me compreso, un po' di confusione con i termini. :D
Innanzitutto, né nVidia né intel si prendono la briga di scrivere compilatori in senso stretto. Il compilatore è, infatti, un elemento tipico di un linguaggio di programmazione e non di un componente hardware. Quelli che chiamiamo in gergo compilatori, riferendoci a componenti hardware, sono più delle interfacce tra i veri compilatori e i layer sottostanti e servono a ottimizzare il funzionamento dell'hardware per cui sono scritti. Quindi, nVidia non può scrivere un compilatore "standard" ossia, ad esempio, per HLSL, che ottimizzi per le sue gpu (c'è già uno standard fissato dalle api di riferimento per quello) ma può creare un layer sottostante che adatti il linguaggio compilato alle sue gpu. Detto questo, se faccimao riferimento proprio a questo ulteriore layer, ovvero quello che consente l'ottimizzazione, ovvero quello che permette di forzare un determinato componente hardware ad assumere determinati comportamenti (ad esmepio a forzare una cpu intel ad otimizzare codice per gpu nVidia), capisci bene che è necessario conoscere l'architettura del chip di cui si vuole manipolare il comportamento.
Diverso il dioscorso dello scrivere un programma per una determinata architettura: scrivere un programma per cpu x86 non comporta una conoscanza approfondita diell'architettura x86 come scrivere un gioco in dx10 non comporta la conoscenza di tutti i chip dx10 prsenti sul mercato. Basta conoscere le api di riferimento (che esistono per quello). Però, avere accesso a dettagli del chip sconosciuto ai più, può aiutare a ottimizzare per per quel particolare tipo di chip.
Un esempio classico, tornando a nVidia e a NV30, è stato fornito da ID software che ha scritto il codice di doom con l'architettura di NV30 come riferimento. A detta dello stesso Carmack, in arb2 standard, R300 era esattamente il doppio più veloce di nv30 (situazione analoga a quella vista in d3d). Quando è uscito doom3, nv30 ed r300 erano pressochè pari come prestazioni. Per ottenere ciò è bastato far leva sui punti di forza di nv30 (calcolo per interi, z fill rate elevato, ombre dinamiche con l'utilizzo di shadow buffer) evitando o riducendo al minimo i punti deboli (calcoli in virgola mobile ed istruzioni matematiche insieme ad operazioni di texture fetch).
Tornando a quanto detto prima, nVidia non si prenderà mai la briga di scrivere un compilatore per hlsl di tipo, diciamo "standard", di quelli integrati nel s.o. e basati sulle api di riferimento, Non potrà mai scrivere un tool che "faccia lavorare" per le sue gpu le cpu intel o amd ottimizzando per loro (dovrebbe conoscerne le architetture e scriverne uno per ciascuna; in pratica dovrebbe scrivere dei driver per cpu :D ). L'unica cosa che pò fare è scrivere driver e tool che ottimizzino il sw per i propri chip facendo tutto ciò che è necessario.
Oppure spingere gli sviluppatori del sw a scrivere codice ottimizzato per i propri chip (come l'esempio che ho citato)
Verissimo me lo ricordo...doom 3, unico gioco che viaggiava davvero bene sulla serie FX, quanti ricordi (brutti :asd:)
:eek:
mi hai fatto prendere un colpo; un giorno che non sento notizie al tg e tu fai un'uscita de genere!?! Vuoi farmi morire? :mbe: :D
Mi son spaventato anche io...:fagiano::D

http://www.quirinale.it/qrnw/statico/costituzione/costituzione.htm ;)

[yossarian]

Verissimo me lo ricordo...doom 3, unico gioco che viaggiava davvero bene sulla serie FX, quanti ricordi (brutti :asd:)

Mi son spaventato anche io...:fagiano::D

http://www.quirinale.it/qrnw/statico/costituzione/costituzione.htm ;)

ora funziona; mi sento più sollevato, la Costituzione è salva :D

[ally]

...ok yossarian è in errore....ma se è così semplice mutare MADD in FMA al volo perchè nividia ha incluso nell'architettura una sezione che gestisce MADD?...non poteva risparmiarsi transistor e aumentare ulteriormente i transitor per FMA?...

...ciao Andrea...

[zorco]

http://www.nvidia.com/object/product_geforce_310_us.html

sembrerebbe un ennesimo rebrand ...

[Kharonte85]

http://www.nvidia.com/object/product_geforce_310_us.html

sembrerebbe un ennesimo rebrand ...

Lo è a tutti gli effetti, quella è una GT 210...ma in realtà sarà disponibile solo per OEM.

[skizzo99999999]

allora, diciamo che abbiamo fatto tutti, me compreso, un po' di confusione con i termini. :D
Innanzitutto, né nVidia né intel si prendono la briga di scrivere compilatori in senso stretto. Il compilatore è, infatti, un elemento tipico di un linguaggio di programmazione e non di un componente hardware. Quelli che chiamiamo in gergo compilatori, riferendoci a componenti hardware, sono più delle interfacce tra i veri compilatori e i layer sottostanti e servono a ottimizzare il funzionamento dell'hardware per cui sono scritti. Quindi, nVidia non può scrivere un compilatore "standard" ossia, ad esempio, per HLSL, che ottimizzi per le sue gpu (c'è già uno standard fissato dalle api di riferimento per quello) ma può creare un layer sottostante che adatti il linguaggio compilato alle sue gpu. Detto questo, se faccimao riferimento proprio a questo ulteriore layer, ovvero quello che consente l'ottimizzazione, ovvero quello che permette di forzare un determinato componente hardware ad assumere determinati comportamenti (ad esmepio a forzare una cpu intel ad otimizzare codice per gpu nVidia), capisci bene che è necessario conoscere l'architettura del chip di cui si vuole manipolare il comportamento.
Diverso il dioscorso dello scrivere un programma per una determinata architettura: scrivere un programma per cpu x86 non comporta una conoscanza approfondita diell'architettura x86 come scrivere un gioco in dx10 non comporta la conoscenza di tutti i chip dx10 prsenti sul mercato. Basta conoscere le api di riferimento (che esistono per quello). Però, avere accesso a dettagli del chip sconosciuto ai più, può aiutare a ottimizzare per per quel particolare tipo di chip.
Un esempio classico, tornando a nVidia e a NV30, è stato fornito da ID software che ha scritto il codice di doom con l'architettura di NV30 come riferimento. A detta dello stesso Carmack, in arb2 standard, R300 era esattamente il doppio più veloce di nv30 (situazione analoga a quella vista in d3d). Quando è uscito doom3, nv30 ed r300 erano pressochè pari come prestazioni. Per ottenere ciò è bastato far leva sui punti di forza di nv30 (calcolo per interi, z fill rate elevato, ombre dinamiche con l'utilizzo di shadow buffer) evitando o riducendo al minimo i punti deboli (calcoli in virgola mobile ed istruzioni matematiche insieme ad operazioni di texture fetch).
Tornando a quanto detto prima, nVidia non si prenderà mai la briga di scrivere un compilatore per hlsl di tipo, diciamo "standard", di quelli integrati nel s.o. e basati sulle api di riferimento, Non potrà mai scrivere un tool che "faccia lavorare" per le sue gpu le cpu intel o amd ottimizzando per loro (dovrebbe conoscerne le architetture e scriverne uno per ciascuna; in pratica dovrebbe scrivere dei driver per cpu :D ). L'unica cosa che pò fare è scrivere driver e tool che ottimizzino il sw per i propri chip facendo tutto ciò che è necessario.
Oppure spingere gli sviluppatori del sw a scrivere codice ottimizzato per i propri chip (come l'esempio che ho citato)

che con compilatore si intendesse la parte software io l'ho sempre dato per scontato nella discussione, ma evidentemente non dovevo farlo, avrei evitato ulteriori incomprensioni. Comunque mi risulta (ma non ci metterei la mano sul fuoco) che intel produca tra i migliori compilatori x86. Ma forse tu intendevi che intel non scrive compilatori GLSL o HLSL, e questo penso sia vero (almeno fino all'arrivo di larrabee). Quello che contesto è che NVIDIA o ATI non abbiano dei compilatori GLSL integrati/pilotati dai driver (da ora scriverò per semplicità solo compilatori nei driver) che tirano fuori il codice degli shader alla bisogna. Che poi l'operazione venga fatta in 2 passaggi (compilatore standard->compilatore driver) può anche essere, anche se la ritengo improbabile. Anche perchè perderebbe di significato avere lo shader testuale, visto che tanto dovrà essere compilato in maniera standard qualsiasi scheda ci giri sotto.
Il caso di NV30 che citi, pur non conoscendo nel dettaglio la faccenda (mi baso su quello che dici, potrei anche avere frainteso), mi sembra che centri poco con quello di cui stiamo parlando. In opengl le arb sono le estensioni che non fanno parte di una versione ufficiale di opengl ma che possono venire comunque usate una volta "approvate" e messe in un profilo (non mi viene meglio...) arb. quando arriva una nuova generazone di api (come le opengl 2.0 rispetto alle 1.5 per esempio) alcune di queste estensioni vengono promosse a core functin e quindi tutte le GPU che si fregiano della compatibilità opengl 2.0 devono riuscire ad eseguire quelle estensioni, che ora estensioni non sono più. Fin quando non sono all'interno delle specifiche dell'api, alcune architetture possono supportare alcune estensioni altre no.
Forse con arb2 ci si riferisce ad un path che corrisponde ad opengl 2.0 (non so se i tempi di sviluppo coincidano), ma comunque il discorso è che non usando stratagemmi particolari Carmack otteneva il doppio di prestazioni da R300, mentre probabilemte usando degli shader alla bisogna con estensioni che supportava solo NV30 o utilizzando al meglio quello che NV30 sapeva fare meglio è riuscito ad ottimizzare meglio il codice su NV30. Probabilmente se avesse fatto altrettanto con R300 anche li si sarebbe avuto un boost prestazionale, ma non saprei. Ad esempio fai giustamente riferimento alle stencil shadow come sistema dinamico per le ombre, che doom3 usa invece che le classiche shadowmap. A differenza di queste ultime, le stencil shadow si calcolano ed usano le risorse della GPU in modo completamente diverso, ed è possibile (anzi probabile) che magari fossero più congeniali all'architettura di NV30 che di R300. Queste cose comunque riguardano la stesura del codice ad alto livello (GLSL), mica la compilazione. E' tutto molto bello, ma non vedo cosa centra con l'argomento di cui stavamo discutendo. Ripeto la citazione dal libro che ho citato già in precedenza:

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

mi sembra talmente chiaro che non richiede ulteriori spiegazioni. Se non vi fidate posso scansionare la pagina, ma mi sembra eccessivo. Certo potrebbe essere una balla, ma la stessa cosa l'ho imparata durante corsi e l'ho trovata in svariati altri libri, tutti autorevoli quanto e più di questo. Ad esempio sono sicuro che c'è una spiegazione + dettagliata nell'orangebook, ma adesso non ho la possibilità di cercare, se qualcuno sul forum ha la possibilità + la voglia di farlo si accomodi. Poi, per carità si possono anche sbagliare tutti. Ma mi sembra comunque una cosa talmente ragionevole e di buon senso che mi pare incredibile che non si faccia. Taralasciando per un attimo la storia MADD/FMA, presumo ce ne siano molte altre di ottimizzazioni che vengano fatte dal driver a livello di compilazione. La stessa MADD come ho già ipotizzato in precedenza, magari non c'era nelle prime architetture programmabili di ATI/NVIDIA (ma su questo di sicuro sei più preparato di me). E' una ipotesi visto che non lo so, è tanto per fare un esempio. magari quindi prima c'erano solo add e mul, ed i compilatori traducevano il codice (ricordo che gli shader sono testuali e non contengono mul e add, ma operazioni ad alto livello) in add e mul. Poi qualcuno ha auvuto l'idea di inserire silicio per una operazione composita in modo da eseguire il tutto + velocemente e così il driver di quella scheda è stato sviluppato per compilare il codice inserendo MADD invece che mul e add (dove sia possibile ovviamente). Magari in futuro (o ci sono già, noon so) i designer introdurranno unità che fanno + cose di una MADD (mul add mul div exp, ecc..), e dovranno quindi aggiornare i compilatori nei loro driver in modo da poter sfruttare queste unità. In questo modo, le schede precedenti continuano a usare il codice compilato come prima, mentre le schede nuove sfrutteranno la nuova compilazione, sia per i giochi vecchi che per quelli nuovi. Poi, come ho già detto, non tutto si può mettere a posto in fase di compilazione, ed infatti una architettura particolare come la VLIW delle ati non la si può mica "domare" solo tramite compilazione. E qui entrano in gioco tutte le strategie che si devono per forza di cose attuare durante l'esecuzione dello shader (che analizzano il flusso di esecuzione), e che nelle CPU, hanno portato alle architetture out of order con branch prediction sofisticatissime e tanti altri barbatrucchi che occupano una porzione maggioritaria di silicio rispetto alle unità di esecuzione vere e proprie. E' infatti proprio per questo che ATOM è così lento se paragonato alle altre moderne CPU, ma senza tutto quel silicio, è anche molto piccolo, "risparmioso" ed economico da produrre. Anche le GPU adotterannno, in misura minore, strategie simili, ma che stanno ad un altro livello di "complessità" di intervento rispetto a quello di cui stiamo parlando, cioè una semplice sostituzione statica. Straripeto un'altra volta: questa particolare ottimizzazione poi magari non potrà avvenire per altri motivi (arrotondamenti, ecc..) che esulano dalle mie conoscenze, ma questo non è il punto.
Adesso sinceramente sono molto impegnato e se darò risposte saranno stringate e non è snobbare o quant'altro, non ho veramente tempo. Non avrei avuto tempo neanche ieri a dirla tutta, ma non pensavo che questa diatriba sarebbe
durata così a lungo.

[devAngnew]

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!

Dici che non ho spiegato molto mentre io credo che per la conoscenza media di questo forum ho detto abbastanza sui compilatori. :)
In particolare ho menzionato un certo modulo (non è altro che un programma che fa parte del compilatore ) ottimizzatore che altro non fa che trasformare codice Assembler in codice Assembler ottimizzato per il processore target.
Successivamente tale codice verrà trasformato in LM (linguaggio macchina) e caricato sulla GPU (nel caso specifico).
Chiedi/ete delle prove ma le uniche prove che io ho sono la letteratura scentifica universitaria di linguaggio formali e compilatori. (non chedetemi di postare nulla nemmeno in privato leggasi copyright)

Qualcun altro dice che il compilatore HLSL no può fare ciò che dico da 20 pagine senza fornire prove ne prendo atto ma sottolineo che ciò è errato.
Successivamente questo qualcuno dice che questo compilatore non esiste proprio :mbe: (ma stiamo scherzando) come avviene il passaggio da HL dello shader allo shader in LM con un interprete sulla GPU (ma stiamo scherzando).
In seguito questo qualcuno sostitusce il compilatore non esiste più ma c'è un tool di cui non si capisce cosa faccia tanto è confuso il discorso.
Potrei continuare su varie domande da me fatte senza ricevere alcuna risposta ma mi fermo qui.
Spero in linea di massima di essere stato chiaro.
Ok chiuso il discorso torniamo a Fermi.

[Severnaya]

Dici che non ho spiegato molto mentre io credo che per la conoscenza media di questo forum ho detto abbastanza sui compilatori. :)


scusa cosa vuol dire che hai spiegato "abbastanza"


abbastanza per chi? per te??? e grazie a sta para de ciufoli :rolleyes:

[skizzo99999999]

Mi è venuto in mente che ho un orange book del 2006 in formato elettronico, e cercando velocemente nella sezione HLSL (piccola, visto che è un libro per GLSL), ho trovato questo:

“One of the main differences between the OpenGL Shading Language and HLSL is in the execution environment (see Figure 21.3). The HLSL compiler is really a translator that lives outside DirectX in the sense that HLSL programs are never sent directly to the DirectX 9 API for execution. Instead, the HLSL compiler translates HLSL source into assembly-level source or binary programs called vertex shaders and pixel shaders (in Microsoft DirectX parlance). Various levels of functionality have been defined for these assembly level shaders, and they are differentiated by a version number (e.g., Vertex Shader 1.0, 2.0, 3.0; Pixel Shader 1.1, 1.4, 2.0, 3.0).
One advantage of this approach is that HLSL programs can be translated offline, or long before the application is actually executed. However, the translation is done to a binary representation of assembly code. This binary representation may still need to be translated to native machine code at execution time. This is in contrast to the OpenGL Shading Language model, in which the compiler is part of the driver, and the graphics hardware vendor writes the compiler. Giving the graphics hardware vendor the responsibility of translating from high-level shading language source to machine code grants these vendors a lot of room for shader optimization and architectural innovation.
HLSL is designed to make it easier for application developers to deal with the various levels of functionality found in these assembly-level shaders. Using HLSL and the support environment that has been built around it, application developers can write shaders in a high-level shading language and be reasonably confident that their shaders will run on hardware with widely varying capabilities.”
OpenGL Shading Language (Orange Book - GLSL 1.2 - 2th Ed 2006) cap 21.4.

Come è scritto chiaramente, in GLSL è il compilatore del driver che compila. In HLSL, almeno al momento della stesura del libro, no, e quindi è molto probabile che la sostituzione funzioni come dici tu. Dico PROBABILE e non SICURO perché non sviluppando in directx non ho certezze in merito. Visto però che di anni ne sono passati ed ora c’è lo shader model 4.0, magari la situazione da quel punto di vista è migliorata e ci si è avvicinati all’approccio dell’OPENGL (o si è trovato qualche compromesso per aggirare il problema e compilare come per il GLSL), o almeno lo spero per le directx…

Spero che questo porti la parola fine alla questione.

[Walrus74]

Premetto che di programmazione, compilazione ecc. non me ne intendo un granchè.
L'ambito di cui mi occupo professionalmente è l'architettura con l'utilizzo di programmi come cad, 3dstudio ecc., però gioco parecchio (o almeno lo facevo :p ).
Prendo come esempi alcuni giochi in cui ricordo che all'inizio dei livelli c'è una barra che dice "caricamento shader" o simili...
Il mai abbastanza rimpianto Timeshift, i titoli Valve (i vari Half Life 2 et similia), Fear 2, Fuel e molti altri che ora si perdono nella memoria...
Ora, da profano, quando faccio partire il gioco, prima di "entrare nel livello" vedo questa barra che si carica con varie didascalie...comunque tutte inerenti gli shader.
Quello che vorrei capire è: non è possibile che questi shader (che servono per fare il render del livello che si sta giocando) vengano pre-caricati nella memoria video e lì stiano finchè non vengono richiamati dalla gpu alla bisogna?
Voglio dire, a cosa servirebbero sti Gigabyte di memoria video se no? (a parte texture ecc...ma di spazio ce n'è in 1 Gb!)
E allora non è possibile che questi shader pre-caricati siano già ottimizzati dai driver (Nvidia o Ati) per girare sulla specifica gpu?
Quindi la conversione di cui voi parlate non avviene "prima" del render?
Dopodichè la gpu quando elabora la scena ha già nella memoria gli shader "convertiti" e non deve ogni volta convertirli?
Boh...a me sembra che almeno nei giochi che ho elencato funzioni così...poi magari sbaglio tutto eh...come dico non è il mio ambito...:D

[skizzo99999999]

C’era anche un grafico in mezzo al discorso dell’orange book:

http://img109.imageshack.us/img109/2233/grafico.jpg

Rende ancora + evidente che la parte “provided by graphics hardware vendor” (e quindi NVIDI o ATI) avvenga prima dell’esecuzione sulla GPU, per cui mi sembra plausibile effettuare una ottimizzazione simile, anche si sicuramente meno efficace (una cosa è avere a disposizione il sorgente come in GLSL, altra cosa è avere solo l’assembler), a quella in essere in opengl. Di sicuro penso che una cosa banale come una sostituzione (in questo caso, visto che l’assembler c’è già, si può effettivamente parlare di sostituzione) la si possa fare tranquillamente a quel punto, e quindi una volta soltanto. Poi magari, come già detto, le cose dal 2006 sono cambiate e dal “nostro” punto di vista non possono che essere migliorate

[yossarian]

...ok yossarian è in errore....ma se è così semplice mutare MADD in FMA al volo perchè nividia ha incluso nell'architettura una sezione che gestisce MADD?...non poteva risparmiarsi transistor e aumentare ulteriormente i transitor per FMA?...

...ciao Andrea...

in realtà non l'ha inclusa. Le alu di fermi sembrerebbero avere delle pipeline di tipo fma che per eseguire una madd impiegano due cicli di clock perchè possono utilizzare solo uno stadio di arrotondamento/troncamento a valle dell'add, in quanto manca quello a valle della mul. In pratica sono come le alu fp64 di una cpu, anche se sono, di fatto, alu fp32 che per lavorare in doppia precisione devono accoppiarsi a due a due.Anche le alu fp64 di gt200 erano dello stesso tipo.

che con compilatore si intendesse la parte software io l'ho sempre dato per scontato nella discussione, ma evidentemente non dovevo farlo, avrei evitato ulteriori incomprensioni. Comunque mi risulta (ma non ci metterei la mano sul fuoco) che intel produca tra i migliori compilatori x86. Ma forse tu intendevi che intel non scrive compilatori GLSL o HLSL, e questo penso sia vero (almeno fino all'arrivo di larrabee). Quello che contesto è che NVIDIA o ATI non abbiano dei compilatori GLSL integrati/pilotati dai driver (da ora scriverò per semplicità solo compilatori nei driver) che tirano fuori il codice degli shader alla bisogna.

bisogna sempre avere chiaro lo schema dei layer esistenti tra applicazione e hardware. Intel, come AMD, nVidia o ATi scrivono dei compilatori, ma non sono quei compilatori presenti all'interno del s.o. che si basano sulle api e fanno da interfaccia tra l'applicazione e i layer sottostanti. Si tratta di compilatori utilizzati da chi scrive le applicazioni e contengono ottimizzazioni per la loro architettura. Ad esempio, i compilatori intel a cui fai riferimento contengono, ad esempio, tutte le estensioni SSE e le altre ottimizzazioni per l'architettura intel. Ciò significa che chi scrive un'applicazione usando quei compilatori scriverà codice ottimizzato per intel. AMD e nVidia fanno la stessa identica cosa. Ma parliamo di applicazioni non di s.o. I compilatori all'interno dei s.o. che si occupano di effettuare la trasduzine di codice ad un livello "digeribile" per l'utilizzatore finale sono di tipo STANDARD e seguono le specifiche delle api di riferimento e basta. Non contengono alcuna particolare ottimizzazione per nessuna architettura, tranne quelle etsensioni, una volta proprietarie, che sono state standardizzate.
Questo significa che il compilatore hlsl o glsl contenuto in una qualsiasi versione di un s.o. non farà mai quello che tu dici che possa fare, ovvero introdurre una specifica ottimizzazione per fermi che non faccia parte dello standard directx o opengl.
Diverso il discorso della swhouse che scrive un gioco adoperando un compiler nVidia che prevede l'uso di fma al posto di madd. In quel caso, il compiler "standard" si troverà delle fma e invierà alla vga delle fma e non della madd. Ma togliti dalla testa che in un s.o. ci siano migliaia di compiler che fanno ottimizzazioni per le diverse architetture in circolazione a seconda delle richieste.
Con nv30 nVidia ha provato a forzare l'uso di un suo compilatore al posto di quello standard: sappiamo tutti come è andata a finire :D

Che poi l'operazione venga fatta in 2 passaggi (compilatore standard->compilatore driver) può anche essere, anche se la ritengo improbabile. Anche perchè perderebbe di significato avere lo shader testuale, visto che tanto dovrà essere compilato in maniera standard qualsiasi scheda ci giri sotto.

no, quello che perderebbe senso è avere uno standard; per quale motivo esistono le api? Non certo per far si che ognuno si compili il codice a suo piacimento. Lo standard esiste, in primo luogo, per far si che tutti quelli che devono o vogliono scrivere codice lo faccianmo avendo un riferimento comune. Una volta funzionava che di una stessa applicazione ne giravano decine di versioni, ognuna ottimizzata per una determinata architettura ed era un gran casino. Così, se avevi un acceleratore grafico PowerVR non potevi cquistare tomb raider in versione 3dfx e viceversa (tanto per fare un esempio). Grazie alla standardizzazione, questo trend si è di molto ridimensionato e oggi, se acquisto un gioco per pc, so che mi gira sia con nVidia che con ATi, ma anche con matrox o s3 o con l'integrata Intel L'unica accortezza è quella di verificare se il mio hw è compatibile con le api di riferimento del gioco. Ovvero, se ho un gioco dx8 e un hw dx7 avrò, ad esempio, degli effetti disabilitati. Questo perchè all'interno dei s.o. girano compilatori di tipo standard che hanno come unico riferimento le api DX e opengl. Se, poi, ti vuoi fare un'ottimizzazione non standard, come la semplice sostituzione di un'istruzione con un'altra (semplice operazione che non è prevista dallo standard però), allora quest'ottimizzazione te la fai a parte e non usando il compiler standard del s.o.


Il caso di NV30 che citi, pur non conoscendo nel dettaglio la faccenda (mi baso su quello che dici, potrei anche avere frainteso), mi sembra che centri poco con quello di cui stiamo parlando. In opengl le arb sono le estensioni che non fanno parte di una versione ufficiale di opengl ma che possono venire comunque usate una volta "approvate" e messe in un profilo (non mi viene meglio...) arb. quando arriva una nuova generazone di api (come le opengl 2.0 rispetto alle 1.5 per esempio) alcune di queste estensioni vengono promosse a core functin e quindi tutte le GPU che si fregiano della compatibilità opengl 2.0 devono riuscire ad eseguire quelle estensioni, che ora estensioni non sono più. Fin quando non sono all'interno delle specifiche dell'api, alcune architetture possono supportare alcune estensioni altre no.
Forse con arb2 ci si riferisce ad un path che corrisponde ad opengl 2.0 (non so se i tempi di sviluppo coincidano), ma comunque il discorso è che non usando stratagemmi particolari Carmack otteneva il doppio di prestazioni da R300, mentre probabilemte usando degli shader alla bisogna con estensioni che supportava solo NV30 o utilizzando al meglio quello che NV30 sapeva fare meglio è riuscito ad ottimizzare meglio il codice su NV30. Probabilmente se avesse fatto altrettanto con R300 anche li si sarebbe avuto un boost prestazionale, ma non saprei. Ad esempio fai giustamente riferimento alle stencil shadow come sistema dinamico per le ombre, che doom3 usa invece che le classiche shadowmap. A differenza di queste ultime, le stencil shadow si calcolano ed usano le risorse della GPU in modo completamente diverso, ed è possibile (anzi probabile) che magari fossero più congeniali all'architettura di NV30 che di R300. Queste cose comunque riguardano la stesura del codice ad alto livello (GLSL), mica la compilazione.
c'entra perchè carmack, in quel caso ha scritto il codice usando come riferimento il compiler di nVidia con le ottimizzazioni per nv30. Se avesse usato come riferimento il codice arb2 (standard opengl 2.0) allora il risultato sarebbe stato differente. Questo all'atto della scrittura del codice. Quando quel codice gira su un pc, non si serve del compiler nVidia ma di quello del s.o. di quel pc che può essere solo quello delle opengl standard che tradurrà le chiamate del codice in maniera del tutto "imparziale" senza fare "favoritismi" o ottimizzazioni di sorta.




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

mi sembra talmente chiaro che non richiede ulteriori spiegazioni. Se non vi fidate posso scansionare la pagina, ma mi sembra eccessivo. Certo potrebbe essere una balla, ma la stessa cosa l'ho imparata durante corsi e l'ho trovata in svariati altri libri, tutti autorevoli quanto e più di questo. Ad esempio sono sicuro che c'è una spiegazione + dettagliata nell'orangebook, ma adesso non ho la possibilità di cercare, se qualcuno sul forum ha la possibilità + la voglia di farlo si accomodi.

infatti è molto chiaro: dice testualmente che l'ogl device dirver può procedere a compilare e ottimizzare perm l'hw sottostante. n.b. ottimizzare secondo quanto prevista dalle api e non dai produttori di hw. Il fatto che accetti codice ad alto livello non aggiunge nulla alla discussione; anche hlsl lo fa: sono stati scritti apposta. Ma una volta scritto il codice, le istruzioni devono essere tradotte a basso livello per essere digerite da un chip e questa traduzione la si fa seguendo gli standard e non gli sghiribizzi e gli umori dei produttori di hardware (per fortuna aggiungerei). Infine dice che è possibile aggiornare facilmente i driver introducendo ottimizzazioni. Certo, infatti, nel caso della sostituzione suddetta puoi introdurre delle istruzioni che dicano che devi eseguire una fma al posto di una madd ma questa sostituzione non te la fa la cpu e non avviene in fase di compilazione da parte del compiler standard. Si appoggia all'hal o ai driver per segnalare al chip grafico che deve effettuare la sotituzione.


Poi, per carità si possono anche sbagliare tutti. Ma mi sembra comunque una cosa talmente ragionevole e di buon senso che mi pare incredibile che non si faccia. Taralasciando per un attimo la storia MADD/FMA, presumo ce ne siano molte altre di ottimizzazioni che vengano fatte dal driver a livello di compilazione.

tutte quelle fuori standard no. Lo standard non prevede che dove trovi una madd esegui una fma e questa sostituzione non avviene a livello di compilazione "standard". Lo standard prevede che dove trovi madd esegui madd e dove trovi fma esegui fma. Il compilatore traduce questa operazioni e le invia alla vram. Il chip grafico esegue le ottimizzazioni non standard.
Ripeto il caso di nv30 dei clipping planes e dello shader replacemnet. Quale compilatore prevede la sostituzione di codice dx9 con codice dx8? E quale compilatore prevede che quando trovi una chiamata 3dmark.exe il chip "tagli" dalla scena tutte le porzioni di spazio non visibili di una techdemo per aumentare il frame rate? Sono ottimizzazioni contenute negli standard DX? Sai chi si occupa delle operazioni geometriche in un'elaborazione grafica? Chi avrebbe potuto fare uso di clipping plane?


La stessa MADD come ho già ipotizzato in precedenza, magari non c'era nelle prime architetture programmabili di ATI/NVIDIA (ma su questo di sicuro sei più preparato di me). E' una ipotesi visto che non lo so, è tanto per fare un esempio. magari quindi prima c'erano solo add e mul, ed i compilatori traducevano il codice (ricordo che gli shader sono testuali e non contengono mul e add, ma operazioni ad alto livello) in add e mul. Poi qualcuno ha auvuto l'idea di inserire silicio per una operazione composita in modo da eseguire il tutto + velocemente e così il driver di quella scheda è stato sviluppato per compilare il codice inserendo MADD invece che mul e add (dove sia possibile ovviamente). Magari in futuro (o ci sono già, noon so) i designer introdurranno unità che fanno + cose di una MADD (mul add mul div exp, ecc..), e dovranno quindi aggiornare i compilatori nei loro driver in modo da poter sfruttare queste unità.
già esistono; non ne abbiamo parlato ma si chiamano special function unit (SFU) e fanno tutta una serie di operazioni come radici quadrate, operazioni trascendenti ecc.


In questo modo, le schede precedenti continuano a usare il codice compilato come prima, mentre le schede nuove sfrutteranno la nuova compilazione, sia per i giochi vecchi che per quelli nuovi.

in questo modo i chip vecchi continueranno ad avere come riferimento le api per cui sono stati progettati e quelli nuovi le ultime uscite.


Poi, come ho già detto, non tutto si può mettere a posto in fase di compilazione, ed infatti una architettura particolare come la VLIW delle ati non la si può mica "domare" solo tramite compilazione.

iniziamo col dire che l'architettura di ATi non è vliw: di vliw ci sono solo le alu ma si tratta di un'architettura ibrida, perfettamente in grado di bilanciare i carichi di lavoro in maniera dinamica e del tutto indipendente dal compiler (un'architettura vliw pura non è in grado di fare una cosa del genere).
Inoltre, mi spieghi perchè sarebbe difficile da "domare" un'architetutra vliw?
Il principio alla base delle architetture vliw è molto semplice: metto insieme tante istruzioni elementari e le trasformo in un'unica istruzione: risparmio transistor e spazio sul silicio e ottengo un livello di parallelismo impensabile con qualsiasi altro tipo di architettura, a costi e complessità di progettazione ridotti. Se, come dici, le ottimizzazioni le fa il compiler "standard", ossia prima che le istruzioni arrivino alla vram, cosa ci vuole a riordinare le stesse in modo da avere sempre 5 istruzioni indipendenti per ogni thread? Peccato che le cose non funzionino così (eppure il riordino delle istruzioni non prevede operazini fuori standard, o sbaglio?). Le 5 istruzioni indipendenti se le deve cercare il thread processor nel momento in cui ha a disposizione le istruzioni stesse e può farlo solo tra quelle a cui ha accesso perchè sono contenute negli instruction buffer. Curioso, non trovi? :D
Altrettanto curioso il fatto che nei bench sintetici relativi ai calcoli geometrici, dove si fa spesso uso di vettori completi e quindi le istruzioni arrivano già "raggruppate" al thread processor, i chip ATi, con alu di tipo vliw ("difficili da domare") demoliscano sistematicamente la controparte nVidia.
Peccato che i giochi non siano solo vertex o geometry shader :sofico:


E qui entrano in gioco tutte le strategie che si devono per forza di cose attuare durante l'esecuzione dello shader (che analizzano il flusso di esecuzione), e che nelle CPU, hanno portato alle architetture out of order con branch prediction sofisticatissime e tanti altri barbatrucchi che occupano una porzione maggioritaria di silicio rispetto alle unità di esecuzione vere e proprie.


gli stessi barbatrucchi li usano da tempo anche le gpu.


E' infatti proprio per questo che ATOM è così lento se paragonato alle altre moderne CPU, ma senza tutto quel silicio, è anche molto piccolo, "risparmioso" ed economico da produrre. Anche le GPU adotterannno, in misura minore, strategie simili, ma che stanno ad un altro livello di "complessità" di intervento rispetto a quello di cui stiamo parlando, cioè una semplice sostituzione statica.

ripeto, anche le gpu adottano le stesse strategie. ATOM è semplicemente in order e dual threaded (ovvero un bel chiodo), una moderna gpu ha un livello di complessità che gli I7 si sognano.
In quanto alla semplice sostituzione statica ti ho già spiegato il motivo per cui il compiler standard non te la farà mai.


Straripeto un'altra volta: questa particolare ottimizzazione poi magari non potrà avvenire per altri motivi (arrotondamenti, ecc..) che esulano dalle mie conoscenze, ma questo non è il punto.
Adesso sinceramente sono molto impegnato e se darò risposte saranno stringate e non è snobbare o quant'altro, non ho veramente tempo. Non avrei avuto tempo neanche ieri a dirla tutta, ma non pensavo che questa diatriba sarebbe
durata così a lungo.

infatti ritengo che sia durata un po' troppo; spero almeno che sia servita a qualcosa. Per quanto mi riguarda non ho altro da aggiungere se non ribadire il concetto che non c'è niente di più fuorviante che confondere i livelli di compilazione fatti all'atto di lanciare un'applicazione da un o.s. e quelli fatti al momento di compilare codice per un'applicazione.

[Bastoner]

Mi sento annichilito :fagiano:

[yossarian]

Mi è venuto in mente che ho un orange book del 2006 in formato elettronico, e cercando velocemente nella sezione HLSL (piccola, visto che è un libro per GLSL), ho trovato questo:

“One of the main differences between the OpenGL Shading Language and HLSL is in the execution environment (see Figure 21.3). The HLSL compiler is really a translator that lives outside DirectX in the sense that HLSL programs are never sent directly to the DirectX 9 API for execution. Instead, the HLSL compiler translates HLSL source into assembly-level source or binary programs called vertex shaders and pixel shaders (in Microsoft DirectX parlance). Various levels of functionality have been defined for these assembly level shaders, and they are differentiated by a version number (e.g., Vertex Shader 1.0, 2.0, 3.0; Pixel Shader 1.1, 1.4, 2.0, 3.0).
One advantage of this approach is that HLSL programs can be translated offline, or long before the application is actually executed. However, the translation is done to a binary representation of assembly code. This binary representation may still need to be translated to native machine code at execution time. This is in contrast to the OpenGL Shading Language model, in which the compiler is part of the driver, and the graphics hardware vendor writes the compiler. Giving the graphics hardware vendor the responsibility of translating from high-level shading language source to machine code grants these vendors a lot of room for shader optimization and architectural innovation.
HLSL is designed to make it easier for application developers to deal with the various levels of functionality found in these assembly-level shaders. Using HLSL and the support environment that has been built around it, application developers can write shaders in a high-level shading language and be reasonably confident that their shaders will run on hardware with widely varying capabilities.”
OpenGL Shading Language (Orange Book - GLSL 1.2 - 2th Ed 2006) cap 21.4.

Come è scritto chiaramente, in GLSL è il compilatore del driver che compila. In HLSL, almeno al momento della stesura del libro, no, e quindi è molto probabile che la sostituzione funzioni come dici tu. Dico PROBABILE e non SICURO perché non sviluppando in directx non ho certezze in merito. Visto però che di anni ne sono passati ed ora c’è lo shader model 4.0, magari la situazione da quel punto di vista è migliorata e ci si è avvicinati all’approccio dell’OPENGL (o si è trovato qualche compromesso per aggirare il problema e compilare come per il GLSL), o almeno lo spero per le directx…

Spero che questo porti la parola fine alla questione.

attenzione, anche le opengl hanno degli standard definiti dall'arb; certo, la ratifica di questi standard è molto più lenta e spesso alcuni produttori, approfittando di queste lungaggini, inseriscono ottimizzazioni ad hoc nei propri driver. Ci sono centinaia di esempi di estensioni proprietarie che si è riusciti a far standardizzare e di altre che, nonostante i ripetuti tentativi, non se ne è potuto fare nulla. Questo non significa che ognuno fa come gli pare. Se un gioco richiede come requisito minimo le opengl 2.0 significa che fa riferimento ad un preciso standard esistente e ratificato e il compiler GLSL eseguirà il lavoro secondo quello standard. Certo, rispetto alle DX dove è MS che rilascia le specifica e inserisce il compilatore nei suoi s.o., hai una maggior libertà ma c'è anche molta più confusione, almeno a livello di programmazione di giochi (e di questo che si sta parlando, visto che le madd servono principalmente per quello). Questa maggior anarchia e il fatto che gli aggiornamento delle specifiche siano sempre troppo in ritardo, hanno fatto spostare la programmazione dei giochi in maniera irreversibile verso le DX che oggi rappresentano una piattaforma di sviluppo decisamente superiore (mentre fino alle DX6 erano un gran troiaio).

Premetto che di programmazione, compilazione ecc. non me ne intendo un granchè.
L'ambito di cui mi occupo professionalmente è l'architettura con l'utilizzo di programmi come cad, 3dstudio ecc., però gioco parecchio (o almeno lo facevo :p ).
Prendo come esempi alcuni giochi in cui ricordo che all'inizio dei livelli c'è una barra che dice "caricamento shader" o simili...
Il mai abbastanza rimpianto Timeshift, i titoli Valve (i vari Half Life 2 et similia), Fear 2, Fuel e molti altri che ora si perdono nella memoria...
Ora, da profano, quando faccio partire il gioco, prima di "entrare nel livello" vedo questa barra che si carica con varie didascalie...comunque tutte inerenti gli shader.
Quello che vorrei capire è: non è possibile che questi shader (che servono per fare il render del livello che si sta giocando) vengano pre-caricati nella memoria video e lì stiano finchè non vengono richiamati dalla gpu alla bisogna?
Voglio dire, a cosa servirebbero sti Gigabyte di memoria video se no? (a parte texture ecc...ma di spazio ce n'è in 1 Gb!)
E allora non è possibile che questi shader pre-caricati siano già ottimizzati dai driver (Nvidia o Ati) per girare sulla specifica gpu?
Quindi la conversione di cui voi parlate non avviene "prima" del render?
Dopodichè la gpu quando elabora la scena ha già nella memoria gli shader "convertiti" e non deve ogni volta convertirli?
Boh...a me sembra che almeno nei giochi che ho elencato funzioni così...poi magari sbaglio tutto eh...come dico non è il mio ambito...:D

si, vengono caricati sulla ram video ma li la gpu non può accedere per fare le ottimizzazioni. Le gpu non lavorano come le cpu e solo in rarissimi casi hanno acceso diretto alla vram e in casi ancora più rari alla ram di sistema. Nella stragrande maggioranza dei casi lavorano effettuando il trasferimento tramite registri. Quindi una unità interna alla gpu ha accesso a tutto ciò che è caricato sui registri ad essa dedicati

[yossarian]

Dici che non ho spiegato molto mentre io credo che per la conoscenza media di questo forum ho detto abbastanza sui compilatori. :)
In particolare ho menzionato un certo modulo (non è altro che un programma che fa parte del compilatore ) ottimizzatore che altro non fa che trasformare codice Assembler in codice Assembler ottimizzato per il processore target.
Successivamente tale codice verrà trasformato in LM (linguaggio macchina) e caricato sulla GPU (nel caso specifico).
Chiedi/ete delle prove ma le uniche prove che io ho sono la letteratura scentifica universitaria di linguaggio formali e compilatori. (non chedetemi di postare nulla nemmeno in privato leggasi copyright)

Qualcun altro dice che il compilatore HLSL no può fare ciò che dico da 20 pagine senza fornire prove ne prendo atto ma sottolineo che ciò è errato.
Successivamente questo qualcuno dice che questo compilatore non esiste proprio :mbe: (ma stiamo scherzando) come avviene il passaggio da HL dello shader allo shader in LM con un interprete sulla GPU (ma stiamo scherzando).
In seguito questo qualcuno sostitusce il compilatore non esiste più ma c'è un tool di cui non si capisce cosa faccia tanto è confuso il discorso.
Potrei continuare su varie domande da me fatte senza ricevere alcuna risposta ma mi fermo qui.
Spero in linea di massima di essere stato chiaro.
Ok chiuso il discorso torniamo a Fermi.
a me risulta che in effetti ci sia qualcuno che continua a scappare senza rispondere alle domande e adesso si cela dietro a copyright inesistenti. Ma questo qualcuno non sono io :D I miei discorsi sonmo lineari e piuttosto chiari, mi sembra, al contrario dei tuoi. E comunque...............

....................ancora aspettando delle risposte, ciccio :sofico:

ps1 (che non è playstation ma post scriptum :sofico: ) quali prove avresti addotto a sostegmno delle tue tesi?
ps2 le prove a sostegno delle mie la sta tirando fuori skizzo
ps3 questo forum è frequentato da gente che lavora da professionista nel campo della programmazione e della progettazione di componenti elettronici.
ps4, forse ti sarà sfuggito ma stiamo parlando di fermi :D

[yossarian]

C’era anche un grafico in mezzo al discorso dell’orange book:

http://img109.imageshack.us/img109/2233/grafico.jpg

Rende ancora + evidente che la parte “provided by graphics hardware vendor” (e quindi NVIDI o ATI) avvenga prima dell’esecuzione sulla GPU, per cui mi sembra plausibile effettuare una ottimizzazione simile, anche si sicuramente meno efficace (una cosa è avere a disposizione il sorgente come in GLSL, altra cosa è avere solo l’assembler), a quella in essere in opengl. Di sicuro penso che una cosa banale come una sostituzione (in questo caso, visto che l’assembler c’è già, si può effettivamente parlare di sostituzione) la si possa fare tranquillamente a quel punto, e quindi una volta soltanto. Poi magari, come già detto, le cose dal 2006 sono cambiate e dal “nostro” punto di vista non possono che essere migliorate

ok, cerchiamo di leggere il grafico:
la prima parte è l'applicazione (fornita dalla swhouse). Questa può essere compilata seguendo lo standard di riferimento o può far uso di un compilatore proprietario di un hardware vendor (come hai detto bene, intel ne fa di ottimi :D .
La seconda fa la traduzione da linguaggio ad alto livello ad assembly ed è fornita da microsoft (ma lo stesso vale nel caso delle opengl, dove ovviamente, il fornitore non sarà MS ma il traduttore dovrà rispettare determinati standard; questo pechè ARB è un consorzio aperto e non un produttore che possa fornire un compiler integrato in un o.s.). Questa è la fase che definite compilazione (ma che di fatto non introduce alcuna ottimizzazione). E' altresì evidente che i driver non agiscono allo stesso livello del compiler del s.o. ma ad un livello più basso (ovvero in un secondo momento).
Terzo stadio, il codice assembly può interfacciarsi con i driver che introducono le ottimizzazioni che non sono esegiute dalla cpu (mi pare evidente). N.b. introdurre l eottimizzazini non significa fare le ottimizzazini. Questo è lo stadio che ho descritto in precedenza in cui l'hal o i driver danno istruzioni al chip grafico su come deve comportarsi in presenza di determinate istruzioni. In questo stadio, il lavoro della cpu è bello che esaurito e, infatti, il codice va al chip grafico che lo elabora e fa tutte le ottimizzazioni del caso.
Come vedi, il processo avviene per gradi e non tutto insieme come ritenevi probabile; ovvero, traduzione (o compilazione se preferisci) e ottimizzazioni sono due step distinti, uno a carico della cpu l'altro della gpu (o del processore della scheda audio o di quello della scheda di rete, dell'HD ecc).

[Bastoner]

Yoss non ho letto una parola di quanto hai scritto perchè non ci capisco un'acca. Oggi ti vedo aggressivo, vai! :sofico:

[Iantikas]

Dici che non ho spiegato molto mentre io credo che per la conoscenza media di questo forum ho detto abbastanza sui compilatori. :)
In particolare ho menzionato un certo modulo (non è altro che un programma che fa parte del compilatore ) ottimizzatore che altro non fa che trasformare codice Assembler in codice Assembler ottimizzato per il processore target.
Successivamente tale codice verrà trasformato in LM (linguaggio macchina) e caricato sulla GPU (nel caso specifico).
Chiedi/ete delle prove ma le uniche prove che io ho sono la letteratura scentifica universitaria di linguaggio formali e compilatori. (non chedetemi di postare nulla nemmeno in privato leggasi copyright)

Qualcun altro dice che il compilatore HLSL no può fare ciò che dico da 20 pagine senza fornire prove ne prendo atto ma sottolineo che ciò è errato.
Successivamente questo qualcuno dice che questo compilatore non esiste proprio :mbe: (ma stiamo scherzando) come avviene il passaggio da HL dello shader allo shader in LM con un interprete sulla GPU (ma stiamo scherzando).
In seguito questo qualcuno sostitusce il compilatore non esiste più ma c'è un tool di cui non si capisce cosa faccia tanto è confuso il discorso.
Potrei continuare su varie domande da me fatte senza ricevere alcuna risposta ma mi fermo qui.
Spero in linea di massima di essere stato chiaro.
Ok chiuso il discorso torniamo a Fermi.

io nn ho nessuna conoscenza specifica in materia...ma il discorso ke sta facendo yossarian lo comprendo, anke di skizzo99999999 capisco il ragionamento xkè segue anke lui una sua logica...


...di ciò ke dici tu nn si capisce un H xkè in ogni post scrivi, scrivi e nn dici niente (ora addirittura x preservare i diritti d'autore :rotfl: )...

...cmq sei divertente da leggere :)

[Bastoner]

io nn ho nessuna conoscenza specifica in materia...ma il discorso ke sta facendo yossarian lo comprendo, anke di skizzo99999999 capisco il ragionamento xkè segue anke lui una sua logica...


...di ciò ke dici tu nn si capisce un H xkè in ogni post scrivi, scrivi e nn dici niente (ora addirittura x preservare i diritti d'autore :rotfl: )...

...cmq sei divertente da leggere :)

In effetti è molto divertente :asd:
Quella del copyright è bellissima :asd:

E questa?

Dici che non ho spiegato molto mentre io credo che per la conoscenza media di questo forum ho detto abbastanza sui compilatori.

Anche un ignorante come me capisce che sta solo :mc:
L'umiltà è la qualità più grande, devAngnew.

[halduemilauno]

http://www.hardware-infos.com/news.php?news=3317
26,7 cm come la gtx285.
;)

[Iantikas]

http://www.hardware-infos.com/news.php?news=3317
26,7 cm come la gtx285.
;)

il mio tedesco è un pò arruginito :D ...l'unica cosa ke capisco è ke il titolo dell'articolo ke posti è una domanda (c'è un punto interrogativo)...quindi c'andrei cautro prima di dire 26,7cm come la gtx285...


...da cosa deduce questo dato?...ciao

[Jackaos]

Dici che non ho spiegato molto mentre io credo che per la conoscenza media di questo forum ho detto abbastanza sui compilatori. :)
In particolare ho menzionato un certo modulo (non è altro che un programma che fa parte del compilatore ) ottimizzatore che altro non fa che trasformare codice Assembler in codice Assembler ottimizzato per il processore target.
Successivamente tale codice verrà trasformato in LM (linguaggio macchina) e caricato sulla GPU (nel caso specifico).
Chiedi/ete delle prove ma le uniche prove che io ho sono la letteratura scentifica universitaria di linguaggio formali e compilatori. (non chedetemi di postare nulla nemmeno in privato leggasi copyright)

Qualcun altro dice che il compilatore HLSL no può fare ciò che dico da 20 pagine senza fornire prove ne prendo atto ma sottolineo che ciò è errato.
Successivamente questo qualcuno dice che questo compilatore non esiste proprio :mbe: (ma stiamo scherzando) come avviene il passaggio da HL dello shader allo shader in LM con un interprete sulla GPU (ma stiamo scherzando).
In seguito questo qualcuno sostitusce il compilatore non esiste più ma c'è un tool di cui non si capisce cosa faccia tanto è confuso il discorso.
Potrei continuare su varie domande da me fatte senza ricevere alcuna risposta ma mi fermo qui.
Spero in linea di massima di essere stato chiaro.
Ok chiuso il discorso torniamo a Fermi.

Riguardo al "Tool" mi pare che yossarian abbia semplicemente voluto precisare che questo fosse il termine più corretto per quanto riguarda la GPU senza scendere in particolari e che per questo non ci fosse un compilatore, e che sia rimasto a parlare di compilatore proprio per restare nel discorso con la vostra terminologia venendovi incontro per meglio comprendervi e farvi comprendere senza scendere in particolari magari inutili ai fini della logica del suo discorso. Inoltre siamo arrivati a parlare della trasformazione di linguaggi ad alto livello a linguaggio macchina per cercare di capire come mai tu sostenessi che tutto questo avvenga a costo zero, quando yossarian vi dice che fondamentalmente per come sono fatte le gpu a costo zero non può avvenire, perchè non c'è nessuna magica entità che andrà a fare il lavoro per lei. Per il resto sono daccordo, hai usato termini e sei entrato in argomenti che io di sicuro non conosco, ma resta se non altro la mia impressione che le tue spiegazioni siano meno articolate e più confuse. Tu comunque sostieni che le cose siano in un modo e forse ritieni che non ci sia molto da aggiungere e da speigare, le cose sono così e basta, magari un fatto semplice non ha bisogno di molte parole, io non ho modo di verificare, magari prenderò spunto da questa interessante discussione per apprendere qualcosa di più su questi marchingegni. Ciao!

[Kharonte85]

http://www.hardware-infos.com/news.php?news=3317
26,7 cm come la gtx285.
;)

il mio tedesco è un pò arruginito :D ...l'unica cosa ke capisco è ke il titolo dell'articolo ke posti è una domanda (c'è un punto interrogativo)...quindi c'andrei cautro prima di dire 26,7cm come la gtx285...


...da cosa deduce questo dato?...ciao

Lo sapevamo già:



NVIDIA Fun fact of the week: The GF100 board pictured in last's week's fun fact is 10.5-inches long -- the same length as GeForce GTX 200 Series graphics cards!


http://www.facebook.com/permalink.php?story_fbid=183411813660&id=8409118252

:)

[halduemilauno]

Lo sapevamo già:



:)

OK.
;)

[devAngnew]

In effetti è molto divertente :asd:
Quella del copyright è bellissima :asd:




Senti le mie fonti sono testi universitari che parla di linguaggi formali e compilatori e del loro funzionamento.
Se vuoi crederci bene altrimenti fà come ti pare e ridi pure del copyright.
di certo non posto le pagine del libro per dimostrare come funziona un compilatore.




Anche un ignorante come me capisce che sta solo :mc:
L'umiltà è la qualità più grande, devAngnew.

Infatti sono daccordo ma non è a me che manca ma qualcun altro.

[yossarian]

Senti le mie fonti sono testi universitari che parla di linguaggi formali e compilatori e del loro funzionamento.
Se vuoi crederci bene altrimenti fà come ti pare e ridi pure del copyright.
di certo non posto le pagine del libro per dimostrare come funziona un compilatore.





Infatti sono daccordo ma non è a me che manca ma qualcun altro.

mi commenti questo, postato da skizzo e preso dall'orange book (strano che lui non abbia problemi di copyright)?

http://img109.imageshack.us/img109/2233/grafico.jpg

a che livello interverrebbe la cpu e a quale livello si farebbero le ottimizzazioni secondo questo grafico?

Ops, wikipedia non ti dà informazioni al riguardo? :sofico:

[Bastoner]

Senti le mie fonti sono testi universitari che parla di linguaggi formali e compilatori e del loro funzionamento.
Se vuoi crederci bene altrimenti fà come ti pare e ridi pure del copyright.
di certo non posto le pagine del libro per dimostrare come funziona un compilatore.

Hai paura che la finanza faccia un blitz su hwupgrade? :D
Se non sbaglio si può fotocopiare, riprodurre e pubblicare il 10% di un libro senza violare i diritti d'autore, correggetemi se sbaglio. Se posti qualche riga non fai danno a nessuno.





Infatti sono daccordo ma non è a me che manca ma qualcun altro.

Urca non m'ero accorto di quale spiccata umiltà fossi dotato. :sofico:



Ops, wikipedia non ti dà informazioni al riguardo? :sofico:

Ma LOL.

[The_SaN]

Dici che non ho spiegato molto mentre io credo che per la conoscenza media di questo forum ho detto abbastanza sui compilatori. :)Chiederó di bloccarti l'accesso all' angolo della topa :O

@Yossarian e skizzo

Grazie mille per il contributo al thread.
Terró conto di tutte queste preziose informazioni, tra 1 anno circa dovró studiare queste cose :)

[ally]

in realtà non l'ha inclusa. Le alu di fermi sembrerebbero avere delle pipeline di tipo fma che per eseguire una madd impiegano due cicli di clock perchè possono utilizzare solo uno stadio di arrotondamento/troncamento a valle dell'add, in quanto manca quello a valle della mul. In pratica sono come le alu fp64 di una cpu, anche se sono, di fatto, alu fp32 che per lavorare in doppia precisione devono accoppiarsi a due a due.Anche le alu fp64 di gt200 erano dello stesso tipo.


...ok...chiaro...

...ciao Andrea...

[Bastoner]

Chiederó di bloccarti l'accesso all' angolo della topa :O




Eh? :mbe:

[The_SaN]

Eh? :mbe:Per mancanza di conoscenze a riguardo (lo so, battuta pessima)

[Kharonte85]

Hai paura che la finanza faccia un blitz su hwupgrade? :D
Se non sbaglio si può fotocopiare, riprodurre e pubblicare il 10% di un libro senza violare i diritti d'autore, correggetemi se sbaglio. Se posti qualche riga non fai danno a nessuno.

OT/ dipende, alcuni testi esplicitamente vietano la riproduzione anche parziale.

[skizzo99999999]

bisogna sempre avere chiaro lo schema dei layer esistenti tra applicazione e hardware. Intel, come AMD, nVidia o ATi scrivono dei compilatori, ma non sono quei compilatori presenti all'interno del s.o. che si basano sulle api e fanno da interfaccia tra l'applicazione e i layer sottostanti. Si tratta di compilatori utilizzati da chi scrive le applicazioni e contengono ottimizzazioni per la loro architettura. Ad esempio, i compilatori intel a cui fai riferimento contengono, ad esempio, tutte le estensioni SSE e le altre ottimizzazioni per l'architettura intel. Ciò significa che chi scrive un'applicazione usando quei compilatori scriverà codice ottimizzato per intel. AMD e nVidia fanno la stessa identica cosa. Ma parliamo di applicazioni non di s.o. I compilatori all'interno dei s.o. che si occupano di effettuare la trasduzine di codice ad un livello "digeribile" per l'utilizzatore finale sono di tipo STANDARD e seguono le specifiche delle api di riferimento e basta. Non contengono alcuna particolare ottimizzazione per nessuna architettura, tranne quelle etsensioni, una volta proprietarie, che sono state standardizzate.
Questo significa che il compilatore hlsl o glsl contenuto in una qualsiasi versione di un s.o. non farà mai quello che tu dici che possa fare, ovvero introdurre una specifica ottimizzazione per fermi che non faccia parte dello standard directx o opengl.
Diverso il discorso della swhouse che scrive un gioco adoperando un compiler nVidia che prevede l'uso di fma al posto di madd. In quel caso, il compiler "standard" si troverà delle fma e invierà alla vga delle fma e non della madd. Ma togliti dalla testa che in un s.o. ci siano migliaia di compiler che fanno ottimizzazioni per le diverse architetture in circolazione a seconda delle richieste.
Con nv30 nVidia ha provato a forzare l'uso di un suo compilatore al posto di quello standard: sappiamo tutti come è andata a finire :D


veramente sei te che continui a tirare fuori i compilatori del s.o., io non ne ho mai parlato. Nel GLSL l's.o. non compila nulla, è il driver di NVIDIA/ATI (e quindi il compilatore NVIDIA/ATI) che lo fa. quindi la compilazione avviene sfruttando, nel limite del possibile di quello che si può fare a compile time (dello shader, non dell'applicazione), al max l'architettura che trova sotto.
Secondo me continui a confondere la compilazione dell'applicativo (il quale gira sulla CPU), con la compilazione dello shader che, almeno in GLSL viene compilato dal driver per poi girare sulla GPU. Una software House non sceglie di usare un compiler microsodt, NVIDIA, ATI o quant'altro: non compila niente. E' molto semplice. La software house scrive l'applicazione, compila l'applicazione. Scrive lo shader E NON LO COMPILA. E' il driver che si fa carico di compilare a runtime lo shader GLSL. quindi non c'è un compiler standard e uno meno standard, c'è solo quello del driver, che quindi varia da architettura a architettura, e che ovviamente ha come vincolo far ottenere gli stessi risultati numerici da tutte le architetture (o almeno così dovrebbe essere, se le 2 case produttrici di chip lavorassero sempre in modo impeccabile). Mi è capitato una volta di trovare un catalyst (mi sembra 6.x o 7.x) che aveva svariati bug nella gestione degli FBO (frame buffer object) che provocavano crash e artefatti vari. E' poi venuto fuori che compilavano male gli shader. Da questo punto di vista in quel periodo i driver ATI di quel periodo erano una tortura, con continui fix e poi fix che introducevano altri errori.
Il tutto mi sembra talmente evidente dai due stralci tratti dai libri che ho postato, ma evidentemente non abbastanza. Io più chiaro ed esplicito di così non riesco ad essere.

[yossarian]

Yoss non ho letto una parola di quanto hai scritto perchè non ci capisco un'acca. Oggi ti vedo aggressivo, vai! :sofico:

più che altro sono stanco di discutere con uno che sono tre giorni che afferma che fermi avrà bello e pronto il codice già ottimizzato perchè ci penserà un non ben precisato compiler fatto girare da una non ben precisata entità presente dentro il pc (forse la marmotta?:D ) che gli farà avere tutta la pappa pronta nella ram video.
Quando gli si chiede dove dovrebbero avvenire queste ottimizzazioni e chi dovrebbe farle e a che livello, non risponde o si trincera dietro un: "è così perchè me lo ha detto la mamma" traducibile con: "l'ho letto su libri che voi umani non potete neanche immaginare" (e che non posso postare perchè portetti dal segreto di stato). Però mi appello al quinto emendamento ed alla convenzione di ginevra. :fagiano:

Per fortuna che abbimao anche una immagine, questa
http://img109.imageshack.us/img109/2233/grafico.jpg
da cui si evince chiaramente che questo famigerato compiler (che altro non è che quello standard hlsl presente all'interno del s.o. e fatto girare dalla cpu, non fa altro che limitarsi a tradurre le istruzioni da linguaggio strutturato a linguaggio a basso livello comprensibile per i destinatari. D'altro canto, chi sa come funziona un pc sa anche che la cpu si occupa di distribuire il lavoro tra le diverse periferiche e deve farlo usando un linguaggio comprensibile a queste periferiche.
Dalla stessa immagine si vede chiaramente che le ottimizzazioni vengono fatte ad un livello più basso e non è la cpu ad occuparsene; a meno che, si dovrebbe pensare che la cpu prima si occupi di tradurre tutto il codice, poi lo richiami di nuovo tutto indietro e proceda a fare le ottimizzazioni per ciascuna periferica (ci si dimentica che un pc non è fatto di sola scheda video, evidentemente :rolleyes: ).
A questo punto, le ottimizzazioni per il chip grafico può farle solo il chip grafico guidato dai suoi driver (driver significa, appunto, conducente, guidatore, colui che guida, ecc). Ora, salvo pensare che questi driver (del chip grafico) non pilotino anche la cpu, verrebbe spontaneo immaginare che, in questo universo e in questo tempo (cosa accada in universi paralleli sfugge al controllo dei nostri sensi) sia la gpu a fare le ottimizzazioni relative. Ammesso che sia così, dove le fa? Ma nella ram video, ovvio, prima che il programma viene caricato, così arriva già tutto bello pronto (me lo ha detto la mamma :D ). Sbagliato, il thread processor della gpu (che è il suo processore interno che fa lo stesso lavoro della cpu di un pc) non ha accesso diretto alla ram video ma può accedere solo alle informazioni contenute nei suoi registri. C'è un motivo pratico perchè ciò avvenga ma non sto qui a dilungarmi ulteriormente (dico solo che così l'elaborazione risulta più fluida e e veloce ma questo è un argomento che può essere compreso solo da chi sa come funziona una gpu). Quindi il thread processor non lavora sulla vram ma sui suoi registri. A questo punto sappiamo chi fa le ottimizzazioni, dove e quando?
Sbagliato, perchè la mamma ha deto che le cose non stanno così e chi sostiene il contrario non è abbastanza umile da riconoscere l'errore. :muro:

Almeno skizzo ha avuto l'intelligenza di ammettere di non conoscere determinati argomenti e ha avuto il merito di arricchire la discussione portando, come contributo, la sua esperienza personale.

[Bastoner]

più che altro sono stanco di discutere con uno che sono tre giorni che afferma che fermi avrà bello e pronto il codice già ottimizzato perchè ci penserà un non ben precisato compiler fatto girare da una non ben precisata entità presente dentro il pc (forse la marmotta?:D ) che gli farà avere tutta la pappa pronta nella ram video.
Quando gli si chiede dove dovrebbero avvenire queste ottimizzazioni e chi dovrebbe farle e a che livello, non risponde o si trincera dietro un: "è così perchè me lo ha detto la mamma" traducibile con: "l'ho letto su libri che voi umani non potete neanche immaginare" (e che non posso postare perchè portetti dal segreto di stato). Però mi appello al quinto emendamento ed alla convenzione di ginevra. :fagiano:

Su consolati, hai sostenuto discussioni peggiori (non facciamo nomi) :fagiano:


Per fortuna che abbimao anche una immagine, questa
http://img109.imageshack.us/img109/2233/grafico.jpg
da cui si evince chiaramente che questo famigerato compiler (che altro non è che quello standard hlsl presente all'interno del s.o. e fatto girare dalla cpu, non fa altro che limitarsi a tradurre le istruzioni da linguaggio strutturato a linguaggio a basso livello comprensibile per i destinatari.


E già, è proprio chiaro. Oserei dire lapalissiano, anche un bambino se ne accorgerebbe :O

:bsod:

[yossarian]

veramente sei te che continui a tirare fuori i compilatori del s.o., io non ne ho mai parlato. Nel GLSL l's.o. non compila nulla, è il driver di NVIDIA/ATI (e quindi il compilatore NVIDIA/ATI) che lo fa. quindi la compilazione avviene sfruttando, nel limite del possibile di quello che si può fare a compile time (dello shader, non dell'applicazione), al max l'architettura che trova sotto.
Secondo me continui a confondere la compilazione dell'applicativo (il quale gira sulla CPU), con la compilazione dello shader che, almeno in GLSL viene compilato dal driver per poi girare sulla GPU. Una software House non sceglie di usare un compiler microsodt, NVIDIA, ATI o quant'altro: non compila niente. E' molto semplice. La software house scrive l'applicazione, compila l'applicazione. Scrive lo shader E NON LO COMPILA. E' il driver che si fa carico di compilare a runtime lo shader GLSL. quindi non c'è un compiler standard e uno meno standard, c'è solo quello del driver, che quindi varia da architettura a architettura, e che ovviamente ha come vincolo far ottenere gli stessi risultati numerici da tutte le architetture (o almeno così dovrebbe essere, se le 2 case produttrici di chip lavorassero sempre in modo impeccabile). Mi è capitato una volta di trovare un catalyst (mi sembra 6.x o 7.x) che aveva svariati bug nella gestione degli FBO (frame buffer object) che provocavano crash e artefatti vari. E' poi venuto fuori che compilavano male gli shader. Da questo punto di vista in quel periodo i driver ATI di quel periodo erano una tortura, con continui fix e poi fix che introducevano altri errori.
Il tutto mi sembra talmente evidente dai due stralci tratti dai libri che ho postato, ma evidentemente non abbastanza. Io più chiaro ed esplicito di così non riesco ad essere.

non cambia nulla all'atto pratico e ai fini del discorso; il nocciolo della questione è sempre lo stesso: la gpu non ha la pappa pronta perchè nessuno gliela prepara. In opengl non c'è un compiler integratoi nel s.o. perchè. come ho detto, non esiste un o.s. prodotto dall'ARB. Quindi, quando gira un'applicazione opengl, ci sia un compiler PIPPO a fare la traduzione o che i driver operino direttamente ad alto livello occupandosi anche della traduzione nno sposta di una cippa il discorso.
I driver del chip grafico non pososno (e lo ripeto per l'ultima volta) gestire nessun tipo di ottimizzazione fino all'intervento dello stesso chip grafico. E questo può lavorare solo sulle istruzioni caricate al suo interno e non su quelkle contenute nella vram o nella ram di sistema. Il procedimento è sempre lo stesso: prima le istruzioni vengono tradotte (ma senza ottimizzazioni) e questo può farlo anche la cpu. Poi si fanno le ottimizzazioni (e questo non lo fa la cpu).
Il compiler deli driver non è fatto a cappella: ha sempre una parte che fa riferimento ad uno standard (oppure dobbiamo pensare che i tizi che fanno parte del consorzio ARB in cui sono presenti anche ATi, nVidia e AMD) si riuniscano, di tanto in tanto, per passare un po di tempo e giocare a canasta. Questa parte STANDARD è quella che si occupa della traduzione ed è uguale per tutti. Le ottimizzazioni sono a parte. Anche i driver per dx hanno una parte standard (altrimenti come si interfacciano e con cosa) e una parte contenente ottimizazioni.
L'immagine che hai postato, riferita alle opengl, sarebbe identica: l'unica differenza sta nel fatto che la traduzione non avviene grazie a microsoft ma grazie alle specifiche dello standard arb di riferimento contenute nei driver degli hw vendor. Un piccolo insignificante particolare che sembri trascurare è che se con le dx qualcuno opera una traduzione a beneficio del chip grafico, ciò non avviene perchè le dx sono una chiavica di api e le opengl sono fiche (a prescindere dal fatto che a detta dei coder e a giudicare dal parco giochi in dx e in ogl sembrerebbe l'esatto opposto, almeno per i videogame) perchè avviene tutto ad alto livello; avviene semplicemente perchè il chip grafico ha bisogno che qualcuno gli traduca il codice che, altrimenti non riesce a leggere: questo avviene tanto con le dx che con le opengl e se lo fa un traduttore standard integrato nel s.o. o lo fa un traduttore atrettanto standard presente nei driver non cambia assolutamente niente. Sai a cosa serva uno standard? A far si che soggetti diversi provenienti da ambienti diversi, possano comunicare tra di loro. MI spieghi come fanno a comunicare soggetti che non usano lo stesso linguaggio (il programmatore sceglie di compilare il gioco come gli pare, il produttore della scheda video inventa il suo driver, quello del processore il suo, quello dellascheda audio il suo, ecc; in questo modo, non solo non ti gira l'applicaziona ma non ti parte neppure il pc :D ). Il vincolo di cui parli (ottenere gli stessi risultati numerici) equivale al vincolo di rispettare quegli standard che permettono l'ottenimento di quei risultati. Quindi se lo standard dx11 o arb3.5 ti dicono che una determinata operazione deve avere una altrettanto determinata precisione di calcolo, non puoi scrivere un driver che invece di, ipotesi, fp32, ti fa l'operazione a INT8; altrimenti non ottieni lo stesso risultato numerico e chi se ne frega se la tua architettura con INT8 lavora maglio che con fp32.
La swhouse, invece sceglie se compilare seguendo lo standrad dx o ogl o seguendo le ottimizzazioni ati, nvidia, intel ecc, eccome; per questo esistono i compilatori (compresi quelli custom). Cosa credi che qualcuno si prenda la briga di scrivere milioni di righe di codice in c senza fare uso di un compilatore? Uno degli step è proprio la compilazione e la correzione degli errori (editor, compiler, debugger). Ma per farlo posso far riferimento allo standard o ottimizzare per una determinata architettura e, ìdi conseguenza, scegliere il tipo di compilatore.
Riguardati l'immagine che hai postato, è fin troppo chiara e guarda anche questo è uno schema dei vari layer; è di fonte microsoft ma non cambia assolutamente nulla per le opengl

http://i.msdn.microsoft.com/Cc185077.micro1(it-it,MSDN.10).jpg

(ti dice nulla la parola inteprete? Sai quelli che traducono da un linguaggio ad un altro e che non possono farlo ad capocchiam ma devono rispettare delle regole sennò non ci si capisce una cippa? Ecco, quell'interprete lo fa girare la cpu che, però, non fa ottimizzazioni ma solo traduzioni, in dx e in opengl)
e se, nonostante tutto, vuoi continuare a pensare che programmare in opengl voglia dire farlo nella piùtotale anarchia, libero di pensarlo. Tanto questo non farà si che la cpu faccia tutto il lavoro per fermi o che la gpu riceva il codice già bello e pronto per essere eseguito (grazie all'intervento dello spirito santo)

[Wikkle]

sbaglio o i nuovi drivere sono fake e sono ancora i .55?

[molochgrifone]

sbaglio o i nuovi drivere sono fake e sono ancora i .55?

Se clicki il link nell'area download di hwup ci sono effettivamente i .55, qua invece ci sono i .62

http://www.nvidia.it/object/win7_winvista_32bit_195.62_whql_it.html

versione 32 bit, e qua i 64 bit http://www.nvidia.it/object/win7_winvista_64bit_195.62_whql_it.html

se invece ti rifersci ad altro non so :stordita:

[skizzo99999999]

più che altro sono stanco di discutere con uno che sono tre giorni che afferma che fermi avrà bello e pronto il codice già ottimizzato perchè ci penserà un non ben precisato compiler fatto girare da una non ben precisata entità presente dentro il pc (forse la marmotta?:D ) che gli farà avere tutta la pappa pronta nella ram video.
Quando gli si chiede dove dovrebbero avvenire queste ottimizzazioni e chi dovrebbe farle e a che livello, non risponde o si trincera dietro un: "è così perchè me lo ha detto la mamma" traducibile con: "l'ho letto su libri che voi umani non potete neanche immaginare" (e che non posso postare perchè portetti dal segreto di stato). Però mi appello al quinto emendamento ed alla convenzione di ginevra. :fagiano:

Per fortuna che abbimao anche una immagine, questa
http://img109.imageshack.us/img109/2233/grafico.jpg
da cui si evince chiaramente che questo famigerato compiler (che altro non è che quello standard hlsl presente all'interno del s.o. e fatto girare dalla cpu, non fa altro che limitarsi a tradurre le istruzioni da linguaggio strutturato a linguaggio a basso livello comprensibile per i destinatari. D'altro canto, chi sa come funziona un pc sa anche che la cpu si occupa di distribuire il lavoro tra le diverse periferiche e deve farlo usando un linguaggio comprensibile a queste periferiche.
Dalla stessa immagine si vede chiaramente che le ottimizzazioni vengono fatte ad un livello più basso e non è la cpu ad occuparsene; a meno che, si dovrebbe pensare che la cpu prima si occupi di tradurre tutto il codice, poi lo richiami di nuovo tutto indietro e proceda a fare le ottimizzazioni per ciascuna periferica (ci si dimentica che un pc non è fatto di sola scheda video, evidentemente :rolleyes: ).
A questo punto, le ottimizzazioni per il chip grafico può farle solo il chip grafico guidato dai suoi driver (driver significa, appunto, conducente, guidatore, colui che guida, ecc). Ora, salvo pensare che questi driver (del chip grafico) non pilotino anche la cpu, verrebbe spontaneo immaginare che, in questo universo e in questo tempo (cosa accada in universi paralleli sfugge al controllo dei nostri sensi) sia la gpu a fare le ottimizzazioni relative. Ammesso che sia così, dove le fa? Ma nella ram video, ovvio, prima che il programma viene caricato, così arriva già tutto bello pronto (me lo ha detto la mamma :D ). Sbagliato, il thread processor della gpu (che è il suo processore interno che fa lo stesso lavoro della cpu di un pc) non ha accesso diretto alla ram video ma può accedere solo alle informazioni contenute nei suoi registri. C'è un motivo pratico perchè ciò avvenga ma non sto qui a dilungarmi ulteriormente (dico solo che così l'elaborazione risulta più fluida e e veloce ma questo è un argomento che può essere compreso solo da chi sa come funziona una gpu). Quindi il thread processor non lavora sulla vram ma sui suoi registri. A questo punto sappiamo chi fa le ottimizzazioni, dove e quando?
Sbagliato, perchè la mamma ha deto che le cose non stanno così e chi sostiene il contrario non è abbastanza umile da riconoscere l'errore. :muro:

Almeno skizzo ha avuto l'intelligenza di ammettere di non conoscere determinati argomenti e ha avuto il merito di arricchire la discussione portando, come contributo, la sua esperienza personale.

guarda che l'immagine io l'ho postata per farti capire che quel compilatore la in alto chiamato HLSL translator in GLSL NON C'E', e se c'è non viene usato, ma invece viene fatto tutto nella parte sotto, dove nel grafico c'è scritto directx driver e che in opengl sarà ovviamente opengl driver. Questo driver non è ne del S.O., ne di microsoft ma del produttore di schede, che infatti si compila il sorgente GLSL come vuole, e se lo fa male sono ca**i suoi, l'utente e lo sviluppatore si incazzeranno e si lamentaranno con chi di dovere. Il sorgente viene compilato tutte le volte che il gioco viene eseguito.

In HLSL invece, come da schema, evidentemente c'è sto fantomatico compilatore standard che fornisce miscrosoft nel suo s.o. e che fornisce al driver lo shader già compilato. Ma il driver non è fatto da microsft e non è del s.o., ma è fatto da ATI/NVIDIA, che come risulta evidente, non prende il codice che gli arriva o lo da in pasto alla GPU e basta. Entra l'assembly source code ed esce l'executable code, poi è quest'ultimo che gira in esecuzione sulla GPU per renderizzare il nostro gioco o quant'altro. Infatti è a questo punto che c'è la freccetta verso il graphics hardware.
Ora non potrebbe e dico potrebbe essere che questa sostituzione avvenga qui, PRIMA che lo shader passi effettivamente all'esecuzione sul graphics hardware? non mi sembra un concetto così strampalato, visto che questa parte di codice sarà diversa a seconda del driver e quindi una per ogni scheda video.
Non mi pare un concetto così difficile da comprendere.


non cambia nulla all'atto pratico e ai fini del discorso; il nocciolo della questione è sempre lo stesso: la gpu non ha la pappa pronta perchè nessuno gliela prepara. In opengl non c'è un compiler integratoi nel s.o. perchè. come ho detto, non esiste un o.s. prodotto dall'ARB. Quindi, quando gira un'applicazione opengl, che sia la cpu a fare la traduzione o che i driver operino direttamente ad alto livello occupandosi anch della traduzione nno sposta di una cippa il discorso.
I driver del chip grafico non pososno (e lo ripeto per l'ultima volta) gestire nessun tipo di ottimizzazione fino all'intervento dello stesso chip grafico. E questo può lavorare solo sulle istruzioni caricate al suo interno e non su quelkle contenute nella vram o nella ram di sistema. Il procedimento è sempre lo stesso: prima le istruzioni vengono tradotte (ma senza ottimizzazioni) e questo può farlo anche la cpu. Poi si fanno le ottimizzazioni (e questo non lo fa la cpu).
Il compiler deli driver non è fatto a cappella: ha sempre una parte che fa riferimento ad uno standard (oppure dobbiamo pensare che i tizi che fanno parte del consorzio ARB in cui sono presenti anche ATi, nVidia e AMD) si riuniscano, di tanot in tanto, per passare un po di tempo e giocare a canasta. Questa parte STANDARD è quella che si occupa della traduzione ed è uguale per tutti. Le ottimizzazioni sono a parte. Anche i driver per dx hanno un aparte standard (altrimenti come si interfacciano e con cosa) e una parte contenente ottimizazioni.
L'immagine che hai postato, riferita alle opengl, sarebbe identica: l'unica differenza sta nel fatto che la traduzione non avviene grazie a microsoft ma grazie alle specifiche dello standard arb di riferimento contenute nei driver degli hw vendor.


sinceramente non so da dove prendi la convinzione che i compilatori all'interno del driver non possano che compilare in modo "fisso". la citazione dal superbible evidenzia proprio che il driver, almeno per quanto riguarda OPENGL, non fa una traduzione fissa. E' solo questo il nodo del contendere.
Se vuoi te la incollo di nuovo:

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

[Wikkle]

Se clicki il link nell'area download di hwup ci sono effettivamente i .55, qua invece ci sono i .62

http://www.nvidia.it/object/win7_winvista_32bit_195.62_whql_it.html

versione 32 bit, e qua i 64 bit http://www.nvidia.it/object/win7_winvista_64bit_195.62_whql_it.html

se invece ti rifersci ad altro non so :stordita:

intendevo proprio quello... grazie ;)
Anche dal link sul sito nvidia nn funzionava...

[Rsdj]

Yoss ma come fai a trovare tutta questa pazienza per continuare a postare senza esito positivo??? :D cmq se ti va passa a farti un giro nel thread della 5970 ;)

[yossarian]

guarda che l'immagine io l'ho postata per farti capire che quel compilatore la in alto chiamato HLSL translator in GLSL NON C'E', e se c'è non viene usato, ma invece viene fatto tutto nella parte sotto, dove nel grafico c'è scritto directx driver e che in opengl sarà ovviamente opengl driver. Questo driver non è ne del S.O., ne di microsoft ma del produttore di schede, che infatti si compila il sorgente GLSL come vuole, e se lo fa male sono ca**i suoi, l'utente e lo sviluppatore si incazzeranno e si lamentaranno con chi di dovere. Il sorgente viene compilato tutte le volte che il gioco viene eseguito.

In HLSL invece, come da schema, evidentemente c'è sto fantomatico compilatore standard che fornisce miscrosoft nel suo s.o. e che fornisce al driver lo shader già compilato. Ma il driver non è fatto da microsft e non è del s.o., ma è fatto da ATI/NVIDIA, che come risulta evidente, non prende il codice che gli arriva o lo da in pasto alla GPU e basta. Entra l'assembly source code ed esce l'executable code, poi è quest'ultimo che gira in esecuzione sulla GPU per renderizzare il nostro gioco o quant'altro. Infatti è a questo punto che c'è la freccetta verso il graphics hardware.
Ora non potrebbe e dico potrebbe essere che questa sostituzione avvenga qui, PRIMA che lo shader passi effettivamente all'esecuzione sul graphics hardware? non mi sembra un concetto così strampalato, visto che questa parte di codice sarà diversa a seconda del driver e quindi una per ogni scheda video.
Non mi pare un concetto così difficile da comprendere.



sinceramente non so da dove prendi la convinzione che i compilatori all'interno del driver non possano che compilare in modo "fisso". la citazione dal superbible evidenzia proprio che il driver, almeno per quanto riguarda OPENGL, non fa una traduzione fissa. E' solo questo il nodo del contendere.
Se vuoi te la incollo di nuovo:

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

ok, basta mi arrendo; in opengl ognuno si compila il driver come vuole, la cpu fa tutto il lavoro per fermi che si ritrova la pappa bella e pronta, siamo tutti più felici e contenti e il pc non parte più.
Va bene così?

Cos'altro vuoi che risponda ad uno che continua a uppare cose che contraddicono le sue stesse parole (mi indichi, nella frase che hai riportato, dove è scritto che non esiste uno standard e dove è scritto che è le ottimizzazioni sono fatte contestualmente alla traduzione del codice sorgente, grazie?), che afferma che una swhouse non fa uso di compilatori quando scrive i suoi programmi e che, di fatto, in opengl NON ESISTE UNO STANDARD (poi mi spiegherai cosa è l'ARB e cosa minchia ci fanno tutti quei tizi, oltre a prendere il caffè alle 5 pm e giocare a bridge). Per la cronaca, il fantomatico traduttore che hai trovato nello schema che hai postato tratto dall'orange book (va meglio così) dell'hlsl opengl è un volgarissimo traduttore c-like come quello del glsl. E sempre per la cronaca, visto che continui a ripetere che la sostituzione potrebbe avvenire prima che il codice arrivi alla gpu, ti inolìtro formale comunicazione che un chip grafico non è in grado di leggere istruzioni ad alto livello (e, di conseguenza, non può tradurle) e la cpu è in grado di leggerle e tradurle ma non è pilotata dai driver della gpu. Chi dovrebbe fare questo lavoro, come, dove, quando e perchè? (sei in un vicolo cieco e non te ne rendi conto :sofico: ).

Resta pure delle tue convinzioni, ripeto. Se è come dici, è normale che nessuno o quasi programmi più giochi in opengl, annzi mi meraviglio che esistano ancora come api :D

ps senza andare troppo lontano, tratto direttamente da wikipedia (come dire, alla portata di tutti)

Le API sono essenziali per i computer come gli standard elettrici lo sono per una casa. Chiunque può inserire la spina del tostapane nella presa a muro della sua casa o dal vicino perché entrambe le case sono conformi ad uno standard. Se non ci fosse una interfaccia standard, occorrerebbe avere una centrale elettrica per fare un toast. Niente vieta che esistano più tipi di interfacce diverse, per esempio un tostapane europeo non può funzionare negli Stati Uniti senza un trasformatore similmente ad un programma scritto per Microsoft Windows che non può essere eseguito direttamente su un sistema UNIX senza un API adapter come WINE.

e dall'home page dell'opengl board

OpenGL is the industry's most widely used, supported and best documented 2D/3D graphics API making it inexpensive & easy to obtain information on implementing OpenGL in hardware and software. There are numerous books, tutorials, online coding examples, coding seminars, and classes that document the API, Extensions, Utility Libraries, and Platform Specific Implementations.


cavolo, se non esiste uno STANDARD per quale motivo ci si sbatte a scrivere un'interfaccia STANDARD, ad aggiornarla, a stabilire quali estensioni includere in questo STANDARD, a scriverne le librerie (librerie? Se ognuno può fare come vuole?), a definire le implementazioni specifiche della piattaforma (quale piattaforma se non c'è uno standard?).

Ora se convieni sul fatto che la opengl siano un'api (e lo sono), allora ti renderai conto di aver detto una ...............ata affermando che ciascuno è libero di scrivere il suo driver come gli pare (e se non funziona è un suo problema) e che non è necessaria un'interfaccia comune STANDARD?
A perte che se un driver non funziona non è solo un problema di chi lo scrive ma di tutti quelli che hanno acquistato i suoi prodotti. Ma questo è un altro dei dettagli insignificanti che dimostri di trascurare.
SEmmai l'unica cosa che ti posso concedere, ma questo non mi pare di averlo mai negato, è questo (sempre dall'opengl board)

The OpenGL Registry contains specifications, header files, and related documentation for OpenGL and related APIs including GLU, GLX, and WGL. In addition to the core API specifications, many extensions to these APIs have been defined by vendors, groups of vendors, and the ARB. The Registry also contains specifications and header files for all registered extensions, written as modifications to the appropriate core API specifications.

The Registry also includes naming conventions, guidelines for creating new extensions and writing suitable extension specifications, and other documentation related to these APIs.


Mi pare chiaro che si possano scrivere estensioni proprietarie e che queste possano essere contenute nei driver proprietari. Ma un conto è dire che i driver contengono alcune estensioni proprietarie che si inseriscono su una piattaforma comune, STANDARDIZZATA E UGUALE PER TUTTI, di cui fa parte anche il FANTOMATICO TRADUTTORE (o compilatore o chiamalo come vuoi, ma comunque quello che si occupa di tradurre il linguaggio ad alto livello in uno comprensibile ad un chip, SENZA FARE OTTIMIZZAZIONI), un altro è dire: posso scrivere il driver come mi pare e se non funziona è un mio problema. Qui non mi risulta che ci sia scritto niente del genere

pa2 anche un adapter è, per forza di cose, un'interfaccia STANDARD.

ps3 (stavolta sta per playstation3 :D ) resta pure delle tue convinzioni. Ti saluto

[maurilio968]

Non sono ferrato in materia ma forse il mio tentativo di riassumere la questione può essere utile (lo è a me se Yoss o Skizzo mi dicono dove sbaglio). Cercate di capire che sto tentando di descrivere il flusso a grandi linee ed in modo “umano” per i non tecnici (ecco perchè faro abuso di ") . Allora vediamo:

Opengl: codice sorgente ->compilatore opengl nel driver che ottimizza per l’hardware sottostante-> codice ottimizzato -> gpu

Directx: codice sorgente->compilatore directx microsoft->compilatore nel driver che ottimizza per l’hardware sottostante->codice ottimizzato ->gpu

Ora in entrambi i casi mi sembra di capire che yoss sostiene che la parola “ottimizza” va intesa in questo senso: usa comunque uno standard (si aspetta un hardware compatibile opengl in un caso e directx nell’altro) e semmai aggiunge delle informazioni su cosa fare (diciamo per restare in tema che questo cosa fare sia “sostituisci MADD con FMA”) quando la gpu in questione (Fermi) trova istruzioni che sono standard ma che lei o non è in grado di eseguire direttamente o le conviene comunque eseguire diversamente.

Queste istruzioni aggiuntive sono viste dalla gpu solo nei suoi registri e quindi non è possibile operare QUESTE sostituzioni PRIMA che entrino nei registri.
Il compilatore non potrebbe mai farlo, perchè sarebbero sostituzioni Fuori standard.

Cioè nessun "compilatore directx 11" inserito nei driver nvidia sostituirà mai MADD con FMA vedendo che sta pilotando una fermi: semmai “dirà cavolo sto pilotando una fermi, allora guarda che quando vedrai le MADD che ho compilato io le dovrai sostituire con delle FMA."
Se lo shader testuale sorgente implicava, dopo la compilazione seguendo lo standard directx, 50 MADD allora il codice "ottimizzato" conterrà sempre 50 madd. Poi il driver dirà per ogni MADD fai una FMA e la gpu fermi processerà in step successivi solo dei pezzi di codice, quelli che riescono a entrare nei suoi registri, e ogni volta in ciascuno di quei pezzi se trova una MADD farà una FMA.

Stesso discorso vale per un "compilatore Opengl". Altrimenti Opengl non sarebbe uno standard.

Ho sbagliato?

[Walrus74]

Credo che il tutto sia dovuto a due visioni diverse della cosa:

1) In un caso si suppone che gli shader vengano "compilati, tradotti, ottimizzati" durante il caricamento del livello di gioco e poi dati in pasto alla gpu che li ha in memoria e così li ha pronti durante il "render time"...

2) Nel secondo caso si dice che gli shader vengono "compilati, tradotti, ottimizzati" durante il "render time", praticamente frame x frame...

Oramai non capisco più nemmeno io dalle varie risposte quale sia quella giusta ^^'

[persa]

cut

Oramai non capisco più nemmeno io dalle varie risposte quale sia quella giusta ^^'
io non ci ho proprio capito nulla di quello che hanno scritto in queste pagine ^^ :sofico:

[yossarian]

facio un ultimo tentativo e poi. giuro che abbndono :p


guarda che l'immagine io l'ho postata per farti capire che quel compilatore la in alto chiamato HLSL translator in GLSL NON C'E', e se c'è non viene usato,

DirectX
perfetto, quindi abbiamo scoperto che in dx le istruzini vengono tradotte da linguaggio ad alto livello a linguaggio a basso livello prima che si arrivi a livello di driver. Quindi il TRADUTTORE è standard, integrato nel s.o. e usato dalla cpu

OpenGL
qui il traduttore non c'è (riporto quello che dici) e tutto viene fatto dai driver. Perfetto. Sai com'è fatto un hard disk? O un banco di ram? Ti risulta di dover installare dei driver per farli funzionare con le opengl? Eppure hanno dei controller integrati e qualsiasi circuito elettrico, persino quello formato da due soli conduttori e una lampadina ha bisogno di dialogare parlando la stessa lingue del sistema in cui è integrato. In parole povere, se attacco due fili allo scacquone del bagno la lampadina non si accende. Quindi, anche la ram o l'HD avranno bisogno di un'interfaccia comune e avranno bisogno di ricevere istruzioni per funzionare e interfacciarsi col resto del sistema. Chi gliele dà queste istruzioni e in che modo se non c'è una parte comune STANDATD nei driver opengl che permetta a queste periferiche di interfacciarsi col resto del sistema (siamo all'ABC di architettura degli elaboratori o giù di li :D )?

DirectX

A livello inferiore, dopo la traduzione delle istruzioni, entrano in scena i driver. A te sembrava strano che compilazione (meglio traduzione) e ottimizzazioni avvenissero in due step. Dall'immagine che hai postato risulta che in D3D avviene proprio così. Strano ma vero :D
A questo punot, tu sostieni che una non ben precisata entità astratta si dovrebbe occupare di effettuare le ottimizzazioni per la gpu. Primo, chi sarebbe questa entità e perchè dovrebbe farlo? Secondo, in che modo lo farebbe? Stiamo parlando dei driver della gpu e non di quelli della cpu o di paperino. Quindi se i responsabili delle ottimizzazioni sono i driver della gpu, queste ottimizzazioni può farle solo la gpu.Come e dove? Non certo nella vram (qui bisogna che ti fidi o che ti cerchi materiale al riguardo). Nella slide parla di ottimizzazioni e, in seguito, di esecuzione del codice. Infatti è quello che succede: la gpu preleva una parte del codice (quello che entra nei registri del thread processor) lo ottimizza e lo invia alle alu per l'esecuzione. STOP. Come direbbe un noto investigatore inglese: elementare Watson :sofico:

OpenGL

siamo al punto in cui nulla è stato tradotto (quindi il sistema non è in grado doi funzionare). Entrano in gioco i driver (di tutte le periferiche coinvolte, ognuno dei quali, scritto dal proprio vendor a suo piacimento e senza la necessità di una parte comune standard). Chi si occupa della traduzione a beneficio di ciascuna periferica? In che modo lo fa? Quali criteri segue? A parte la cpu, nessun altro chip è in grado di fare lettura e traduzione del codice e nessun altro chip è in grado di lavorare direttamente con codice ad alto livello. A questo punto, o presupponiamo che ogni driver di ogni periferica faccia fare alla cpu la traduzione e le ottimizzazioni ad hoc (non vedo come il driver di una stampante o di uno scanner possa pilotare la cpu; al massimo può pilotare la stampante o lo scanner e far fare loro richiesta di accesso alle risorse di sistema, accessi gestiti, per altro, dal memory controller e non dalla cpu (tranne i casi di MC integrato nella cpu, ma sempre di MC si tratta), oppure dobbiamo rassegnarci all'idea che il sistema non potrà mai funzionare e, a questo punot, è chiaro perchè le swhouse stanno tutte migrando verso altri lidi (cosa programmo a fare in ogl se i giochi non vanno?).

L'unico modo per uscire da questa fogna è che in ogl le cose vadano esattamente coma in dx, ovvero che la cpu si occupi di tradurre il codice sorgente per tutti seguendo degli standard e lo faccia prima di ogni altra cosa e senza alcuna ottimizzazione. Il fatto che il traduttore sia all'interno dei driver o del s.o. non sposta di una virgola il senso del discorso. Un driver compatibile con le ogl 3.2 avrà il traduttore per quella versione di api (e includerà anche tutto ciò che serve per la retrocompatibilità).

Questo driver non è ne del S.O., ne di microsoft ma del produttore di schede,

e grazie al ciufolo; cosa vuoi che gliene freghi a MS di scrivere driver o compiler o translator per le opengl? :D . E neppure puoi apsettarti che sia l'opengl board (chi li dovrebbe scrivere? ATi, nVidia, AMD, SUN, SGI? Non ha importanza chi sia il produttore..........

che infatti si compila il sorgente GLSL come vuole, e se lo fa male sono ca**i suoi, l'utente e lo sviluppatore si incazzeranno e si lamentaranno con chi di dovere.
....l'importante è che lo compili secondo LO STANDARD DI RIFERIMENTO



In HLSL invece, come da schema, evidentemente c'è sto fantomatico compilatore standard che fornisce miscrosoft nel suo s.o. e che fornisce al driver lo shader già compilato.

anche il ogl c'è, per forza di cose, un traduttore standard e ti ho spiegato il perchè (fai sempre la prova della lampadine e dello sciacquone).


Ma il driver non è fatto da microsft e non è del s.o., ma è fatto da ATI/NVIDIA,
e ci mancherebbe pure; chi vuoi che glielo faccia? Ciccio di Nonna Papera?
Non solo è fatto da ATi/nVidia ma funziona anche solo con prodotti ATi/nVIdia (quindi scordati che il driver di fermi convincerà mai la cpu a fare il lavoro per lei :sofico: ).


che come risulta evidente, non prende il codice che gli arriva o lo da in pasto alla GPU e basta. Entra l'assembly source code ed esce l'executable code, poi è quest'ultimo che gira in esecuzione sulla GPU per renderizzare il nostro gioco o quant'altro. Infatti è a questo punto che c'è la freccetta verso il graphics hardware.


stai parlando di driver e compilaori come fossero entità in grado di fare qualcosa materialmente. Un driver non prende un bel niente. Se metto un driver sul tavolo del salotto non va da nessuna parte e se lo metto nel forno a microonde o in frigorifero non ci ricavo nulla di commestibile. Un driver non è altro che righe di codice che hanno bisogno di un chip per poter girare e questo chip può essere solo la gpu (se il driver è della gpu). Quindi dire il driver prende, il driver ottimizza, il driver compila, il driver sostituisce equivale a dire le pere sono le mele, oppure oggi è una bella giornata, infatti ho i calzini rossi; si tratta di frasi senza senso. Il driver istruisce la gpu su ciò che deve fare ma poichè la gpu non è in grado di tradurre codice ad alto livello, il driver deve contenere un traduttore standard che la cpu riconosca come tale e che sia uguale per tutte la periferiche compatibili con quell'API, in modo che la cpu esegua la traduzione. Poi, ma solo in un secondo momento, la parte del driver che contiene le ottimizzazioni (che è la parte custom non standard della quale la cpu se ne sbatte,) può dire alla gpu cosa fare. La gpu agisce di conseguenza tenenod conto delle sue limitazioni già esposte. Quindi il codice viene ottimizzato solo dentro la gpu anche in opengl.



Ora non potrebbe e dico potrebbe essere che questa sostituzione avvenga qui, PRIMA che lo shader passi effettivamente all'esecuzione sul graphics hardware? non mi sembra un concetto così strampalato, visto che questa parte di codice sarà diversa a seconda del driver e quindi una per ogni scheda video.
Non mi pare un concetto così difficile da comprendere.

no, è un concetto privo di qualunque valenza e del tutto incomprensibile per quanto detto prima.


sinceramente non so da dove prendi la convinzione che i compilatori all'interno del driver non possano che compilare in modo "fisso". la citazione dal superbible evidenzia proprio che il driver, almeno per quanto riguarda OPENGL, non fa una traduzione fissa. E' solo questo il nodo del contendere.
Se vuoi te la incollo di nuovo:

da tutto quanot riportato sopra


"Unlike some other shading language APIs out there, GLSL is designed to accept shader text rather than precompiled binaries.
qui il riferimento è esplicito alle vecchie versioni di opengl (le dx sono arrivate al linguaggio ad alto livello ben prima)


This makes it possible for the application to provide a single universal shader regardless of the underlying OpenGL implementation.

possibile anche in DX; l'importante è scrivere in modo tale che ciò che scrivi sia comprensibile a tutti; il che significa usare un linguaggio comune con delle regole STANDARD.


The OpenGL device driver can then proceed to compile and optimize for the underlying hardware.

peccato che qui non ti dica che i due step non sono simultanei ma successivi. La traduzione deve avvenire per forza prima e deve essere compatibile con il linguaggio comune delle altre periferiche (qualcuno ha detto STANDARD?)


Another benefit is that the driver can be updated with improved optimization methods, making shaders run faster over time, without any burden on application vendors to patch their applications." Superbible pag 528

vale anche per le DX (bugfix o ottimizzazioni per migliorare prestazioni e compatibilità sono all'ordine del mese se non della settimana)

Dove sarebbe la differenza?

[Severnaya]

ma nn vi potete drogare come tutti gli altri?!


:asd:

[maurilio968]

Quindi io avevo capito bene. Grazie Yossarian.

[maurilio968]

ma nn vi potete drogare come tutti gli altri?!


:asd:

Facciamo anche quello :D

[Severnaya]

nice :asd:

[yossarian]

Non sono ferrato in materia ma forse il mio tentativo di riassumere la questione può essere utile (lo è a me se Yoss o Skizzo mi dicono dove sbaglio). Cercate di capire che sto tentando di descrivere il flusso a grandi linee ed in modo “umano” per i non tecnici (ecco perchè faro abuso di ") . Allora vediamo:

Opengl: codice sorgente ->compilatore opengl nel driver che ottimizza per l’hardware sottostante-> codice ottimizzato -> gpu

Directx: codice sorgente->compilatore directx microsoft->compilatore nel driver che ottimizza per l’hardware sottostante->codice ottimizzato ->gpu

Ora in entrambi i casi mi sembra di capire che yoss sostiene che la parola “ottimizza” va intesa in questo senso: usa comunque uno standard (si aspetta un hardware compatibile opengl in un caso e directx nell’altro) e semmai aggiunge delle informazioni su cosa fare (diciamo per restare in tema che questo cosa fare sia “sostituisci MADD con FMA”) quando la gpu in questione (Fermi) trova istruzioni che sono standard ma che lei o non è in grado di eseguire direttamente o le conviene comunque eseguire diversamente.

Queste istruzioni aggiuntive sono viste dalla gpu solo nei suoi registri e quindi non è possibile operare QUESTE sostituzioni PRIMA che entrino nei registri.
Il compilatore non potrebbe mai farlo, perchè sarebbero sostituzioni Fuori standard.

Cioè nessun "compilatore directx 11" inserito nei driver nvidia sostituirà mai MADD con FMA vedendo che sta pilotando una fermi: semmai “dirà cavolo sto pilotando una fermi, allora guarda che quando vedrai le MADD che ho compilato io le dovrai sostituire con delle FMA."
Se lo shader testuale sorgente implicava, dopo la compilazione seguendo lo standard directx, 50 MADD allora il codice "ottimizzato" conterrà sempre 50 madd. Poi il driver dirà per ogni MADD fai una FMA e la gpu fermi processerà in step successivi solo dei pezzi di codice, quelli che riescono a entrare nei suoi registri, e ogni volta in ciascuno di quei pezzi se trova una MADD farà una FMA.

Stesso discorso vale per un "compilatore Opengl". Altrimenti Opengl non sarebbe uno standard.

Ho sbagliato?

sostituisci, più correttamente, compilatore con traduttore, ma il senso è quello. Anche in opengl deve esistere per forza un traduttore standard (immagina se in una conferenza ognuno traducesse nella propria lingua ciò che vuole; ci si riuscirebbe a capire?). Per il resto hai capito perfettamente. Anzi aggiungo che, a parte la soggettivizzazione del compilatore o del driver che vengono ammantati di poteri "taumaturgici", ma sono semplici righe di codice che hanno bisogno di un chip su cui girare, ma neppure la stessa cpu, quando si occupa della traduzione, sa che sta traducendo anche per fermi (ci si dimentica sempre di tutte le altre periferiche del pc ma si focalizza l'attenzione solo sulla scheda video; vi vorrei vedere a giocare senza audio o con ram o HD che non funzionano :D ). E anche se lo venisse a sapere, non glie ne potrebbe fregare di meno.

In merito ai "poteri" dei driver, invito chiunque a scrivere un'istruzione per vostro fratello minore (trasferito in australia) del tipo; vai a prendere il latte per la colazione.L'istruzione è esplicitamente per vostro fratello in australia, non per vostra sorella che vive con voi.
Mettete l'istruzione sulla scrivania e ogni giorno aprite il frigo cercando il latte.
Un driver per una periferica è l'equivalente di quell'istruzione; se non ha un destinatario, un chip su cui girare, non serve ad un bel niente; e quel chip deve per forza essere il destinatario dell'istruzione. :p

Credo che il tutto sia dovuto a due visioni diverse della cosa:

1) In un caso si suppone che gli shader vengano "compilati, tradotti, ottimizzati" durante il caricamento del livello di gioco e poi dati in pasto alla gpu che li ha in memoria e così li ha pronti durante il "render time"...

2) Nel secondo caso si dice che gli shader vengono "compilati, tradotti, ottimizzati" durante il "render time", praticamente frame x frame...

Oramai non capisco più nemmeno io dalle varie risposte quale sia quella giusta ^^'

Gli shader vengono tradotti dalla cpu e inviati alla vram. Da qui caricati nella gpu e ottimizzati in runtime una porzione di codice dopo l'altra e ogni volta che si incontra una madd la si sostituisce con una fma.

[Bastoner]

ma nn vi potete drogare come tutti gli altri?!


:asd:

:asd:
Geniale

[Iantikas]

http://www.nvidia.com/object/product_geforce_310_us.html


è uscita ufficialmemte la prima gpu nvidia della serie GT3xx :D ...


...la NUOVISSIMA Geforce GT310...e come dice nvidia "Every PC needs good graphics" :sofico: anke se in realtà quest'lutimo ritrovato della tecnologia di cui ha bisogno ogni pc nn'è altro ke una Geforce 210, identica in tutto e x tutto tranne ke x il nome ke magicamente l'ha fatta divenire una gpu di nuova generazione :sofico: ...


...cmq skerzi a parte ora sta davvero inziando ad esagerare col gioketto del rebranding...



...ciao

[Kharonte85]

E' old, ne abbiamo parlato prima: http://www.hwupgrade.it/forum/showpost.php?p=29839392&postcount=9021

[zorco]

http://www.nvidia.com/object/product_geforce_310_us.html


è uscita ufficialmemte la prima gpu nvidia della serie GT3xx :D ...


...la NUOVISSIMA Geforce GT310...e come dice nvidia "Every PC needs good graphics" :sofico: anke se in realtà quest'lutimo ritrovato della tecnologia di cui ha bisogno ogni pc nn'è altro ke una Geforce 210, identica in tutto e x tutto tranne ke x il nome ke magicamente l'ha fatta divenire una gpu di nuova generazione :sofico: ...


...cmq skerzi a parte ora sta davvero inziando ad esagerare col gioketto del rebranding...



...ciao
sei old già postato:O :D :Prrr:

[maurilio968]

http://www.nvidia.com/object/product_geforce_310_us.html

è uscita ufficialmemte la prima gpu nvidia della serie GT3xx :D ...

...la NUOVISSIMA Geforce GT310

...ciao

Bene, chiudiamo questo thread; ormai "aspettando gt3xx" non ha più senso.
Trasferiamoci tutti su un nuovo thread ufficiale gtx310...anzi no, restiamo tutti "fermi". :D

[skizzo99999999]

Mi riprometto di smettere ma stavolta è l’ultima. Ecco 3 pagine, estratte sempre dall’orange book. La parte migliore arriva nella sezione 2.5.2, anche se mi sa che senza leggere la parte precedente non ci capirete molto

http://img69.imageshack.us/img69/5382/45128354.jpg
http://img682.imageshack.us/img682/8844/68152471.jpg
http://img69.imageshack.us/img69/7862/70376117.jpg

avete digerito queste paginette? Bene… visto che le glcompile e soci le si chiamano una volta sola durante il caricamento dell’applicazione, ed è spiegato chiaramente che il compilatore non tira fuori niente di standard, come è possibie che la GPU faccia le “sostituzioni” al volo ad ogni esecuzione dei vari shader?

Voglio sottolineare:
“It is assumed that the back end of the OpenGL Shading Language compiler will be implemented differently on different platforms. Each implementation must take the high-level representation produced by the publicly available front end and produce optimized machine code for a particular hardware target. This is an area in which individual hardware vendors can add value to their shading language implementation by figuring out ways to map the high-level representation onto the actual machine instructions found in their hardware. Likewise, the linking stage is also highly hardware dependent because it involves operations like assigning variables to actual memory locations in the hardware. A variety of global optimizations may also be performed as part of linking”

Ed il linking lo si fa una volta sola.
Se non risulta chiaro adesso secondo me ci sono solo 2 possibilità:
- o non avete letto le pagine
- o non le avete capite
non ce niente di male in nessuno dei due casi, basta rendersene conto. Uno non può capire/sapere tutto. Questo vale anche per me naturalmente, potrei avere anche frainteso tutto quello che ho letto e imparato, ed infatti visto che continuo a sentirmi dire che sto dicendo una marea di str*****e, il dubbio mi è venuto… ma rileggendo queste pagine, davvero non capisco cosa ci sia da interpretare… volevo dire compilare…

perdonate la terribile battuta

[Iantikas]

E' old, ne abbiamo parlato prima: http://www.hwupgrade.it/forum/showpost.php?p=29839392&postcount=9021

sei old già postato:O :D :Prrr:

http://img80.imageshack.us/img80/5379/antiold.gif (http://img80.imageshack.us/i/antiold.gif/)


madò son quasi commosso...era da na vita ke volevo postare sta gif ma nn m'era mai capitata l'occasione...finalmente ce l'ho fatta :winner: :D

[skizzo99999999]

mi è venuto in mente che forse c'è una soluzione per dimostrare che gli shader vengono compilati diversamente. Chi ha una ati provi ad andare sul sito:
http://developer.amd.com/gpu/shader/Pages/default.aspx

E' un programma che ho usate un paio di anni fa, non so se ora sia cambiato molto. Aveva 2 sezioni: nella parte sinistra gli mettevi lo shader, nela parte destra ti veniva fuori il codice con le mul, mad, ecc...
In alto a destra si poteva cambiare la scheda di target, in modo da vedere le differenze che venivano fuori a livello di mul, mad, ecc.. cambiando scheda. Non mi ricordo se usare il driver attuale o se c'era una specie di database nel quale sceglievi pure la release del driver.
E' facile verificare di persona che, almeno scegliendo le OPENGL (ovviamente con le directx non ho mai provato), il codice di destra cambia cambiando la scheda target.

[eXeS]

Mi riprometto di smettere ma stavolta è l’ultima. Ecco 3 pagine, estratte sempre dall’orange book. La parte migliore arriva nella sezione 2.5.2, anche se mi sa che senza leggere la parte precedente non ci capirete molto

http://img69.imageshack.us/img69/5382/45128354.jpg
http://img682.imageshack.us/img682/8844/68152471.jpg
http://img69.imageshack.us/img69/7862/70376117.jpg

avete digerito queste paginette? Bene… visto che le glcompile e soci le si chiamano una volta sola durante il caricamento dell’applicazione, ed è spiegato chiaramente che il compilatore non tira fuori niente di standard, come è possibie che la GPU faccia le “sostituzioni” al volo ad ogni esecuzione dei vari shader?

Voglio sottolineare:
“It is assumed that the back end of the OpenGL Shading Language compiler will be implemented differently on different platforms. Each implementation must take the high-level representation produced by the publicly available front end and produce optimized machine code for a particular hardware target. This is an area in which individual hardware vendors can add value to their shading language implementation by figuring out ways to map the high-level representation onto the actual machine instructions found in their hardware. Likewise, the linking stage is also highly hardware dependent because it involves operations like assigning variables to actual memory locations in the hardware. A variety of global optimizations may also be performed as part of linking”

Ed il linking lo si fa una volta sola.
Se non risulta chiaro adesso secondo me ci sono solo 2 possibilità:
- o non avete letto le pagine
- o non le avete capite
non ce niente di male in nessuno dei due casi, basta rendersene conto. Uno non può capire/sapere tutto. Questo vale anche per me naturalmente, potrei avere anche frainteso tutto quello che ho letto e imparato, ed infatti visto che continuo a sentirmi dire che sto dicendo una marea di str*****e, il dubbio mi è venuto… ma rileggendo queste pagine, davvero non capisco cosa ci sia da interpretare… volevo dire compilare…

perdonate la terribile battuta

E tutta questa magia chi la fa, il driver, che non è codice scritto in linguaggio binario riconosciuto dalla gpu, ma è codice x86 o x64 eseguito dalla cpu che fra le altre cose, fa delle chiamate dirette al dispositivo grafico.

Un tutorial su come sviluppare un driver elementare e che stampa hello word
http://www.rohitab.com/discuss/index.php?showtopic=24166

Il driver a differenza di un'applicazione standard ha l'entry point che si chiama DriverEntry, un'applicazione in finestra WinMain, e una DLL DllMain

Il processo di creazione del .sys (che contiene codice binario) passa attraverso

-Compilazione
-Linking

esattamente come il processo di creazione del binario di un exe o dll.

Aggiungo inoltre, ma se il driver non contenesse codice eseguibile dalla CPU, come cavolo farebbe in funzione del nome dell'exe ad applicare ottimizzazioni specifiche, attivare sli e crossfire, forzare l'uso dell'AA e quant'altro, chi è che fa il test sul nome dell'eseguibile, la GPU ? :D

[Giullo]

caspita era da tempo che non si leggevano cose del genere sul forum di hwupgrade .... sentiti ringraziamenti a yoss e skizzo per l'interessante lettura :)

[Andrea deluxe]

caspita era da tempo che non si leggevano cose del genere sul forum di hwupgrade .... sentiti ringraziamenti a yoss e skizzo per l'interessante lettura :)

quoto!:D

[marco XP2400+]

caspita era da tempo che non si leggevano cose del genere sul forum di hwupgrade .... sentiti ringraziamenti a yoss e skizzo per l'interessante lettura :)
quoto

[DVD2005]

quoto!:D

anche io :D sebbene non ci capisca una mazza :p

[The_SaN]

http://img80.imageshack.us/img80/5379/antiold.gif (http://img80.imageshack.us/i/antiold.gif/)


madò son quasi commosso...era da na vita ke volevo postare sta gif ma nn m'era mai capitata l'occasione...finalmente ce l'ho fatta :winner: :DHahaha bellissima :D

[yossarian]

Mi riprometto di smettere ma stavolta è l’ultima. Ecco 3 pagine, estratte sempre dall’orange book. La parte migliore arriva nella sezione 2.5.2, anche se mi sa che senza leggere la parte precedente non ci capirete molto

http://img69.imageshack.us/img69/5382/45128354.jpg
http://img682.imageshack.us/img682/8844/68152471.jpg
http://img69.imageshack.us/img69/7862/70376117.jpg

avete digerito queste paginette? Bene… visto che le glcompile e soci le si chiamano una volta sola durante il caricamento dell’applicazione, ed è spiegato chiaramente che il compilatore non tira fuori niente di standard, come è possibie che la GPU faccia le “sostituzioni” al volo ad ogni esecuzione dei vari shader?

Voglio sottolineare:
“It is assumed that the back end of the OpenGL Shading Language compiler will be implemented differently on different platforms. Each implementation must take the high-level representation produced by the publicly available front end and produce optimized machine code for a particular hardware target. This is an area in which individual hardware vendors can add value to their shading language implementation by figuring out ways to map the high-level representation onto the actual machine instructions found in their hardware. Likewise, the linking stage is also highly hardware dependent because it involves operations like assigning variables to actual memory locations in the hardware. A variety of global optimizations may also be performed as part of linking”

Ed il linking lo si fa una volta sola.
Se non risulta chiaro adesso secondo me ci sono solo 2 possibilità:
- o non avete letto le pagine
- o non le avete capite
non ce niente di male in nessuno dei due casi, basta rendersene conto. Uno non può capire/sapere tutto. Questo vale anche per me naturalmente, potrei avere anche frainteso tutto quello che ho letto e imparato, ed infatti visto che continuo a sentirmi dire che sto dicendo una marea di str*****e, il dubbio mi è venuto… ma rileggendo queste pagine, davvero non capisco cosa ci sia da interpretare… volevo dire compilare…

perdonate la terribile battuta

io, invece sottolineerei questa

the net resukt of this assumption is that graphics hardware vendors will implement the majority of the OGSL compiler and linker. Along with the OGL drivers itself, this software will tipically be included as part of the graphics driver installation package that is provided by a graphics hardware vendor

Devo tradurla?

Oppure risulta chiaro che c'è una parte di codice STANDARD che viene incluso nei driver e che comprende il compiler e il linker, che serve da interfaccia con l'applicazione, che si occupa di fare la traduzione e che è scritto, come dice bene eXeS, in un codice che giri sulla cpu di turno? Hai presente l'architettura di un pc? Hai idea di chi si occupi di assegnare i compiti alle varie periferiche, di inizializzare (ho detto inizializzare, non avviare) le richieste di accesso alle memoria e, contestualmente, di fornire gli indirizzi delle locazioni di memoria dove reperire i dati per eseguire le istruzioni?
E dall'immagine che hai postato (il primo dei 3 link) non risulta altrettanto chiaro che l'operazione di linking avviene dopo la compilazione (hai presente un diagramma ad albero?) e non in simultanea?

Non ti dice niente tutto ciò?
Torno a riformulare le solite domande ammesso che sia come dici in opengl (in directx abbiamo appurato che è come sostengo io), mi spieghi:
1) chi si occupa della traduzione (o compilazione) dell'applicazione
2) a che stadio avviene la compilazione
3) dove avviene la compilazione
4) da cosa è controllata, diretta, guidata, la compilazione
5) che tipo di codice arriva al chip grafico?
6) quando avverrebbero queste ottimizzazioni?
7) chi se ne occuperebbe?
8) dove sarbbero fatte?
9) da chi sarebbero controllate, dirette e guidate?
10) a che pro, in che modo e per quale motivo quacun altro dovrebbe fare tutto ciò al posto della gpu o, se preferisci, in che modo la gpu può procedere a elaborare il codice?

Visto che vanno di moda le 10 domande mi adeguo al trend :sofico:

mi è venuto in mente che forse c'è una soluzione per dimostrare che gli shader vengono compilati diversamente. Chi ha una ati provi ad andare sul sito:
http://developer.amd.com/gpu/shader/Pages/default.aspx

E' un programma che ho usate un paio di anni fa, non so se ora sia cambiato molto. Aveva 2 sezioni: nella parte sinistra gli mettevi lo shader, nela parte destra ti veniva fuori il codice con le mul, mad, ecc...
In alto a destra si poteva cambiare la scheda di target, in modo da vedere le differenze che venivano fuori a livello di mul, mad, ecc.. cambiando scheda. Non mi ricordo se usare il driver attuale o se c'era una specie di database nel quale sceglievi pure la release del driver.
E' facile verificare di persona che, almeno scegliendo le OPENGL (ovviamente con le directx non ho mai provato), il codice di destra cambia cambiando la scheda target.

uno shader analyzer? e cosa dovrebbe dimostrare? Ovvio che da una gpu all'altra cambiano le cose. Pensa che ci sono gpu che non hanno SFU, oppure che lavorano e fp32 solo con i vertex shader e ci sono gpu che hanno shader unificati e latre che li hanno dedicati. Qualcuna ha le funzioni di tessellation altre no, ma anche chi ce le ha presenta differenti implementazioni; le più recenti calcolano anche i geometry shader e le ultima fanno persino le fma (prova con una chiamata di tipo fma su un g80 o su un RV670 o un RV770 :D ). Inoltre ci sono gpu che non "sanno" neppure cosa sia un vertex o un pixel shader e altre che non fanno neppure T&L. Addirittura ci sono stati chip grafici che non facevano neppure multitexturing. Strano vero?
Questo proverebbe che hai ragione?
Ok, hai ragione :sofico:

E tutta questa magia chi la fa, il driver, che non è codice scritto in linguaggio binario riconosciuto dalla gpu, ma è codice x86 o x64 eseguito dalla cpu che fra le altre cose, fa delle chiamate dirette al dispositivo grafico.

Un tutorial su come sviluppare un driver elementare e che stampa hello word
http://www.rohitab.com/discuss/index.php?showtopic=24166

Il driver a differenza di un'applicazione standard ha l'entry point che si chiama DriverEntry, un'applicazione in finestra WinMain, e una DLL DllMain

Il processo di creazione del .sys (che contiene codice binario) passa attraverso

-Compilazione
-Linking

esattamente come il processo di creazione del binario di un exe o dll.

Aggiungo inoltre, ma se il driver non contenesse codice eseguibile dalla CPU, come cavolo farebbe in funzione del nome dell'exe ad applicare ottimizzazioni specifiche, attivare sli e crossfire, forzare l'uso dell'AA e quant'altro, chi è che fa il test sul nome dell'eseguibile, la GPU ? :D

lascia stare, è una causa persa. Inutile pensare di convincere qualcuno che si è barricato dietro a driver miracolosi (che si occupano di fare tutto da soli e in maniera del tutto autonoma), che confonde il compiler standard di un'api e quelli custom dei vari vendor, e che ritiene che un driver o un compiler si scriva e si comporti come una normale istruzione di una qualsivoglia applicazione.
In effetti, a ben pensarci, di cosa si cruccia nVidia per la mancanza delle licenze x86, data la loro perfetta inutilità? Basta scrivere driver ottimizzati per fermi o, in generale, per le sue gpu, tanto fanno tutto loro.
Ma........aspetta...............No, non è possibile!!!!!!!!!!!!!!!!!!!! Dal supporto ufficiale di nVdia al GLSL leggo testualmente, riferendosi, in particolare a tre estensioni proprietarie
The opengl 2.0 specifications incorporated a version of these extensions into the core opengl STANDARD. ...........................STANDARD? Ma non si era detto che ognuno poteva scrivere quello che voleva e ottimizzare come gli pareva tanto ci pensavano i driver? E 'sto STANDARD da dove salta fuori e, soprattutto, a cosa serve? E poi, solo tre estensioni proprietarie integrate all'interno del core opengl standard? Ma se è standard, allora è uguale per tutti? E lo standard comprende anche il compiler e il linker? :D

[luX0r.reload]

... per fortuna in questi giorno sono strapieno di lavoro e non riesco ad entrare nel forum se non a quest'ora, altrimenti mi sarei già dato una pistolettata in testa. Ah sorry... è stato già fatto :D
Se ve ne avanza una... io sono OLD, io sono OLD:sofico: :Prrr:

[maurilio968]

Visto che vanno di moda le 10 domande mi adeguo al trend



:sofico:

Se il trend è quello che dico io per le risposte dovrai aspettare la puntata di porta a porta. :D

PSP (nel senso di "potevo scriverlo prima" non di playstation portable) : voto questa discussione come topic del mese!

[luX0r.reload]

:sofico:

Se il trend è quello che dico io per le risposte dovrai aspettare la puntata di porta a porta. :D

:asd:

[maurilio968]

Per saperne di più su MADD ed FMA yossarian ne parla

QUI -> elementi funzionali di una gpu. le alu (http://www.appuntidigitali.it/5025/elementi-funzionali-di-una-gpu-le-alu/)

[eXeS]

io, invece sottolineerei questa

the net resukt of this assumption is that graphics hardware vendors will implement the majority of the OGSL compiler and linker. Along with the OGL drivers itself, this software will tipically be included as part of the graphics driver installation package that is provided by a graphics hardware vendor

Devo tradurla?

Oppure risulta chiaro che c'è una parte di codice STANDARD che viene incluso nei driver e che comprende il compiler e il linker, che serve da interfaccia con l'applicazione, che si occupa di fare la traduzione e che è scritto, come dice bene eXeS, in un codice che giri sulla cpu di turno? Hai presente l'architettura di un pc? Hai idea di chi si occupi di assegnare i compiti alle varie periferiche, di inizializzare (ho detto inizializzare, non avviare) le richieste di accesso alle memoria e, contestualmente, di fornire gli indirizzi delle locazioni di memoria dove reperire i dati per eseguire le istruzioni?
E dall'immagine che hai postato (il primo dei 3 link) non risulta altrettanto chiaro che l'operazione di linking avviene dopo la compilazione (hai presente un diagramma ad albero?) e non in simultanea?

Non ti dice niente tutto ciò?
Torno a riformulare le solite domande ammesso che sia come dici in opengl (in directx abbiamo appurato che è come sostengo io), mi spieghi:
1) chi si occupa della traduzione (o compilazione) dell'applicazione
2) a che stadio avviene la compilazione
3) dove avviene la compilazione
4) da cosa è controllata, diretta, guidata, la compilazione
5) che tipo di codice arriva al chip grafico?
6) quando avverrebbero queste ottimizzazioni?
7) chi se ne occuperebbe?
8) dove sarbbero fatte?
9) da chi sarebbero controllate, dirette e guidate?
10) a che pro, in che modo e per quale motivo quacun altro dovrebbe fare tutto ciò al posto della gpu o, se preferisci, in che modo la gpu può procedere a elaborare il codice?

Visto che vanno di moda le 10 domande mi adeguo al trend :sofico:



uno shader analyzer? e cosa dovrebbe dimostrare? Ovvio che da una gpu all'altra cambiano le cose. Pensa che ci sono gpu che non hanno SFU, oppure che lavorano e fp32 solo con i vertex shader e ci sono gpu che hanno shader unificati e latre che li hanno dedicati. Qualcuna ha le funzioni di tessellation altre no, ma anche chi ce le ha presenta differenti implementazioni; le più recenti calcolano anche i geometry shader e le ultima fanno persino le fma (prova con una chiamata di tipo fma su un g80 o su un RV670 o un RV770 :D ). Inoltre ci sono gpu che non "sanno" neppure cosa sia un vertex o un pixel shader e altre che non fanno neppure T&L. Addirittura ci sono stati chip grafici che non facevano neppure multitexturing. Strano vero?
Questo proverebbe che hai ragione?
Ok, hai ragione :sofico:



lascia stare, è una causa persa. Inutile pensare di convincere qualcuno che si è barricato dietro a driver miracolosi (che si occupano di fare tutto da soli e in maniera del tutto autonoma), che confonde il compiler standard di un'api e quelli custom dei vari vendor, e che ritiene che un driver o un compiler si scriva e si comporti come una normale istruzione di una qualsivoglia applicazione.
In effetti, a ben pensarci, di cosa si cruccia nVidia per la mancanza delle licenze x86, data la loro perfetta inutilità? Basta scrivere driver ottimizzati per fermi o, in generale, per le sue gpu, tanto fanno tutto loro.
Ma........aspetta...............No, non è possibile!!!!!!!!!!!!!!!!!!!! Dal supporto ufficiale di nVdia al GLSL leggo testualmente, riferendosi, in particolare a tre estensioni proprietarie
The opengl 2.0 specifications incorporated a version of these extensions into the core opengl STANDARD. ...........................STANDARD? Ma non si era detto che ognuno poteva scrivere quello che voleva e ottimizzare come gli pareva tanto ci pensavano i driver? E 'sto STANDARD da dove salta fuori e, soprattutto, a cosa serve? E poi, solo tre estensioni proprietarie integrate all'interno del core opengl standard? Ma se è standard, allora è uguale per tutti? E lo standard comprende anche il compiler e il linker? :D
Mi sa che hai frainteso, poichè come detto nel mio predente post i driver, che in modo molto semplicistico possiamo chiamare file con estensione .sys contengono codice binario eseguito dalla cpu, e chiamate dirette all'hardware grafico, i driver potranno contenere il codice, ribadisco eseguito dalla cpu, delegato alla manipolazione del codice shader, rimpiazzanando le MADD con le FMA, prima che quest'ultimo venga inoltrato alla gpu.

[skizzo99999999]

ho sperato inutilmente, ma pazienza. Ho sempre detto che il compilatore GLSL era all'interno del driver e dici bene, "che comprende il compiler e il linker, che serve da interfaccia con l'applicazione, che si occupa di fare la traduzione e che è scritto, come dice bene eXeS, in un codice che giri sulla cpu". Quello che è standard è il codice GLSL, non il codice compilato che esce dal compilatore del driver, questo sarà diverso per ogni scheda video. Dal diagramma della prima imamgine si vede bene che al driver arriva il source dello shader (che è testo) ed esce l'executable code che POI viene eseguito dalla GPU. La frase:

"the net resukt of this assumption is that graphics hardware vendors will implement the majority of the OGSL compiler and linker. Along with the OGL drivers itself, this software will tipically be included as part of the graphics driver installation package that is provided by a graphics hardware vendor"

dice che il compilatore è fornito dal produttore della scheda attraverso il driver che ognuno si scarica da internet. Mi sembra di continuare a dire questo da una vita... è proprio per questo che ogni scheda si ritrova il suo compilatore che riceve un source GLSL STANDARD e sputa un codice diverso per ogni scheda che si trova sotto.

veniamo alle domande
1) l'applicazione vera e propria (e quindi non gli shader ma il gioco/programma) viene compilata dalla software house. Se vado a comprare l'ultimo call of duty non compilo niente, clicco su exe (dopo averlo installato e gioco)
2-3-4) se intendi sempre dell'applicazione, la risposta è uguale a quella precedente, se invece intendi il GLSL come ti ho già detto sopra e come scritto nelle 3 pagine linkate, la fa il compilatore del driver.
5) il codice uscito da tutta la sequenza di operazioni di compile, link, ecc...
6-7-8-9) ancora? come da risposta 2-3-4
10) la GPU esegue il codice tradotto in executable code, mica processa direttamente il source code (è quello, lo ripeto che è standard). E' fatta per quello: se non riesce neanche ad eseguire il codice compilato per lei... Poi è ovvio che a livello di compilazione non si potrà ottimizzare tutto quello che si vorrebbe, infatti alcune cose non si possono fare a compile time; è solo durante l'esecuzione che si fa la branch prediction e similari. Sennò, facendo una similitudine con le CPU, non servirebbe a niente tutto il silicio nelle moderne CPU che esaminano al volo il codice e fanno esecuzioni out of order ecc... qua si stava parlando di utilizzare una unità funzionale con un'altra che fa la stessa cosa con una precisione migliore. Per usare un esempio che ho già fatto, se un domani venisse inserito un nuovo elemento che fa un madd + divisione (per gli operandi bisognerebbe pensarci bene...), il compilatore nel driver, che è scritto per questa nuova GPU, mentre compila il source del GLSL se vede che la può utilizzare la utilizza. Lo stesso shader GLSL se viene utilizzato dalla stessa applicazione che gira però su una scheda video "tradizionale" senza quel particolare elemento funzionale, allora semplicemente verrà tradotta in una Madd seguita da una divisione e non con una MADDDIV (sto inventando...).

Quando tu dici:

Dal supporto ufficiale di nVdia al GLSL leggo testualmente, riferendosi, in particolare a tre estensioni proprietarie
The opengl 2.0 specifications incorporated a version of these extensions into the core opengl STANDARD. ...........................STANDARD? Ma non si era detto che ognuno poteva scrivere quello che voleva e ottimizzare come gli pareva tanto ci pensavano i driver? E 'sto STANDARD da dove salta fuori e, soprattutto, a cosa serve? E poi, solo tre estensioni proprietarie integrate all'interno del core opengl standard? Ma se è standard, allora è uguale per tutti? E lo standard comprende anche il compiler e il linker? :D


Ognuno chi? lo sviluppatore? lo sviluppatore mica scrive in codice macchina, scrive in C/C++ o quant'altro l'applicazione (che contiene anche le chiamate OPENGL) i gli shader GLSL li scrive in un file tipo txt usando il linguaggio standard GLSL. Siccome le versioni di opengl evolvono (ora siamo oltre la 3), anche il GLSL evolve, si possono man mano fare sempre nuove cose; quindi nuove estensioni, che prima erano approvate dall'ARB verranno mano a mano promosse a core function, cioè chiunque implementi una architettura compatibile OPENGL x.x dovrà incorporarle tutte. Poi ci sono sempre nuove estensioni al di fuori delle core function (come è ovvio), e li uno sviluppatore se le implementa sa che gireranno solo su architetture che supportano quella particolare estensione.
Non vedo che centra questo con quello di cui stavamo parlando.

Comunque non ho detto che in directx funziona come dici te, ho solo detto che non conoscendo, è possibile che sia così, anche se non mi sembra un approccio ragionevole, visto anche l'altro stralcio dell'orangebook che ho già postato, in cui c'era il diagramma delle Directx e anche li c'era un ulteriore passo nel driver. Ma li il libro non va in profondità perche non è un libro sulle directx

x eXeS: forse ho trovato un "alleato", venghino signori venghino...

[skizzo99999999]

:sofico:

Se il trend è quello che dico io per le risposte dovrai aspettare la puntata di porta a porta. :D

PSP (nel senso di "potevo scriverlo prima" non di playstation portable) : voto questa discussione come topic del mese!

Se mi stai paragonando al personaggio che penso, sappi che per me è una offesa gravissima, la peggiore... :stordita:

[molochgrifone]

ma nn vi potete drogare come tutti gli altri?!


:asd:

Parole sante :O

caspita era da tempo che non si leggevano cose del genere sul forum di hwupgrade .... sentiti ringraziamenti a yoss e skizzo per l'interessante lettura :)

anche io :D sebbene non ci capisca una mazza :p

Come dice il buon Davide quoto sulla fiducia, perché mi sono perso dopo 5 minuti, ma direi che si coglie che la vostra preparazione è ottima, anche se avete idee divergenti :mano:

[martinez1983]

ma nn vi potete drogare come tutti gli altri?!


:asd:

Questo è il post dell' anno!!!:D :D



Cmq ragazzi perfavore aprite un thread apposito...ormai ho l' instinto di suicidarmi!!!:D
Trattate argomenti estremamenti interessanti ma siete molto OT!!!;)

Cmq per ricapitolare...forse si vedrà qualcosa per gennaio??(nelle migliori delle ipotesi)

[eXeS]

x eXeS: forse ho trovato un "alleato", venghino signori venghino...
Non mi sembra che tu abbia bisogno di alleati :) , ho dato solo un piccolo contributo per avallare la tesi da te inizialmente ipotizzata e non condivisa da yossarian, secondo la quale il codice del driver può tranquillamente fare il replace della mad prima che lo shader venga inviato alla gpu, con hit prestazionale che si manifesta solo nel momento dell'invio dello shader alla gpu, e non ogni volta che le istruzioni ivi contenute vengono processate dalla gpu.

Se ancora ci fossero dei dubbi sull'affermazione secondo la quale il driver contiene codice eseguibile dalla cpu, basta dissassemblare qualunque .sys, per notare che il disassemblato contiene istruzioni assembler x86 ;)

http://www.pctunerup.com/up/results/_200911/th_20091126224744_nuovo-1.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091126224744_nuovo-1.jpg)

[maurilio968]

Se mi stai paragonando al personaggio che penso, sappi che per me è una offesa gravissima, la peggiore... :stordita:

Allora scusa, stavo solo scherzando. ;)

Enrando nel merito delle tue risposte: mi hai fatto venire nuovamente qualche dubbio.
Attendo la replica di yossarian.

[skizzo99999999]

Allora scusa, stavo solo scherzando. ;)

Enrando nel merito delle tue risposte: mi hai fatto venire nuovamente qualche dubbio.
Attendo la replica di yossarian.

ovviamente avevo capito che era una battuta, ho solo replicato in tono scherzoso per abbassare un po i toni (noni tuoi ovviamente, della discussione in generale)

[ally]

...piu' fermi (http://www.theinquirer.net/inquirer/news/1563765/nvidia-rebrands) di così si muore...

...ciao Andrea...

[Diobrando_21]

io ne sto uscendo pazzo non vi seguo più :mbe: :nera: :cry:

per essere più semplici...si può fare un breve riepilogo sulle caratteristiche certe di fermi e delle sue prestazioni? solo quello che realmente si sa senza supposizioni, in modo da far capire anche a chi ne sa di meno sulle MADD e FMA...ve ne sarei grato :)

[Andrea deluxe]

io ne sto uscendo pazzo non vi seguo più :mbe: :nera: :cry:

per essere più semplici...si può fare un breve riepilogo sulle caratteristiche certe di fermi e delle sue prestazioni? solo quello che realmente si sa senza supposizioni, in modo da far capire anche a chi ne sa di meno sulle MADD e FMA...ve ne sarei grato :)


Presunte spec GT300:

512 cuda core

bus ram 384bit

ram gddr5

3 miliardi di transistor

200-220W tdp

frequenze approssimative 600-1600-4800


potenza elaborativa a doppia precisione drammaticamente elevata, mentre quella a singola precisione e' un po sotto a quella della radeon 5870.

la singola viene usata nei games
la doppia vine usata nei calcoli scientifici.

secondo alcune fonti e per sentito dire qui ed altrove, si pensa possa andare un 30% in piu' di una 5870, ma non si sa ancora quanto impattera' sulle prestazioni la tassellazione, che viene eseguita in maniera diversa dalle ati dx11.


insomma adesso di certo al 100% non si sa niente, ma secondo i rumor, potrebbe andare molto veloce in alcuni frangenti (vedi giochi fortemente ottimizzati) e male in altri, nel caso la tassellazione fosse stata mal implementata.

nb: la tassellazione in fermi viene eseguita da funzione fisse nei cuda core, e secondo yoss richiedono circa 4-5 cicli per essere eseguite, rispetto alla soluzione ti che esegue con singola passata.

[A.L.M.]

Presunte spec GT300:

512 cuda core

bus ram 384bit

ram gddr5

3 miliardi di transistor

200-220W tdp

frequenze approssimative 600-1600-4800


potenza elaborativa a doppia precisione drammaticamente elevata, mentre quella a singola precisione e' un po sotto a quella della radeon 5870.

la singola viene usata nei games
la doppia vine usata nei calcoli scientifici.

secondo alcune fonti e per sentito dire qui ed altrove, si pensa possa andare un 30% in piu' di una 5870, ma non si sa ancora quanto impattera' sulle prestazioni la tassellazione, che viene eseguita in maniera diversa dalle ati dx11.


insomma adesso di certo al 100% non si sa niente, ma secondo i rumor, potrebbe andare molto veloce in alcuni frangenti (vedi giochi fortemente ottimizzati) e male in altri, nel caso la tassellazione fosse stata mal implementata.

nb: la tassellazione in fermi viene eseguita da funzione fisse nei cuda core, e secondo yoss richiedono circa 4-5 cicli per essere eseguite, rispetto alla soluzione ti che esegue con singola passata.

2 correzioni:

- per il TDP sali... :asd: Siamo a 225W di consumo massimo effettivo previsto da NVidia per Tesla con clocks parecchio più bassi... ;)

- Le ALU per definizione non sono fixed functions units. :)

[Andrea deluxe]

- Le ALU per definizione non sono fixed functions units. :)

che ti devo dire...



girava una slide con scritto che le unita' avevano la funzione tassellazione fissa.....:boh:

[elgabro.]

Scusate, mi hanno appena riferito che sta scheda dovrebbe uscire verso aprile-maggio, io speravo gennaio-febbraio :eek: :cry:

[Andrea deluxe]

Scusate, mi hanno appena riferito che sta scheda dovrebbe uscire verso aprile-maggio, io speravo gennaio-febbraio :eek: :cry:

entro febbraio escono sicuro....

[Psyco89]

Scusate, mi hanno appena riferito che sta scheda dovrebbe uscire verso aprile-maggio, io speravo gennaio-febbraio :eek: :cry:

chi è stato scusa ? io non ho visto nulla.

[sickofitall]

chi è stato scusa ? io non ho visto nulla.

http://profile.ak.fbcdn.net/object3/512/93/n40643882593_5397.jpg

:asd:

[appleroof]

Non mi sembra che tu abbia bisogno di alleati :) , ho dato solo un piccolo contributo per avallare la tesi da te inizialmente ipotizzata e non condivisa da yossarian, secondo la quale il codice del driver può tranquillamente fare il replace della mad prima che lo shader venga inviato alla gpu, con hit prestazionale che si manifesta solo nel momento dell'invio dello shader alla gpu, e non ogni volta che le istruzioni ivi contenute vengono processate dalla gpu.

Se ancora ci fossero dei dubbi sull'affermazione secondo la quale il driver contiene codice eseguibile dalla cpu, basta dissassemblare qualunque .sys, per notare che il disassemblato contiene istruzioni assembler x86 ;)

http://www.pctunerup.com/up/results/_200911/th_20091126224744_nuovo-1.jpg (http://www.pctunerup.com/up/image.php?src=_200911/20091126224744_nuovo-1.jpg)

azz...se tu e skizzo aveste ragione, come quest'ultimo post dimostrerebbe (sottolineo perchè anche io praticamente ignorante della materia) sarebbe la prima volta che yoss venisse "smentito" :sofico:

se così fosse, davvero complimenti, vista la preparazione di yoss :D :D

[Bastoner]

azz...se tu e skizzo aveste ragione, come quest'ultimo post dimostrerebbe (sottolineo perchè anche io praticamente ignorante della materia) sarebbe la prima volta che yoss venisse "smentito" :sofico:

se così fosse, davvero complimenti, vista la preparazione di yoss :D :D

Io ne dubito fortemente. Peccato che non posso dimostrarlo, data la mia ignoranza. :D
Ma penso che yoss si sia stancato, forse non risponderà.

[appleroof]

Io ne dubito fortemente. Peccato che non posso dimostrarlo, data la mia ignoranza. :D
Ma penso che yoss si sia stancato, forse non risponderà.

non lo so, seguendo il dibattito si capisce che il post di exes dovrebbe appunto dimostrare che yoss su quel punto sbagliava...lo so, se così fosse sarebbe la fine del mito dell'infallibilità di yoss anche per me :asd: :asd:

[Bastoner]

non lo so, seguendo il dibattito si capisce che il post di exes dovrebbe appunto dimostrare che yoss su quel punto sbagliava...lo so, se così fosse sarebbe la fine del mito dell'infallibilità di yoss anche per me :asd: :asd:

Yoss è una specie di divinità, non può sbagliare :asd:

[Psyco89]

entro febbraio escono sicuro....

mica tanto se esce a febbraio quanti mesi sono ?

[Andrea deluxe]

mica tanto se esce a febbraio quanti mesi sono ?

3

[Psyco89]

3

ma scusa e...ma la 5870 è uscita a settembre.

da settembre a febbraio sono 6 mesi di ritardo we !

[Andrea deluxe]

ma scusa e...ma la 5870 è uscita a settembre.

da settembre a febbraio sono 6 mesi di ritardo we !

a ma tu intendevi il ritardo.....:stordita:

io intendevo quanto tempo mancava.....:sbonk:

[Psyco89]

a ma tu intendevi il ritardo.....:stordita:

io intendevo quanto tempo mancava.....:sbonk:

vuol dire che fra un po' potrebbe anche passare direttamente alla generazione successiva.

[Andrea deluxe]

http://www.tweaktown.com/articles/3029/amd_vs_nvidia_are_they_even_playing_the_same_game/index.html

[sinfoni]

http://www.tweaktown.com/articles/3029/amd_vs_nvidia_are_they_even_playing_the_same_game/index.html

Una traduzione (anche maccherronica) veloce??:D

[Andrea deluxe]

Una traduzione (anche maccherronica) veloce??:D

http://translate.google.it/translate?js=y&prev=_t&hl=it&ie=UTF-8&u=http%3A%2F%2Fwww.tweaktown.com%2Farticles%2F3029%2Famd_vs_nvidia_are_they_even_playing_the_same_game%2Findex.html&sl=en&tl=it

[Kharonte85]

Una traduzione (anche maccherronica) veloce??:D
Non dice niente di nuovo, anzi a dire il vero non dice nulla...:asd:
non lo so, seguendo il dibattito si capisce che il post di exes dovrebbe appunto dimostrare che yoss su quel punto sbagliava...lo so, se così fosse sarebbe la fine del mito dell'infallibilità di yoss anche per me :asd: :asd:
Ho seguito il dibattito fin dall'inizio e ho capito quel che potevo :fagiano:...spero che abbiano ragione eXeS e skizzo per il semplice fatto che così facendo Fermi potrebbe avere un potenziale molto più elevato...ma a dire il vero ho ancora dei dubbi, o meglio, mi sorprenderebbe non poco che Yossarian si stesse sbagliando.

Al momento la metto così: quando arriveranno le recensioni della gtx 380 (o quel che sarà) se le prestazioni dovessero essere sottotono probabilmente Yoss aveva ragione altrimenti probabilmente aveva torto...se i dati rimangono quelli e non ci sono altre sorprese in GF100.

[veltosaar]

Presunte spec GT300:

512 cuda core

bus ram 384bit

ram gddr5

3 miliardi di transistor

200-220W tdp

frequenze approssimative 600-1600-4800


potenza elaborativa a doppia precisione drammaticamente elevata, mentre quella a singola precisione e' un po sotto a quella della radeon 5870.

la singola viene usata nei games
la doppia vine usata nei calcoli scientifici.

secondo alcune fonti e per sentito dire qui ed altrove, si pensa possa andare un 30% in piu' di una 5870, ma non si sa ancora quanto impattera' sulle prestazioni la tassellazione, che viene eseguita in maniera diversa dalle ati dx11.


insomma adesso di certo al 100% non si sa niente, ma secondo i rumor, potrebbe andare molto veloce in alcuni frangenti (vedi giochi fortemente ottimizzati) e male in altri, nel caso la tassellazione fosse stata mal implementata.

nb: la tassellazione in fermi viene eseguita da funzione fisse nei cuda core, e secondo yoss richiedono circa 4-5 cicli per essere eseguite, rispetto alla soluzione ti che esegue con singola passata.

Stai ovviamente parlando di una ipotetica gtx380 giusto? quindi i tuoi valori sono più o meno il top a singola gpu che sarà previsto immagino.

No perchè di certo vi sarà una specie di gtx390\395 a doppia gpu e anche le derivate inferiori come gtx360\370 con meno shader.

Inoltre un aspetto di cui nessuno tiene mai conto è: la lunghezza?

Che senso ha continuare ad aumentare la potenza all'infinito come fa ati senza poi sostenere consumi e dimensioni?

la 5970 è lunga 34cm!

[The_SaN]

Stai ovviamente parlando di una ipotetica gtx380 giusto? quindi i tuoi valori sono più o meno il top a singola gpu che sarà previsto immagino.

No perchè di certo vi sarà una specie di gtx390\395 a doppia gpu e anche le derivate inferiori come gtx360\370 con meno shader.

Inoltre un aspetto di cui nessuno tiene mai conto è: la lunghezza?

Che senso ha continuare ad aumentare la potenza all'infinito come fa ati senza poi sostenere consumi e dimensioni?

la 5970 è lunga 34cm!30.5cm, che sono comunque troppi. :)

[marco XP2400+]

Che senso ha continuare ad aumentare la potenza all'infinito come fa ati senza poi sostenere consumi e dimensioni?

in che senso??

[Jackaos]

Stai ovviamente parlando di una ipotetica gtx380 giusto? quindi i tuoi valori sono più o meno il top a singola gpu che sarà previsto immagino.

No perchè di certo vi sarà una specie di gtx390\395 a doppia gpu e anche le derivate inferiori come gtx360\370 con meno shader.

Inoltre un aspetto di cui nessuno tiene mai conto è: la lunghezza?

Che senso ha continuare ad aumentare la potenza all'infinito come fa ati senza poi sostenere consumi e dimensioni?

la 5970 è lunga 34cm!

Per quanto riguarda i consumi mi pare che sia così un pò per tutto il sistema, anche i processori consumano più di quelli di qualche anno fa, almeno le schede video sono molto più sfruttate e lo saranno sempre di più in futuro, e poi non mi pare che si possa criticare il lavoro di ATI sui consumi della serie 5000. Per la lunghezza concordo, ma forse meglio di così non potevano fare, poi c'è da vedere quanto saranno lunghe le nuove Geforce, non credo proprio che saranno delle compattone!

[M4R1|<]

Per quanto riguarda i consumi mi pare che sia così un pò per tutto il sistema, anche i processori consumano più di quelli di qualche anno fa, almeno le schede video sono molto più sfruttate e lo saranno sempre di più in futuro, e poi non mi pare che si possa criticare il lavoro di ATI sui consumi della serie 5000. Per la lunghezza concordo, ma forse meglio di così non potevano fare, poi c'è da vedere quanto saranno lunghe le nuove Geforce, non credo proprio che saranno delle compattone!

Bus a 384bit e 225watt nn sono sicuramente rassicuranti. Servirà una sezioni di alimentazione nn piccola ed un voluminoso sistema di raffreddamento.
ATI sotto i consumi ha fatto i miracoli sulle dimensioni un po' meno certo nn c'è da dimenticarsi anche gli overvolt che si possono fare su 58x0 e 5970, infatti quello che incide molto sulle dimensioni è la sezione di alimentazione. Cmq parliamo di schede di fascia altissima dedicate ad una fascia di mercato che possiede almeno un tower, se nn full-tower, mica i midle della mediamondo (raffreddati pure male) ;)

[appleroof]

Bus a 384bit e 225watt nn sono sicuramente rassicuranti. Servirà una sezioni di alimentazione nn piccola ed un voluminoso sistema di raffreddamento.
ATI sotto i consumi ha fatto i miracoli sulle dimensioni un po' meno certo nn c'è da dimenticarsi anche gli overvolt che si possono fare su 58x0 e 5970, infatti quello che incide molto sulle dimensioni è la sezione di alimentazione. Cmq parliamo di schede di fascia altissima dedicate ad una fascia di mercato che possiede almeno un tower, se nn full-tower, mica i midle della mediamondo (raffreddati pure male) ;)

e quello che ho in firma (raffreddato pure bene)?? :(

io credo che insistere su una scheda a singolo pcb sia stato fatto più che altro per i costi, spero che con i prossimi die-shrink si possa tornare a dimensioni più umane (anche se probabilmente aumenteranno i transistor e siamo punto e a capo...)

[M4R1|<]

e quello che ho in firma (raffreddato pure bene)?? :(

io credo che insistere su una scheda a singolo pcb sia stato fatto più che altro per i costi, spero che con i prossimi die-shrink si possa tornare a dimensioni più umane (anche se probabilmente aumenteranno i transistor e siamo punto e a capo...)

Il CM690, che possiedo anch'io, nn è un case da supermercato ;)
Cmq la dimensione del pcb è strettamente legata al bus, essendo invariato dalla generazione 4 alla 5 nn è questo che ha fatto aumentare le dimensioni

[appleroof]

Il CM690, che possiedo anch'io, nn è un case da supermercato ;)

appunto :stordita: ma la 5970 non ci va :read:

Cmq la dimensione del pcb è strettamente legata al bus, essendo invariato dalla generazione 4 alla 5 nn è questo che ha fatto aumentare le dimensioni

immagino c'entri anche la dimensione del chip in sè, per quello speravo che con un die-shrink futuro si tornasse a lunghezze complessive minori

cmq siamo del tutto OT :D

[Jackaos]

e quello che ho in firma (raffreddato pure bene)?? :(

io credo che insistere su una scheda a singolo pcb sia stato fatto più che altro per i costi, spero che con i prossimi die-shrink si possa tornare a dimensioni più umane (anche se probabilmente aumenteranno i transistor e siamo punto e a capo...)

In effetti non si può dire che ci sia stato un progresso puro al 100%, mi pare che anche anni addietro esistessero le schede video di fascia altissima, ma i case erano comunque di dimensioni ridotte. Il progresso vero c'è nel momento in cui mantenendo la stessa posizione ( parlando in maniera un pò astratta) riesco ad avere un di più. Sembra paradossale che nella storia dei computer le dimensioni siano andate sempre riducendosi ( i primi occupavano interi stanzoni ) ed ora i nostri stiano lievitando. Probabilmente la miniaturizzazione ( intesa in generale ) che in principio è avanzata in percentuali mostruose adesso in rapporto alla capacità di elaborazione dati sta diminuendo, e il rapporto non è più lo stesso di decadi fa, e allora siccome la complessità del sistema aumenta, ma non si trovano soluzioni tecniche di pari livello, aumentano le dimensioni.
Magari se il rimpicciolimento fosse andato avanti sempre allo stesso passo, adesso avremmo dei computer da guardare al microscopio e invece ci sono dei limiti fisici che non riusciamo a superare, ma intanto aumentano i dati da elaborare e la loro complessità, per cui aumentano ( anche se di poco ) dimensioni e ( ahimè ) i consumi. Forse sono cose ovvie quelle che ho detto, però pensando al futuro, mi chiedo che soluzioni adotteranno e cosa ci aspetta, la miniaturizzazione dei chip mi pare di capire che sia quasi al limite ed è per questo che ci proprinano i multicore, ma la parallelizzazione del calcolo mi pare che sia una soluzione temporanea, credo che programmare per architetture multicore sia molto più complicato e laborioso. Quindi cosa ci aspetta, Fermi, la serie 6000, il Majorana, la serie 7000 e poi...??? Cloud compunting per tutti? Il sixwaysli + doublecrossfirex by pumped lucid hydra? Il Phenom 4 a benzina???

[Andrea deluxe]

In effetti non si può dire che ci sia stato un progresso puro al 100%, mi pare che anche anni addietro esistessero le schede video di fascia altissima, ma i case erano comunque di dimensioni ridotte. Il progresso vero c'è nel momento in cui mantenendo la stessa posizione ( parlando in maniera un pò astratta) riesco ad avere un di più. Sembra paradossale che nella storia dei computer le dimensioni siano andate sempre riducendosi ( i primi occupavano interi stanzoni ) ed ora i nostri stiano lievitando. Probabilmente la miniaturizzazione ( intesa in generale ) che in principio è avanzata in percentuali mostruose adesso in rapporto alla capacità di elaborazione dati sta diminuendo, e il rapporto non è più lo stesso di decadi fa, e allora siccome la complessità del sistema aumenta, ma non si trovano soluzioni tecniche di pari livello, aumentano le dimensioni.
Magari se il rimpicciolimento fosse andato avanti sempre allo stesso passo, adesso avremmo dei computer da guardare al microscopio e invece ci sono dei limiti fisici che non riusciamo a superare, ma intanto aumentano i dati da elaborare e la loro complessità, per cui aumentano ( anche se di poco ) dimensioni e ( ahimè ) i consumi. Forse sono cose ovvie quelle che ho detto, però pensando al futuro, mi chiedo che soluzioni adotteranno e cosa ci aspetta, la miniaturizzazione dei chip mi pare di capire che sia quasi al limite ed è per questo che ci proprinano i multicore, ma la parallelizzazione del calcolo mi pare che sia una soluzione temporanea, credo che programmare per architetture multicore sia molto più complicato e laborioso. Quindi cosa ci aspetta, Fermi, la serie 6000, il Majorana, la serie 7000 e poi...??? Cloud compunting per tutti? Il sixwaysli + doublecrossfirex by pumped lucid hydra? Il Phenom 4 a benzina???

il problema e' che il silicio non va piu' d'accordo con il marketing.....:D

non gli sta proprio piu' dietro....:O

[Jackaos]

il problema e' che il silicio non va piu' d'accordo con il marketing.....:D

non gli sta proprio piu' dietro....:O

Non va più tanto daccordo nemmeno col contatore. Ed aggiungo che i pc un tempo non avevano bisogno d'essere trasformati in gallerie del vento, e per restare a parlare di VGA la mia ATI 9800pro era una signora VGA con una ventolina ridicola.

[M4R1|<]

appunto :stordita: ma la 5970 non ci va :read:

pardon

immagino c'entri anche la dimensione del chip in sè, per quello speravo che con un die-shrink futuro si tornasse a lunghezze complessive minori

cmq siamo del tutto OT :D

ovviamente tutto è in relazione alla dimensione del chip e del bus, ma tra Rv770 e Rv870 nn c'è una differenza come tra G92 e GT200. Cmq si riducendosi il pp il bus si può far stare in minor spazio e la dimensione della sezione di alimentazione diminuisce, quindi a seguito di un die-shrink vi è una scheda più piccola (giusto per fare due esempi recenti: HD2900XT e 3870 oppure 8600GT e 9500GT)

In effetti non si può dire che ci sia stato un progresso puro al 100%, mi pare che anche anni addietro esistessero le schede video di fascia altissima, ma i case erano comunque di dimensioni ridotte. Il progresso vero c'è nel momento in cui mantenendo la stessa posizione ( parlando in maniera un pò astratta) riesco ad avere un di più. Sembra paradossale che nella storia dei computer le dimensioni siano andate sempre riducendosi ( i primi occupavano interi stanzoni ) ed ora i nostri stiano lievitando. Probabilmente la miniaturizzazione ( intesa in generale ) che in principio è avanzata in percentuali mostruose adesso in rapporto alla capacità di elaborazione dati sta diminuendo, e il rapporto non è più lo stesso di decadi fa, e allora siccome la complessità del sistema aumenta, ma non si trovano soluzioni tecniche di pari livello, aumentano le dimensioni.
Magari se il rimpicciolimento fosse andato avanti sempre allo stesso passo, adesso avremmo dei computer da guardare al microscopio e invece ci sono dei limiti fisici che non riusciamo a superare, ma intanto aumentano i dati da elaborare e la loro complessità, per cui aumentano ( anche se di poco ) dimensioni e ( ahimè ) i consumi. Forse sono cose ovvie quelle che ho detto, però pensando al futuro, mi chiedo che soluzioni adotteranno e cosa ci aspetta, la miniaturizzazione dei chip mi pare di capire che sia quasi al limite ed è per questo che ci proprinano i multicore, ma la parallelizzazione del calcolo mi pare che sia una soluzione temporanea, credo che programmare per architetture multicore sia molto più complicato e laborioso. Quindi cosa ci aspetta, Fermi, la serie 6000, il Majorana, la serie 7000 e poi...??? Cloud compunting per tutti? Il sixwaysli + doublecrossfirex by pumped lucid hydra? Il Phenom 4 a benzina???

Alla fine il modo di far stare una VGA sotto i 29cm si trova. Credo che Nvidia sotto questo punto di vista sia più avanti di ATI, facendo sempre riferimento agli ultimi 4 anni dalla 8800GTX (ma forse anche la 7950GX2) alla GTX295 nn ci sono stati grossi cambiamenti di dimensioni.
Ciò nn toglie che chi sfrutta una 5970 ed un ipotetico Fermi da over 30cm se ne frega altamente delle dimensioni, per tutti gli altri ci sono soluzioni altrettanto performanti ma meno voluminose e soprattutto costose ;)

[M4R1|<]

Non va più tanto daccordo nemmeno col contatore. Ed aggiungo che i pc un tempo non avevano bisogno d'essere trasformati in gallerie del vento, e per restare a parlare di VGA la mia ATI 9800pro era una signora VGA con una ventolina ridicola.

già però considera che dai tempi della 9800pro ad oggi la capacità computazionale è aumentata esponenzialmente con ogni nuova architettura, mentre il consumo assolutamente no. C'è stato un calo con G80 e R600 ma ad oggi è acqua passata (fortunatamente), ne sono dimostrazione gli ottimi consumi della serie GTX2xx, pur avendo un chip mastodontico, HD48xx e 58/9xx

[leoneazzurro]

Uhm... ho lasciato perdere questa discussione per un po´e ne é venuto su un flame mica da poco. La questione comunque é abbastanza di lana caprina: come si era detto giá da tempo, il codice ad alto livello viene "compilato" ma non restituisce direttamente il codice macchina della GPU, questo perché le API sono "agnostiche" rispetto all´hardware. In pratica é come se le DirectX fossero una "macchina virtuale" con un proprio linguaggio macchina, e la compilazione dell´applicazione richiama proprio le funzioni di questa macchina virtuale nel linguaggio macchina non della GPU, ma della macchina virtuale stessa. Lo strato di astrazione hardware (HAL) serve appunto allo scopo di interfacciare lo "strato" dell´API con lo "strato" del driver. Il driver riceve le chiamate da parte dell´API "tradotte" attraverso l´HAL ed invia i comandi alla GPU.
Il driver "gira" sia sulla CPU che sulla GPU, dato che interfaccia il SO (gestito dalla CPU) con la periferica "scheda video" (gestita dalla GPU). All´interno del driver c´é un ulteriore "compilatore" che traduce le chiamate dell´HAL nel linguaggio macchina della GPU e si occupa di un primo livello di ottimizzazione. Le operazioni di shader replacement, se presenti, si fanno a questo livello e anche la conversione di MADD in FMA potrebbe essere svolta tranquillamente a questo livello e probabilmente sará cosí. Poi, nella GPU, viene eseguito anche un secondo livello di ottimizzazione gestito dal thread processor.

[Kharonte85]

Più che altro mi chiedo perché NV30 sia stato la cagata pazzesca (cit.) che è stato se era possibile fare questa semplice magia...
Non credo che sia paragonabile...nv 30 era deficitario in parecchi aspetti rispetto a R300.
Bus a 384bit e 225watt nn sono sicuramente rassicuranti. Servirà una sezioni di alimentazione nn piccola ed un voluminoso sistema di raffreddamento.
ATI sotto i consumi ha fatto i miracoli sulle dimensioni un po' meno certo nn c'è da dimenticarsi anche gli overvolt che si possono fare su 58x0 e 5970, infatti quello che incide molto sulle dimensioni è la sezione di alimentazione. Cmq parliamo di schede di fascia altissima dedicate ad una fascia di mercato che possiede almeno un tower, se nn full-tower, mica i midle della mediamondo (raffreddati pure male) ;)
E' praticamente certo che le dimensioni saranno identiche alle gtx 280 &co, ricordo per l'ennesima volta che il TDP della gtx 280 era ben 236W e il chip @65nm vantava una superficie maggiore quindi niente fa pensare che vedremo schede più lunghe, sezioni di alimentazioni mai viste e/o con dissipatori diversi da quelli visti sino ad ora ;)

[veltosaar]

'innovazione per essere sostenibile ed efficiente dovrebbe quantomeno raddoppiare le prestazioni aumentando meno che proporzionalmente i consumi.

Siccome si è arrivati ad un punto (250w solo per una scheda video è quasi come la lavatrice) di non ritorno, ora l'innovazione deve essere più che sostenibile.

Cioè raddoppiare le prestazioni mantenendo i consumi almeno uguali se non minori. Ed è questa la sfida. Ed è questo il perchè si va a ridurre il processo produttivo.

Non si capisce allora il perchè di queste lunghezze esagerate.

Io con un thermaltake element G che è al top per i middle tower potrei aver problemi con una scheda sui 30 cm ed oltre. Ed è assurdo.

In questo caso prendono piede dei case da 50 euro ma full tower contro i case da 150 euro middle tower.

Bah!

[Kharonte85]

'innovazione per essere sostenibile ed efficiente dovrebbe quantomeno raddoppiare le prestazioni aumentando meno che proporzionalmente i consumi.

Siccome si è arrivati ad un punto (250w solo per una scheda video è quasi come la lavatrice) di non ritorno, ora l'innovazione deve essere più che sostenibile.

Cioè raddoppiare le prestazioni mantenendo i consumi almeno uguali se non minori. Ed è questa la sfida. Ed è questo il perchè si va a ridurre il processo produttivo.
Teoricamente dovrebbe essere così, praticamente invece si hanno incrementi del 50% circa a prezzo di una leggera diminuzione o un pareggio o un leggero aumento dei cosumi.

La cosa preoccupante è che prima o poi (e io temo che i primi segnali già ci siano) la pacchia del passaggio al pp inferiore diverrà molto difficoltosa...a quel punto sarà difficile inventarsi un nuovo modo per diminuire consumi e aumentare le prestazioni.


Non si capisce allora il perchè di queste lunghezze esagerate.

Io con un thermaltake element G che è al top per i middle tower potrei aver problemi con una scheda sui 30 cm ed oltre. Ed è assurdo.

In questo caso prendono piede dei case da 50 euro ma full tower contro i case da 150 euro middle tower.

Bah!
Le lunghezze sono un discorso differente, è chiaro che la 5970 paga il fatto di essere una dual GPU sullo stesso pcb (è proprio una questione di spazio/complessità) mentre per ora nvidia non ha più aumentato le dimensioni delle proprie schede sin dall'uscita di G80...

[veltosaar]

Le lunghezze sono un discorso differente, è chiaro che la 5970 paga il fatto di essere una dual GPU sullo stesso pcb (è proprio una questione di spazio/complessità) mentre per ora nvidia non ha più aumentato le dimensioni delle proprie schede sin dall'uscita di G80...

Si ma la gtx295 single pcb è lunga come la 285 ed ha 2 gpu. Non solo, è anche a 55nm! contro i 40 nm della 5970.

Vabbè, speriamo che la futura gtx380 sia almeno 27\28. Sennò perdono di senso.

In questo le cpu invece fanno da maestre. Aumentano i core nello stesse dimensioni e con consumi sempre simili.

[Milotto]

Più che altro mi chiedo perché NV30 sia stato la cagata pazzesca (cit.) che è stato se era possibile fare questa semplice magia...

Il grande limite di NV30 era la precisione di calcolo con la quale venivano eseguiti li shader.. FP16 o FP32 , mentre la controparte ATI con l'architettura R300 eseguiva in FP24 bit (scelta più saggia e "comoda" per la potenza di allora)..
Da un certo punto di vista NV30 era avanti: disponeva dello SM 3.0 poi adottato all'unanimità...

[MetalPonch]

Piu che altro a mio parere si dovrebbero ricercare nuove tecnologie non tanto per diminuire i consumi ma piu che altro per limitare lo spreco energetico...pensate a quando la scheda arriva 80°C oppure a tutto il calore emanato dalle componenti cpu vga e psu su tutte:
bene tutto quel calore è energia letteralmente buttata nel cesso xké allo stato attuale non è possibile riutilizzarla.
Se tutto quel calore invece di essere buttato fuori dal case potesse essere recuperato e riutilizzato per alimentare altre componenti o parte delle stesse da cui proviene,sarebbe un grande passo avanti.
Quindi per il futuro al di là delle performance credo ke le varie industrie sia di componenti ke di altro,dovrebbero puntare piu sull'ottimizzazione energetica.
Tanto oggi avere un sistema ke fa 100fps invece ke 120 non cambia né la vita né il piacere di gioco/esperienza
ma avere un sistema ke in full consuma 450w contro uno ke se ne succhia 600 la cambia e come...

[appleroof]

cut
E' praticamente certo che le dimensioni saranno identiche alle gtx 280 &co, ricordo per l'ennesima volta che il TDP della gtx 280 era ben 236W e il chip @65nm vantava una superficie maggiore quindi niente fa pensare che vedremo schede più lunghe, sezioni di alimentazioni mai viste e/o con dissipatori diversi da quelli visti sino ad ora ;)

quoto, non dimentichiamo poi che come sappiamo quel tdp massimo si raggiunge molto raramente, è difficile che sia raggiunto fuori da bench/sw appositi e quindi neanche in game..

io spero sia lunga quanto gtx280

[Jackaos]

Piu che altro a mio parere si dovrebbero ricercare nuove tecnologie non tanto per diminuire i consumi ma piu che altro per limitare lo spreco energetico...pensate a quando la scheda arriva 80°C oppure a tutto il calore emanato dalle componenti cpu vga e psu su tutte:
bene tutto quel calore è energia letteralmente buttata nel cesso xké allo stato attuale non è possibile riutilizzarla.
Se tutto quel calore invece di essere buttato fuori dal case potesse essere recuperato e riutilizzato cut

Ho il case posizionato in modo che l'aria vada a raccogliersi nell'angolo della stanza dove sto io, non accendo il termosifone, la mia 4870x2 fa un bel caldino:asd: , quando gioco il gatto si mette dietro al pc :asd: .

[Kharonte85]

quoto, non dimentichiamo poi che come sappiamo quel tdp massimo si raggiunge molto raramente, è difficile che sia raggiunto fuori da bench/sw appositi e quindi neanche in game..

io spero sia lunga quanto gtx280

Nvidia praticamente lo ha semi-ufficialmente dichiarato in tre modi: Presentando le tesla, facendo vedere quella foto di gf100 che esegue il benchmark e dicendo esplicitamente che la lunghezza della scheda è identica a quella della serie GTX 2xx ;)