[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[konzendoji]

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

[Kharonte85]

Originariamente inviato da 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 .

Ecco speriamo di no...

Originariamente inviato da konzendoji

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

Ci mancava Socrate...


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

[yossarian]

Originariamente inviato da skizzo99999999

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

Originariamente inviato da Kharonte85

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

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

[Kharonte85]

Originariamente inviato da yossarian

allora, diciamo che abbiamo fatto tutti, me compreso, un po' di confusione con i termini.
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 ). 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 )

Originariamente inviato da yossarian

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

Mi son spaventato anche io...

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

[yossarian]

Originariamente inviato da Kharonte85

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

Mi son spaventato anche io...

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

Spoiler:

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

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

sembrerebbe un ennesimo rebrand ...

[Kharonte85]

Originariamente inviato da zorco

http://www.nvidia.com/object/product...ce_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]

Originariamente inviato da yossarian

allora, diciamo che abbiamo fatto tutti, me compreso, un po' di confusione con i termini.
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 ). 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]

Originariamente inviato da 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!

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.

[Severnaya]

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.

scusa cosa vuol dire che hai spiegato "abbastanza"


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

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

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

Originariamente inviato da 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...

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.

Originariamente inviato da skizzo99999999

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

Originariamente inviato da skizzo99999999

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.

Originariamente inviato da skizzo99999999

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.

Originariamente inviato da skizzo99999999

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

Originariamente inviato da skizzo99999999

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?

Originariamente inviato da skizzo99999999

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.

Originariamente inviato da skizzo99999999

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.

Originariamente inviato da skizzo99999999

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

Originariamente inviato da skizzo99999999

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.

Originariamente inviato da skizzo99999999

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.

Originariamente inviato da skizzo99999999

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

[yossarian]

Originariamente inviato da 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.

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

Originariamente inviato da 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 ).
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...

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]

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.

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 I miei discorsi sonmo lineari e piuttosto chiari, mi sembra, al contrario dei tuoi. E comunque...............

....................ancora aspettando delle risposte, ciccio

ps1 (che non è playstation ma post scriptum ) 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

[yossarian]

Originariamente inviato da 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

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