[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[Bastoner]

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

[Iantikas]

Originariamente inviato da devAngnew

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

...cmq sei divertente da leggere

[Bastoner]

Originariamente inviato da Iantikas

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

...cmq sei divertente da leggere

In effetti è molto divertente
Quella del copyright è bellissima

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
L'umiltà è la qualità più grande, devAngnew.

[halduemilauno]

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

[Iantikas]

Originariamente inviato da halduemilauno

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

il mio tedesco è un pò arruginito ...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]

Originariamente inviato da devAngnew

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 (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]

Originariamente inviato da halduemilauno

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

Originariamente inviato da Iantikas

il mio tedesco è un pò arruginito ...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à:

Originariamente inviato da A.L.M.

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.ph...&id=8409118252

[halduemilauno]

Originariamente inviato da Kharonte85

Lo sapevamo già:

OK.

[devAngnew]

Originariamente inviato da Bastoner

In effetti è molto divertente
Quella del copyright è bellissima

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
L'umiltà è la qualità più grande, devAngnew.

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

[yossarian]

Originariamente inviato da devAngnew

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?

[Bastoner]

Originariamente inviato da devAngnew

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

Originariamente inviato da devAngnew

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

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

Originariamente inviato da yossarian

Ops, wikipedia non ti dà informazioni al riguardo?

Ma LOL.

[The_SaN]

Originariamente inviato da devAngnew

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

@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]

Originariamente inviato da yossarian

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]

Originariamente inviato da The_SaN

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

Eh?

[The_SaN]

Originariamente inviato da Bastoner

Eh?

Per mancanza di conoscenze a riguardo (lo so, battuta pessima)

[Kharonte85]

Originariamente inviato da Bastoner

Hai paura che la finanza faccia un blitz su hwupgrade?
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]

Originariamente inviato da yossarian

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

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]

Originariamente inviato da Bastoner

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

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

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

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]

Originariamente inviato da yossarian

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

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

Originariamente inviato da yossarian

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

[yossarian]

Originariamente inviato da skizzo99999999

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



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