Hardware Upgrade Forum

Hardware Upgrade Forum (https://www.hwupgrade.it/forum/index.php)
-   Schede Video - Discussioni generali (https://www.hwupgrade.it/forum/forumdisplay.php?f=28)
-   -   [HWVintage] Retrogaming avanti tutta (https://www.hwupgrade.it/forum/showthread.php?t=991407)


walter sampei 15-10-2007 15:41

Quote:

Originariamente inviato da note degli omegadrivers per win9x
================================================================================
NVIDIA Display Driver for Windows 9x version 4.14.10.4523, 07/28/2003
================================================================================

Operating systems supported
---------------------------
Microsoft Windows 95
Microsoft Windows 98
Microsoft Windows Millennium Edition (Windows Me)


Adapters supported
------------------
NVIDIA RIVA TNT
NVIDIA RIVA TNT2
NVIDIA RIVA TNT2 Pro
NVIDIA RIVA TNT2 Ultra
NVIDIA Vanta
NVIDIA Vanta LT
NVIDIA RIVA TNT2 Model 64
NVIDIA RIVA TNT2 Model 64 Pro
NVIDIA Aladdin TNT2
NVIDIA GeForce 256
NVIDIA GeForce DDR
NVIDIA Quadro
NVIDIA GeForce2 MX
NVIDIA GeForce2 MX 200
NVIDIA GeForce2 MX 400
NVIDIA Quadro2 MXR
NVIDIA Quadro2 EX
NVIDIA GeForce2 GTS
NVIDIA GeForce2 Pro
NVIDIA GeForce2 Ti
NVIDIA GeForce2 Ultra
NVIDIA GeForce2 Integrated GPU
NVIDIA Quadro2 Pro
NVIDIA GeForce4 MX 420
NVIDIA GeForce4 MX 440
NVIDIA GeForce4 MX 440-SE
NVIDIA GeForce4 MX 460
NVIDIA Quadro NVS
NVIDIA Quadro4 500 XGL
NVIDIA Quadro4 550 XGL
NVIDIA GeForce4 MX Integrated GPU
NVIDIA GeForce4 MX 420 with AGP8X
NVIDIA GeForce4 MX 440 with AGP8X
NVIDIA GeForce4 MX 440SE with AGP8X
NVIDIA Quadro4 NVS with AGP8X
NVIDIA Quadro4 380 XGL
NVIDIA Quadro4 580 XGL
NVIDIA GeForce3
NVIDIA GeForce3 Ti 200
NVIDIA GeForce3 Ti 500
NVIDIA Quadro DCC
NVIDIA GeForce4 Ti 4200
NVIDIA GeForce4 Ti 4400
NVIDIA GeForce4 Ti 4600
NVIDIA GeForce4 Ti 4200 with AGP8X
NVIDIA GeForce4 Ti 4800
NVIDIA GeForce4 Ti 4800 SE
NVIDIA Quadro4 700 XGL
NVIDIA Quadro4 750 XGL
NVIDIA Quadro4 900 XGL
NVIDIA Quadro4 780 XGL
NVIDIA Quadro4 980 XGL
NVIDIA GeForce FX 5800
NVIDIA GeForce FX 5800 Ultra
NVIDIA Quadro FX 1000
NVIDIA Quadro FX 2000

purtroppo la riva128 non e' supportata da questi... a meno che non sia supportata da qualche release vecchissima, la vedo dura :(

P3pPoS83 15-10-2007 16:06

Quote:

Originariamente inviato da walter sampei (Messaggio 19160670)
purtroppo la riva128 non e' supportata da questi... a meno che non sia supportata da qualche release vecchissima, la vedo dura :(

Che peccato:(

Bye:cool:

Bescio 15-10-2007 16:30

Se dovreste fare un rapporto Prestazioni/Compatibilità tra Rage128 e Savage3D quale delle due la spunterebbe?

:nonio:

P3pPoS83 15-10-2007 17:19

Quote:

Originariamente inviato da Bescio (Messaggio 19161513)
Se dovreste fare un rapporto Prestazioni/Compatibilità tra Rage128 e Savage3D quale delle due la spunterebbe?

:nonio:

Ovviamente la rage128:)

Bye:cool:

shodan 15-10-2007 22:11

Quote:

Originariamente inviato da Bescio (Messaggio 19161513)
Se dovreste fare un rapporto Prestazioni/Compatibilità tra Rage128 e Savage3D quale delle due la spunterebbe?

:nonio:

La Savage3D e, ancora meglio, la Savage4 erano fantastiche se usate con un gioco che supportava l'S3TC (in pratica Unreal e Unreal Tournament, che potevano appoggiarsi anche all'API Metal proprietaria).

In D3D e OGL la Rage128 era migliore, forte del suo bus verso le memorie a 128 bit (le Savage3D/4 erano a 64 bit).
La Rage128 Pro aggiunse anche il supporto agli schemi di compressione DX6, che in pratica ricalcavano l'S3TC: in pratica, nel 2000 la feature migliore delle schede S3 divenne di "dominio pubblico", diminuendo l'interesse verso queste schede e, in parte, anche dalla Savage2000 (che si spostò sul motore di T&L).

Ciao. :)

walter sampei 16-10-2007 01:45

ma alla fine c'era qualche gioco che usava le metal? a parte ut, non penso di averne visti altri... :confused:

P3pPoS83 16-10-2007 08:44

Quote:

Originariamente inviato da walter sampei (Messaggio 19169520)
ma alla fine c'era qualche gioco che usava le metal? a parte ut, non penso di averne visti altri... :confused:

Infatti... Forse è l'unico:confused: ???

Bye:cool:

shodan 16-10-2007 10:43

Quote:

Originariamente inviato da walter sampei (Messaggio 19169520)
ma alla fine c'era qualche gioco che usava le metal? a parte ut, non penso di averne visti altri... :confused:

Si, putroppo è l'unico... dico putroppo perchè era una libreria discretamente ottimizzata; non al livello delle Glide, ma sicuramente meglio del driver D3D / OGL.

Ciao. :)

