Newsgroup: it.comp.hardware.video-3d
Titolo: R: Hal-300 GrW1...miei c.....!

non sei d'accordo??
no (o almeno non del tutto) per tutto quello che ho gia' scritto sopra :)
ciao,
Marco
p.s. ho crosspostato su it.comp.hw.video-3d perche' perche' siamo
     pesantemente OT, sarebbe meglio che il tuo reply arrivasse solo su
     questo ng e non su it.comp.hw.cpu, altrimenti ci linciano :)
 

 questo e' vero solo se hai un triple buffering.
mmmhhhh.... perche'??? dal pto di vista HW se ho un tempo t0 (1/vsync) per
finire il rendering di una scena prima che ci sia lo switch sul frame buffer
(suppongo di lavorare con un frame buffer doppio, come normalmente d'uso),
qual e' la differenza nello sfruttare 0.001*t0 oppure 0.999*t0 per finire la
stessa?? (sto parlando in termini esemplificativi, lo so che ci sono anche
sgn di sincronismo e che lo switch non puo' avvenire in t=0).
in ambo i casi avro' un fps=vsync.
diverso invece il caso 0.9*t0 e 1.1*t0, ma qui ricadiamo nel discorso
maxfillrate.
dove sbaglio???
ciao
PS
visto che mi sembra che te ne intendi abbastanza, se mi permetti me ne
approfitto.... ;-))
lasciando per ora da parte tutte le considerazioni tecniche su cui stiamo
discutendo, e mettendoci in un ottica, diciamo, + commerciale, secondo te la
GeForce avra' successo?? voglio dire, dai dati di targa mi pare di capire
che il throughput della scheda (sia come fillrate che come poligoni/sec)
possa essere paragonabile ad una accoppiata K7 700 + G400 max (mi sono
tenuto largo, IMHO basterebbe un K7 600 con codice ottimizzato).
per cui, a livello di mercato, avra' una vita da "novita'" per al max 1-2
mesi.
inoltre c'e' il prob del codice, quante SWHouse si metteranno a
riscrivere/ricompilare per sfruttare GPU sulla scheda?
infatti, e su questo direi che sono abbastanza sicuro visto che e' il mio
campo, non bastera' aggiungere una libreria o un driver ottimizzato, ma
occorre andare a intervenire sul codice del motore per sostituire tutte le
routine (che attualmente usano la fpu) con opportuni link a delle funzioni
di libreria che si appoggiano sulla GPU della scheda. e tutto questo per una
sola scheda e per di + che dopo 1-2 mesi sara' superata da altre
soluzioni?????????
IMHO la cosa si risolvera' in un grosso hype, che all'inizio portera'
tantissima gente con un k6 a svenarsi per prendere la scheda (che dovendo
mantenere anche i dati geometrici in mem locale dovra' avere almeno 48MB di
ram, altrimenti e' inutile la gpu sulla scheda se mi devo scaricare i dati
dalla ram di sistema) salvo poi accorgersi dopo poco tempo che investendo
solo poco di + avrebbero preso una soluzione molto + scalabile e molto +
duratura (cavoli, io con le mie V2 sli sono passato attraverso un k6 200, un
P2 233, un mendo 450, e non intenzione di cambiarle per almeno altri 6
mesi.......)
PPS
o porca miseria, mi sono accorto di aver scritto un romanzo, speriamo che
mo' che semo passati su ICH.VIDEO-3D non ci lincino uguale.....

 d'arrivo l'nv15 :-)))))
beh.... dalle ultime info che mi ritrovo, sembra essere previsto per
febbraio/marzo. (cmq io ho gia' deciso per una scheda con un full
geometric setup, indi per cui.......)
ciao
PS scusa per i brutali <snip> ma ho dovuto "scremare" senno' arriviamo ai
20k di msg..............

molto).
beh..credo che 64 mega di ram per queste schede video saranno lo
standard.
La ge256 dovrebbe avere memoria a 5 ns (200 mhz).
ciao,
Marco


ssembrler 6502? buaaahh!! che ricordi... 
Mi ricordavi il divertimento a scrivere codice per un campo stellare
paralattico a 3 livelli usando  il refresh di chars appositamente
disegnati...
E il bello E' che si poteva usare con il basic...
L'effetto era magnifico quasi 3d....
-- 
Sidewinder  
---------------------------------------------------------------------
"Well, here's something to occupy you and keep your mind off things." "It
 won't work, I have an exceptionally large mind." - HHGG
---------------------------------------------------------------------

 La ge256 dovrebbe avere memoria a 5 ns (200 mhz).
appunto. ai prezzi attuali una scheda con tanta ram di quel tipo costera' +
di 1MŁ. imo decisamente troppo. sicuramente faranno uscire modelli con 16 e
32 e ci sara' altrettanto sicuramente chi dira' che + ram non serve.
mi spiace solo per i polli che ci cascheranno e butteranno i loro soldi.
ciao

