[HWVintage] Retrogaming avanti tutta

[Murakami]

mi hanno regalato una diamond multimedia da 4 mega!!! :sofico: :flower: :cry:

E che roba è... :mbe:

[walter sampei]

E che roba è... :mbe:

d'oh!!! mi sono dimenticato di mettere il nome del modello!!! :muro:

comunque e' uguale a questa

http://www.falconfly.de/identify/Diamond_Monster_3D.jpg

[Max_R]

E' una Monster 3D :D Di Diamond (multimedia) :sofico:

[Saragot]

d'oh!!! mi sono dimenticato di mettere il nome del modello!!! :muro:

comunque e' uguale a questa

http://www.falconfly.de/identify/Diamond_Monster_3D.jpg

Che spettacolo!!!

[Saragot]

Ragazzi, ho qualche buona notizia: mi faccio prestare un p3 800 da un amico per fare i test!!!!
Ed il bello è che sul p3 c'è montata una voodoo5 5500!!!
Quindi ora posso testare una ati rage fury maxx, una voodoo 2 , una voodoo 5 , la kyro 2 e forse una tnt2 m64

[Crisp]

1000 - 933 = 67... :stordita:

io parlavo del bus, da 100 a 133 :)

[walter sampei]

Ragazzi, ho qualche buona notizia: mi faccio prestare un p3 800 da un amico per fare i test!!!!
Ed il bello è che sul p3 c'è montata una voodoo5 5500!!!
Quindi ora posso testare una ati rage fury maxx, una voodoo 2 , una voodoo 5 , la kyro 2 e forse una tnt2 m64

doppio, chiedo scusa :(

[walter sampei]

Ragazzi, ho qualche buona notizia: mi faccio prestare un p3 800 da un amico per fare i test!!!!
Ed il bello è che sul p3 c'è montata una voodoo5 5500!!!
Quindi ora posso testare una ati rage fury maxx, una voodoo 2 , una voodoo 5 , la kyro 2 e forse una tnt2 m64

megacomparativaaaaaaaaaa :sbavvv: :ave:

http://scott.club365.net/uploaded_images/drooling_homer-712749.gif

[Murakami]

Ragazzi, ho qualche buona notizia: mi faccio prestare un p3 800 da un amico per fare i test!!!!
Ed il bello è che sul p3 c'è montata una voodoo5 5500!!!
Quindi ora posso testare una ati rage fury maxx, una voodoo 2 , una voodoo 5 , la kyro 2 e forse una tnt2 m64
Vai, Saragot: stai entrando con pieno merito nella ristretta cerchia dei retrogamers... :O
Vedremo anche come va il tuo P3 800 rispetto al mio "lento" 1000: puoi subito fare una comparazione con il Kyro 2 usando Forsaken e Quake 2.

[Murakami]

d'oh!!! mi sono dimenticato di mettere il nome del modello!!! :muro:

comunque e' uguale a questa

http://www.falconfly.de/identify/Diamond_Monster_3D.jpg
La mitica: con clock a 57 mhz (usando i drivers Diamond) contro i 50 di default.

[Murakami]

A me piacerebbe procurarmi un P3 1000/256/133: vedrò se mi riesce... e anche un P3 933, per andare alla pari dei test di quasi 3 anni fa.
Nel mentre, un amico mi ha regalato un P3 800/256/133: mi sa che 200 mhz di differenza, però, siano un pò troppi per giustificare la sostituzione con il P3 1000/256/100... :p

[Murakami]

Cavolo,allora non puoi fare nulla... se non segare il bordo del case! :D

Non riesco a fare i test di fill rate che mi hai chiesto: il GeForce 2 è una delle schede per testare le quali dovrei segare il case... :fagiano:

[Max_R]

Posso farlo io questo test del fill rate. Con quale 3D Mark lo eseguite? 2001 SE?
Ho una GTS ed una Ultra.

[ReDeX]

io ho trasformato una 9600 passiva in modo molto simile alla tua tranne che per i dissipatorini sulle ram.
l'ho imprestata e si è bruciata ,chi l'ha usata si è dimenticato di collegare l'allimentazione della ventolina :mad:
Era una bella vga per assemblare computer per vecchi giochi..

Col cavolo, diciamo piuttosto che c'erano sopra 10 strati di sporco incrostato e che dava già segni di cedimento. :O

[Murakami]

Posso farlo io questo test del fill rate. Con quale 3D Mark lo eseguite? 2001 SE?
Ho una GTS ed una Ultra.

Si, ti prego, fallo: chiedi a Shodan, lo desidera da 3 anni... :mc:
Mi vendi la Ultra? :sofico:

[Max_R]

Non ho nulla da vendere, giusto un po' di materiale del quale sbarazzarmi e la Ultra non ne fa parte ovviamente :bimbo:

[Murakami]

Ho montato il nuovo dissipatore passivo a heat pipe sul GeForce 4 TI 4600: una bellezza. Ho poi installato la scheda sul PC principale (Venice 3000+) e ho constatato che i driver 43.51 consentono si l'abilitazione dello Z occlusion Culling, ma per il resto sono mediocri: gestione del doppio monitor assai carente e confusa, pannello di controllo scarno, mancanza di supporto alle SSE3; persino lo scrolling della pagine web è rallentato.
Ora li provo con Forsaken e di seguito i 93.71: vediamo chi vince.
Domani formatto, che è meglio... :stordita:

[Murakami]

Bah, mi sa che ho incasinato tutti installando, disinstallando e reinstallando varie versioni di drivers: i risultati sono incoerenti, ma in ogni caso Forsaken gira troppo forte e l'fps counter del gioco (che registra, comunque, una media di 525 fps, con picchi in quadrupla cifra) non è affidabile.
Format in arrivo: in tutti i casi, CPU e GPU raffreddati passivamente reggono bene bench in loop... posso ritenermi soddisfatto.

[Saragot]

Cos'è lo Z occlusion Culling ?

[Max_R]

E' una sorta di HSR che dovrebbe sgravare la gpu dal calcolo dei triangoli posti dietro ad altri elementi e quindi nascosti da questi ultimi ;)

[Malek86]

E' una sorta di HSR che dovrebbe sgravare la gpu dal calcolo dei triangoli posti dietro ad altri elementi e quindi nascosti da questi ultimi ;)

Come per il PowerVR, dunque?

Ma doveva avere dei problemi, dato che poi l'hanno rimosso e non l'hanno mai ripreso in futuro :what:

[walter sampei]

Come per il PowerVR, dunque?

Ma doveva avere dei problemi, dato che poi l'hanno rimosso e non l'hanno mai ripreso in futuro :what:

si, il problema che la 5200 faceva schifo ma dovevano venderla :sofico:

scusate, mi e' scappata :p

[Malek86]

si, il problema che la 5200 faceva schifo ma dovevano venderla :sofico:

scusate, mi e' scappata :p

E' la seconda volta che sento dire questa storia :p ma non riesco a capire bene il collegamento fra le FX e l'assenza di Occlusion Culling.

[walter sampei]

E' la seconda volta che sento dire questa storia :p ma non riesco a capire bene il collegamento fra le FX e l'assenza di Occlusion Culling.

semplice: quando sono uscite le fx, era evidente che le nuove schede erano piu' lente. e soprattutto, usare qualcosa in modalita' dx 9 (caratteristica tanto sbandierata) significava un crollo di prestazioni. poi i polli che leggono 5200 e pensano "5200>4200, quindi e' piu' veloce" ci sono sempre.

per cui ricordo che all'epoca in molti dicevano che nvidia con le nuove release dei driver voleva "castrare" le geffo4 per rallentarle o comunque spingere il nuovo prodotto.

[shodan]

Si, stai usando gli ultimi disponibili, ma temo che per vecchi giochi non siano i più adeguati: in particolare, ricordo anche io l'impossibilità di far funzionare la modalità a 32 bit in Slave Zero. Prova con driver più vecchi, come i 43.45.
E' il gioco che sceglie il tipo di bump mapping a seconda della scheda che trova: nel tuo caso usa l'embossing, una tecnica di multitexturing che richiede l'applicazione di tre texel per pixel. Dato che il TNT è dotato di due unità di texture mapping, lo esegue in due passate, dimezzando di fatto il suo fill rate: fortunatamente, l'effetto è applicato solo al robot del giocatore... :p

Ciao,
in realtà, usando l'emboss a 3 passaggi (ne esiste uno di qualità inferiore con 2 passaggi), il fill-rate del TNT si divide almeno per 3. Infatti, dovendo applicare 3 texture per pixel, e avendo un'architettura di tipo 2x1, è normale che il fill-rate scenda vertiginosamente.
In realtà, probabilmente, l'applicazione dell'emboss potrebbe addirittura dividere per 4 (e non per 3) le prestazioni del TNT. Questo perchè, in base a vecchie letture su Beyond3D, ricordo che il TNT ha delle limitazioni quando opera in multitexture, e una di queste limitazioni indicava che tale chip può operare in multitexture solo "agganciando" le due pipeline. Cerco di essere più chiaro:
CLOCK-1 TMU-1:impegnata TMU-2:impegnata
CLOCK-2 TMU-1:impegnata TMU-2:idle
TOTALE: 1 pixel ogni 2 clock, o, se preferite, 1 pixel ogni 4 operazioni di texturing.

Ovviamente tali calcoli sono validi _solo_ se quanto ricordo è corretto. Potrei infatti ricordare male io o potrebbero essere comunque informazioni non esatte. Quasi quasi rispolvero il mio bench opengl per dotarlo di funzioni di emboss... ;)

Ciao. :)

[shodan]

dunque raga per l'occasione mi dovrebbero entrare un bel po di VGA ciabattose da retrogame da mettere sotto torchio :D


* VGA TRIDENT 3D IMAGE 9750 AGP 4MB

Sono Curioso di vedere i bench di questa scheda... vediamo se va davvero così male... ;)

* VGA S3 VIRGE/DX ON BOARD 8 MB

Sicuro che è una ViRGE DX classica? Mi pare di ricordare che un framebuffer di tale ampiezza (8 MB) fosse supportato solo dalle VX e dalle GX.

Ciao. :)

[Murakami]

Ciao,
in realtà, usando l'emboss a 3 passaggi (ne esiste uno di qualità inferiore con 2 passaggi), il fill-rate del TNT si divide almeno per 3. Infatti, dovendo applicare 3 texture per pixel, e avendo un'architettura di tipo 2x1, è normale che il fill-rate scenda vertiginosamente.
In realtà, probabilmente, l'applicazione dell'emboss potrebbe addirittura dividere per 4 (e non per 3) le prestazioni del TNT. Questo perchè, in base a vecchie letture su Beyond3D, ricordo che il TNT ha delle limitazioni quando opera in multitexture, e una di queste limitazioni indicava che tale chip può operare in multitexture solo "agganciando" le due pipeline. Cerco di essere più chiaro:
CLOCK-1 TMU-1:impegnata TMU-2:impegnata
CLOCK-2 TMU-1:impegnata TMU-2:idle
TOTALE: 1 pixel ogni 2 clock, o, se preferite, 1 pixel ogni 4 operazioni di texturing.

Ovviamente tali calcoli sono validi _solo_ se quanto ricordo è corretto. Potrei infatti ricordare male io o potrebbero essere comunque informazioni non esatte. Quasi quasi rispolvero il mio bench opengl per dotarlo di funzioni di emboss... ;)

Ciao. :)
Ciao bello, mi pare strano quanto dici: un'architettura capace di 2 texel per pixel per clock dovrebbe essere capace di applicare 3 texture in 2 passate... almeno credo... :p
Inoltre, in giochi come "Expendable" e "Slave Zero", il calo di prestazioni attivando l'embossing non è così drastico... :fagiano:
Se mi linki qualcosa, comunque, ne sono ben contento... :stordita:

[shodan]

Ma che razza di Radeon 7500 ho beccato? Core clock 214 mhz, mem clock 143 mhz, 128 mb di SDRAM... :doh:

Hai beccato una delle Radeon 7500 costruite per fare concorrenza alla GeForce2 MX400... in pratica, una Radeon SDR con core clock un po' più elevato (214 Mhz vx 166 Mhz) grazie alla tecnologia di produzione a 0,15u.

Ciao. :)

[Murakami]

Hai beccato una delle Radeon 7500 costruite per fare concorrenza alla GeForce2 MX400... in pratica, una Radeon SDR con core clock un po' più elevato (214 Mhz vx 166 Mhz) grazie alla tecnologia di produzione a 0,15u.

Ciao. :)
Lo so, sono stato sfigato (alla faccia dei dissipatori presenti su ogni modulo di ram): amen, le prove avranno comunque una loro valenza... :rolleyes:

[shodan]

Diciamo addio alla cara Tyan Soket 7 Agp ed Sdram con un mega di cache esterna :O
Dopo anni di sonno l'ho riesumata e lei ha preso fuoco :(

Montava un VIA Apollo MVP3 vero?

Riposi in pace... :cry:

[shodan]

Tanto per farmi un'idea delle potenzialità del muletto e vedere se è possibile comparare i risultati che ottengo con quelli ottenuti a suo tempo (P3 933 bus 133 mhz vs. P3 1000 bus 100 mhz), ho eseguito due veloci sessioni di test con "Forsaken" e "Quake 2", in modalità software, 640x480x16, massimo dettaglio.
Considerando che il chipset e il quantitativo di ram è lo stesso dei primi test, vado quindi a paragonare l'efficacia di frequenza della CPU e bus CPU-ram.
Abbiamo quindi:
Forsaken: 26.2 fps contro 22.5 del vecchio muletto;
Quake 2: 40.6 fps contro 48.4 del vecchio muletto.
Sorprendente: la frequenza della CPU la fà da padrona in Forsaken, quella del bus in Quake 2.
Possibile? :confused:

Come prestazioni dovremmo essere molto vicini, dato che i P3 risentono notevolmente della frequenza di bus. Non ni sorprende, quindi, il risultato di Quake2 (dove il processore con bus a 133 Mhz è più veloce); sono, invece, al di fuori di ogni logica i risultati di Forsaken: il P3 1000 ha frequenza solo di un 7-8% maggiore rispetto a quella del P3 993, eppure i risultati sono un buon 20% maggiori. Sicuramente c'è qualcos'altro che inficia le prestazioni del tuo nuovo muletto.

EDIT: leggendo il tuo messaggio seguente, potrebbero essere davvero i timings della ram o di altri componenti a penalizzare leggermente il tuo nuovo muletto...

Ciao. :)

[shodan]

d'oh!!! mi sono dimenticato di mettere il nome del modello!!! :muro:

comunque e' uguale a questa

http://www.falconfly.de/identify/Diamond_Monster_3D.jpg

:ave:

[shodan]

Non riesco a fare i test di fill rate che mi hai chiesto: il GeForce 2 è una delle schede per testare le quali dovrei segare il case... :fagiano:

:nera: :bsod: :lamer:

[Murakami]

Come per il PowerVR, dunque?

Ma doveva avere dei problemi, dato che poi l'hanno rimosso e non l'hanno mai ripreso in futuro :what:
Si, beh, comunque c'è qualcosa di strano in questa "estromissione", dato che riguarda pure il GeForce3 (che, in ogni caso, con le FX ha poco da spartire)... :wtf:
Vuoi che per due generazioni di chip abbiano introdotto una feature bacata a livello di implementazione hardware? E se ne accorgono dopo un paio d'anni? E fino a quel momento i giochi funzionavano bene? E che disturbo poteva dare, a livello di confronto di prestazioni, il GeForce 3 all'FX?

[shodan]

Posso farlo io questo test del fill rate. Con quale 3D Mark lo eseguite? 2001 SE?
Ho una GTS ed una Ultra.

Grande Max_R!!
Puoi usare direttamente la Ultra, portandola alle frequenze della GTS (ti spiego sotto perchè...).
Se non ti è di disturbo, dovresti utilizzare il 3D Mark 2000 e articolare il test in 3 fasi:
-) test 16/32 bit single/multitexture con clock della GTS (200/333);
-) test 16/32 bit single/multitexture con GPU a 250 Mhz e RAM a 333 Mhz;
-) test 16/32 bit single/mutitexture con GPU a 200 Mhz (come la GTS) e RAM a 460 Mhz (il valore standard della Ultra).

Così dovremmo finalmente essere in grado di capire come si comportano le pipeline del GF2 a 32 bit di colore...

Ciao grazie. :)

[shodan]

Ciao bello, mi pare strano quanto dici: un'architettura capace di 2 texel per pixel per clock dovrebbe essere capace di applicare 3 texture in 2 passate... almeno credo... :p

Si infatti, le applica in 2 passate... il punto è che in queste due passate le TMU vengono probabilmente impiegate 4 volte e, quindi, il fill-rate scende a 1/4.
Faccio una tabellina:
-) TNT @ 90 Mhz - fill-rate in single-texture: 180 mp/sec - textel-rate: 180 mt/sec - 2 px per clock;
-) TNT @ 90 Mhz - fill-rate in dual-texture: 90 mp/sec - textel-rate: 180 mt/sec - 1 px dual-textured per clock;
-) TNT @ 90 Mhz - fill-rate in tri-texture: 45 mp/sec - textel-rate: 120 mt/sec - 1 px tri-textured ogni 2 clock;

Perchè, in tri-texture, i valori sono di 1/4 e non di 1/3? Perchè, alla luce delle limitazioni del multitexture insite nel chip, nella seconda passata probabilmente una TMU rimane inattiva. Per evitare questo problema, il chip potrebbe funzionare come incapace di fare multitexture e quindi impiegare 3 passaggi per pixel ma usando una sola TMU per pixel. In altre parole, abbiamo due soluzioni:
-) impiegare 2 passate per pixel ma sprecando il lavoro di una TMU (e quindi abbattando il textel rate da 180 a 120 mt/sec) e avendo così 1 px ogni 2 clock;
-) impiegare 3 passate per pixel ma facendo lavorare le TMU su pixel diversi, avendo così 2 pixel ogni 3 clock ma incrementando almeno del 50% il traffico che transita da e verso il framebuffer.

I calcoli sopra riportati sono frutto di mie speculazioni (basate su quanto lessi in passato), beninteso... ma sono facili da verificare: qualcuno con il 3D Mark 2000 faccia girare il bench dell'emboss a 1, 2 e 3 passaggi e il bench del fill-rate su una scheda TNT e ne riporti i valori.


Inoltre, in giochi come "Expendable" e "Slave Zero", il calo di prestazioni attivando l'embossing non è così drastico... :fagiano:
Se mi linki qualcosa, comunque, ne sono ben contento... :stordita:

Si, è vero che il calo di prestazioni è ridotto, ma solo perchè il bump è applicato a una minima parte di quello che vedi a schermo... ;)

Ciao. :)

[Murakami]

