[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

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

Originariamente inviato da Kharonte85

E' old, ne abbiamo parlato prima: http://www.hwupgrade.it/forum/showpo...postcount=9021

Originariamente inviato da zorco

sei old già postato

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

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

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

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

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

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

quoto!

[marco XP2400+]

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

quoto

[DVD2005]

Originariamente inviato da Andrea deluxe

quoto!

anche io sebbene non ci capisca una mazza

[The_SaN]

Originariamente inviato da Iantikas

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

Hahaha bellissima

[yossarian]

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

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

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

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

Originariamente inviato da eXeS

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

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?

[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
Se ve ne avanza una... io sono OLD, io sono OLD

[maurilio968]

Originariamente inviato da yossarian

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

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

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

[luX0r.reload]

Originariamente inviato da maurilio968

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

[maurilio968]

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

QUI -> elementi funzionali di una gpu. le alu

[eXeS]

Originariamente inviato da yossarian

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



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



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?

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:

Originariamente inviato da yossarian

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?

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]

Originariamente inviato da maurilio968

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

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

[molochgrifone]

Originariamente inviato da Severnaya

ma nn vi potete drogare come tutti gli altri?!

Parole sante

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

Originariamente inviato da DVD2005

anche io sebbene non ci capisca una mazza

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

[martinez1983]

Originariamente inviato da Severnaya

ma nn vi potete drogare come tutti gli altri?!

Questo è il post dell' anno!!!



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

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

[eXeS]

Originariamente inviato da skizzo99999999

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