Frame Rates for Half-Life 2

[yossarian]

Originariamente inviato da Vifani
E' stato pubblicato un articolo che spiega alcune cosette sul Source Engine. Forse può essere interessante leggerlo per coloro che seguono questo topic.

http://www.hwupgrade.it/articoli/1127/index.html

La tecnica del Radiosity Normal Mapping è implementata con ben 1920 diversi pixel shaders. Il più lungo conta 42 operazioni di tipo ALU e fino a sette texture fetches. Ogni cosa all’interno del Source Engine può essere eseguita in un singolo passaggio di rendering con pixel shaders 2.0 e con tre diversi passaggi con i pixel shaders 1.1.


questa è una delle operazioni in cui l'indipendenza di alu e tmu di R3x0 e R4x0 dà dei vantaggi anche a parità di clock.

Per il resto, nel confronto tra DX8 e DX9, si vede chiaramente come, nelle mappe che fanno uso di fp32 in modo più pesante (tipo canals), le prestazioni delle Fx crollino a valori pari a circa 1/4 di quelli ottenuti con ps1.x (come era lecito attendersi dalle considerazioni teoriche fatte). Nelle mappe che ricorrono ad un uso più bilanciato tra fp16 e fp32 si scende a circa 1/3, invece

[fek]

Originariamente inviato da Vifani
E' stato pubblicato un articolo che spiega alcune cosette sul Source Engine. Forse può essere interessante leggerlo per coloro che seguono questo topic.

http://www.hwupgrade.it/articoli/1127/index.html

Bell'articolo, Raffaele, e' impressionante come hai spiegato certi concetti piuttosto complessi in maniera semplice e immediata. Complimentoni.

Un solo piccolo appunto, se mi permetti, riguardo il motore di Doom3:

Eseguendo un rapido confronto con il motore di Doom III è immediatamente lampante la differente idea di base che ha spinto le due software house. John Carmak ha implementato un sistema di illuminazione dinamico in ogni sua parte ed ha completamente ignorato la componente ambientale. Il risultato è un motore grafico che da un lato mostra ombre dinamiche a tutto spiano e dall’altro produce un’immagine nera nelle zone non direttamente illuminate da alcuna fonte di luce (approccio fisicamente non corretto in quanto la componente ambientale è presente nella realtà, ma coerente con il resto del sistema di illuminazione).

Le zone in ombra appiaono nere non perche' e' stato ignorato il contributo ambientale, ma perche' il gamma e' molto basso, in altre parole e' tutto molto "scuro".

L'equazione di illuminazione di Doom3 e' qualcosa del tipo:

C = A + S1 * L1 + S2 * L2

Dove A, S1 * L1, S2 + L2 sono le diverse passate, A e' il contributo ambientale, S1 e L1 rispettivamente maschera per l'ombra e prima luce diffusiva e speculare.
C'e' in piu' una passata che inizializza lo zbuffer, ma non ci interessa ora.
Diciamo che una tipica "ottimizzazione visiva" e' non considerare l'assenza di luce come contributo zero, ma aggiungere una certa percentuale di componente diffusiva, di modo da non perdere tutti i dettagli della superficie. In Doom3 non e' stato fatto perche' tale shader non sarebbe stato visivamente compatibile con le implementazioni di classe DX8.

[Athlon 64 3000+]

Originariamente inviato da yossarian
La tecnica del Radiosity Normal Mapping è implementata con ben 1920 diversi pixel shaders. Il più lungo conta 42 operazioni di tipo ALU e fino a sette texture fetches. Ogni cosa all’interno del Source Engine può essere eseguita in un singolo passaggio di rendering con pixel shaders 2.0 e con tre diversi passaggi con i pixel shaders 1.1.


questa è una delle operazioni in cui l'indipendenza di alu e tmu di R3x0 e R4x0 dà dei vantaggi anche a parità di clock.

