[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[Wikkle]

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

[molochgrifone]

Originariamente inviato da Wikkle

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

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

http://www.nvidia.it/object/win7_win...2_whql_it.html

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

se invece ti rifersci ad altro non so

[skizzo99999999]

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.

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.

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

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

Originariamente inviato da yossarian

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

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

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

[Wikkle]

Originariamente inviato da molochgrifone

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

http://www.nvidia.it/object/win7_win...2_whql_it.html

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

se invece ti rifersci ad altro non so

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

[Rsdj]

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

[yossarian]

Originariamente inviato da skizzo99999999

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

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



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

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

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

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

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

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

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

e dall'home page dell'opengl board

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


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

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

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

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


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

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

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

[maurilio968]

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

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

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

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

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

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

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

Ho sbagliato?

[Walrus74]

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

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

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

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

[persa]

Originariamente inviato da Walrus74

cut

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

io non ci ho proprio capito nulla di quello che hanno scritto in queste pagine ^^

[yossarian]

facio un ultimo tentativo e poi. giuro che abbndono

Originariamente inviato da skizzo99999999

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

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

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

DirectX

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

OpenGL

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

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

Originariamente inviato da skizzo99999999

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

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

Originariamente inviato da skizzo99999999

che infatti si compila il sorgente GLSL come vuole, e se lo fa male sono ca**i suoi, l'utente e lo sviluppatore si incazzeranno e si lamentaranno con chi di dovere.

....l'importante è che lo compili secondo LO STANDARD DI RIFERIMENTO

Originariamente inviato da skizzo99999999

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

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

Originariamente inviato da skizzo99999999

Ma il driver non è fatto da microsft e non è del s.o., ma è fatto da ATI/NVIDIA,

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

Originariamente inviato da skizzo99999999

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

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

Originariamente inviato da skizzo99999999

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

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

Originariamente inviato da skizzo99999999

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

da tutto quanot riportato sopra

Originariamente inviato da skizzo99999999

"Unlike some other shading language APIs out there, GLSL is designed to accept shader text rather than precompiled binaries.

qui il riferimento è esplicito alle vecchie versioni di opengl (le dx sono arrivate al linguaggio ad alto livello ben prima)

Originariamente inviato da skizzo99999999

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

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

Originariamente inviato da skizzo99999999

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

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

Originariamente inviato da skizzo99999999

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

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

Dove sarebbe la differenza?

[Severnaya]

ma nn vi potete drogare come tutti gli altri?!

[maurilio968]

Quindi io avevo capito bene. Grazie Yossarian.

[maurilio968]

Originariamente inviato da Severnaya

ma nn vi potete drogare come tutti gli altri?!

Facciamo anche quello

[Severnaya]

nice

[yossarian]

Originariamente inviato da maurilio968

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

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

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

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

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

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

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

Ho sbagliato?

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

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

Originariamente inviato da Walrus74

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

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

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

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

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

[Bastoner]

Originariamente inviato da Severnaya

ma nn vi potete drogare come tutti gli altri?!

Geniale

[Iantikas]

http://www.nvidia.com/object/product...ce_310_us.html


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


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


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



...ciao

[Kharonte85]

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

[zorco]

Originariamente inviato da Iantikas

http://www.nvidia.com/object/product...ce_310_us.html


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


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


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



...ciao

sei old già postato

[maurilio968]

Originariamente inviato da Iantikas

http://www.nvidia.com/object/product...ce_310_us.html

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

...la NUOVISSIMA Geforce GT310

...ciao

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