Perchè, in tri-texture, i valori sono di 1/4 e non di 1/3? Perchè, alla luce delle limitazioni del multitexture insite nel chip, nella seconda passata probabilmente una TMU rimane inattiva.
Credi sia la stessa limitazione che impedisce il vero trilinear filtering in multitexture?

[Malek86]

I calcoli sopra riportati sono frutto di mie speculazioni (basate su quanto lessi in passato), beninteso... ma sono facili da verificare: qualcuno con il 3D Mark 2000 faccia girare il bench dell'emboss a 1, 2 e 3 passaggi e il bench del fill-rate su una scheda TNT e ne riporti i valori.

Va bene, dovrei poterlo fare. Vediamo un po'.

[Malek86]

Dunque... il test è girato a 640x480x32 perchè quello è il massimo del mio monitor.

Fillrate (single texturing): 26.6 MTexels/s
Fillrate (multi texturing): 50.9 MTexels/s
Bump Mapping Emboss (3-pass): 27.6 FPS
Bump Mapping Emboss (2-pass): 35.9 FPS
Bump Mapping Emboss (1-pass): 48.5 FPS

Sono valori prevedibili?

[shodan]

Dunque... il test è girato a 640x480x32 perchè quello è il massimo del mio monitor.

Fillrate (single texturing): 26.6 MTexels/s
Fillrate (multi texturing): 50.9 MTexels/s
Bump Mapping Emboss (3-pass): 27.6 FPS
Bump Mapping Emboss (2-pass): 35.9 FPS
Bump Mapping Emboss (1-pass): 48.5 FPS

Sono valori prevedibili?

Mmm... sono valori davvero strani, in quanto il fill-rate è estremamente basso.
Puoi rifarlo a 16 bit e, magari, usando il 3D Mark 99 MAX?

Ciao. :)

[shodan]

Credi sia la stessa limitazione che impedisce il vero trilinear filtering in multitexture?

Sostanzialmente si: il trilinear + multitexture richiede 2 volte i campionamenti necessari per il semplice bilinear + multitexture.
In altre parole, il fill-rate sarebbe ridotto a 1/4 (e forse anche meno, considerando il maggior carico sul bus verso la VRAM). Non deve sorprendere, quindi, che Nvidia abbia deciso di disabilitare il trilineare in presenza del multitexture (a livello driver, in quanto qualsiasi chip teoricamente potrebbe farlo usando il multipass).
In regime di single-texture, invece, il fill-rate viene ridotto "solo" di 1/2.

Chip con architettura 1x2, quali il Voodoo3, si comportano invece in modo molto diverso.
Normalizzando le prestazioni del semplice bilineare a 1, le prestazioni del trilineare sono:
-) in regime di single-texture, uguali a quelle del bilineare;
-) in regime di multi-texture, 1/2 rispetto a quelle del bilineare.

I test che abbiamo fatto fin'ora confermano quanto sopra: in giochi single-texture, il TNT, forte delle 2 pipeline, va decisamente meglio del Voodoo3; in Quake2/3, giochi fortemente multi-textured, le prestazioni tendono ad appaiarsi (i questi 2 giochi, entrambi i chip non usano il trilineare me solo il mipmap dithering).

Ciao. :)

[Murakami]

Dunque... il test è girato a 640x480x32 perchè quello è il massimo del mio monitor.

Fillrate (single texturing): 26.6 MTexels/s
Fillrate (multi texturing): 50.9 MTexels/s
Bump Mapping Emboss (3-pass): 27.6 FPS
Bump Mapping Emboss (2-pass): 35.9 FPS
Bump Mapping Emboss (1-pass): 48.5 FPS

Sono valori prevedibili?
Ma che TNT hai? :confused:

[Malek86]

Mmm... sono valori davvero strani, in quanto il fill-rate è estremamente basso.
Puoi rifarlo a 16 bit e, magari, usando il 3D Mark 99 MAX?

Ciao. :)

Ma che TNT hai? :confused:

Lo sapevo, stai a vedere che hanno rifilato un pacco anche a me :O :asd:

Il bios e anche il 3DMark, comunque, la riconoscono come Riva TNT. Sulla scheda c'è scritto "1290A"... c'è una ventolina della Aavid.

Boh, provo a 16bit e col 99 (e intanto vado a cercare una nuova scheda sulla baia :asd:).

EDIT: con 16 bit, vengono 57.9 MT/s e 73.7 MT/s.

EDIT2: con il 99MAX, a 640x480x16, vengono 55.3 MT/s e 95.6 MT/s.

[Max_R]

Montava un VIA Apollo MVP3 vero?

Riposi in pace... :cry:Via Apollo VP3.
Lo sapevo, stai a vedere che hanno rifilato un pacco anche a me :O :asd:

Il bios e anche il 3DMark, comunque, la riconoscono come Riva TNT. Sulla scheda c'è scritto "1290A"... c'è una ventolina della Aavid.

Boh, provo a 16bit e col 99 (e intanto vado a cercare una nuova scheda sulla baia :asd:).

EDIT: con 16 bit, vengono 57.9 MT/s e 73.7 MT/s.

EDIT2: con il 99MAX, a 640x480x16, vengono 55.3 MT/s e 95.6 MT/s.Una A-Trend TNT

Ora eseguo i test richiesti con 3D Mark 2000

[Malek86]

Una A-Trend TNT

Mai sentita questa A-Trend. E' normale che facciano schede con risultati così bassi?

[Murakami]

Mai sentita questa A-Trend. E' normale che facciano schede con risultati così bassi?

Mica tanto: hai verificato il clock di core e ram? L'interfaccia verso la ram è a 128 bit, vero?

[Malek86]

Mica tanto: hai verificato il clock di core e ram? L'interfaccia verso la ram è a 128 bit, vero?

Uhm, mi ci vorrebbe qualche programma per controllare, perchè non riesco ad accedere al pannello di controllo Nvidia (non si apre).

[Max_R]

A-Trend produceva 3Dfx :D Provato RivaTuner?

[Saragot]

Ragazzi, piccola curiosità, visto che siamo in tema...
Come mai usando il kyro 2 e il motore di quake 3 arena, le prestaxzioni variavano molto da bilinear a trilinear?
Succede solo a me, oppure è normale?

[Malek86]

A-Trend produceva 3Dfx :D Provato RivaTuner?

Non funziona, mi dice che mancano dei DLL e collegamenti ad alcune periferiche. Suppongo che Win95 sia troppo obsoleto.

Nessun altro programma disponibile?

[Max_R]

Test eseguiti a 1024x768 triple buffering
I risultati sono espressi in MegaTexel al secondo

Frequenze 200 / 333 @ 16 bit
551,3 in singletexturing e 1081,0 in multitexturing

Frequenze 200 / 333 @ 32 bit
275,8 in singletexturing e 553,5 in multitexturing

Frequenze 250 / 333 @ 16 bit
554,2 in singletexturing e 1086,5 in multitexturing

Frequenze 250 / 333 @ 32 bit
278,0 in singletexturing e 557,8 in multitexturing

Frequenze 200 / 458 @ 16 bit
689,5 in singletexturing e 1292,9 in multitexturing

Frequenze 200 / 458 @ 32 bit
378,9 in singletexturing e 757,0 in multitexturing

Frequenze 250 / 458 @ 16 bit
739,2 in singletexturing e 1410,4 in multitexturing

Frequenze 250 / 458 @ 32 bit
383,3 in singletexturing e 759,7 in multitexturing

Frequenze 125 / 458 @ 16 bit
464,3 in singletexturing e 889,7 in multitexturing

Frequenze 125 / 458 @ 32 bit
365,5 in singletexturing e 718,5 in multitexturing

[Murakami]

Ragazzi, piccola curiosità, visto che siamo in tema...
Come mai usando il kyro 2 e il motore di quake 3 arena, le prestaxzioni variavano molto da bilinear a trilinear?
Succede solo a me, oppure è normale?
E' normale: il Kyro ha grossi problemi con trilinear e anisotropic, per motivi già spiegati nelle prime pagine di questo thread.

[shodan]

Test eseguiti a 1024x768 triple buffering
I risultati sono espressi in MegaTexel al secondo

Frequenze 200 / 333 @ 16 bit
551,3 in singletexturing e 1081,0 in multitexturing

Frequenze 200 / 333 @ 32 bit
275,8 in singletexturing e 553,5 in multitexturing

Frequenze 250 / 333 @ 16 bit
554,2 in singletexturing e 1086,5 in multitexturing

Frequenze 250 / 333 @ 32 bit
278,0 in singletexturing e 557,8 in multitexturing

Frequenze 200 / 458 @ 16 bit
689,5 in singletexturing e 1292,9 in multitexturing

Frequenze 200 / 458 @ 32 bit
378,9 in singletexturing e 757,0 in multitexturing

Frequenze 250 / 460 @ 16 bit
739,2 in singletexturing e 1410,4 in multitexturing

Frequenze 250 / 460 @ 32 bit
383,3 in singletexturing e 759,7 in multitexturing

Ottimo Max_R, grazie mille!
Ti chiedo un'ultima prova: puoi rifare i test con la GPU @ 100 Mhz e le RAM @ 460 Mhz?

Grazie. :)

[Murakami]

Ottimo Max_R, grazie mille!
Ti chiedo un'ultima prova: puoi rifare i test con la GPU @ 100 Mhz e le RAM @ 460 Mhz?

Grazie. :)
Poi ci fai tu il riassuntino finale, eh? :read:

[shodan]

Poi ci fai tu il riassuntino finale, eh? :read:

Ok ok :D

[Max_R]

Ottimo Max_R, grazie mille!
Ti chiedo un'ultima prova: puoi rifare i test con la GPU @ 100 Mhz e le RAM @ 460 Mhz?

Grazie. :)Non so se sia prevista questa possibilità comunque vedo di provare domani. P.s. anche il downclock mette sotto stress i componenti!

[shodan]

Non so se sia prevista questa possibilità comunque vedo di provare domani. P.s. anche il downclock mette sotto stress i componenti!

Be, se non puoi arrivare a 100 Mhz va bene anche un'altra frequenza bassa... ;)
Il downclock ovviamente non mette sotto stress la scheda; paradossalmente, a volte, potresti avere artefatti, ma non appena riavvii torna tutto ok.

Allora aspetto i test... grazie mille! :)

[Murakami]

Tosi, ho trovato il P3 1000/256/133: appena mi arriva saggio la differenza! :O

[shodan]

Tosi, ho trovato il P3 1000/256/133: appena mi arriva saggio la differenza! :O

Vedrai che sarà sicuramente rilevante... ;)

[Max_R]

Ho aggiornato ;)

[shodan]

Ho aggiornato ;)

Grazie mille!

Allora, vediamo di fare un po' di calcoli: a 125 Mhz il GeForce2 dovrebbe sviluppare un massimo di 500 Mp/sec e 1 Gt/sec.
Tali valori sono approcciati dai test condotti a 16 bit (abbiamo, infatti, 464 Mp/s e 889 Mt/sec) ma rimangono abbastanza lontani da quelli condotti a 32 bit (con 365 Mp/sec e 718 Mt/sec).

Il notevole distacco esistente tra i risultati a 16 bit e quelli a 32 bit è stato da sempre attribuito alla limitata ampiezza di banda verso la VRAM o, meglio, alla mancanza di algoritmi di risparmio delle banda; più di una persona però ha ipotizzato che in realtà il distacco dipendesse dal fatto che il GF2 fosse incapace di utilizzare parte del suo hardware quando portato a lavorare a 32 bit. In particolare, le ipotesi che sono state avanzate sono 2:
-) che il GF2 utilizzasse solo 2 delle 4 pipeline di cui dispone;
-) che il GF2 utilizzasse tutte le 4 pipeline di cui dispone ma non facesse lavorare la seconda TMU per ogni pipeline.

I test condotti da Max_R ci permettono di scartare, con ragionevole dubbio, queste ipotesi. In altre parole, confermano che il divario esistente tra il rendering a 16 bit e quello a 32 è dovuto solo alla mancanza di banda verso le VRAM.
Perchè questo? Perchè a 32 bit, seppure le prestazioni siano notevolmente più basse di quelli a 16 bit, i risultati rimangono troppo alti per giustificare la perdita di funzionalità da parte del 50% della potenza di rendering.
Infatti, se le ipotesi sopra esposte dovrebbero essere veritiere, avremmo dei valori massimi di p/s e t/s di:
-) 250 mp/s e 500 mt/s in caso il chip spegnesse 2 pipeline;
-) 500 mp/s e 500 mt/s in caso il chip spegnesse la seconda TMU per pipeline.

I valori ottenuti, pari a 365,5 mp/s e 718,5 mt/s, non sono compatibili con nessuna delle due ipotesi. In altre parole, tutto l'hardware del GF2 rimane perfettamente utilizzabile durante il rendering a 32 bit; il collo di bottiglia è dato dalla banda di memoria.

In effetti fa un po' impressione vedere, a 32 bit, che i risultati dei test condotti con chip a 125 Mhz non sono affatto distanti da quelli condotti con chip a 250 Mhz... il GF2 era davvero un "divoratore" di banda verso le VRAM. :)

Spero che questa piccola analisi di un chip tanto vecchio vi sia piaciuta... ;)

Ciao. :)

[Murakami]

In estrema sintesi, Yossarian aveva torto ed io avevo ragione... :O
Bravo Max_R: in un giorno hai fatto ciò che non sono riuscito a fare in 3 anni... accontentare Shodan... :p

[shodan]

In estrema sintesi, Yossarian aveva torto ed io avevo ragione... :O
Bravo Max_R: in un giorno hai fatto ciò che non sono riuscito a fare in 3 anni... accontentare Shodan... :p

Vedi com'è stato performante Max_R! :D
Altro che un certo Murakami... :ciapet:

[Max_R]

Spero che questa piccola analisi di un chip tanto vecchio vi sia piaciuta... ;)Decisamente si :) Ora di che altro si potrebbe discutere? :D

[Saragot]

Beh, io aspetto solo le sdr, che nn so dove trovarle, per il resto sono pronto a fare un pò di test nuovi...
Alla fine sono tutte schede già analizzate, tranne la ati rage fury maxx... Sono molto curioso di vederla in azione!

[shodan]

Decisamente si :) Ora di che altro si potrebbe discutere? :D

Possiamo riprendere il discorso TNT, tanto caro a Murakami...
Chi ha una TNT esegua questo test: http://www.bug.hr/download/dl/files/FillrateTester.zip
e posti i risultati... vediamo cosa esce fuori!

Ciao. :)

[Max_R]

Ho una collezione di TNT :asd:

[shodan]

Ho una collezione di TNT :asd:

Allora vai di test, mio prode! :fagiano:

[Max_R]

Unable to locate 3D Device
Devo cercare dei drivers validi quindi rimando a domani

[Malek86]

Possiamo riprendere il discorso TNT, tanto caro a Murakami...
Chi ha una TNT esegua questo test: http://www.bug.hr/download/dl/files/FillrateTester.zip
e posti i risultati... vediamo cosa esce fuori!

Ciao. :)

Manca il D3D9.dll :fagiano:

Mi sa che mi tocca per forza mettere almeno il Win2000, se voglio fare un qualsiasi controllo delle caratteristiche (schifose) della mia scheda... sul 95 non funziona nulla :fagiano:

[Max_R]

A me continua a non funzionare :asd:
Utilizzo WinXp ed ho tentato due TNT di brand differenti con diverse release dei drivers reference
Domani provo i drv presi dal disco Diamond

[Malek86]

A me continua a non funzionare :asd:
Utilizzo WinXp ed ho tentato due TNT di brand differenti con diverse release dei drivers reference

A me non funziona neanche Rivatuner, GPU-Z... sul 95 non va proprio niente :p

E in qualche modo devo assolutamente controllare le frequenze della mia scheda probabilmente paccosa... :mc:

[Max_R]

Powerstrip, magari un'edizione antica, dovrebbe funzionare :fagiano:

[Malek86]

Powerstrip, magari un'edizione antica, dovrebbe funzionare :fagiano:

Funziona! Grande! :D

Allora, risulta che ho... 80mhz di RAM e 90mhz di Core? Un po' meno dei valori standard, mi pare. Inoltre, l'AGP risulta disattivato :what: vado a dare un'ochhiata al bios.

[Max_R]

Che chipset ha la scheda madre? Hai aggiornato i drivers? E' probabile che quelli forniti con '95 siano un po' vecchiotti
Core 90 MHz e Ram 110 MHz

[Malek86]

Che chipset ha la scheda madre? Hai aggiornato i drivers? E' probabile che quelli forniti con '95 siano un po' vecchiotti
Core 90 MHz e Ram 110 MHz

La scheda madre è una Intel 440BX2. Proverò a aggiornare i drivers... se li trovo.

[Max_R]

Qui (http://downloadcenter.intel.com/filter_results.aspx?strTypes=all&ProductID=816&OSFullName=Windows*+95&lang=ita&strOSs=15&submit=Vai%21)

[Malek86]

Qui (http://downloadcenter.intel.com/filter_results.aspx?strTypes=all&ProductID=816&OSFullName=Windows*+95&lang=ita&strOSs=15&submit=Vai%21)

Ah, sì, grazie. Messo tutto. Sembra funzionare normalmente.

Comunque, non c'è differenza prestazionale... e il Powerstrip segna sempre 80mhz Memory e 90mhz Engine. Sarà una scheda fatta così bassa apposta? Certo che 30fps in Quake2 a 640 è triste :mc:

[Max_R]

Avranno usato memorie dalle caratteristiche economiche e quindi dalle latenze piuttosto alte. Per il resto non posso non dire che, si sa, queste schede non si avantaggiano della banda concessa dallo slot Agp e che quindi utilizzare una versione pci o agp poco cambia. Lo stesso discorso vale per i vari settaggi Agp disponibili da bios.
Il fatto che l'agp fosse disattivato era indice di carenza drivers ;)

[Malek86]

Avranno usato memorie dalle caratteristiche economiche e quindi dalle latenze piuttosto alte.

Non pensavo una cosa del genere - 30mhz di differenza - ti potesse dimezzare totalmente il framerate. Dai test che vedo in rete riguardo a Quake 2, la TNT con un Pentium 2 a 333 (io ho un 350), a 640x480 dovrebbe fare almeno 60fps :what:

[Max_R]

Puoi riportare il codice stampato sulle memorie?

[Malek86]

Puoi riportare il codice stampato sulle memorie?

Intendi le scritte sopra i chippini delle RAM? Ci sono queste:

ASD (credo sia il produttore) AE45C16016T-7 3399320517A

[Max_R]

7 ns contro le mie che montano chip da 8 ns
La tua quindi oltre a reggere bene i 110 ha ancora margine (non so quanto possa essere utile)

[Malek86]

7 ns contro le mie che montano chip da 8 ns
La tua quindi oltre a reggere bene i 110 ha ancora margine (non so quanto possa essere utile)

Ahi. Potrei provare a alzarle manualmente in qualche modo? :O

In ogni caso, posso restare anche così, tanto uso il PC vecchio principalmente per i giochi 2D o DOS. Certo che... mah. Anche il fillrate così basso è strano.

[Max_R]

Sempre Powerstrip ;) Altrimenti dovrebbe esserci il modo di modificare il bios in maniera da forzargli le frequenze corrette
La penso come te: non ne vale la pena (è sicuramente bella di suo :p)

[Malek86]

La penso come te: non ne vale la pena (è sicuramente bella di suo :p)

A pensarci bene, dato che ci vado sempre in 2D, era meglio se tenevo la Matrox Mystique... aveva una qualità d'immagine eccellente :p

[walter sampei]

lo stesso mio amico che mi ha portato la diamond mi ha fatto vedere una matrox, sul chip c'era scritto mga64... era una mystique, giusto?

[shodan]

Grazie mille!

Allora, vediamo di fare un po' di calcoli: a 125 Mhz il GeForce2 dovrebbe sviluppare un massimo di 500 Mp/sec e 1 Gt/sec.
Tali valori sono approcciati dai test condotti a 16 bit (abbiamo, infatti, 464 Mp/s e 889 Mt/sec) ma rimangono abbastanza lontani da quelli condotti a 32 bit (con 365 Mp/sec e 718 Mt/sec).

Il notevole distacco esistente tra i risultati a 16 bit e quelli a 32 bit è stato da sempre attribuito alla limitata ampiezza di banda verso la VRAM o, meglio, alla mancanza di algoritmi di risparmio delle banda; più di una persona però ha ipotizzato che in realtà il distacco dipendesse dal fatto che il GF2 fosse incapace di utilizzare parte del suo hardware quando portato a lavorare a 32 bit. In particolare, le ipotesi che sono state avanzate sono 2:
-) che il GF2 utilizzasse solo 2 delle 4 pipeline di cui dispone;
-) che il GF2 utilizzasse tutte le 4 pipeline di cui dispone ma non facesse lavorare la seconda TMU per ogni pipeline.

