MMX,SSE e GeForce...
marble
degli ultimi gioielli tecnologici per PC.
Mi sono soffermato sulle istruzioni SSE del Pentium III (tanto
reclamizzate in TV) e su alcune features delle nuovissime schede 3d.
Si diceva in sostanza che il PIII ha un set di istruzioni dedicato
esplicitamente ai calcoli in virgola mobile per i giochi 3d, che
potrebbero accelerare il codice del 180%. Si diceva anche che la nuova
scheda GeForce Annihilator ha un chip grafico built-in che si calcola
da sola tutta l'illuminazione della scena 3d.
Come vedete queste nuove features?
Vorrei anche sapere se tutte queste implementazioni a livello hardware
possano uccidere definitavamente il coding, e se un giorno ci
ritroveremo a usare tutti insieme degli script fatti da terzi non
modificabili.
marble
Ciddi3d
c.castiglia...@studenti.to.it says...
> (beh, se la Creative mi desse una decina di milioni per fare una demo per
> sola GeForce allora se ne potrebbe parlare). Ma anche qui esistono le
> eccezioni... Contour gira solo su schede TNT, e Virhe solo su Voodoo3.
Beh, Nvidia, non Creative, ma non credo che abbia bisogno di intro in
raytracing... 8-)
Le demo girano solo su una scheda (specialmente la TNT, che non ha API
proprietarie) semplicemente perche' hanno qualche bug o perche' il coder
non ha avuto il tempo/la voglia/la possibilita' di provare la demo su
varie schede video.
Se sviluppi un gioco non c'e' problema, fai comprare tutte le schede
video esistenti (o te le fai mandare dal produttore); non e' una
soluzione da democoder squattrinato, purtroppo 8-)
> > Vorrei anche sapere se tutte queste implementazioni a livello hardware
> > possano uccidere definitavamente il coding.
>
> Questo non lo credo. E' come chiedersi se una scheda con l'audio surround
> incorporato o con un postprocessing del segnale puo' uccidere il music
> making...
Non lo credo neppure io.
Non mi risulta che ci siano in giro molti engine come quello di Quake3,
eppure le TNT2 e Voodoo3 le hanno tutti...
--
ciddi3d^Z
www.dronez.com
FrOYd
> Come vedete queste nuove features?
Bene.
> Vorrei anche sapere se tutte queste implementazioni a livello hardware
> possano uccidere definitavamente il coding, e se un giorno ci
> ritroveremo a usare tutti insieme degli script fatti da terzi non
> modificabili.
Ancora questa scemenza?
Perche'?
Quando hanno messo le FPU veloci abbiamo smesso di utilizzare le tabelle
per le divisioni, quando hanno messo ISQRT sul 3DNow abbiamo (magari...
;) ) smesso di fare le tabelle per le radici quadrate inverse, ma il
coding non e' finito. Perche' dovrebbe finire ora?
--
C++ao,
FrOYd / DeathStar
FrOYd
> Per i giochi?!?! Saranno delle istruzioni per accelerare i calcoli in
> virgola mobile, sia quelli dei giochi che quelli di Calc.exe :D
No. Solo i giochi, non hanno la precisione sufficiente per CALC.
> dedicate. Gia' ora mi pare strano che esistano ancora effetti non
> ottimizzati MMX (dove possibile, ovviamente).
MMX sux.
> >Si diceva anche che la nuova
> > scheda GeForce Annihilator ha un chip grafico built-in che si calcola
> > da sola tutta l'illuminazione della scena 3d.
> Questo e' un altro discorso. Mentre le istruzioni built i del processore
> possono raggiungere un'audience piu' vasta, non credo sia giusto limitare la
> godibilita' di una demo ai soli possessori di una scheda grafica particolare
> (beh, se la Creative mi desse una decina di milioni per fare una demo per
> sola GeForce allora se ne potrebbe parlare). Ma anche qui esistono le
> eccezioni... Contour gira solo su schede TNT, e Virhe solo su Voodoo3.
Esattamente il contrario. Mentre per i processori devi scrivere codice
apposta, per le schede video basta usare opportunamente OpenGL o
Direct3D. Contour e Virhe sono esempi di programmazione del mesozoico.
> I lamer di sicuro. I veri sceners cercheranno, per quanto possibile, di
> andare oltre, compatibilmente con la disponibilita' di doc e di informazioni
> sull'hardware e sui drivers.
Macche'. Usano le API.
Cesare Castiglia
> Beh, Nvidia, non Creative, ma non credo che abbia bisogno di intro in
> raytracing... 8-)
Beh, io penso che prima o poi del RT ci cagheremo il cazzo pure noi :D
(ammesso che non sia gia' successo...)
> Le demo girano solo su una scheda (specialmente la TNT, che non ha API
> proprietarie) semplicemente perche' hanno qualche bug o perche' il coder
> non ha avuto il tempo/la voglia/la possibilita' di provare la demo su
> varie schede video.
Per quello che ne so io, Virhe dei Mature Furk (carino l'anagramma eh...)
vuole la Voodoo3 semplicemente perche' la Remedy voleva un Benchmark per
schede Voodoo, mentre Contour sfrutta l'alpha blending hardware delle schede
TNT, che altrove risulta solo in un bel mapping grigio uniforme su tutti i
poligoni.
> Se sviluppi un gioco non c'e' problema, fai comprare tutte le schede
> video esistenti (o te le fai mandare dal produttore); non e' una
> soluzione da democoder squattrinato, purtroppo 8-)
Hehehe, verissimo. Infatti il democoder di solito si preoccupa solo di
provarle su un PC il piu' simile possibile a quello della compo machine del
party a cui vuole rilasciare :)
> Non lo credo neppure io.
> Non mi risulta che ci siano in giro molti engine come quello di Quake3,
> eppure le TNT2 e Voodoo3 le hanno tutti...
Diciamo anche che non tutti gli sviluppatori sono in grado di programmare un
engine come quello di Q3, cosi' come pochi democoder sono in grado di codare
come Statix, Unreal, Echo o Vipa...
Comunque, secondo me, la morte del coding (dal punto di vista professionale,
non del demo coding) ci sara' quando l'hardware fornira' abbastanza features
da rendere praticamente inosservabile (all'occhio del videogiocatore medio)
qualsiasi ottimizzazione apportata dai coder. Da quel giorno sara' solo piu'
un lavoro di motion capture e di texture...
Per fortuna questo non dovrebbe capitare alle demo...
bye
DiXan
P. Foscari
Hey Marbello!
> Si diceva in sostanza che il PIII ha un set di istruzioni dedicato
> esplicitamente ai calcoli in virgola mobile per i giochi 3d, che
> potrebbero accelerare il codice del 180%. Si diceva anche che la nuova
> scheda GeForce Annihilator ha un chip grafico built-in che si calcola
> da sola tutta l'illuminazione della scena 3d.
Son 2 mesi che CDS non fa che rompere le scatole colla geforce, dov'eri
tu? :-)
Comunque le SSE me le sto studiando ora (sto pure facendo un doc al
riguardo visto che al solito la documentazione intel e' di un ordine
sublime...) e non credo promettano quello che mantengano. In teoria il
compilatore Intel le potrebbe sfruttare, ma tanto chi lo usa?
> Come vedete queste nuove features?
> Vorrei anche sapere se tutte queste implementazioni a livello hardware
> possano uccidere definitavamente il coding, e se un giorno ci
> ritroveremo a usare tutti insieme degli script fatti da terzi non
> modificabili.
Bah, ci sara' sempre qualcosa da fare. Per ora in vista ci sono nurbs e
subdivision surfaces...
E poi ti assicuro che codare per le SSE e' ancor + divertente che per le
MMX, l'unico svantaggio al limite e' che non ti accelerano di molto.
Quel 180% in piu' mi pare ridicolo, al max puo' andare per uno starfield,
ma in pratica la situazione e' ben diversa. Del 180% al max ti velocizza
le trasformazioni geometriche (ed in casi particolari, con oggetti statici
coi dati preorganizzati in modo particolare), ma non un gioco nel suo
complesso.
La cosa che mi piace di piu' delle SSE e' l'istruzione Prefetch, che non
centra niente con quelle di calcolo float SIMD.
In realta' non vedo l'ora di mettere le mani su un Athlon piuttosto...
Saludos
Quartz
FrOYd
c.castiglia...@studenti.to.it says...
> Comunque, secondo me, la morte del coding (dal punto di vista professionale,
> non del demo coding) ci sara' quando l'hardware fornira' abbastanza features
> da rendere praticamente inosservabile (all'occhio del videogiocatore medio)
> qualsiasi ottimizzazione apportata dai coder. Da quel giorno sara' solo piu'
> un lavoro di motion capture e di texture...
> Per fortuna questo non dovrebbe capitare alle demo...
Quando inventarono gli scanner 3D con texture dissero che era finito il
lavoro dei modellatori + texture artist.
Non credo, invece, che un solo modellatore o texture artist sia stato
licenziato.
--
C++ao,
Gio' "FrOYd" Caturano / Zetha gameZ
http://www.dronez.com
[AD] HereBit
che si imponga uno standard, perchè un democoder non ha certo il tempo
di stare a supportare sia il 3Dnow! che le SSE, oltre naturalmente al MMX, e
non può certo ripartire da zero ogni volta che esce una nuova versione di
directx (cosa che avviente puntualmente).
Purtroppo ho sentito dire che il progetto di unificare Opengl e Direct3D
sotto
un'unica api + evoluta di nome Fahreneit (o qualcosa del genere) sia stato
abbandonato dalla SGI e verrà portato avanti dalla sola Microsoft (non oso
pensare a cosa combineranno!).
Secondo me la prossima rivoluzione sarà l'avere un intero engine3D in
hardware che magari supporti anche le nurbs ecc. , cosa che permetterebbe ai
coder di concentrarsi su altri particolari che finora sono stati trascurati,
e permetterebbe anche ai principianti di iniziare a divertirsi nel mondo
della grafica 3D in tempo reale (con conseguente sviluppo della scena).
marble <qua...@ipsnet.it> wrote in message 38411b8...@news.ipsnet.it...
> Stamattina mi sono comprato una rivista di informatica che parlava
> degli ultimi gioielli tecnologici per PC.
> Mi sono soffermato sulle istruzioni SSE del Pentium III (tanto
> reclamizzate in TV) e su alcune features delle nuovissime schede 3d.
> Si diceva in sostanza che il PIII ha un set di istruzioni dedicato
> esplicitamente ai calcoli in virgola mobile per i giochi 3d, che
> potrebbero accelerare il codice del 180%. Si diceva anche che la nuova
> scheda GeForce Annihilator ha un chip grafico built-in che si calcola
> da sola tutta l'illuminazione della scena 3d.
>
> Come vedete queste nuove features?
>
> Vorrei anche sapere se tutte queste implementazioni a livello hardware
> possano uccidere definitavamente il coding, e se un giorno ci
> ritroveremo a usare tutti insieme degli script fatti da terzi non
> modificabili.
>
> marble
------
Posted via news://freenews.netfront.net
Complaints to ne...@netfront.net
FrOYd
says...
> Secondo me queste sono tutte belle cose, ma ad una condizione:
> che si imponga uno standard, perchè un democoder non ha certo il tempo
> di stare a supportare sia il 3Dnow! che le SSE, oltre naturalmente al MMX, e
> non può certo ripartire da zero ogni volta che esce una nuova versione di
> directx (cosa che avviente puntualmente).
Usa OpenGL! 3 versioni in 10 anni.
> Purtroppo ho sentito dire che il progetto di unificare Opengl e Direct3D
> sotto un'unica api + evoluta di nome Fahreneit (o qualcosa del genere) sia stato
> abbandonato dalla SGI e verrà portato avanti dalla sola Microsoft (non oso
> pensare a cosa combineranno!).
Come sia sia, nel progetto di Farenheit c'e' di mantenere OGL come low-
level API, il resto di fanfarenheit non ci interessa.
> Secondo me la prossima rivoluzione sarà l'avere un intero engine3D in
> hardware che magari supporti anche le nurbs ecc. , cosa che permetterebbe ai
> coder di concentrarsi su altri particolari che finora sono stati trascurati,
> e permetterebbe anche ai principianti di iniziare a divertirsi nel mondo
> della grafica 3D in tempo reale (con conseguente sviluppo della scena).
Cio' stai parlando di aggiungere il supporto HW per la tesselazione
delle NURBS? Mah... non e' che mi pare questa grande cosa, cmq...
FrOYd
p.foscariDE...@vi.nettuno.it says...
[SSE]
> sublime...) e non credo promettano quello che mantengano. In teoria il
> compilatore Intel le potrebbe sfruttare, ma tanto chi lo usa?
Io?
> In realta' non vedo l'ora di mettere le mani su un Athlon piuttosto...
Lo dico sempre, io.
Piero Foscari
> > possano uccidere definitavamente il coding, e se un giorno ci
> > ritroveremo a usare tutti insieme degli script fatti da terzi non
> > modificabili.
> Perche'?
> Quando hanno messo le FPU veloci abbiamo smesso di utilizzare le tabelle
> per le divisioni, quando hanno messo ISQRT sul 3DNow abbiamo (magari...
> ;) ) smesso di fare le tabelle per le radici quadrate inverse, ma il
> coding non e' finito. Perche' dovrebbe finire ora?
Dai, ogni tanto ci vuole sto discorso, da' quel tocco di rivitalizzazione in
piu' all'eterna morte della scena :-)
(hmm, ma la ISQRT del 3dnow e' inutile come quella SSE?)
Bye
Quartz
Piero Foscari
Piero Foscari
> delle NURBS? Mah... non e' che mi pare questa grande cosa, cmq...
Meglio il supporto SW per le subdivision surfaces infatti...
Non chiedermi come si texturano, ma se lo fanno alla pixar si puo' :-)
Byetz
Quartz
FrOYd
says...
> Meglio il supporto SW per le subdivision surfaces infatti...
> Non chiedermi come si texturano, ma se lo fanno alla pixar si puo' :-)
Hanno le loro coordinate UV.
E cmq la pixar praticamente ha inventato il tmap.
Ciddi3d
says...
> (hmm, ma la ISQRT del 3dnow e' inutile come quella SSE?)
No, e' sicuramente meglio.
--
ciddi3d^Z
www.dronez.com
friol
>Quando hanno messo le FPU veloci abbiamo smesso di utilizzare le tabelle
>per le divisioni, quando hanno messo ISQRT sul 3DNow abbiamo (magari...
>;) ) smesso di fare le tabelle per le radici quadrate inverse, ma il
>coding non e' finito. Perche' dovrebbe finire ora?
tu facevi le tabelle per 1/sqrt(n) ?
e quanto erano grosse? 8)
cmq non c'e' bisogno di fare tabelle,basta uno shift
friol
Ciddi3d
says...
> tu facevi le tabelle per 1/sqrt(n) ?
> e quanto erano grosse? 8)
4k
> cmq non c'e' bisogno di fare tabelle,basta uno shift
Si'? E perche' mai hanno messo l'istruzione fsqrt e 1/fsqrt in 3dnow e
sse, se si puo' fare tutto con gli shift?
--
ciddi3d^Z
www.dronez.com
FrOYd
> tu facevi le tabelle per 1/sqrt(n) ?
> e quanto erano grosse? 8)
4K
> cmq non c'e' bisogno di fare tabelle,basta uno shift
Prego?
friol
[1/sqrt(n)]
>> cmq non c'e' bisogno di fare tabelle,basta uno shift
>Si'? E perche' mai hanno messo l'istruzione fsqrt e 1/fsqrt in 3dnow e
>sse, se si puo' fare tutto con gli shift?
che c'entra,non ho detto che le istruzioni 3dnow e sse sono inutili,
ho solo detto che si puo' fare l'operazione di reciproco sulla matrice
senza tabelle.
partendo dal fatto che:
1/sqrt(n)=n^(-1/2)
e tenendo conto del formato dei numeri in virgola mobile a singola
precisione, si puo' usare questo codice per il reciproco della sqrt
(ovviamente bisogna anche tenere conto della polarizzazione
dell'esponente):
float RcpSqrt(float flt)
{
unsigned int& i = *(unsigned int*)&flt;
int exp1=(i>>23);
unsigned int mant=i&0x3fffff;
exp-=127;
exp1>>=1;
exp1=-exp1+127;
unsigned int res=mant|(exp1<<23);
float f = *(float*)&res;
return f;
}
ovviamente si puo' fare tutto in maniera molto piu' ottimizzata con
opportune maschere e/o ricorrendo all'assembly...
ora pero' spiegatemi voi come fate a fare una tabella 1/sqrt(n) in 4k
8->
friol
Simone Freato
friol wrote:
> float RcpSqrt(float flt)
> {
> unsigned int& i = *(unsigned int*)&flt;
>
> int exp1=(i>>23);
> unsigned int mant=i&0x3fffff;
>
> exp-=127;
> exp1>>=1;
> exp1=-exp1+127;
>
> unsigned int res=mant|(exp1<<23);
>
> float f = *(float*)&res;
> return f;
> }
>
La mantissa e' sbagliata cosi'.
>
> ora pero' spiegatemi voi come fate a fare una tabella 1/sqrt(n) in 4k
> 8->
La tabella di 4k serve per la mantissa, appunto :)
Blade / Absurd
FrOYd
says...
[radice quadrata]
> partendo dal fatto che:
> 1/sqrt(n)=n^(-1/2)
Questa cosa e' vera con i numeri reali, non con i floating point, mi
pare.
Che risultati ottieni facendo la radice quadrata di 3, 4 e 5?
Boh, io non mi trovo.
Ciddi3d
> float RcpSqrt(float flt)
> {
> unsigned int& i = *(unsigned int*)&flt;
>
> int exp1=(i>>23);
> unsigned int mant=i&0x3fffff;
>
> exp-=127;
> exp1>>=1;
> exp1=-exp1+127;
>
> unsigned int res=mant|(exp1<<23);
>
> float f = *(float*)&res;
> return f;
> }
Beh, con questa 1/sqrt non hai la precisione per fare NIENTE.
Sicuramente non puoi normalizzare i vettori. (che e' poi quello per cui
uso 1/sqrt, di solito).
> ora pero' spiegatemi voi come fate a fare una tabella 1/sqrt(n) in 4k
> 8->
no, huhuhu 8-)
--
ciddi3d^Z
www.dronez.com
Mura/Turbo
friol <fr...@llpp8.inet.it> wrote in message
384920f7...@news.tiscalinet.it...
> c...@niente.com (Ciddi3d) ha scritto:
>
> [1/sqrt(n)]
> >> cmq non c'e' bisogno di fare tabelle,basta uno shift
> >Si'? E perche' mai hanno messo l'istruzione fsqrt e 1/fsqrt in 3dnow e
> >sse, se si puo' fare tutto con gli shift?
>
> che c'entra,non ho detto che le istruzioni 3dnow e sse sono inutili,
> ho solo detto che si puo' fare l'operazione di reciproco sulla matrice
> senza tabelle.
>
>
> 1/sqrt(n)=n^(-1/2)
>
> precisione, si puo' usare questo codice per il reciproco della sqrt
> (ovviamente bisogna anche tenere conto della polarizzazione
> dell'esponente):
>
> {
> unsigned int& i = *(unsigned int*)&flt;
>
> int exp1=(i>>23);
> unsigned int mant=i&0x3fffff;
>
> exp-=127;
> exp1>>=1;
> exp1=-exp1+127;
>
> unsigned int res=mant|(exp1<<23);
>
> float f = *(float*)&res;
> return f;
> }
>
> opportune maschere e/o ricorrendo all'assembly...
>
> 8->
>
ecco una bella tabellonza di 256 entry presa che uso
unsigned int fast_sqrt_table[256];
unsigned int fast_rcpsqrt_table[256];
void build_sqrt_tables(void)
{
unsigned short i;
float f;
unsigned int *fi = (unsigned*)&f;
for(i = 0; i <= 0x7f; i++)
{
*fi = 0;
// prima parte della tabella
*fi = (i << 16) | (127 << 23);
f = (float)sqrt(f);
fast_sqrt_table[i] = (*fi & 0x7fffff);
*fi = (i << 16) | (127 << 23);
f = 1.0f/(float)sqrt(f);
fast_rcpsqrt_table[i] = (*fi & 0x7fffff);
// seconda parte
*fi = 0;
*fi = (i << 16) | (128 << 23);
f = (float)sqrt(f);
fast_sqrt_table[i+0x80] = (*fi & 0x7fffff);
*fi = (i << 16) | (128 << 23);
f = 1.0f/(float)sqrt(f);
fast_rcpsqrt_table[i+0x80] = (*fi & 0x7fffff);
}
}
ora se la vuoi estendere a 4k e' na cazzata, basta modificare un niente.
friol
[...]
>> ora pero' spiegatemi voi come fate a fare una tabella 1/sqrt(n) in 4k
>> 8->
>ecco una bella tabellonza di 256 entry presa che uso
>unsigned int fast_sqrt_table[256];
>unsigned int fast_rcpsqrt_table[256];
[...]
>ora se la vuoi estendere a 4k e' na cazzata, basta modificare un niente.
e' talmente una cazzata che e' gia' di 4 k
friol