Shader 3.0 o Shader 2.0

[fek]

Originariamente inviato da DjLode
Considera la differenza tra calcolare (uno ad uno) e disegnare 100 steli d'erba e calcolarne uno e disegnarlo 100 volte.

In entrambi i casi "calcoli" 100 steli d'erba, ma facendo geometry instancing li spedisci alla GPU tutti in un solo colpo, piuttosto che uno alla volta, il che migliora notevolmente le prestazioni sotto D3D.
Il punto e' che non serve certo l'SM3.0 per fare geometry instancing, che si puo' fare piu' che decentemente anche con una scheda DX7.

In altre parole: occhio che quelli di FarCry sboronano grosso.

Ma infatti non sta scritto che con i PS2 non si possono calcolare più di una luce. Dice che ne calcolano 3/4 (poi da dimostare ) con una sola passata, invece che una con una sola passata (3/4 in 3/4 passate). Quindi qualitativamente uguale (stesso numero di luci) ma magari più veloce (e ripeto poi c'è da dimostrare di quanto).

I casi in cui si puo' ottenere un beneficio prestazionale usando l'SM3.0 sono molto rari al giorno d'oggi. Anche nel caso delle luci, le condizioni in cui si puo' ottenere un effettivo beneficio e si e' costretti ad usare il dynamic branching per ottenerlo sono praticamente nulle.

[Alberto Falchi]

Originariamente inviato da fek
In entrambi i casi "calcoli" 100 steli d'erba, ma facendo geometry instancing li spedisci alla GPU tutti in un solo colpo, piuttosto che uno alla volta, il che migliora notevolmente le prestazioni sotto D3D.
Il punto e' che non serve certo l'SM3.0 per fare geometry instancing, che si puo' fare piu' che decentemente anche con una scheda DX7.

Non sono un programmatore, quindi potrei dire una sciocchezza, ma credo che l'instancing utilizzato in FC si basi sui salti condizionati, possibili solamente cn lo SM3. Sono in ogni caso certo che non lo puoi fare con le DX7. O meglio, puoi fare l'instancing di un oggetto, ma non certo di uno shader, visto che sono supportati solo dalle 8 in su.

Pape

[fek]

Originariamente inviato da GMCPape
Non sono un programmatore, quindi potrei dire una sciocchezza, ma credo che l'instancing utilizzato in FC si basi sui salti condizionati, possibili solamente cn lo SM3. Sono in ogni caso certo che non lo puoi fare con le DX7. O meglio, puoi fare l'instancing di un oggetto, ma non certo di uno shader, visto che sono supportati solo dalle 8 in su.

Pape

Per la precisione si basa sul Vertex Stream Frequency che e' supportato solo con VS3.0.

L'idea e' quella di mettere la geometria di un oggetto in memoria video una volta sola e poi, impostrato lo stream frequency, mettere in memoria tutte le posizioni nelle quali disegnare l'oggetto.

Ma questo e' solo un modo (per altro efficiente) di fare geometry instancing.
Si puo' anche fare geometry instancing semplicemente copiando mano a mano ogni copia dell'oggetto nella posizione finale e scrivendoli in un buffer dinamico da mandare alla GPU ogni frame. Usa piu' CPU del metodo precedente ma funziona letteralmente con qualunque GPU sul pianeta.
E nel caso dell'erba (in generale con oggetti di pochi poligoni)basta e avanza.

[MaBru]

Originariamente inviato da fek
[...]Ma questo e' solo un modo (per altro efficiente) di fare geometry instancing[...]

Sul forum di Beyond3d si mormora che l'R420 supporti il vertex instancing? Che è?

[fek]

Originariamente inviato da MaBru
Sul forum di Beyond3d si mormora che l'R420 supporti il vertex instancing? Che è?

E' un altro nome del Geometry Instancing.

Francamente ho cercato per un buon pomeriggio per vedere se l'R420 lo supporta e mi sembra di no. Poi i doc delle D3D affermano esplicitamente che richiede i VS3.0.
Magari quando ho un po' di tempo e riesco a mettere le mani sullo Shuttle ci riprovo. Sulla mia macchina ho un NV40 e il geometry instancing funziona.

[REPSOL]

Ohhhh eccolo il nostro fek che ci spolpa nozioni manco fosse un programmatore di black and white......... OPS

[Milotto]

Francamente non si capisce più un C***o.....
Questo è il link del sito di un utente very skilled di beyond3D , potete trovarci un demo che esegue dynamic branching senza la necessità dello S.M. 3.0 , ovvero su un hardware con S.M. 2.0...
http://esprit.campus.luth.se/~humus/



CIAO

[MaBru]

Originariamente inviato da Milotto
Francamente non si capisce più un C***o.....
Questo è il link del sito di un utente very skilled di beyond3D , potete trovarci un demo che esegue dynamic branching senza la necessità dello S.M. 3.0 , ovvero su un hardware con S.M. 2.0...
http://esprit.campus.luth.se/~humus/

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

[Pat77]

Originariamente inviato da GMCPape
Non sono un programmatore, quindi potrei dire una sciocchezza, ma credo che l'instancing utilizzato in FC si basi sui salti condizionati, possibili solamente cn lo SM3. Sono in ogni caso certo che non lo puoi fare con le DX7. O meglio, puoi fare l'instancing di un oggetto, ma non certo di uno shader, visto che sono supportati solo dalle 8 in su.

Pape

Se disegni man mano tutti gli oggetti potresti farlo anche con le Dx7 in linea teorica ma avrebbe un'incidenza sulle prestazioni madornale.

Questa caratteristica degli SM3 serve proprio per rendere il codice meno pesante senza nessuna perdita qualitativa, chiamando l'oggetto dal vertex buffer.

Credo che negli Rts avrà un'incidenza notevole se utilizzato bene.

Pk77

[fek]

Originariamente inviato da Pat77
Se disegni man mano tutti gli oggetti potresti farlo anche con le Dx7 in linea teorica ma avrebbe un'incidenza sulle prestazioni madornale.

Questa caratteristica degli SM3 serve proprio per rendere il codice meno pesante senza nessuna perdita qualitativa, chiamando l'oggetto dal vertex buffer.

Credo che negli Rts avrà un'incidenza notevole se utilizzato bene.

Pk77

C'e' una grossa limitazione: non puo' essere usato con oggetti animati. L'unica soluzione in questo caso e fare batching (ancora un altro nome per il GI ) con la CPU.

E' una feature interessante, che semplifica abbastanza la vita, ma nulla che non possa essere fatto in altro modo con prestazioni quasi equivalenti.

[MaBru]

Originariamente inviato da fek
C'e' una grossa limitazione: non puo' essere usato con oggetti animati. L'unica soluzione in questo caso e fare batching (ancora un altro nome per il GI ) con la CPU.

E' questo il caso della demo "Crowd" di Ati?

[fek]

Originariamente inviato da MaBru
E' questo il caso della demo "Crowd" di Ati?

Non conosco i dettagli di implementazione della demo Crowd. Immagino, pero' e' solo una supposizione, che tre o quattro soldati vengano raggruppati assieme e le loro "bone" siano inserite nella vertex constant table.

Ma quella demo non e' cosi' impressionante, sono un migliaio di oggetti animati renderizzati su una X800.

Il problema e' renderizzarne 2/3000, ma su una GF2MX: qui le cose diventano un pelo piu' complicate

[DjLode]

Originariamente inviato da fek
In entrambi i casi "calcoli" 100 steli d'erba, ma facendo geometry instancing li spedisci alla GPU tutti in un solo colpo, piuttosto che uno alla volta, il che migliora notevolmente le prestazioni sotto D3D.
Il punto e' che non serve certo l'SM3.0 per fare geometry instancing, che si puo' fare piu' che decentemente anche con una scheda DX7.

In altre parole: occhio che quelli di FarCry sboronano grosso.

Sei sicuro di quello che dici?
A parte gli scherzi, mi ricordavo male, mi ricordavo la tecnica che spieghi poi e ho fatto casino

Ciao Fek

[josefor]

Non ho capito una mazz.. però sono felice di trovare gente cosi preparata, dei veri e propri programmatori, anch'io sono un vostro collega, di serie B o C o anche meno magari, io lavoro con alcuni amici ad un Mod di Battlefiel1942 stiamo valutando di passare a Far Cry, ma miseria se è pesante, più che tutte queste implementazioni video dovrebbero guardare di sistemare il netcode.
Ma a proposito questo PolyBump, non l'ho notato io o non l'hanno messo in FC. A me parrebbe una cosina molto più carina del sm2.0 o 3.0.

[Jedi_Master]

Originariamente inviato da josefor
Ma a proposito questo PolyBump, non l'ho notato io o non l'hanno messo in FC. A me parrebbe una cosina molto più carina del sm2.0 o 3.0.

C'e' ed e' applicato ai personaggi per farli sembrare composti
da molti piu' poligoni di quello che in realta' sono!

[fek]

Originariamente inviato da DjLode
Sei sicuro di quello che dici?

Un po'

[Pat77]

Originariamente inviato da fek
Non conosco i dettagli di implementazione della demo Crowd. Immagino, pero' e' solo una supposizione, che tre o quattro soldati vengano raggruppati assieme e le loro "bone" siano inserite nella vertex constant table.

Ma quella demo non e' cosi' impressionante, sono un migliaio di oggetti animati renderizzati su una X800.

Il problema e' renderizzarne 2/3000, ma su una GF2MX: qui le cose diventano un pelo piu' complicate

Mi hai fatto ricordare che un mio amico con tale scheda, a dettagli minimi riusciva a far girare Halo Pc a 20-30 fps, i Gear box non sono certo famosi per l'ottimizzazione in questo titolo.

Altri titoli, come Breed o Farcry nemmeno partivano... questo episodio mi fece rivalutare un poco il lavoro di conversione di Halo (anche se lo ritengo tutt'ora solo sufficiente).

Pk77

[amd-novello]

Originariamente inviato da fek
Un po'

mi spiegheresti in modo umano la differenza fra vertex shader e pixelshader?

cosa significa "parlare dei SM3.0 non vuol dire niente perchè è generalizzare"?



grazie o sommo

[astronauta]

Secondo me, se uno deve acquistare una nuova scheda video di punta, gli conviene prendere una GeForce 6800 xkè ha gli Shader 3.0 e rimane tranquillo per + tempo. Invece se uno sceglie Ati magari tra 2 anni esce un gioco stupendo che usa gli Shader 3 e la Ati te la puoi mettere nel c..o!

[Aryan]

Originariamente inviato da astronauta
Secondo me, se uno deve acquistare una nuova scheda video di punta, gli conviene prendere una GeForce 6800 xkè ha gli Shader 3.0 e rimane tranquillo per + tempo. Invece se uno sceglie Ati magari tra 2 anni esce un gioco stupendo che usa gli Shader 3 e la Ati te la puoi mettere nel c..o!

Tra due annni ti puoi mettere nel culo anche la 6800. Tranquillo che i giochi che usciranno nel 2006 non gireranno con la 6800 con i filtri attivati.