Per il resto, nel confronto tra DX8 e DX9, si vede chiaramente come, nelle mappe che fanno uso di fp32 in modo più pesante (tipo canals), le prestazioni delle Fx crollino a valori pari a circa 1/4 di quelli ottenuti con ps1.x (come era lecito attendersi dalle considerazioni teoriche fatte). Nelle mappe che ricorrono ad un uso più bilanciato tra fp16 e fp32 si scende a circa 1/3, invece

E come mai spiegi delle prestazioni così scadenti con L'NV40?
Ci macherebbe che abbia sbagliato a prendere la 6800GT,forse era meglio prendere la X800XT?

[fek]

Originariamente inviato da yossarian Ti ho chiesto più volte di spiegare come dovrebbe essere programmato un SW per esaltare le qualità di NV3x, ma continui a rispondere con frasi senza senso alcuno, glissando completamente su un'eventuale spiegazione.

Allineare le prestazioni e' dura anzi durissima. Diciamo che con un po' di accorgimenti, sfruttando molto i texture fetch e limitando le operazioni matematiche, limitando al minimo l'fp32 si riesce ad ottenere prestazioni con i ps2.0 decenti. E' un dato di fatto pero' che sono costretto a scalare molti effetti su NV3X, che su R3X0 mi girano quasi a pieno regime (non ci fossero le limitazioni varie del ps2.0 di mezzo) e mi girano ottimamente sul'NV40.
Proprio oggi ho dovuto scrivere tre versioni differenti dello stesso effetto di heat haze per le tre architetture. A quando un po' di convergenza nelle specifiche delle GPU?

[fek]

Originariamente inviato da andreamarra
C'è questo comando nel config, l'heat haze.

Francamente però ignoro cosa sia , chi lo spiega ?

Eccomi! Sono fresco fresco sull'argomento
E' la simulazione della distorsione della luce provocato dall'aria ad alta temperature, ad esempio riscaldata dal fuoco.

Stringi stringi si riduce a distorcere il la scena dietro il fuoco e applicare un po' di blur.

[Athlon 64 3000+]

Originariamente inviato da fek
Allineare le prestazioni e' dura anzi durissima. Diciamo che con un po' di accorgimenti, sfruttando molto i texture fetch e limitando le operazioni matematiche, limitando al minimo l'fp32 si riesce ad ottenere prestazioni con i ps2.0 decenti. E' un dato di fatto pero' che sono costretto a scalare molti effetti su NV3X, che su R3X0 mi girano quasi a pieno regime (non ci fossero le limitazioni varie del ps2.0 di mezzo) e mi girano ottimamente sul'NV40.
Proprio oggi ho dovuto scrivere tre versioni differenti dello stesso effetto di heat haze per le tre architetture. A quando un po' di convergenza nelle specifiche delle GPU?

Come va L'NV40 con i ps 2.0(e se è FP16 o FP32) che stai facendo per Black and White 2?
Spero che riesca a capire la domanda.

[Vifani]

Originariamente inviato da fek
Bell'articolo, Raffaele, e' impressionante come hai spiegato certi concetti piuttosto complessi in maniera semplice e immediata. Complimentoni.

Un solo piccolo appunto, se mi permetti, riguardo il motore di Doom3:



Le zone in ombra appiaono nere non perche' e' stato ignorato il contributo ambientale, ma perche' il gamma e' molto basso, in altre parole e' tutto molto "scuro".

L'equazione di illuminazione di Doom3 e' qualcosa del tipo:

C = A + S1 * L1 + S2 * L2

Dove A, S1 * L1, S2 + L2 sono le diverse passate, A e' il contributo ambientale, S1 e L1 rispettivamente maschera per l'ombra e prima luce diffusiva e speculare.
C'e' in piu' una passata che inizializza lo zbuffer, ma non ci interessa ora.
Diciamo che una tipica "ottimizzazione visiva" e' non considerare l'assenza di luce come contributo zero, ma aggiungere una certa percentuale di componente diffusiva, di modo da non perdere tutti i dettagli della superficie. In Doom3 non e' stato fatto perche' tale shader non sarebbe stato visivamente compatibile con le implementazioni di classe DX8.