I test condotti da Max_R ci permettono di scartare, con ragionevole dubbio, queste ipotesi. In altre parole, confermano che il divario esistente tra il rendering a 16 bit e quello a 32 è dovuto solo alla mancanza di banda verso le VRAM.
Perchè questo? Perchè a 32 bit, seppure le prestazioni siano notevolmente più basse di quelli a 16 bit, i risultati rimangono troppo alti per giustificare la perdita di funzionalità da parte del 50% della potenza di rendering.
Infatti, se le ipotesi sopra esposte dovrebbero essere veritiere, avremmo dei valori massimi di p/s e t/s di:
-) 250 mp/s e 500 mt/s in caso il chip spegnesse 2 pipeline;
-) 500 mp/s e 500 mt/s in caso il chip spegnesse la seconda TMU per pipeline.

I valori ottenuti, pari a 365,5 mp/s e 718,5 mt/s, non sono compatibili con nessuna delle due ipotesi. In altre parole, tutto l'hardware del GF2 rimane perfettamente utilizzabile durante il rendering a 32 bit; il collo di bottiglia è dato dalla banda di memoria.

In effetti fa un po' impressione vedere, a 32 bit, che i risultati dei test condotti con chip a 125 Mhz non sono affatto distanti da quelli condotti con chip a 250 Mhz... il GF2 era davvero un "divoratore" di banda verso le VRAM. :)

Spero che questa piccola analisi di un chip tanto vecchio vi sia piaciuta... ;)

Ciao. :)

Ragazzi, mi quoto perchè stanotte ho avuto una rivelazione: per quanto poco probabile, i risultati sopra lasciano adito a pensare che la GF2 spenga _una_ pipeline (e non 2 come precedentemente ipotizzato). Dobbiamo assolutamente verificare questa cosa... :read:
Max_R, ti stresso se ti chiedo di rifare un fill-rate test con il core a frequenza ancora minore? Oppure, se non ti è possibile abbassare ancora il core, alzando la frequenza della VRAM (che so, portandola intorno ai 500-520 Mhz) ?

Ciao,
grazie.

[shodan]

Ah, sì, grazie. Messo tutto. Sembra funzionare normalmente.

Comunque, non c'è differenza prestazionale... e il Powerstrip segna sempre 80mhz Memory e 90mhz Engine. Sarà una scheda fatta così bassa apposta? Certo che 30fps in Quake2 a 640 è triste :mc:

In effetti la tua scheda ha valori di fill-rate davvero bassi, che non mi paiono giustificabili semplicemente tirando in causa le RAM a 80 Mhz... non è che ha bus a 64 bit?
Puoi postare una foto?

Ciao. :)

[Murakami]

Malek86, fossi in te passerei a Win98SE: tenersi Win95 è davvero anacronistico e potrebbe, dico potrebbe, spiegare qualche anomalia.

[Malek86]

In effetti la tua scheda ha valori di fill-rate davvero bassi, che non mi paiono giustificabili semplicemente tirando in causa le RAM a 80 Mhz... non è che ha bus a 64 bit?
Puoi postare una foto?

Ciao. :)

Uhm, se ti accontenti di una foto fatta col telefonino...

Malek86, fossi in te passerei a Win98SE: tenersi Win95 è davvero anacronistico e potrebbe, dico potrebbe, spiegare qualche anomalia.

Win98SE ha qualche incompatibilità in più coi giochi DOS, che io sappia. Dato che il mio obiettivo principale è quello, preferisco tenermi la scheda così piuttosto.

Oppure, dato che ricordo che la Voodoo2 andava benissimo quando ce l'avevo, magari mi prendo un'altra di quelle e la riaffianco alla Mystique. Anche il Glide è un vantaggio in più :O

[Murakami]

Win98SE ha qualche incompatibilità in più coi giochi DOS, che io sappia.

Questa mi è nuova, dato che anche Win98SE dispone di una modalità DOS nativa... :mbe:

[Malek86]

Questa mi è nuova, dato che anche Win98SE dispone di una modalità DOS nativa... :mbe:

Non ne sono sicuro ovviamente, ma è quello che ho sempre letto in giro. Riguardo alla gestione dell'EMS. Considera che non vado in DOS nativo, rimango su Win per giocare.

Comunque, uhm, ecco una fotina intanto. Fa un po' schifo, ma per ora purtroppo non posso fare di meglio.

http://www.gogettonia.net/malek/rivatnt.jpg

[Murakami]

Considera che non vado in DOS nativo, rimango su Win per giocare.
Male, malissimo: che purista sei! :mad: :O

[Malek86]

Male, malissimo: che purista sei! :mad: :O

Ehi, chi ha mai detto che sono un purista? :asd: :p sicuramente è meglio di XP, e finora non ho avuto problemi, quindi mi sta bene :D

Inoltre, il config.sys e l'autoexec.bat mi stanno sulle balle :O :D

[Crisp]

Non pensavo una cosa del genere - 30mhz di differenza - ti potesse dimezzare totalmente il framerate. Dai test che vedo in rete riguardo a Quake 2, la TNT con un Pentium 2 a 333 (io ho un 350), a 640x480 dovrebbe fare almeno 60fps :what:

be io con un p166mmx e una voodoo2 a quake2 facevo sui 25/26 fps..:D

[blindwrite]

Non ne sono sicuro ovviamente, ma è quello che ho sempre letto in giro. Riguardo alla gestione dell'EMS. Considera che non vado in DOS nativo, rimango su Win per giocare.

Comunque, uhm, ecco una fotina intanto. Fa un po' schifo, ma per ora purtroppo non posso fare di meglio.

http://www.gogettonia.net/malek/rivatnt.jpg

suppongo sia 64bit data la mancanza dei 4 chip di memoria in alto;)

[Malek86]

suppongo sia 64bit data la mancanza dei 4 chip di memoria in alto;)

Ma allora è come una specie di Vanta? :O

[blindwrite]

Ma allora è come una specie di Vanta? :O

dipende dalla frequenze, assomiglia molto ad una Vanta LT
esisteva anche una TNT2 M64 con bus a 64bit, ma mi sembra di ricordare avesse frequenze più alte.

Io avevo una vanta da 8mb non era il max ma ci si giochicchiava;)

[shodan]

Ma allora è come una specie di Vanta? :O

In effetti è l'ipotesi più probabile... :(

[Murakami]

In effetti è l'ipotesi più probabile... :(
Si, lo è, anche perchè il TNT2 M64 ha frequenza core 125 mhz ed è leggermente più veloce di un TNT1.

[Malek86]

dipende dalla frequenze, assomiglia molto ad una Vanta LT

Io avevo una vanta da 8mb non era il max ma ci si giochicchiava

Le frequenze sono 80mhz la memoria e 90mhz l'engine (secondo Powerstrip).

Anch'io ci giochicchio abbastanza, in effetti. In D3D è buona. E poi, per quello che ci devo fare... :O

In effetti è l'ipotesi più probabile... :(

Eh, certo che se fosse una Vanta vera e propria, il bios lo direbbe. Sarà una Vanta mascherata da TNT :O

[Max_R]

Ragazzi, mi quoto perchè stanotte ho avuto una rivelazione: per quanto poco probabile, i risultati sopra lasciano adito a pensare che la GF2 spenga _una_ pipeline (e non 2 come precedentemente ipotizzato). Dobbiamo assolutamente verificare questa cosa... :read:
Max_R, ti stresso se ti chiedo di rifare un fill-rate test con il core a frequenza ancora minore? Oppure, se non ti è possibile abbassare ancora il core, alzando la frequenza della VRAM (che so, portandola intorno ai 500-520 Mhz) ?

Ciao,
grazie.Sotto a 125 MHz per il core non mi è possibile con
rivatuner. Provo con Powerstrip altrimenti alzo la frequenza delle memorie.
Questa mi è nuova, dato che anche Win98SE dispone di una modalità DOS nativa... :mbe:E' da settare però, altrimenti sono cavoli amari.Non ne sono sicuro ovviamente, ma è quello che ho sempre letto in giro. Riguardo alla gestione dell'EMS. Considera che non vado in DOS nativo, rimango su Win per giocare.

Comunque, uhm, ecco una fotina intanto. Fa un po' schifo, ma per ora purtroppo non posso fare di meglio.

http://www.gogettonia.net/malek/rivatnt.jpgSecondo me è una TNT però non capisco gli spazi vuoti per i chip di memoria. Le TNT hanno sempre avuto 16 mb che io sappia. La tua ne ha 8 (8M sull'etichetta)? Perchè altrimenti aggiungere ram la farebbe arrivare a 32 mb :mbe: 8 mb invece di 16 su Q3A può influire molto.
In definitiva io penso che sia una scheda destinata all'OEM

[lele.miky]

Ragazzi, mi quoto perchè stanotte ho avuto una rivelazione: per quanto poco probabile, i risultati sopra lasciano adito a pensare che la GF2 spenga _una_ pipeline (e non 2 come precedentemente ipotizzato). Dobbiamo assolutamente verificare questa cosa... :read:
Max_R, ti stresso se ti chiedo di rifare un fill-rate test con il core a frequenza ancora minore? Oppure, se non ti è possibile abbassare ancora il core, alzando la frequenza della VRAM (che so, portandola intorno ai 500-520 Mhz) ?

Ciao,
grazie.

se riesco stasera lo faccio anche io il test col gf2GTS
ripetimi che test vuoi e a che frequenze,su winXP va bene lo stesso?

ciao

[walter sampei]

Questa mi è nuova, dato che anche Win98SE dispone di una modalità DOS nativa... :mbe:

Non ne sono sicuro ovviamente, ma è quello che ho sempre letto in giro. Riguardo alla gestione dell'EMS. Considera che non vado in DOS nativo, rimango su Win per giocare.

cut

l'ems di default su win98se e' disattivato, ma lo puoi attivare in modo semplicissimo con 2 linee nel config.sys. tra l'altro in alcuni casi sembrava aumentare di un po' le prestazioni del pc anche sotto windows. l'avevo scritto tempo fa in questo stesso thread ;)

[Malek86]

l'ems di default su win98se e' disattivato, ma lo puoi attivare in modo semplicissimo con 2 linee nel config.sys. tra l'altro in alcuni casi sembrava aumentare di un po' le prestazioni del pc anche sotto windows. l'avevo scritto tempo fa in questo stesso thread ;)

Non sono mai stato un granchè nella gestione del config.sys :stordita:

Ci ho provato per un po', ma poi ho visto che tanto i titoli non partivano lo stesso. A quel punto sono rimasto sul 95. Comunque, non penso che mettendo Win98 cambierei nulla, probabilmente è una scheda per l'OEM come ha detto Max...

[walter sampei]

Non sono mai stato un granchè nella gestione del config.sys :stordita:

Ci ho provato per un po', ma poi ho visto che tanto i titoli non partivano lo stesso. A quel punto sono rimasto sul 95. Comunque, non penso che mettendo Win98 cambierei nulla, probabilmente è una scheda per l'OEM come ha detto Max...

mi autolinko ;)

http://www.hwupgrade.it/forum/showpost.php?p=13023934&postcount=1946

se cerchi "ems" nella discussione, trovi parecchia roba

[shodan]

se riesco stasera lo faccio anche io il test col gf2GTS
ripetimi che test vuoi e a che frequenze,su winXP va bene lo stesso?

ciao

Ciao,
quello che ci interesserebbe è vedere i risultati del fill rate test del 3D Mark 2000 sia a frequenze di default (200/333) che con il chip grafico al minimo possibile (es: 50/333).

WinXP va benissimo. :)

Ciao,
grazie.

[shodan]

Sotto a 125 MHz per il core non mi è possibile con
rivatuner. Provo con Powerstrip altrimenti alzo la frequenza delle memorie.
E' da settare però, altrimenti sono cavoli amari.Secondo me è una TNT però non capisco gli spazi vuoti per i chip di memoria. Le TNT hanno sempre avuto 16 mb che io sappia. La tua ne ha 8 (8M sull'etichetta)? Perchè altrimenti aggiungere ram la farebbe arrivare a 32 mb :mbe: 8 mb invece di 16 su Q3A può influire molto.
In definitiva io penso che sia una scheda destinata all'OEM

Con rivatuner (così come con powerstrip) è possibile specificare il range min-max dello slider che ti permette di settare la frequenza. Se non riesci fammelo sapere che vedo come fare... ;)

Ciao. :)

[Malek86]

Uhm... intanto sono il nuovo possessore di una G200 da 16Mb, appena mi arriva, s'intende. Addio, signora ventolina.

Già che ci sono. I problemi di OpenGL della G200 vennero risolti in qualche driver, oppure mi tocca tenermi il wrapper schifoso? :O

[Murakami]

Uhm... intanto sono il nuovo possessore di una G200 da 16Mb, appena mi arriva, s'intende. Addio, signora ventolina.

Già che ci sono. I problemi di OpenGL della G200 vennero risolti in qualche driver, oppure mi tocca tenermi il wrapper schifoso? :O
Ampiamente risolti da un driver ICD... ;)

[walter sampei]

popolo, una domanda: secondo voi, se piazzo la voodoo sul mio pc a dare una mano alla radeon 3450 :asd: , rischio di fare danni? perdo tanto in qualita' video? (sono su un lcd 1024*768 con ingresso vga)? e soprattutto, qualcuno sa quando consumavano le voodoo in idle?

[Max_R]

Potrebbe disturbarti (molto) il segnale, si. Non danneggi alcunchè comunque quindi prova e valuta da te. IMHO è abbastanza inutile come soluzione e quel "dare una mano" non ha a che fare con le Voodoo :asd:
Il consumo è irrilevante.

[walter sampei]

Potrebbe disturbarti (molto) il segnale, si. Non danneggi alcunchè comunque quindi prova e valuta da te. IMHO è abbastanza inutile come soluzione e quel "dare una mano" non ha a che fare con le Voodoo :asd:
Il consumo è irrilevante.

se non altro la voodoo alla 3450 fa compagnia :asd:

battute a parte, TUTTO sospeso. non mi vanno piu' le porte usb del pc!!! :help:

adesso vado a vedere se c'e' qualche thread che mi sia utile in "schede madri", se no mi tocca aprirne uno... :cry:

[blindwrite]

ragazzi mi consigliate qualche gioco da provare su una SIS M650, OS xp p4 2600Mhz 480mb di ram??
qualcosa tipo diablo 2 che girava molto bene!!

[Max_R]

Che genere preferisci?

[Murakami]

Ragazzi, mi è arrivato Serious Sam: SE... sapete mica come si bencha? :stordita:

[blindwrite]

Che genere preferisci?

qualunque cosa che può girare degnamente con quella scheda...
qualcosa tipo diablo non mi dispiacerebbe...
anche qualcosa di guida, o uno sportivo, comunque nulla di impegnativo, solo per passare un po' di tempo e divertirmi

[Max_R]

Ragazzi, mi è arrivato Serious Sam: SE... sapete mica come si bencha? :stordita:Puoi usare Bench'emAll! o Fraps.
L'alternativa è usare il comando /dem_bProfile=1 dalla console.

qualunque cosa che può girare degnamente con quella scheda...
qualcosa tipo diablo non mi dispiacerebbe...
anche qualcosa di guida, o uno sportivo, comunque nulla di impegnativo, solo per passare un po' di tempo e divertirmiCi penso su un po' perchè non è una domanda facile: di titoli ce ne sono a migliaia e non conosco bene il tuo controller video ;)

Edit: aggiorno qui sotto appena mi viene in mente un titolo
Nox
Sacred

[Max_R]

Manca il D3D9.dll :fagiano:

Mi sa che mi tocca per forza mettere almeno il Win2000, se voglio fare un qualsiasi controllo delle caratteristiche (schifose) della mia scheda... sul 95 non funziona nulla :fagiano:Provando con '98 mi ha dato lo stesso problema. Siamo sicuri che il software funzioni?

[Murakami]

