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)


shodan 26-04-2008 08:59

Quote:

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.

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
Quote:

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

Murakami 26-04-2008 09:34

Quote:

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

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 26-04-2008 10:37

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 26-04-2008 11:19

Quote:

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:

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

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 26-04-2008 18:30

Quote:

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

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

Murakami 26-04-2008 18:31

Quote:

Originariamente inviato da shodan (Messaggio 22187265)
...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 26-04-2008 18:50

Quote:

Originariamente inviato da Murakami (Messaggio 22196294)
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 26-04-2008 18:52

Quote:

Originariamente inviato da Murakami (Messaggio 22196313)
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 26-04-2008 19:04

Quote:

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

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 26-04-2008 19:04

Quote:

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

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

Murakami 26-04-2008 19:12

Quote:

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:

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 26-04-2008 19:45

Quote:

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

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 26-04-2008 19:46

Quote:

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.

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

Ciao. :)

shodan 26-04-2008 19:47

Quote:

Originariamente inviato da Murakami (Messaggio 22196646)
Esatto, e questo mi sembra difficile da giustificare con la sola variazione del LOD.

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

Malek86 26-04-2008 20:56

Quote:

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

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

Max_R 26-04-2008 21:03

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

Murakami 26-04-2008 22:31

Quote:

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

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 26-04-2008 22:33

Quote:

Originariamente inviato da shodan (Messaggio 22197095)
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 27-04-2008 11:39

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 27-04-2008 12:01

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


Tutti gli orari sono GMT +1. Ora sono le: 15:32.

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