Grazie mille per i complimenti fek. Secondo le mie fonti (interviste, forum di Beyond3D, ecc...) il contributo ambientale in Doom III non c'è proprio. Con le stencil shadows il contributo ambientale dovrebbe essere fatto nella prima passata, insieme all'inizializzazione dello zbuffer, mentre Carmak nella prima passata non scrive proprio nel frame buffer. L'immagine rimane nera così come è stata inizializzata alla cancellazione del frame buffer.

[MaBru]

Originariamente inviato da Pat77
Bhe diciamo che nvidia c'ha provato con CG (come del resto fece 3dfx con glide), e i presupposti, prima dell'uscita di Fx per sfondare c'erano tutti.

CG è un linguaggio ad alto livello, GLide una API. Dove sta il nesso?

[fek]

Originariamente inviato da Vifani
Grazie mille per i complimenti fek. Secondo le mie fonti (interviste, forum di Beyond3D, ecc...) il contributo ambientale in Doom III non c'è proprio. Con le stencil shadows il contributo ambientale dovrebbe essere fatto nella prima passata, insieme all'inizializzazione dello zbuffer, mentre Carmak nella prima passata non scrive proprio nel frame buffer. L'immagine rimane nera così come è stata inizializzata alla cancellazione del frame buffer.

A quanto pubblicato da Carmack in vari post sui forum tecnici, lui parla esplicitamente di una passata per lo zbuffer e una per la luce ambiente, il che pare coerente col fatto che letteralmente tutti abbiamo fatto la stessa cosa

[fek]

Originariamente inviato da Athlon 64 3000+
Come va L'NV40 con i ps 2.0(e se è FP16 o FP32) che stai facendo per Black and White 2?
Spero che riesca a capire la domanda.

Uso un NV40 nella macchina principale e non ho mai avuto alcun problema, e' la mia scheda di riferimento quando lavoro.
Sul muletto mi hanno montato oggi una 9600 perche' dicono che scrivo shader troppo pesanti e mi vogliono costringere ad usare una gpu piu' lenta... bah

Al momento sto lavorando su un framework di post processing e compositing video: praticamente una cosa simile a quello che accade nell'industria cinematografica nella fase di compositing finale, quando si applicano effetti 2d al film (tipo per ricreare scene di notte a partire da scene girate in pieno giorno). Fra i vari effetti di post processing sto lavorando su cose tipo heat haze, depth of field, blooming...

[MaBru]

Originariamente inviato da fek
CUT

Che combina Alex con il radiosity?

[Vifani]

Originariamente inviato da fek
A quanto pubblicato da Carmack in vari post sui forum tecnici, lui parla esplicitamente di una passata per lo zbuffer e una per la luce ambiente, il che pare coerente col fatto che letteralmente tutti abbiamo fatto la stessa cosa

Bene, ma non capisco perché non le faccia entrambe all'inizio.

In ogni caso il termine "ignorato" all'interno dell'articolo sta più che altro a significare "non curato". Rispetto all'implementazione del Source Engine intendo.

Comunque, che te ne pare del Source Engine? Secondo me alcune soluzioni sono davvero interessanti. Quella del Radiosity Normal Mapping è stata una vera genialata anche se effettivamente io preferisco gli approcci dinamici a quelli statici per la generazione dell'illuminazione.

[MaBru]

Originariamente inviato da Vifani
Quella del Radiosity Normal Mapping è stata una vera genialata anche se effettivamente io preferisco gli approcci dinamici a quelli statici per la generazione dell'illuminazione.

Come resa finale negli interni HL2 imho è superiore a Doom3, luce dinamica o no. Poi giudicare l'engine di D3 da come è usato in un gioco così scuro è fuorviante. Qualcosa di più preciso si potrà dire con Quake 4 o RTCW2.

[Vifani]