Ho provato Serious Sam SE e devo dire che è ancora molto bello! :eek:
Ho usato una 9600 liscia, che è anche troppo per questo gioco: peccato, però, che se attivo il Truform (ancora supportato dai driver per Win98, per quanto nel 9600 sia soltanto un'emulazione software), il frame rate letteralmente crolla, rendendo il titolo ingiocabile... :fagiano: ... però nella stanza degli effetti se ne può apprezzare il pregevole risultato... :O
Carente la gestione dell'antialiasing dei driver per Win98 del 9600 (almeno in OpenGL): attivando l'AA, Serious Sam esibisce difetti di corruzione grafica nei menù, mentre Star Trek: Elite Force II si impalla completamente, restituendo schermo nero. Tutto a posto con l'algoritmo multisampling del GeForce 5600, così come con il supersampling di Radeon 7500 e 9250 (stessi driver del 9600).

[Murakami]

Ragazzi, vorrei sapere se qualcuno di voi conosce la differenza, nello specifico tecnico, tra le modalità prestazioni e qualità dell'antialiasing di Radeon 7500 e 8500 (e derivati, tra i quali il mio 9250). Nel techbrief di ATI sullo Smoothvision di prima generazione (8500) la cosa è spiegata abbastanza bene ( :mbe: ), ma riguardo il 7500 ho solo un'idea, quella presa cioè da questo articolo (http://www.sharkyextreme.com/hardware/articles/ati_radeon_in-depth/9.shtml), dal quale si potrebbe evincere che l'unità di blending non venga utilizzata nella modalità qualità (implementata solo in seguito) e che, quindi, un "vero" AA venga eseguito in multipass. Questo, però, dovrebbe valere per l'AA 4X: ma per il 2X? Voi che dite?
Per quanto riguarda, invece, le modalità prestazioni e qualità del filtro anisotropico di R300 e derivati, qualcuno ne sa qualcosa? Grazie.

[Murakami]

Incredibilmente, il problema che avevo a suo tempo con il GeForce2 su WinXP si ripropone anche con il GeForce4 TI: il rendering (non lo scrolling) della pagine web è molto lento, non importa quali driver uso. Ma è mai possibile? L'anomalia si presenta in misura minore anche con il GeForceFX 5600.
Tutto a posto, invece, con le Radeon, che, tra l'altro, su questo monitor (Acer AL1916W), restituiscono un'immagine di qualità nettamente superiore (tranne il 7500, penosamente sfuocato), specie da angolazioni orizzontali e verticali accentuate: non si nota differenza alcuna, invece, su CRT (anche il 7500 si comporta molto bene).
Che il mio LCD sia un pò schizzinoso? Che le risoluzioni wide mettano in crisi le schede più vecchie? Ma soprattutto, come giustificare la lentezza delle GeForce in un particolare tipo di operazione 2D?
Sotto con le idee... :O

[Max_R]

Settato alla risoluzione nativa? Un minimo di perdita con l'attacco vga rispetto al dvi è motivato e la migliore qualità nel 2D la vantava Ati al periodo.
Riguardo alla lentezza: boh!

[Murakami]

Settato alla risoluzione nativa? Un minimo di perdita con l'attacco vga rispetto al dvi è motivato e la migliore qualità nel 2D la vantava Ati al periodo.

Si, res nativa (il mio monitor non ha ingresso DVI): ma la differenza di qualità è vistosa, anche (tanto per dirti) rispetto ad un GeForce6 6600.
E' un pò assurdo; sembra che il monitor prediliga le ATI... :p
Precisazione: la qualità del GeForce 5600 è circa pari ad ATI; pessimo il GeForce4 MX (il testo si impasta), mediocri GeForce4 TI e GeForce6 6600 (cambiando un pò angolazione il testo diventa meno leggibile, i contorni si sfuocano).

[Murakami]

Incredibilmente, il problema che avevo a suo tempo con il GeForce2 su WinXP si ripropone anche con il GeForce4 TI: il rendering (non lo scrolling) della pagine web è molto lento, non importa quali driver uso. Ma è mai possibile? L'anomalia si presenta in misura minore anche con il GeForceFX 5600.
Ho individuato l'origine del problema: ora sto scrivendo con il browser Opera ed il rendering è immediato. C'è qualcosa nella combinazione driver nVidia, schede vecchie e IE (sia 6 che 7) che funziona male.
EDIT: anche con Firefox tutto perfetto.

[walter sampei]

Ho individuato l'origine del problema: ora sto scrivendo con il browser Opera ed il rendering è immediato. C'è qualcosa nella combinazione driver nVidia, schede vecchie e IE (sia 6 che 7) che funziona male.
EDIT: anche con Firefox tutto perfetto.

la mia ti, con gli omega, dava problemi di lentezza anche con firefox. forse i driver...

[Murakami]

Non so nemmeno io per quale motivo, ma ho comprato (usata, forse mi attirava il prezzo: 80 €) una ATI X1950 PRO 512 mb AGP: a che test potrei sottoporla... :wtf:

[Saragot]

Ragazzi, sabato è successa una cosa allucinante....
Ho fuso la 7600gt nel tentativo di fare un wr....
Era una scheda fortunatissima, 870 Mhz di core nn è da tutte.....

[Max_R]

Non so nemmeno io per quale motivo, ma ho comprato (usata, forse mi attirava il prezzo: 80 €) una ATI X1950 PRO 512 mb AGP: a che test potrei sottoporla... :wtf:Serious Sam 2 SM3 ovviamente

Ragazzi, sabato è successa una cosa allucinante....
Ho fuso la 7600gt nel tentativo di fare un wr....
Era una scheda fortunatissima, 870 Mhz di core nn è da tutte.....Che è successo?

[Murakami]

Che è successo?
Eh beh, suppongo overclock troppo spinto (870 mhz di core)... :p

[Max_R]

Si ma ha fatto fumo, è schioppata ed ha fatto fischiare le orecchie a tutto il vicinato (senza parlare della puzza di petardo) oppure ha cominciato a dare artefatti oppure ancora a non dare più il segnale video ma senza effetti speciali? :asd:

[Saragot]

Il core funziona ancora benissimo, e sicuramente mi sarei avvicinato ai 900Mhz, salendo a 1,8V (a liquido ovviamente, ad aria arrivavo a 850 Mhz a 1,55V). Il problema erano le memorie che a 930 hanno iniziato a sfocare l'immagina. Al riavvio era un tripudio di artefatti...
Stranissimo, prima ad aria ci stavano benino a 930 Mhz.
Cmq, la schda a 850/920 andava più di una 7800gtx... nel 3dmark 2005 facevo 8100 punti con un processore scarsino....
Addio bella scheda.
Cmq, ho il p3 800 per le prove e le schede, mi mancano solo le ram....

[Max_R]

In questi casi tentare un reflash del bios può dare ottimi risultati: su cinque volte che ho fatto un lavoro simile, ben tre volte mi è andata bene.
Siccome non hai nulla da perdere, non mi sembra una cattiva idea ;)

[Murakami]

Piccolo OT: miseria che missile questa X1950... mai avuto io una scheda così... :mbe:
Tornando in topic, a giorni dovrebbe arrivarmi la CPU a 133 mhz per il confronto sul muletto: poi, ho in programma uno scontro tra Riva128 e Riva128ZX... :Perfido:

[Max_R]

E' la scheda che monto al momento nel sistema principale ;)

[Murakami]

Ho scoperto anche cosa rendeva così diversa la qualità d'immagine tra le varie schede: il parametro nitidezza del monitor. Bisogna regolarlo manualmente per ogni VGA, pena vistoso scadimento della qualità del testo: per qualche motivo, l'impostazione automatica andava bene solo sulle ATI, ma non su questa X1950... al che mi sono deciso a smanettare, trovando l'inghippo.

[Murakami]

E' la scheda che monto al momento nel sistema principale ;)
Che tu sappia, gli ultimo tool Avivo -converter- usano la GPU o no?

[Max_R]

Buh... :asd:

[Murakami]

Ragazzi, vorrei sapere se qualcuno di voi conosce la differenza, nello specifico tecnico, tra le modalità prestazioni e qualità dell'antialiasing di Radeon 7500 e 8500 (e derivati, tra i quali il mio 9250). Nel techbrief di ATI sullo Smoothvision di prima generazione (8500) la cosa è spiegata abbastanza bene ( :mbe: ), ma riguardo il 7500 ho solo un'idea, quella presa cioè da questo articolo (http://www.sharkyextreme.com/hardware/articles/ati_radeon_in-depth/9.shtml), dal quale si potrebbe evincere che l'unità di blending non venga utilizzata nella modalità qualità (implementata solo in seguito) e che, quindi, un "vero" AA venga eseguito in multipass. Questo, però, dovrebbe valere per l'AA 4X: ma per il 2X? Voi che dite?
Per quanto riguarda, invece, le modalità prestazioni e qualità del filtro anisotropico di R300 e derivati, qualcuno ne sa qualcosa? Grazie.
Shodan, perchè quando mi serve la tua pseudo-competenza ti eclissi... :mad:
Ti senti forse sconfitto ed umiliato dalla mia rinnovata e straripante potenza (X1950)? :wtf:

[shodan]

Shodan, perchè quando mi serve la tua pseudo-competenza ti eclissi... :mad:
Ti senti forse sconfitto ed umiliato dalla mia rinnovata e straripante potenza (X1950)? :wtf:

Eila capo, non ti preoccupare, ho letto tutto... ;)
Sto un po' incasinato col lavoro... quanto prima faccio un post riassuntivo... :D

Ciao.

[Crisp]

Che tu sappia, gli ultimo tool Avivo -converter- usano la GPU o no?

certo che usano la gpu, è fatto apposta :)
diciamo che la gpu aiuta la cpu nelle operazioni.
non l'ho mai usato quando avevo la x1900GT, ma usavo xp x64 che non supporta avivo converter, ma è un ottimo tool per chi ha queste vga.

[Murakami]

certo che usano la gpu, è fatto apposta :)
diciamo che la gpu aiuta la cpu nelle operazioni.
non l'ho mai usato quando avevo la x1900GT, ma usavo xp x64 che non supporta avivo converter, ma è un ottimo tool per chi ha queste vga.
Le informazioni che ho trovato girovagando per la Rete dicono l'esatto contrario, tanto è vero che taluni furbetti hanno sbloccato una versione per farla funzionare su qualsiasi sistema. Pare che il tool faccia un semplice check della GPU, ma poi usi solo la CPU. Potrei portarti decine di link a riguardo: tu riesci a portarmene uno solo che avvalori la tua tesi (che sarei ben felice di sposare)? :fagiano:

[Crisp]

http://www.news3d.eu/index.php?PHPSESSID=r4m1g5au5ufuqvh5abkvkq52m2&action=3dnews;art=990;pg=6

http://babgvant.com/blogs/andyvt/archive/2007/09/25/Converting-DVR_2D00_MS-to-WMVHD.aspx

[Murakami]

http://www.news3d.eu/index.php?PHPSESSID=r4m1g5au5ufuqvh5abkvkq52m2&action=3dnews;art=990;pg=6

http://babgvant.com/blogs/andyvt/archive/2007/09/25/Converting-DVR_2D00_MS-to-WMVHD.aspx

"I checked my GPU temp while running an AVIVO conversion of a wmv file to mpeg 4, it doesn't budge, stays at my standard idle temp of 65degs C so I am pretty certain this is NOT using the GPU, also my CPU was 100% use by CLI.exe during the conversion. All in all I am highly dissappointed by this misleading convertor."
"ATI has stated in interviews that the Avivo transcoder utility currently does NOT use the GPU and that future version will use the GPU for hardware assist.
In other words, its 100% software and CPU (plus X1000 series GPU even though it is not used and stands as an artificial limitation) for now and X1000 assisted later.
This point was illustrated clearly by a hacked and leaked version of the ATI AvivoXCode utility that would work on any system regardless of GPU,…. nVidia or ATI (X1000 series not needed)."

Da http://www.rage3d.com/board/archive/index.php?t-33848376.html

Potrei continuare all'infinito... :fagiano:

[ReDeX]

"I checked my GPU temp while running an AVIVO conversion of a wmv file to mpeg 4, it doesn't budge, stays at my standard idle temp of 65degs C so I am pretty certain this is NOT using the GPU, also my CPU was 100% use by CLI.exe during the conversion. All in all I am highly dissappointed by this misleading convertor."
"ATI has stated in interviews that the Avivo transcoder utility currently does NOT use the GPU and that future version will use the GPU for hardware assist.
In other words, its 100% software and CPU (plus X1000 series GPU even though it is not used and stands as an artificial limitation) for now and X1000 assisted later.
This point was illustrated clearly by a hacked and leaked version of the ATI AvivoXCode utility that would work on any system regardless of GPU,…. nVidia or ATI (X1000 series not needed)."

Da http://www.rage3d.com/board/archive/index.php?t-33848376.html

Potrei continuare all'infinito... :fagiano:

Infatti so anch'io che questo avivo video converter era una bufala, la gpu in realtà non veniva toccata.

[Murakami]

Infatti so anch'io che questo avivo video converter era una bufala, la gpu in realtà non veniva toccata.

http://www.tomshw.it/graphic.php?guide=20070109&page=avivo_purevideo-12
Ce n'è per tutti i gusti... :muro:

[walter sampei]

http://www.tomshw.it/graphic.php?guide=20070109&page=avivo_purevideo-12
Ce n'è per tutti i gusti... :muro:

beh, tom's e' parecchio di parte... :rolleyes:

[shodan]

Ragazzi, vorrei sapere se qualcuno di voi conosce la differenza, nello specifico tecnico, tra le modalità prestazioni e qualità dell'antialiasing di Radeon 7500 e 8500 (e derivati, tra i quali il mio 9250). Nel techbrief di ATI sullo Smoothvision di prima generazione (8500) la cosa è spiegata abbastanza bene ( :mbe: ), ma riguardo il 7500 ho solo un'idea, quella presa cioè da questo articolo (http://www.sharkyextreme.com/hardware/articles/ati_radeon_in-depth/9.shtml), dal quale si potrebbe evincere che l'unità di blending non venga utilizzata nella modalità qualità (implementata solo in seguito) e che, quindi, un "vero" AA venga eseguito in multipass. Questo, però, dovrebbe valere per l'AA 4X: ma per il 2X? Voi che dite?

Ciao, da quanto ne so io l'AA di R100 e R200 è sostanzialmente lo stesso, e questo quindi implica che:
-) sono entrambi realizzati tramite super-sampling (e questo lo si sa :D)
-) la modalità qualità di entrambi filtra maggiormente le texture (tramite filtro anisotropico).
Una differenza sostanziale, però, è data da come i due chip scelgono il livello di dettaglio (mipmap) da applicare agli oggetti: date un'occhiata al link http://www.techreport.com/articles.x/3266/7

A proposito delle speculazioni circa l'utilizzo (o meno) dell'unità di blending, ricordo anch'io di aver letto quell'articolo di sharky extreme ma penso che il redattore abbia preso un abbaglio: in modalità supersampling, i 4 subpixel che vengono generati sono in realtà pixel veri e propri che solo in un secondo tempo saranno mescolati in un solo pixel; quindi, se quello che dice il redattore è vero, le TMU e l'unita di AB di una singola pipeline di R100 dovrebbero essere in grado di lavorare su 4 pixel diversi contemporaneamente. Mi pare difficile...

Per quanto riguarda, invece, le modalità prestazioni e qualità del filtro anisotropico di R300 e derivati, qualcuno ne sa qualcosa? Grazie.
Allora, qui possiamo avere le seguenti modalità:
-) disabilitato (o application select): le texture vengono filtrate con filtro bilineare e, se richiesto dall'applicativo, con quello trilineare e/o anisotropico;
-) modalità performance: l'anisotropico viene applicato ignorando le eventuali richieste di filtraggio trilineari da parte dell'applicazione (in pratica, il chip calcola aniso+bilinear forzandolo su tutti i layer di texture);
-) modalità quality: l'anisotropico viene applicato ignorando le eventuali richiesta di filtraggio trilineari da parte dell'applicazione tranne che per il primo layer, dove viene usato il filtro trilineare (in pratica, il chip calcola aniso+trilinear sul primo layer e aniso+bilinear forzandolo su tutti i rimanenti layer di texture);

Da questo si evince che la migliore qualità possibile la si raggiunge lasciando impostare il filtro anisotropico all'applicazione. ;)

[shodan]

Con rivatuner (così come con powerstrip) è possibile specificare il range min-max dello slider che ti permette di settare la frequenza. Se non riesci fammelo sapere che vedo come fare... ;)

Ciao. :)

Novità? :fagiano:

[Max_R]

Novità? :fagiano:Domani ho l'intera giornata libera :D Piuttosto con il discorso TNT, al quale invece mi sono dedicato, non c'è stato verso.

[shodan]

Domani ho l'intera giornata libera :D Piuttosto con il discorso TNT, al quale invece mi sono dedicato, non c'è stato verso.

Cioè? Non parte il fill-rate tester? Se è per l'errore relativo alle DX9, è probabile che il bench funzioni solo sotto win2000/XP (con le DX9 installate).
Tu l'hai provato sotto Win98, vero?

Ciao.

[Max_R]

Inizialmente no, sotto a Xp.

[Murakami]

Ciao, da quanto ne so io l'AA di R100 e R200 è sostanzialmente lo stesso, e questo quindi implica che:
-) sono entrambi realizzati tramite super-sampling (e questo lo si sa :D)
-) la modalità qualità di entrambi filtra maggiormente le texture (tramite filtro anisotropico).
Beh, dimentichi lo sparse grid sampling programmabile di R200 e derivati, che consente una qualità superiore rispetto all'ordered grid fisso di R100. Tra l'altro, per R100 sono disponibili solo le modalità 2X e 4X, mentre per R200 sono selezionabili 2X, 3X, 4X, 5X e 6X.

[Murakami]

Allora, qui possiamo avere le seguenti modalità:
-) disabilitato (o application select): le texture vengono filtrate con filtro bilineare e, se richiesto dall'applicativo, con quello trilineare e/o anisotropico;
-) modalità performance: l'anisotropico viene applicato ignorando le eventuali richieste di filtraggio trilineari da parte dell'applicazione (in pratica, il chip calcola aniso+bilinear forzandolo su tutti i layer di texture);
-) modalità quality: l'anisotropico viene applicato ignorando le eventuali richiesta di filtraggio trilineari da parte dell'applicazione tranne che per il primo layer, dove viene usato il filtro trilineare (in pratica, il chip calcola aniso+trilinear sul primo layer e aniso+bilinear forzandolo su tutti i rimanenti layer di texture);

Da questo si evince che la migliore qualità possibile la si raggiunge lasciando impostare il filtro anisotropico all'applicazione. ;)
Se è come dici, il tutto non tocca l'ottimizzazione dipendente dall'angolo della superficie interessata, che probabilmente è hardwired: mi sa che gli ingegneri ATI hanno introdotto una modalità angle independent solo in R520 e derivati.

[Murakami]

beh, tom's e' parecchio di parte... :rolleyes:

Può essere, ma la CPU al 100% e la GPU "fredda" sono dati oggettivi, riscontrati da più parti.

[walter sampei]

Può essere, ma la CPU al 100% e la GPU "fredda" sono dati oggettivi, riscontrati da più parti.

senza dubbio, sul fatto che il converter NON usi la gpu siamo tutti d'accordo. su quel sito pero' c'e' comunque parecchia roba che non mi torna.

[shodan]

Beh, dimentichi lo sparse grid sampling programmabile di R200 e derivati, che consente una qualità superiore rispetto all'ordered grid fisso di R100. Tra l'altro, per R100 sono disponibili solo le modalità 2X e 4X, mentre per R200 sono selezionabili 2X, 3X, 4X, 5X e 6X.

