Originariamente inviato da Murakami (Messaggio 22182174)

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.

Originariamente inviato da shodan (Messaggio 22185895)

Qui:
http://www.tomshardware.com/reviews/...500,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. :)

Originariamente inviato da Murakami (Messaggio 22186089)

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:

Originariamente inviato da shodan (Messaggio 22187265)

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. :)

Originariamente inviato da shodan (Messaggio 22187265)

...anche a me la modalità quality sembra semplicemente avere un mipmap LOD più alto...

Originariamente inviato da Murakami (Messaggio 22196294)

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

Originariamente inviato da Murakami (Messaggio 22196313)

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

Originariamente inviato da shodan (Messaggio 22196478)

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. :)

Originariamente inviato da shodan (Messaggio 22196492)

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. :)

Originariamente inviato da Murakami (Messaggio 22186726)

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:

Originariamente inviato da Murakami (Messaggio 22196637)

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)?

Originariamente inviato da Murakami (Messaggio 22196715)

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.

Originariamente inviato da Murakami (Messaggio 22196646)

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

Originariamente inviato da Murakami (Messaggio 22196715)

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

Originariamente inviato da shodan (Messaggio 22197075)

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. :)

Originariamente inviato da shodan (Messaggio 22197095)

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

Originariamente inviato da Max_R (Messaggio 22201952)

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

Originariamente inviato da Max_R (Messaggio 22201952)

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

Originariamente inviato da Murakami (Messaggio 22198553)

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

Originariamente inviato da Murakami (Messaggio 22198569)

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).

Originariamente inviato da Murakami (Messaggio 22201675)

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.

Originariamente inviato da shodan (Messaggio 22207102)

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. :)

Originariamente inviato da shodan (Messaggio 22207149)

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. :)

Originariamente inviato da Murakami (Messaggio 22207182)

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?

Originariamente inviato da Murakami (Messaggio 22207229)

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.

Originariamente inviato da shodan (Messaggio 22207128)

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:

Originariamente inviato da Murakami (Messaggio 22207255)

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:

Originariamente inviato da shodan (Messaggio 13402211)

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)


Note: nulla in particolare.

-) Matrox G200 LE 8MB AGP - frequenze 84/112 (core/mem)


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)


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)


Note: nulla in particolare.

-) Nvidia TNT2 Pro 32MB AGP - frequenze 142/166


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...


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).


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.




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)






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. :)

Originariamente inviato da Max_R (Messaggio 22207445)

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?

Originariamente inviato da shodan (Messaggio 22207102)

- NV30 -> max 16X aniso+trilinear -> 128 tap

Originariamente inviato da shodan (Messaggio 22207978)

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

Ciao.

Originariamente inviato da Max_R (Messaggio 22217012)

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