Frame Rates for Half-Life 2

[Vifani]

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

Però lo shadow mapping... non so a voi, ma le ombre del 3DMark05 a me non piacciono poi così tanto. L'aliasing regna sovrano oltre ai vari difetti qua e la (a seconda dell'angolazione delle normali, ecc....). E poi per le luci puntiformi omnidirezionali le shadowmap sono pesantissime... una cube shadow map è pesantissima da calcolare.

[yossarian]

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

cioè tutti utilizzate la prima passata solo per scrivere valori nello z-buffer? (scusa ma, come sai, la programmazione non è proprio il mio campo e sto cercando di capirci qualcosa)

[Banus]

Originariamente inviato da yossarian
cioè tutti utilizzate la prima passata solo per scrivere valori nello z-buffer? (scusa ma, come sai, la programmazione non è proprio il mio campo e sto cercando di capirci qualcosa)

Se non ho capito male (le stencil non le ho mai implementate) si fa una z-pass, si effettua lo z-test sui poligoni dello shadow volume scrivendo i valori sullo stencil buffer (prima passata). A questo punto si renderizza la scena, applicando la componente ambientale solo dove c'è ombra, controllando lo stencil buffer (stencil-test). Inoltre lo z-buffer non è stato cancellato e quindi è possibile non renderizzare a priori i pixel nascosti. (seconda passata). A questo punto applica la componente diffusa e speculare solo dove non c'è ombra, con un altro stencil test (terza passata). Ulteriori due passate e due bit sullo stencil buffer per ogni luce in grado di produrre ombre.
Vifani saprà darti qualche dettaglio in più dal momento che ha programmato una demo sulle stencil

[Athlon 64 3000+]

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

Non riesco a percepire per bene il tuo discorso riguardo l'NV40 con la velocità di utilizzo in fp16 e fp32.

[fek]

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

Io ti posso dire che in genere scrivo tutti gli shader in fp32 e poi, quando ho ottenuto l'effetto, scalo a fp16 tutto quello che posso e guadagno, mediamente, un 20/30% sia su NV3X sia su NV40. Mi sembra solo un po' forzato effettuare i benchmark di HL2 in fp32 e riportare che le NV3X non sono all'altezza: beh, e' ovvio.
Oddio, suono come un fanboy, la riformulo
Io avrei scalato tutto il possibile a fp16, dato in pasto al mercato delle NV3X degli shader ragionevoli e poi concluso che non sono comunque all'altezza, ma dopo un "fair test".
Sarebbe come ottimizzare qualcosa ed eseguire il profiling in debug invece che in release: i risultati che ne escono non hanno alcun valore.

Originariamente inviato da Vifani
Però lo shadow mapping... non so a voi, ma le ombre del 3DMark05 a me non piacciono poi così tanto. L'aliasing regna sovrano oltre ai vari difetti qua e la (a seconda dell'angolazione delle normali, ecc....). E poi per le luci puntiformi omnidirezionali le shadowmap sono pesantissime... una cube shadow map è pesantissima da calcolare.

Lo shadow mapping ha sicuramente problemi di aliasing ancora: i sample devono essere filtrati e poi qualche tecnica per "smussare" ulteriormente i contorni (filtri stocastici o blur basato sulla distanza dalla luce). Il punto e' che lo shadow mapping e' molto scalabile: aumenta il fillrate e linearmente aumenta la qualita' delle ombre, quindi per high end e per i motori futuri e' preferibile. Le stencil shadow sono fisse: quella e' la qualita' sempre e comunque e non e' banale migliorarla. Inoltre hanno enormi problemi con la geometria che usa alpha testing (immagina gli alberi), richiedono l'intervento della CPU per la geometria animata, e' una tecnica inerentemente multi pass. Bilanciando i pro e i contro, si stanno tutti muovendo sulle shadow map.

Le omni light, alla fine, sono paradossalmente piu' veloci di una directional light
E' vero che vanno renderizzate 6 facce di una cube map, ma e' anche vero che in queste sei facce il numero di oggetti e' di solito davvero esiguo: un buon algoritmo di rimozione degli oggetti nascosti risolve il problema. Mi sono trovato molto bene tanto che il mio primo tentativo con le shadow map e' stato proprio con omni light. I problemi nascono con le luci direzionali (perspective shadow mapping), ma la teoria sta facendo passi da gigante in questa direzione e nel giro di un paio d'anni dovrebbe essere una tecnica consolidata.

