Newsgroup: it.comp.giochi.simulatori.volo
Titolo: Per Umberto e l'AGP...

A questo sito 
http://www.pc-extreme.com/artikel/tuning/agp/
 fanno
vedere come le differenze tra AGP1x e AGP2x/4x siano minime per non
dire nulle... >:-P
Se non ti ricordi fa nulla. ^__-
-- 
Dio... non fateci troppo affidamento: Dio è un burlone...
... purtroppo lo è su scala COSMICA: è quello, che ci frega tutti...
----
e-mail: 
ulis...@iol.it
ICARUS: 
http://users.iol.it/ulisse31

 Se non ti ricordi fa nulla. ^__-
Fare i benchmark senza capire il funzionamento di quello che si sta testando e' 
completamente inutile...
Come ho gia' detto, ripetuto e confermato, l'AGP puo' avere un grosso impatto 
sulle prestazioni, ma non auto-magicamente, solo in determinate condizioni, 
cioe' SE il programma usa il T&L, SE il programma trasferisce i triangoli 
ordinati in un certo modo ( solo in OpenGL ci sono 6 diversi modi di trasferire 
i triangoli e non tutti usano i trasferimenti AGP ) e SE la somma di memoria 
richiesta da texture+dati geometrici+buffer video supera la dimensione della 
VRAM della scheda video.
Quando una geometria complessa deve essere mandata dalla RAM del PC alla scheda 
video, viene fatto un trasferimento usando l'AGP, SIA delle texture ( questo 
con praticamente tutte le schede AGP ) e SIA dei dati poligonali, questo solo 
con le schede che hanno il T&L, nei programmi che lo abilitano.
Ovviamente, se sta girando un benchmark o un gioco, se tutti i dati necessari 
entrano nella VRAM, dopo la prima volta che viene trasferito tutto via AGP, non 
viene piu' fatto NESSUN trasferimento per tutto il resto del gioco o del test, 
per cui e' *OVVIO* che e' completamente ininfluente la velocita' del primo 
trasferimento, visto che dopo non ne vengono piu' fatti.
La differenza la si vede solo quando vengono usati scenari estremamente 
complessi, pieni sia di poligoni che di texture, che eccedono la VRAM della 
scheda video. Cosa che si riscontra molto meno nei giochi commerciali ( dato 
che si cerca in genere di tenere almeno gli scenari di default entro limiti 
normali per l'hardware che c'e' in commercio ) e molto piu' frequentemente in 
prodotti aggiuntivi, specialmente con FS2002, un po' perche' e' possibile 
utilizzare ed installare piu' scenari contemporaneamente, anche nella stessa 
zona, un po' perche' chi fa scenari per FS2002 non sempre e' un programmatore 
professionista e quindi spesso tralascia di perdere tempo ad ottimizzare ( 
tenendo conto che molti add-on sono gratuiti ), e anche perche', oltre agli 
scenari, la complessita' poligonale della scheda e i requisiti di memoria sono 
contesi oltre che dagli scenari, anche dagli aerei aggiuntivi ( molto piu' 
complessi di quelli standard ) e dagli aerei dell'ATC, che possono aumentare di 
numero e memoria richiesta ( ognuno ha i suoi poligoni e le sue texture ), 
anche solo aumentando la frequenza dei voli o il numero di piazzole in un 
aeroporto, andando quindi ben oltre le stime iniziali di complessita' prevista 
che puo' avere fatto la Microsoft quando lo hanno programmato, tarandolo magari 
per funzionare bene con schede video da 32MB con aerei e scenari di default.
E' chiaro che, piu' VRAM c'e' sulla scheda video, piu' la velocita' dell'AGP 
conta meno, perche' sara' sempre piu' difficile per un programma trovarsi ad 
esaurire la memoria video.
Infatti, il benchmark del sito che hai segnalato, conferma perfettamente 
questo, dato che hanno usato come test programmi abbastanza vecchi ( demo001 di 
Quake, per esempio, e' il demo di default ), che giravano gia' senza problemi 
con schede con 32MB di VRAM, fatti girare pero' con una scheda con 128MB!
Ci credo che l'AGP non conta nulla, tutti i dati di quei giochi entrano nella 
VRAM, e l'AGP non viene *mai* chiamato in causa, tranne nel primo fotogramma 
del gioco, quando vengono mandati i dati.
Volevano testare la velocita' dell'AGP ? Andava fatta la prova con uno scenario 
estramamente complesso, tipo 30MB di texture e almeno 20 mila poligoni di 
scena, su una scheda da 32MB, cioe' una situazione molto simile ad un FS2002 
caricato di add-on con una scheda simile a quella che hanno la maggioranza 
delle persone oggi.
E non pensare che, con l'avvento delle schede da 128MB o 256MB, il problema 
sparira'. Ci saranno semplicemente giochi con scenari sempre piu' complessi, 
che questi MB in piu' li useranno tutti. Basta usare estensivamente 
multitexturing e bump-map, e vedi che in un attimo i requisiti di memoria 
possono come niente quadruplicare. 
Umberto Colapicchioni
http://www.virtualisoftware.com