esecuzione da fpu]
nada :)
Faccio un'ultimo esempio.
Sotto OpenGL esistono 2 funzioni:
LoadMatrix(gl_float *m(16))
MultMatrix(gl_float *m(16))
La prima carica una matrice, la seconda moltiplica la matrice
caricata in precedenza con la nuova passata in input (si passa
un puntatore a un vettore di 4x4=16 valori in floating point).
Se si conosce un po' di algebra lineare con queste 2 funzioni
praticamente si riesce ad implementare quasi tutto l'engine
geometrico.
Ora come vedi..tu dal tuo sorgente le chiami e te ne freghi
se gireranno su una macchina con gpu o senza.
Ci pensera' poi il driver fornito dal produttore ad usare
la gpu oppure l'unita' vettoriale del tuo processore (se esiste).
ciao,
Marco

 Al resto ci pensa il driver.
sinceramente ho sempre saputo diverso.
purtroppo (o per fortuna, scegli tu) io mi occupo principalmente di macchine
pro, dove l'architettura SW e' esattamente quella che ti ho descritto:
1) il prg chiama una api funct standard.
2) l'api chiama il minidrv (una semplice tabella si/no) per vedere se la
funzione standard richiesta e' implementata in HW.
3a) si --> la passa al driver vero e proprio, che la esegue in HW (cioe'
attiva una implementazione HW (un circuito, pe' capisse) della funzione
richiesta).
3b) no --> la esegue in emulazione SW.
ovviamente per fare questo occorre definire uno std (le funct dell'api
appunto) per la libreria in questione, altrimenti il minidriver dovrebbe
essere una sorta di decoder (un wrapper) anziche' una semplice tabella, con
evidente decadimento delle prestazioni.
se invece la situazione e' quella che tu hai descritto allora hai ragione,
ma sinceramente ancora adesso mi suona strano, a meno che nvidia non abbia
implementato in HW DIRETTAMENTE tutte o le principali chiamate ad una
specifica libreria (cosi' come ha fatto 3dfx con le glide; da notare che il
supporto Dx (almeno fino alla V2) era fatto proprio con un mini-wrapper, con
le conseguenze che tutti conoscono, ovvero prestazioni moooooolto inferiori
rispetto alle glide), con il che pero' le apps dovrebbero essere scritte
solo sotto quella libreria.
cmq, visto che sostanzialmente si tratta di aspettare qualche mese e vedere
all'opera la scheda su apps vere e non su bench, direi che potremmo chiudere
con una frase fatta: "chi vivra' (sgrat sgrat sgrat......;-)) ) vedra'"
ciao
PS mi sono scaricato Q3 arena pero' non mi funge, mi sa' che devo smanettare
qlcs. appena ho qualche risultato ti faccio sapere. oh, appro, mi sono
scordato di precisare che i 100fps (e oltre) in Q2 si riferiscono ad una
combo mendo 504 + 2*V2@100MHz a 1024x768 con demo2
PPS breve aggiornamento. sono stato allo stand creative a vedere la
annihilator. sinceramente non mi ha stupito + di tanto (anzi proprio per
nulla); per onesta' pero' devo dire che i commessi sottoposti ad adeguato
interrogatorio (all'inizio non volevano rispondere, poi mi sono qualificato
come rappresentante, eheheheheheheh banfa clamorosa........) si sono un po'
scuciti dicendo che i driver in realta' ancora non erano pronti (stavano
usando una alpha) e che non potevano mandare la scheda al max per grossi
prob di surriscaldamento del chip (che dovrebbe essere costruito a 0.22u.
ecchecavolo!!! e che gli serve uno 0.13??????). la prima questione e' solo
un prob di tempo, la seconda no......
non vorrei si riproponesse la stessa storia del TnT........
oh, appro, un responsabile mi ha anche detto che il taglio di ram ideale per
la scheda e' 64MB, al di sotto le prestazioni peggiorano in maniera
sensibile (in effetti loro stavano usando una 32MB). non mi chiedere perche'
che' tanto non lo so'.....

che' tanto non lo so'.....
serve tanta tanta memoria per le geoemtrie :)
(Ti ricordo che anche se carichi una scena totalmente sulla memoria
della scheda grafica, durante il processo di calcolo delle geometrie
ti serve ALMENO il doppio della memoria che hai gia' allocato
per le  geometrie stesse.
Se poi attivi anche il calcolo delle luci, probabilmente le richieste
di memoria raddoppiano ulteriormente)
ciao,
Marco
------------------------------------------------------
Marco Salvi - Bologna  University - Physics Department
e-mail:  
mar...@cadvlsi1.df.unibo.it
web:     
http://cadvlsi1.df.unibo.it
------------------------------------------------------

 di memoria raddoppiano ulteriormente)
sisisisisi, la mia voleva solo essere una battuta..... se ti rileggi i miei
post noterai che una delle mie osservazioni principali e' proprio che la ram
al minimo deve essere 64MB per non far crollare le prestazioni. sarebbe un
assurdo avere la gpu sulla scheda e i dati nella ram di sistema........
ciao

girare il demo.
lo sapevo..qualche difetto la v2 doveva avercelo :)
Come..sei proprio sicuro che giri in modalita' soft?


 Come..sei proprio sicuro che giri in modalita' soft?