[fek]

Originariamente inviato da yossarian
cioè tutti utilizzate la prima passata solo per scrivere valori nello z-buffer? (scusa ma, come sai, la programmazione non è proprio il mio campo e sto cercando di capirci qualcosa)

Dipende, non e' sempre conveniente.
In pratica si sta pagando il risparmio di fillrate con della geometria; il prezzo vale la candela quando il pixel shader e' molto complesso e l'overdraw della scena e' molto alto. In queste condizioni, una prima passata sullo zbuffer e tecniche come lo ZCull (o HyperZ), permettono di eseguire lo shader complesso strettamente (quasi) una volta per pixel, invece che piu' volte per pixel in situazioni di alto over draw.

(In altre parole, secondo me in Doom3 non conviene )

[yossarian]

Originariamente inviato da Athlon 64 3000+
Non riesco a percepire per bene il tuo discorso riguardo l'NV40 con la velocità di utilizzo in fp16 e fp32.

guarda anche la risposta di fek poco più in basso; con un guadagno del 20-30% su 8/10 fps (comr visto in canals che fa uso di shader fp32 complessi), per NV3x le cose non cambierebbero più di tanto.
NV40, invece, qualcosa guadagnerebbe, anche se, in fin dei conti, l'ultimo chip NV riesce a gestire piuttosto bene anche fp32.
Il calo vistoso in "canals" dipende dall'uso di fp32 e dalla dipendenza tra alu e tmu; l'impatto del primo si può minimizzare con il ricorso, dove possibile a fp16

[Athlon 64 3000+]