No, non lo dimentico: il fatto è che la millantata programmabilità dell'AA di R200 non si è mai contretizzata e non è mai stata esposta via driver.
As esempio, il TemporaryAA (che usa proprio la programmabilità del motore AA) non è mai stata attivato su R200 ma solo su R300 e derivati.

Riguardo alle modalità intermedie (3X, 5X e 6X), il punto è che cambiava solo la risoluzione a cui l'immagine veniva inizialmente renderizzata, nulla di più... per esempio, ricordo che in origine anche il GF256 DDR con driver detonator 5.22 permetteva di scegliere queste modalità intermedie, che poi sono scomparse con altre versioni di driver.

Ciao. :)

[shodan]

Se è come dici, il tutto non tocca l'ottimizzazione dipendente dall'angolo della superficie interessata, che probabilmente è hardwired: mi sa che gli ingegneri ATI hanno introdotto una modalità angle independent solo in R520 e derivati.

Infatti è proprio così: la dipendeza dall'angolazione rimaneva costante con tutte le modalità di AF (anche con quella "super" attivabile via tweaker e che forzava il driver a usare sempre il aniso+trilinear). Tempo fa su Beyond3D si ipotizzava che tale scelta potesse essere stata fatta per risparmare transistor sul chip e non tanto per migliorare le prestazioni (e infatti R520 non perde poi molto con l'AF HighQuality).

Ciao. :)

[Murakami]

No, non lo dimentico: il fatto è che la millantata programmabilità dell'AA di R200 non si è mai contretizzata e non è mai stata esposta via driver.
As esempio, il TemporaryAA (che usa proprio la programmabilità del motore AA) non è mai stata attivato su R200 ma solo su R300 e derivati.

Riguardo alle modalità intermedie (3X, 5X e 6X), il punto è che cambiava solo la risoluzione a cui l'immagine veniva inizialmente renderizzata, nulla di più... per esempio, ricordo che in origine anche il GF256 DDR con driver detonator 5.22 permetteva di scegliere queste modalità intermedie, che poi sono scomparse con altre versioni di driver.

Ciao. :)
Ma sei sicuro? Questo è quanto dichiara ATI nel suo documento ufficiale circa la prima implementazione di Smoothvision (R200):

"ATI’s implementation of anti-aliasing provides a substantial improvement over other forms of anti-aliasing found in other GPUs. Instead of shifting every pixel in the same direction, groups of pixels can be individually shifted in different directions. This technique can be used to generate a more random distribution of pixel samples, leading to higher quality anti-aliased images.
SMOOTHVISION™ uses a large group of 16-sample blocks that cover a variable number of pixels, which is determined by the level of anti-aliasing being implemented. Each pixel within every group of 16 samples has their actual sample positions selected from a pre-programmed 8-sample jitter table.
As the level of anti-aliasing is increased, each 16-sample block will cover a smaller number of pixels. For example in the 2x anti-aliasing case, a total of 8 pixels are covered by the 16 sample group, and in the 4x case, a total of 4 pixels are sampled 4 times each.
A non-ordered pixel sampling approach provides the optimal solution, since the eye has a much harder time seeing artifacts in the resulting anti-aliased image, being less sensitive to non-ordered sampling patterns.
High-Quality SMOOTHVISION™ anti-aliasing uses a different texture color per sample, providing superior image quality compared to other competing anti-aliasing techniques, as a greater amount of color data is used to create the final anti-aliased image. Combined with superior sampling pattern of SMOOTHVISION™, the High-Quality SMOOTHVISION™ provides users with an unparalleled anti-aliasing solution.
High-Performance SMOOTHVISION™ anti-aliasing uses a jittered sample pattern for high-quality jagged edge removal, combined with an advanced sample blending and filtering algorithm. This advanced algorithm allows SMOOTHVISION™ to take fewer samples per pixel by blending in samples from other outside pixels. This results in a High-Performance anti-aliasing setting, while maintaining a level of image quality very similar to competing anti-aliasing solutions."

Ricordo anch'io che tale processo non era impiegato nelle prime versioni di driver, ma poi mi sembrava che la cosa fosse stata corretta. Magari non avranno sfruttato tale "jittered sampling pattern" per implementare anche il temporal AA (comunque inutile su tale fascia di prodotto, troppo lento oltre che superato), però la differenza rispetto a R100 (che, secondo me, usa un classico supersampling AA di tipo ordered grid) dovrebbe comunque sussistere.
Per questo mi chiedevo se le considerazioni che ATI illustra circa la differenza tra le due modalità di AA (qualità vs. prestazioni) per R200 potessero essere valide anche per R100 o meno, con le dovute proporzioni e differenze.
Per tagliare la testa al toro, domani metto alla prova la mia 7500 e la mia 9250 con SS:SE e le varie modalità di AA: se la seconda filtra meglio della prima, dovrei essere in grado di accorgermene.
Onestamente, infine, questo abbinamento che fai tra AA e AF non l'ho mai sentito prima (del resto, per l'AF c'è l'apposita voce nel pannello): dove lo hai beccato? :stordita:

[shodan]

Ma sei sicuro? Questo è quanto dichiara ATI nel suo documento ufficiale circa la prima implementazione di Smoothvision (R200):

"ATI’s implementation of anti-aliasing provides a substantial improvement over other forms of anti-aliasing found in other GPUs. Instead of shifting every pixel in the same direction, groups of pixels can be individually shifted in different directions. This technique can be used to generate a more random distribution of pixel samples, leading to higher quality anti-aliased images.
SMOOTHVISION™ uses a large group of 16-sample blocks that cover a variable number of pixels, which is determined by the level of anti-aliasing being implemented. Each pixel within every group of 16 samples has their actual sample positions selected from a pre-programmed 8-sample jitter table.
As the level of anti-aliasing is increased, each 16-sample block will cover a smaller number of pixels. For example in the 2x anti-aliasing case, a total of 8 pixels are covered by the 16 sample group, and in the 4x case, a total of 4 pixels are sampled 4 times each.
A non-ordered pixel sampling approach provides the optimal solution, since the eye has a much harder time seeing artifacts in the resulting anti-aliased image, being less sensitive to non-ordered sampling patterns.
High-Quality SMOOTHVISION™ anti-aliasing uses a different texture color per sample, providing superior image quality compared to other competing anti-aliasing techniques, as a greater amount of color data is used to create the final anti-aliased image. Combined with superior sampling pattern of SMOOTHVISION™, the High-Quality SMOOTHVISION™ provides users with an unparalleled anti-aliasing solution.
High-Performance SMOOTHVISION™ anti-aliasing uses a jittered sample pattern for high-quality jagged edge removal, combined with an advanced sample blending and filtering algorithm. This advanced algorithm allows SMOOTHVISION™ to take fewer samples per pixel by blending in samples from other outside pixels. This results in a High-Performance anti-aliasing setting, while maintaining a level of image quality very similar to competing anti-aliasing solutions."

Ricordo anch'io che tale processo non era impiegato nelle prime versioni di driver, ma poi mi sembrava che la cosa fosse stata corretta. Magari non avranno sfruttato tale "jittered sampling pattern" per implementare anche il temporal AA (comunque inutile su tale fascia di prodotto, troppo lento oltre che superato), però la differenza rispetto a R100 (che, secondo me, usa un classico supersampling AA di tipo ordered grid) dovrebbe comunque sussistere.
Per questo mi chiedevo se le considerazioni che ATI illustra circa la differenza tra le due modalità di AA (qualità vs. prestazioni) per R200 potessero essere valide anche per R100 o meno, con le dovute proporzioni e differenze.
Per tagliare la testa al toro, domani metto alla prova la mia 7500 e la mia 9250 con SS:SE e le varie modalità di AA: se la seconda filtra meglio della prima, dovrei essere in grado di accorgermene.

La teoria è proprio come l'hai descritta tu, il punto è che probabilmente non è mai stata esposta a livello driver. ;)
Il test sarà sicuramente interessante, vediamo che succede. Personalmente ricordo che all'inizio alcuni siti scrissero che la modalità Quality abilitasse il pattern pseudo-random mentre la modalità performance fosse un normale OGSS; in tutte le successive recensioni, però, l'AA di R200 viene sempre dato per un normale AA OGSS. Magari prova anche le applicazioni "FSAA tester" e "D3D FSAA Viewer": forniranno sicuramente dei dati interessanti. Le puoi trovare qui: http://www.3dcenter.org/downloads

Onestamente, infine, questo abbinamento che fai tra AA e AF non l'ho mai sentito prima (del resto, per l'AF c'è l'apposita voce nel pannello): dove lo hai beccato? :stordita:
Qui:
http://www.tomshardware.com/reviews/radeon-8500,391-2.html
Tieni però conto che, probabilmente, la differenza tra quality e performance è più legata al diverso dettaglio delle mipmap che ad altro (ricordo infatti che diversi siti notarono che la modalità performance abbassava il LOD delle mipmap).

Ciao. :)

[Murakami]

Qui:
http://www.tomshardware.com/reviews/radeon-8500,391-2.html
Tieni però conto che, probabilmente, la differenza tra quality e performance è più legata al diverso dettaglio delle mipmap che ad altro (ricordo infatti che diversi siti notarono che la modalità performance abbassava il LOD delle mipmap).

Ciao. :)
Che articolo bacato: attribuisce la superiore qualità delle texture di R200 all'anisotropic filtering abilitato di default, asserendo nelle premesse che lo Smoothvision è, al pari di GeForce3, una tecnica di multisampling.
Peccato che sia vero l'esatto contrario, ovverosia che l'AA di R200 è di tipo supersampling è che il superiore dettaglio delle texture è dovuto proprio al sovracampionamento delle stesse... :doh:
Inoltre, che io sappia, la modalità 16X equivale a 128 tap, non 64... :fagiano:

[Murakami]

P3 1 ghz con bus a 133 mhz arrivato e perfettamente funzionante: questo week end lo metto alla frusta con i test, per primi quelli di confronto con il P3 1 ghz con bus a 100... :Perfido:

[shodan]

Che articolo bacato: attribuisce la superiore qualità delle texture di R200 all'anisotropic filtering abilitato di default, asserendo nelle premesse che lo Smoothvision è, al pari di GeForce3, una tecnica di multisampling.
Peccato che sia vero l'esatto contrario, ovverosia che l'AA di R200 è di tipo supersampling è che il superiore dettaglio delle texture è dovuto proprio al sovracampionamento delle stesse... :doh:

Bhe... è il mitico Zio Tom! :stordita:
Comunque, a parte gli scherzi, anche a me la modalità quality sembra semplicemente avere un mipmap LOD più alto, ma, dato l'autorevolezza (:D) della fonte, mi pareva giusto riportare anche la tesi dell'AF abilitato...
Inoltre, che io sappia, la modalità 16X equivale a 128 tap, non 64... :fagiano:

Qui il discorso si complica, in quanto avete ragione tutti e due :p
R200 non può fare aniso+trilinear, e quindi, anche la modalità 16X si limita a prendere 16 campioni bilineari, per un totale di 64 sample. Il punto è questi 64 sample danno un'immagine nitida tanto quanto una da 16X+trilinear (128 sample) ma hanno un problema: in alcune scene la mancaza di trilinear rende discernibile il passaggio tra una mipmap e l'altro. Ecco quindi che il filtro 16X di R200 (16 campioni x 4 textel = 64 tap) ha un'immagine più nitida dell'8X del GF3 (8 campioni x 8 textel = 64 tap) ma, a causa della mancaza del filtro trilineare, può avere il difetto di rendere i bordi delle mipmap visibili.

Il settaggio 128 tap che alcuni twaker fanno impostare per R100 / R200 equivale a un filtraggio anisotropio 32X (con campioni sempre bilineari, ecco quindi i 128 sample).

Ciao. :)

[Murakami]

Il settaggio 128 tap che alcuni twaker fanno impostare per R100 / R200 equivale a un filtraggio anisotropio 32X (con campioni sempre bilineari, ecco quindi i 128 sample).

Ciao. :)
Allora il settaggio 16X del chip R300 non equivale al 16X dei chip R100 o R200?

[Murakami]

...anche a me la modalità quality sembra semplicemente avere un mipmap LOD più alto...
E questo, secondo te, basta a giustificare una differenza di velocità piuttosto evidente tra le due modalità? :confused:

[shodan]

Allora il settaggio 16X del chip R300 non equivale al 16X dei chip R100 o R200?

Il 16X di R200 equivale al 16X performance di R300, ma devi mettere in conto che quest'ultimo soffre meno delle angolazioni delle superfici. A livello di efficacia a diverse angolazioni siamo messi come segue:

R200 -> massima efficacia a multipli e sottomultipli di 90°, efficacia nulla a multipli e sottomultipli di 45°
R300 -> massima efficacia a multipli e sottomultipli di 45° e 90°, efficacia nulla a multipli e sottomultipli di 22,5°

Ciao. :)

[shodan]

E questo, secondo te, basta a giustificare una differenza di velocità piuttosto evidente tra le due modalità? :confused:

A bastare basterebbe, è che ora mi sovviene che la modalità performance generalmente è utilizzabile anche a risoluzioni dove la quality non produce nessun effetto (in quanto è esaurita la memoria del framebuffer).
Mi sa che devo rimontare la Hercules 8500... ;)

Ciao. :)

[Murakami]

Il 16X di R200 equivale al 16X performance di R300, ma devi mettere in conto che quest'ultimo soffre meno delle angolazioni delle superfici. A livello di efficacia a diverse angolazioni siamo messi come segue:

R200 -> massima efficacia a multipli e sottomultipli di 90°, efficacia nulla a multipli e sottomultipli di 45°
R300 -> massima efficacia a multipli e sottomultipli di 45° e 90°, efficacia nulla a multipli e sottomultipli di 22,5°

Ciao. :)
Quello che volevo dire è: preso per base il bilinear filtering (in quanto R100/200 non possono applicare il trilinear in contemporanea all'aniso), i tap della modalità 16X sono gli stessi o no tra i vari chip (R100/200 contro R300)?

[Murakami]

A bastare basterebbe, è che ora mi sovviene che la modalità performance generalmente è utilizzabile anche a risoluzioni dove la quality non produce nessun effetto (in quanto è esaurita la memoria del framebuffer).
Mi sa che devo rimontare la Hercules 8500... ;)

Ciao. :)
Esatto, e questo mi sembra difficile da giustificare con la sola variazione del LOD.

[Murakami]

P3 1 ghz con bus a 133 mhz arrivato e perfettamente funzionante: questo week end lo metto alla frusta con i test, per primi quelli di confronto con il P3 1 ghz con bus a 100... :Perfido:
Ecco i risultati:

Forsaken
Software: 27.2 fps (P3 1000/133) contro 26.2 fps (P3 1000/100)
Kyro2: 264 fps (P3 1000/133) contro 252 fps (P3 1000/100)

Quake 2
Software: 49.8 fps (P3 1000/133) contro 40.6 fps (P3 1000/100)
Kyro2: 138.3 fps (P3 1000/133) contro 125.4 fps (P3 1000/100)

I risultati parlano chiaro: la frequenza del bus fà una grossa differenza, più di un moderato aumento della frequenza della CPU (difatti, le prestazioni sono sempre leggermente superiori anche rispetto al vecchio muletto P3 933).
A questo punto, se mi procurassi una CPU P3 933, i risultati sarebbero paragonabili al muletto originale.

[shodan]

Quello che volevo dirè è: preso per base il bilinear filtering (in quanto R100/200 non possono applicare il trilinear in contemporanea all'aniso), i tap della modalità 16X sono gli stessi o no tra i vari chip (R100/200 contro R300)?

Assolutamente sì: per "tap" si intende l'unità di campionamento base e i due chip non hanno differenze a livello di filtro bilineare. In altre parole, l'AF 16X di R200 (64 tap bilinear o 16 campioni 2x2 bilinear) è identico al 16X performance di R300; ovviamente devi tenere conto del diverso comportamento con le superfici inclinate.

Ciao. :)

[shodan]

Ecco i risultati:

Forsaken
Software: 27.2 fps (P3 1000/133) contro 26.2 fps (P3 1000/100)
Kyro2: 264 fps (P3 1000/133) contro 252 fps (P3 1000/100)

Quake 2
Software: 49.8 fps (P3 1000/133) contro 40.6 fps (P3 1000/100)
Kyro2: 138.3 fps (P3 1000/133) contro 125.4 fps (P3 1000/100)

I risultati parlano chiaro: la frequenza del bus fà una grossa differenza, più di un moderato aumento della frequenza della CPU (difatti, le prestazioni sono sempre leggermente superiori anche rispetto al vecchio muletto P3 933).
A questo punto, se mi procurassi una CPU P3 933, i risultati sarebbero paragonabili al muletto originale.

Mi aspettavo questi risultati: un P3 a 1 Ghz è fortemente limitato dal bus a 100 Mhz... ;)

Ciao. :)

[shodan]

Esatto, e questo mi sembra difficile da giustificare con la sola variazione del LOD.

Già, vale la pena indagare... :mbe:

[Malek86]

Ecco i risultati:

Forsaken
Software: 27.2 fps (P3 1000/133) contro 26.2 fps (P3 1000/100)
Kyro2: 264 fps (P3 1000/133) contro 252 fps (P3 1000/100)

Quake 2
Software: 49.8 fps (P3 1000/133) contro 40.6 fps (P3 1000/100)
Kyro2: 138.3 fps (P3 1000/133) contro 125.4 fps (P3 1000/100

Wow, la differenza così netta in Quake 2 dipende solo dal bus? Accidenti :mbe:

[Max_R]

In fin dei conti è la velocità di comunicazione tra i vari componenti, non c'è tanto da stupirsi ;)

[Murakami]

Assolutamente sì: per "tap" si intende l'unità di campionamento base e i due chip non hanno differenze a livello di filtro bilineare. In altre parole, l'AF 16X di R200 (64 tap bilinear o 16 campioni 2x2 bilinear) è identico al 16X performance di R300; ovviamente devi tenere conto del diverso comportamento con le superfici inclinate.

Ciao. :)
E allora dimmi: dal GeForce3 fino al GeForceFX, nVidia proponeva un AF 8X, poi è passata al 16X. Questo 16X è equivalente (in termini di tap) al 16X di Ati? Però, fin dal GeForce 3 l'AF si poteva abbinare al trilinear: significa che, complessivamente, le capacità di campionamento erano paragonbili tra R200 e NV20?
Inoltre: quando R300 applica trilinear+aniso (combinazione proibita a R100 e R200), quanti tap vengono usati/campionati? 128? Così anche per NV40?
Chiariscimi un pò le idee, principe onorario del retrogaming... :O

[Murakami]

Già, vale la pena indagare... :mbe:
E come indaghiamo? :mbe:
Se vuoi apro un ticket con Ati, ma dai miei recenti precedenti posso dirti che quelli che mettono a rispondere ne sanno meno di noi dei loro chip (non esagero).

[Murakami]