sicuro al 100% no, pero' mi sembra proprio strano che non faccia una piega
se lo faccio girare su un driver vga generico a 16 colori, che ovviamente
non supporta le chiamate OGL........
IMHO l'unica e' che tali chiamate sono risolte in emulazione SW.
il dubbio m'e' venuto confrontando i risultati della  la mia G100 con una
Fire 3000, che tira fuori poco + di 5fps su un P3 600@672.
un po' troppo vicini, considerando che la G100 NON HA ALCUN ICD mentre la
fire3000 ha (aveva) uno dei migliori e + completi supporti OGL (non ho avuto
tempo di provarlo sulla E&S che abbiamo in lab, appena riesco a rubare 5min
ti faccio sapere).
ora, io non dico che il demo e' fasullo, pero' certo non e' molto "fair" nel
senso che se anche una G400 non ha l'HW per fare le T&L magari pero' un po'
+ veloce di 4fps ci va' se le altre chiamate OGL le risolvi in
HW..............
insomma, ognuno se fa' li bench sua.........
(nvidia non e' la prima e non sara' di certo l'ultima)
ciao

Fire 3000, che tira fuori poco + di 5fps su un P3 600@672.
Sul simple o sul complex??
BTW secondo me se non trova un icd le chiamate Ogl  magari se le
risolve in software, ma se ce il driver  sicuramente lo usa, 
anche perche'  e' un demo dichiarato ogl, e poi nel readme parla di
varie issues per diverse schede grafiche provate sulla stessa
macchina, segno che il bench utilizzava i rispettivi driver Ogl.
D'altro canto la gestione dell'Ogl non e' rilevante in un test di
questo tipo, poiche se non c'e un supporto hw per il T&L, sara' sempre
la scheda video ad aspettare(e di parecchio) la cpu, ecco il perche'
dell'appiattimento dei valori .
Diverso il discorso se si confronteranno due schede col T&L
es. gf256 e savage2000.
La cosa che mi ha cmq sorpreso e' che dalle prime prove del gf256
il complex fa + di 14 fps quando io col mio cel550 (la sk video imho
non ha importanza)  non faccio + di 2,5 fps; si risolve
maccheronicamente che per il T&L una scheda come il gf256 esprime la
potenza di un celeron di oggi  a 3Ghz !!!!!???
Ciao
ZiPpOoooo

 potenza di un celeron di oggi  a 3Ghz !!!!!???
se parliamo di mendo in particolare e' giusto, ma io ho sempre parlato di
K7.
un K7 ha 3 pipe fp, 2 possono eseguire codice fp/mmx/e3dnow, l'altra puo'
eseguire codice fp/mmx, il tutto simultaneamente e senza limitazioni. quindi
sostanzialmente con codice ben scritto (una rarita' di questi tempi, ne
convengo) anche senza e3dnow arrivi per il K7 700 ad un mendo simil-2.1GHz.
se poi consideri che le 3 pipe ti consentono di giocare con l'esecuzione
fuori sequenza e altre cosuccie ti accorgi che e' anche di +. cmq lasciamo
stare queste "finezze". adesso consideriamo il nostro simil-2.1GHz e
applichiamoci un codice e3dnow: IMHO si superano tranquillamente i famosi
3GHz. ecco perche' ho sempre detto e ripetuto che IMVVVVVVVVVVVVVVHO, la
soluzione GeForce e' superata gia' ora (o meglio, sarebbe superata se le
SWhouse ottimizzassero i loro prg anche per K7+E3DNow).
un ultimo appunto: nvidia parla di svariati GFlops per la sua unita' gpu.
attenzione a non prendere abbagli: quel numerello si riferisce alla unita'
gpu in alimentazione costante teorica, il che tradotto vuol dire che quel
numero si ottiene con una ram che avesse una latency=0 e una freq operativa
pari alla gpu stessa, e che inoltre non debba servire nessun'altra cpu/chip.
sulla ge oltre alla gpu la ram deve servire le 4 pipe di rendering e il dac,
senza considerare che la latency di qualunque ram (anche della + veloce
sram) non puo' mai essere 0 se confrontata con gli attuali clock di cpu.
in pratica quindi quel famoso numerello NON VIENE MAI RAGGIUNTO; anzi in
conf "reale" non viene mai neanche avvicinato.
ciao

un ultimo appunto: nvidia parla di svariati GFlops per la sua unita' gpu.
Mai preso in seria considerazione le press release ;-)
Ciao
ZiPpOooooo

 ma non pensavo ad un salto prestazionale cosi' marcato.
il pto e' che sia i bench che i prg sono ottimizzati per la singola fpu del
P2/P3, il che implica (ad es.) che quando devo fare una serie di fp il
compilatore puo' decidere di inserire dei nop tra una fp e l'altra, in modo
da ottimizzare la pipe, un po' quello che succede con le joc. pero', mentre
cosi' si ottimizza il codice per il P2, si ammazza quello per K7, che invece
potrebbe mandare in execute fino a 3 fp in contemporanea.
ciao