P3pPoS83 16-10-2007 15:54

Vecchio sito ormai defunto dedicato al verite 1000/2x00:D

http://web.archive.org/web/199804210...w.bjorn3d.com/

Bye:cool:

shodan 16-10-2007 18:56

Ciao a tutti,
approfittando del fatto che sto studiano più o meno seriamente l'OpenGL, ho scritto, a scopo di esercizio, un piccolo benchmark che si occupa di misurare il fill-rate di un chip grafico.
Perchè un benchmark del genere? Non ce ne sono già a sufficienza? Si, ma il mio ha due caratterstiche particolari:
-) gira sotto Linux;
-) verifica il fill-rate al variare delle dimensioni della texture usata.
Penso quindi sia interessante vedere insieme i risultati ottenuti.

Prima di tutto le specifiche del sistema utilizzato:
-) Processore P3 866EB (Coppermine, FSB 133);
-) Scheda madre Gigabyte basata su Via Apollo Pro 133A (AGP 4X);
-) Ram 384 MB;
-) Debian Etch con kernel 2.6.22.8.

Le schede video testate sono:
-) Creative Voodoo Banshee AGP 16 MB SGRAM (clock 100/110);
-) OEM Savage4 Pro 32 MB (clock 110/125);
-) PowerColor TNT2 Pro 32 MB (clock 142/166);
-) Radeon VE 64 MB (clock 155/155);
-) Radeon 8500LE 64 MB (clock 250/250).

