[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[eXeS]

Originariamente inviato da skizzo99999999

Penso proprio di si. A dire il vero mi è venuto in mente un possibile problema che forse impedisce (proprio a causa dell'arrotondamento) la trasformazione MADD-FMA. Non mi sembra concettualmente complicatissimo da far capire (ma lo pensavo anche per il compilatore...), ma sarebbe comunque un discorso fine a se stesso. Se a qualcuno interessa ci posso provare

A me interessa

[Pike79]

Originariamente inviato da eXeS

A me interessa

Idem!

[leoneazzurro]

x skizzo: non é detto che lo shader sia compilato prima, potrebbe essere anche compilato in tempo reale, in quel caso ci sarebbe un ulteriore overhead dovuto all´analisi necessaria per la sostituzione. Dipende probabilmente dall´applicazione.

Originariamente inviato da Ratatosk

Ah ecco, invece di essere un'operazione diversa ma concettualmente simile (MADD vs FMA) erano operazionei del tutto diverse.

A questo punto resta quindi solo da capire se applicare delle FMA al posto delle MADD funziona oppure gli errori introdotti possono essere distruttivi a tal punto da renderlo impossibile, nel qual caso l'unica alternativa è farsi le MADD in due passi. Giusto?

Originariamente inviato da eXeS

Più che parlare di errori introdotti sarebbe corretto parlare di errori mancanti, e bo, mi sembra così assurdo che una operazione (FMA) che produce risultati più precisi in tempi più rapidi, sia meno preferibile a due operazioni che producono lo stesso risultato (MUL-ADD) in tempi più lunghi.

Certo, il colore del pixel risultante usando FMA al posto di MADD (MUL-ADD) potrebbe essere diverso, ma approssimerà meglio quello che avrebbe dovuto essere il vero colore finale.

L´operazione é piú precisa, certo, ma rispetto alla MADD c´é una differenza nel risultato che nel caso di shader lunghi potrebbe portare a differenze non trascurabili nel risultato finale e il problema diventa se il pixel che restituisce uno shader con FMA sia quello che lo sviluppatore intendeva quando ha programmato lo shader con MADD (magari con tecniche di compensazione dell´errore che adesso é di diversa entitá). In casi particolari si potrebbero avere variazioni di gamma colore oppure dei veri e propri artefatti, bisogna vedere quanti questi casi particolari sranno in realtá.

[molochgrifone]

Originariamente inviato da appleroof

appunto ma la 5970 non ci va



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

cmq siamo del tutto OT

Originariamente inviato da persa

ma forse nel CM690 II ci andrà. fotina http://www.coolermaster.com/upload/360/RC-690K_360.swf

Siamo OT, ma c'è il modo di farla entrare anche nel CM attuale utilizzando il modulo 4-in-3 per gli hard disk e rimuovendo la gabbia degli HD

[persa]

Originariamente inviato da molochgrifone

Siamo OT, ma c'è il modo di farla entrare anche nel CM attuale utilizzando il modulo 4-in-3 per gli hard disk e rimuovendo la gabbia degli HD

insomma devi svuotare mezzo case per farcela stare

[molochgrifone]

Originariamente inviato da persa

insomma devi svuotare mezzo case per farcela stare

In realtà è un'operazione abbastanza facile e veloce, che inoltre migliora il raffreddamento degli HD

[davide155]

Ragazzi insomma non c'è punte news riguardo Fermi?

Sto aspettando queste schede per scegliere la mia prossima vga tra Ati e Nvidia.

Sperando che tornino (almeno Nvidia) a fare delle schede video con lunghezze più contenute come le vecchie G80, e non quelle Limousine che hanno tirato fuori ultimamente, dato che non ne entra nemmeno una nel mio Thermaltake Armor JR

[appleroof]

Originariamente inviato da davide155

Ragazzi insomma non c'è punte news riguardo Fermi?

Sto aspettando queste schede per scegliere la mia prossima vga tra Ati e Nvidia.

Sperando che tornino (almeno Nvidia) a fare delle schede video con lunghezze più contenute come le vecchie G80, e non quelle Limousine che hanno tirato fuori ultimamente, dato che non ne entra nemmeno una nel mio Thermaltake Armor JR

quoto


p.s.: ciao, era da molto tempo che non ti vedevo in questi lidi

[skizzo99999999]

Originariamente inviato da leoneazzurro

x skizzo: non é detto che lo shader sia compilato prima, potrebbe essere anche compilato in tempo reale, in quel caso ci sarebbe un ulteriore overhead dovuto all´analisi necessaria per la sostituzione. Dipende probabilmente dall´applicazione.

gli shader sono si compilati in tempo reale (cioè quando l'applicazione/gioco è partita, quindi a run-time), ma all'atto del caricamento degli stessi, non quando vengono utilizzati (per più volte per frame) all'interno del loop di rendering. E non è che dipende dall'applicazione, è proprio così sempre, a meno che uno non richiami il caricamento e le successive fasi compilazione/link di ogni shader ogni volta prima di utilizzarli. E' proprio questo il motivo del contendere delle ultime pagine, ma ormai sull'argomento mi sembra sia stato detto tutto.

Per quanto riguarda i possibili problemi dell'arrotondamento, quello che mi è venuto in mente è l'integrazione tra la fixed pipeline e quella programmabile.
Fino all'arrivo delle directx 8.1/9 e opengl 2.0 le GPU non erano programmabili, per cui gli algoritmi che potevano essere utilizzati (ad esempio per l'illuminazione) erano fissi e sempre gli stessi per tutti. Con l'avvento dei pixel e vertex shader programmabili (ora anche geometry shader e compute shader), ognuno può farsi il suo modello di illuminazine utilizzando più o meno risorse, fare i calcoli per vertex o per pixel, ecc... Inoltre si possono fare processare anche altri dati oltre a quelli prettamente geometrici, per farci godere tutti gli effetti di post-processing tipo depth-of-filed, motion blur, ambient occlusion, ecc...
Ovviamente per questione di compatibilità la fixed pipeline (cioè quella non programmabile) è stata mantenuta: non nel senso che ci sono delle unità non programmabili, ma che quando questa funzionalità viene richiesta, viene caricato un codice che fa le stesse operazioni che farebbe una GPU non programmabile. Quest'ultimo concetto è molto importante perchè alcune volte, per alcuni passi di rendering non è necessario accedere a risorse particolari (mi viene in mente ad esempio se uno deve disegnare un HUD con informazioni testuali tipo quello di un fps), per cui un invece che scrivere uno shader di una decina di righe o meno può non usare gli shader e quindi utilizzare le funzioni standard. Ed è qui che può sorgere il problema. Se uno utilizza in uno shader un "risultato" prodotto da un passo "programmabile" con uno proveniente da un calcolo di un passo "fixed", potrebbe succedere che numeri che dovrebbero essere uguali, non lo sono a causa dell'utilizzo di unità diverse che effettuano calcoli a precisione diverse. Per fare un esempio terra terra, un'istruzione che si fa sempre nel vertex shader è:

gl_Position = ftransform();

che prende le coordinate del vertice in esame e le trasforma dal "world space" in "clip space" utilizzabili nel pixel shader. Questa operazione emula il comportamento della fixed e può essere svolta "a mano" operando direttamente sulle matrici e vettori:

gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;

teoricamente dovrebbero portare allo stesso risultato, ma visto che è possibile che una GPU abbia "ottimizzato" in un certo in modo quella operazione matematica, possono esserci delle precisioni "diverse". L'emulazione dlla fixed pipeline garantisce che avrò sempre gli stessi risultati invece. Un esempio tipico di artefatti che possono nascere da cose del genere sono gli “Z-fighting”. Mettiamo che io abbia 2 poligoni paralleli (o mooooolto vicini) alla stessa distanza dalll'osservatore che si trovano almeno in parte sovrapposti (quindi più pixel che li compongono hanno le stesse coordinate z, quelle relative alla profondità). Potrebbe accadere che alcuni pixel siano rilevati come davanti e altri dietro, formado un effetto di miscuglio di colori che viene visto come artefatto.

Il problema nasce prorpio da qui. Siccome io devo almeno far funzionare le applicazioni sulla mia scheda, mi sembra ragionevole che se verranno sostituite le MADD con le FMA, verranno anche sostituite nei calcoli che coinvolgono l'emulazione della fixed pipeline, sennò i risultati non sarebbero più confrontabili e si creerebbero probabilmente situazioni come quella descritta in precedenza. Così facendo però, non avremo più i risultati derivanti dalla fixed uguali a quelli delle altre schede, e non so se questo sia accettabile, cioè ci siano dei vincoli numerici di precisione minima e massima da rispettare in questa modalità per essere "standard".

Non so se sono stato chiarissimo ma spero che si capisca il succo del discorso

[davide155]

Originariamente inviato da appleroof

quoto


p.s.: ciao, era da molto tempo che non ti vedevo in questi lidi

Grande appleroof, piacere di rivederti

[Milotto]

Originariamente inviato da leoneazzurro

Quello era NV40 (la serie 6). La NV30 disponeva del 2.0a (un superset del 2.0)

....yes mi sono confuso...ricordavo tutta una serie di screenshoots qui su hwupgrade dove veniva analizzata la resa qualitativa degli shader di Farcry eseguiti con FP16 (vistosi problemi di banding) e eseguiti con FP32 (framerate scadente)....
Lo SM 3.0 era causa di una altre querelle....HDR or not?

[M4R1|<]

Originariamente inviato da Ratatosk

In realtà al cambio di pp il bus è la cosa che si restringe meno

Si be la dimensione del bus è più o meno sempre quella infatti con pp sempre più piccoli o si aumentano anche le dimensioni del chip (quindi maggiori transistor) oppure fisicamente nn ci stanno i bus che ci stavano nella precedente generazione (vedi 4870 e 5770)

Originariamente inviato da Kharonte85

Non credo che sia paragonabile...nv 30 era deficitario in parecchi aspetti rispetto a R300.

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

meglio così, cmq per quando mi rigurda ribadisco quando detto, e cioè che le soluzioni estreme, che garantiscono il top delle performance, anche se sforano dai 30cm nn sono poi così problematiche

[leoneazzurro]

Originariamente inviato da skizzo99999999

gli shader sono si compilati in tempo reale (cioè quando l'applicazione/gioco è partita, quindi a run-time), ma all'atto del caricamento degli stessi, non quando vengono utilizzati (per più volte per frame) all'interno del loop di rendering. E non è che dipende dall'applicazione, è proprio così sempre, a meno che uno non richiami il caricamento e le successive fasi compilazione/link di ogni shader ogni volta prima di utilizzarli.

Si, non intendevo compilati piú volte al frame, pensavo volessi dire che si puó avere lo shader precompilato giá prima dell esecuzione (ma cosí si perdono molte ottimizzazioni). Comunque anche l´ottimizzazione on-chip non é da sottovalutare

[yossarian]

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

tutto giusto in teoria; ma poichè con la sola teoria non si costruice niente, veniamo alla pratica. Secondo il tuo ragionamento, nVidia (perchè di nVidia stiamo parlando), mette mano al suo compilatore custom o ne progetta uno nuovo ogni volta che deve supportare una nuova architettura. Se ciò fosse vero, con CUDA, progetto su cui nVIdia sta lavorando da anni, dovrebbe aver messo a punto compilatore e ottimizzatore ad hoc per i proprio chip (si tratta di supportare solo quelli a shader unificati). Sentiamo cosa ha da dire proprio nVidia in proposito, premettendo ceh CUDA non significa solo "driver unificati" ma è un progetto che abbraccia l'architettura del SW e la microarchitettura dell'HW che deve far girare quel SW (l'appellativo CUDA CORE delle unità di calcolo di fermi fa esplicito riferimento, non a caso, a questa architettura)
The CUDA compiler driver splits an application into two parts, one which is run on the host CPU, and the other which is run on the GPU. The CPU code uses the default host compiler, while the GPU code uses a new toolchain that includes Open64.

Quindi il compiler ad alto livello non fa altro che dividere in due parti l'applicazione, facendo girare una parte sul compiler di default della cpu e l'altra su un compiler che fa uso di Open64. Il primo ci interessa poco, ai fini di questo discorso (utilizza istruzioni standard della cpu e dell'API su cui gira).
Vediamo il secondo.
NVIDIA already had a well-tuned low-level compiler for graphics codes, called OCG (Optimized Code Generator). This handles register allocation, scheduling, and peephole optimizations. This compiler is built into the graphics driver for doing just-in-time compilation of graphic codes.


qui parla di un optimizer a basso livello e di tipo JIT.

Because graphics codes tend to be relatively simple compared to general purpose C code (control flow has only recently been added to DirectX), and due to the compile-time limitations of needing to compile at runtime, it was decided that CUDA needed a high-level optimizer to handle the compute codes

There were three options for doing this: write a new proprietary optimizer, use GCC, or use Open64. Writing a new optimizer was ruled out because it would require too many man years to develop. So the choice was between using GCC or Open64. Because of Open64's reputation for optimization (and with my encouragement), we chose Open64.


qui si esclude la possibilità di creare un optimizer proprietario ad alto livello perchè ciò avrebbe richiesto troppi anni. Quindi si è scelto quello open64 STANDARD.
Ricapitolando: la cpu elabora codice non ottimizzato da nVidia e per la gpu si fa uso di un compiler ad alto livello Open64 STANDARD (per sistemi basati su unix, per win ce n'è un altro). Questo esempio, fatto per CUDA vale anche per OpenGL o DirectX perchè, a basso livello, si fa uso sempre dello stesso optimizer OCG (optimize code generator).
In più, il modello di ottimizzazione (che non definirei proprio at runtime) da voi proposto (la cpu fornisce in fase di compilazione il codice alla gpu che lo riceve già bello e pronto per essere elaborato) è giudicato inefficiente dalla stessa nVidia che preferisce ottimizzazioni JIT. Motivi di spreco di risorse, lentezza nel trasferimento dati tra cpu vram e gpu, difficoltà nel mettere le mani su compiler standard o nel progettarne uno custom per intero, questioni di portabilità e di compatibilità con i prodotti passati e futuri con semplici modifiche del codice dell'OCG, credo siano motivi più che sufficienti. E se non siete d'accordo protestate con nVidia.
Comunque, proseguiamo: il codice sorgente destinato alla gpu è compilato (non ottimizzato), dunque, da un compiler STANDARD e fornisce istruzioni per PTX (parallel thread execution) che è una VM installata su gpu con una sua ISA. La prima versione 1.0 risale ai tempi di G80 e con fermi si arriva alla versione 2.0. PTX provvede a ricompilare di nuovo il codice lanciando le ottimizzazioni tramite OCG. Questo tool è in grado di riconoscere il tipo di gpu e, di conseguenza, effettuare tutte le ottimizzazioni necessarie pr quella specifica architettura (cosa che una cpu che non ha accesso all'interno della gpu non potrà mai fare). Tra queste ottimizzazioni ci sono anche quelle relative all'uso di preephole che sono delle finestre che permettono di individuare parti di codice su cui intervenire. In questo caso possono permettere di individuare le MADD e effettuare la sostituzione con le FMA in modalità JIT all'interno della gpu.
"Casualmente" , Fermi contiene alcune ottimizzazioni atte a velocizzare il thread switching (ad esempio il dual warp scheduler) oltre ad avere una notevole potenza di calcolo con gli interi (necessaria ad effettuare preephole optimization); infine, nVidia annovera tra i "device runtime components" (col termine device indica la gpu mentre la cpu è indicata come host) proprio quelle atomic ops con interi (and, or, contronto) che servono per le preephole optimization (e quindi per le operazioni di instruction replacement) e specifica che queste sono disponibili dalla relaease 1.1 della PTX VM (quindi G80 è escluso ma fermi sembra rientrarci alla stragrande ).

A questo punto, sei liberissimo di continuare a credere che i driver facciano il "miracolo" di far si che la cpu ottimizzi tutto il codice all'atto della compilazione (hai una visione molto statica delle cose). E che questo avvenga in opengl con compiler custom (ma nVidia pare non voglia perdere tempo a scrivere un compiler per opengl o per open64, o per qualsivoglia piattaforma e preferisce affidarsi a compiler standard) e in D3D (non dimentichiamo che parliamo di fermi e giochi e, quindi soprattutto DX) con la modifica del compiler standard HLSL (operazione che solo un pazzo andrebbe ad intraprendere, quando ci sono vie più sicure e veloci). L'idea, poi, che la cpu possa eseguire ottimizzazioni JIT è ancora più folle: ti do solo un paio di dati: su GT200 il tempo di accesso medio stimato alla vram (non alla ram di sistema, quindi ma a quella video) era di 400-800 cicli, contro i 2-3 cicli di tempo di accesso ai registri interni e i circa 30-40 di accesso alle cache interne). Non oso pensare a quali sarebbero gli access time attraverso ram di sistema, bus pci-ex. e vram. Ci pensi ai disastri di un'ottimizzazione al volo fatta via cpu con, ad esempio, shader procedurali, o istruzioni di tessellation (con vertici fissi e funzione matematica che descrive la superficie da riprodurre) o con istruzioni che generano cascate di dati con cui sono necessarie altrettante istruzioni. Non mi meraviglio che nVidia, avendo a che fare con un processo di tipo dinamico, cerchi di eseguire il maggior numero di operazioni direttamente sulla gpu scaricando, il più possibile, persino la vram, per ridurre le latenze.

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.

nessuno ha mai negato che il driver contenga istruzioni per la cpu. Semmai è il contrrio; quello che sostengo è che la cpu non fa una cippa di ottimizzazione all'atto della compilazione e che il driver contiene anche istruzioni per la gpu e sono questa a contenere le ottimizzazioni.

Originariamente inviato da eXeS

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.

interessante, ma l'utilità ai fini di ciò di cui si discute?

Originariamente inviato da eXeS

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 ?

cosa che nessuno, ripeto, sta mettendo in dubbio

Originariamente inviato da eXeS

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

infatti yossarian (e pare anche nVidia, il cui parere, ritengo sia più autorevole, in quanto si parla di Fermi), continua a non condividere la tesi delle ottimizzazioni fatte dalla stessa cpu in fase di compilazione e ritiene improbabili quelle JIT fatte dalla cpu. Insomma, nVidia pensa che meno traffico ci sia nel bus pci-express e meno la cpu (e, addirittura, la vram) interviene e meglio è per tutti. Voi, liberi di pensarla come volete

[Foglia Morta]

Dopo "tanto" tempo quando nessuno se lo aspettava più ritorni con una doppietta , sarai micca parente di Huntelaar

[The_SaN]

Originariamente inviato da Foglia Morta

Dopo "tanto" tempo quando nessuno se lo aspettava più ritorni con una doppietta , sarai micca parente di Huntelaar

Sono juventino

[yossarian]

Originariamente inviato da leoneazzurro

Si, non intendevo compilati piú volte al frame, pensavo volessi dire che si puó avere lo shader precompilato giá prima dell esecuzione (ma cosí si perdono molte ottimizzazioni). Comunque anche l´ottimizzazione on-chip non é da sottovalutare

per ottimizzazioni "al volo" è l'unica strada percorribile.

[Defragg]

Originariamente inviato da The_SaN

Sono juventino

Ci stiamo prendendo solo limoni

[Alex656]

Questa l'avevate letta?
http://www.fudzilla.com/content/view/16601/1/

[maurilio968]

Originariamente inviato da yossarian

infatti yossarian (e pare anche nVidia, il cui parere, ritengo sia più autorevole, in quanto si parla di Fermi), continua a non condividere la tesi delle ottimizzazioni fatte dalla stessa cpu in fase di compilazione e ritiene improbabili quelle JIT fatte dalla cpu. Insomma, nVidia pensa che meno traffico ci sia nel bus pci-express e meno la cpu (e, addirittura, la vram) interviene e meglio è per tutti. Voi, liberi di pensarla come volete

Bene, mi sembra che siamo giunti ad un punto chiarificatore: non è impossibile "ottimizzare" (nel senso in cui intende skizzo) per la singola gpu il fatto è che non è conveniente farlo perchè tale ottimizzazione sarebbe a carico della cpu e quindi troppo lenta.
E lo direbbe la stessa nvidia.

Sicuramente sembra non essere conveniente farlo in directx per i videogames.
Forse in opengl è diverso ed è uno dei motivi per cui i giochi si sono spostati tutti su architettura dx.

Notate i "sembra" ed i condizionali non per mettere in dubbio quanto dice yossarian ma per sottolineare che non vorrei aver capito male io.

Vorrei comunque ringraziare sia Yossarian che skizzo per questa discussione che a me sembra molto interessante.