View Full Version : Shader 3.0 o Shader 2.0
Eh si cari amici, sembra che la diatriba stia prendendo sempre più
piede, il supporto al pixel shader 3.0 si stà incominciado a diffondere nei giochi di ultima generazione facendo segnare dei record grafici senza precendenti rispetto al 2.0, a questo punto difronte a questa nuova tecnologia voi cosa rispondete, Ati R420 (non gli supporta) o Nvidia Nv40, le due schede fanno registrare prestazioni velocistiche molto vicine tra di loro, anche se la soluzione ATI pare nel complesso superiore, ma non credete che Ati abbia sbagliato a non implementare il supporto agli shader 3.0 ??
DevilMalak
04-07-2004, 23:54
ha sbagliato ma non è che quel supporto sia vitale IMHO, già pochi giochi usano gli shader 2.0 a dovere... nn mi sembra ke tutti i giochi ke usciranno adesso saranno shader 3.0, ad esempio hl2 e doom3 no
massimomarc
04-07-2004, 23:55
il supporto al pixel shader 3.0 si stà incominciado a diffondere nei giochi di ultima generazione
dove li vedi scusa ? :asd:
ma se io vedo ancora mooolto pochi i giochi ps2 :asd:
da quello che abbiamo visto con far cry non sembra che le schede ati soffriranno x il mancato supporto agli shader 3 mentre per le nvidia sembra che un aumento di performnce ci sia ... quindi ben vengano ma ci andrei piano a dire che si stanno diffondendo...
ati non ha sbagliato a non implementarli, x me a sbagliato solo a mantenere i prezzi delle schede alti come quelli della concorrenza mentre forse poteva stare un po' + sotto visto che sono stati + conservativi (cmq parlo da profano, potrei aver detto anche una caxxata..:D)
Originariamente inviato da Nie73
da quello che abbiamo visto con far cry non sembra che le schede ati soffriranno x il mancato supporto agli shader 3 mentre per le nvidia sembra con un aumento di performnce ci sia ... quindi ben vengano ma ci andrei piano a dire che si stanno diffondendo...
E'stato scoperto che l'aumento di performance è dovuto al fatto che la nvidia non applica filtri quando usa quei ps3 :(
Che dire, non mi pare una scelta appropriata, basarsi su questi ps3.
Forse conla prossima generazione di schede potremmo riparlarne, ma ora è veramente troppo presto.
Ciaoz
sbrizzolo
05-07-2004, 01:01
scusate la mia domanda da rinco (sono le 2 di notte e a quest'ora sparo alcune bombe)
Si può giocare lo stesso con un gioco 3.0 avendo una scheda che supporta solo il 2.0??
Comunque Half Life 2 dovrebbe uscire già ps 3.0 enable, non si sa se con una patch o direttamente nel gioco retail.
Detto questo, credo che i ps 2.0 saranno ancora la base, mentre i ps 3.0 offriranno migliori prestazioni generali, ma un vero divario tra le due soluzioni non si vedrà almeno per altri 6 mesi.
Pk77
amd-novello
05-07-2004, 06:46
Originariamente inviato da sbrizzolo
scusate la mia domanda da rinco (sono le 2 di notte e a quest'ora sparo alcune bombe)
Si può giocare lo stesso con un gioco 3.0 avendo una scheda che supporta solo il 2.0??
si solo se le istruzioni ps2 non sono così complesse come nel ps3. ma adesso anche un giocone come unreal3 come num di istr rientra nelle 2, quindi.
va sia sulle ati che nvidia.
io credo come ha detto qualcuno che quando usciranno giochi per le ps3 veri la 6800 sarà troppo lenta per farli girare adeguatamente.
Beh ati ha "sbagliato" infatti non poteva aggiungere all' R3xx un supporto full al 3.0 senza stravolgere e riprogettare il chip.
Visto che ati aveva ben chiaro di spendere il minimo possibile (forte di un'architettura di base veloce) ha lanciato l'aggiornamento R420 sul mercato,investendo il 2% del costo dell'eventuale modifica al supporto 3.0, per screditare tramite marketing Nvidia.
Se non a furore di popolo creare un imbrido 2.0/3.0....
Resta pur vero che oggi come oggi è completamente inutile il Ps 3.0.
Resta da vedere xò,com'è stato per il 3Dnow e le SSe quanto "pesi" nel settore del gaming un produttore rispetto all'altro.
E' innegabile che se Nvidia imporrà i suo 3.0 (che velocizzano rispetto i 2.0) sarà in netto vantaggio su Ati.
Insomma.........boh ! ;)
REPERGOGIAN
05-07-2004, 08:20
Originariamente inviato da massimomarc
il supporto al pixel shader 3.0 si stà incominciado a diffondere nei giochi di ultima generazione
dove li vedi scusa ? :asd:
infatti
;)
In Farcry portano un aumento prestazionale dal 4% al 30% a seconda delle condizioni (in condizioni limite con filtri attivati), ma restano troppo immaturi attualmente per farne una considerazione generale.
Credo che un'implementazione in Half-life 2 ci possa sicuramente dire di più.
Pk77
i filtri sono stati abilitati da chi ha fatto le rece...ma effettivamente l'aa non ve veniva applicato nella scene...;)
sbrizzolo
05-07-2004, 10:16
Il problema è che quì si sta procedendo ad un ritmo forsennato per quanto riguarda le innovazioni in campo tecnologico applicato alla scheda video!
Questo è il componente del pc che necessita un più continuo aggiornamento rispetto ad altri pezzi, e quindi ci scommetto che tra breve, le schede di cui state parlando ora saranno già cosa vecchia!
Come si fà a stare a dietro a tutto, cè da spararsi!
Basta non farsi prendere dalla foga, io ho un Palo 1800 Xp con 5600 a cui gioco a tutto, a volte con taluni compromessi, soprattutto di risoluzione, a volte al max.
Pk77
Su multiplayer.it c'è scritto che i SM3.0 non portano ne benifici prestazionali, ne qualitativi(tranne le superfici degli oggetti)... :muro: :muro: :muro:
Alberto Falchi
05-07-2004, 10:54
Originariamente inviato da Aryan
Su multiplayer.it c'è scritto che i SM3.0 non portano ne benifici prestazionali, ne qualitativi(tranne le superfici degli oggetti)... :muro: :muro: :muro:
Beh, non dargli ascolto ^_^
Puoi vedere i bench su tutti i siti più seri di hardware (tom, anandtech, xbitlabs etc), e questi dimostrano che l'0incremento di prestazioni, almeno in particolari condizioni c'è. In certi casi anche piuttosto sensibile. Nessun miglioramente della qualità, quello vero, ma oltre a velocizzare l'esecuzione degli shader, semplificano non poco la vita ai programmatori
Pape
Esatto, è proprio questo il punto, l'implementazione è molto più veloce e semplice, anche tramite patch.
Qualitativamente dovrebbero essere nativi i Ps a 32bit, aumentano notevolemnte la loro flessibilità e usano un numero superiore di registri.
Essendo una prima implementazione su un motore nativo 2.0 è logico che le differenze siano per lo più prestazionali, un utilizzo mirato potrebbe portare a qualche palusibile miglioria visiva, ma le due tecnologie condividono molti parametri che le rendono simili in molte applicazioni.
Insomma i Ps3.0 servono a snellire, non ad aumentare la qualità.
Pk77
amd-novello
05-07-2004, 12:48
Insomma i Ps3.0 servono a snellire, non ad aumentare la qualità.
Pk77
esatto la qualità già con i ps2 basta e avanza guardate unreal3 che fa impallidire doom3 e compagnia bella.
Uscirà nel 2006, porca miseria mi pare logico....
Pensandoci bene anche D3 forse uscirà per quella data.... mmmmmm :)
DevilMalak
05-07-2004, 12:55
nn penso proprio ke hl2 userà gli shaders 3.0 visto che le skede ati non li hanno
E quindi? :)
HL2 non è di certo un gioco Ati così come Ati non ha commissionato HL2.
La Valve ha usato hw Ati per la presentazione del gioco (come dargli torto? L'R3x0 era il chip Dx9 per eccellenza) ma sicuramente implementerà tutte le caratteristiche della concorrenza, a cui sicuramente vuole vendere i giochi.
Carmack ha sviluppato su Nvidia per via dei driver OGL, ma in certi casi se ne era uscito con il fatto che le Ati erano ben più veloci in alcuni casi.
Suvvia, una mente un pò più aperta :)
amd-novello
05-07-2004, 13:03
Originariamente inviato da DjLode
Uscirà nel 2006, porca miseria mi pare logico....
Pensandoci bene anche D3 forse uscirà per quella data.... mmmmmm :)
eheh :)
cmq
Crytek has implemented pixel shader 3.0 and vertex shader 3.0 improvements into Far Cry 1.2. On the vertex side, geometry instancing has been implemented for rendering grass and other foliage. With instancing, data is replicated from within the vertex buffer to create many examples of the same type of object. This is perfect for an application such as replicating multiple strands of grass to encompass a jungle. In future patches we’ve been told that Crytek will implement even more examples of instancing for even better performance improvements.
The second addition Crytek has made involves lighting. Crytek has used PS 3.0’s increased number of interpolated registers (8 in PS 2.0a and PS2.0b versus 10 in PS 3.0) to collapse multiple lights into one pass. We were told that instead of an individual pass per light with PS 2.0, up to three or four lights can be combined into one pass using PS 3.0. This should bring performance improvements in scenes with multiple light sources.
cioè
1) fc 1.2 userà sto benedetto geometry instancing meglio per creare l'erba in modo da non caricare il sistema. ma il 2d è così pesante?
2) con i ps3 si calcoleranno luci multiple in un singolo pass. invece di una nei ps2 se ne calcoleranno 3 o 4 con i ps3. ma non dicevano che non intaccavano la qualità ma solo le prestazioni??
ditemi se ho cazzato. :D
DevilMalak
05-07-2004, 13:06
Originariamente inviato da DjLode
E quindi? :)
HL2 non è di certo un gioco Ati così come Ati non ha commissionato HL2.
La Valve ha usato hw Ati per la presentazione del gioco (come dargli torto? L'R3x0 era il chip Dx9 per eccellenza) ma sicuramente implementerà tutte le caratteristiche della concorrenza, a cui sicuramente vuole vendere i giochi.
Carmack ha sviluppato su Nvidia per via dei driver OGL, ma in certi casi se ne era uscito con il fatto che le Ati erano ben più veloci in alcuni casi.
Suvvia, una mente un pò più aperta :)
vabbè... chi vivrà vedrà :sofico:
amd-novello
05-07-2004, 13:08
ci saranno sempre i nostri nipoti per avvertirci di queste implementazioni nel nuovissimo e attesissimo dukenukem neverendingstory3 :D :D
Originariamente inviato da amd-novello
cioè
1) fc 1.2 userà sto benedetto geometry instancing meglio per creare l'erba in modo da non caricare il sistema. ma il 2d è così pesante?
Considera la differenza tra calcolare (uno ad uno) e disegnare 100 steli d'erba e calcolarne uno e disegnarlo 100 volte.
2) con i ps3 si calcoleranno luci multiple in un singolo pass. invece di una nei ps2 se ne calcoleranno 3 o 4 con i ps3. ma non dicevano che non intaccavano la qualità ma solo le prestazioni??
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).
amd-novello
05-07-2004, 13:20
si infatti per adesso si è visto aumentare il frame di 5 o 6 frame sai che roba :D
Originariamente inviato da amd-novello
si infatti per adesso si è visto aumentare il frame di 5 o 6 frame sai che roba :D
Bhè su 50 fps, sono sempre il 10%. Non mi aspettavo certo di più.
amd-novello
05-07-2004, 13:25
beh io sinceramente si.
Colpa di chi ha sparato la tecnologia come rivoluzionaria :)
amd-novello
05-07-2004, 13:32
ci credi al fatto che il prossimo serious sam userà 700 mega di texture con il 3dc?
è possibile?
Ah, tutto è possibile. SS ha sempre avuto locazioni molto grandi e aperte quindi tutto è possibile.
3Dc ha sempre una ratio di 4 a 1, migliorando la qualità del risultato finale, 700 mega di texture le trovo eccessive anche perchè mi ricordo le texture di Unreal Tournament per voodoo 3, assolutamente splendite e poco grosse.
Ritornando ai Ps trovo che un 10 fps in più siano un risultato prevedibile, anche se in alcuni test ha dimostrato di poter avere un buon 30% di margine.
Pk77
amd-novello
05-07-2004, 14:31
certo che texture compresse come quelle di halo le devo vedere, anche farcry con la qualità text a palla le vedi slavatissime da vicino.
invece halo (su xbox non la cagata su pc) le ha perfette anche se non sono tutte cosi'
TheDarkAngel
05-07-2004, 14:57
Originariamente inviato da amd-novello
certo che texture compresse come quelle di halo le devo vedere, anche farcry con la qualità text a palla le vedi slavatissime da vicino.
invece halo (su xbox non la cagata su pc) le ha perfette anche se non sono tutte cosi'
in ss sono tutte splendide da vicino...
amd-novello
05-07-2004, 15:41
lo so addirittura nell'1 con tutte quelle opzioni attivavi la compressione texture ed erano favolose anche se un po' finte,
ma in altri non si vedono ste robe
Originariamente inviato da amd-novello
lo so addirittura nell'1 con tutte quelle opzioni attivavi la compressione texture ed erano favolose anche se un po' finte,
ma in altri non si vedono ste robe
Ut2004?
Painkiller?
bYeZ!
amd-novello
05-07-2004, 16:09
non li ho visti ora lo so
Le texture di halo da vicino erano irrealistiche come quelle di Serious Sam imho, inoltre quelle a distanza avevano una risoluzione pessima.
(in Halo)
In questi giochi la qualità non dona qualcosa in più ma crea uno stacco inaccettabile e l'ho sempre ritenuta una feature sostanzialmente inutile.
Mi piace molto di più la resa di un Farcry o di Unreal 2, anche il primo Unreal con Voodoo3 era splendido.
Pk77
amd-novello
05-07-2004, 17:23
per quanto riguarda halo non sono d'accordo
in far cry quando ti avvicini alle parti lontanissime noti il lod che cambia
in halo è tutto al massimo anche da lontano e avvicinandoti non cambia niente.
insomma solo i personaggi hanno diversi modelli di qualità ma non l'ambiente. ripeto:parlo della versione xbox. gioco del 99 nato su mac, ricordiamocelo.
La versione Xbox e quella Pc sono identiche tecnicamente tranne nell'anisotropico, negli effetti di fumo via ps 2.0 e nella risoluzione.
Da lontano le texture scalano alla bassa risoluzione, da vicino invece sono dettagliatissime.
In serious sam invece sono sempre dettagliate ma da vicino livellano male e si vede tutta la loro artificiosità.
Pk77
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
05-07-2004, 22:23
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
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.
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 è?
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.
Ohhhh eccolo il nostro fek che ci spolpa nozioni manco fosse un programmatore di black and white......... OPS :D
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
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/
:old:
http://forum.hwupgrade.it/showthread.php?s=&threadid=718904
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
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.
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?
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 ;)
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? :sofico:
A parte gli scherzi, mi ricordavo male, mi ricordavo la tecnica che spieghi poi e ho fatto casino :)
Ciao Fek :)
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
06-07-2004, 14:57
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!
Originariamente inviato da DjLode
Sei sicuro di quello che dici? :sofico:
Un po' :p
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 :O 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
07-07-2004, 14:43
Originariamente inviato da fek
Un po' :p
:ave: :ave: :ave:
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
08-07-2004, 16:39
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!
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. ;)
Originariamente inviato da Aryan
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. ;)
Concordo
ragzzi volevo sapere se qualcuno poteva darmi una spiegazione tecnica e una più terra terra su cosa sono e a cosa servono i pixel e i vertex shader e in cosa si differenziano i vari tipi: 1,2,3
Originariamente inviato da Haku
ragzzi volevo sapere se qualcuno poteva darmi una spiegazione tecnica e una più terra terra su cosa sono e a cosa servono i pixel e i vertex shader e in cosa si differenziano i vari tipi: 1,2,3
Trovi qualcosa quà (http://www.lithium.it/articolo.asp?code=22&pag=2)
come responso tecnico va più che bene!Grazie
E la spiegazione pù terra terra me la può fornire qualcuno?
Originariamente inviato da Haku
come responso tecnico va più che bene!Grazie
E la spiegazione pù terra terra me la può fornire qualcuno?
Non hai voglia di leggere vero?:D
Guarda che si capisce benissimo.;)
Il Vertex Shader è in pratica un 'piccolo' processore vettoriale in tecnologia SIMD (Single Istruction Multiple Data) che ha l'obbiettivo di elaborare i dati geometrici secondo specifici programmi (Vertex Programs) che i programmatori possono liberamente definire per personalizzare le elaborazioni di T&L.
...
link (http://www.lithium.it/articolo.asp?code=22&pag=18)
appena ho un po' di tempo me lo leggo!:D
Cmq grazie
;)
gino1221
19-07-2004, 08:50
qualcuno mi sa dire come si tolgono ifiltri a una scheda video? scusate la domanda, magari ho anche chiesto una cavolata, ma non è che sono tanto esperto..
trovi le relative voci dei filtri nei driver della tua scheda video. di lì sei libero di modificarne le impostazioni , e di disabilitarli se vuoi.
Originariamente inviato da gino1221
qualcuno mi sa dire come si tolgono ifiltri a una scheda video? scusate la domanda, magari ho anche chiesto una cavolata, ma non è che sono tanto esperto..
Prendi in caccaivite a punta molto fine, poi togli il dissipatore che ricopre la VPU, a qst punto apri il chip in due, ma devi essere delicato, poi asporta alcune parti, a tuo piacimento, ecco, i filtri non ci sono più ;)
:sofico:
ma così non si rischia di rivinare il chip?:confused: :confused:
:sofico: :sofico: :sofico: :sofico:
Originariamente inviato da crice
ma così non si rischia di rivinare il chip?:confused: :confused:
No no tranqui, è assodato che funzica, se vuoi fare un lavoro veramente perfetto punta il cacciavite sul core e dagli una bella martellata, minimo minimo riabiliti altre pipeline di rendering ;)
Ma vi devo dire sempre tutto!! :mad:
:sofico:
PSYCOMANTIS
19-07-2004, 16:36
http://www.tela.it/immagini/filtri.jpg
Ecco la serie completa dei filtri una volta tolti....
N.b. Quello tondo e' l'AA :asd:
Originariamente inviato da PSYCOMANTIS
http://www.tela.it/immagini/filtri.jpg
Ecco la serie completa dei filtri una volta tolti....
N.b. Quello tondo e' l'AA :asd:
Rotfl
Qui c'è un pò troppa sbornaggine :D
A partire da Maury sisisis ;)
Originariamente inviato da REPSOL
Qui c'è un pò troppa sbornaggine :D
A partire da Maury sisisis ;)
:p
Ma è tutta bonarietà, nn c'è cattiveria, per ridere :p
Ragazzi,forse le persone che possono dare una risposta alle mie domande siete propio voi....
Allora ho da poco una 9800pro e ho installato come driver gli unian 1047.Dentro il pacchetto dei driver c'era un utility,la ati tray tools.Questa utility permette vari tweak di cui ignoro totalmente lo scopo e i vantaggi.
Tra queste c'è propio la possibilità di settare il vertex ed il pixel shader version,impostabili rispetivamente fino a 2 e 2.1.
Di defoult è su "disable override"
Ora,ma cosa sono queste funzioni,che pro e che contro hanno?
Ho anche il dubbio che la mia scheda le supporti,e attivandole di friggere tutto.
Quindi chiedo lumi e consigli.
lascia tutto in defoult, così la tua scheda lavorerà a seconda dei casi nel modo + ottimale.
Originariamente inviato da Maury
:p
Ma è tutta bonarietà, nn c'è cattiveria, per ridere :p
Lo so lo so, oramai (purtroppo :p) vi conosco tutti su questo forum :D
Originariamente inviato da crice
lascia tutto in defoult, così la tua scheda lavorerà a seconda dei casi nel modo + ottimale.
Dici che è la soluzione migliore?
Però di defoult sono settati come disable,questo significa che nn verranno usati in nessun caso....
Originariamente inviato da mantes
Dici che è la soluzione migliore?
Però di defoult sono settati come disable,questo significa che nn verranno usati in nessun caso....
Magari è disabilitata la forzatura dei pixel e vertex.... quindi essendo su disable, vengono scelti dal tipo di applicazione avviata...... penso voglia dire quello.
Ciaoz
Notiziuola forse interessante:
http://www.ixbt.com/video2/fc12-2.shtml
E' in russo quindi occhio per ora solo ai grafici. Un pò di traduzione presa da un sito, magari è fatta un pò con i piedi ma si capisce:
"Disclaimer: The large part of this article was written to the output
of the final version of patcha. Nearer toward the end of the article
possible it found additional information about changes in those
occurred between the version originally by us of that obtained and by
the version, which left officially.
After the appearance of the first part of the article many opinions
appeared. Among them was both enthusiastic and skeptical. The first
expected it saw FarCry, renderinga (so called sm30path) carried out in
the new regime on all videokartakh, which support piksel'nye sheydery
of the second version. However, the second spoke about the complete
impossibility of this. Now 4, already during indivisible experimenting
with different modifications FarCry 1.2, which work on videokartakh of
those supporting sheydery only of second version, I can he said that
are partly right they was and those, etc.
Without putting aside into the long box, 4 to podtverzhdayu that on
the hands is version FarCry 1.2, which is carried out in the so-called
regime "sm30path" (more precise only in its part of that corresponding
to piksel'nym sheyderam) on videokartakh of those supporting
piksel'nye sheydery 2..x and that put outting as a result the image,
identical obtained on NV40. further such sheydery we budem frequently
called "long".
Necessarily noted that duplicating geometry (GeometryInstancing) in
the case of our tests practically it does not influence eventual
result. This it is not meant that this function it is useless, but it
wakes it maximally appeared in the case when "narrow" place with
renderinge it is central processor not have timing it assigned the set
of the excess parameters for mapping of scene. Such with the standard
testing FarCry on NV40 it is not occurred, partly because FarCry
originally byl is optimized under existing videokarty. Subsequently
the situation can changed. For example, developers on videokartakh,
which support duplicating geometry (GeometryInstancing), smogut on the
free spaces it sketched the real geometry of vegetation at large
distances from the player, without substituting by its spraytami
(imposters).
Even with the preparation of the first part of the article it was
explained that theoretically in regime sm30path instead of sheyderov
of the third version possible it limited to the use of sheyderov of
the second version. Therefore was undertaken attempts it forced FarCry
it used the regime of renderinga, calculated for "long" sheydery of
the third version on videokartakh, which support only sheydery 2..x.
The total step-by-step list of the accomplished work appears
approximately thus:
FarCry was "it was deceived" it sufficed was used the regime of
renderinga, analogous to that carried out on NV40, with renderinge
instead of sheyderov of the third version of steel it was used
equivalent sheydery of the second version, was checked the identity of
the obtained images. The first stage is solved relatively simply: with
the aid of utility 3DAnalize already mentioned in the previous part of
the material was substituted combination VendorID/DeviceID, which
identifies producer and concrete product, and also was advanced flags
that current videokarta it supports sheydery of the third version. As
a result of such actions FarCry neglected on the system with any
videokartoy begins it received it as NV40 it allows was used rendering
of several sources it dawned into one passage with the aid of "long"
sheyderov.
The second stage - substitution of sheyderov of the third version, to
analogous sheydery of the second version - for us it succeeded it
conducted partly using cursor itself FarCry as pomoshnika. The fact is
that FarCry can itself perekompilirovat' its sheydery, written on
HLSL/Cg, and it carries out this, using external compiler from
Microsoft: fxc.exe. Therefore for achievement of our aimed this
compiler it was substituted with another program, which carries out
all actions, required from the original compiler, and by at the same
time contributing the neobkhodimye correctives into sheydery and
gathering on them statistics.
Because of the limited time for working and verification of data the given below results are based on the data of 4 levels, used in demkakh, given NVIDIA together with patchem FarCry 1.2, and alsoon the results of the girder of quite these demok: Research, Regulator, Training and Volcano. I will first give general statistics. In all for renderinga of four levels FarCry pointed out above prepare about 3500 piksel'nykh sheyderov and 3500 apical sheyderov of all accessible versions: from 1.1 to 3.0. The lion's share of sheyderov comprise the permutations of sheyderov 3.0 for the set of the different values of the initial parameters. All apical sheydery 3.0 without the problems are compiled into sheydery 2.0. As sheyderov 2.0 we obtain with the compilation of piksel'nykh sheyderov 3.0: 1700 sheyderov 2.0 and 1900 sheyderov 2..x (was used profayl ps_2_.b for chips ATI R420, but unconditionally all these sheydery can be compiled with profaylom ps_2_.a). Evidently that more than half of sheyderov impose requirements those exceeding base version 2.0. But the compilation of sheyderov, does not indicate their required use in the real game situation. For example, with the girder of demok NVIDIA it is used on one sheyderu of version 2..x at levels Regulator and Training. And not one sheydera 2..x at levels Research and Volcano. In this case a quantity of sheyderov of the base version of version 2.0, utilized in each of these demkok kolebletsya in the region of 70 pieces. Thus, we smoothly arrived at the third part of our study: the comparison of the identity of the obtained images. This part proved to be most complex, since after the initial fulfillment of two points mentioned above it turned out that skrinshoty, obtained with the use of "long" sheyderov frequently they do not coincide with those obtained with the use of sheyderov of the third version. Moreover it was not possible to say that they incorrect - simply somewhat others. Reason proved to be in the use by developers FarCry of one of the special features of the model of sheyderov of the third version - 10 interpolation registers, which store given with the floating point, and using for the transfer of the results of fulfilling apical sheydera to the the piksel'nyy. The specifications of sheyderov of y..kh-2.kh stipulated the presence only of 8 such registers of standard accuracy. Two remained registers are used for the transfer it is color, their accuracy only must be not less than 8 bits to the color channel (standard 32 bit color), and even the more crucial point: with transfer from apical sheydera to the the piksel'nyy the values of these "color" registers are cut in the range [ 0..1 ]. I.e. any value, recorded in apical sheydere and which exceeds 1 or smaller than 0 will be unavoidably distorted with the transfer to piksel'nyy sheyder. It is important to here note that this requirement of specification DirectX, so that even if videokarta, which supports piksel'nye sheydery of version 2..x can interpolate more than 8 registers with the high accuracy it it is obligated to emulate the behavior described above. Above I indicated that the developers used a special feature of sheyderov - the presence of 10 interpolation registers, but in the reality they use only 9 registers of 10 and that only with renderinge the illumination from four luminous sources into one passage (four sources - this is a maximum quantity,supported by cursor FarCry at the given moment)."
"This appears by asomewhat distinction constraint and when desired of the support of sheyderov of the second version developers FarCry could simply it
limited single-pass rendering 3 by sources it dawned for this class of videokart. But since it did not be neither possibility nor of desire guided the code of game itself it was necessary it searched for alternate routes
Part 2:
Such ways at least three, below they are somewhat simply described.
With renderinge of less than 4 sources it dawned were used 8
accessible registers of high accuracy, while with 4 sources it dawned
one of the registers left "color". This the simplest and adding no
overhead expenses. As a result precisely this version was we have
used. Although there is a probability that into some places in the
game image with the use of such sheyderov it wakes it differed: we did
not find such places. after final the computed value of registers in
apical sheydere was carried out their normalization, before the
transfer to piksel'nyy sheyder. This method will wear, since in any
event in piksel'nom sheydere these registers again normalizuyutsya.
None of the interpolation registers of standard accuracy uses in
FarCry immediately all 4 components of register (x.y.z.sh). The part
of the registers uses generally only two components x and y, parts
Last Part
Reminder some Russian text was not translated (Mostly the ones under the benchmark graphs). But this gives you some ideal why jumping ship to early can co$t you
On 21 July there was was at long last released the official version of patcha 1.2. I can only be glad at the fact that all conclusions made even in the first part of the article were confirmed, and also to the fact which for me it is not necessary to strongly complain about developers FarCry about their purely marketingovom behavior. But against this below in the conclusion. Thus, admirers ATI can be glad: FarCry 1.2 are supported both the special way of renderinga for sheyderov 2..0b and the textures, compressed with the aid of 3Dc. The special method of renderinga for ATI R420 is activated, by analogy with NVIDIA by two keys: either "r_.sm2bPath" or "r_.noPs2b". For this either in the console it is necessary to introduce "\.r_.sm2bPatyu 1" or in the command line to assign the parameter to "&.tsuot;.r_.sm2bPatyu of y&.tsuot;" (quotation mark they are required). Moreover with start r_.sm2bPath, by analogy with NV40, on R420 in the future drivers will be activated "duplicating of geometry". Developers FarCry, in all likelihood, send by means of the smallest resistance and with the start of the method of using sheydery 2..x they limited the number of utilized lighting sources by 3 pieces for the passage. That 4 it proposed above: -). In this case a maximum quantity of utilized interpolation registers is equal to their maximally accessible quantity - 8 to pieces. In the operational regime we took results with the use of new patcha. Unfortunately the system, on which were removed the results was already changed in comparison with the previous measurements. ServicePack2 (but it for start sm2bPath and it was not necessary), in particular not was established. Therefore to compare results with an accuracy to one sequence will not come out. Nevertheless results it is present: Up to the moment of writing this conclusion developers FarCry by the output of official reliza of patcha 1.2 singlehandedly confirmed entire material outlined above. Thus, I will again repeat the main theses: The special features of sheyderov of the third version in the current realization FarCry are used only in the quite minimum volume. Piksel'nye sheydery 2.x easily can bethey are used instead of sheyderov 3.0 for the application of the new "accelerated" method of renderinga. Is possible the application of the "accelerated" method of renderinga even for the maps, which support only base version of sheyderov 2.0. This is confirmed at least by the fact that the maximum gain from "accelerated" renderinga came out in demkakh, which do not use sheydery of version larger the base the version 2.0. So that to developers still there is where to optimize rendering for an enormous quantity of existing videokart, which support only piksel'nye sheydery 2.0. From other side the developers dvizhutsya to introduction HDR (high dynamic range) renderinga, which will lead to further increase in the length of piksel'nykh sheyderov. And that for Crytek more priority we probably learn with the output of following patcha."
In pratica è già presente il supporto al 3dc e allo SM 2.0b e le fantomatiche cose che hanno aggiunto sono fattibilissime anche con quella versione e i risultati sono quelli che vedi. La traduzione è un pò pesante però da leggere :)
L'articolo è molto interessante , peccato sia tradotto in maniera penosa.....
Andrebbe capita meglio la natura dei primi grafici quando si scrive R420 SM 3.0...
Cmq sembra che la XT800PE sia di nuovo sopra ( e non di poco) al NV40...
http://www.ixbt.com/video2/images/fc12/pic1.png
http://www.ixbt.com/video2/images/fc12/pic2.png
http://www.ixbt.com/video2/images/fc12/pic3.png
Da approfondire...
Se sai fare meglio una traduzione dal russo... accomodati :)
Come ho detto è da riconfermare ma pare che le stesse cose fatte con lo shader model 2.0b diano quei risultati.
Purtroppo non so tradurre dal russo :rolleyes:
In ogni caso c'è un interessante articolo su :
http://www.digit-life.com/articles2/gffx/fc12.html
in definitiva ati batte nvidia con i filtri attivati...aspettando gli sgader model 2b
In realtà è possibile ottenere attraverso la patch 1.2 l'attivazione del Geometry Instancing (feature che alcuni dubitavano che R420 avesse) ed il path SM 2.0b ; quest'ultimo da un notevole incremento alle performance ATI ...
http://www.driverheaven.net/showthread.php?s=&threadid=51427
Originariamente inviato da Milotto
In realtà è possibile ottenere attraverso la patch 1.2 l'attivazione del Geometry Instancing (feature che alcuni dubitavano che R420 avesse) ed il path SM 2.0b ; quest'ultimo da un notevole incremento alle performance ATI ...
http://www.driverheaven.net/showthread.php?s=&threadid=51427
Si, ma servono i 4.8 (mi sembra)
Originariamente inviato da fd-82
Si, ma servono i 4.8 (mi sembra)
ma il 2.0b è presente anche sulle 9800 vero?
romansnake
25-07-2004, 11:58
Ragazzi domanda secca: quindi attualmente sarebbe meglio acquistare una 6800Ultra XFX 450MHz o una X800XT PE? :rolleyes:
Originariamente inviato da umile
ma il 2.0b è presente anche sulle 9800 vero?
The 2nd option is to have a R3xx or above graphics card (9500,9600,9700,9800) DirectX 9.0b, FarCry 1.2 and Catalyst 8.041. With this setup Geometry Instancing support is possible.
Mi sembra di no, però puoi attivare il Geometry Instancing che su Far Cry darà un bel boost (da quello che si dice)
Originariamente inviato da romansnake
Ragazzi domanda secca: quindi attualmente sarebbe meglio acquistare una 6800Ultra XFX 450MHz o una X800XT PE? :rolleyes:
Io comprerei la x800GT 16 pipe, se uscira.:D
Il prezzo +o- sara quello della 6800GT, la sua concorrente, e avendo 16 pipe basta poco per trasformarla in xt. (vedi 9800pro@9800xt)
romansnake
25-07-2004, 18:14
Eh ma io devo prenderla ora ^___^
Prezzo a parte, tanto le pagherei uguali:
XFX 6800Ultra (core 450) o Sapphire X800XT ?
No flame please.. :D
Originariamente inviato da fd-82
Mi sembra di no, però puoi attivare il Geometry Instancing che su Far Cry darà un bel boost (da quello che si dice)
io sapevo che dalla 9700 la differenza era nelle istruzioni appunto chiamate 2.0b
Originariamente inviato da umile
io sapevo che dalla 9700 la differenza era nelle istruzioni appunto chiamate 2.0b
Prova a vedere quà (http://users.erols.com/chare/video.htm).
Originariamente inviato da umile
io sapevo che dalla 9700 la differenza era nelle istruzioni appunto chiamate 2.0b
No, la 9700 e la 9800 fino alla XT supportano lo SM 2.0 (al massimo il 2.0a).
Le X800 lo SM 2.0b
Le 6800 lo SM3.
abitrulez
26-07-2004, 14:29
si vabbe tanto la 6800 usa la partial precision con gli sm3.0...
Alberto Falchi
26-07-2004, 14:51
Originariamente inviato da abitrulez
si vabbe tanto la 6800 usa la partial precision con gli sm3.0...
Ma questa stronzata da dove salta fuori? Se usa lo SM3 NON usa PP. Se non nelle menti bacate di qualche psicotico.
Pape
Originariamente inviato da GMCPape
Ma questa stronzata da dove salta fuori? Se usa lo SM3 NON usa PP. Se non nelle menti bacate di qualche psicotico.
Pape
Infatti la 6800 ci prende per il culo perché non implementa correttamente i PS3 lavorando a 16bit cioò PS1!!! :muro: :muro: :muro:
Per avere i 2.0 devi avere un FP di 24bit almeno!!!
abitrulez
26-07-2004, 16:55
Originariamente inviato da GMCPape
Ma questa stronzata da dove salta fuori? Se usa lo SM3 NON usa PP. Se non nelle menti bacate di qualche psicotico.
Pape
Evidentemente non hai capito bene le cose...
io non ti offendo come hai fatto tu ma ribadisco il concetto in modo civile.
Nvidia spinge sui developers (in modo particolare ID software con la quale ha un accordo commerciale) affinche' usino sulle proprie schede una partial precision a 16 Bit ove possibile... Questo significa che nella maggior parte delle sequenze tu non vedrai mai i colori come dovrebbero essere, ma leggermente "falsati".
Nvidia la mena tanto con gli SM3 ma intanto le sue schede non rispettano nemmeno i requisiti minimi per essere direct x 9 cioe' i 24 bit di precision.
In doom 3 che e opengl poi nell'80% del gioco usa i 16 bit
puah se devo prendermi una scheda che a qualita grafica va come una voodoo 2 del 1998 allora non la prendo neanche.
Originariamente inviato da amd-novello
mi spiegheresti in modo umano la differenza fra vertex shader e pixelshader?
Un vertex shader e' un "programmino" che la GPU esegue per ogni vertice che compone un modello da disegnare.
Un pixel shader e' un "programmino" che la GPU esegure per ogni pixel (in realta' e' piu' giusto chiamarli "fragment") di ogni triangolo che compone un modello da disegnare.
Quindi i pixel shader sono eseguiti molte piu' volte dei vertex shader.
(scusa per il ritardo della risposta)
John Carmack:
The quote is from me. Nvidia probably IS "cheating" to some degree, recognizing the Doom shaders and substituting optimized ones, because I have found that making some innocuous changes causes the performance to drop all the way back down to the levels it used to run at. I do set the precision hint to allow them to use 16 bit floating point for everything, which gets them back in the ballpark of the R300 cards, but generally still a bit lower.
Removing a back end driver path is valuable to me, so I don't complain
about the optimization. Keeping Nvidia focused on the ARB standard paths
instead of their vendor specific paths is a Good Thing.
The bottom line is that the ATI R300 class systems will generally run a
typical random fragment program that you would write faster than early NV30 class systems, although it is very easy to run into the implementation
limits on the R300 when you are experimenting. Later NV30 class cards are
faster (I have not done head to head comparisons with non-Doom code), and the NV40 runs everything really fast.
Feel free to post these comments.
John Carmack
Se l'Nv40 nei bench usa fp16 mentre ati fp24 i risultati sono comparabili?
Originariamente inviato da fek
...
Andate bene le vacenze? ;)
Originariamente inviato da abitrulez
Evidentemente non hai capito bene le cose...
io non ti offendo come hai fatto tu ma ribadisco il concetto in modo civile.
Nvidia spinge sui developers (in modo particolare ID software con la quale ha un accordo commerciale) affinche' usino sulle proprie schede una partial precision a 16 Bit ove possibile... Questo significa che nella maggior parte delle sequenze tu non vedrai mai i colori come dovrebbero essere, ma leggermente "falsati".
Nvidia la mena tanto con gli SM3 ma intanto le sue schede non rispettano nemmeno i requisiti minimi per essere direct x 9 cioe' i 24 bit di precision.
In doom 3 che e opengl poi nell'80% del gioco usa i 16 bit
puah se devo prendermi una scheda che a qualita grafica va come una voodoo 2 del 1998 allora non la prendo neanche.
Come ho scritto dall'altra parte, nel 99% delle situazioni, con pixel shader della lunghezza di quelli implementati oggi non c'e' alcuna differenza fra fp16 e fp32: la precisione degli fp16 e' piu' che sufficiente.
Non e' NVIDIA a spingere affinche' si usi PP, ma e' una soluzione semplice e logica che ogni programmatore puo' prendere: si tratta di valutare se la precisione in piu' e' necessaria o meno e se non lo e', scalare ad una precisione inferiore che e' eseguita piu' velocemente. E' una scelta in piu' in mano al programmatore, non ci sono cospirazioni di mercato dietro.
Usare sempre e solo fp32 significa, molto semplicemente, non essere capaci a programmare.
I requisiti minimi delle DX9 sono fp16. Consigliati fp24. NVIDIA supporta sia fp16 sia fp24, quindi e' perfettamente nello standard.
Originariamente inviato da MaBru
Andate bene le vacenze? ;)
Mangiato molto :D
Originariamente inviato da fek
Come ho scritto dall'altra parte, nel 99% delle situazioni, con pixel shader della lunghezza di quelli implementati oggi non c'e' alcuna differenza fra fp16 e fp32: la precisione degli fp16 e' piu' che sufficiente.
Non e' NVIDIA a spingere affinche' si usi PP, ma e' una soluzione semplice e logica che ogni programmatore puo' prendere: si tratta di valutare se la precisione in piu' e' necessaria o meno e se non lo e', scalare ad una precisione inferiore che e' eseguita piu' velocemente. E' una scelta in piu' in mano al programmatore, non ci sono cospirazioni di mercato dietro.
Usare sempre e solo fp32 significa, molto semplicemente, non essere capaci a programmare.
I requisiti minimi delle DX9 sono fp16. Consigliati fp24. NVIDIA supporta sia fp16 sia fp24, quindi e' perfettamente nello standard.
Nvidia non supportava 16 e 32, mentre Ati 24??? :confused:
Originariamente inviato da Aryan
Nvidia non supportava 16 e 32, mentre Ati 24??? :confused:
Si'... ho scritto una scemenza ;)
Originariamente inviato da fek
Si'... ho scritto una scemenza ;)
Tranquillo... :)
PS: è confermato B&W2 per settembre/ottobre?
Originariamente inviato da Aryan
PS: è confermato B&W2 per settembre/ottobre?
Esce quando e' pronto :D
sicuramente non a settembre ;)
Originariamente inviato da fek
I requisiti minimi delle DX9 sono fp16. Consigliati fp24. NVIDIA supporta sia fp16 sia fp24, quindi e' perfettamente nello standard.
Io mi ricordo, alla presentazione dell'NV40, di una slide mostrata da nvidia stessa in cui si menzionava al fatto che lo SM2.0 richiedesse come MINIMO una precisione a fp24 mentre fp32 per lo SM3. Cosa dicono i doc sulle DX9?
Originariamente inviato da MaBru
Io mi ricordo, alla presentazione dell'NV40, di una slide mostrata da nvidia stessa in cui si menzionava al fatto che lo SM2.0 richiedesse come MINIMO una precisione a fp24 mentre fp32 per lo SM3. Cosa dicono i doc sulle DX9?
In teoria:
SM1.0 --> 16bit
SM2.0 --> 24bit
SM3.0 --> 32bit
Originariamente inviato da fek
Esce quando e' pronto :D
Ma che è? DukeNukem ForNever??? :D
sicuramente non a settembre ;)
:cry: :cry: :cry:
Originariamente inviato da MaBru
Io mi ricordo, alla presentazione dell'NV40, di una slide mostrata da nvidia stessa in cui si menzionava al fatto che lo SM2.0 richiedesse come MINIMO una precisione a fp24 mentre fp32 per lo SM3. Cosa dicono i doc sulle DX9?
In realta' le specifiche minime sono mooolto labili.
Diciamo che i 2.0 devono supportare i floating point e come minimo fp16, poi si consiglia gli fp24.
L'SM1.0 e' solo fixed point (8 bit).
zerothehero
26-07-2004, 17:50
Originariamente inviato da fek
In realta' le specifiche minime sono mooolto labili.
Diciamo che i 2.0 devono supportare i floating point e come minimo fp16, poi si consiglia gli fp24.
L'SM1.0 e' solo fixed point (8 bit).
tornando a una cosa che hai detto su ps 3.0 di far cry...mi sembra che tu abbia detto che in realtà questi ps 3.0 di far cry sono un pò fasulli..come mai allora si notano dei boost prestazionali con la loro attivazione? forse hanno introdotto delle ottimizzazione per le 6800? fammi capire..sono curioso..
Originariamente inviato da zerothehero
tornando a una cosa che hai detto su ps 3.0 di far cry...mi sembra che tu abbia detto che in realtà questi ps 3.0 di far cry sono un pò fasulli..come mai allora si notano dei boost prestazionali con la loro attivazione? forse hanno introdotto delle ottimizzazione per le 6800? fammi capire..sono curioso..
Sembra che abbiano semplicemente ricompilato shader HLSL in SM3.0.
zerothehero
26-07-2004, 17:57
Originariamente inviato da fek
Sembra che abbiano semplicemente ricompilato shader HLSL in SM3.0.
Quindi hanno preso gli shader e con un semplice compilatore le hanno trasformate in 3.0...con uno sforzo nullo...se già così ci sono state delle ottime performance è una grande notizia per le 6800...o sbaglio?
Originariamente inviato da zerothehero
Quindi hanno preso gli shader e con un semplice compilatore le hanno trasformate in 3.0...con uno sforzo nullo...se già così ci sono state delle ottime performance è una grande notizia per le 6800...o sbaglio?
Bisognerebbe valutare l'incremento di performance ;)
Alberto Falchi
26-07-2004, 18:07
Originariamente inviato da abitrulez
Evidentemente non hai capito bene le cose...
io non ti offendo come hai fatto tu ma ribadisco il concetto in modo civile.
L'offesa non era rivolta a te, e me ne scuso se ti ho dato questa impressione.
Nvidia spinge sui developers (in modo particolare ID software con la quale ha un accordo commerciale) affinche' usino sulle proprie schede una partial precision a 16 Bit ove possibile... Questo significa che nella maggior parte delle sequenze tu non vedrai mai i colori come dovrebbero essere, ma leggermente "falsati".
Il discorso non è errato, ma quel "dove possibile" va inteso come "quando FP16 non porta un degrado della qualità rispetto a FP24/32".
Nvidia la mena tanto con gli SM3 ma intanto le sue schede non rispettano nemmeno i requisiti minimi per essere direct x 9 cioe' i 24 bit di precision.
Veramente sono full 32 bit le 6800.
In doom 3 che e opengl poi nell'80% del gioco usa i 16 bit
puah se devo prendermi una scheda che a qualita grafica va come una voodoo 2 del 1998 allora non la prendo neanche.
Mah... mi sembra tanto un dirscorso da fanboy. Ma più che altro lascia ben intendere le tue scarsissime conoscenze tecniche.
Pape
Ricordo soltanto che laddove Nvidia usa i 16 bit, Ati usa i 24bit (calcola a 24bit, poi magari sputa fuori i dati a 16 o 32). Laddove Nvidia usa i 32bit però, Ati usa sempre i 24bit. Cosa che ancora nessuno ha "fatto notare" :)
Suvvia, prendetevela con calma non c'è bisogno di farsi il sangue cattivo, ora che abbiamo scoperto che ancora non sappiamo come vadano le schede neanche con D3 e la patch 1.2 di Far Cry :muro:
Il fatto che Ati usi sempre 24 bit di precisione può essere anche visto come un fatto negativo. Se infatti ci sono degli shader che si possono calcolare a 16 bit senza perdere qualità (come sembra che sia per buona parte di questi, in farcry almeno), le schede ATI consumerebbero molte più risorse, con il risultato di avere frame rate più bassi.
E' ovvio che se il calcolo fatto a 16 bit porta ad un degrado di qualità allora il discorso è diverso. Ma è tutto da dimostrare IMHO.
amd-novello
27-07-2004, 15:00
Originariamente inviato da fek
Un vertex shader e' un "programmino" che la GPU esegue per ogni vertice che compone un modello da disegnare.
Un pixel shader e' un "programmino" che la GPU esegure per ogni pixel (in realta' e' piu' giusto chiamarli "fragment") di ogni triangolo che compone un modello da disegnare.
Quindi i pixel shader sono eseguiti molte piu' volte dei vertex shader.
(scusa per il ritardo della risposta)
grazie mille per la risposta che viene incontro alle mie capacità mentali ridotte. :D :D
ma sta precisione maledetta riguarda la rappresentazione dei colori?
perchè ho letto uno speciale su doom3 e le sue tecnologie e carmack già 2 anni fa lamentava il fatto che i 24 bit sarebbero stati una manna spiegando la cosa con queste cifre:
16 bit 0.12 quindi 2 cifre dopo la virgola
24 bit 0.1258 (+ o -) quindi molta + precisione.
ma il fatto è: le schede dx9.0 appena uscite hanno un calo di prestazioni aumentando la precisione? se uscissero giochi con
precisione 32 la 6800 li farebbe andare umanamente?
in definitiva i 32 servono a poco no?
amd-novello
27-07-2004, 15:03
Originariamente inviato da fd-82
Prova a vedere quà (http://users.erols.com/chare/video.htm).
:eek: :eek: :eek: :eek: bellissimo sito
Originariamente inviato da amd-novello
grazie mille per la risposta che viene incontro alle mie capacità mentali ridotte. :D :D
ma sta precisione maledetta riguarda la rappresentazione dei colori?
perchè ho letto uno speciale su doom3 e le sue tecnologie e carmack già 2 anni fa lamentava il fatto che i 24 bit sarebbero stati una manna spiegando la cosa con queste cifre:
16 bit 0.12 quindi 2 cifre dopo la virgola
24 bit 0.1258 (+ o -) quindi molta + precisione.
ma il fatto è: le schede dx9.0 appena uscite hanno un calo di prestazioni aumentando la precisione? se uscissero giochi con
precisione 32 la 6800 li farebbe andare umanamente?
in definitiva i 32 servono a poco no?
http://www.nvitalia.com/forum/showthread.php?s=&threadid=38010&pagenumber=2
Originariamente inviato da fek :
Ma questo e' un limite dell'architettura non un suo vantaggio.
Non porta a nessun vantaggio perche' l'architettura non supporta la partial precision.
Ti faccio un esempio. Immagina di aver scritto un'applicazione che gira a 25 fps in determinate condizioni su NV40, ti viene detto che le specifiche sono minimo 30fps.
Inizi a fare profiling e scopri che l'applicazione e' pixel shader limited, devi ottimizzare i pixel shader. Vai a guardare il pixel shader piu' usato che e' scritto usando fp32. L'opzione piu' semplice per ottimizzarlo e' scalare alcune istruzioni a fp16. Lanci l'applicazione, controlli che i requisiti sulla qualita' siano soddisfatti, va a 30fps, chiudi tutto e vai al pub.
Stessa applicazione che gira su R420 a 25fps, requisiti richiedono 30fps, guardi il pixel shader e che fai? Scali la precisione? No, l'architettura non lo supporta, devi riscrivere il pixel shader e/o semplificarlo riducendone la qualita', ma cercando di mantenerla entro le specifiche. Probabilmente andrai al pub un po' piu' tardi oggi.
E' un esempio, non e' detto che basti ridurre tutte le volte la precisione per far volare il gioco, ma vuole mostrare come con l'architettura nvidia hai un'opzione in piu' da sfruttare. E' un vantaggio.
amd-novello
27-07-2004, 17:04
ariririririgrazie!!!!!!!
per la storia del dithering della torcia c'è un errore HW o sono i driver acerbi?
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.