Prima di presentare i numeri, vediamo cosa fa il benchmark (i cui sorgenti trovate allegati). In pratica viene aperta una finestra di 700x700 pixel al cui interno viene disegnato un quadrato (composto da 2 triangoli rettangoli) di 650x650 pixel. La geometria è stata volutamente tenuta il più semplice possibile, per evitare una qualsiasi dipendenza dei risultati dalla prestazioni del processore. Allo stesso scopo, per disegnarla sono stati utilizzati i compiled vertex array (estensione LOCK) o, ancora meglio, i vertex buffer object (estensione VBO). Questo rettangolo viene disegnato 1000 volte e, alla fine, viene calcolato il valore in Mpixel / sec. fornito dalla scheda grafica. La prima volta il rettangolo è disegnato senza nessuna texture, permettendo di misurare il fill-rate nudo e crudo (solid fill). Finito il ciclo di disegno, il rettangolo viene disegnato applicandovi di volta in volta texture più definite: si parte da una texture base di 1x1 fino ad arrivare a 2048x2048 (per l'hardware che le supporta). Ogni texture viene disegnata 1000 volte e quindi viene calcolato il fill-rate. La procedura di disegno delle texture viene ripetuta 4 volte, usando ogni volta un filtro diverso, secondo quanto riportato sotto:
-) GL_NEAREST (in pratica nessun filtraggio, ergo si vedono i quadrettoni);
-) GL_LINEAR (il filtro bilineare);
-) GL_LINEAR_MIPMAP_NEAREST (il filtro bilineare + mipmaps);
-) GL_LINEAR_MIPMAP_LINEAR (il filtro trilineare, cioè l'interpolazione lineare tra due campioni bilinear di due mipmap diverse).
Alla fine del ciclo viene calcolato il tempo necessario a completare le precedenti funzioni di drawing e quindi viene ricavato il valore di Mp / sec.
Una nota in merito a come vengono presi i valori del tempo di start e stop: sulla Debian da me provata, ho l'impressione che a volte il tempo riportato dalla funzione clock_gettime non sia del tutto affidabile. Sul portatile, che monta Gentoo64, il discorso è diverso: è possibile istruire la funzione clock_gettime in modo da riportare il tempo usato da un singolo processo. La differenza sta nel modo in cui è stata compilata la libc: nella macchina Debian la libc è compilata con altri flag e usa un altro sistema per calcolare il tempo, la cui precisione/affidabilità differisce. Se cercate su google ci sono lunghi thread che avvalorano uno o l'altro sistema... io personalmente preferisco di gran lunga quello usato dalla Gentoo.

Per interpretare correttamente i risultati, è necessario sapere che esistono 2 casi che possono verificarsi quando si applica una texture a una superficie:
-) la texture è più piccola della superficie, quindi va estesa (magnification);
-) la texture è più grande della superficie, quindi va rimpicciolita (minification).
Per l'operazione di magnification ha senso usare solo GL_NEAREST o GL_LINEAR (essendo la texture già piccola di per sé, infatti, non ha senso tirare in ballo le sue mipmaps, che sono ancora più piccole); per l'operazione di minification si può usare una qualsiasi dei 4 filtri sopra esposti. La prima considerazione che traiamo da questo è che il filtro trilineare viene utilizzato solo in caso di una texture più grande rispetto alla superficie su cui verrà applicata. In altre parole, nel mio benchmark il filtro trilineare verrà applicato solo per le texture di dimensione 1024x1024 e 2048x2048.
Una cosa che ho scoperto facendo le varie prove è che l'operazione di minification è molto più onerosa che quella di magnification. In pratica, se si utilizza texture più grandi della superficie di destinazione c'è un forte impatto sulle prestazioni, impatto che non è imputabile semplicemente alle grandi dimensioni della texture: aumentando anche le dimensioni del poligono sul quale disegnare la texture, infatti, le prestazioni salgono significativamente. Allo stesso modo, applicando una texture non molto grande (256x256, ad esempio) su una superficie ancora più piccola (128x128), si assiste allo stesso forte impatto velocistico. E' quindi proprio l'operazione di riduzione che incide parecchio sulle prestazioni.

Fatte queste premesse, iniziamo a vedere i risultati...

Voodoo Banshee:


Qualità del filtro trilineare:


Nota: le immagini del filtro trilineare sono tutte jpeg salvate con una qualità dell'85% utilizzando TheGimp.

Le prestazioni della banshee sono praticamente costanti al variare della dimensione delle texture, avendo una leggerissima flassione solo con texture di dimensioni maggiori di 64x64 pixel.
Come potete vedere, i filtri nearest e bilinear incidono molto poco sulle prestazioni del solid fill; una minima differenza prestazionale la si vede solo con texture più grandi di 64x64 pixel. Il filtro trilineare non è supportato (neanche usando il dithering fra le mipmaps). Questo vuol dire che la schede esegue il normale filtro bilineare + mipmap.
Efficienza del solid fill rispetto ai valori teorici: 99,77%.
Efficienza del bilineare con texture di 256x256 pixel: 95,6%.


Savage4:






Qualità del filtro trilineare (nb: il filtro trilineare di S3 utilizza un'implementazione particolare, che non ne permette il rilevamento con le mipmaps colorate. Per ulteriori informazioni, vedi gli aggiornamenti riportati sotto):


Note: per garantire il funzionamento dell'AGP a 4X, ho dovuto impostare l'opzione “AGPMode” “4” nel file “/etc/X11/xorg.conf”.

La Savage4, come altre schede testate, dava dei risultati un po' altalenanti: ho riportato quindi i valori dati da 2 esecuzioni del benchmark. Per rendersene conto, basta vedere i valori del filtro bilinear + mipmap nella prima esecuzione e quello del trilinear nella seconda. Tenete presente però il discorso che ho fatto sopra sul calcolo del tempo (che influenza in maniera diretta il calcolo dei Mp / sec).
Questa scheda produce risultati molto dipendenti dalle dimensioni delle texture: da texture di dimensioni pari a 128x128 pixel in su, la velocità scende parecchio. A parziale discolpa, c'è da dire che la compressione S3TC migliora parzialmente le prestazioni, ma non in tutti i casi.
I filtri nearest e bilinear invece non impattano per nulla sulle prestazioni (d'altro canto, gli ultimi chip che avevano problemi prestazionali ad applicare il bilinear sono stati il RageII e il Renditition Verité V1000).
L'utilizzo delle mipmap migliora notevolmente le prestazioni con texture di grandi dimensioni: questo risultato si ottiene perchè, in questo casi, il chip può scegliere che invece di minificare la texture (1024x1024 pixel da ridimensionare a 650x650) può magnificare la mipmap immediatamente successiva (512x512 pixel). Questo produce un notevole aumento delle performance. Ricordo infatti che una volta provai a disabilitare la gestione delle mipmaps su una 9800Pro e il gioco che provai, cioè UT2003, era molto più lento che non con le mipmaps abilitate.
Riguardo al filtro trilineare, in prima istanza pensavo che avesse ottime prestazioni a causa del particolare tipo di implementazione utilizzata sui chip Savage (chiamata da S3 “free trilinear”, su cui ora non mi dilungherò, ma possiamo parlarne in un post apposito...); in realtà, o almeno da quanto mi è possibile verificare tramite l'immagine sopra riportata, il filtro trilineare non funziona correttamente, applicando un bilineare + mipmap. Sono comunque aperto ad altri pareri... :)
Aggiornamento n.1:
dopo essermi ripassato la modalità di funzionamento del filtro trilineare implementato nei chip S3, devo correggere la precendete frase: è senza dubbio possibile (nonchè probabile) che in effetti il Savage4 stia applicando il filtro trilineare tramite l'algoritmo proprietario sviluppato da S3. Per maggiorni informazioni: http://www.xbitlabs.com/articles/vid..._13.html#sect0 e pagina seguente. Nel caso il chip S3 stia davvero utilizzando il filtro trilineare, non si può fare a meno di notare gli enormi vantaggi prestazionali offerti dal Savage4.
Aggiornamento n.2:
per verificare che la Savage4 stesse davvero applicando il filtro trilineare ho apportato una modifica al programma, così che il trilinear venga testato non usando delle mipmaps colorate ma una texture ad alta frequenza. I risultati confermano che la Savage4 sta applicando il filtro trilineare, utilizzando la sua implementazione proprietaria. L'implementazione di S3 è ben spiegata su Xbitlabs al link riportato appena sopra. Per averne conferma, basta confrontare le immagini ottenute usando i diversi filtri:
Bilinear + mipmaps

Come è visibile, il cambiamento di mipmap (in prossimità del rettangolo rosso) è molto evidente

Trilinear

Nonostante il cambiamento della mipmap sia ancora leggermente visibile, l'effetto è molto attenuato: si vede anche chiaramente come le due mipmaps vangano amalgamate (attraverso un'interpolazione lineare) proprio per rendere lo stacco meno evidente.

Non posso fare altro che complimentarmi con S3 con l'ottima implementazione del filtro trilineare che, seppur non corrispondente in maniera perfetta ai classici canoni, garantiva un compromesso di qualità e prestazioni (entrambe ottime) irraggiungibile per le schede dell'epoca (basti vedere i risultati del TNT2 Pro, un chip con oltre il doppio del fill-rate e della banda di memoria).
Peccato per i 64 bit verso la VRAM, altrimenti il Savage4 avrebbe potuto impensierire anche chip di fascia più alta...
Efficienza del solid fill rispetto ai valori teorici: 95,73%.
Efficienza del bilineare con texture di 256x256 pixel: 72,05%.
Efficienza del bilineare con texture di 256x256 pixel + S3TC: 93,97%.


TNT2 Pro:


Qualità del filtro trilineare:


Nota: non mi è stato possibile abilitare l'AGP 4X neanche intervenendo a mano nei file di configurazione. Il sistema è stato quindi provato con l'AGP a 2X, con FW e SB disabilitati. Pare che il problema sia dovuto al chipset Via Apollo Pro 133A.

Notevoli i risultati del TNT2 Pro che, grazie all'architettura TwiNTextel, produce, nelle migliori condizioni, 273 Mp / sec. Questo chip sembra avere una piccola cache per le texture ampia 256 byte (64 pixel, ognuno dei quali ampio 4 byte).
I filtri nearest, bilinear e bilinear + mipmaps sono gestisti alla stessa velocità del solid fill, mentre il filtro trilineare dimezza le prestazioni. Un fatto curioso è che con texture di dimensione fino a 512x512 in realtà il filtro trilineare, anche se abilitato, non dovrebbe essere utilizzato (vedi spiegazione sopra), mentre il TNT2 accusa lo stesso un marcatissimo calo delle performance. Sembra quasi che le sua pipeline si riconfigurino in una modalità 1x2... se a qualcuno interessa possiamo vedere come verificarlo.
Vorrei spendere due parole per la grossa differenza di velocità tra i filtri bilinear + mipmaps e trilinear ottenuta con texture di 1024x1024, che è ben oltre quanto lecito aspettarsi. Ma la soluzione non è lontana: mentre il filtro bilinear + mipmaps può applicare la texture partendo dalla mipmap di 512x512 e quindi estenderla per coprire tutta la superficie, il filtro trilineare deve eseguire un'interpolazione lineare tra la mipmap da 512x512 estesa e quella da 1024x1024 rimpicciolita: è questa minificazione che uccide le prestazioni, oltre al doppio campionamento delle due mipmap che dimezza già di suo il fill-rate.
Efficienza del solid fill rispetto ai valori teorici: 96,13%.
Efficienza del bilineare con texture di 256x256 pixel: 84,65%.


--segue nel post successivo--

shodan 16-10-2007 18:56

1 Allegato(i)
Radeon VE:








Qualità del filtro trilineare:


Note: per garantire il funzionamento dell'AGP a 4X, ho dovuto impostare l'opzione “AGPMode” “4” nel file “/etc/X11/xorg.conf”.

Anche la Radeon VE ha risultati a tratti altalenanti, quindi l'ho testata due volte. Inoltre, per vedere eventuali differenze dovute alla compressione S3TC o all'HyperZ, ho eseguiti i test anche con queste modalità.
Il risultato alla fine è un pattern comune, dove né l'S3TC né l'HyperZ hanno cambiato le carte in tavola. A dirla tutta, nelle condizioni di utilizzo in cui ho messo la scheda, l'HyperZ non poteva fare affidamento sulla sua componente più importante, cioè lo HyerachicalZ, dato che nella scena non c'è overdraw, né sulle altre componenti FastZ clear e Z compression, dato che non ha usato uno Z buffer. In altre parole, mi aspettavo che la sua abilitazione non cambiasse nulla... così è stato.
Tutti i filtri sembrano subire un certo calo con texture di dimensioni superiori a 64x64 pixel; possiamo quindi ipotizzare una cache ampia 64x64x4 bytes, cioè 16 KB.
Da notare anche come le 3 TMU permettano alla scheda di essere meno penalizzata nell'applicazione del trilineare rispetto al TNT2, per lo meno con texture di 2048x2048 pixel.
Efficienza del solid fill rispetto ai valori teorici: 98,55%.
Efficienza del bilineare con texture di 256x256 pixel: 90,79%.
Efficienza del bilineare con texture di 256x256 pixel + S3TC: 90,75%.


Radeon 8500LE:








Qualità del filtro trilineare:


Nota: la scheda è stata fatta funzionare in modalità PCI in quanto l'abilitazione di qualsiasi modalità AGP impediva ad X di avviarsi. Per avere questo risultato, ho usato l'opzione “BUSType” “PCI” nel file “/etc/X11/xorg.conf”. Pare che il problema sia dovuto al chipset Via Apollo Pro 133A.

Anche la Radeon 8500LE si è dimostrata un po' altalenante: ho ripetuto i test anche in questo caso.
Diciamo che possono applicarsi le stesse considerazioni fatte per la Radeon VE; anche la cache sembra ugualmente ampia. Questo perchè anche in questo caso c'è un calo diffuso con texture più grandi di 64x64 pixel, quindi possiamo ipotizzare la stessa cache di 16 KB.
Efficienza del solid fill rispetto ai valori teorici: 97,6%.
Efficienza del bilineare con texture di 256x256 pixel: 84,14%.
Efficienza del bilineare con texture di 256x256 pixel + S3TC: 87,43%.



Arrivati alla fine, che dire... spero che questa analisi vi sia piaciuta! :p
Aspetto i vostri commenti... ;)

