L'ora della verità...

[yossarian]

Originariamente inviato da Pat77

Parlavo del dato Ps 1.1, che si discosta zero dal pure fill rate, risultando il doppio di una 5700 ultra, che in game va circa il doppio (aumentando il divario con i filtri) di una 4200, scheda con 1 vertex in più e in generale più performante sia di 8500 che di ti500. (poi pare che r200 avesse in realtà 2 vertex che funzionavano in modo molto differente da nvidia).

Pk77

il dato apparentemente anomalo è quello della 5700 che nelle operazioni di shading e nel multitexturing si comporta come una 2x2, mentre nel pure fillrate e nel single texturing funziona da 4x1.
I bench sintetici servono per capire come è fatta un'architettura e per cercare di scoprirne eventuali lacune o punti di forza e anche eventuali ricorsi ad application detect e sahder replacement; però si limitano a testare un elemento per volta, quindi non sono indicativi delle prestazioni nei giochi.

[ReDeX]

Originariamente inviato da Pat77

Msi Creative 250/513 da 64 Mb
Per la cronaca Doom3 l'ho provato con patch 1.3 e in quasi tutte le occasioni va circa la metà, se non peggio.

Pk77

Hai detto poco, 64Mb di memoria video sono il veramente pochi per Doom3, come per gli altri giochi da te citati. Se anche la 5700Ultra ne avesse 64, la differenza imho sarebbe molto inferiore.

[Pat77]

Originariamente inviato da ReDeX

Hai detto poco, 64Mb di memoria video sono il veramente pochi per Doom3, come per gli altri giochi da te citati. Se anche la 5700Ultra ne avesse 64, la differenza imho sarebbe molto inferiore.

Ho avuto in testing anche 10 geforce 4200 128MB, con gli stessi risultati, ma con una maggiore fluidità generale e meno scatti (quei microscatti che si verificano per il passaggio delle texture) ma nei bench sono molto simili i comportamenti (anche perchè sono arrivato a 1024 max).
Anzi la 64 Mb spesso era davanti a causa della maggiore frequenza delle ram.

Pk77

[ReDeX]

Originariamente inviato da Pat77

Ho avuto in testing anche 10 geforce 4200 128MB, con gli stessi risultati, ma con una maggiore fluidità generale e meno scatti (quei microscatti che si verificano per il passaggio delle texture) ma nei bench sono molto simili i comportamenti (anche perchè sono arrivato a 1024 max).
Anzi la 64 Mb spesso era davanti a causa della maggiore frequenza delle ram.

Pk77

Hai provato solo bench, o anche Doom3 e gli altri giochi da te citati?

[Murakami]

Ho verificato che su GeForce 4 MX lo Z-occlusion non viene disattivato dai driver serie 50 e successive: attenzione che RivaTuner fà vedere comunque la voce in grigetto a partire dai 43.51, ma se guardate bene è selezionata e non disattivabile...su GeForce 4 TI, invece, è deselezionata e non attivabile.

[conan_75]

Originariamente inviato da Murakami

Ho verificato che su GeForce 4 MX lo Z-occlusion non viene disattivato dai driver serie 50 e successive: attenzione che RivaTuner fà vedere comunque la voce in grigetto a partire dai 43.51, ma se guardate bene è selezionata e non disattivabile...su GeForce 4 TI, invece, è deselezionata e non attivabile.

Come possiamo essere sicuri che sia attivo?
Comunque, come ti dicevo nell'altro tread, dai test che ho fatto personalmente su una 4ti, lo Zocc non fa miracoli, anzi serve a pochissimo.
Ci sono altre questioni sotto...

[Murakami]

Originariamente inviato da conan_75

Come possiamo essere sicuri che sia attivo?

Che sicurezze ci rimangono nella vita, se non quella che, prima o poi, tutti dobbiamo morire?
Conan (barbaro e distruttore... ), se RivaTuner a pari driver mi fà vedere la voce deselezionata e non attivabile su GeForce 4 TI e selezionata e non disattivabile su GeForce 4 MX, permettimi di concludere che nel primo caso lo z-occlusion è disattivo, nel secondo è attivo...

[Pat77]

Originariamente inviato da ReDeX

Hai provato solo bench, o anche Doom3 e gli altri giochi da te citati?

Giochi, o test che si riferiscono ad essi.

Per me 3dmark e compagnia sono solo utili per verificare fill rate e qualche dato interessante come il numero di poligoni ecc...