Ti chiedo come mai in alcuni benchmark additittura la 6800Ultra scende a livelli della 9800XT?
Sicuramente incide la dipendenza tra alu e Tmu(e di fatto l'R420 è superiore)ma non capisco come può andare a livello di una scheda con 8 pipeline e che ha in fill-rate che è la metà.

[yossarian]

Originariamente inviato da fek
Io ti posso dire che in genere scrivo tutti gli shader in fp32 e poi, quando ho ottenuto l'effetto, scalo a fp16 tutto quello che posso e guadagno, mediamente, un 20/30% sia su NV3X sia su NV40. Mi sembra solo un po' forzato effettuare i benchmark di HL2 in fp32 e riportare che le NV3X non sono all'altezza: beh, e' ovvio.
Oddio, suono come un fanboy, la riformulo
Io avrei scalato tutto il possibile a fp16, dato in pasto al mercato delle NV3X degli shader ragionevoli e poi concluso che non sono comunque all'altezza, ma dopo un "fair test".
Sarebbe come ottimizzare qualcosa ed eseguire il profiling in debug invece che in release: i risultati che ne escono non hanno alcun valore.

è propri qui che volevo arrivare; un guadagno del 20-30% su una media di 8/10 fps (o giù di li) come visto nella mappa "canals" che fa uso di shader fp32 complessi non cambierebbe la vita per NV3x. L'unico che parzialmente se ne gioverebbe e NV40 (che però riesce a "trattre" piuttosto bene anche fp32).
Capisco il tuo discorso e non è escluso che Valve abbia tentato una strada del genere. Magari facendo come dice avrebbe evitato di fare la figura di chi abbia deciso, per partito preso di boicottare le serie NV3x. Però, da tecnico del settore, ti rendi conto tu stesso della scarsa utilità della cosa.

[yossarian]

Originariamente inviato da Athlon 64 3000+
Ti chiedo come mai in alcuni benchmark additittura la 6800Ultra scende a livelli della 9800XT?
Sicuramente incide la dipendenza tra alu e Tmu(e di fatto l'R420 è superiore)ma non capisco come può andare a livello di una scheda con 8 pipeline e che ha in fill-rate che è la metà.

perchè in quei test viene fatto anche uso massiccio di shader fp32 complessi (con cui tutti i chip, anche R420, NV40, R3x0, nati per gestire sm2.0) accusano una perdita di circa il 40/50%; in più aggiungi che NV40 perde un'ulteriore percentuale a causa del fatto che i calcoli in fp32 in qualche modo incidono negativamente sulle prestazioni (specie in presenza di texture fetch in contemporanea). Diciamo che al calo dovuto alla dipendenza tra tmu e alu devi aggiungere circa un ulteriore 15-20% dovuto all'uso di fp32 (rispetto a fp24di ATi)

[Athlon 64 3000+]

Originariamente inviato da yossarian
è propri qui che volevo arrivare; un guadagno del 20-30% su una media di 8/10 fps (o giù di li) come visto nella mappa "canals" che fa uso di shader fp32 complessi non cambierebbe la vita per NV3x. L'unico che parzialmente se ne gioverebbe e NV40 (che però riesce a "trattre" piuttosto bene anche fp32).
Capisco il tuo discorso e non è escluso che Valve abbia tentato una strada del genere. Magari facendo come dice avrebbe evitato di fare la figura di chi abbia deciso, per partito preso di boicottare le serie NV3x. Però, da tecnico del settore, ti rendi conto tu stesso della scarsa utilità della cosa.

Altra cosa che mi interessa sapere è:
Nella demo canals si fa uso di shader fp32 e dici che scaldando a fp16 NV40 ne gioverebbe parzialmente e poi ti chiedo cosa intendi che riesce a "trattare" piuttosto bene anche shader fp32?
Scusami magari se non mi sono espresso bene ma non sono mai stato molto bravo a spiegarmi bene.

[Athlon 64 3000+]

Originariamente inviato da yossarian
perchè in quei test viene fatto anche uso massiccio di shader fp32 complessi (con cui tutti i chip, anche R420, NV40, R3x0, nati per gestire sm2.0) accusano una perdita di circa il 40/50%; in più aggiungi che NV40 perde un'ulteriore percentuale a causa del fatto che i calcoli in fp32 in qualche modo incidono negativamente sulle prestazioni (specie in presenza di texture fetch in contemporanea). Diciamo che al calo dovuto alla dipendenza tra tmu e alu devi aggiungere circa un ulteriore 15-20% dovuto all'uso di fp32 (rispetto a fp24di ATi)

Quindi se ho capito bene è per questo motivo che una 6800Ultra in quel particolare caso va come una 9800XT?

[yossarian]

Originariamente inviato da Athlon 64 3000+
Quindi se ho capito bene è per questo motivo che una 6800Ultra in quel particolare caso va come una 9800XT?

si; NV40, al contrario di NV3x (che non va d'accordo con i calcoli in fp e che, in particolare, con fp32 è un "chiodo"), can lo sm2.0, anche con fp32 ha una resa più che buona. Va da sé che, anche per un ottimo chip come NV40, fp32 è sicuramente un po' più pesante da gestire di quanto non lo sia fp24 e ancora di più fp16; questo soprattutto in presenza di altri tipi di calcoli in contemporanea (nell'esecuzione dei soli calcoli matematici, dai bench sintetici si vede chiaramente che NV40 gestisce fp16 e fp32 con la stessa disinvoltura con cui gestisce i calcoli in fx: questo dimostra che non è afflitto dai problemi evidenziati dalla precedente generazione).

[fek]

Originariamente inviato da yossarian
è propri qui che volevo arrivare; un guadagno del 20-30% su una media di 8/10 fps (o giù di li) come visto nella mappa "canals" che fa uso di shader fp32 complessi non cambierebbe la vita per NV3x. L'unico che parzialmente se ne gioverebbe e NV40 (che però riesce a "trattre" piuttosto bene anche fp32).
Capisco il tuo discorso e non è escluso che Valve abbia tentato una strada del genere. Magari facendo come dice avrebbe evitato di fare la figura di chi abbia deciso, per partito preso di boicottare le serie NV3x. Però, da tecnico del settore, ti rendi conto tu stesso della scarsa utilità della cosa.

Francamente non la trovo di scarsa utilita'. Tu sai meglio di me, perche' nel tuo campo e' ancora piu' importante che nel mio, che non ha senso usare un cannone per uccidere una mosca, si usano gli strumenti adeguati a risolvere il problema.
Se uno shader e' computazionalmente esattamente identico in fp16 perche' usare fp32? Non c'e' alcun motivo logico dal punto di vista ingegneristico, ed un programmatore alla Valve, che sicuramente ne sa, non farebbe mai un errore simile.

Non voglio accusare nessuno di niente, mi limito a constatare l'ovvio, che qualcosa di strano c'e'.

[R@nda]

Leggete qui....un pò macchinoso e alla carlona,però funziona.
Renderizza tutto correttamente e senza mancanze e artefatti.

http://forum.hwupgrade.it/showthread...hreadid=824334

[Athlon 64 3000+]

Originariamente inviato da yossarian
perchè in quei test viene fatto anche uso massiccio di shader fp32 complessi (con cui tutti i chip, anche R420, NV40, R3x0, nati per gestire sm2.0) accusano una perdita di circa il 40/50%; in più aggiungi che NV40 perde un'ulteriore percentuale a causa del fatto che i calcoli in fp32 in qualche modo incidono negativamente sulle prestazioni (specie in presenza di texture fetch in contemporanea). Diciamo che al calo dovuto alla dipendenza tra tmu e alu devi aggiungere circa un ulteriore 15-20% dovuto all'uso di fp32 (rispetto a fp24di ATi)

Lo riprendo un'attimo scusami magarii se sono un po' ripetitivo e concludo dicendo che è per il motovo che che c'è scritto qui sopra il perchè una 9800XT va come una 6800Ultra in quel particolare benchmark.
Con future realease di driver potra migliorare la situazione? almeno da far diventare NV40 più veloce almeno della 9800XT

[leoneazzurro]

Originariamente inviato da yossarian
si; NV40, al contrario di NV3x (che non va d'accordo con i calcoli in fp e che, in particolare, con fp32 è un "chiodo"), can lo sm2.0, anche con fp32 ha una resa più che buona. Va da sé che, anche per un ottimo chip come NV40, fp32 è sicuramente un po' più pesante da gestire di quanto non lo sia fp24 e ancora di più fp16; questo soprattutto in presenza di altri tipi di calcoli in contemporanea (nell'esecuzione dei soli calcoli matematici, dai bench sintetici si vede chiaramente che NV40 gestisce fp16 e fp32 con la stessa disinvoltura con cui gestisce i calcoli in fx: questo dimostra che non è afflitto dai problemi evidenziati dalla precedente generazione).

Scusa Yoss, ma se il calo fosse del 30% non mi sarei stupito più di tanto, qui si parla di più del 50%! A 1024x768 senza filtri, oltretutto.
Per quanto si possa esser limitati dall'architettura e dagli FP 32 mi aspetterei prestazioni perlomeno un attimino più elevate. Almeno più di una 9800XT. Sembra come non solo si siano scritti gli shader senza pensare a NV 40, ma persino nella maniera peggiore di come potessero essere scritti....

[Athlon 64 3000+]

Originariamente inviato da leoneazzurro
Scusa Yoss, ma se il calo fosse del 30% non mi sarei stupito più di tanto, qui si parla di più del 50%! A 1024x768 senza filtri, oltretutto.
Per quanto si possa esser limitati dall'architettura e dagli FP 32 mi aspetterei prestazioni perlomeno un attimino più elevate. Almeno più di una 9800XT. Sembra come non solo si siano scritti gli shader senza pensare a NV 40, ma persino nella maniera peggiore di come potessero essere scritti....

Anche a me questa situazione non mi va proprio giù,perchè mi sembra veramente troppo assurdo.Capisco che L'R420 sia più veloce ma non da arrivare a R360.

[yossarian]

Originariamente inviato da fek
Francamente non la trovo di scarsa utilita'. Tu sai meglio di me, perche' nel tuo campo e' ancora piu' importante che nel mio, che non ha senso usare un cannone per uccidere una mosca, si usano gli strumenti adeguati a risolvere il problema.
Se uno shader e' computazionalmente esattamente identico in fp16 perche' usare fp32? Non c'e' alcun motivo logico dal punto di vista ingegneristico, ed un programmatore alla Valve, che sicuramente ne sa, non farebbe mai un errore simile.

Non voglio accusare nessuno di niente, mi limito a constatare l'ovvio, che qualcosa di strano c'e'.

hai ragione, anzi nel mio campo si ha spesso il problema della "coperta corta".
Non conosco a fondo il motore di HL2 per sapere che tipo di shader sono stati usati; stando ai test postati da Raffaele, però, è evidente che gli shader della mappa "prison" sono molto meno complessi degli altri, il che farebbe pensare, se veramente fossero in fp32 anche questi, alla possibilità di sostituirli con fp16. E d'altra parte, non credo che non ci sia la possibilità di utilizzare una path dx9 ed effettuare, la dove possibile, shader replacement, scendendo anche fino ai ps1.x.
Certo che se Valve dovesse aver utilizzato, per la path dx9, solo fp32 avrebbe commesso un errore piuttosto grossolano (se di errore si è trattato).
Non si tratta di accusare o meno qualcuno, però, in effetti, sembra che ID e Valve abbiano operato scelte progettuali un po' strane e fuori dai canoni per non destare qualche sospetto.
Tu stesso hai detto, in precedenza, che nel caso specifico di Doom3 l'algoritmo di rendering adoperato da Carmack non è conveniente. La penso allo stesso modo e, da quello che ha scritto, pare che anche Raffaele sia di questa idea. L'unica cosa che può venire in mente è che quel particolare ordine di rendering conviene alle GeForce che, in presenza di soli calcoli relativi allo z-buffer, raddoppiano il pixel fillrate. Questo, di fatto, considerate anche le maggiori frequenze operative, annulla il gap tra NV3x e R3x0 e dà un buon margine di vantaggio a NV40 (nonostante le frequenze inferiori rispetto a R420).
Scelta opposta pare essere stata operata da Valve: un uso smodato e ridondante di fp32, anche dove non fosse necessario, avrebbe lo scopo (non dichiarato) di abbattere ulteriormente le prestazioni di una famiglia di chip (NV3x) che non ha molta dimestichezza con lo sm2.0, giustificandone il declassamento a chip DX8.x.
IMHO, HL2 e Doom3 rappresentano due facce della stessa medaglia: scelte progettuali opposte dettate, evidentemente, non solo da scelte tecniche "particolari" ma da alleanze politiche e di marketing

[yossarian]

Originariamente inviato da leoneazzurro
Scusa Yoss, ma se il calo fosse del 30% non mi sarei stupito più di tanto, qui si parla di più del 50%! A 1024x768 senza filtri, oltretutto.
Per quanto si possa esser limitati dall'architettura e dagli FP 32 mi aspetterei prestazioni perlomeno un attimino più elevate. Almeno più di una 9800XT. Sembra come non solo si siano scritti gli shader senza pensare a NV 40, ma persino nella maniera peggiore di come potessero essere scritti....

se ti ricordi, ne abbiamo parlato anche su nV Italia; io continuo a poensarla sempre alla stessa maniera: sia ID che Valve hanno progettato i loro engine pensando a come "far dispetto al rivale" (ATi e nVIDIA rispettivamente). Sicuramente gli shader di HL2 sono quanto di più indigesto possibile si possa concepire per l'architettura delle GeForce e, sicuramente, sono stati scritti in modo da massimizzare il problema della dipendenza tra alu e tmu, perchè il calo di NV40 è troppo elevato da essere giustificato dal solo utilizzo di fp32. Gli shader della mappa "canals" sono sicuramente complessie piuttosto lunghi: questo dovrebbe provocare (come in effetti avviene) un abbattimento delle prestazioni di tutti i chip. Solo che quelli delle ATi sono più contenuti, vuoi per l'utilizzo di fp24, vuoi per capacità di eseguire più istruzioni per ciclo grazie all'indipendenza tra alu e tmu (le 12 pipeline della X800 pro, in una situazione del genere, risultano più veloci delle 16 della 6800 ultra avendo un vantaggio di 4 operazioni per ciclo di clock che diventano 16 se il confronto si fa con le 16 pipeline della X800XT).