Ho portato a termine il confronto tra Riva 128 e Riva 128ZX, che si è purtroppo rivelato un clamoroso buco nell'acqua. I risultati dello ZX, difatti, sono talmente bassi che mi fanno sospettare che l'esemplare in mio possesso sia dotato di un bus verso la ram a 64 bit, contro i 128 del Riva normale.
Premesso infatti che:
1) vanta un'interfaccia AGP 2X, contro l'1X del fratello minore;
2) monta 8 mb di ram, contro i 4 mb del 128;
3) core clock e mem clock sono in entrambi i casi di 100 mhz (verificati con Powerstrip);
4) il v-sync non si riesce a disattivare in entrambi i chip;
non si giustifica altrimenti uno score di 60.8 fps in Forsaken e di 31 fps in Quake2, contro gli 86.4 fps del 128 "liscio" in Forsaken e 43 fps in Quake2. Vi risparmio gli impietosi score alle risoluzioni più alte (con soli 4 mb il Riva fornisce un frame rate decente a ben 960x720x16, mentre per lo ZX è poco più di una moviola).
Credo che la mia teoria sia anche avvalorata dalla densità delle piste sul PCB: troppo bassa.
Per la cronaca, ho almeno avuto la conferma che non solo l'edge antialiasing non funziona (già verificato con il 128), ma neppure il full scene (che, secondo driver, richiede 8 mb di ram): in entrambi i casi, il risultato visivo è nullo e la velocità rimane inalterata.

P.S. Shodan, Max_R, Sampei, chiunque: se vi spedisco GRATIS il Savage4, fate voi qualche prova (dato che io sono impossibilitato dal case)?

[Max_R]

Basterebbe trovarsi al Mediaworld, comunque sia, ho un Savage (se non ricordo male). Ora lo cerco e poi vi dico.

[walter sampei]

purtroppo per motivi di spazio e problemi in casa sono impossibilitato... ho da mesi un muletto quasi completo, che non posso usare :muro: :cry:

[Max_R]

Basterebbe trovarsi al Mediaworld, comunque sia, ho un Savage (se non ricordo male). Ora lo cerco e poi vi dico.ELSA Winner II-A16 SG ;)

[Murakami]

Basterebbe trovarsi al Mediaworld, comunque sia, ho un Savage (se non ricordo male). Ora lo cerco e poi vi dico.
Ecco, fammi sapere, se non lo trovi ci vediamo da MW e te lo do io.

[shodan]

E allora dimmi: dal GeForce3 fino al GeForceFX, nVidia proponeva un AF 8X, poi è passata al 16X. Questo 16X è equivalente (in termini di tap) al 16X di Ati? Però, fin dal GeForce 3 l'AF si poteva abbinare al trilinear: significa che, complessivamente, le capacità di campionamento erano paragonbili tra R200 e NV20?
Inoltre: quando R300 applica trilinear+aniso (combinazione proibita a R100 e R200), quanti tap vengono usati/campionati? 128? Così anche per NV40?
Chiariscimi un pò le idee, principe onorario del retrogaming... :O

Allora, vediamo di fare un po' di chiarezza: per tap si intende la singola campionatura, e, quindi, per numero di tap si intende la capacità di campionatura della scheda. Vale la pena fare una piccola tabellina di riferimento:
- filtro bilineare: 4 tap (o sample o campionature, se preferisci... parliamo della stessa cosa)
- filtro trilineare: 2 sample bilineari, cioè 8 tap
- filtro anisotropico+bilinear 2X: 2 sample bilineari, cioè 8 tap
- filtro anisotropico+bilinear 4X: 4 sample bilineari, cioè 16 tap
- filtro anisotropico+bilinear 8X: 8 sample bilineari, cioè 32 tap
- filtro anisotropico+bilinear 16X: 16 sample bilineari, cioè 64 tap
- filtro anisotropico+trilinear 2X: 2 sample trilineari, cioè 16 tap
- filtro anisotropico+trilinear 4X: 4 sample trilineari, cioè 32 tap
- filtro anisotropico+trilinear 8X: 8 sample trilineari, cioè 64 tap
- filtro anisotropico+trilinear 16X: 16 sample trilineari, cioè 128 tap

Come si può vedere, diverse impostazioni possono condividere lo stesso numero di tap: basti vedere i casi del semplice filtro trilineare e il 2X aniso+bilinear, oppure il 16X aniso+bilinear e l'8X aniso+trilinear.
Vuol dire questo che tali impostazioni producono gli stessi risultati visivi? No.
Perchè? Perchè nel caso delle impostazioni che prevedono il filtro trilineare, metà dei tap è dedicata al campionamento della successiva mipmap, da amalgamare con la mipmap corrente in modo da non rendere visibile il passaggio da una mipmap all'altra.
Ecco quindi che, pur usando lo stesso numero di tap, il 16X aniso+bilinear ha una nitidezza superiore al settaggio 8X aniso+trilinear ma ha il difetto di rendere visibile il passaggio da una mipmap all'altra (problema di cui le modalità con trilinear non soffrono).

Torniamo ai chip grafici, e facciamo anche qui una piccola tabellina:
- R100 -> max 16X / 32X aniso+bilinear -> 64 / 128 tap (la modalità 32X è attivabile tramite tweaker)
- R200 -> max 16X / 32X aniso+bilinear -> 64 / 128 tap (la modalità 32X è attivabile tramite tweaker)
- R300 -> max 16X aniso+trilinear -> 128 tap
- NV10 / NV15 -> max 2X aniso+trilinear -> 16 tap *
- NV20 / NV25 -> max 8X aniso+trilinear -> 64 tap
- NV30 -> max 8X aniso+trilinear -> 64 tap
- NV40 -> max 16X aniso+trilinear -> 128 tap

* per NV10 / NV15 sono dati indicativi... sinceramente è passato troppo tempo e non ricordo al 100% se tali chip possono combinare aniso+trilinear.

Ciao. :)

[shodan]

E come indaghiamo? :mbe:
Se vuoi apro un ticket con Ati, ma dai miei recenti precedenti posso dirti che quelli che mettono a rispondere ne sanno meno di noi dei loro chip (non esagero).

No, non aprendo un ticket a ATI, ma cercando qualcosa nel web e, in caso contrario, vedendo come possiamo verificare noi stessi i vari settaggi... :stordita:

[shodan]

Ho portato a termine il confronto tra Riva 128 e Riva 128ZX, che si è purtroppo rivelato un clamoroso buco nell'acqua. I risultati dello ZX, difatti, sono talmente bassi che mi fanno sospettare che l'esemplare in mio possesso sia dotato di un bus verso la ram a 64 bit, contro i 128 del Riva normale.
Premesso infatti che:
1) vanta un'interfaccia AGP 2X, contro l'1X del fratello minore;
2) monta 8 mb di ram, contro i 4 mb del 128;
3) core clock e mem clock sono in entrambi i casi di 100 mhz (verificati con Powerstrip);
4) il v-sync non si riesce a disattivare in entrambi i chip;
non si giustifica altrimenti uno score di 60.8 fps in Forsaken e di 31 fps in Quake2, contro gli 86.4 fps del 128 "liscio" in Forsaken e 43 fps in Quake2. Vi risparmio gli impietosi score alle risoluzioni più alte (con soli 4 mb il Riva fornisce un frame rate decente a ben 960x720x16, mentre per lo ZX è poco più di una moviola).
Credo che la mia teoria sia anche avvalorata dalla densità delle piste sul PCB: troppo bassa.
Per la cronaca, ho almeno avuto la conferma che non solo l'edge antialiasing non funziona (già verificato con il 128), ma neppure il full scene (che, secondo driver, richiede 8 mb di ram): in entrambi i casi, il risultato visivo è nullo e la velocità rimane inalterata.

Accidenti, ero curioso di vedere quanto lo ZX era più veloce del Riva128 liscio: nvidia dichiarava un +50%, ma non ho mai potuto verificare.

P.S. Shodan, Max_R, Sampei, chiunque: se vi spedisco GRATIS il Savage4, fate voi qualche prova (dato che io sono impossibilitato dal case)?

Be', io un Savage4 32 MB ce l'ho (anche se OEM): che bench vuoi che faccia?

Ciao. :)

[Murakami]

Allora, vediamo di fare un po' di chiarezza: per tap si intende la singola campionatura, e, quindi, per numero di tap si intende la capacità di campionatura della scheda. Vale la pena fare una piccola tabellina di riferimento:
- filtro bilineare: 4 tap (o sample o campionature, se preferisci... parliamo della stessa cosa)
- filtro trilineare: 2 sample bilineari, cioè 8 tap
- filtro anisotropico+bilinear 2X: 2 sample bilineari, cioè 8 tap
- filtro anisotropico+bilinear 4X: 4 sample bilineari, cioè 16 tap
- filtro anisotropico+bilinear 8X: 8 sample bilineari, cioè 32 tap
- filtro anisotropico+bilinear 16X: 16 sample bilineari, cioè 64 tap
- filtro anisotropico+trilinear 2X: 2 sample trilineari, cioè 16 tap
- filtro anisotropico+trilinear 4X: 4 sample trilineari, cioè 32 tap
- filtro anisotropico+trilinear 8X: 8 sample trilineari, cioè 64 tap
- filtro anisotropico+trilinear 16X: 16 sample trilineari, cioè 128 tap

Come si può vedere, diverse impostazioni possono condividere lo stesso numero di tap: basti vedere i casi del semplice filtro trilineare e il 2X aniso+bilinear, oppure il 16X aniso+bilinear e l'8X aniso+trilinear.
Vuol dire questo che tali impostazioni producono gli stessi risultati visivi? No.
Perchè? Perchè nel caso delle impostazioni che prevedono il filtro trilineare, metà dei tap è dedicata al campionamento della successiva mipmap, da amalgamare con la mipmap corrente in modo da non rendere visibile il passaggio da una mipmap all'altra.
Ecco quindi che, pur usando lo stesso numero di tap, il 16X aniso+bilinear ha una nitidezza superiore al settaggio 8X aniso+trilinear ma ha il difetto di rendere visibile il passaggio da una mipmap all'altra (problema di cui le modalità con trilinear non soffrono).

Torniamo ai chip grafici, e facciamo anche qui una piccola tabellina:
- R100 -> max 16X / 32X aniso+bilinear -> 64 / 128 tap (la modalità 32X è attivabile tramite tweaker)
- R200 -> max 16X / 32X aniso+bilinear -> 64 / 128 tap (la modalità 32X è attivabile tramite tweaker)
- R300 -> max 16X aniso+trilinear -> 128 tap
- NV10 / NV15 -> max 2X aniso+trilinear -> 16 tap *
- NV20 / NV25 -> max 8X aniso+trilinear -> 64 tap
- NV30 -> max 16X aniso+trilinear -> 128 tap

* per NV10 / NV15 sono dati indicativi... sinceramente è passato troppo tempo e non ricordo al 100% se tali chip possono combinare aniso+trilinear.

Ciao. :)
Eccellente riassunto, e... si, GeForce 1 e 2 possono applicare trilinear + aniso contemporaneamente (lo so per esperienza diretta).
Questa del tweaker che rende possibile l'aniso 32X su R100 e R200 non la sapevo: che tool serve?

[Murakami]

Accidenti, ero curioso di vedere quanto lo ZX era più veloce del Riva128 liscio: nvidia dichiarava un +50%, ma non ho mai potuto verificare.


Be', io un Savage4 32 MB ce l'ho (anche se OEM): che bench vuoi che faccia?

Ciao. :)

Cercherò un altro ZX, ma non sarà facile: ce ne sono pochissimi in giro. Al 50%, comunque, non credo affatto.
Mi piacerebbe che benchassi i soliti Quake2 e Forsaken con il Savage4, esattamente con le impostazioni da prima pagina: vorrei vedere dove si inserisce a livello di prestazioni, oltre ad un tuo giudizio sulla qualità d'immagine.

[shodan]

Eccellente riassunto, e... si, GeForce 1 e 2 possono applicare trilinear + aniso contemporaneamente (lo so per esperienza diretta).
Questa del tweaker che rende possibile l'aniso 32X su R100 e R200 non la sapevo: che tool serve?

Una qualsiasi vecchia versione di Rage3D Tweaker dovrebbe andare bene: l'opzione si chiama "128 tap anisotropic" o qualcosa del genere ;)

Ciao. :)

[shodan]

Cercherò un altro ZX, ma non sarà facile: ce ne sono pochissimi in giro. Al 50%, comunque, non credo affatto.
Mi piacerebbe che benchassi i soliti Quake2 e Forsaken con il Savage4, esattamente con le impostazioni da prima pagina: vorrei vedere dove si inserisce a livello di prestazioni, oltre ad un tuo giudizio sulla qualità d'immagine.

Vedo di organizzarmi... ;)

[Murakami]

No, non aprendo un ticket a ATI, ma cercando qualcosa nel web e, in caso contrario, vedendo come possiamo verificare noi stessi i vari settaggi... :stordita:
Cercherò, ma le prove dei chip sono spesso fatte con i primi driver, che raramente implementano tutte le features: in questo caso, l'esempio è del tutto calzante, trattandosi anche di prodotti vecchi e abbandonati. Quanto alla verifica personale... beh, proverò ad aguzzare il mio occhio di falco, tu fai altrettanto... :mbe:

[shodan]

Cercherò, ma le prove dei chip sono spesso fatte con i primi driver, che raramente implementano tutte le features: in questo caso, l'esempio è del tutto calzante, trattandosi anche di prodotti vecchi e abbandonati. Quanto alla verifica personale... beh, proverò ad aguzzare il mio occhio di falco, tu fai altrettanto... :mbe:

Nulla potrà sfuggire ai nostri occhi bionici... :read: :banned: :ciapet:

[Max_R]

Trovata: il codice è scritto sopra, non so dirvi di più oltre al fatto che ha 16 mb SGRam. Secondo voi che Savage è?
Tu, Murakami, che Savage hai?

[shodan]

Dato che in questo periodo al lavoro ho diverso tempo libero (clienti in ferie! :p ), ho finalmente fatto i test che avevo promesso da tanto tempo.

Il sistema utilizzato è il seguente:
CPU: P3 coppermine 1 GHz;
MB: Compaq i815;
RAM: 512 MB SDR 133;
HD: 20GB (utilizzati un'unica partizione da 2GB, sia per il sistema operativo che per le applicazioni);
OS: Win98 SE.

Il sistema è stato installato da 0; fatto questo ho provveduto a installare, nell'ordine:
-) driver AGP;
-) directX 9.0c;
-) driver video (salvo diversa indicazione, sono stati usati gli ultimi reference messi a disposizione dalle varie case produttrici);
-) applicazioni usate per i benchmark.
A fine installazione, il sistema è stato deframmentato.
Tutti i valori indicati dai grafici sotto sono stati presi al secondo "giro" di ogni programma usato come benchmark; fa eccezione il 3DMark 2000 (è stato preso come valido il primo risultato ottenuto).

Ecco le schede video testate:
-) Ati Rage Pro Turbo 8MB AGP - frequenze 75/100 (core/mem)
http://img105.imageshack.us/img105/3745/rageproturbofrontec5.th.jpg (http://img105.imageshack.us/my.php?image=rageproturbofrontec5.jpg)
http://img105.imageshack.us/img105/4964/rageproturbobackpf6.th.jpg (http://img105.imageshack.us/my.php?image=rageproturbobackpf6.jpg)
Note: nulla in particolare.

-) Matrox G200 LE 8MB AGP - frequenze 84/112 (core/mem)
http://img104.imageshack.us/img104/9295/g200frontna4.th.jpg (http://img104.imageshack.us/my.php?image=g200frontna4.jpg)
http://img87.imageshack.us/img87/2966/g200backuc0.th.jpg (http://img87.imageshack.us/my.php?image=g200backuc0.jpg)
Note: la scheda è stata provata anche usando i driver per G400, il cui pacchetto autoestraente conteneva anche i file relativi alla G200. Non ci sono state differenze prestazionali, mentre diversi giochi hanno esibito artefatti. Ho così scartato quei valori, lasciando solo quelli ottenuti con l'ultima release dei driver per G200 indicata sul sito Matrox.

-) S3 Savage4 Extreme 32MB AGP - frequenze 143/143 (core/mem)
http://img291.imageshack.us/img291/9110/savage4extremefrontoh1.th.jpg (http://img291.imageshack.us/my.php?image=savage4extremefrontoh1.jpg)
http://img82.imageshack.us/img82/3914/savage4extemebackeh1.th.jpg (http://img82.imageshack.us/my.php?image=savage4extemebackeh1.jpg)
Note: questa scheda mi ha fatto tribolare non poco. L'etichetta incollata sul PCB riporta la dicitura "Savage4 Xtreme", cioè dovrebbe avere frequenze di 143/143 oppure di 166/166 (a seconda della versione, dato che sono usciti due modelli "Xtreme"). La frequenza corretta dovrebbe essere proprio quella di 143/143, in virtù dei chip RAM che monta (da 7ns, quindi 143 Mhz). Il BIOS della scheda però riporta le frequenza classiche del Savage4 Pro, cioè 110/125. Dato che la scheda si presenta come un modello "Xtreme", ho deciso di impostare a mano (tramite il tool SavageTweak) la suddetta frequenza. Putroppo però la scheda si bloccava di continuo. Nel tentativo di risolvere il problema, ho cambiato release di driver utilizzati, eliminando quelli messi a disposizione dal sito www.s3graphics.com e utilizzando quelli trovati nell'area download di hwupgrade, che sono leggermente più nuovi (versione 8.20.38). Il problema però persisteva. Allora ho reimpostato i clock indicati dal BIOS, sperando che questo risolvesse la situazione. Nulla da fare. Ho quindi messo una ventolina sul dissipatore (passivo) della scheda, riuscendo ad alleviare notevolmente il problema. Dopo qualche test, ho reimpostato le frequenze di 143/143 ed eseguito i benchmark con queste impostazioni e con i driver 8.20.38.

-) Matrox G400 16MB AGP - frequenze 126/168 (core/mem)
http://img520.imageshack.us/img520/2681/g400frontll1.th.jpg (http://img520.imageshack.us/my.php?image=g400frontll1.jpg)
http://img520.imageshack.us/img520/1019/g400backgv1.th.jpg (http://img520.imageshack.us/my.php?image=g400backgv1.jpg)
Note: nulla in particolare.

-) Nvidia TNT2 Pro 32MB AGP - frequenze 142/166
http://img238.imageshack.us/img238/7536/tnt2profrontjj2.th.jpg (http://img238.imageshack.us/my.php?image=tnt2profrontjj2.jpg)
http://img105.imageshack.us/img105/6367/tnt2probackou0.th.jpg (http://img105.imageshack.us/my.php?image=tnt2probackou0.jpg)
Note: la scheda è stata provata sia con i driver 6.31 (con cui ricordavo che andasse molto bene), sia con i driver 71.84 (uno degli ultimi set a supportare la suddetta scheda). In questo modo è stato possibile valutare anche i vantaggi/svantaggi prestazionali incorsi durante lo sviluppo dei driver da parte di Nvidia. Inoltre, è da segnalare il fatto che la scheda è leggermente danneggiata; questo comporta la presenza, a video, di alcuni artefatti (come punti fuori posto, colori delle texture non sempre perfetti, ecc). I difetti sono più visibili utilizzando l'ultima versione dei driver video.