Originariamente inviato da MaBru
Come resa finale negli interni HL2 imho è superiore a Doom3, luce dinamica o no. Poi giudicare l'engine di D3 da come è usato in un gioco così scuro è fuorviante. Qualcosa di più preciso si potrà dire con Quake 4 o RTCW2.

Si... sono molto curioso di vedere la flessibilità di quel motore. Secondo me è molto ridotta però... chissà che non mi sbagli. Io per le schede più veloci farei estrudere la geometria completamente via vertex shader... anche se il numero di poligoni da trattare aumenterebbe moltissimo, penso che R420 e NV40 siano in grado di farlo velocemente.

[MaBru]

Originariamente inviato da Vifani
Io per le schede più veloci farei estrudere la geometria completamente via vertex shader...

Come fa il motore di Riddick.

[yossarian]

Originariamente inviato da Athlon 64 3000+
E come mai spiegi delle prestazioni così scadenti con L'NV40?
Ci macherebbe che abbia sbagliato a prendere la 6800GT,forse era meglio prendere la X800XT?

non è che le prestazioni con NV40 siano scadenti; Nv40 ha dei limiti, così come R420; uno shader piuttosto complesso che prevede l'utilizzo contemporaneo di texture fetch e di calcoli alu penalizza NV40 in misura maggiore di quanto non faccia con R420: questo perchè NV40 ha ereditato (unico aspetto negativo) la dipendenza prima fpu e tmu; questo significa che la prima unità di calcolo di NV40 è in grado di eseguire sia calcoli matematici che operazioni sulle texture, però non tutti e due nello stesso ciclo. Al contrario, R420, come anche R300, hanno alu e tmu separate, perciò hanno la possibilità di eseguire entrambi i tipi di calcolo nello stesso ciclo. Evidentemente gli algoritmi di illuminazione e quello relativo all'acqua (riflessioni, rifrazioni, ecc) sono tra i più complessi di HL2 e sono tra quelli in cui sono richieste texture fetch e operazioni matematiche in contemporanea: in questo tipo di calcoli sono avvantaggiati i chip ATi (prprio a livello di numero di istruzioni per ciclo, quindi indipendentemente dalla frequenza di lavoro). Non è un caso che le prestazioni peggiori, NV40 le mostri nella mappa "canals". Non è da escudere che, nei prossimi mesi, i tecnici nVIDIA lavoreranno sul riordino delle istruzioni per cercare di minimizzare il gap dovuto alla dipendenza delle unità di calcolo.
Diciamo che nel progettare il loro engine, quelli di Valve si sono preoccupati poco dell'architettura dei chip NV (come del resto ha fatto Carmack con Doom3 e i chip ATi); quindi stai tranquillo: hai fatto un buon acquisto, come lo avresti fatto se avessi preso una vga con R420.

[fek]

Originariamente inviato da Vifani
Bene, ma non capisco perché non le faccia entrambe all'inizio.

In ogni caso il termine "ignorato" all'interno dell'articolo sta più che altro a significare "non curato". Rispetto all'implementazione del Source Engine intendo.

Comunque, che te ne pare del Source Engine? Secondo me alcune soluzioni sono davvero interessanti. Quella del Radiosity Normal Mapping è stata una vera genialata anche se effettivamente io preferisco gli approcci dinamici a quelli statici per la generazione dell'illuminazione.

Sono d'accordo con te.
A livello di cura dei materiali il Source ha davvero degli ottimi shader, ma l'impostazione generale mi sembra ancora troppo legata al passato: diciamo che ci si sta muovendo nella direzione opposta. E' tutto troppo statico, le ombre sono appena abbozzate e a mio avviso un sistema di ombre dinamico e' un must. Occhio che su questo punto non tutti i programmatori 3d la pensano allo stesso modo.
Sicuramente e' molto leggero, ma non ci credo che non sia possibile forzare l'fp16 per le gpu nvidia. Sarebbe un errore troppo marchiano che un simile team di sviluppo non farebbe.

In sintesi: anch'io preferisco gli approggi dinamici e non vado matto per le lightmap.