[conan_75]

Originariamente inviato da Murakami

Che sicurezze ci rimangono nella vita, se non quella che, prima o poi, tutti dobbiamo morire?
Conan (barbaro e distruttore... ), se RivaTuner a pari driver mi fà vedere la voce deselezionata e non attivabile su GeForce 4 TI e selezionata e non disattivabile su GeForce 4 MX, permettimi di concludere che nel primo caso lo z-occlusion è disattivo, nel secondo è attivo...

Forse solo i registri potrebbero darci una risposta certa, oppure qualche test della banda di memoria con superfici nascoste.
La questione di rivatuner però ci da una precisa indicazione come hai fatto notare.
Comunque se ti è possibile fai qualche test con driver vecchi abilitando e disabilitando lo Z-Occ; vedrai che cambia poco o niente.
Il divario tra diver vecchi e nuovi invece è sensibile e preoccupante

[ReDeX]

Originariamente inviato da Pat77

Giochi, o test che si riferiscono ad essi.

Per me 3dmark e compagnia sono solo utili per verificare fill rate e qualche dato interessante come il numero di poligoni ecc...

Idem per me, se mi basassi sui benchmark, non avrei ancora la 9100.

[Zak84]

Questi sono dei test che feci tempo fa con la GF3 Liscia. Ci sono anche test in oc.
Avevate chiesto dei test con i giochi e credo che questi dovrebbero accontentarvi...

LINK (se avete problemi a scaricarlo con firefox provate con IE)


BYEZZZZZZZZZZZ!!!!!!!!!!!!

[Pat77]

Originariamente inviato da yossarian

il dato apparentemente anomalo è quello della 5700 che nelle operazioni di shading e nel multitexturing si comporta come una 2x2, mentre nel pure fillrate e nel single texturing funziona da 4x1.
I bench sintetici servono per capire come è fatta un'architettura e per cercare di scoprirne eventuali lacune o punti di forza e anche eventuali ricorsi ad application detect e sahder replacement; però si limitano a testare un elemento per volta, quindi non sono indicativi delle prestazioni nei giochi.

Appunto, nv36 cambia dinamicamente a seconda dei casi in 4x1 e 2x2, ma anche in nv40 c'è una pur minima variazione di fill rate da ps pure a ps 1.1.

Pk77

[Pat77]

Originariamente inviato da ReDeX

Idem per me, se mi basassi sui benchmark, non avrei ancora la 9100.