-) Intel i815 - frequenze 100/100, integrato su scheda madre (presente a titolo di confronto).

Le applicazioni testare le prestazioni sono:
-) Quake 2 demo (OpenGL)
-) Quake 3 demo (OpenGL)
-) Forsaken (D3D)
-) Unreal Tournament v4.36 (D3D)
-) Final Reality (D3D)
-) 3DMark 2000 (D3D)

Le impostazioni comuni utilizzate sono:
-) risoluzione 1024x768
-) Vsync off;
-) double buffer;
-) con rendering a 16 bit, anche lo z-buffer e le texture sono state impostate a 16 bit;
-) con rendering a 32 bit, lo z-buffer è stato impostato a 24 bit e le texture, ove possibile, a 24 bit

Tutte le altre impostazioni dei vari driver sono state lasciate come di default.

Ecco quindi, finalmente, i risultati...

http://img133.imageshack.us/img133/4282/giochi16bitvw2.jpg
Nota 1: la G200 esibisce degli artefatti in Quake 3. Inoltre in Unreal Tournament sono sporadicamente visibile le linee di giunzione tra i poligoni.
Nota 2: utilizzando l'API proprietaria Metal con il gioco Unreal Tournament, la Savage4 esibisce alcuni problemi con le texture (non sono state utilizzate le texture ultra-definite contenute nel 2° CD del gioco).

http://img90.imageshack.us/img90/2986/giochi32bitqn2.jpg
Nota 1: l'i815 è stato provato con rendering a 24 bit, in quanto incapace di effettuarlo a 32 bit.
Nota 2: il Rage Pro Turbo non riesce a far girare Quake 3 utilizzando un framebuffer a 32 bit; il gioco continua a renderizzare a 16 bit nonostante il menù di configurazione visualizzi impostati i 32 bit.
Nota 3: la G200 non riesce a far girare Unreal Tournament utilizzando un framebuffer a 32 bit; il gioco, se si impostanto i 32 bit, passa al rendering in finestra.
Nota 4: la Savage4 mostra artefatti utilizzando il gioco Unreal Tournament con un framebuffer a 32 bit, sia utilizzando l'API D3D che Metal.

http://img90.imageshack.us/img90/5858/finalrealitytf1.jpg

http://img91.imageshack.us/img91/8505/3dmark2000scorefr5.jpg
Nota 1: l'i815 è stato testato solo con rendering a 16 bit, in quanto incapace di rendering a 32 bit.
Nota 2: i driver 71.84 non permettono al TNT2 di eseguire questo benchmark (il 3DMark 2000 esce al desktop o da un errore in fase di avvio, dicendo di non trovare hardware DX7)

http://img91.imageshack.us/img91/2443/3dmark2000fillratenj7.jpg

http://img91.imageshack.us/img91/1314/3dmark2000polyzv1.jpg


Alcune considerazioni...
-) Ati Rage Pro Turbo: le prestazioni erano il linea con quanto mi aspettavo, ma mi ha sorpreso la compatibilità dei driver ATI: sono stati capaci di far girare sia UT che Q3, risultando inoltre compatibili con le DX8.1 (almeno stando al readme contenuto nel pacchetto dei driver). Ottima la qualità e le performance 2D della scheda.
-) Matrox G200: sinceramente sono un po' deluso dalla sue prestazioni, mi aspettavo di meglio. I driver OpenGL in particolare risultano lenti e, in qualche modo, buggati (non mi spiego in altro modo tutt gli artefatti avuti con Q3). Le prestazioni e la qualità 2D risultano, come sempre, ottime.
-) Savage 4 Xtreme: a livello prestazionale la scheda non mi ha sopreso: era lì dove me la ricordavo. Significativi comunque i 25 fps ottenuti con Q3, soprattuto considerando il bus a 64 bit. Non ricordavo invece cali così marcati utilizzando il rendering a 32 bit (tra le altre cose, anche nella recensione di Anandtech si leggeva che la scheda non aveva grossi cali passando ai 32 bit... bho!). La sua carta vincente rimaneva, per l'epoca, il supporto all'S3TC, che garantiva ai giochi che lo supportavano a dovere (in pratica solo Unreal e UT) una grafica davvero spettacolare. La qualità 2D della scheda non mi ha entusiasmato, anzi, ritengo migliore quella della grafica integrata. A casa però usavo una Savage4 prodotta dalla Creative che aveva una qualità 2D decisamente migliore.
-) Matrox G400: questa scheda mi ha lasciato un po' indeciso. Velocissima in Forsaken e in UT (in quest'ultimo però a 32 bit accusa un calo marcato), crolla letteralmente con Q3. Perde il confronto con la TNT2 Pro anche con il 3DMark 2000. A parziale discolpa ci sono i soli 16 MB di RAM (che, con il rendering a 32 bit, probabilmente saranno stati saturati sia da UT che Q3) e il fatto che ha una qualità 3D decisamente migliore di quella sfoderata dal TNT2 Pro. Ottima qualità e performance 2D.
-) TNT2 Pro: la classica TNT2 "no brand", dal costo limitato e dalle prestazioni elevate. Paga però il fatto di essere economica con una qualità 2D scadente: direi la peggiore del gruppo.

Che altro aggiungere... al momento mi pare di avere detto tutto, ma sicuramente qualcosa mi verrà in mente dopo! :p

Ciao a tutti. :)

Mi quoto per fornirvi alcuni bench sulla Savage4, nel mentre che ne facciamo di nuovi... ;)
Vi ricordo che la risoluzione utilizzata è 1024x768

Ciao.

[Murakami]

Trovata: il codice è scritto sopra, non so dirvi di più oltre al fatto che ha 16 mb SGRam. Secondo voi che Savage è?
Tu, Murakami, che Savage hai?
Una Number Nine SR9 AGP SDRAM NLX 8 mb. Credo sia un Savage4 LT, qualsiasi cosa significhi.
E' questa (http://oferta.deremate.com.ar/id=17914925_aceleradora-number-nine-sr9-agp-2x-sdram-nlx-8mb).

[Murakami]

- NV30 -> max 16X aniso+trilinear -> 128 tap
Vedo solo ora: credo che tu debba cambiare NV30 con NV40.

[Murakami]

Non vorrei farmi bello per nulla, ma ho trovato e flashato con successo l'ultimo BIOS del Riva128 (Diamond Viper V330 AGP 4 mb)... :sofico:

[Murakami]

Mi quoto per fornirvi alcuni bench sulla Savage4, nel mentre che ne facciamo di nuovi... ;)
Vi ricordo che la risoluzione utilizzata è 1024x768

Ciao.
Piccola nota: secondo me ti sei dimenticato, parlando di TNT e driver serie 70, di abilitare l'estensione GL_SGIS_MULTITEXTURE con RivaTuner.

[Max_R]

La mia Riva 128 è STB, peccato che io non abbia ZX.

[Murakami]

La mia Riva 128 è STB, peccato che io non abbia ZX.

Tu riesci, in qualche modo, a togliere il v-sync? Io ho provato con Powerstrip, ma il settaggio non ha effetto. Sarei davvero curioso di vedere il risultato con Forsaken senza v-sync.

[Malek86]

Mi quoto per fornirvi alcuni bench sulla Savage4, nel mentre che ne facciamo di nuovi... ;)
Vi ricordo che la risoluzione utilizzata è 1024x768

Ciao.

Orz, faceva così schifo la G200? Dai test su internet sembrava migliore. Fortuna che ho ordinato la versione da 16Mb, forse andrà un po' meglio... e fortuna anche che il mio monitor arriva fino a 640x480 :D

[Max_R]

A risoluzioni "basse" è la cpu che fa la differenza ;)
Dove hai preso la 16 mb?
Tu riesci, in qualche modo, a togliere il v-sync? Io ho provato con Powerstrip, ma il settaggio non ha effetto. Sarei davvero curioso di vedere il risultato con Forsaken senza v-sync.Posso provare!

[Murakami]

Orz, faceva così schifo la G200? Dai test su internet sembrava migliore. Fortuna che ho ordinato la versione da 16Mb, forse andrà un po' meglio... e fortuna anche che il mio monitor arriva fino a 640x480 :D

La versione di shodan (LE) è particolarmente sfigata: la Millennium G200 con SGRAM è molto più veloce.

[Murakami]

Posso provare!

Fammi sapere, anche se la vedo dura.

[Malek86]

A risoluzioni "basse" è la cpu che fa la differenza ;)
Dove hai preso la 16 mb?
Posso provare!

Su Ebay... strano che non mi sia ancora arrivata, in realtà. Alla fine della settimana chiedo al venditore.

[shodan]

Una Number Nine SR9 AGP SDRAM NLX 8 mb. Credo sia un Savage4 LT, qualsiasi cosa significhi.
E' questa (http://oferta.deremate.com.ar/id=17914925_aceleradora-number-nine-sr9-agp-2x-sdram-nlx-8mb).

Il Savage4LT è un Savage4 con clock ridotti e supporto per un massimo di 16 MB di RAM... tutto qui. ;)

Ciao. :)

[shodan]

Vedo solo ora: credo che tu debba cambiare NV30 con NV40.

Giusto: NV30 permette di utilizzare un anisotropico fino al livello 8X.
Grazie per la segnalazione, correggo subito. ;)

Ciao. :)

[shodan]

Piccola nota: secondo me ti sei dimenticato, parlando di TNT e driver serie 70, di abilitare l'estensione GL_SGIS_MULTITEXTURE con RivaTuner.

No, non me ne sono dimenticato: ho semplicemente lasciato le impostazioni di default perchè, comparando due set di driver, mi sembrava giusto lasciare i settaggi predefiniti.

Ciao. :)

[shodan]

La versione di shodan (LE) è particolarmente sfigata: la Millennium G200 con SGRAM è molto più veloce.

Quoto: il chip G200 andava decisamente meglio con le SGRAM ;)

[walter sampei]

Il Savage4LT è un Savage4 con clock ridotti e supporto per un massimo di 16 MB di RAM... tutto qui. ;)

Ciao. :)

certo che ci voleva coraggio a castrare un savage... o volevano battere il virge? :sofico:

[Crisp]

Può essere, ma la CPU al 100% e la GPU "fredda" sono dati oggettivi, riscontrati da più parti.

Ma tu hai provato personalmente un encoding usando solo la cpu e lo stesso encoding usando l'avivo converter?
Non cambia di una virgola?

[Murakami]

Ma tu hai provato personalmente un encoding usando solo la cpu e lo stesso encoding usando l'avivo converter?
Non cambia di una virgola?
L'Avivo converter è molto più rapido, ma la qualità dell'output è inferiore.

[Crisp]

e allora la gpu viene usata..
anche se non al 100%, però forse ci si rimette in qualità.

purtroppo non essendo compatibile con XP a 64bit non ho mai potuto provarlo.
Sempre che non decida di riesumarla per il secondo pc anche se la scheda madre che usavo prima non da segni di vita..

[Murakami]

e allora la gpu viene usata..
anche se non al 100%, però forse ci si rimette in qualità.
Non puoi inferire questo, dato che la qualità è inferiore: qualsiasi software può fare un transcoding di pessima qualità mettendoci meno tempo. I dati oggettivi relativi all'utilizzo della CPU e alla temperatura della GPU sono molto più indicativi.

[Murakami]

Ragazzi, secondo voi la prova di una Matrox G550 sarebbe interessante o è un prodotto trascurabile? C'è un tipo sul mercatino che la vende per 15 €, spedizione inclusa... :fagiano:
http://www.hwupgrade.it/forum/showthread.php?t=1729451

[Max_R]

Ragazzi, secondo voi la prova di una Matrox G550 sarebbe interessante o è un prodotto trascurabile? C'è un tipo sul mercatino che la vende per 15 €, spedizione inclusa... :fagiano:
http://www.hwupgrade.it/forum/showthread.php?t=1729451Se non sbaglio sono schede limitate ad un bus di 64 bit per le memorie, seppure ddr. Solitamente schede del genere non faccio fatica a trascurarle :stordita:

[Murakami]

Se non sbaglio sono schede limitate ad un bus di 64 bit per le memorie, seppure ddr. Solitamente schede del genere non faccio fatica a trascurarle :stordita:

Sostanzialmente, è una G400 con bus a 64bit (contro 128) e ram DDR (contro SDR): la banda passante è circa quella. In più, vanta un mai usato/esposto motore di matrix palette skinning (chi si ricorda il morto sul nascere headcasting sa di cosa parlo) e, soprattutto, 2 texture unit per pipe, contro la singola del G400/450. Poteva essere interessante vedere come quest'ultimo aspetto influisce nei giochi multitexture... :fagiano:

[Max_R]

Si, ricordo la tecnologia ma non l'ho mai vista all'opera.

[Luxor83]

Orz, faceva così schifo la G200? Dai test su internet sembrava migliore. Fortuna che ho ordinato la versione da 16Mb, forse andrà un po' meglio... e fortuna anche che il mio monitor arriva fino a 640x480 :D

No per niente, con i primi driver faceva decisamente defecare, io l'ho presa con il mio primo pc e addirittura non era ancora stato abilitato l'agp texturing o una cosa del genere. Poi qualche mese dopo capito un pò meglio l'uso e l'importanza dei driver misi gli ultimi usciti e la vga ebbe un boost che non oso dire superiore al 50%, mi ricordo con l'allora 3d mark 99 facevo quasi 2500punti in overclock quando una tnt2 o un g400max facevano poco più di 3000 con un PIII500 (io avevo il PIII450), con quake3 sono riuscito poi a giocare ma non benissimo. E udite udite RE-VOLT mi andava a 1024*768 senza scendere mai sotto ai 30FPS. Io me la ricordo come un ottima vga, senza picchi si, ma qualitativamente superiore alle altre della sua epoca, 32bit - poi mi pare avesse una cosa che si chiamava vibrant color quality o qualcosa del genere. L'unico punto debole erano i driver, poi quando uscì il G400 uscirono driver molto migliori che me la fecero tenere per un altro anno.

Poi presi la GeForce DDR.......un altra storia.

[Murakami]

...poi mi pare avesse una cosa che si chiamava vibrant color quality o qualcosa del genere...
Si, un bel nome per una non-feature di puro marketing (elaborazione interna a 32 bit: tutto qui)... :D

[walter sampei]

Si, un bel nome per una non-feature di puro marketing (elaborazione interna a 32 bit: tutto qui)... :D

se non ricordo male anche altri chip video dell'epoca e degli anni successivi vantavano una elaborazione interna a 32 bit... mi pare anche il v3 (oltre al kyro 2)... o sbaglio? :confused:

[Murakami]

se non ricordo male anche altri chip video dell'epoca e degli anni successivi vantavano una elaborazione interna a 32 bit... mi pare anche il v3 (oltre al kyro 2)... o sbaglio? :confused:
Praticamente, quasi tutti: ma a Matrox piaceva vantarsi dei suoi RAMDAC e inventava nomi strambi... :p

[Luxor83]

Si, un bel nome per una non-feature di puro marketing (elaborazione interna a 32 bit: tutto qui)... :D

Bhè guarda ti dico una cosa, marketing o meno, matrox vantava una qualità grafica con G200 e il G400 poi che gli altri si sognavano....3dfx tutta velocità ma colori a 16bit sia con Vodoo2 ( infatti si montava G200+Voodo) che con il Vodoo3 (antagonista di G400) ma sempre con 16 bit di colore. Poi c'era tnt con i mipmap davvero scadenti e qualità bassa.

[Murakami]

Bhè guarda ti dico una cosa, marketing o meno, matrox vantava una qualità grafica con G200 e il G400 poi che gli altri si sognavano....3dfx tutta velocità ma colori a 16bit sia con Vodoo2 ( infatti si montava G200+Voodo) che con il Vodoo3 (antagonista di G400) ma sempre con 16 bit di colore. Poi c'era tnt con i mipmap davvero scadenti e qualità bassa.

Si, è vero, ma dipendeva per lo più dai DAC. Le Voodoo non sono nemmeno paragonabili, in quanto incapaci di rendering a 32 bit (in output, a livello di frame buffer).

[Luxor83]

Si, è vero, ma dipendeva per lo più dai DAC. Le Voodoo non sono nemmeno paragonabili, in quanto incapaci di rendering a 32 bit (in output, a livello di frame buffer).

Si esatto io in ogni caso, quando presi il GeforceDDR, certo era un altro mondo in velocità e ci mancherebbe altro, però al primo impatto giuro che non mi ha qualitativamente sorpreso rispetto al mio vetusto G200. Stessa cosa quando sono passato dal GeForceDDR alla GeForce4 Ti4600, molta più velocità, molti più effetti, davvero bella a primo impatto perchè mi permetteva di giocare molto meglio, ma, ci sono rimasto sempre male per la qualità visiva parlo a livello proprio di colori, mi sembravano morti, troppo spenti non mi trasmettevano nulla. Poi con la 9800XT sono ritornato a vedere quella vivacità di colori che un tempo riusciva a trasmettermi il G200 di matrox.

Personalmente quando matrox si ritirò dalla corsa alle vga da gioco ci sono rimasto troppo ma troppo male, ha tirato fuori sempre schede ottime fino al G400Max, chi si ricorda il Bump Mapping? Quando lo vidi per la prima volta ci sono rimasto proprio di cacca! C'era un gioco Draken: the order of the Flame che sfruttava quella tecnologia ed era stupendo (anche come gioco oltre che graficamente).

[Max_R]

...chi si ricorda il Bump Mapping? Quando lo vidi per la prima volta ci sono rimasto proprio di cacca! C'era un gioco Draken: the order of the Flame che sfruttava quella tecnologia ed era stupendo (anche come gioco oltre che graficamente).Sei nel posto giusto :D Ho adorato Drakan (sia come gameplay che graficamente) ;)

[Luxor83]

Sei nel posto giusto :D Ho adorato Drakan (sia come gameplay che graficamente) ;)

Un gioco stupendo. Se nn ricordo male esisteva un bench su quel gioco, forse interno direttamente

[Murakami]

chi si ricorda il Bump Mapping?
Qui si parla di bump mapping una pagina si e due no... :D

[Luxor83]

Qui si parla di bump mapping una pagina si e due no... :D

Ebè infatti io ho letto solo le ultime due! :ciapet:

[Murakami]