[fek]

Originariamente inviato da Vifani
Si... sono molto curioso di vedere la flessibilità di quel motore. Secondo me è molto ridotta però... chissà che non mi sbagli. Io per le schede più veloci farei estrudere la geometria completamente via vertex shader... anche se il numero di poligoni da trattare aumenterebbe moltissimo, penso che R420 e NV40 siano in grado di farlo velocemente.

Io per le schede veloci eviterei totalmente le stencil shadow
Estrudere nel vertex shader e' una manciata di istruzioni e funziona benissimo con geometria non animata. Con geometria animata i problemi iniziano ad essere enormi, non ho trovato una soluzione decente e mi sono buttato sullo shadow mapping. A quanto ho letto in giro, non esiste una soluzione ottima e praticabile a quel problema.

[yossarian]

Originariamente inviato da fek
Allineare le prestazioni e' dura anzi durissima. Diciamo che con un po' di accorgimenti, sfruttando molto i texture fetch e limitando le operazioni matematiche, limitando al minimo l'fp32 si riesce ad ottenere prestazioni con i ps2.0 decenti. E' un dato di fatto pero' che sono costretto a scalare molti effetti su NV3X, che su R3X0 mi girano quasi a pieno regime (non ci fossero le limitazioni varie del ps2.0 di mezzo) e mi girano ottimamente sul'NV40.
Proprio oggi ho dovuto scrivere tre versioni differenti dello stesso effetto di heat haze per le tre architetture. A quando un po' di convergenza nelle specifiche delle GPU?

lo so; infatti la domanda era retorica (maliziosa e tendenziosa ). Anche perchè sfruttare molto le texture fetch e ridurre al minimo i calcoli matematici in fp (soprattutto fp32) non è un approccio tipico da chip DX9 compliant come NV3x dovrebbe essere. Si tratta di operazioni che (sostituendo i pochi calcoli in fp presenti con ps1.x) potrebbero essere utilizzati anche per un qualunque chip DX8.x.
La convergenza nelle specifiche dele GPU ci sarebbe se i produttori si attenessero alle API di riferimento e fossero meno "creativi". Ci sarebbe più appiattimento nelle prestazioni, però sicuramente voi dovreste lavorare di meno e qualche compratore prenderebbe qualche fregatura in meno.
Ho l'impressione, però, che con l'architettura unificata di ps e vs ci sarà molto meno spazio per l'estro di qualcuno (almeno a livello di tipologia di unità di calcolo; purtroppo ci si potrà sempre sbizzarrire con i tipi di connessione tra unità, con la quantità e il tipo di cache interne e con troppi altri parametri, per essere sicuri che nessuno avrà future alzate d'ingegno)

[yossarian]

Originariamente inviato da fek
Sono d'accordo con te.
A livello di cura dei materiali il Source ha davvero degli ottimi shader, ma l'impostazione generale mi sembra ancora troppo legata al passato: diciamo che ci si sta muovendo nella direzione opposta. E' tutto troppo statico, le ombre sono appena abbozzate e a mio avviso un sistema di ombre dinamico e' un must. Occhio che su questo punto non tutti i programmatori 3d la pensano allo stesso modo.
Sicuramente e' molto leggero, ma non ci credo che non sia possibile forzare l'fp16 per le gpu nvidia. Sarebbe un errore troppo marchiano che un simile team di sviluppo non farebbe.

In sintesi: anch'io preferisco gli approggi dinamici e non vado matto per le lightmap.

io sono convinto che sia possibile forzare l'fp16; il problema è: chi ci guadagnerebbe?
Sia NV3x che NV4x non trarrebbero grandi vantaggi, per opposti motivi: NV3x non è brillante neppure con la pp, soprattutto nella gestione di shader lunghi e complessi; NV40 gestisce piuttosto bene anche fp32 (certo, dall'utilizzo di fp16 avrebbe comunque qualche fps in più e la cosa non guasterebbe ma neanche rivoluzionerebbe le prestazioni)