Ciao. :)

PS: in allegato trovate il codice del benchmark!

Crisp 16-10-2007 19:47

perchè non dai a tutti i possessori di windows di provarla?
fai una versione per Win.
Dato che chi fa retro prova svariate vga e non sarebbe male provarne il più possibile con uno stesso programma: il tuo ;)

shodan 16-10-2007 20:15

Quote:

Originariamente inviato da Crisp (Messaggio 19180999)
perchè non dai a tutti i possessori di windows di provarla?
fai una versione per Win.
Dato che chi fa retro prova svariate vga e non sarebbe male provarne il più possibile con uno stesso programma: il tuo ;)

Si, è una cosa a cui avevo già pensato; inoltre il porting dovrebbe essere banale... è che da domani sarò abbastanza impegnato al lavoro, quindi non so dirti quando sarà mai pronta la versione per Win! :p
In ogni caso se qualcuno ci si vuole cimentare, dovrebbe bastare sostituire la funzione clock_gettime con qualcosa che faccia la stessa cosa, sotto Windows.

Altrimenti aspettate me! :D

Ciao. :)

Bescio 16-10-2007 21:57

Quote:

Originariamente inviato da shodan (Messaggio 19171472)
Si, putroppo è l'unico... dico putroppo perchè era una libreria discretamente ottimizzata; non al livello delle Glide, ma sicuramente meglio del driver D3D / OGL.