Non considerando doom3, nvidia oriented, potresti benchare hl2 cs source in dx 8 (-dxlevel 80 dall'icona del gioco) per valutare quanto la differenza di fill rate sia effettiva, magari a 800x600.

Pk77

[yossarian]

Originariamente inviato da Pat77

Appunto, nv36 cambia dinamicamente a seconda dei casi in 4x1 e 2x2, ma anche in nv40 c'è una pur minima variazione di fill rate da ps pure a ps 1.1.

Pk77

del tutto giustificata dalla molto maggiore complessità delle pipeline dei chip della generazione successiva a NV2x e R200. L'aumento del numero di stadi, di registri interni per ogni unità di calcolo, l'introduzione di nuovi stadi dedicati a particolari funzionalità, hanno accresciuto enormemente la complessità delle pipeline, rendendole idonee a soddisfre le richieste delle nuove API ma, nello stesso tempo, meno efficienti con elaborazioni semplici come quelle proposte dallo sm1.1

[Pat77]

Display adapter: NVIDIA GeForce3 Ti 500
Driver version: 6.14.10.7801
Display mode: 1024x768 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------

FFP - Pure fillrate - 906.134766M pixels/sec
FFP - Z pixel rate - 934.874878M pixels/sec
FFP - Single texture - 652.766785M pixels/sec
FFP - Dual texture - 586.997009M pixels/sec
FFP - Triple texture - 309.649353M pixels/sec
FFP - Quad texture - 298.010712M pixels/sec
PS 1.1 - Simple - 473.249237M pixels/sec
PS 1.4 - Simple - Failed!
PS 2.0 - Simple - Failed!
PS 2.0 PP - Simple - Failed!
PS 2.0 - Longer - Failed!
PS 2.0 PP - Longer - Failed!
PS 2.0 - Longer 4 Registers - Failed!
PS 2.0 PP - Longer 4 Registers - Failed!
PS 2.0 - Per Pixel Lighting - Failed!
PS 2.0 PP - Per Pixel Lighting - Failed!

Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce4 Ti 4200
Driver version: 6.14.10.7772
Display mode: 1024x768 A8R8G8B8 70Hz
Z-Buffer format: D24S8
--------------------------

FFP - Pure fillrate - 930.431091M pixels/sec
FFP - Z pixel rate - 973.094421M pixels/sec
FFP - Single texture - 861.695740M pixels/sec
FFP - Dual texture - 750.655090M pixels/sec
FFP - Triple texture - 397.413330M pixels/sec
FFP - Quad texture - 371.548615M pixels/sec
PS 1.1 - Simple - 492.626953M pixels/sec
PS 1.4 - Simple - Failed!
PS 2.0 - Simple - Failed!
PS 2.0 PP - Simple - Failed!
PS 2.0 - Longer - Failed!
PS 2.0 PP - Longer - Failed!
PS 2.0 - Longer 4 Registers - Failed!
PS 2.0 PP - Longer 4 Registers - Failed!
PS 2.0 - Per Pixel Lighting - Failed!
PS 2.0 PP - Per Pixel Lighting - Failed!


Altri esempi

2778 fill rate pure di 9800xt
1599 ps 1.1

3206 fill rate pure x700pro
1813 ps 1.1

[ReDeX]

Originariamente inviato da Pat77

Non considerando doom3, nvidia oriented, potresti benchare hl2 cs source in dx 8 (-dxlevel 80 dall'icona del gioco) per valutare quanto la differenza di fill rate sia effettiva, magari a 800x600.

Pk77

Come si fa il bench di HL2? Si può fare anche col demo?

[yossarian]

Originariamente inviato da Pat77

Display adapter: NVIDIA GeForce3 Ti 500
Driver version: 6.14.10.7801
Display mode: 1024x768 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------

FFP - Pure fillrate - 906.134766M pixels/sec
FFP - Z pixel rate - 934.874878M pixels/sec
FFP - Single texture - 652.766785M pixels/sec
FFP - Dual texture - 586.997009M pixels/sec
FFP - Triple texture - 309.649353M pixels/sec
FFP - Quad texture - 298.010712M pixels/sec
PS 1.1 - Simple - 473.249237M pixels/sec
PS 1.4 - Simple - Failed!
PS 2.0 - Simple - Failed!
PS 2.0 PP - Simple - Failed!
PS 2.0 - Longer - Failed!
PS 2.0 PP - Longer - Failed!
PS 2.0 - Longer 4 Registers - Failed!
PS 2.0 PP - Longer 4 Registers - Failed!
PS 2.0 - Per Pixel Lighting - Failed!
PS 2.0 PP - Per Pixel Lighting - Failed!

Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce4 Ti 4200
Driver version: 6.14.10.7772
Display mode: 1024x768 A8R8G8B8 70Hz
Z-Buffer format: D24S8
--------------------------

FFP - Pure fillrate - 930.431091M pixels/sec
FFP - Z pixel rate - 973.094421M pixels/sec
FFP - Single texture - 861.695740M pixels/sec
FFP - Dual texture - 750.655090M pixels/sec
FFP - Triple texture - 397.413330M pixels/sec
FFP - Quad texture - 371.548615M pixels/sec
PS 1.1 - Simple - 492.626953M pixels/sec
PS 1.4 - Simple - Failed!
PS 2.0 - Simple - Failed!
PS 2.0 PP - Simple - Failed!
PS 2.0 - Longer - Failed!
PS 2.0 PP - Longer - Failed!
PS 2.0 - Longer 4 Registers - Failed!
PS 2.0 PP - Longer 4 Registers - Failed!
PS 2.0 - Per Pixel Lighting - Failed!
PS 2.0 PP - Per Pixel Lighting - Failed!


Altri esempi

2778 fill rate pure di 9800xt
1599 ps 1.1

3206 fill rate pure x700pro
1813 ps 1.1

Originariamente inviato da Pat77

Display adapter: NVIDIA GeForce3 Ti 500
Driver version: 6.14.10.7801
Display mode: 1024x768 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------

FFP - Pure fillrate - 906.134766M pixels/sec
FFP - Z pixel rate - 934.874878M pixels/sec
FFP - Single texture - 652.766785M pixels/sec
FFP - Dual texture - 586.997009M pixels/sec
FFP - Triple texture - 309.649353M pixels/sec
FFP - Quad texture - 298.010712M pixels/sec
PS 1.1 - Simple - 473.249237M pixels/sec
PS 1.4 - Simple - Failed!
PS 2.0 - Simple - Failed!
PS 2.0 PP - Simple - Failed!
PS 2.0 - Longer - Failed!
PS 2.0 PP - Longer - Failed!
PS 2.0 - Longer 4 Registers - Failed!
PS 2.0 PP - Longer 4 Registers - Failed!
PS 2.0 - Per Pixel Lighting - Failed!
PS 2.0 PP - Per Pixel Lighting - Failed!

Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce4 Ti 4200
Driver version: 6.14.10.7772
Display mode: 1024x768 A8R8G8B8 70Hz
Z-Buffer format: D24S8
--------------------------

FFP - Pure fillrate - 930.431091M pixels/sec
FFP - Z pixel rate - 973.094421M pixels/sec
FFP - Single texture - 861.695740M pixels/sec
FFP - Dual texture - 750.655090M pixels/sec
FFP - Triple texture - 397.413330M pixels/sec
FFP - Quad texture - 371.548615M pixels/sec
PS 1.1 - Simple - 492.626953M pixels/sec
PS 1.4 - Simple - Failed!
PS 2.0 - Simple - Failed!
PS 2.0 PP - Simple - Failed!
PS 2.0 - Longer - Failed!
PS 2.0 PP - Longer - Failed!
PS 2.0 - Longer 4 Registers - Failed!
PS 2.0 PP - Longer 4 Registers - Failed!
PS 2.0 - Per Pixel Lighting - Failed!
PS 2.0 PP - Per Pixel Lighting - Failed!


Altri esempi

2778 fill rate pure di 9800xt
1599 ps 1.1

3206 fill rate pure x700pro
1813 ps 1.1

capito cosa intendi; la 8500 è l'unica che fa segnare un valore nei ps1.1 uguale a quello del pure fillrate. In realtà, la stessa cosa accade con al Parhelia: ti riporto un test a 1024x768

Fillrate Tester
--------------------------
Display adapter: Matrox Parhelia 256MB
Driver version: 6.13.1.1778
Display mode: 1024x768 A8R8G8B8 120Hz
Z-Buffer format: D15S1
--------------------------

FFP - Pure fillrate - 584.019897M pixels/sec
FFP - Z pixel rate - 588.028381M pixels/sec
FFP - Single texture - 471.751373M pixels/sec
FFP - Dual texture - 469.304016M pixels/sec
FFP - Triple texture - 431.204163M pixels/sec
FFP - Quad texture - 383.128174M pixels/sec
PS 1.1 - Simple - 587.959106M pixels/sec
PS 1.4 - Simple - Failed!
PS 2.0 - Simple - Failed!
PS 2.0 PP - Simple - Failed!
PS 2.0 - Longer - Failed!
PS 2.0 PP - Longer - Failed!
PS 2.0 - Longer 4 Registers - Failed!
PS 2.0 PP - Longer 4 Registers - Failed!
PS 2.0 - Per Pixel Lighting - Failed!
PS 2.0 PP - Per Pixel Lighting - Failed!

Il comportamento "anomalo" va ricercato nel fatto che R200 e Parhelia hanno un numero di registri (temporanei e relativi alle texture), superiore, adeguato allo standard ps1.4 (anche se la Parhelia è 1.3, però si tratta di un chip molto particolare, con una precisione interna di calcolo superiore allo standard 1.1 e con le unità VS quasi 2.0), e pipeline con un numero più elevato di stadi. Tutti i chip successivi (da R300 in poi), pur avendo un numero di registri molto più alto, non hanno HW dedicato allo sm1.x (è emulato dalle fpu, tranne che in NV30, NV31 e NV34, dove si hanno unità in virgola fissa uguali a quelle di NV2x, oltre alla fpu principale che si occupa dei calcoli in fp). Da qui la maggior efficienza di questi due chip con lo sm1.1.
Come puoi vedere, però, in R200, l'utilizzo dello sm1.4 (per cui il chip è strutturato), fa crollare le prestazioni al livello di quelle di NV20 con lo sm1.1. Questo eprchè la quantità di unità di calcolo e di registri utilizzati non eccede mai le specifiche per cui il chip è stato progettato (ma si attiene sempre al valore limite). Uniche eccezioni, i chip della serie NV3x che avevano un numero di registri costanti più elevato eispetto a quanto richiesto dallo standard sm2.0, ma un numero di registri temporanei inferiore.

[Franx1508]

Originariamente inviato da yossarian

capito cosa intendi; la 8500 è l'unica che fa segnare un valore nei ps1.1 uguale a quello del pure fillrate. In realtà, la stessa cosa accade con al Parhelia: ti riporto un test a 1024x768

Fillrate Tester
--------------------------
Display adapter: Matrox Parhelia 256MB
Driver version: 6.13.1.1778
Display mode: 1024x768 A8R8G8B8 120Hz
Z-Buffer format: D15S1
--------------------------

FFP - Pure fillrate - 584.019897M pixels/sec
FFP - Z pixel rate - 588.028381M pixels/sec
FFP - Single texture - 471.751373M pixels/sec
FFP - Dual texture - 469.304016M pixels/sec
FFP - Triple texture - 431.204163M pixels/sec
FFP - Quad texture - 383.128174M pixels/sec
PS 1.1 - Simple - 587.959106M pixels/sec
PS 1.4 - Simple - Failed!
PS 2.0 - Simple - Failed!
PS 2.0 PP - Simple - Failed!
PS 2.0 - Longer - Failed!
PS 2.0 PP - Longer - Failed!
PS 2.0 - Longer 4 Registers - Failed!
PS 2.0 PP - Longer 4 Registers - Failed!
PS 2.0 - Per Pixel Lighting - Failed!
PS 2.0 PP - Per Pixel Lighting - Failed!

Il comportamento "anomalo" va ricercato nel fatto che R200 e Parhelia hanno un numero di registri (temporanei e relativi alle texture), superiore, adeguato allo standard ps1.4 (anche se la Parhelia è 1.3, però si tratta di un chip molto particolare, con una precisione interna di calcolo superiore allo standard 1.1 e con le unità VS quasi 2.0), e pipeline con un numero più elevato di stadi. Tutti i chip successivi (da R300 in poi), pur avendo un numero di registri molto più alto, non hanno HW dedicato allo sm1.x (è emulato dalle fpu, tranne che in NV30, NV31 e NV34, dove si hanno unità in virgola fissa uguali a quelle di NV2x, oltre alla fpu principale che si occupa dei calcoli in fp). Da qui la maggior efficienza di questi due chip con lo sm1.1.
Come puoi vedere, però, in R200, l'utilizzo dello sm1.4 (per cui il chip è strutturato), fa crollare le prestazioni al livello di quelle di NV20 con lo sm1.1. Questo eprchè la quantità di unità di calcolo e di registri utilizzati non eccede mai le specifiche per cui il chip è stato progettato (ma si attiene sempre al valore limite). Uniche eccezioni, i chip della serie NV3x che avevano un numero di registri costanti più elevato eispetto a quanto richiesto dallo standard sm2.0, ma un numero di registri temporanei inferiore.

cavolo ma la parheliaè scarsina...rispetto alla ti500 e 8500.

[Murakami]

Originariamente inviato da Franx1508

cavolo ma la parheliaè scarsina...rispetto alla ti500 e 8500.

Considerando la quadrupla TMU per pipe, il valore del test "quad texture" è davvero basso: possibile che la banda passante, nonostante la mancanza di particolari algoritmi di ottimizzazione, sia insufficiente? Trattasi pur sempre di un bus a 256 bit con fast Z clear, per circa 16-17 gb/sec...

[yossarian]

Originariamente inviato da Murakami

Considerando la quadrupla TMU per pipe, il valore del test "quad texture" è davvero basso: possibile che la banda passante, nonostante la mancanza di particolari algoritmi di ottimizzazione, sia insufficiente? Trattasi pur sempre di un bus a 256 bit con fast Z clear, per circa 16-17 gb/sec...

in questo test, al contrario del 3DMark, il punteggio in multitexturing va decrescendo, eprchè non si misurano i texel ma i pixel per pass. Grazie alle 4 tmu, Matrox riesce a contenere le perdite passando da 1 a 4 texture; però è il punteggio del single e del fillrate a essere bassi, se relazionati a quelli di NV2x e R200. In questo incidono le basse frequenze di funzionamento del chip (sui 220 Mhz se non ricordo male).

Altro handicap è dato dal fatto che la parhelia non ha alcun tipo di algoritmo di hsr; questo significa che ricorre al "vecchio" immediate rendering, calcolando prima tutti i pixel e poi eliminando le superfici nascoste (una buona mole di lavoro inutile).