Nei prossimi giorni intendo cimentarmi in qualche test approfondito del Radeon 7500: in particolare, cercherò di misurare l'utilizzo e l'efficacia della terza TMU.
Pensavo: in un gioco single texture come "Forsaken", una sola TMU viene adoperata; corretto? Se abilito il trilinear filtering, entra in gioco la seconda TMU o anche la terza?
In poche parole, vorrei una situazione in cui il gioco non adoperi di default la terza TMU, per poi utilizzarla attivando il trilinear: quale potrebbe essere lo scenario ideale? Forse Quake2, un gioco che adopera 2 texture per passata? O magari Quake3?
Potrei poi verificare la differenza prestazionale con una VGA DX7 dotata di sole 2 TMU per pipe, che quindi è costretta a ricorrere al multipass per il filtro trilineare... e poi anche con una scheda DX8 a singola TMU per pipe, che non deve ricorrere al multipass (grazie alle capacità di loopback della pipeline) ma che è comunque costretta a sprecare più di un ciclo di clock.
Infine, voglio provare Serious Sam in bilinear filtering, impostando prima 2 texture per passata e poi 3: la differenza prestazionale dovrebbe essere eclatante (di molto superiore rispetto ad una VGA che esegue si 3 o più texture per passata, ma in più cicli di clock: tipoco scenario di un scheda DX8 o DX9, con solo 1 o 2 TMU per pipe).
Shodan, ragiono bene o male? Hai qualcosa da dire? :O

[Murakami]

Nei prossimi giorni intendo cimentarmi in qualche test approfondito del Radeon 7500: in particolare, cercherò di misurare l'utilizzo e l'efficacia della terza TMU.
Pensavo: in un gioco single texture come "Forsaken", una sola TMU viene adoperata; corretto? Se abilito il trilinear filtering, entra in gioco la seconda TMU o anche la terza?
In poche parole, vorrei una situazione in cui il gioco non adoperi di default la terza TMU, per poi utilizzarla attivando il trilinear: quale potrebbe essere lo scenario ideale? Forse Quake2, un gioco che adopera 2 texture per passata? O magari Quake3?
Potrei poi verificare la differenza prestazionale con una VGA DX7 dotata di sole 2 TMU per pipe, che quindi è costretta a ricorrere al multipass per il filtro trilineare... e poi anche con una scheda DX8 a singola TMU per pipe, che non deve ricorrere al multipass (grazie alle capacità di loopback della pipeline) ma che è comunque costretta a sprecare più di un ciclo di clock.
Infine, voglio provare Serious Sam in bilinear filtering, impostando prima 2 texture per passata e poi 3: la differenza prestazionale dovrebbe essere eclatante (di molto superiore rispetto ad una VGA che esegue si 3 o più texture per passata, ma in più cicli di clock: tipoco scenario di un scheda DX8 o DX9, con solo 1 o 2 TMU per pipe).
Shodan, ragiono bene o male? Hai qualcosa da dire? :O
Ho effettuato i primi test, con Quake 2 e 3, ma i risultati sono inconcludenti.
In breve, a prescindere dalla risoluzione e profondità di colore (ho cercato di escludere il collo di bottiglia della lenta SDR della 7500, e poi di farla diventare invece un fattore), Radeon 7500 e 9250 risentono pochissimo dell'applicazione dei filtri trilineare ed anisotropico 16x, in proporzioni circa uguali (zero frame a 640x480x16, da due a quattro a 1280x1024x32, sia per trilinear che aniso -ricordo che queste GPU non li possono usare in abbinata-). La terza TMU non sembra produrre effetti tangibili.
Come interpretare questi risultati? :fagiano:
Purtroppo, l'unica scheda DX7 che possiedo con 2 TMU (GeForce 2) non entra nel case, quindi l'impatto del resend della geometria (multipass) non riesco -per ora- a testarlo.
Ora passo a Serious Sam, e poi cerco di valutare visivamente le due modalità di AA dei chip Radeon.
P.S. Ho comprato (arriverà a breve) un Radeon 7500 con frequenze 290/460 a 10 eurazzi... :winner:

[Murakami]

Ho benchato Serious Sam:SE con Fraps, ed anche qui una delusione: in 800x600, 16 bit, bilinear filtering, variando la modalità di multitexturing (nessuna, doppia, tripla), la differenza prestazionale è modesta, nell'ordine di mezzo frame su 40, al più 1 su 40. Considerando il sistema approssimativo con cui ho ottenuto questi valori (file di log di fraps per ogni sec, eliminazione dei valori iniziali e finali -che corrispondono ai menù del gioco-, copia e incolla in excel, funzione media per ogni colonna), direi che lo scarto percentuale è nell'ordine dell'errore di misurazione insito nel metodo adoperato.
Questa terza TMU sembra servire davvero a poco, persino in un titolo che prevede nativamente 3 texture per passata.

[Murakami]

Infine, qualche breve osservazione sulle modalità di AA dei chip Radeon 7500 e 9250, valutate riprendendo la stessa scena statica da più angolazioni (lo specchio nel quale si riflette il giocatore, proprio all'inizio del primo livello): ho scelto di adoperare una risoluzione bassa (800x600) ed un campionamento solo 2X, per potermi accorgere agevolmente di differenze macroscopiche.
Diciamo subito che la modalità "prestazioni" del 7500 è davvero scadente, quasi come non averla: seghettature più che evidenti ad ogni angolazione. Passando alla modalità "qualità" si ha un netto miglioramento: l'impressione è quasi quella di un campionamento superiore, con transizioni molto più morbide tra le "scalette".
Venendo al 9250, la modalità "prestazioni" si configura come una via di mezzo tra le due del 7500, mentre la "qualità" si allinea sostanzialmente con la corrispondente del 7500.
Che dire? Probabilmente, nella modalità "prestazioni" del chip 9250 avranno aggiunto qualche post filter tipo blur ma, nella sostanza, si conferma la teoria di Shodan: tra le due GPU non si palesa una grossa differenza qualitativa nella gestione dell'antialiasing, alla faccia del supposto "jittered sparse sampling" e balle varie.
Mi piacerebbe, comunque, che qualcuno potesse confermare o smentire queste mie impressioni con prove analoghe (es. Shodan con il suo 8500).
Tra l'altro, ho notato qualche anomalia nella gestione dello slider dell'AA: la risoluzione massima supportata -la cui differenza tra le due modalità rimane, in ogni caso, un mistero, così come la differenza tecnica che passa tra le due- non sembra tenere conto della quantità di ram a bordo della scheda; inoltre, per quanto riguarda il 9250, il limite massimo del campionamento 3X è 800x600 (ridicolmente basso, tenendo conto dei 256 mb di ram di cui è dotato il mio esemplare), che passa a 1024x768 per il 4X... :mbe:
Infine, ho osservato che, quando l'AA è impostato su "secondo l'applicazione", con il 7500 la possibilità di switchare tra "prestazioni" e "qualità" è inibita, mentre si conserva per il 9250.

[Max_R]

Io ho constatato che la mia Savage4 Pro ha problemi e come lei anche una delle mie Banshee. Probabilmente però questo è dovuto ad un'incompatibilità con la P5A-B che ho sottomano. Ho provato invece la Savage4 di ELSA con Unreal Tournament S3TC @1024x768x32 ma i f/s sono indecenti :asd:

[lele.miky]

seguendo i bench su Serious Sam SE ,ho voluto testare il Kyro2 con questo gioco variando il numero di textur da 2 a 4,nonostante Kyro2 ne possa renderizzare 1 per pipeline,sorprendentemente non risente nelle prestazioni,ottenendo sempre valori pressochè identici.(illuminatemi su tale comportamento).
Ho voluto anche testare l'antialiasing 4x del kyro che vanta una uqalità estremamente elevata,anche se le prestazioni vengono uccise,
cmq vi lascio i grafici e gli screen con antialiasing

http://img339.imageshack.us/img339/5074/kyro2sssehs1.th.jpg (http://img339.imageshack.us/my.php?image=kyro2sssehs1.jpg)

http://img261.imageshack.us/img261/8033/kyro24xaaoa5.th.jpg (http://img261.imageshack.us/my.php?image=kyro24xaaoa5.jpg)

ho evitato di inserire l'Aniso perchè è risaputo che il kyro2 non riesce a gestire troppo bene questo filtro dal punto di vista delle performance

cmq spero mi possiate illuminare meglio sul comportamento della scheda e magari sulla qualità dell'immagine

domani dovrei riuscire a fare qualche test uguale su una ATI radeon 64DDr VIVO(la prima Radeon256 DDR)una 7500DDR standard e qualche altra scheda,se volete qualcosa in particolare chiedete


PS: il sistema di test è un Cube con AthlonXP 2000+ e 1GB di ram e XP
PPS: ho anche un Riva128 e un 128ZX standard non castrati,appena riesco a mettere win98 testo un po


ciao

[Murakami]

seguendo i bench su Serious Sam SE ,ho voluto testare il Kyro2 con questo gioco variando il numero di textur da 2 a 4,nonostante Kyro2 ne possa renderizzare 1 per pipeline,sorprendentemente non risente nelle prestazioni,ottenendo sempre valori pressochè identici.(illuminatemi su tale comportamento)
Il Kyro può renderizzare 8 texture per passata (in più cicli di clock, ovviamente), quindi -in teoria- le prestazioni dovrebbero crescere alzando il multitexturing da 2 a 4: se ciò non avviene, significa che il collo di bottiglia è da qualche altra parte. D'altra parte, proprio ieri io ho verificato un comportamento del tutto analogo per il Radeon 7500: a questo punto, mi chiedo che uso faccia il gioco della capacità di multitexturing delle VGA.

ho anche un Riva128 e un 128ZX standard non castrati,appena riesco a mettere win98 testo un po

Cos'è che hai tu? :eek:
Me lo vendi, verooooooooooooooo? :mad:

[lele.miky]

bene,probabilmente è il gioco a non trarne effettivo vantaggio
cmq il riva 128ZX rimane a casuccia :-) ,è un pezzo che difficilmente lascera' la collezione,cmq mi dite che test volete e provvedo,tra l'altro ne avrei un'altro ma non da segnali a video,devo testare meglio

per la qualità dell'antialiasing come vi sembra l'immagine?

[Murakami]

bene,probabilmente è il gioco a non trarne effettivo vantaggio
per la qualità dell'antialiasing come vi sembra l'immagine?
Si, ma il problema è che quel gioco è forse l'unico che dovrebbe trarne vantaggio... :D
Parlando di AA, in quello shot non si vede una scaletta nemmeno con il binocolo di Sam il serioso... :D

[Murakami]

Ti prego, lele, metti a confronto Riva128 liscio e ZX con Forsaken e Quake2 (con Win98, ovviamente): sono curiosissimo.

[lele.miky]

ok,fammi prendere l'hard disk con Win installato,pero tu dimmi come fare a far partire il bench

ciao

[Murakami]

ok,fammi prendere l'hard disk con Win installato,pero tu dimmi come fare a far partire il bench

ciao
Quando sei pronto fammi uno squillo.
Mi raccomando, driver 3.37.
Le 2 schede hanno la stessa interfaccia (PCI o AGP), vero?

[lele.miky]

pronto,driver 3.37,tutte e due AGP

ora ho sotto la 128ZX,installo i giochi,intanto tu dimmi come si bencha e che opzioni vuoi che attvo

ciao

[Murakami]

Forsaken, risoluzioni 640x480x16 e 800x600x16, formato texture 5650, tutto al massimo, autodettaglio off, contenuti adulti on, suono off. Fai partire il demo 1, lascia scorrere, quando finisce rientra nella schermata di caricamento del demo e leggi sotto il valore fps medio.
Quake 2, risoluzioni come sopra con l'aggiunta di 960x720, tutto al massimo, texture a 8 bit off, suono a qualità minima, tiri giù la console con il tasto "\", digita "timedemo 1" e invio, poi "map demo1.dm2" e invio, ripeti 2 volte e leggi il valore dell'ultimo ciclo su console.
In generale: tieni la risoluzione del desktop bassa e a 16 bit, disattiva l'antialiasing da driver per la modalità D3D, switcha invece alla massima qualità l'opzione nel pannello di controllo OpenGL.

[lele.miky]

ciao,non riesco a far partire quake2 in opengl,mi va solo in software mode
hai idea di come possa fare?

[lele.miky]

ho portato a termine i test con forsaken(intanto cerco di procurarmi una copia diversa di quake2)
le perplessita di murakami sembrano essere fondate,il mio esemplare di riva128ZX è a 128Bit con 8MB di ram,eppure restituisce performance piu basse del fratello liscio,nello specifico abbiamo

640*480 800*600
71.46 61.75 riva128
58.2 54.49 riva128ZX

da questi dati si puo osservare che il 128ZX perde meno frame all'aumentare della risoluzione,segno che forse il lavoro svolto da nvidia fosse mirato ad aumentare le prestazioni all'aumentare della stesa risoluzione(anche per via del maggior quantitativo di ram).
quello ce però non mi torna è come fosse possibile uno scarto cosi ampio a 640*480,almeno avrebbero dovuto restituire un risultato pressochè simile

cmq lascio a voi piu esperti giudicare questi risultati

intanto testo un buon savage3D nelle medesime condizioni

a dopo

ciao

[Murakami]

ho portato a termine i test con forsaken(intanto cerco di procurarmi una copia diversa di quake2)
le perplessita di murakami sembrano essere fondate,il mio esemplare di riva128ZX è a 128Bit con 8MB di ram,eppure restituisce performance piu basse del fratello liscio,nello specifico abbiamo

640*480 800*600
71.46 61.75 riva128
58.2 54.49 riva128ZX

da questi dati si puo osservare che il 128ZX perde meno frame all'aumentare della risoluzione,segno che forse il lavoro svolto da nvidia fosse mirato ad aumentare le prestazioni all'aumentare della stesa risoluzione(anche per via del maggior quantitativo di ram).
quello ce però non mi torna è come fosse possibile uno scarto cosi ampio a 640*480,almeno avrebbero dovuto restituire un risultato pressochè simile

Lo ZX perde meno all'aumentare della risoluzione perchè ha il doppio di ram e, quindi, non deve ricorrere alla ram di sistema per le texture: molto semplice.
Rimane il mistero delle prestazioni decisamente basse in assoluto. Come hai stabilito che l'interfaccia verso la ram è a 128 bit? Che tool si potrebbe usare?

[Murakami]

ciao,non riesco a far partire quake2 in opengl,mi va solo in software mode
hai idea di come possa fare?
Sinceramente, no: a me funziona perfettamente, forse hai il sistema un pò incasinato di driver video. Prova, comunque, a patchare Quake2 alla versione 3.20.

[lele.miky]

Lo ZX perde meno all'aumentare della risoluzione perchè ha il doppio di ram e, quindi, non deve ricorrere alla ram di sistema per le texture: molto semplice.
Rimane il mistero delle prestazioni decisamente basse in assoluto. Come hai stabilito che l'interfaccia verso la ram è a 128 bit? Che tool si potrebbe usare?

infatti lo immaginavo,anche se un passaggio da 640 a 800 non pensavo pesasse molto sul quantitativo di ram

per il bus ho usato un metodo empirico,le schede hanno un layout simile,con la stessa disposizione delle ram,se il riva128 ha 128bit anche lo ZX le ha a 128
tutto qui

ho provato rivatuner ma non visualizza nulla,powerstrip invece non lo ho provato,ora vedo cosa mi risulta

quake è già patchato,ora me ne sto "procurando" un altro

a dopo

[shodan]

Si, un bel nome per una non-feature di puro marketing (elaborazione interna a 32 bit: tutto qui)... :D

Be', se si esclude le Voodoo, tutte le altre schede dell'epoca, quando usate con framebuffer a 16 bit, funzionavano con precisione interna anche a 16 bit. Al contrario, G200/G400 usavano internamente i 32 bit anche con framebuffer a 16 bit.
Inoltre non dimentichiamo che l'Ultrasharp DAC era, effettivamente, migliore di quello delle altre schede (ci si avvicinavano solo Rage128 e Voodoo3, ma non lo pareggiavano di certo).

Ciao. :)

[shodan]

Nei prossimi giorni intendo cimentarmi in qualche test approfondito del Radeon 7500: in particolare, cercherò di misurare l'utilizzo e l'efficacia della terza TMU.
Pensavo: in un gioco single texture come "Forsaken", una sola TMU viene adoperata; corretto? Se abilito il trilinear filtering, entra in gioco la seconda TMU o anche la terza?
In poche parole, vorrei una situazione in cui il gioco non adoperi di default la terza TMU, per poi utilizzarla attivando il trilinear: quale potrebbe essere lo scenario ideale? Forse Quake2, un gioco che adopera 2 texture per passata? O magari Quake3?
Potrei poi verificare la differenza prestazionale con una VGA DX7 dotata di sole 2 TMU per pipe, che quindi è costretta a ricorrere al multipass per il filtro trilineare... e poi anche con una scheda DX8 a singola TMU per pipe, che non deve ricorrere al multipass (grazie alle capacità di loopback della pipeline) ma che è comunque costretta a sprecare più di un ciclo di clock.
Infine, voglio provare Serious Sam in bilinear filtering, impostando prima 2 texture per passata e poi 3: la differenza prestazionale dovrebbe essere eclatante (di molto superiore rispetto ad una VGA che esegue si 3 o più texture per passata, ma in più cicli di clock: tipoco scenario di un scheda DX8 o DX9, con solo 1 o 2 TMU per pipe).
Shodan, ragiono bene o male? Hai qualcosa da dire? :O

Il filtro trilineare è definto come una media pesata di due campionamenti bilineari. Ciò vuol dire che aggiungere il trilineare impiega una TMU in più. In altre parole: un gioco single-textured renderizzato in trilineare potrà impegnare 2 TMU; un gioco dual-textured renderizzato sempre in trilineare potrà utilizzare 3 TMU.
In teoria, quindi, benchando con Q3 Arena alla massima qualità, una volta usando solo il bilinear e una volta usando il trilinear, dovresti essere in grado di evidenziare le differenze che cerchi. Il punto è che non so quanti poligoni Q3 Arena renderizza con 2 texture piuttosto che con una; per massimizzare il numero di pixel con più texture, _devi_ usare l'illuminazione lightmap.

In ogni caso, l'ideale sarebbe usare un benchmark che renderizzi una superficie rispettivamente con 1, 2 e 3 texture: se non esiste potrei anche attivarmi per crearlo... il punto è che io programmo sotto Linux! :fuck:

In mancanza d'altro, per testare la 3° TMU di R100 potresti usare il fill-rate tester del 3DMark2001 (quel bench infatti usa tutte le TMU che ha a disposizione... dai un'occhiata al readme se vuoi capire perchè ;))

EDIT: dimenticavo... il fill rate tester di Marco Dolenco è quello che fa per noi, in quanto esegue test con 1, 2, 3 e 4 texture! Scaricalo (l'ho linkato in precedenza) e prova a eseguirlo. L'unica pecca è che non supporto il multipass, quindi chip con il GF2 passeranno solo i test con 1 e 2 texture.

Ciao.