Ciao. :)

Purtroppo ho avuto esperienze negative usando le Metal con Unreal. Con due release di driver differenti, l'ultima disponibile e la precedente, Unreal presentava problemi di rendering.... -_-"

walter sampei 17-10-2007 00:52

intanto grande shodan :)

Murakami 17-10-2007 08:03

Interessantissimi i test di Shodan: qui ci vorrebbe Yossarian per interpretare correttamente certi risultati, come quello del TNT che sembra riconfigurarsi in 1x2... quando lo dissi io a suo tempo venni smentito senza pietà... :cry:
Anche il mancato trilinear filtering del Savage4 è molto interessante ed in aperto contrasto con quanto riportato qui: chissà come si spiega la cosa...

shodan 17-10-2007 08:25

Quote:

Originariamente inviato da Murakami (Messaggio 19186099)
Interessantissimi i test di Shodan: qui ci vorrebbe Yossarian per interpretare correttamente certi risultati, come quello del TNT che sembra riconfigurarsi in 1x2... quando lo dissi io a suo tempo venni smentito senza pietà... :cry:

Puoi sempre invitarlo no... :read:
Quote:

Anche il mancato trilinear filtering del Savage4 è molto interessante ed in aperto contrasto con quanto riportato qui: chissà come si spiega la cosa...
Ho aggiornato la sezione che parla del filtro trilineare del Savage4... dai un'occhiata! ;)

Ciao. :)

Murakami 17-10-2007 09:05

Interessante anche la totale assenza del trilinear filtering sul Banshee: forse che la TMU in meno rispetto al Voodoo2 ne sia responsabile? Il Voodoo2 ce l'ha il trilinear, vero? :confused:

shodan 17-10-2007 09:11

Quote:

Originariamente inviato da Murakami (Messaggio 19186508)
Interessante anche la totale assenza del trilinear filtering sul Banshee: forse che la TMU in meno rispetto al Voodoo2 ne sia responsabile? Il Voodoo2 ce l'ha il trilinear, vero? :confused:

Si, la voodoo2 è in grado di fare il "vero" trilinear.
La banshee è in grado di fare solo il mipmap dithering (che di default è disabilitato) o, per meglio dire, per fare anche il classico trilinear ha bisogno del multipass.

Ciao. :)

shodan 17-10-2007 16:40

Ciao,
dopo ulteriori test posso confermare che il Savage4 sta effettivamente utilizzando il trilinear.Il trilinear impiegato è un'implementazione proprietaria di S3, come ho anche aggiunto nel post.
Per una conferma visiva del fatto che il chip stia usando il filtro trilineare, ho aggiunto 2 screenshot. Dategli un'occhiata! ;)

Ciao. :)


Tutti gli orari sono GMT +1. Ora sono le: 06:39.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Hardware Upgrade S.r.l.