View Full Version : Marco Dolenc's fillrate test
yossarian
08-12-2004, 16:28
per chi fosse interessato, può scaricare, partendo dal link di questa pagina, il test utilizzato da B3D per valutare le prestazioni dei chip grafici con le varie versioni di ps
http://www.beyond3d.com/previews/nv.../index.php?p=21
volendo potremmo creare un nostro database e vedere anche come si comportano le nuove vga
lasciando, per il test, le impostazioni di default, questi sono i risultati che ho ottenuto
9700 pro non o/c, OS Win ME; Drivers Catalyst 4.9
FFP - Pure fillrate - 1393.287842M pixels/sec
FFP - Z pixel rate - 1855.852173M pixels/sec
FFP - Single texture - 233.671921M pixels/sec
FFP - Dual texture - 149.607315M pixels/sec
FFP - Triple texture - 123.890892M pixels/sec
FFP - Quad texture - 86.983498M pixels/sec
PS 1.1 - Simple - 1210.677246M pixels/sec
PS 1.4 - Simple - 1209.882813M pixels/sec
PS 2.0 - Simple - 1209.384033M pixels/sec
PS 2.0 PP - Simple - 1209.945557M pixels/sec
PS 2.0 - Longer - 628.559692M pixels/sec
PS 2.0 PP - Longer - 625.314697M pixels/sec
PS 2.0 - Longer 4 Registers - 627.982544M pixels/sec
PS 2.0 PP - Longer 4 Registers - 628.275146M pixels/sec
PS 2.0 - Per Pixel Lighting - 147.815475M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 148.173279M pixels/sec
mi raccomando, non barate e buon divertimento
:D
leoneazzurro
08-12-2004, 16:43
Ti rispondo di nuovo anche qui ;)
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce 6800 GT (400 MHz)
Driver version: 6.14.10.6693
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 5299.248535M pixels/sec
FFP - Z pixel rate - 9467.812500M pixels/sec
FFP - Single texture - 2941.027100M pixels/sec
FFP - Dual texture - 1959.145020M pixels/sec
FFP - Triple texture - 1370.884277M pixels/sec
FFP - Quad texture - 1068.245483M pixels/sec
PS 1.1 - Simple - 2644.242188M pixels/sec
PS 1.4 - Simple - 2645.474854M pixels/sec
PS 2.0 - Simple - 2644.375244M pixels/sec
PS 2.0 PP - Simple - 2644.277100M pixels/sec
PS 2.0 - Longer - 1371.299561M pixels/sec
PS 2.0 PP - Longer - 1371.242188M pixels/sec
PS 2.0 - Longer 4 Registers - 1370.625366M pixels/sec
PS 2.0 PP - Longer 4 Registers - 1370.697266M pixels/sec
PS 2.0 - Per Pixel Lighting - 391.765106M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 587.651672M pixels/sec
non mi funziona quel link :(
bYeZ!
yossarian
08-12-2004, 16:55
Originariamente inviato da ATi7500
non mi funziona quel link :(
bYeZ!
cerca la recensione che B3D ha fatto della 5900 ultra, oppure fai una ricerca per "Marco Dolenc's fillrate test application" con google
ma non puoi mettere il link funzionante?
yossarian
08-12-2004, 17:04
provate questo
http://www.beyond3d.com/previews/nvidia/nv35/index.php?p=21
sperando che funzioni
oppure
http://www.beyond3d.com/previews/nvidia/nv35/
e, dal menù a tendina, selezionate "further tests"
http://www2.arnes.si/~mdolen/FillrateTester.zip
bYeZ!
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce 6800 Ultra
Driver version: 6.14.10.7090
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 5867.808105M pixels/sec
FFP - Z pixel rate - 11232.070313M pixels/sec
FFP - Single texture - 3517.950195M pixels/sec
FFP - Dual texture - 2348.263916M pixels/sec
FFP - Triple texture - 1665.170166M pixels/sec
FFP - Quad texture - 1175.552368M pixels/sec
PS 1.1 - Simple - 3226.569580M pixels/sec
PS 1.4 - Simple - 3216.205322M pixels/sec
PS 2.0 - Simple - 3223.004150M pixels/sec
PS 2.0 PP - Simple - 3219.690186M pixels/sec
PS 2.0 - Longer - 1644.299072M pixels/sec
PS 2.0 PP - Longer - 1643.785645M pixels/sec
PS 2.0 - Longer 4 Registers - 1645.993286M pixels/sec
PS 2.0 PP - Longer 4 Registers - 1643.802979M pixels/sec
PS 2.0 - Per Pixel Lighting - 514.041443M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 718.678345M pixels/sec
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce 6800 Ultra
Driver version: 6.14.10.7090
Display mode: 1024x768 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 6569.950684M pixels/sec
FFP - Z pixel rate - 12125.846680M pixels/sec
FFP - Single texture - 6044.337402M pixels/sec
FFP - Dual texture - 3248.246094M pixels/sec
FFP - Triple texture - 2179.063477M pixels/sec
FFP - Quad texture - 1634.588867M pixels/sec
PS 1.1 - Simple - 3326.356201M pixels/sec
PS 1.4 - Simple - 3320.039063M pixels/sec
PS 2.0 - Simple - 3321.811523M pixels/sec
PS 2.0 PP - Simple - 3321.074219M pixels/sec
PS 2.0 - Longer - 1683.144287M pixels/sec
PS 2.0 PP - Longer - 1674.423950M pixels/sec
PS 2.0 - Longer 4 Registers - 1675.169556M pixels/sec
PS 2.0 PP - Longer 4 Registers - 1675.726929M pixels/sec
PS 2.0 - Per Pixel Lighting - 517.519714M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 739.160645M pixels/sec
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce 6800 Ultra
Driver version: 6.14.10.7090
Display mode: 1280x1024 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 6519.856445M pixels/sec
FFP - Z pixel rate - 12593.039063M pixels/sec
FFP - Single texture - 5055.252930M pixels/sec
FFP - Dual texture - 3123.562256M pixels/sec
FFP - Triple texture - 2144.732422M pixels/sec
FFP - Quad texture - 1618.435425M pixels/sec
PS 1.1 - Simple - 3345.470947M pixels/sec
PS 1.4 - Simple - 3346.393066M pixels/sec
PS 2.0 - Simple - 3349.548340M pixels/sec
PS 2.0 PP - Simple - 3344.898193M pixels/sec
PS 2.0 - Longer - 1680.252075M pixels/sec
PS 2.0 PP - Longer - 1678.428223M pixels/sec
PS 2.0 - Longer 4 Registers - 1678.360596M pixels/sec
PS 2.0 PP - Longer 4 Registers - 1678.478271M pixels/sec
PS 2.0 - Per Pixel Lighting - 518.321533M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 741.369812M pixels/sec
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce 6800 Ultra
Driver version: 6.14.10.7090
Display mode: 1600x1200 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 6581.759277M pixels/sec
FFP - Z pixel rate - 12910.447266M pixels/sec
FFP - Single texture - 5673.455566M pixels/sec
FFP - Dual texture - 3205.989502M pixels/sec
FFP - Triple texture - 2176.045410M pixels/sec
FFP - Quad texture - 1636.630615M pixels/sec
PS 1.1 - Simple - 3351.943848M pixels/sec
PS 1.4 - Simple - 3352.251953M pixels/sec
PS 2.0 - Simple - 3350.710938M pixels/sec
PS 2.0 PP - Simple - 3348.892334M pixels/sec
PS 2.0 - Longer - 1681.798096M pixels/sec
PS 2.0 PP - Longer - 1683.058838M pixels/sec
PS 2.0 - Longer 4 Registers - 1682.374878M pixels/sec
PS 2.0 PP - Longer 4 Registers - 1682.359131M pixels/sec
PS 2.0 - Per Pixel Lighting - 518.453369M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 743.916687M pixels/sec
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce 6800 Ultra
Driver version: 6.14.10.7090
Display mode: 1600x1024 R5G6B5 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 6565.438477M pixels/sec
FFP - Z pixel rate - 12630.859375M pixels/sec
FFP - Single texture - 6311.576660M pixels/sec
FFP - Dual texture - 3154.173340M pixels/sec
FFP - Triple texture - 2193.032715M pixels/sec
FFP - Quad texture - 1634.781982M pixels/sec
PS 1.1 - Simple - 3339.492432M pixels/sec
PS 1.4 - Simple - 3338.200928M pixels/sec
PS 2.0 - Simple - 3351.455078M pixels/sec
PS 2.0 PP - Simple - 3338.222900M pixels/sec
PS 2.0 - Longer - 1680.128662M pixels/sec
PS 2.0 PP - Longer - 1680.313232M pixels/sec
PS 2.0 - Longer 4 Registers - 1679.490234M pixels/sec
PS 2.0 PP - Longer 4 Registers - 1679.633911M pixels/sec
PS 2.0 - Per Pixel Lighting - 517.694824M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 745.456360M pixels/sec
yossarian
08-12-2004, 17:24
Originariamente inviato da leoneazzurro
Ti rispondo di nuovo anche qui ;)
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce 6800 GT (400 MHz)
Driver version: 6.14.10.6693
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 5299.248535M pixels/sec
FFP - Z pixel rate - 9467.812500M pixels/sec
FFP - Single texture - 2941.027100M pixels/sec
FFP - Dual texture - 1959.145020M pixels/sec
FFP - Triple texture - 1370.884277M pixels/sec
FFP - Quad texture - 1068.245483M pixels/sec
PS 1.1 - Simple - 2644.242188M pixels/sec
PS 1.4 - Simple - 2645.474854M pixels/sec
PS 2.0 - Simple - 2644.375244M pixels/sec
PS 2.0 PP - Simple - 2644.277100M pixels/sec
PS 2.0 - Longer - 1371.299561M pixels/sec
PS 2.0 PP - Longer - 1371.242188M pixels/sec
PS 2.0 - Longer 4 Registers - 1370.625366M pixels/sec
PS 2.0 PP - Longer 4 Registers - 1370.697266M pixels/sec
PS 2.0 - Per Pixel Lighting - 391.765106M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 587.651672M pixels/sec
scoperto l'arcano sulla grande differenza di pure fillrate; io ho eseguito il test a 320, tu a 640
questi sono i miei risultati a 640x480
Display adapter: RADEON 9700 PRO
Driver version: 4.14.1.227
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D16_LOCKABLE
--------------------------
FFP - Pure fillrate - 2373.875977M pixels/sec
FFP - Z pixel rate - 2186.839355M pixels/sec
FFP - Single texture - 1131.169922M pixels/sec
FFP - Dual texture - 527.184448M pixels/sec
FFP - Triple texture - 304.772491M pixels/sec
FFP - Quad texture - 226.401367M pixels/sec
PS 1.1 - Simple - 1281.630005M pixels/sec
PS 1.4 - Simple - 1281.308716M pixels/sec
PS 2.0 - Simple - 1282.359863M pixels/sec
PS 2.0 PP - Simple - 1279.553955M pixels/sec
PS 2.0 - Longer - 645.843567M pixels/sec
PS 2.0 PP - Longer - 644.880859M pixels/sec
PS 2.0 - Longer 4 Registers - 646.073547M pixels/sec
PS 2.0 PP - Longer 4 Registers - 646.546692M pixels/sec
PS 2.0 - Per Pixel Lighting - 162.326965M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 162.212509M pixels/sec
yossarian
08-12-2004, 17:27
grazie a questi test è possibile vedere come l'NV40 si comporti allo stesso modo con ps1.x e con ps2.0 sia in fp16 che in fp32 (al contrario di quanto accadeva con NV3x); inoltre si può apprezzare l'efficienza delle ROP's che, in caso di soli calcoli relativi allo z-buffer, riescono quasi a raddoppiare l'output (caratteristica, questa, presente anche su NV3x)
BTinside
08-12-2004, 17:29
Nessuno che ha la X800XT lo fa?:D
Originariamente inviato da yossarian
grazie a questi test è possibile vedere come l'NV40 si comporti allo stesso modo con ps1.x e con ps2.0 sia in fp16 che in fp32 (al contrario di quanto accadeva con NV3x); inoltre si può apprezzare l'efficienza delle ROP's che, in caso di soli calcoli relativi allo z-buffer, riescono quasi a raddoppiare l'output (caratteristica, questa, presente anche su NV3x)
come fai a sapere quali sono i risultati in fp16 e quelli in fp32?
cosa cabia da Display mode: 1600x1024 R5G6B5 60Hz
a Display mode: 1600x1200 A8R8G8B8 60Hz
cosa cambia nei vari z-buffer selezionabili?
yossarian
08-12-2004, 17:32
Display adapter: RADEON 9700 PRO
Driver version: 4.14.1.227
Display mode: 1152x864 A8R8G8B8 0Hz
Z-Buffer format: D24X8
--------------------------
FFP - Pure fillrate - 2483.534180M pixels/sec
FFP - Z pixel rate - 2242.562744M pixels/sec
FFP - Single texture - 2116.882568M pixels/sec
FFP - Dual texture - 1042.277344M pixels/sec
FFP - Triple texture - 525.363403M pixels/sec
FFP - Quad texture - 370.998779M pixels/sec
PS 1.1 - Simple - 1293.834351M pixels/sec
PS 1.4 - Simple - 1293.239868M pixels/sec
PS 2.0 - Simple - 1291.509155M pixels/sec
PS 2.0 PP - Simple - 1294.000366M pixels/sec
PS 2.0 - Longer - 649.171936M pixels/sec
PS 2.0 PP - Longer - 648.917419M pixels/sec
PS 2.0 - Longer 4 Registers - 650.922241M pixels/sec
PS 2.0 PP - Longer 4 Registers - 648.341736M pixels/sec
PS 2.0 - Per Pixel Lighting - 163.077988M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 162.636276M pixels/sec
yossarian
08-12-2004, 17:43
Originariamente inviato da samuelx
come fai a sapere quali sono i risultati in fp16 e quelli in fp32?
cosa cabia da Display mode: 1600x1024 R5G6B5 60Hz
a Display mode: 1600x1200 A8R8G8B8 60Hz
cosa cambia nei vari z-buffer selezionabili?
quando trovi la dicitura ps2.0 pp indica fp16; ps2.0 simple, invece, è fp32.
per i vari formati di z-buffer puoi dare un'occhiata qui
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_m/directx/ref/ns/microsoft.directx.direct3d/e/format/format.asp
sperando che funzioni
leoneazzurro
08-12-2004, 19:46
Originariamente inviato da yossarian
scoperto l'arcano sulla grande differenza di pure fillrate; io ho eseguito il test a 320, tu a 640
questi sono i miei risultati a 640x480
Display adapter: RADEON 9700 PRO
Driver version: 4.14.1.227
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D16_LOCKABLE
--------------------------
FFP - Pure fillrate - 2373.875977M pixels/sec
FFP - Z pixel rate - 2186.839355M pixels/sec
FFP - Single texture - 1131.169922M pixels/sec
FFP - Dual texture - 527.184448M pixels/sec
FFP - Triple texture - 304.772491M pixels/sec
FFP - Quad texture - 226.401367M pixels/sec
PS 1.1 - Simple - 1281.630005M pixels/sec
PS 1.4 - Simple - 1281.308716M pixels/sec
PS 2.0 - Simple - 1282.359863M pixels/sec
PS 2.0 PP - Simple - 1279.553955M pixels/sec
PS 2.0 - Longer - 645.843567M pixels/sec
PS 2.0 PP - Longer - 644.880859M pixels/sec
PS 2.0 - Longer 4 Registers - 646.073547M pixels/sec
PS 2.0 PP - Longer 4 Registers - 646.546692M pixels/sec
PS 2.0 - Per Pixel Lighting - 162.326965M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 162.212509M pixels/sec
Eh.. a me in default proponeva 640x480. :)
PS: per Samulex : hai le frequenze della Ultra a default?
oc 350/830
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce 6800
Driver version: 6.14.10.6693
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 3529.519287M pixels/sec
FFP - Z pixel rate - 7077.949219M pixels/sec
FFP - Single texture - 2887.470947M pixels/sec
FFP - Dual texture - 1645.382202M pixels/sec
FFP - Triple texture - 1133.591797M pixels/sec
FFP - Quad texture - 865.570068M pixels/sec
PS 1.1 - Simple - 1763.488037M pixels/sec
PS 1.4 - Simple - 1763.557861M pixels/sec
PS 2.0 - Simple - 1763.886719M pixels/sec
PS 2.0 PP - Simple - 1763.564941M pixels/sec
PS 2.0 - Longer - 940.260315M pixels/sec
PS 2.0 PP - Longer - 940.008362M pixels/sec
PS 2.0 - Longer 4 Registers - 940.245300M pixels/sec
PS 2.0 PP - Longer 4 Registers - 940.248657M pixels/sec
PS 2.0 - Per Pixel Lighting - 272.645477M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 419.661896M pixels/sec
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce4 Ti 4200
Driver version: 6.14.10.6702
Display mode: 1024x768 A8R8G8B8 85Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 1115.608398M pixels/sec
FFP - Z pixel rate - 1170.974121M pixels/sec
FFP - Single texture - 1013.330017M pixels/sec
FFP - Dual texture - 876.510254M pixels/sec
FFP - Triple texture - 459.065613M pixels/sec
FFP - Quad texture - 432.258636M pixels/sec
PS 1.1 - Simple - 592.537964M 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!
notare come la 4200 in multitexturing stia sopra alla 9700 :D
yossarian
08-12-2004, 20:35
Originariamente inviato da checo
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce4 Ti 4200
Driver version: 6.14.10.6702
Display mode: 1024x768 A8R8G8B8 85Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 1115.608398M pixels/sec
FFP - Z pixel rate - 1170.974121M pixels/sec
FFP - Single texture - 1013.330017M pixels/sec
FFP - Dual texture - 876.510254M pixels/sec
FFP - Triple texture - 459.065613M pixels/sec
FFP - Quad texture - 432.258636M pixels/sec
PS 1.1 - Simple - 592.537964M 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!
notare come la 4200 in multitexturing stia sopra alla 9700 :D
e anche come, grazie alla doppia tmu, il passaggio da 1 a 2 e da 3 a 4 texture non sia così traumatico come nei chip con singola tmu (R3x0, R420, NV40). Purtroppo con i ps1.1 paga la scotto di avere una sola alu per pipeline
Originariamente inviato da leoneazzurro
Eh.. a me in default proponeva 640x480. :)
PS: per Samulex : hai le frequenze della Ultra a default?
si le frequenze sono 400/1100
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce 6800 Ultra @425/1150
Driver version: 6.14.10.7090
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 6463.857422M pixels/sec
FFP - Z pixel rate - 11870.563477M pixels/sec
FFP - Single texture - 3826.388672M pixels/sec
FFP - Dual texture - 2589.628418M pixels/sec
FFP - Triple texture - 1766.044067M pixels/sec
FFP - Quad texture - 1371.229614M pixels/sec
PS 1.1 - Simple - 3397.631348M pixels/sec
PS 1.4 - Simple - 3398.598877M pixels/sec
PS 2.0 - Simple - 3395.940186M pixels/sec
PS 2.0 PP - Simple - 3399.714844M pixels/sec
PS 2.0 - Longer - 1762.729004M pixels/sec
PS 2.0 PP - Longer - 1762.356812M pixels/sec
PS 2.0 - Longer 4 Registers - 1765.427856M pixels/sec
PS 2.0 PP - Longer 4 Registers - 1761.195313M pixels/sec
PS 2.0 - Per Pixel Lighting - 538.793152M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 736.786804M pixels/sec
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce 6800 Ultra @425/1150
Driver version: 6.14.10.7090
Display mode: 1600x1200 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 6990.172852M pixels/sec
FFP - Z pixel rate - 13708.497070M pixels/sec
FFP - Single texture - 6121.027344M pixels/sec
FFP - Dual texture - 3399.645508M pixels/sec
FFP - Triple texture - 2312.535889M pixels/sec
FFP - Quad texture - 1740.954834M pixels/sec
PS 1.1 - Simple - 3543.903320M pixels/sec
PS 1.4 - Simple - 3546.824707M pixels/sec
PS 2.0 - Simple - 3544.030273M pixels/sec
PS 2.0 PP - Simple - 3544.850342M pixels/sec
PS 2.0 - Longer - 1782.463867M pixels/sec
PS 2.0 PP - Longer - 1781.810547M pixels/sec
PS 2.0 - Longer 4 Registers - 1780.979126M pixels/sec
PS 2.0 PP - Longer 4 Registers - 1781.899536M pixels/sec
PS 2.0 - Per Pixel Lighting - 541.714417M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 189681.250000M pixels/sec <---- :confused: rifatto 2 volte risultato simile :muro:
yossarian
08-12-2004, 22:42
Originariamente inviato da samuelx
PS 2.0 PP - Per Pixel Lighting - 189681.250000M pixels/sec <---- :confused: rifatto 2 volte risultato simile :muro:
sarà, con ogni probabilità, qualche bug nei drivers (così come era successo con le prime release, con cui l'NV40 sembrava andare meglio con i ps2.0 in fp32 che non con fp16 o con i ps1.x (con cui si comportava come se avesse 12 e non 16 pipeline).
Il risultato reale è molto simile a quello ottenuto a 640x480
IIPyrosII
09-12-2004, 13:11
Scheda cloccata come in sign
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce FX 5900XT
Driver version: 6.14.10.6672
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 833.328979M pixels/sec
FFP - Z pixel rate - 3283.066650M pixels/sec
FFP - Single texture - 1589.981934M pixels/sec
FFP - Dual texture - 1144.068115M pixels/sec
FFP - Triple texture - 652.526794M pixels/sec
FFP - Quad texture - 465.925720M pixels/sec
PS 1.1 - Simple - 877.980347M pixels/sec
PS 1.4 - Simple - 832.167297M pixels/sec
PS 2.0 - Simple - 563.016418M pixels/sec
PS 2.0 PP - Simple - 833.561340M pixels/sec
PS 2.0 - Longer - 213.498749M pixels/sec
PS 2.0 PP - Longer - 424.998932M pixels/sec
PS 2.0 - Longer 4 Registers - 213.393600M pixels/sec
PS 2.0 PP - Longer 4 Registers - 560.214355M pixels/sec
PS 2.0 - Per Pixel Lighting - 84.670235M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 120.282982M pixels/sec
Non capisco il perche di un fillrate cosi ridicolo..
yossarian
09-12-2004, 14:11
Originariamente inviato da IIPyrosII
Scheda cloccata come in sign
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce FX 5900XT
Driver version: 6.14.10.6672
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 833.328979M pixels/sec
FFP - Z pixel rate - 3283.066650M pixels/sec
FFP - Single texture - 1589.981934M pixels/sec
FFP - Dual texture - 1144.068115M pixels/sec
FFP - Triple texture - 652.526794M pixels/sec
FFP - Quad texture - 465.925720M pixels/sec
PS 1.1 - Simple - 877.980347M pixels/sec
PS 1.4 - Simple - 832.167297M pixels/sec
PS 2.0 - Simple - 563.016418M pixels/sec
PS 2.0 PP - Simple - 833.561340M pixels/sec
PS 2.0 - Longer - 213.498749M pixels/sec
PS 2.0 PP - Longer - 424.998932M pixels/sec
PS 2.0 - Longer 4 Registers - 213.393600M pixels/sec
PS 2.0 PP - Longer 4 Registers - 560.214355M pixels/sec
PS 2.0 - Per Pixel Lighting - 84.670235M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 120.282982M pixels/sec
Non capisco il perche di un fillrate cosi ridicolo..
se parli del pure fillrate, c'è da dire che incidono non poco le sole 4 pipeline. Se provi il test a 1024x768 il valore dovrebbe salire sensibilmente. Tieni conto che per ogni 4 pixel in output c'è la necessità di un accesso al framebuffer per prelavare altri dati; quindi rispetto ad un'architettura 8x1 o 16x1, gli accessi alla ram video (che sono uno degli elementi che maggiormente contribuiscono ad abbassare le prestazioni), sono rispettivamente doppi o quadrupli.
Comunque, finalmente una FX che, per quanto riguarda questo test, rappresenta la famiglia di chip più interessante, perchè hanno un comportamento non così lineare come quello di R3x0, R420 e NV40, come si può notare dalle oscillazioni dei dati relativi all'utilizzo di ps2.0 in fp16 e in fp32.
Come si può notare, con shader particolarmente lunghi, anche l'fp16, seppure permetta di raddoppiare le prestazioni rispetto a fp32 (che nei giochi, considerando anche le operazioni di texturing e altro si traduce in un 20-30% in più) non garantisce un frame rate sufficientemente elevato (quello che succede in alcune mappe di HL2)
Se vi interessa un raffronto con la schede "vecchie", almeno per quanto riguarda la fillrate dato che per i PS si fermano prima :D
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce2 GTS/GeForce2 Pro -> @200/400
Driver version: 6.14.10.6177
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 729.713135M pixels/sec
FFP - Z pixel rate - 634.393433M pixels/sec
FFP - Single texture - 579.117004M pixels/sec
FFP - Dual texture - 274.523193M pixels/sec
FFP - Triple texture - Failed!
FFP - Quad texture - Failed!
PS 1.1 - Simple - Failed!
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 -> @250/513 (default)
Driver version: 6.14.10.6693
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 925.071960M pixels/sec
FFP - Z pixel rate - 967.265137M pixels/sec
FFP - Single texture - 784.871033M pixels/sec
FFP - Dual texture - 573.592224M pixels/sec
FFP - Triple texture - 371.719482M pixels/sec
FFP - Quad texture - 284.931732M pixels/sec
PS 1.1 - Simple - 491.068146M 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!
zerothehero
09-12-2004, 16:17
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce 6800 GT
Driver version: 6.14.10.6702
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
FFP - Pure fillrate - 5742.466797M pixels/sec
FFP - Z pixel rate - 10428.486328M pixels/sec
FFP - Single texture - 3527.928711M pixels/sec
FFP - Dual texture - 2351.639648M pixels/sec
FFP - Triple texture - 1716.735229M pixels/sec
FFP - Quad texture - 1295.418213M pixels/sec
PS 1.1 - Simple - 2939.975098M pixels/sec
PS 1.4 - Simple - 2939.774658M pixels/sec
PS 2.0 - Simple - 2940.089355M pixels/sec
PS 2.0 PP - Simple - 2940.016357M pixels/sec
PS 2.0 - Longer - 1560.307983M pixels/sec
PS 2.0 PP - Longer - 1564.027588M pixels/sec
PS 2.0 - Longer 4 Registers - 1563.478149M pixels/sec
PS 2.0 PP - Longer 4 Registers - 1564.561890M pixels/sec
PS 2.0 - Per Pixel Lighting - 440.757782M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 685.300903M pixels/sec
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce 6800 GT
Driver version: 6.14.10.6702
Display mode: 1600x1200 A8R8G8B8 75Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 6237.808594M pixels/sec
FFP - Z pixel rate - 12294.779297M pixels/sec
FFP - Single texture - 5755.492676M pixels/sec
FFP - Dual texture - 3091.392578M pixels/sec
FFP - Triple texture - 2077.685791M pixels/sec
FFP - Quad texture - 1566.009766M pixels/sec
PS 1.1 - Simple - 3145.321777M pixels/sec
PS 1.4 - Simple - 3145.660645M pixels/sec
PS 2.0 - Simple - 3146.949219M pixels/sec
PS 2.0 PP - Simple - 3145.873291M pixels/sec
PS 2.0 - Longer - 1579.383911M pixels/sec
PS 2.0 PP - Longer - 1579.310669M pixels/sec
PS 2.0 - Longer 4 Registers - 1578.957153M pixels/sec
PS 2.0 PP - Longer 4 Registers - 1579.669067M pixels/sec
PS 2.0 - Per Pixel Lighting - 446.206482M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 702.758240M pixels/sec
yossarian
09-12-2004, 23:31
Originariamente inviato da lowenz
Se vi interessa un raffronto con la schede "vecchie", almeno per quanto riguarda la fillrate dato che per i PS si fermano prima :D
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce2 GTS/GeForce2 Pro -> @200/400
Driver version: 6.14.10.6177
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 729.713135M pixels/sec
FFP - Z pixel rate - 634.393433M pixels/sec
FFP - Single texture - 579.117004M pixels/sec
FFP - Dual texture - 274.523193M pixels/sec
FFP - Triple texture - Failed!
FFP - Quad texture - Failed!
------------------------------------------------------------------------------
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce4 Ti 4200 -> @250/513 (default)
Driver version: 6.14.10.6693
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 925.071960M pixels/sec
FFP - Z pixel rate - 967.265137M pixels/sec
FFP - Single texture - 784.871033M pixels/sec
FFP - Dual texture - 573.592224M pixels/sec
FFP - Triple texture - 371.719482M pixels/sec
FFP - Quad texture - 284.931732M pixels/sec
PS 1.1 - Simple - 491.068146M pixels/sec
PS 1.4 - Simple - Failed!
battute a parte, si tratta di risultati estremamente interessanti: primo fra tutti, quello relativo al dual texturing del GF2; un'architettura 4x2 non dovrebbe presentare un calo così marcato nel passaggio tra 1 e 2 texture; invece nei dati che hai postato, la diminuzione del fillrate supera il 50%, coma accade anche con il Radeon 8500. Questo farebbe ipotizzare che solo 2 pipeline su 4 sino in grado di effetture operazioni di multitexturing.
Invece, poichè il test considera solo le operazioni eseguite per single pass, nel caso di applicazione di 3 o 4 texel per pixel il risultato "failed" è scontato, in quanto la GF2 esegue al massimo dual texturing in single pass.
Ottima la capacità in multitexturing dell'NV25 che riesce, unico chip 4x2 di quelli visti, alimitare l eperdite anche nel passaggio da 2 a 3 texl per pixel che per una 4x2 è il passaggio più critico.
scheda a 600/560
Fillrate Tester
--------------------------
Display adapter: RADEON X800 XT Platinum Edition
Driver version: 6.14.10.6490
Display mode: 1024x768 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 6231.618164M pixels/sec
FFP - Z pixel rate - 9022.066406M pixels/sec
FFP - Single texture - 4621.896973M pixels/sec
FFP - Dual texture - 2588.618164M pixels/sec
FFP - Triple texture - 1821.676270M pixels/sec
FFP - Quad texture - 1244.296021M pixels/sec
PS 1.1 - Simple - 4670.588379M pixels/sec
PS 1.4 - Simple - 4669.790527M pixels/sec
PS 2.0 - Simple - 4670.097656M pixels/sec
PS 2.0 PP - Simple - 4670.029297M pixels/sec
PS 2.0 - Longer - 2365.087158M pixels/sec
PS 2.0 PP - Longer - 2365.136230M pixels/sec
PS 2.0 - Longer 4 Registers - 2364.955811M pixels/sec
PS 2.0 PP - Longer 4 Registers - 2364.999268M pixels/sec
PS 2.0 - Per Pixel Lighting - 679.893799M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 679.889404M pixels/sec
Fillrate Tester
--------------------------
Display adapter: RADEON X800 XT Platinum Edition
Driver version: 6.14.10.6490
Display mode: 1280x1024 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 6450.443359M pixels/sec
FFP - Z pixel rate - 8905.141602M pixels/sec
FFP - Single texture - 4678.484863M pixels/sec
FFP - Dual texture - 2662.453613M pixels/sec
FFP - Triple texture - 1843.867188M pixels/sec
FFP - Quad texture - 1263.865723M pixels/sec
PS 1.1 - Simple - 4685.487305M pixels/sec
PS 1.4 - Simple - 4685.471680M pixels/sec
PS 2.0 - Simple - 4685.161621M pixels/sec
PS 2.0 PP - Simple - 4685.050781M pixels/sec
PS 2.0 - Longer - 2370.227051M pixels/sec
PS 2.0 PP - Longer - 2370.260010M pixels/sec
PS 2.0 - Longer 4 Registers - 2370.183350M pixels/sec
PS 2.0 PP - Longer 4 Registers - 2370.180908M pixels/sec
PS 2.0 - Per Pixel Lighting - 680.753845M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 680.746521M pixels/sec
qualcuno con schede meno sberluccicanti?
9800se, 5700...
sarei curioso di vedere che differenze percentuali ci sono con le schede "monstre" (la mia, tutt'altro che monster è già stata sviscerata).
Salut
Stasera con un po' di fortuna provo anche io...
Ciao! :)
BTinside
10-12-2004, 14:29
Fillrate Tester
--------------------------
Display adapter: Gainward GeForce 6800 GT@Ultra (400/1100)
Driver version: 6.14.10.6702
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 5922.908203M pixels/sec
FFP - Z pixel rate - 10599.741211M pixels/sec
FFP - Single texture - 3530.028564M pixels/sec
FFP - Dual texture - 2352.800537M pixels/sec
FFP - Triple texture - 1716.273804M pixels/sec
FFP - Quad texture - 1288.487061M pixels/sec
PS 1.1 - Simple - 2961.478516M pixels/sec
PS 1.4 - Simple - 2945.014404M pixels/sec
PS 2.0 - Simple - 2954.542725M pixels/sec
PS 2.0 PP - Simple - 2958.227051M pixels/sec
PS 2.0 - Longer - 1565.437988M pixels/sec
PS 2.0 PP - Longer - 1567.082031M pixels/sec
PS 2.0 - Longer 4 Registers - 1567.414551M pixels/sec
PS 2.0 PP - Longer 4 Registers - 1564.583862M pixels/sec
PS 2.0 - Per Pixel Lighting - 440.822662M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 685.492126M pixels/sec
BTinside
10-12-2004, 14:52
Originariamente inviato da crice
scheda a 600/560
Fillrate Tester
--------------------------
Display adapter: RADEON X800 XT Platinum Edition
Driver version: 6.14.10.6490
Display mode: 1024x768 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 6231.618164M pixels/sec
FFP - Z pixel rate - 9022.066406M pixels/sec
FFP - Single texture - 4621.896973M pixels/sec
FFP - Dual texture - 2588.618164M pixels/sec
FFP - Triple texture - 1821.676270M pixels/sec
FFP - Quad texture - 1244.296021M pixels/sec
PS 1.1 - Simple - 4670.588379M pixels/sec
PS 1.4 - Simple - 4669.790527M pixels/sec
PS 2.0 - Simple - 4670.097656M pixels/sec
PS 2.0 PP - Simple - 4670.029297M pixels/sec
PS 2.0 - Longer - 2365.087158M pixels/sec
PS 2.0 PP - Longer - 2365.136230M pixels/sec
PS 2.0 - Longer 4 Registers - 2364.955811M pixels/sec
PS 2.0 PP - Longer 4 Registers - 2364.999268M pixels/sec
PS 2.0 - Per Pixel Lighting - 679.893799M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 679.889404M pixels/sec
Fillrate Tester
--------------------------
Display adapter: RADEON X800 XT Platinum Edition
Driver version: 6.14.10.6490
Display mode: 1280x1024 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 6450.443359M pixels/sec
FFP - Z pixel rate - 8905.141602M pixels/sec
FFP - Single texture - 4678.484863M pixels/sec
FFP - Dual texture - 2662.453613M pixels/sec
FFP - Triple texture - 1843.867188M pixels/sec
FFP - Quad texture - 1263.865723M pixels/sec
PS 1.1 - Simple - 4685.487305M pixels/sec
PS 1.4 - Simple - 4685.471680M pixels/sec
PS 2.0 - Simple - 4685.161621M pixels/sec
PS 2.0 PP - Simple - 4685.050781M pixels/sec
PS 2.0 - Longer - 2370.227051M pixels/sec
PS 2.0 PP - Longer - 2370.260010M pixels/sec
PS 2.0 - Longer 4 Registers - 2370.183350M pixels/sec
PS 2.0 PP - Longer 4 Registers - 2370.180908M pixels/sec
PS 2.0 - Per Pixel Lighting - 680.753845M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 680.746521M pixels/sec
Crice mi farestri un favore? lo firai il test a 640x480 e a frequenze standard? così posso confrontarlo con la mia scheda
grazie , ciao
Thunder82
10-12-2004, 18:02
Fillrate Tester
--------------------------
Display adapter: RADEON 9600XT (@ 570/700)
Driver version: 6.14.10.6497 (4.12 beta)
Display mode: 1600x1200 A8R8G8B8 75Hz
Z-Buffer format: D16_LOCKABLE
--------------------------
FFP - Pure fillrate - 1378.207031M pixels/sec
FFP - Z pixel rate - 2134.623779M pixels/sec
FFP - Single texture - 1376.892090M pixels/sec
FFP - Dual texture - 1014.514771M pixels/sec
FFP - Triple texture - 681.482239M pixels/sec
FFP - Quad texture - 525.284973M pixels/sec
PS 1.1 - Simple - 1108.431763M pixels/sec
PS 1.4 - Simple - 1108.447144M pixels/sec
PS 2.0 - Simple - 1108.481201M pixels/sec
PS 2.0 PP - Simple - 1108.431274M pixels/sec
PS 2.0 - Longer - 560.150879M pixels/sec
PS 2.0 PP - Longer - 560.114258M pixels/sec
PS 2.0 - Longer 4 Registers - 560.109863M pixels/sec
PS 2.0 PP - Longer 4 Registers - 560.116211M pixels/sec
PS 2.0 - Per Pixel Lighting - 160.792419M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 160.781647M pixels/sec
Fillrate Tester
--------------------------
Display adapter: RADEON 9600XT (@570/700)
Driver version: 6.14.10.6497 (4.12 beta)
Display mode: 1024x768 A8R8G8B8 85Hz
Z-Buffer format: D16_LOCKABLE
--------------------------
FFP - Pure fillrate - 1387.985596M pixels/sec
FFP - Z pixel rate - 2171.204346M pixels/sec
FFP - Single texture - 1386.632935M pixels/sec
FFP - Dual texture - 953.452026M pixels/sec
FFP - Triple texture - 637.466919M pixels/sec
FFP - Quad texture - 506.399506M pixels/sec
PS 1.1 - Simple - 1112.999634M pixels/sec
PS 1.4 - Simple - 1112.999634M pixels/sec
PS 2.0 - Simple - 1112.998901M pixels/sec
PS 2.0 PP - Simple - 1113.076782M pixels/sec
PS 2.0 - Longer - 561.209778M pixels/sec
PS 2.0 PP - Longer - 561.140747M pixels/sec
PS 2.0 - Longer 4 Registers - 561.132751M pixels/sec
PS 2.0 PP - Longer 4 Registers - 561.157104M pixels/sec
PS 2.0 - Per Pixel Lighting - 161.258728M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 160.885941M pixels/sec
Azzo come rulla :sofico:
Ho prestazioni identiche sia a 1024 che a 1600, anzi a 1024 faccio di più che a 1600 come mai? finora ho visto che le prestazioni cambiano con la risoluzione con le altre schede :confused:
Crice mi farestri un favore? lo firai il test a 640x480 e a frequenze standard? così posso confrontarlo con la mia scheda
grazie , ciao
eccoti il test a 520/560, fammi sapere i tuoi risultati
Fillrate Tester
--------------------------
Display adapter: RADEON X800 XT Platinum Edition
Driver version: 6.14.10.6490
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 5626.375977M pixels/sec
FFP - Z pixel rate - 7375.786133M pixels/sec
FFP - Single texture - 3207.737305M pixels/sec
FFP - Dual texture - 1776.733276M pixels/sec
FFP - Triple texture - 1216.183594M pixels/sec
FFP - Quad texture - 741.293396M pixels/sec
PS 1.1 - Simple - 3965.727783M pixels/sec
PS 1.4 - Simple - 3964.726074M pixels/sec
PS 2.0 - Simple - 3965.047363M pixels/sec
PS 2.0 PP - Simple - 3964.977051M pixels/sec
PS 2.0 - Longer - 2033.613403M pixels/sec
PS 2.0 PP - Longer - 2033.564941M pixels/sec
PS 2.0 - Longer 4 Registers - 2033.656006M pixels/sec
PS 2.0 PP - Longer 4 Registers - 2033.575806M pixels/sec
PS 2.0 - Per Pixel Lighting - 585.837585M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 585.832458M pixels/sec
Fillrate Tester
--------------------------
Display adapter: RADEON X800 XT Platinum Edition @default cata 4.11
Driver version: 6.14.10.6490
Display mode: 1152x864 A8R8G8B8 100Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 5734.060547M pixels/sec
FFP - Z pixel rate - 7717.536133M pixels/sec
FFP - Single texture - 4158.125488M pixels/sec
FFP - Dual texture - 2324.672607M pixels/sec
FFP - Triple texture - 1608.985596M pixels/sec
FFP - Quad texture - 1096.692017M pixels/sec
PS 1.1 - Simple - 4071.221436M pixels/sec
PS 1.4 - Simple - 4061.173828M pixels/sec
PS 2.0 - Simple - 4058.468018M pixels/sec
PS 2.0 PP - Simple - 4060.837402M pixels/sec
PS 2.0 - Longer - 2062.400879M pixels/sec
PS 2.0 PP - Longer - 2052.154541M pixels/sec
PS 2.0 - Longer 4 Registers - 2052.051514M pixels/sec
PS 2.0 PP - Longer 4 Registers - 2052.073975M pixels/sec
PS 2.0 - Per Pixel Lighting - 589.170227M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 589.130188M pixels/sec
che cappero di risuluzione è 1152x864?
potresti rifare il test a 640x480@ 60hz?così possiamo confrontare i risultati dei vari utenti.
grazie
Originariamente inviato da crice
che cappero di risuluzione è 1152x864?
potresti rifare il test a 640x480@ 60hz?così possiamo confrontare i risultati dei vari utenti.
grazie
Fillrate Tester
--------------------------
Display adapter: RADEON X800 XT Platinum Edition @default
Driver version: 6.14.10.6490
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 5515.325684M pixels/sec
FFP - Z pixel rate - 7509.715332M pixels/sec
FFP - Single texture - 3192.421631M pixels/sec
FFP - Dual texture - 1777.020996M pixels/sec
FFP - Triple texture - 1214.343750M pixels/sec
FFP - Quad texture - 739.723816M pixels/sec
PS 1.1 - Simple - 3997.434570M pixels/sec
PS 1.4 - Simple - 3995.125977M pixels/sec
PS 2.0 - Simple - 4012.619873M pixels/sec
PS 2.0 PP - Simple - 3996.077637M pixels/sec
PS 2.0 - Longer - 2035.096191M pixels/sec
PS 2.0 PP - Longer - 2039.318237M pixels/sec
PS 2.0 - Longer 4 Registers - 2034.490234M pixels/sec
PS 2.0 PP - Longer 4 Registers - 2033.882568M pixels/sec
PS 2.0 - Per Pixel Lighting - 587.031189M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 586.895996M pixels/sec
Ciao, ecco il mio risultato:
Fillrate Tester
--------------------------
Display adapter: RADEON 9800 XT
Driver version: 6.14.10.6497
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D16_LOCKABLE
--------------------------
FFP - Pure fillrate - 2740.079590M pixels/sec
FFP - Z pixel rate - 2722.244629M pixels/sec
FFP - Single texture - 1677.936035M pixels/sec
FFP - Dual texture - 803.108398M pixels/sec
FFP - Triple texture - 560.367004M pixels/sec
FFP - Quad texture - 411.318695M pixels/sec
PS 1.1 - Simple - 1612.683594M pixels/sec
PS 1.4 - Simple - 1612.624512M pixels/sec
PS 2.0 - Simple - 1614.792114M pixels/sec
PS 2.0 PP - Simple - 1614.643311M pixels/sec
PS 2.0 - Longer - 814.082581M pixels/sec
PS 2.0 PP - Longer - 814.232056M pixels/sec
PS 2.0 - Longer 4 Registers - 814.090332M pixels/sec
PS 2.0 PP - Longer 4 Registers - 814.012268M pixels/sec
PS 2.0 - Per Pixel Lighting - 233.407166M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 233.398972M pixels/sec
Ci tengo a precisare che la mia non è una vera 9800XT in quanto ho una 9800Pro sulla quale ho messo un BIOS che riporta come deviceid quello della 9800XT (4E4A) ma, dato che ho una scheda con R350 e non R360, nel 3DMark2003 test 2 e 3 ci sono artefatti.
Con tutte le altre applicazioni nulla fuori posto da segnalare :cool: (almeno per ora...:D).
BTinside
11-12-2004, 14:20
Originariamente inviato da crice
eccoti il test a 520/560, fammi sapere i tuoi risultati
Fillrate Tester
--------------------------
Display adapter: RADEON X800 XT Platinum Edition
Driver version: 6.14.10.6490
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 5626.375977M pixels/sec
FFP - Z pixel rate - 7375.786133M pixels/sec
FFP - Single texture - 3207.737305M pixels/sec
FFP - Dual texture - 1776.733276M pixels/sec
FFP - Triple texture - 1216.183594M pixels/sec
FFP - Quad texture - 741.293396M pixels/sec
PS 1.1 - Simple - 3965.727783M pixels/sec
PS 1.4 - Simple - 3964.726074M pixels/sec
PS 2.0 - Simple - 3965.047363M pixels/sec
PS 2.0 PP - Simple - 3964.977051M pixels/sec
PS 2.0 - Longer - 2033.613403M pixels/sec
PS 2.0 PP - Longer - 2033.564941M pixels/sec
PS 2.0 - Longer 4 Registers - 2033.656006M pixels/sec
PS 2.0 PP - Longer 4 Registers - 2033.575806M pixels/sec
PS 2.0 - Per Pixel Lighting - 585.837585M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 585.832458M pixels/sec
i miei risultati sono più sopra inquesta pagina, grazie comunque;)
BTinside
11-12-2004, 14:29
Circe nei primi sei valori ti do le botte con la 6800Gt@Ultra, invece in tutti gli altri, ovvero con Pixel shader mi batti tu. Però strano che ottengo valori di fillrate superiori ad una X800XT PE.
L'ideale serebbe conforntarmi con una X800XT, la reale concorrente della 6800Ultra, la PE fu fatta da Ati solo dopo aver visto che la 6800Ultra teneva tranquillamente testa alla normale X800XT, Nvidia però non ha ancora risposto con la 6800Ultra extreme.
Circe che ne diresti di downclokkare a 500:D , scherzo
ecco qui il mio e il tuo test
--------------------------
Display adapter: Gainward GeForce 6800 GT@Ultra (400/1100)
Driver version: 6.14.10.6702
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 5922.908203M pixels/sec
FFP - Z pixel rate - 10599.741211M pixels/sec
FFP - Single texture - 3530.028564M pixels/sec
FFP - Dual texture - 2352.800537M pixels/sec
FFP - Triple texture - 1716.273804M pixels/sec
FFP - Quad texture - 1288.487061M pixels/sec
PS 1.1 - Simple - 2961.478516M pixels/sec
PS 1.4 - Simple - 2945.014404M pixels/sec
PS 2.0 - Simple - 2954.542725M pixels/sec
PS 2.0 PP - Simple - 2958.227051M pixels/sec
PS 2.0 - Longer - 1565.437988M pixels/sec
PS 2.0 PP - Longer - 1567.082031M pixels/sec
PS 2.0 - Longer 4 Registers - 1567.414551M pixels/sec
PS 2.0 PP - Longer 4 Registers - 1564.583862M pixels/sec
PS 2.0 - Per Pixel Lighting - 440.822662M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 685.492126M pixels/sec
------------------------------------------------------------------------------------
eccoti il test a 520/560, fammi sapere i tuoi risultati
Fillrate Tester
--------------------------
Display adapter: RADEON X800 XT Platinum Edition
Driver version: 6.14.10.6490
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 5626.375977M pixels/sec
FFP - Z pixel rate - 7375.786133M pixels/sec
FFP - Single texture - 3207.737305M pixels/sec
FFP - Dual texture - 1776.733276M pixels/sec
FFP - Triple texture - 1216.183594M pixels/sec
FFP - Quad texture - 741.293396M pixels/sec
PS 1.1 - Simple - 3965.727783M pixels/sec
PS 1.4 - Simple - 3964.726074M pixels/sec
PS 2.0 - Simple - 3965.047363M pixels/sec
PS 2.0 PP - Simple - 3964.977051M pixels/sec
PS 2.0 - Longer - 2033.613403M pixels/sec
PS 2.0 PP - Longer - 2033.564941M pixels/sec
PS 2.0 - Longer 4 Registers - 2033.656006M pixels/sec
PS 2.0 PP - Longer 4 Registers - 2033.575806M pixels/sec
PS 2.0 - Per Pixel Lighting - 585.837585M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 585.832458M pixels/sec
:sofico:
rimane comunque che nv40 e r420 siano architetture riuscite entrambe piuttosto bene.
comunque i confronti veri sarebbe opportuni farli sul campo vero e propio, e non in questi test
yossarian
11-12-2004, 15:18
Originariamente inviato da crice
:sofico:
rimane comunque che nv40 e r420 siano architetture riuscite entrambe piuttosto bene.
comunque i confronti veri sarebbe opportuni farli sul campo vero e propio, e non in questi test
"sul campo" ci sono alcuni problemi che possono essere "mascherati" dai drivers, come avvanuto con la serie NV3x e lo sm2.x; problemi che questo test, invece, permette di evidenziare.
Ad esempio, l'osservazione di BTinside sulla superiorità dell'NV40 nel fillrate (lo z-pixel fillrate non fa testo perchè li sappiamo che i chip NV riescono a raddoppiare l'otput e sono, di conseguenza, molto più veloci) e nelle operazioni di texturing, non è sbagliata. La serie R3x0 e la serie R420 mostrano, da sempre, prestazioni molto al di sotto di quelle che sono le stime teoriche che derivano dai calcoli basati sul numero delle pipeline e sulla frequenza. Questo vuol dire che, in questi test, non si mostrano molto efficienti. Al contrario, i chip NV mostrano una buona efficienz proprio in questo tipo di operazioni. Nel "pure" fillrate, NV40 fa il suo dovere; è la X800XT pe che è molto distante dal suo valore teorico (8320 Mpixels/sec). Negli altri test, invece, l'efficienza dei due chip è la stessa e la differenza è data dalla superiore frequenza dell'R420. Quindi, complessivamente, questo test mostra che l'architettura superscalare di NV40 è, nella peggiore delle ipotesi, efficiente quanto la 3+1 dell'R420.
Ovvio che poi, nelle applicazioni che obbligano all'utilizzo conteporaneo di alu e tmu, viene fuori l'handicap dell'NV40 dovuto alla dipendenza dei due tipi di unità di calcolo (vedi HL2).
Questo e altri test sintetici danno la possibilità di indagare abbastanza a fondo sulle architetture dei vari chip, permettendo di studiarne punti deboli e forti. Ad esempio, nel test del pure fillrate emerge uno dei pochi punti deboli di quella che è stata una delle architetture più riuscite della storia dei chip grafici di tipo consumer (quella dell'R300, ripresa e potenziata con R420)
BTinside
11-12-2004, 15:27
Originariamente inviato da crice
:sofico:
rimane comunque che nv40 e r420 siano architetture riuscite entrambe piuttosto bene.
comunque i confronti veri sarebbe opportuni farli sul campo vero e propio, e non in questi test
Vabè per questo sul web trovi decine di benchmarks e recensioni
BTinside
11-12-2004, 15:29
Originariamente inviato da yossarian
"sul campo" ci sono alcuni problemi che possono essere "mascherati" dai drivers, come avvanuto con la serie NV3x e lo sm2.x; problemi che questo test, invece, permette di evidenziare.
Ad esempio, l'osservazione di BTinside sulla superiorità dell'NV40 nel fillrate (lo z-pixel fillrate non fa testo perchè li sappiamo che i chip NV riescono a raddoppiare l'otput e sono, di conseguenza, molto più veloci) e nelle operazioni di texturing, non è sbagliata. La serie R3x0 e la serie R420 mostrano, da sempre, prestazioni molto al di sotto di quelle che sono le stime teoriche che derivano dai calcoli basati sul numero delle pipeline e sulla frequenza. Questo vuol dire che, in questi test, non si mostrano molto efficienti. Al contrario, i chip NV mostrano una buona efficienz proprio in questo tipo di operazioni. Nel "pure" fillrate, NV40 fa il suo dovere; è la X800XT pe che è molto distante dal suo valore teorico (8320 Mpixels/sec). Negli altri test, invece, l'efficienza dei due chip è la stessa e la differenza è data dalla superiore frequenza dell'R420. Quindi, complessivamente, questo test mostra che l'architettura superscalare di NV40 è, nella peggiore delle ipotesi, efficiente quanto la 3+1 dell'R420.
Ovvio che poi, nelle applicazioni che obbligano all'utilizzo conteporaneo di alu e tmu, viene fuori l'handicap dell'NV40 dovuto alla dipendenza dei due tipi di unità di calcolo (vedi HL2).
Questo e altri test sintetici danno la possibilità di indagare abbastanza a fondo sulle architetture dei vari chip, permettendo di studiarne punti deboli e forti. Ad esempio, nel test del pure fillrate emerge uno dei pochi punti deboli di quella che è stata una delle architetture più riuscite della storia dei chip grafici di tipo consumer (quella dell'R300, ripresa e potenziata con R420)
Come si fa a non quotare questo ragazzo:D,
quelli elencati da Yossarian sono i motivi che mi hanno spinto a passare da R300 a NV40.
Praticamente diciamo che con NV40, data l'efficienza di questo chip con architettua superscalare, nvidia potrebbe permettersi di starsene tranquilla per un po' , limitandosi al solo innalzamento delle frequenze al passare del tempo.
Ovvio che poi, nelle applicazioni che obbligano all'utilizzo conteporaneo di alu e tmu, viene fuori l'handicap dell'NV40 dovuto alla dipendenza dei due tipi di unità di calcolo (vedi HL2).
Vabè come tu ci hai ben spiegato in altri 3ad sembra che valve abbia fatto il possibile, nello sviluppo di half life 2, per massimizzare questo handicap della dipendenza fra ALU e TMU di NV40, unico handicap ereditato da NV3X
Originariamente inviato da yossarian
"sul campo" ci sono alcuni problemi che possono essere "mascherati" dai drivers, come avvanuto con la serie NV3x e lo sm2.x; problemi che questo test, invece, permette di evidenziare.
Ad esempio, l'osservazione di BTinside sulla superiorità dell'NV40 nel fillrate (lo z-pixel fillrate non fa testo perchè li sappiamo che i chip NV riescono a raddoppiare l'otput e sono, di conseguenza, molto più veloci) e nelle operazioni di texturing, non è sbagliata. La serie R3x0 e la serie R420 mostrano, da sempre, prestazioni molto al di sotto di quelle che sono le stime teoriche che derivano dai calcoli basati sul numero delle pipeline e sulla frequenza. Questo vuol dire che, in questi test, non si mostrano molto efficienti. Al contrario, i chip NV mostrano una buona efficienz proprio in questo tipo di operazioni. Nel "pure" fillrate, NV40 fa il suo dovere; è la X800XT pe che è molto distante dal suo valore teorico (8320 Mpixels/sec). Negli altri test, invece, l'efficienza dei due chip è la stessa e la differenza è data dalla superiore frequenza dell'R420. Quindi, complessivamente, questo test mostra che l'architettura superscalare di NV40 è, nella peggiore delle ipotesi, efficiente quanto la 3+1 dell'R420.
Ovvio che poi, nelle applicazioni che obbligano all'utilizzo conteporaneo di alu e tmu, viene fuori l'handicap dell'NV40 dovuto alla dipendenza dei due tipi di unità di calcolo (vedi HL2).
Questo e altri test sintetici danno la possibilità di indagare abbastanza a fondo sulle architetture dei vari chip, permettendo di studiarne punti deboli e forti. Ad esempio, nel test del pure fillrate emerge uno dei pochi punti deboli di quella che è stata una delle architetture più riuscite della storia dei chip grafici di tipo consumer (quella dell'R300, ripresa e potenziata con R420)
Infatti i chip Nvidia sono sempre stati eccellenti nelle operazioni di texturing, basta vedere come gira UT2003 (un gioco con texture grandi e molto diverse una dall'altra) su una GF4Ti... davvero non male! ;)
BTinside
11-12-2004, 20:07
Originariamente inviato da shodan
Infatti i chip Nvidia sono sempre stati eccellenti nelle operazioni di texturing, basta vedere come gira UT2003 (un gioco con texture grandi e molto diverse una dall'altra) su una GF4Ti... davvero non male! ;)
Sarebbe mooolto interessante che qualke possessore di Xgi Volari Duo V8 Ultra facesse questo test e lo postasse. Se ciò che Xgi mette su carta è veritiero, e cioè un fillrate di 6000 e passa m/textel dovuto al bi-processore, dovremmo avere valori di fillrate simili a quelli delle 6800 e X800.
Domanda a yoss: la versione dei driver e la potenza della CPU influiscono sulla resa dell vga in questo test? oppure il test calcola la capacità massima teorica indipendentemente da quale driver sia a supporto della scheda e senza l'ausilio della CPU?
Vabè come tu ci hai ben spiegato in altri 3ad sembra che valve abbia fatto il possibile, nello sviluppo di half life 2, per massimizzare questo handicap della dipendenza fra ALU e TMU di NV40, unico handicap ereditato da NV3X
se la mettiamo in questi termini possiamo dire lo stesso di doom3, allora,e finiremmo nel solito circolo vizioso...
BTinside
12-12-2004, 01:51
Originariamente inviato da crice
se la mettiamo in questi termini possiamo dire lo stesso di doom3, allora,e finiremmo nel solito circolo vizioso...
Certo che si può dire lo stesso per Doom3, la Id software ha ottimizzato il codice del gioco per tutte quelle feature di NV che alla fine fanno produrre un fill rate pressocchè doppio rispetto alle concorrenti Ati, cosa che pone in vantaggio le soluzioni NV40 su R420 e più o meno sullo stesso piano R300 e NV3X,
come per esempio dependent texture read, shadow buffer, massimo sfruttamento della capacità delle ROP's nVIDIA di produrre un output raddoppiato in presenza di sole z-oops.
Aiuta anche l'Ultrashadow II di NV40.
Originariamente inviato da yossarian
"sul campo" ci sono alcuni problemi che possono essere "mascherati" dai drivers, come avvanuto con la serie NV3x e lo sm2.x; problemi che questo test, invece, permette di evidenziare.
Ad esempio, l'osservazione di BTinside sulla superiorità dell'NV40 nel fillrate (lo z-pixel fillrate non fa testo perchè li sappiamo che i chip NV riescono a raddoppiare l'otput e sono, di conseguenza, molto più veloci) e nelle operazioni di texturing, non è sbagliata. La serie R3x0 e la serie R420 mostrano, da sempre, prestazioni molto al di sotto di quelle che sono le stime teoriche che derivano dai calcoli basati sul numero delle pipeline e sulla frequenza. Questo vuol dire che, in questi test, non si mostrano molto efficienti. Al contrario, i chip NV mostrano una buona efficienz proprio in questo tipo di operazioni. Nel "pure" fillrate, NV40 fa il suo dovere; è la X800XT pe che è molto distante dal suo valore teorico (8320 Mpixels/sec). Negli altri test, invece, l'efficienza dei due chip è la stessa e la differenza è data dalla superiore frequenza dell'R420. Quindi, complessivamente, questo test mostra che l'architettura superscalare di NV40 è, nella peggiore delle ipotesi, efficiente quanto la 3+1 dell'R420.
Ovvio che poi, nelle applicazioni che obbligano all'utilizzo conteporaneo di alu e tmu, viene fuori l'handicap dell'NV40 dovuto alla dipendenza dei due tipi di unità di calcolo (vedi HL2).
Questo e altri test sintetici danno la possibilità di indagare abbastanza a fondo sulle architetture dei vari chip, permettendo di studiarne punti deboli e forti. Ad esempio, nel test del pure fillrate emerge uno dei pochi punti deboli di quella che è stata una delle architetture più riuscite della storia dei chip grafici di tipo consumer (quella dell'R300, ripresa e potenziata con R420)
Ciao Yossarian,
ti riquoto perchè voglio farti una domanda: non ti sembra strano che per R300/R420 il textel rate sia pressocchè uguale sia con 1 texture che con 4?
Se non sbaglio in genere, in regime di multitexturing, il textel rate (che ricordo essere calcolabile moltiplicando il pixel rate per il numero di layer di texture, giusto?) dovrebbe avvicinarsi parecchio al massimo teorico, dato che sia gli accessi alla RAM video sia i possibili stalli alla fine della pipeline dovute alla mancanza di un'architettura crossbar tra pipeline e rops dovrebbe essere minimizzata dall'accresciuto tempo elaborativo del singolo pixel (che deve essere ricoperto da ben 4 texture).
Nei test sintetici che ho visto fin'ora (tipo 3DMark) infatto il fill rate in multi-texture di R420 è davvero elevatissimo, mentre valori di fill rate in single texture non proprio brillantissimi...
Ciao grazie! :)
Originariamente inviato da BTinside
Sarebbe mooolto interessante che qualke possessore di Xgi Volari Duo V8 Ultra facesse questo test e lo postasse. Se ciò che Xgi mette su carta è veritiero, e cioè un fillrate di 6000 e passa m/textel dovuto al bi-processore, dovremmo avere valori di fillrate simili a quelli delle 6800 e X800.
Domanda a yoss: la versione dei driver e la potenza della CPU influiscono sulla resa dell vga in questo test? oppure il test calcola la capacità massima teorica indipendentemente da quale driver sia a supporto della scheda e senza l'ausilio della CPU?
Ciao, al link sotto trovi qualche test interessante di un Volari V8 Duo Ultra:
http://www.xbitlabs.com/articles/video/display/xgi-volari_10.html
Non so se il programma di test è lo stesso (sinceramente non credo), inoltre i driver usati sono molto vecchi (la recensione risale a gennaio 2004) ma credo che si possa comunque trarre un'idea delle caratteristiche (positive e negative) della scheda.
Ciao.
yossarian
12-12-2004, 02:23
Originariamente inviato da BTinside
Sarebbe mooolto interessante che qualke possessore di Xgi Volari Duo V8 Ultra facesse questo test e lo postasse. Se ciò che Xgi mette su carta è veritiero, e cioè un fillrate di 6000 e passa m/textel dovuto al bi-processore, dovremmo avere valori di fillrate simili a quelli delle 6800 e X800.
Domanda a yoss: la versione dei driver e la potenza della CPU influiscono sulla resa dell vga in questo test? oppure il test calcola la capacità massima teorica indipendentemente da quale driver sia a supporto della scheda e senza l'ausilio della CPU?
la potenza della cpu è del tutto indifferente; la versione dei drivers può, in parte influenzare il test, ma in maniera molto particolare; ti faccio un esempio pratico: all'uscita della 5900 ultra, B3D ha fatto una recensione (di cui ho postato il link per farvi scaricare il test), in cui, con fp32 la 5800 ultra andava, apparentemente, meglio della 5900 ultra. La cosa anomala, che saltava subito all'occhio, era che passando da fp16 a fp32 la 5900 ultra vedeva dimezzato il framerate, mentre quello della 5800 u restava costante. La domanda ovvia potrebbe sembrare: perchè nVIDIA ha prodotto la 5900 se la 5800 va meglio? La risposta, con un po' di ragionamento (ed eventualmente l'ausilio di un altro bench che permette di calcolare la precisioni con cui lavorano i ps) era: i drivers con la 5800 forzavano tutto in fp16, mentre con la 5900 abilitavano fp32.
Questo è un esempio di come i drivers possano incidere sul test, ma anche di come il test stesso permetta di scoprire il trucco. Il programma che permette il calcolo della precisione dei ps dovrebbe trovarsi nella stessa pagina linkata.
In altri casi, l'intervento dei drivers può ottimizzare qualche funzionalità del chip, permettendo il miglioramento di qualche valore (ad esempio la parte lecita del compilatore NV ha permesso, rispetto ai primi test eseguiti, di far guadagnare qualche punto alle fx, soprattutto in fp16 e, in particolare, alla serie derivata da NV35)
BTinside
12-12-2004, 02:36
Originariamente inviato da yossarian
la potenza della cpu è del tutto indifferente; la versione dei drivers può, in parte influenzare il test, ma in maniera molto particolare; ti faccio un esempio pratico: all'uscita della 5900 ultra, B3D ha fatto una recensione (di cui ho postato il link per farvi scaricare il test), in cui, con fp32 la 5800 ultra andava, apparentemente, meglio della 5900 ultra. La cosa anomala, che saltava subito all'occhio, era che passando da fp16 a fp32 la 5900 ultra vedeva dimezzato il framerate, mentre quello della 5800 u restava costante. La domanda ovvia potrebbe sembrare: perchè nVIDIA ha prodotto la 5900 se la 5800 va meglio? La risposta, con un po' di ragionamento (ed eventualmente l'ausilio di un altro bench che permette di calcolare la precisioni con cui lavorano i ps) era: i drivers con la 5800 forzavano tutto in fp16, mentre con la 5900 abilitavano fp32.
Questo è un esempio di come i drivers possano incidere sul test, ma anche di come il test stesso permetta di scoprire il trucco. Il programma che permette il calcolo della precisione dei ps dovrebbe trovarsi nella stessa pagina linkata.
In altri casi, l'intervento dei drivers può ottimizzare qualche funzionalità del chip, permettendo il miglioramento di qualche valore (ad esempio la parte lecita del compilatore NV ha permesso, rispetto ai primi test eseguiti, di far guadagnare qualche punto alle fx, soprattutto in fp16 e, in particolare, alla serie derivata da NV35)
Grazie, sempre esauriente;)
PS: sai se questo Marc Dolen'c Test che stiamo facendo è stato mai fatto su Volari Duo V8 Ultra, se si dove che vado a guardare?
yossarian
12-12-2004, 02:39
Originariamente inviato da shodan
Ciao Yossarian,
ti riquoto perchè voglio farti una domanda: non ti sembra strano che per R300/R420 il textel rate sia pressocchè uguale sia con 1 texture che con 4?
Se non sbaglio in genere, in regime di multitexturing, il textel rate (che ricordo essere calcolabile moltiplicando il pixel rate per il numero di layer di texture, giusto?) dovrebbe avvicinarsi parecchio al massimo teorico, dato che sia gli accessi alla RAM video sia i possibili stalli alla fine della pipeline dovute alla mancanza di un'architettura crossbar tra pipeline e rops dovrebbe essere minimizzata dall'accresciuto tempo elaborativo del singolo pixel (che deve essere ricoperto da ben 4 texture).
Nei test sintetici che ho visto fin'ora (tipo 3DMark) infatto il fill rate in multi-texture di R420 è davvero elevatissimo, mentre valori di fill rate in single texture non proprio brillantissimi...
Ciao grazie! :)
in questo test è calcolato il pixel fillrate e non il texel fillrate e i valori con 4 texture sono molto più bassi di quelli con 1; il primo è molto più interessante come parametro, perchè rappresenta l'output reale frutto dell'elaborazione. Mentre il texel fillrate, all'aumentare del numero di layer cresce, poichè i texel successivi al primo necessitano di molti mewno calcoli (ad esmepio tutta la parte geometrica non deve essere ricalcolata) e, inoltre, il processo si svolge tutto "on chip", il pixel fillrate cala, perchè, per elaborare ogni pixel, più texel si applicano più tempo ci vuole; quindi il risultato è che sono prodotti, in un secondo, sempre meno pixel, ognuno, però, sempre più "ricco" di texel
Fillrate Tester
--------------------------
Display adapter: GeXCube RADEON 9600XT Game Buster
Driver version: 6.14.10.6490
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D16_LOCKABLE
--------------------------
FFP - Pure fillrate - 1274.505493M pixels/sec
FFP - Z pixel rate - 1913.672485M pixels/sec
FFP - Single texture - 1103.490356M pixels/sec
FFP - Dual texture - 668.871826M pixels/sec
FFP - Triple texture - 484.283783M pixels/sec
FFP - Quad texture - 226.612518M pixels/sec
PS 1.1 - Simple - 978.171814M pixels/sec
PS 1.4 - Simple - 978.186768M pixels/sec
PS 2.0 - Simple - 978.034363M pixels/sec
PS 2.0 PP - Simple - 978.023315M pixels/sec
PS 2.0 - Longer - 493.423492M pixels/sec
PS 2.0 PP - Longer - 493.405060M pixels/sec
PS 2.0 - Longer 4 Registers - 493.515961M pixels/sec
PS 2.0 PP - Longer 4 Registers - 493.502808M pixels/sec
PS 2.0 - Per Pixel Lighting - 141.508850M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 141.507965M pixels/sec
--------------------------
Display adapter: GeXCube RADEON 9600XT Game Buster
Driver version: 6.14.10.6490
Display mode: 1024x768 A8R8G8B8 60Hz
Z-Buffer format: D16_LOCKABLE
--------------------------
FFP - Pure fillrate - 1279.593384M pixels/sec
FFP - Z pixel rate - 1912.306152M pixels/sec
FFP - Single texture - 1257.020142M pixels/sec
FFP - Dual texture - 787.261902M pixels/sec
FFP - Triple texture - 419.502197M pixels/sec
FFP - Quad texture - 319.190826M pixels/sec
PS 1.1 - Simple - 981.030762M pixels/sec
PS 1.4 - Simple - 981.244202M pixels/sec
PS 2.0 - Simple - 981.010986M pixels/sec
PS 2.0 PP - Simple - 981.064880M pixels/sec
PS 2.0 - Longer - 494.530579M pixels/sec
PS 2.0 PP - Longer - 494.541534M pixels/sec
PS 2.0 - Longer 4 Registers - 494.530762M pixels/sec
PS 2.0 PP - Longer 4 Registers - 494.530762M pixels/sec
PS 2.0 - Per Pixel Lighting - 141.781998M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 141.781097M pixels/sec
...ecco i risultati di una 9600XT con frequenze default.
...ciao!
yossarian
12-12-2004, 02:46
Originariamente inviato da BTinside
Grazie, sempre esauriente;)
PS: sai se questo Marc Dolen'c Testi che stiamo facendo è stato mai fatto su Volarri Duo V8 Ultra, se si dove che vado a guardare?
non credo; gli unici che lo utilizzano sono quelli di B3D: se esiste una review fatta da B3D sulla Volari sicuramente è stato fatto il test, altrimenti è molto difficile.
Comunque la Volari ha dato origine ad una serie di equivoci. Il singolo chip ha 8 pipeline, però le unità di calcolo sono dimezzate: questo spiega i valori non elevati (altro limite è l'ampiezza del collegamento tra i due chip). Il numero di operazioni che il chip è in grado di compiere per ogni ciclo di clock, quindi, non è pari a 8 ma a 4
Originariamente inviato da yossarian
in questo test è calcolato il pixel fillrate e non il texel fillrate e i valori con 4 texture sono molto più bassi di quelli con 1; il primo è molto più interessante come parametro, perchè rappresenta l'output reale frutto dell'elaborazione. Mentre il texel fillrate, all'aumentare del numero di layer cresce, poichè i texel successivi al primo necessitano di molti mewno calcoli (ad esmepio tutta la parte geometrica non deve essere ricalcolata) e, inoltre, il processo si svolge tutto "on chip", il pixel fillrate cala, perchè, per elaborare ogni pixel, più texel si applicano più tempo ci vuole; quindi il risultato è che sono prodotti, in un secondo, sempre meno pixel, ognuno, però, sempre più "ricco" di texel
Ciao,
per calcolare il textel fill-rate basta moltiplicare il numero di pixel/sec. per il numero di layer di texture utilizzate, giusto?
In questo caso, se guardi i valori ottenuni con 4 texture noterai che il pixel fill rate si riduce a 1/4 di quello ottenuto con una sola texture, e di conseguenza il texture rate non cresce. Dato che come indichi anche tu è il primo textel a richiedere la maggior parte della potenza elaborativa, come mai al crescere del numero di layer il pixel rate cala in modo proporzionale? Non dovrebbe scendere in modo più soffice, dato che il numero di textel/sec aumenta?
Mi sono spiegato da cane... spero il post sia almeno lontanamente comprensibile! :D
Ciao grazie.
Originariamente inviato da BTinside
Grazie, sempre esauriente;)
PS: sai se questo Marc Dolen'c Test che stiamo facendo è stato mai fatto su Volari Duo V8 Ultra, se si dove che vado a guardare?
Hai dato un'occhiata al link postato sopra? ;)
BTinside
12-12-2004, 03:29
Originariamente inviato da shodan
Hai dato un'occhiata al link postato sopra? ;)
Si , grazie;)
yossarian
12-12-2004, 15:16
Originariamente inviato da shodan
Ciao,
per calcolare il textel fill-rate basta moltiplicare il numero di pixel/sec. per il numero di layer di texture utilizzate, giusto?
In questo caso, se guardi i valori ottenuni con 4 texture noterai che il pixel fill rate si riduce a 1/4 di quello ottenuto con una sola texture, e di conseguenza il texture rate non cresce. Dato che come indichi anche tu è il primo textel a richiedere la maggior parte della potenza elaborativa, come mai al crescere del numero di layer il pixel rate cala in modo proporzionale? Non dovrebbe scendere in modo più soffice, dato che il numero di textel/sec aumenta?
Mi sono spiegato da cane... spero il post sia almeno lontanamente comprensibile! :D
Ciao grazie.
adesso ho afferrato il senso del tuo post precedente. Quello che hai appena citato (il paragone tra il Dolenc's test e il 3DMark) è un esempio di come, a volte, i numeri possano fuorviare. Se analizzi i risultati del 3DMark, ti rendi conto che il criterio computazionale adottato è del tutto differente. Mentre il Dolenc's test fa riferimento all'effettivo pixel fillrate, il 3DMark fa riferimento ad un texel fillrate "equivalente"; perchè dico "equivalente"? E' evidente che, nel caso di multitexturing (che nel 3DMark vuol dire semplicemente applicazione di 2 texel per pixel), il texel fillrate non è immediatamente riconvertibile nel pixel fillrate. L'operazione che verrebbe immediata è quella di prendere il texel fillrate, dividere per due (connsoderando che per ogni pixel sono applicati due texel) e considerare il risultato come quello relativo al pixel fillrate. Questo porta, nel caso da te citato relativo all'R420, a risultati sballati: infatti risulta che applicando 2 texel per pixel, quindi aumentando il carico di lavoro delle pipeline, il pixel fillrate aumenti. Quella che va, invece considerata, è l'efficienza relativa in caso di single e di multitexturing. Facendo un calcolo del genere, viene fuori che i risultati dei due test sono molto vicini, poichè danno un incremento, nell'efficienza delle operazioni di texturing, attorno al 15-16% per il 3DMark e al 12-13% per il Dolenc's fillrate test, nel passaggio da 1 a 2 texel per pixel.
Il calo che ti sembra elevato, in realtà è fisiologico; nel passaggio da 1 a 4 texel il calo medio della X800XT pe si attesta intorno ad un 38% (contro il 28% della 6800 Ultra) che è ben lontano da quello che si avrebbe se fosse necessario ricalcolare tutti i dati relativi alla prima elaborazione.
Infine, cosa che no ho però verificato di persona, sia su B3D che su x-bit labs, si considerano i risultati del fillrate test del 3DMark solo in parte attendibile e validi soprattutto per stime di tipo qualitativo (e piuttosto grossolane) perchè, a lro rire, sarebbe un test bandwidth limited.
Ciao;) vi può interessare questo come comparazione nv30/r360 ?
Sono i valori delle SV del Pc2 e Pc1 con i nuovi driver nvidia/ati
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce FX 5800 Ultra
Driver version: 6.14.10.7090
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 1015.434937M pixels/sec
FFP - Z pixel rate - 3676.880859M pixels/sec
FFP - Single texture - 1412.016235M pixels/sec
FFP - Dual texture - 1070.458496M pixels/sec
FFP - Triple texture - 624.299988M pixels/sec
FFP - Quad texture - 467.652618M pixels/sec
PS 1.1 - Simple - 1067.395386M pixels/sec
PS 1.4 - Simple - 1011.502563M pixels/sec
PS 2.0 - Simple - 685.421997M pixels/sec
PS 2.0 PP - Simple - 685.449890M pixels/sec
PS 2.0 - Longer - 416.221741M pixels/sec
PS 2.0 PP - Longer - 416.232788M pixels/sec
PS 2.0 - Longer 4 Registers - 336.675598M pixels/sec
PS 2.0 PP - Longer 4 Registers - 415.649078M pixels/sec
PS 2.0 - Per Pixel Lighting - 66.429321M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 78.880753M pixels/sec
Fillrate Tester
--------------------------
Display adapter: RADEON 9800 XT
Driver version: 6.14.10.6497
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 2752.633057M pixels/sec
FFP - Z pixel rate - 2848.968018M pixels/sec
FFP - Single texture - 1696.900757M pixels/sec
FFP - Dual texture - 818.008362M pixels/sec
FFP - Triple texture - 573.215393M pixels/sec
FFP - Quad texture - 422.025635M pixels/sec
PS 1.1 - Simple - 1612.161133M pixels/sec
PS 1.4 - Simple - 1612.156128M pixels/sec
PS 2.0 - Simple - 1612.165894M pixels/sec
PS 2.0 PP - Simple - 1612.166748M pixels/sec
PS 2.0 - Longer - 812.332703M pixels/sec
PS 2.0 PP - Longer - 812.333618M pixels/sec
PS 2.0 - Longer 4 Registers - 812.331055M pixels/sec
PS 2.0 PP - Longer 4 Registers - 812.330383M pixels/sec
PS 2.0 - Per Pixel Lighting - 233.042892M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 233.042816M pixels/sec
yossarian
12-12-2004, 15:26
Originariamente inviato da ant72
Ciao;) vi può interessare questo come comparazione nv30/r360 ?
Sono i valori delle SV del Pc2 e Pc1 con i nuovi driver nvidia/ati
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce FX 5800 Ultra
Driver version: 6.14.10.7090
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 1015.434937M pixels/sec
FFP - Z pixel rate - 3676.880859M pixels/sec
FFP - Single texture - 1412.016235M pixels/sec
FFP - Dual texture - 1070.458496M pixels/sec
FFP - Triple texture - 624.299988M pixels/sec
FFP - Quad texture - 467.652618M pixels/sec
PS 1.1 - Simple - 1067.395386M pixels/sec
PS 1.4 - Simple - 1011.502563M pixels/sec
PS 2.0 - Simple - 685.421997M pixels/sec
PS 2.0 PP - Simple - 685.449890M pixels/sec
PS 2.0 - Longer - 416.221741M pixels/sec
PS 2.0 PP - Longer - 416.232788M pixels/sec
PS 2.0 - Longer 4 Registers - 336.675598M pixels/sec
PS 2.0 PP - Longer 4 Registers - 415.649078M pixels/sec
PS 2.0 - Per Pixel Lighting - 66.429321M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 78.880753M pixels/sec
Fillrate Tester
--------------------------
Display adapter: RADEON 9800 XT
Driver version: 6.14.10.6497
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 2752.633057M pixels/sec
FFP - Z pixel rate - 2848.968018M pixels/sec
FFP - Single texture - 1696.900757M pixels/sec
FFP - Dual texture - 818.008362M pixels/sec
FFP - Triple texture - 573.215393M pixels/sec
FFP - Quad texture - 422.025635M pixels/sec
PS 1.1 - Simple - 1612.161133M pixels/sec
PS 1.4 - Simple - 1612.156128M pixels/sec
PS 2.0 - Simple - 1612.165894M pixels/sec
PS 2.0 PP - Simple - 1612.166748M pixels/sec
PS 2.0 - Longer - 812.332703M pixels/sec
PS 2.0 PP - Longer - 812.333618M pixels/sec
PS 2.0 - Longer 4 Registers - 812.331055M pixels/sec
PS 2.0 PP - Longer 4 Registers - 812.330383M pixels/sec
PS 2.0 - Per Pixel Lighting - 233.042892M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 233.042816M pixels/sec
c'è qualcosa che non torna nei test con ps2.0; è forzata sempre la fp16 anche con i ps2.0 simple. Evidentemente con la serie NV30 i drivers continuano a fare shader replacement.
Dark Schneider
12-12-2004, 16:15
Originariamente inviato da BTinside
Certo che si può dire lo stesso per Doom3, la Id software ha ottimizzato il codice del gioco per tutte quelle feature di NV che alla fine fanno produrre un fill rate pressocchè doppio rispetto alle concorrenti Ati, cosa che pone in vantaggio le soluzioni NV40 su R420 e più o meno sullo stesso piano R300 e NV3X,
come per esempio dependent texture read, shadow buffer, massimo sfruttamento della capacità delle ROP's nVIDIA di produrre un output raddoppiato in presenza di sole z-oops.
Aiuta anche l'Ultrashadow II di NV40.
La features che fa si che NV4x/3x raddoppi il proprio fillrate tra l'altro è stata publicizzata un po' da nVidia già da diverso tempo prima che Doom 3 uscisse, precisando che sarebbe stata sfruttata nel titolo ID. :)
IMHO è una features interressantissima. :)
p.s. adesso che ho un po' di tempo faccio anchio sto test va :)
Dark Schneider
12-12-2004, 16:33
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce 6800 GT
Driver version: 6.14.10.6702
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 5287.608398M pixels/sec
FFP - Z pixel rate - 9459.811523M pixels/sec
FFP - Single texture - 3234.010498M pixels/sec
FFP - Dual texture - 2204.121094M pixels/sec
FFP - Triple texture - 1528.635864M pixels/sec
FFP - Quad texture - 1157.284180M pixels/sec
PS 1.1 - Simple - 2645.262939M pixels/sec
PS 1.4 - Simple - 2644.984863M pixels/sec
PS 2.0 - Simple - 2645.881592M pixels/sec
PS 2.0 PP - Simple - 2645.378174M pixels/sec
PS 2.0 - Longer - 1370.839355M pixels/sec
PS 2.0 PP - Longer - 1370.957397M pixels/sec
PS 2.0 - Longer 4 Registers - 1371.527954M pixels/sec
PS 2.0 PP - Longer 4 Registers - 1370.823242M pixels/sec
PS 2.0 - Per Pixel Lighting - 391.815552M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 587.742065M pixels/sec
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce 6800 GT
Driver version: 6.14.10.6702
Display mode: 1024x768 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 5445.960938M pixels/sec
FFP - Z pixel rate - 10514.918945M pixels/sec
FFP - Single texture - 5398.083008M pixels/sec
FFP - Dual texture - 2744.056396M pixels/sec
FFP - Triple texture - 1832.508667M pixels/sec
FFP - Quad texture - 1365.199951M pixels/sec
PS 1.1 - Simple - 2753.656006M pixels/sec
PS 1.4 - Simple - 2752.208008M pixels/sec
PS 2.0 - Simple - 2752.965088M pixels/sec
PS 2.0 PP - Simple - 2753.247314M pixels/sec
PS 2.0 - Longer - 1383.858521M pixels/sec
PS 2.0 PP - Longer - 1383.512207M pixels/sec
PS 2.0 - Longer 4 Registers - 1383.438232M pixels/sec
PS 2.0 PP - Longer 4 Registers - 1383.830566M pixels/sec
PS 2.0 - Per Pixel Lighting - 396.844208M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 616.001038M pixels/sec
Test eseguito con la 6800 GT DEFAULT. :)
BTinside
12-12-2004, 18:38
Originariamente inviato da Dark Schneider
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce 6800 GT
Driver version: 6.14.10.6702
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 5287.608398M pixels/sec
FFP - Z pixel rate - 9459.811523M pixels/sec
FFP - Single texture - 3234.010498M pixels/sec
FFP - Dual texture - 2204.121094M pixels/sec
FFP - Triple texture - 1528.635864M pixels/sec
FFP - Quad texture - 1157.284180M pixels/sec
PS 1.1 - Simple - 2645.262939M pixels/sec
PS 1.4 - Simple - 2644.984863M pixels/sec
PS 2.0 - Simple - 2645.881592M pixels/sec
PS 2.0 PP - Simple - 2645.378174M pixels/sec
PS 2.0 - Longer - 1370.839355M pixels/sec
PS 2.0 PP - Longer - 1370.957397M pixels/sec
PS 2.0 - Longer 4 Registers - 1371.527954M pixels/sec
PS 2.0 PP - Longer 4 Registers - 1370.823242M pixels/sec
PS 2.0 - Per Pixel Lighting - 391.815552M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 587.742065M pixels/sec
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce 6800 GT
Driver version: 6.14.10.6702
Display mode: 1024x768 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 5445.960938M pixels/sec
FFP - Z pixel rate - 10514.918945M pixels/sec
FFP - Single texture - 5398.083008M pixels/sec
FFP - Dual texture - 2744.056396M pixels/sec
FFP - Triple texture - 1832.508667M pixels/sec
FFP - Quad texture - 1365.199951M pixels/sec
PS 1.1 - Simple - 2753.656006M pixels/sec
PS 1.4 - Simple - 2752.208008M pixels/sec
PS 2.0 - Simple - 2752.965088M pixels/sec
PS 2.0 PP - Simple - 2753.247314M pixels/sec
PS 2.0 - Longer - 1383.858521M pixels/sec
PS 2.0 PP - Longer - 1383.512207M pixels/sec
PS 2.0 - Longer 4 Registers - 1383.438232M pixels/sec
PS 2.0 PP - Longer 4 Registers - 1383.830566M pixels/sec
PS 2.0 - Per Pixel Lighting - 396.844208M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 616.001038M pixels/sec
Test eseguito con la 6800 GT DEFAULT. :)
Ottimi valori per essere @default, chissà overclokkando a ultra se ottieni gli stessi miei risultati oppure anche superiori.
Che marca è la tua?
Originariamente inviato da yossarian
adesso ho afferrato il senso del tuo post precedente. Quello che hai appena citato (il paragone tra il Dolenc's test e il 3DMark) è un esempio di come, a volte, i numeri possano fuorviare. Se analizzi i risultati del 3DMark, ti rendi conto che il criterio computazionale adottato è del tutto differente. Mentre il Dolenc's test fa riferimento all'effettivo pixel fillrate, il 3DMark fa riferimento ad un texel fillrate "equivalente"; perchè dico "equivalente"? E' evidente che, nel caso di multitexturing (che nel 3DMark vuol dire semplicemente applicazione di 2 texel per pixel), il texel fillrate non è immediatamente riconvertibile nel pixel fillrate. L'operazione che verrebbe immediata è quella di prendere il texel fillrate, dividere per due (connsoderando che per ogni pixel sono applicati due texel) e considerare il risultato come quello relativo al pixel fillrate. Questo porta, nel caso da te citato relativo all'R420, a risultati sballati: infatti risulta che applicando 2 texel per pixel, quindi aumentando il carico di lavoro delle pipeline, il pixel fillrate aumenti. Quella che va, invece considerata, è l'efficienza relativa in caso di single e di multitexturing. Facendo un calcolo del genere, viene fuori che i risultati dei due test sono molto vicini, poichè danno un incremento, nell'efficienza delle operazioni di texturing, attorno al 15-16% per il 3DMark e al 12-13% per il Dolenc's fillrate test, nel passaggio da 1 a 2 texel per pixel.
Il calo che ti sembra elevato, in realtà è fisiologico; nel passaggio da 1 a 4 texel il calo medio della X800XT pe si attesta intorno ad un 38% (contro il 28% della 6800 Ultra) che è ben lontano da quello che si avrebbe se fosse necessario ricalcolare tutti i dati relativi alla prima elaborazione.
Infine, cosa che no ho però verificato di persona, sia su B3D che su x-bit labs, si considerano i risultati del fillrate test del 3DMark solo in parte attendibile e validi soprattutto per stime di tipo qualitativo (e piuttosto grossolane) perchè, a lro rire, sarebbe un test bandwidth limited.
Ciao Yossarian,
grazie per la risposta, ho letto con estremo interesse il tuo post. :)
C'è però ancora qualcosa che non mi torna... vediamo se riesco ad essere "esauriente" :D.
Ho fatto un test del fill rate con 3DMark 2003 e questi sono i risultati ottenuti:
-) single-texture: 1833 Mtextel/sec., che in questo caso corrispondono a 1833 Mpixel (dato che è stata applicata una sola texture per pixel);
-) multi-texture: 3168 Mtextel/sec., che in questo caso corrispondono a 396 Mpixel (dato che sono applicate 8 texture per pixel).
Si nota quindi che, nonostante il drastico calo del pixel rate, l'efficenza complessiva è comunque quasi raddoppiata: in regime di single texture infatti, applicando 8 textel per pixel (facendo quindi 8 passate), il pixel rate dovrebbe scendere a 229 Mpixel, cioè ad 1/8 di quello ottenibile con una sola texture per pixel, mentre facendo tutto in single pass si rimane sui 396 Mpixel (come calcolato sopra).
Questi sono invece i risultati ottenuti con il test in questione:
-) sigle-texture: 1677.936035 Mpixel/sec., che corrispondono a 1677.936035 Mtextel/sec (dato che viene applicata una sola texture per pixel);
-) multi-texture: 411.318695 Mpixel/sec., che corrispondono a 1645.27478 Mtexte/sec (dato che vengono applicate 4 texture per pixel).
E' qui che i conti non mi tornano: in single pass, usando 4 texture per pixel si diminuisce notevolmente il pixel rate, ma questo non dovrebbe comunque scendere in modo proporzionato. In pratica, se in un singolo passaggio uso 4 texture per pixel non avrò un pixel rete di 1/4 rispetto all'uso di una singola texture perchè non farò n accessi al frame buffer ma solo n/4 (indicativamente), dato che ho un hardware in grado di applicare 4 texture in single pass. Di conseguenze, sebbene il pixel rate sicuramente cali, il texture rate dovrebbe salire fino a sfiorare il massimo teorico del chip in questione, dato che si passa da una situazione bandwidth limited (come nel caso di 1 texture per pixel, che richiede n accessi al framebuffer, 1 per ogni textel, in pratica lasciando le pipeline spesso senza lavoro, dato che ad applicare una singola texture non ci mettono molto) a una fill rate limited (dato che, dovendo applicare 4 texture per pixel ma potente effettuare questo in single pass, potrò scrivere nel framebuffer ogni 4 textel e quindi in proporzione le pipeline hanno molte più possibilità di esprimersi al meglio).
Con il test del 3DMark questa regola è confermata: nonostante il pixel rate cali, l'efficenza complessiva (misurata in Mtextel) quasi raddoppia.
Con il test oggetto di questo post invece ciò non succede, anzi, l'efficenza complessiva scende leggermente (da 1677.936035 Mtextel/sec a 1645.27478 Mtexte/sec).
L'unico motivo che trovo per giustificare questo è che anche in single texture questo test sia fill rate limited e non bandwidth limited, eppure questo mi sembra molto strano...
Più tardi proverò a rifare gli stessi test abbassando le frequenze di core e ram separatemente ;).
Ciao! :)
leoneazzurro
12-12-2004, 20:43
Noto che, drivers a parte, questo test ha anche una dipendenza dalla bandwidth della memoria. Ad esempio io ho una GTina della ASUS overclockata a 400/860 (core a frequenze della ultra) e vedo che però la Ultra mi distacca in questi test sintetici in modo non proprio disprezzabile, anzi (un 15%). In effetti i miei punteggi non sono troppo lontani da quelli di Dark Schneider, che però ha il core a default.
Insomma, anche in questi test sintetici sembra che il sottosistema memoria conti molto.
yossarian
12-12-2004, 22:24
Originariamente inviato da shodan
Ciao Yossarian,
grazie per la risposta, ho letto con estremo interesse il tuo post. :)
C'è però ancora qualcosa che non mi torna... vediamo se riesco ad essere "esauriente" :D.
Ho fatto un test del fill rate con 3DMark 2003 e questi sono i risultati ottenuti:
-) single-texture: 1833 Mtextel/sec., che in questo caso corrispondono a 1833 Mpixel (dato che è stata applicata una sola texture per pixel);
-) multi-texture: 3168 Mtextel/sec., che in questo caso corrispondono a 396 Mpixel (dato che sono applicate 8 texture per pixel).
Si nota quindi che, nonostante il drastico calo del pixel rate, l'efficenza complessiva è comunque quasi raddoppiata: in regime di single texture infatti, applicando 8 textel per pixel (facendo quindi 8 passate), il pixel rate dovrebbe scendere a 229 Mpixel, cioè ad 1/8 di quello ottenibile con una sola texture per pixel, mentre facendo tutto in single pass si rimane sui 396 Mpixel (come calcolato sopra).
Questi sono invece i risultati ottenuti con il test in questione:
-) sigle-texture: 1677.936035 Mpixel/sec., che corrispondono a 1677.936035 Mtextel/sec (dato che viene applicata una sola texture per pixel);
-) multi-texture: 411.318695 Mpixel/sec., che corrispondono a 1645.27478 Mtexte/sec (dato che vengono applicate 4 texture per pixel).
E' qui che i conti non mi tornano: in single pass, usando 4 texture per pixel si diminuisce notevolmente il pixel rate, ma questo non dovrebbe comunque scendere in modo proporzionato. In pratica, se in un singolo passaggio uso 4 texture per pixel non avrò un pixel rete di 1/4 rispetto all'uso di una singola texture perchè non farò n accessi al frame buffer ma solo n/4 (indicativamente), dato che ho un hardware in grado di applicare 4 texture in single pass. Di conseguenze, sebbene il pixel rate sicuramente cali, il texture rate dovrebbe salire fino a sfiorare il massimo teorico del chip in questione, dato che si passa da una situazione bandwidth limited (come nel caso di 1 texture per pixel, che richiede n accessi al framebuffer, 1 per ogni textel, in pratica lasciando le pipeline spesso senza lavoro, dato che ad applicare una singola texture non ci mettono molto) a una fill rate limited (dato che, dovendo applicare 4 texture per pixel ma potente effettuare questo in single pass, potrò scrivere nel framebuffer ogni 4 textel e quindi in proporzione le pipeline hanno molte più possibilità di esprimersi al meglio).
Con il test del 3DMark questa regola è confermata: nonostante il pixel rate cali, l'efficenza complessiva (misurata in Mtextel) quasi raddoppia.
Con il test oggetto di questo post invece ciò non succede, anzi, l'efficenza complessiva scende leggermente (da 1677.936035 Mtextel/sec a 1645.27478 Mtexte/sec).
L'unico motivo che trovo per giustificare questo è che anche in single texture questo test sia fill rate limited e non bandwidth limited, eppure questo mi sembra molto strano...
Più tardi proverò a rifare gli stessi test abbassando le frequenze di core e ram separatemente ;).
Ciao! :)
prova a rifare il test a 1024x768; il multitexturing del 3DMark applica non più di 2 texel per pixel (altrimenti, se fossero 8, non sarebbe seguito da tutti i chip non DX9).
Originariamente inviato da yossarian
prova a rifare il test a 1024x768; il multitexturing del 3DMark applica non più di 2 texel per pixel (altrimenti, se fossero 8, non sarebbe seguito da tutti i chip non DX9).
Ciao,
ho rifatto i test a 1280x1024, ecco i risultati:
Fillrate Tester
--------------------------
Display adapter: RADEON 9800 XT
Driver version: 6.14.10.6497
Display mode: 1280x1024 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 2860.052246M pixels/sec
FFP - Z pixel rate - 2774.524170M pixels/sec
FFP - Single texture - 2779.023926M pixels/sec
FFP - Dual texture - 1496.930664M pixels/sec
FFP - Triple texture - 1004.172241M pixels/sec
FFP - Quad texture - 669.347778M pixels/sec
PS 1.1 - Simple - 1624.631592M pixels/sec
PS 1.4 - Simple - 1624.628540M pixels/sec
PS 2.0 - Simple - 1624.616089M pixels/sec
PS 2.0 PP - Simple - 1624.632813M pixels/sec
PS 2.0 - Longer - 817.209839M pixels/sec
PS 2.0 PP - Longer - 817.210693M pixels/sec
PS 2.0 - Longer 4 Registers - 817.211060M pixels/sec
PS 2.0 PP - Longer 4 Registers - 817.210693M pixels/sec
PS 2.0 - Per Pixel Lighting - 234.093536M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 234.093369M pixels/sec
Come vedi i risultati sono aumentati in senso assoluto, eppure i rapporti tra di loro non cambiano: il textel rate nel test con 1 texture è maggiore rispetto a quello con 4 texture, e questo non me lo spiego (vedi post precedente).
Riguardo al 3DMark ti posto direttamente quello che leggo nell'help dell'applicativo stesso:
There are two different test runs included in the fill rate test, and they are:
Single-Texturing: There are 64 surfaces with one texture each. This means that the graphics hardware fills each of these objects separately, no matter how many texture layers that card is capable of drawing in a single pass.
Multi-Texturing: We draw 64 texture layers as fast as possible. This means that we take advantage of the fact that modern cards are usually capable of drawing multiple texture layers on a single object nearly as fast as it would draw one single layer. 64 texture layers are distributed so that each surface in use has as many texture layers as that particular card can draw in a single pass. For example, if your card is capable of doing 6 texture layers in a pass, there will be 10 objects with 6 layers and an 11th layer with the remaining 4 layers. Fixed function texturing has an upper limit of 8 textures per pass, which means that even modern DX9 hardware capable of up to 16 per pass, will not do more than 8.
Da qui mi pare di capire che in single texture il programma disegnerà 64 layer ognuno con una texture sopra, mentre in multi texture disegnera n layer dove n = 64/texture per pass. In pratica, su un hardware capace di disegnare 8 texture, verranno creati 8 layer ognuno con 8 texture: in questo modo i textel totali non cambiano, mentre il numero di pixel da disegnare è ridotto ad 1/8 (infatti il test in multi texture genera un frame rate decisamente più alto rispetto a quello in sigle texture). Su hardware che supporto un massimo di 2 texture per passaggio invece si avranno 32 layer con 2 texture per ognuno.
Questo per lo meno è quello che ho capito leggendo il readme, ma posso benissimo sbagliarmi... :)
yossarian
13-12-2004, 13:20
Originariamente inviato da shodan
Ciao,
ho rifatto i test a 1280x1024, ecco i risultati:
Fillrate Tester
--------------------------
Display adapter: RADEON 9800 XT
Driver version: 6.14.10.6497
Display mode: 1280x1024 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 2860.052246M pixels/sec
FFP - Z pixel rate - 2774.524170M pixels/sec
FFP - Single texture - 2779.023926M pixels/sec
FFP - Dual texture - 1496.930664M pixels/sec
FFP - Triple texture - 1004.172241M pixels/sec
FFP - Quad texture - 669.347778M pixels/sec
PS 1.1 - Simple - 1624.631592M pixels/sec
PS 1.4 - Simple - 1624.628540M pixels/sec
PS 2.0 - Simple - 1624.616089M pixels/sec
PS 2.0 PP - Simple - 1624.632813M pixels/sec
PS 2.0 - Longer - 817.209839M pixels/sec
PS 2.0 PP - Longer - 817.210693M pixels/sec
PS 2.0 - Longer 4 Registers - 817.211060M pixels/sec
PS 2.0 PP - Longer 4 Registers - 817.210693M pixels/sec
PS 2.0 - Per Pixel Lighting - 234.093536M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 234.093369M pixels/sec
Come vedi i risultati sono aumentati in senso assoluto, eppure i rapporti tra di loro non cambiano: il textel rate nel test con 1 texture è maggiore rispetto a quello con 4 texture, e questo non me lo spiego (vedi post precedente).
Riguardo al 3DMark ti posto direttamente quello che leggo nell'help dell'applicativo stesso:
There are two different test runs included in the fill rate test, and they are:
Single-Texturing: There are 64 surfaces with one texture each. This means that the graphics hardware fills each of these objects separately, no matter how many texture layers that card is capable of drawing in a single pass.
Multi-Texturing: We draw 64 texture layers as fast as possible. This means that we take advantage of the fact that modern cards are usually capable of drawing multiple texture layers on a single object nearly as fast as it would draw one single layer. 64 texture layers are distributed so that each surface in use has as many texture layers as that particular card can draw in a single pass. For example, if your card is capable of doing 6 texture layers in a pass, there will be 10 objects with 6 layers and an 11th layer with the remaining 4 layers. Fixed function texturing has an upper limit of 8 textures per pass, which means that even modern DX9 hardware capable of up to 16 per pass, will not do more than 8.
Da qui mi pare di capire che in single texture il programma disegnerà 64 layer ognuno con una texture sopra, mentre in multi texture disegnera n layer dove n = 64/texture per pass. In pratica, su un hardware capace di disegnare 8 texture, verranno creati 8 layer ognuno con 8 texture: in questo modo i textel totali non cambiano, mentre il numero di pixel da disegnare è ridotto ad 1/8 (infatti il test in multi texture genera un frame rate decisamente più alto rispetto a quello in sigle texture). Su hardware che supporto un massimo di 2 texture per passaggio invece si avranno 32 layer con 2 texture per ognuno.
Questo per lo meno è quello che ho capito leggendo il readme, ma posso benissimo sbagliarmi... :)
hai ragione, i punteggi sono effettivamnete troppo bassi; quello che ho detto prima vale per i test visti online e per quelli in cui c'è un aumento, anche minimo, del texel fillrate in m/t.
In effetti, in alcuni risultati, c'è qualcosa di strano su cui vale la pena di indagare
ciao
Sarebbe interessante fare delle comparazioni anche con il tool usato da xbitlabs, devo vedere se riesco a beccarlo...
Al limite possiamo sempre chiedere a Marco Dolenc di darci qualche spiegazione! :D:D
yossarian
13-12-2004, 15:12
Originariamente inviato da shodan
Sarebbe interessante fare delle comparazioni anche con il tool usato da xbitlabs, devo vedere se riesco a beccarlo...
Al limite possiamo sempre chiedere a Marco Dolenc di darci qualche spiegazione! :D:D
prova con rightmark, puoi scaricarlo anche da qui
http://software.hwupgrade.it/lista/5.file
Ho già provato diversi test; questo tool ti permette di effettuare settaggi in dettaglio (grandezza delle texture, tipo di shader, utilizzo o mano di filtri, ecc.).
Ti conviene partire dalla configurazione standard delle batch e aggiungere quelle relative al pixel filling che ti interessano, settando ps2.0 e vs2.0.
Sia su x-bit che su b3d usano, di solito, rightmark, shadermark, dolenc's fillrate test e 3dmark, combinando i risultati tra loro.
Dark Schneider
13-12-2004, 17:30
Originariamente inviato da BTinside
Ottimi valori per essere @default, chissà overclokkando a ultra se ottieni gli stessi miei risultati oppure anche superiori.
Che marca è la tua?
E' una Point of View!!! :) Magari dopo provo ad OC ad Ultra e vedo. :)
flavix25
30-12-2004, 15:21
ed ecco a voi una bella aoppen 6800le 16x1,6 frequenze default
"214 euro di scheda"
--------------------------
Display adapter: MSI MS-StarForce GeForce 6800 LE (NVIDIA GeForce 6800 LE)
Driver version: 6.14.10.7122
Display mode: 1024x768 A8R8G8B8 100Hzquesto è un monitor non un lcd del cappero
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 4616.528320M pixels/sec
FFP - Z pixel rate - 8817.872070M pixels/sec
FFP - Single texture - 4504.428223M pixels/sec
FFP - Dual texture - 2303.893311M pixels/sec
FFP - Triple texture - 1543.567871M pixels/sec
FFP - Quad texture - 1158.311157M pixels/sec
PS 1.1 - Simple - 2339.156494M pixels/sec
PS 1.4 - Simple - 2338.141846M pixels/sec
PS 2.0 - Simple - 2338.130127M pixels/sec
PS 2.0 PP - Simple - 2338.190186M pixels/sec
PS 2.0 - Longer - 1180.671143M pixels/sec
PS 2.0 PP - Longer - 1180.050171M pixels/sec
PS 2.0 - Longer 4 Registers - 1180.048218M pixels/sec
PS 2.0 PP - Longer 4 Registers - 1180.047607M pixels/sec
PS 2.0 - Per Pixel Lighting - 364.008026M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 522.071106M pixels/sec
Giusto poer prova li faccio anche con 60hz
--------------------------
Display adapter: MSI MS-StarForce GeForce 6800 LE (NVIDIA GeForce 6800 LE)
Driver version: 6.14.10.7122
Display mode: 1024x768 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 4535.981934M pixels/sec
FFP - Z pixel rate - 8899.750000M pixels/sec
FFP - Single texture - 4531.683105M pixels/sec
FFP - Dual texture - 2264.473877M pixels/sec
FFP - Triple texture - 1509.759766M pixels/sec
FFP - Quad texture - 1156.738647M pixels/sec
PS 1.1 - Simple - 2339.946045M pixels/sec
PS 1.4 - Simple - 2338.798096M pixels/sec
PS 2.0 - Simple - 2338.402832M pixels/sec
PS 2.0 PP - Simple - 2338.860107M pixels/sec
PS 2.0 - Longer - 1179.591797M pixels/sec
PS 2.0 PP - Longer - 1178.660889M pixels/sec
PS 2.0 - Longer 4 Registers - 1178.677368M pixels/sec
PS 2.0 PP - Longer 4 Registers - 1178.609009M pixels/sec
PS 2.0 - Per Pixel Lighting - 364.305756M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 521.814087M pixels/sec
aggiungo i risultati in oc ma non cambia molto 350/850
--------------------------
Display adapter: MSI MS-StarForce GeForce 6800 LE (NVIDIA GeForce 6800 LE)
Driver version: 6.14.10.7122
Display mode: 1024x768 A8R8G8B8 100Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 4618.256348M pixels/sec
FFP - Z pixel rate - 8819.678711M pixels/sec
FFP - Single texture - 4619.667969M pixels/sec
FFP - Dual texture - 2339.148682M pixels/sec
FFP - Triple texture - 1569.259888M pixels/sec
FFP - Quad texture - 1177.994995M pixels/sec
PS 1.1 - Simple - 2349.987061M pixels/sec
PS 1.4 - Simple - 2351.237793M pixels/sec
PS 2.0 - Simple - 2350.309814M pixels/sec
PS 2.0 PP - Simple - 2349.772217M pixels/sec
PS 2.0 - Longer - 1182.011475M pixels/sec
PS 2.0 PP - Longer - 1182.321533M pixels/sec
PS 2.0 - Longer 4 Registers - 1181.580322M pixels/sec
PS 2.0 PP - Longer 4 Registers - 1181.598389M pixels/sec
PS 2.0 - Per Pixel Lighting - 364.350464M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 524.796021M pixels/sec
flavix25
30-12-2004, 15:34
Questa pperò me la dovete sppiegare...si ok ho un monitor da paura un 17" che regge 1600x1200 a 70hz! Ma come cavolo faccio a migliorare le pprestazioni aumentando di risoluzione
--------------------------
Display adapter: MSI MS-StarForce GeForce 6800 LE (NVIDIA GeForce 6800 LE)
Driver version: 6.14.10.7122
Display mode: 1600x1200 A8R8G8B8 70Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 5469.419434M pixels/sec
FFP - Z pixel rate - 10740.154297M pixels/sec
FFP - Single texture - 4769.708984M pixels/sec
FFP - Dual texture - 2706.770752M pixels/sec
FFP - Triple texture - 1815.455078M pixels/sec
FFP - Quad texture - 1367.999512M pixels/sec
PS 1.1 - Simple - 2763.511963M pixels/sec
PS 1.4 - Simple - 2764.105713M pixels/sec
PS 2.0 - Simple - 2764.130371M pixels/sec
PS 2.0 PP - Simple - 2763.783936M pixels/sec
PS 2.0 - Longer - 1387.626587M pixels/sec
PS 2.0 PP - Longer - 1387.015869M pixels/sec
PS 2.0 - Longer 4 Registers - 1387.014038M pixels/sec
PS 2.0 PP - Longer 4 Registers - 1386.860229M pixels/sec
PS 2.0 - Per Pixel Lighting - 427.902130M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 608.237793M pixels/sec
Thunder82
30-12-2004, 15:37
Originariamente inviato da flavix25
Questa pperò me la dovete sppiegare...si ok ho un monitor da paura un 17" che regge 1600x1200 a 70hz! Ma come cavolo faccio a migliorare le pprestazioni aumentando di risoluzione
--------------------------
Display adapter: MSI MS-StarForce GeForce 6800 LE (NVIDIA GeForce 6800 LE)
Driver version: 6.14.10.7122
Display mode: 1600x1200 A8R8G8B8 70Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 5469.419434M pixels/sec
FFP - Z pixel rate - 10740.154297M pixels/sec
FFP - Single texture - 4769.708984M pixels/sec
FFP - Dual texture - 2706.770752M pixels/sec
FFP - Triple texture - 1815.455078M pixels/sec
FFP - Quad texture - 1367.999512M pixels/sec
PS 1.1 - Simple - 2763.511963M pixels/sec
PS 1.4 - Simple - 2764.105713M pixels/sec
PS 2.0 - Simple - 2764.130371M pixels/sec
PS 2.0 PP - Simple - 2763.783936M pixels/sec
PS 2.0 - Longer - 1387.626587M pixels/sec
PS 2.0 PP - Longer - 1387.015869M pixels/sec
PS 2.0 - Longer 4 Registers - 1387.014038M pixels/sec
PS 2.0 PP - Longer 4 Registers - 1386.860229M pixels/sec
PS 2.0 - Per Pixel Lighting - 427.902130M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 608.237793M pixels/sec
è normale... il fillrate aumenta all'aumentare della risoluzione. Occhio che fillrate non è fps...
flavix25
30-12-2004, 15:40
Originariamente inviato da Thunder82
è normale... il fillrate aumenta all'aumentare della risoluzione. Occhio che fillrate non è fps...
degli fps lo sappevo pperchè si sono piu che dimezzati (avevo fraps attivato).
cmq della risoluzione non lo sappevo grazie
Thunder82
30-12-2004, 15:47
Originariamente inviato da flavix25
degli fps lo sappevo pperchè si sono piu che dimezzati (avevo fraps attivato).
cmq della risoluzione non lo sappevo grazie
se fai 60 fps ad esempio sia a 1024x768 e anche a 1600x1200, avrai:
1 immagine a 1024x768 è 786432 pixels
1 immagine a 1600x1200 è 1920000 pixels
quindi 60 fps per ogni immagine fa:
a 1024x768 786432*60=47,18592 MPixels/s
a 1600x1200 1920000*60=115,2 MPixels/s
:)
rmarango
30-12-2004, 19:31
Originariamente inviato da yossarian
Come si può notare, con shader particolarmente lunghi, anche l'fp16, seppure permetta di raddoppiare le prestazioni rispetto a fp32 (che nei giochi, considerando anche le operazioni di texturing e altro si traduce in un 20-30% in più) non garantisce un frame rate sufficientemente elevato (quello che succede in alcune mappe di HL2)
Yoss,
Qui volevo soltanto commentare che se guardi il test piu' pesante (il per pixel lighting) il tizio con la fx5900 ha fatto circa 120 (ovviamente in fp16) contro i 140,150 delle ATi di fascia piu' o meno paragonabile (che vanno in fp24) ... mi sembrano risultati abbastanza comparabili.
Lo dimostrano anche i risultati con 3danalyze di tanta gente nei forum esteri che hanno ottenuto un frame rate piu' che accettabile anche in dx9.
Sono aperto a tutte le tue critiche comunque...
:)
Originariamente inviato da rmarango
Yoss,
Qui volevo soltanto commentare che se guardi il test piu' pesante (il per pixel lighting) il tizio con la fx5900 ha fatto circa 120 (ovviamente in fp16) contro i 140,150 delle ATi di fascia piu' o meno paragonabile (che vanno in fp24) ... mi sembrano risultati abbastanza comparabili.
Lo dimostrano anche i risultati con 3danalyze di tanta gente nei forum esteri che hanno ottenuto un frame rate piu' che accettabile anche in dx9.
Sono aperto a tutte le tue critiche comunque...
:)
Ciao,
in realtà è la 9600XT di Thunder82 a fare 140 Mpixel. La 9600XT però non è paraganabile, come fascia di prezzo e prestazioni, alle 5900 e neanche con le 5900XT.
Le 5900 XT - liscie - ultra vanno confrontate con le 9800 liscie - pro.
Dato che la mia 9800Pro, con core a 412Mhz, fa circa 233 Mpixel, posso immaginare che alle frequenze di una 9800 liscia riesca a garantire un pixel rate di 180-190 Mpixel/sec, quindi decisamente superiore a quello della 5900 presa in considerazioni (che tra l'altro, come da te ricordato, lavora in fp16 rispetto all'fp24 di ATI).
All'atto pratica, anche una 5900 con frequenze di 450/910 come quella del test a cui ti riferisci (quindi quasi una 5950Ultra) non riesce a superare le prestazioni di una ben più anziana ma assolutamente valida Radeon 9700Pro (come quella di yossarian).
Ciao. :)
Originariamente inviato da shodan
Ciao,
in realtà è la 9600XT di Thunder82 a fare 140 Mpixel.
...ehi...! è la mia ex 9600XT che fa 141 Mpixel!!! :mad: :D :)
...quella di Thunder82 ne fa 160...! :eek:
...ciao!
Originariamente inviato da shodan
All'atto pratica, anche una 5900 con frequenze di 450/910 come quella del test a cui ti riferisci (quindi quasi una 5950Ultra) non riesce a superare le prestazioni di una ben più anziana ma assolutamente valida Radeon 9700Pro (come quella di yossarian).
Ciao. :)
..."all'atto pratica" la 5900XT non riesce a superare nemmeno la 9600XT nei test ps...
Fillrate Tester
--------------------------
Display adapter: GeXCube RADEON 9600XT Game Buster
Display mode: 640x480 A8R8G8B8 60Hz
--------------------------
FFP - Pure fillrate - 1274.505493M pixels/sec
FFP - Z pixel rate - 1913.672485M pixels/sec
FFP - Single texture - 1103.490356M pixels/sec
FFP - Dual texture - 668.871826M pixels/sec
FFP - Triple texture - 484.283783M pixels/sec
FFP - Quad texture - 226.612518M pixels/sec
PS 1.1 - Simple - 978.171814M pixels/sec
PS 1.4 - Simple - 978.186768M pixels/sec
PS 2.0 - Simple - 978.034363M pixels/sec
PS 2.0 PP - Simple - 978.023315M pixels/sec
PS 2.0 - Longer - 493.423492M pixels/sec
PS 2.0 PP - Longer - 493.405060M pixels/sec
PS 2.0 - Longer 4 Registers - 493.515961M pixels/sec
PS 2.0 PP - Longer 4 Registers - 493.502808M pixels/sec
PS 2.0 - Per Pixel Lighting - 141.508850M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 141.507965M pixels/sec
Fillrate Tester
--------------------------
Display adapter: 5900XT
Display mode: 640x480 A8R8G8B8 60Hz
--------------------------
FFP - Pure fillrate - 833.328979M pixels/sec
FFP - Z pixel rate - 3283.066650M pixels/sec
FFP - Single texture - 1589.981934M pixels/sec
FFP - Dual texture - 1144.068115M pixels/sec
FFP - Triple texture - 652.526794M pixels/sec
FFP - Quad texture - 465.925720M pixels/sec
PS 1.1 - Simple - 877.980347M pixels/sec
PS 1.4 - Simple - 832.167297M pixels/sec
PS 2.0 - Simple - 563.016418M pixels/sec
PS 2.0 PP - Simple - 833.561340M pixels/sec
PS 2.0 - Longer - 213.498749M pixels/sec
PS 2.0 PP - Longer - 424.998932M pixels/sec
PS 2.0 - Longer 4 Registers - 213.393600M pixels/sec
PS 2.0 PP - Longer 4 Registers - 560.214355M pixels/sec
PS 2.0 - Per Pixel Lighting - 84.670235M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 120.282982M pixels/sec
--------------------------
...ciao! :)
Originariamente inviato da belin
...ehi...! è la mia ex 9600XT che fa 141 Mpixel!!! :mad: :D :)
...quella di Thunder82 ne fa 160...! :eek:
...ciao!
Azzz... perdonami :D:cool:
Originariamente inviato da belin
..."all'atto pratica" la 5900XT non riesce a superare nemmeno la 9600XT nei test ps...
Fillrate Tester
--------------------------
Display adapter: GeXCube RADEON 9600XT Game Buster
Display mode: 640x480 A8R8G8B8 60Hz
--------------------------
FFP - Pure fillrate - 1274.505493M pixels/sec
FFP - Z pixel rate - 1913.672485M pixels/sec
FFP - Single texture - 1103.490356M pixels/sec
FFP - Dual texture - 668.871826M pixels/sec
FFP - Triple texture - 484.283783M pixels/sec
FFP - Quad texture - 226.612518M pixels/sec
PS 1.1 - Simple - 978.171814M pixels/sec
PS 1.4 - Simple - 978.186768M pixels/sec
PS 2.0 - Simple - 978.034363M pixels/sec
PS 2.0 PP - Simple - 978.023315M pixels/sec
PS 2.0 - Longer - 493.423492M pixels/sec
PS 2.0 PP - Longer - 493.405060M pixels/sec
PS 2.0 - Longer 4 Registers - 493.515961M pixels/sec
PS 2.0 PP - Longer 4 Registers - 493.502808M pixels/sec
PS 2.0 - Per Pixel Lighting - 141.508850M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 141.507965M pixels/sec
Fillrate Tester
--------------------------
Display adapter: 5900XT
Display mode: 640x480 A8R8G8B8 60Hz
--------------------------
FFP - Pure fillrate - 833.328979M pixels/sec
FFP - Z pixel rate - 3283.066650M pixels/sec
FFP - Single texture - 1589.981934M pixels/sec
FFP - Dual texture - 1144.068115M pixels/sec
FFP - Triple texture - 652.526794M pixels/sec
FFP - Quad texture - 465.925720M pixels/sec
PS 1.1 - Simple - 877.980347M pixels/sec
PS 1.4 - Simple - 832.167297M pixels/sec
PS 2.0 - Simple - 563.016418M pixels/sec
PS 2.0 PP - Simple - 833.561340M pixels/sec
PS 2.0 - Longer - 213.498749M pixels/sec
PS 2.0 PP - Longer - 424.998932M pixels/sec
PS 2.0 - Longer 4 Registers - 213.393600M pixels/sec
PS 2.0 PP - Longer 4 Registers - 560.214355M pixels/sec
PS 2.0 - Per Pixel Lighting - 84.670235M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 120.282982M pixels/sec
--------------------------
...ciao! :)
Già... senza contare che la 5900XT da te indicata è parecchio overcloccata (l'utente che la possiede ha scritto che le frequenze sono di 475/910).
Ciao. :)
rmarango
31-12-2004, 11:16
Originariamente inviato da shodan
Ciao,
in realtà è la 9600XT di Thunder82 a fare 140 Mpixel. La 9600XT però non è paraganabile, come fascia di prezzo e prestazioni, alle 5900 e neanche con le 5900XT.
Le 5900 XT - liscie - ultra vanno confrontate con le 9800 liscie - pro.
Dato che la mia 9800Pro, con core a 412Mhz, fa circa 233 Mpixel, posso immaginare che alle frequenze di una 9800 liscia riesca a garantire un pixel rate di 180-190 Mpixel/sec, quindi decisamente superiore a quello della 5900 presa in considerazioni (che tra l'altro, come da te ricordato, lavora in fp16 rispetto all'fp24 di ATI).
All'atto pratica, anche una 5900 con frequenze di 450/910 come quella del test a cui ti riferisci (quindi quasi una 5950Ultra) non riesce a superare le prestazioni di una ben più anziana ma assolutamente valida Radeon 9700Pro (come quella di yossarian).
Ciao. :)
Tutto giusto cio' che hai scritto. :)
Quello che intendevo dire e' che forzando fp16 si puo' ottenere un frame rate piu' che accettabile e apparentemente senza i.q. degradation dagli screenshot visti su internet.
Ciao :)
Thunder82
31-12-2004, 11:33
Originariamente inviato da rmarango
Tutto giusto cio' che hai scritto. :)
Quello che intendevo dire e' che forzando fp16 si puo' ottenere un frame rate piu' che accettabile e apparentemente senza i.q. degradation dagli screenshot visti su internet.
Ciao :)
sì ma vedi che una scheda da 500€ (la 5900xt che fa 120MPixel era overclockata alle frequenze della 5950ultra) va comunque parecchio meno di una scheda da 160€ (la 9600xt).
Dai su, cerchiamo di essere obiettivi e di non continuare a difendere queste schede laddove sono indifendibili... ok vanno bene in opengl, ok vanno bene in dx8, ma in dx9 proprio non ci siamo...
rmarango
31-12-2004, 11:43
Originariamente inviato da Thunder82
sì ma vedi che una scheda da 500€ (la 5900xt che fa 120MPixel era overclockata alle frequenze della 5950ultra) va comunque parecchio meno di una scheda da 160€ (la 9600xt).
Dai su, cerchiamo di essere obiettivi e di non continuare a difendere queste schede laddove sono indifendibili... ok vanno bene in opengl, ok vanno bene in dx8, ma in dx9 proprio non ci siamo...
Veramente la 5900 io la pagai sui 200 euro.
In dx9 hai ragione...senza workaround non vanno
:)
Thunder82
31-12-2004, 11:52
Originariamente inviato da rmarango
Veramente la 5900 io la pagai sui 200 euro.
In dx9 hai ragione...senza workaround non vanno
:)
sì la 5900xt costa 200 euro, ma le frequenze a cui ha fatto 120MPixel non sono propriamente quelle della 5900xt ma sono quelle della 5950 ultra, scheda da 500€ all'uscita
rmarango
31-12-2004, 11:57
Originariamente inviato da Thunder82
sì la 5900xt costa 200 euro, ma le frequenze a cui ha fatto 120MPixel non sono propriamente quelle della 5900xt ma sono quelle della 5950 ultra, scheda da 500€ all'uscita
Ok , thunder hai ragione, pero' sai meglio di me che portare una 5900 a 5900ultra e' facilissimo ...sono schede super overcloccabili. :)
Originariamente inviato da Thunder82
sì ma vedi che una scheda da 500€ (la 5900xt che fa 120MPixel era overclockata alle frequenze della 5950ultra) va comunque parecchio meno di una scheda da 160€ (la 9600xt).
Già, era proprio questo che volevo sottolineare...
Che poi le prestazioni delle NV3x in partial precision siano migliori rispetto a quelle ottenibili in full precision non ci piove, però il risultato in questione è già fatto in partial precision (e nonostante questo la 9600XT risulta essere superiore).
Ciao! :)
yossarian
22-04-2005, 19:03
riapro questa vecchia discussione per chiedere a qualche possessore di 5600/5700 e di 5200 di eseguire il test. La richiesta nasce dal fatto che vorrei verificare l'andamento qualitativo dello z rate perchè sospetto che le rop's di nv31 (e di nv36) siano diverse da quelle di nv30 e nv35; in quest'ottica sarebbe interessante valutare anche il comportamento di nv34
nonikname
22-04-2005, 20:07
Test 1 con GPU singola - 6800gt PCI-E tutto default (Impostazioni Test e GPU non o.c.)
--------------------------
Display adapter: NVIDIA GeForce 6800 Series GPU
Driver version: 6.14.10.7189
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 5282.449219M pixels/sec
FFP - Z pixel rate - 9396.738281M pixels/sec
FFP - Single texture - 3234.586914M pixels/sec
FFP - Dual texture - 2204.351563M pixels/sec
FFP - Triple texture - 1528.315308M pixels/sec
FFP - Quad texture - 1172.796509M pixels/sec
PS 1.1 - Simple - 2645.994385M pixels/sec
PS 1.4 - Simple - 2645.928467M pixels/sec
PS 2.0 - Simple - 2645.415039M pixels/sec
PS 2.0 PP - Simple - 2645.965088M pixels/sec
PS 2.0 - Longer - 1371.327881M pixels/sec
PS 2.0 PP - Longer - 1371.408691M pixels/sec
PS 2.0 - Longer 4 Registers - 1371.330811M pixels/sec
PS 2.0 PP - Longer 4 Registers - 1371.390381M pixels/sec
PS 2.0 - Per Pixel Lighting - 421.025085M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 587.691650M pixels/sec
Test 2 in modalità Split Frame Rendering
--------------------------
Display adapter: NVIDIA GeForce 6800 Series GPU
Driver version: 6.14.10.7189
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 8850.323242M pixels/sec
FFP - Z pixel rate - 15888.615234M pixels/sec
FFP - Single texture - 5883.103516M pixels/sec
FFP - Dual texture - 4117.377441M pixels/sec
FFP - Triple texture - 2900.254150M pixels/sec
FFP - Quad texture - 2202.758545M pixels/sec
PS 1.1 - Simple - 4815.695801M pixels/sec
PS 1.4 - Simple - 4814.540039M pixels/sec
PS 2.0 - Simple - 4814.224609M pixels/sec
PS 2.0 PP - Simple - 4813.205566M pixels/sec
PS 2.0 - Longer - 2592.662354M pixels/sec
PS 2.0 PP - Longer - 2591.586426M pixels/sec
PS 2.0 - Longer 4 Registers - 2594.418457M pixels/sec
PS 2.0 PP - Longer 4 Registers - 2592.720947M pixels/sec
PS 2.0 - Per Pixel Lighting - 808.169189M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 1146.513672M pixels/sec
Test 2 in modalità Alternate Frame Rendering
--------------------------
Display adapter: NVIDIA GeForce 6800 Series GPU
Driver version: 6.14.10.7189
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 9344.098633M pixels/sec
FFP - Z pixel rate - 17328.695313M pixels/sec
FFP - Single texture - 6226.075684M pixels/sec
FFP - Dual texture - 4310.813477M pixels/sec
FFP - Triple texture - 2939.702148M pixels/sec
FFP - Quad texture - 2343.510742M pixels/sec
PS 1.1 - Simple - 5290.038574M pixels/sec
PS 1.4 - Simple - 5289.884277M pixels/sec
PS 2.0 - Simple - 5292.013184M pixels/sec
PS 2.0 PP - Simple - 5287.950195M pixels/sec
PS 2.0 - Longer - 2687.803223M pixels/sec
PS 2.0 PP - Longer - 2686.880371M pixels/sec
PS 2.0 - Longer 4 Registers - 2687.054199M pixels/sec
PS 2.0 PP - Longer 4 Registers - 2688.752197M pixels/sec
PS 2.0 - Per Pixel Lighting - 839.732971M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 1175.803101M pixels/sec
In modalità AFR2 i valori sono pressochè simili all'AFR , che pare essere la migliore modalità per tale bench...
Per curiosità ho anche provato 1280x1024 in modalità no SLI e con l'AFR (a destra)
--------------------------
Display adapter: NVIDIA GeForce 6800 Series GPU
Driver version: 6.14.10.7189
Display mode: 1280x1024 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 5398.896973M pixels/sec - 10678.129883M pixels/sec
FFP - Z pixel rate - 10641.284180M pixels/sec - 20228.980469M pixels/sec
FFP - Single texture - 4860.671875M pixels/sec - 9447.580078M pixels/sec
FFP - Dual texture - 2719.077637M pixels/sec - 5398.970703M pixels/sec
FFP - Triple texture - 1828.769165M pixels/sec - 3647.580322M pixels/sec
FFP - Quad texture - 1373.160400M pixels/sec - 2743.748779M pixels/sec
PS 1.1 - Simple - 2766.149414M pixels/sec - 5483.775391M pixels/sec
PS 1.4 - Simple - 2766.125977M pixels/sec - 5484.026855M pixels/sec
PS 2.0 - Simple - 2765.814453M pixels/sec - 5484.735352M pixels/sec
PS 2.0 PP - Simple - 2766.323730M pixels/sec - 5485.086426M pixels/sec
PS 2.0 - Longer - 1389.019775M pixels/sec - 2769.262695M pixels/sec
PS 2.0 PP - Longer - 1388.990845M pixels/sec - 2769.741943M pixels/sec
PS 2.0 - Longer 4 Registers - 1389.014893M pixels/sec - 2769.714600M pixels/sec
PS 2.0 PP - Longer 4 Registers - 1388.974365M pixels/sec - 2770.242188M pixels/sec
PS 2.0 - Per Pixel Lighting - 427.972015M pixels/sec - 854.191162M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 616.540894M pixels/sec - 1228.187500M pixels/sec
A voi la palla.. :)
riapro questa vecchia discussione per chiedere a qualche possessore di 5600/5700 e di 5200 di eseguire il test. La richiesta nasce dal fatto che vorrei verificare l'andamento qualitativo dello z rate perchè sospetto che le rop's di nv31 (e di nv36) siano diverse da quelle di nv30 e nv35; in quest'ottica sarebbe interessante valutare anche il comportamento di nv34
Ciao yossarian, come mai questo sospetto?
Ciao. :)
PS: ma poi su NVitalia avete capito se la GF2 lavora come una 4x2 anche a 32 bit o solo a 16? :confused:
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce FX 5900
Driver version: 6.14.10.6702
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 748.244995M pixels/sec
FFP - Z pixel rate - 2908.533447M pixels/sec
FFP - Single texture - 1352.119507M pixels/sec
FFP - Dual texture - 985.733337M pixels/sec
FFP - Triple texture - 550.083618M pixels/sec
FFP - Quad texture - 395.119232M pixels/sec
PS 1.1 - Simple - 784.853699M pixels/sec
PS 1.4 - Simple - 743.117432M pixels/sec
PS 2.0 - Simple - 501.666687M pixels/sec
PS 2.0 PP - Simple - 744.921692M pixels/sec
PS 2.0 - Longer - 189.995590M pixels/sec
PS 2.0 PP - Longer - 378.871643M pixels/sec
PS 2.0 - Longer 4 Registers - 189.866440M pixels/sec
PS 2.0 PP - Longer 4 Registers - 499.340424M pixels/sec
PS 2.0 - Per Pixel Lighting - 73.985176M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 106.453873M pixels/sec
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce FX 5900
Driver version: 6.14.10.6702
Display mode: 640x480 A8R8G8B8 120Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 745.819519M pixels/sec
FFP - Z pixel rate - 2911.538330M pixels/sec
FFP - Single texture - 1342.446899M pixels/sec
FFP - Dual texture - 979.593018M pixels/sec
FFP - Triple texture - 546.469421M pixels/sec
FFP - Quad texture - 392.525513M pixels/sec
PS 1.1 - Simple - 785.291382M pixels/sec
PS 1.4 - Simple - 743.222351M pixels/sec
PS 2.0 - Simple - 501.971252M pixels/sec
PS 2.0 PP - Simple - 745.084290M pixels/sec
PS 2.0 - Longer - 190.083008M pixels/sec
PS 2.0 PP - Longer - 378.778046M pixels/sec
PS 2.0 - Longer 4 Registers - 189.956497M pixels/sec
PS 2.0 PP - Longer 4 Registers - 499.507843M pixels/sec
PS 2.0 - Per Pixel Lighting - 73.918716M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 106.452324M pixels/sec
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce FX 5900
Driver version: 6.14.10.6702
Display mode: 1024x768 A8R8G8B8 85Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 754.834412M pixels/sec
FFP - Z pixel rate - 2979.347656M pixels/sec
FFP - Single texture - 1446.950439M pixels/sec
FFP - Dual texture - 1236.527710M pixels/sec
FFP - Triple texture - 675.351868M pixels/sec
FFP - Quad texture - 454.041138M pixels/sec
PS 1.1 - Simple - 792.896118M pixels/sec
PS 1.4 - Simple - 749.845215M pixels/sec
PS 2.0 - Simple - 505.119629M pixels/sec
PS 2.0 PP - Simple - 751.587891M pixels/sec
PS 2.0 - Longer - 190.641769M pixels/sec
PS 2.0 PP - Longer - 380.876251M pixels/sec
PS 2.0 - Longer 4 Registers - 185.487183M pixels/sec
PS 2.0 PP - Longer 4 Registers - 502.793518M pixels/sec
PS 2.0 - Per Pixel Lighting - 80.429405M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 107.696556M pixels/sec
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce FX 5900
Driver version: 6.14.10.6702
Display mode: 1280x1024 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 757.374268M pixels/sec
FFP - Z pixel rate - 2973.322510M pixels/sec
FFP - Single texture - 1492.063599M pixels/sec
FFP - Dual texture - 1365.475952M pixels/sec
FFP - Triple texture - 570.752869M pixels/sec
FFP - Quad texture - 399.668732M pixels/sec
PS 1.1 - Simple - 793.613342M pixels/sec
PS 1.4 - Simple - 750.303345M pixels/sec
PS 2.0 - Simple - 505.691895M pixels/sec
PS 2.0 PP - Simple - 752.195740M pixels/sec
PS 2.0 - Longer - 182.800247M pixels/sec
PS 2.0 PP - Longer - 372.332672M pixels/sec
PS 2.0 - Longer 4 Registers - 182.686020M pixels/sec
PS 2.0 PP - Longer 4 Registers - 503.442749M pixels/sec
PS 2.0 - Per Pixel Lighting - 82.386436M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 108.099770M pixels/sec
yossarian
23-04-2005, 01:32
Ciao yossarian, come mai questo sospetto?
Ciao. :)
PS: ma poi su NVitalia avete capito se la GF2 lavora come una 4x2 anche a 32 bit o solo a 16? :confused:
ciao shodan
sia la GF2 che la GF256 lavorano, a 32 bit, come un'architettura a 2 pixel pipeline; il risultato del test è lo stesso anche a risoluzioni (640x480) che non lasciano adito a dubbi.
Il sospetto nasce da una vecchia recensione in cui i valori del fillrate in caso di z ops e texturing erano molto vicini. Se la serie 5600/5700 è una 4x1 in single e una 2x2 in multi e se le rop's hanno la stessa architettura di quelle di NV30/NV35, l'output doveva essere doppio rispetto a quello ottenuto in caso di color ops o di operazioni di texturing.
Invece, questo è un test che ho trovato sul forum di nV news
Display adapter: NVIDIA GeForce FX 5600 Ultra
Driver version: 6.14.10.6072
Display mode: 1024x768 A8R8G8B8 85Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 371.555481M pixels/sec
FFP - Z pixel rate - 1544.887695M pixels/sec
FFP - Single texture - 1352.166260M pixels/sec
FFP - Dual texture - 681.763184M pixels/sec
FFP - Triple texture - 315.009216M pixels/sec
FFP - Quad texture - 219.407974M pixels/sec
PS 1.1 - Simple - 403.544495M pixels/sec
PS 1.4 - Simple - 362.331543M pixels/sec
PS 2.0 - Simple - 186.789444M pixels/sec
PS 2.0 PP - Simple - 243.642380M pixels/sec
PS 2.0 - Longer - 144.970230M pixels/sec
PS 2.0 PP - Longer - 144.605988M pixels/sec
PS 2.0 - Longer 4 Registers - 117.678246M pixels/sec
PS 2.0 PP - Longer 4 Registers - 139.612488M pixels/sec
PS 2.0 - Per Pixel Lighting - 23.637486M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 26.770041M pixels/sec
Guarda i dati relativi allo z rate e al caso di 1 sola texture e confrontali con i dati omologhi relativi a NV30, NV35 e NV40 (parlo del solo dato qualitativo). Nel caso di nv31 i due valori sono pressochè uguali, mentre nel caso di nv30 e di nv35 il secondo è almeno doppio rispetto al primo. Se la cosa fosse confermata, vorrebbe dire che le rop's di nv31/nv36 non permettono il raddoppio dell'output in caso di z ops only.
ciao shodan
sia la GF2 che la GF256 lavorano, a 32 bit, come un'architettura a 2 pixel pipeline; il risultato del test è lo stesso anche a risoluzioni (640x480) che non lasciano adito a dubbi.
Il sospetto nasce da una vecchia recensione in cui i valori del fillrate in caso di z ops e texturing erano molto vicini. Se la serie 5600/5700 è una 4x1 in single e una 2x2 in multi e se le rop's hanno la stessa architettura di quelle di NV30/NV35, l'output doveva essere doppio rispetto a quello ottenuto in caso di color ops o di operazioni di texturing.
Invece, questo è un test che ho trovato sul forum di nV news
Display adapter: NVIDIA GeForce FX 5600 Ultra
Driver version: 6.14.10.6072
Display mode: 1024x768 A8R8G8B8 85Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 371.555481M pixels/sec
FFP - Z pixel rate - 1544.887695M pixels/sec
FFP - Single texture - 1352.166260M pixels/sec
FFP - Dual texture - 681.763184M pixels/sec
FFP - Triple texture - 315.009216M pixels/sec
FFP - Quad texture - 219.407974M pixels/sec
PS 1.1 - Simple - 403.544495M pixels/sec
PS 1.4 - Simple - 362.331543M pixels/sec
PS 2.0 - Simple - 186.789444M pixels/sec
PS 2.0 PP - Simple - 243.642380M pixels/sec
PS 2.0 - Longer - 144.970230M pixels/sec
PS 2.0 PP - Longer - 144.605988M pixels/sec
PS 2.0 - Longer 4 Registers - 117.678246M pixels/sec
PS 2.0 PP - Longer 4 Registers - 139.612488M pixels/sec
PS 2.0 - Per Pixel Lighting - 23.637486M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 26.770041M pixels/sec
Guarda i dati relativi allo z rate e al caso di 1 sola texture e confrontali con i dati omologhi relativi a NV30, NV35 e NV40 (parlo del solo dato qualitativo). Nel caso di nv31 i due valori sono pressochè uguali, mentre nel caso di nv30 e di nv35 il secondo è almeno doppio rispetto al primo. Se la cosa fosse confermata, vorrebbe dire che le rop's di nv31/nv36 non permettono il raddoppio dell'output in caso di z ops only.
Grazie delle info, yossarian :)
Un paio di domande:
-) ho letto i tuoi post dove chiedevi di usare la risoluzione 640x480 in modo da limitare l'impatto della bandwidth della memoria. Presupponendo solo operazioni di rendering, in modo da non tenere conto né della CPU né dei driver della scheda video, perchè a 640x480 il bus di memoria è meno stressato? Mi spiego: è ovvio che a 640x480 vanno trasferiti meno dati alla volta in quanto un frame non ha moltissimi pixel, però, proprio per la relativa semplicità del rendering, la GPU potrà lavorare a una velocità più elevata, elaborando più frame di quelli che potrebbe a una risoluzione più elevata. In sintesi, il rapporto tra uso GPU / uso bandwidth non dovrebbe rimanere costante a tutte le risoluzioni?
-) c'è un motivo particolare per attribuire la sospetta minore efficienza di NV31/36 proprio alle ROPs? Cosa fanno di preciso queste unità se non scrivere il pixel nel frame buffer?
Grazie fin da ora per le risposte! ;)
yossarian
24-04-2005, 01:31
Grazie delle info, yossarian :)
Un paio di domande:
-) ho letto i tuoi post dove chiedevi di usare la risoluzione 640x480 in modo da limitare l'impatto della bandwidth della memoria. Presupponendo solo operazioni di rendering, in modo da non tenere conto né della CPU né dei driver della scheda video, perchè a 640x480 il bus di memoria è meno stressato? Mi spiego: è ovvio che a 640x480 vanno trasferiti meno dati alla volta in quanto un frame non ha moltissimi pixel, però, proprio per la relativa semplicità del rendering, la GPU potrà lavorare a una velocità più elevata, elaborando più frame di quelli che potrebbe a una risoluzione più elevata. In sintesi, il rapporto tra uso GPU / uso bandwidth non dovrebbe rimanere costante a tutte le risoluzioni?
-) c'è un motivo particolare per attribuire la sospetta minore efficienza di NV31/36 proprio alle ROPs? Cosa fanno di preciso queste unità se non scrivere il pixel nel frame buffer?
Grazie fin da ora per le risposte! ;)
non è che a risoluzioni inferiori la gpu lavori a velocità più elevata; la velocità di elaborazione teorica è sempre la stessa mentre quella che varia è la velocità di riempimento del quadro. La bandwidth, inoltre, non è determinata dalla sola ampiezza del canale di comunicazione tra gpu e ram ma dal prodotto di questa ampiezza per la frequenza di lavoro delle ram. Quindi, più che un indice relativo alla velocità di elaborazione della gpu, è un indice della capacità massima della ram di scambiare dati con la gpu stessa. Aumentando la risoluzione la quantità di dati scambiati aumenta e, ovviamente, può arrivare a superare questo limite. Nel qual caso si creano code con dati che vengono letteralmente "messi in attesa di trovare un posto libero" e ciò, di conseguenza, rallenta tutte le operazioni di calcolo. Aggiungi a questo che la ram video contiene non solo il frame buffer ma anche texture buffer, z-buffer, pixel buffer (solo per citare i più noti) e le dimensioni di tutti crescono all'aumentare della risoluzione. I modi in cui, poi, la quantità di dati scambiati possa influenzare la velocità di elaborazione del chip, sono molteplici. Un chip non è un sistema perfetto in cui, ad ogni ciclo di clock, tutte le unità di calcolo sono impegnate a fare qualcosa. Esistono, in ogni elaborazione, tempi morti fisiologici (infatti sarebbe corretto dire che, ad esempio un chip con 8 pipeline di r4ndering e 1 tmu e 2 alu per pipeline, è capace di un massimo di 24 operazioni operazioni per ciclo, piuttosto che compie 24 operazioni per ciclo); questi tempi morti aumentano se la velocità di accesso ai dati è rallentata. Tutti i dati elaborati dal chip passano attraverso il bus e, aumentando la quantità dei dati, aumenta anche il numero di quelli, tra di essi, che sono costretti a "fare la fila"; tieni conto, inoltre, che i dati viaggiano contemporaneamente in entrambi i sensi e che la priorità viene assegnata loro da un controller che stabilisce, in base ai segnali che riceve dal chip, quali dati devono passare in quel momento; altro elemento da non trascurare è quello relativo al rapporto tra dimensioni delle cache interne e quantità dei dati necessari ad una certa elaborazione: è evidente che, ad esempio, l'utilizzo di texture a risoluzione inferiore diminuisce la quantità di dati relativa e aumenta la velocità di esecuzione (più dati, relativi ad una specifica elaborazione, è possibile caricare on chip, più quella elaborazione risulterà veloce)
A bilanciare, in parte, questi effetti negativi, c'è il fatto che aumentando la risoluzione il chip deve elaborare molti più pixel per ogni quadro e, di conseguenza, si riduce il numero dei fps e quello degli intervalli di tempo tra un frame e il successivo (che per un chip sta a significare un intervallo di tempo lunghissimo di inattività).
Di fatto, quindi, esistono due possibili limiti per il fillrate: uno dettato dalla capacità di elaborazione assoluta del chip, l'altro dalla quantità di dati messi a disposizione del chip stesso. Siccome mi interessa valutare il primo, ho bisogno che il secondo non sia in grado di influenzare il risultato.
nelle rop's vengono eseguite operazioni di blending oltre ad alpha test, color test, depth test.
Per quanto riguarda il discorso sull'efficienza, non è che le rop's di nv31 siano meno efficienti in assoluto; lo sono, eventualmente, solo in relazione all'esecuzione di alcune operazioni (stencil e depth ops in particolare) e quindi con motori grafici che le sfruttano (quello di Doom3 ad esempio). In realtà, se fosse come sospetto, le rop's di nv31 e nv34 non sarebbero troppo diverse da quelle di r300. La minor efficienza di questi due chip deriva essenzialmente dall'architettura delle pixel pipeline e risulta ancora più evidente, rispetto a quella di Nv30 e NV35, a causa dell'assenza della seconda tmu e per il fatto di avere un numero di alu inferiori per ogni pipeline (basta vedere i dati relativi, ad esempio, al fillrate di nv31 in presenza di texture fetch e operazioni matematiche contemporaneamente).
Quello che sto cercando di capire è semplicemente se le rop's di nv31, nv34 e nv36 sono diverse da quelle di nv30 e di nv35 oppure no (al di là dei discorsi sull'efficienza)
non è che a risoluzioni inferiori la gpu lavori a velocità più elevata; la velocità di elaborazione teorica è sempre la stessa mentre quella che varia è la velocità di riempimento del quadro. La bandwidth, inoltre, non è determinata dalla sola ampiezza del canale di comunicazione tra gpu e ram ma dal prodotto di questa ampiezza per la frequenza di lavoro delle ram. Quindi, più che un indice relativo alla velocità di elaborazione della gpu, è un indice della capacità massima della ram di scambiare dati con la gpu stessa. Aumentando la risoluzione la quantità di dati scambiati aumenta e, ovviamente, può arrivare a superare questo limite. Nel qual caso si creano code con dati che vengono letteralmente "messi in attesa di trovare un posto libero" e ciò, di conseguenza, rallenta tutte le operazioni di calcolo. Aggiungi a questo che la ram video contiene non solo il frame buffer ma anche texture buffer, z-buffer, pixel buffer (solo per citare i più noti) e le dimensioni di tutti crescono all'aumentare della risoluzione. I modi in cui, poi, la quantità di dati scambiati possa influenzare la velocità di elaborazione del chip, sono molteplici. Un chip non è un sistema perfetto in cui, ad ogni ciclo di clock, tutte le unità di calcolo sono impegnate a fare qualcosa. Esistono, in ogni elaborazione, tempi morti fisiologici (infatti sarebbe corretto dire che, ad esempio un chip con 8 pipeline di r4ndering e 1 tmu e 2 alu per pipeline, è capace di un massimo di 24 operazioni operazioni per ciclo, piuttosto che compie 24 operazioni per ciclo); questi tempi morti aumentano se la velocità di accesso ai dati è rallentata. Tutti i dati elaborati dal chip passano attraverso il bus e, aumentando la quantità dei dati, aumenta anche il numero di quelli, tra di essi, che sono costretti a "fare la fila"; tieni conto, inoltre, che i dati viaggiano contemporaneamente in entrambi i sensi e che la priorità viene assegnata loro da un controller che stabilisce, in base ai segnali che riceve dal chip, quali dati devono passare in quel momento; altro elemento da non trascurare è quello relativo al rapporto tra dimensioni delle cache interne e quantità dei dati necessari ad una certa elaborazione: è evidente che, ad esempio, l'utilizzo di texture a risoluzione inferiore diminuisce la quantità di dati relativa e aumenta la velocità di esecuzione (più dati, relativi ad una specifica elaborazione, è possibile caricare on chip, più quella elaborazione risulterà veloce)
A bilanciare, in parte, questi effetti negativi, c'è il fatto che aumentando la risoluzione il chip deve elaborare molti più pixel per ogni quadro e, di conseguenza, si riduce il numero dei fps e quello degli intervalli di tempo tra un frame e il successivo (che per un chip sta a significare un intervallo di tempo lunghissimo di inattività).
Di fatto, quindi, esistono due possibili limiti per il fillrate: uno dettato dalla capacità di elaborazione assoluta del chip, l'altro dalla quantità di dati messi a disposizione del chip stesso. Siccome mi interessa valutare il primo, ho bisogno che il secondo non sia in grado di influenzare il risultato.
Quindi, se ho ben capito, all'aumentare della risoluzione i dati che devono transitare tra chip e ram aumentano in misura maggiore rispetto a quelli che deve eleborare il chip per "riempire" completamente il frame. Però non capisco: se a 640x480 ho un certo carico sia di GPU che di banda, a 1600x1200 le proprozioni fra i due carichi dovrebbero rimanere uguali, no? Eppure questo appena detto contrasta con quanto indicato sopra... c'è qualcosa che mi sfugge.
nelle rop's vengono eseguite operazioni di blending oltre ad alpha test, color test, depth test.
Per quanto riguarda il discorso sull'efficienza, non è che le rop's di nv31 siano meno efficienti in assoluto; lo sono, eventualmente, solo in relazione all'esecuzione di alcune operazioni (stencil e depth ops in particolare) e quindi con motori grafici che le sfruttano (quello di Doom3 ad esempio). In realtà, se fosse come sospetto, le rop's di nv31 e nv34 non sarebbero troppo diverse da quelle di r300. La minor efficienza di questi due chip deriva essenzialmente dall'architettura delle pixel pipeline e risulta ancora più evidente, rispetto a quella di Nv30 e NV35, a causa dell'assenza della seconda tmu e per il fatto di avere un numero di alu inferiori per ogni pipeline (basta vedere i dati relativi, ad esempio, al fillrate di nv31 in presenza di texture fetch e operazioni matematiche contemporaneamente).
Quello che sto cercando di capire è semplicemente se le rop's di nv31, nv34 e nv36 sono diverse da quelle di nv30 e di nv35 oppure no (al di là dei discorsi sull'efficienza)
Ho capito perfettamente. Thanks! ;)
Ciao grazie! :)
yossarian
25-04-2005, 22:00
Quindi, se ho ben capito, all'aumentare della risoluzione i dati che devono transitare tra chip e ram aumentano in misura maggiore rispetto a quelli che deve eleborare il chip per "riempire" completamente il frame. Però non capisco: se a 640x480 ho un certo carico sia di GPU che di banda, a 1600x1200 le proprozioni fra i due carichi dovrebbero rimanere uguali, no? Eppure questo appena detto contrasta con quanto indicato sopra... c'è qualcosa che mi sfugge.
Ciao grazie! :)
le proporzioni tra i due carichi, al variare della risoluzione non restano affatto costanti, a meno di pensare di avere una bandwidth teoricamente infinita (o anche un fillrate infinito, nel caso di limitazioni dovute alla capacità d'elaborazione del chip); la banda passante non può assolutamente andare oltre un certo limite e la sua limitazione condiziona anche la velocità d'elaborazione del chip. Nel momento in cui la banda è satura il chip non può ricevere tutti i dati necessari per tempo e il fillrate diminuisce.
le proporzioni tra i due carichi, al variare della risoluzione non restano affatto costanti, a meno di pensare di avere una bandwidth teoricamente infinita (o anche un fillrate infinito, nel caso di limitazioni dovute alla capacità d'elaborazione del chip); la banda passante non può assolutamente andare oltre un certo limite e la sua limitazione condiziona anche la velocità d'elaborazione del chip. Nel momento in cui la banda è satura il chip non può ricevere tutti i dati necessari e il fillrate diminuisce.
Si, ma a una basse risoluzione, il chip fa molto in fretta a completare il frame e a chiedere nuovi dati. Faccio un esempio per chiarirmi: mettiamo che a 1600x1200 dovrebbe metterci 40 millisecondi, chiedendo alla ram 4 MB di dati. A 800x600 i dati richiesti alla RAM saranno solo 1/4, quindi 1 MB, ma il il chip impiegherà solo 1/4 del tempo originario a completare il frame (quindi ci metterà 10 millisecondi). Di conseguenza, nella stessa unità di tempo il chip potrà elaborare 4 frame, per un totale di 4 MB richieste alla RAM (1MB x 4 frame).
Da ciò che hai esposto sopra è chiaro che il ragionamento, seppur apparentemente corretto, non sia valido e non ho dubbi di questo. Mi chiedo piuttosto perchè non sia valido. In sintesi: cosa mi sfugge? :confused:
Ciao grazie.
yossarian
25-04-2005, 22:22
Si, ma a una basse risoluzione, il chip fa molto in fretta a completare il frame e a chiedere nuovi dati. Faccio un esempio per chiarirmi: mettiamo che a 1600x1200 dovrebbe metterci 40 millisecondi, chiedendo alla ram 4 MB di dati. A 800x600 i dati richiesti alla RAM saranno solo 1/4, quindi 1 MB, ma il il chip impiegherà solo 1/4 del tempo originario a completare il frame (quindi ci metterà 10 millisecondi). Di conseguenza, nella stessa unità di tempo il chip potrà elaborare 4 frame, per un totale di 4 MB richieste alla RAM (1MB x 4 frame).
Da ciò che hai esposto sopra è chiaro che il ragionamento, seppur apparentemente corretto, non sia valido e non ho dubbi di questo. Mi chiedo piuttosto perchè non sia valido. In sintesi: cosa mi sfugge? :confused:
Ciao grazie.
quello che ti sfugge è che all'aumentare della risoluzione il chip potrebbe aver bisogno di più informazioni di quelle che, di fatto, riescono a passare attraverso il canale di comunicazione. Se ho un ponte attraverso cui passano solo 8 auto per volta e mi serve che passino delle auto bianche, se il traffico è limitato le auto bianche passano senza problemi insieme alle altre; se il traffico aumenta può succedere che, nel momento in cui deve passare un'auto bianca il ponte sia già pieno di auto di altri colori. Di conseguenza la frequenza con cui passano le auto bianche può diminuire (e la diminuzione è proporzionale all'aumento del traffico).
Nell'esempio da te citato, supponi, ad esempio, che la bandwidth sia di soli 2 Mb; a 800x600 non ci sono problemi; a 1600x1200 credi che l'elaborazione sarebbe altrettanto veloce?
Nell'esempio da te citato, supponi, ad esempio, che la bandwidth sia di soli 2 Mb; a 800x600 non ci sono problemi; a 1600x1200 credi che l'elaborazione sarebbe altrettanto veloce?
L'elaborazione sarebbe più lenta a livello di fps, ma non di pixel rate. Ipotizziamo che tra chip e ram ci sia una banda di 2 MB ogni 40 millisecondi (data del tutto fantasioso). A 800x600 riuscirei ad elaborare solo 2 frame, quindi 800*600*2 pixel, cioè 960.000 pixel, nonostante il chip possa elaborare 4 frame ogni 40 millisecondi. A causa dell'insufficenza di banda sprecherei quindi il 50% del mio fill rate.
A 1600x1200 mi servirebbero 4 MB di dati, quindi o aspetto 80 millisecondi o uso i 2 MB trasferiti in 40 millisecondi per creare una metà del frame, producendo in entrambi i casi 1600*1200*1/2 pixel, cioè 960.000 pixel. Anche in questo caso, sprecheri la metà del mio fill rate teorico, così come nell'ipotesi della risoluzione di 800x600. In pratica le proporzioni di lavoro dei carichi GPU/RAM rimarrebbero le stesse.
Giusto? :)
yossarian
25-04-2005, 22:49
L'elaborazione sarebbe più lenta a livello di fps, ma non di pixel rate. Ipotizziamo che tra chip e ram ci sia una banda di 2 MB ogni 40 millisecondi (data del tutto fantasioso). A 800x600 riuscirei ad elaborare solo 2 frame, quindi 800*600*2 pixel, cioè 960.000 pixel, nonostante il chip possa elaborare 4 frame ogni 40 millisecondi. A causa dell'insufficenza di banda sprecherei quindi il 50% del mio fill rate.
A 1600x1200 mi servirebbero 4 MB di dati, quindi o aspetto 80 millisecondi o uso i 2 MB trasferiti in 40 millisecondi per creare una metà del frame, producendo in entrambi i casi 1600*1200*1/2 pixel, cioè 960.000 pixel. Anche in questo caso, sprecheri la metà del mio fill rate teorico, così come nell'ipotesi della risoluzione di 800x600. In pratica le proporzioni di lavoro dei carichi GPU/RAM rimarrebbero le stesse.
Giusto? :)
sia a 800x600 che a 1600x1200 elaboro un frame per volta; o meglio, a 800x600 ci riesco, a 1600x1200, invece, per ogni frame ho bisogno del doppio della bandwidth disponibile. Quindi, mentre nel primo caso l'elaborazione non sarà mai limitata dalla bandwidth nel secondo si; questo perchè non è la velocità del chip ma quella con cui la ram lavora (si svuota e si riempie) e stabilire il limite alla velocità di elaborazione.
Il carico di lavoro non può mantenere le stesse proporzioni; mi sembra evidente. Se nel primo caso, ogni 20 ms elaboro un frame e dopo 80 ms avrò 4 frame, alla risoluzione più elevata, in 80 ms, non sarò riuscito ad elaborare un singolo frame.
p.s. spero di essermi riuscito a spiegare
Il carico di lavoro non può mantenere le stesse proporzioni; mi sembra evidente. Se nel primo caso, ogni 20 ms elaboro un frame e dopo 80 ms avrò 4 frame, alla risoluzione più elevata, in 80 ms, non sarò riuscito ad elaborare un singolo frame.
Ecco, qui non capisco. Dopo 80 millesecondi avrò 4 frame a 800x600 e 1 frame a 1600x1200, pareggiando di fatto il pixel rate. Perchè dici che a 1600x1200, dopo 80 millisecondi, non avrei neppure un frame? Se dopo 80 millesecondi ho 4 frame da 800x600, ho raggiunto il numero di pixel necessari per comporne uno da 1600x1200, no?
Ti allego i risultati del test a due risoluzioni distinte e a due clock diversi(sorry ma il mio LCD arriva solo a 1280x1024):
GPU 412 / MEM 364
Display adapter: RADEON 9800 XT
Driver version: 6.14.10.6525
Display mode: 800x600 A8R8G8B8 60Hz
Z-Buffer format: D24X8
--------------------------
FFP - Pure fillrate - 2783.511719M pixels/sec
FFP - Z pixel rate - 2798.670898M pixels/sec
FFP - Single texture - 2275.760986M pixels/sec
FFP - Dual texture - 1332.942505M pixels/sec
FFP - Triple texture - 873.367371M pixels/sec
FFP - Quad texture - 621.002686M pixels/sec
PS 1.1 - Simple - 1603.232300M pixels/sec
PS 1.4 - Simple - 1077.633789M pixels/sec
PS 2.0 - Simple - 1603.288940M pixels/sec
PS 2.0 PP - Simple - 1603.228516M pixels/sec
PS 2.0 - Longer - 811.569519M pixels/sec
PS 2.0 PP - Longer - 811.572327M pixels/sec
PS 2.0 - Longer 4 Registers - 650.876343M pixels/sec
PS 2.0 PP - Longer 4 Registers - 650.874817M pixels/sec
PS 2.0 - Per Pixel Lighting - 233.117447M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 233.117447M pixels/sec
--------------------------
Display adapter: RADEON 9800 XT
Driver version: 6.14.10.6525
Display mode: 1280x1024 X8R8G8B8 60Hz
Z-Buffer format: D24X8
--------------------------
FFP - Pure fillrate - 2859.840576M pixels/sec
FFP - Z pixel rate - 2774.573975M pixels/sec
FFP - Single texture - 2778.471191M pixels/sec
FFP - Dual texture - 1535.709473M pixels/sec
FFP - Triple texture - 816.538696M pixels/sec
FFP - Quad texture - 673.659119M pixels/sec
PS 1.1 - Simple - 1624.623047M pixels/sec
PS 1.4 - Simple - 1087.431885M pixels/sec
PS 2.0 - Simple - 1624.625977M pixels/sec
PS 2.0 PP - Simple - 1624.629395M pixels/sec
PS 2.0 - Longer - 817.219727M pixels/sec
PS 2.0 PP - Longer - 817.207214M pixels/sec
PS 2.0 - Longer 4 Registers - 654.550354M pixels/sec
PS 2.0 PP - Longer 4 Registers - 654.549438M pixels/sec
PS 2.0 - Per Pixel Lighting - 234.092712M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 234.094025M pixels/sec
GPU 412 / MEM 333
Display adapter: RADEON 9800 XT
Driver version: 6.14.10.6525
Display mode: 800x600 A8R8G8B8 60Hz
Z-Buffer format: D24X8
--------------------------
FFP - Pure fillrate - 2540.945313M pixels/sec
FFP - Z pixel rate - 2757.090332M pixels/sec
FFP - Single texture - 2120.983398M pixels/sec
FFP - Dual texture - 1262.939575M pixels/sec
FFP - Triple texture - 822.534058M pixels/sec
FFP - Quad texture - 472.860840M pixels/sec
PS 1.1 - Simple - 1603.234009M pixels/sec
PS 1.4 - Simple - 1077.636475M pixels/sec
PS 2.0 - Simple - 1603.231689M pixels/sec
PS 2.0 PP - Simple - 1603.249878M pixels/sec
PS 2.0 - Longer - 811.598816M pixels/sec
PS 2.0 PP - Longer - 811.585205M pixels/sec
PS 2.0 - Longer 4 Registers - 650.881897M pixels/sec
PS 2.0 PP - Longer 4 Registers - 650.878113M pixels/sec
PS 2.0 - Per Pixel Lighting - 233.306198M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 233.306885M pixels/sec
--------------------------
Display adapter: RADEON 9800 XT
Driver version: 6.14.10.6525
Display mode: 1280x1024 A8R8G8B8 60Hz
Z-Buffer format: D24X8
--------------------------
FFP - Pure fillrate - 2614.524170M pixels/sec
FFP - Z pixel rate - 2752.305908M pixels/sec
FFP - Single texture - 2559.721680M pixels/sec
FFP - Dual texture - 1474.295776M pixels/sec
FFP - Triple texture - 978.377258M pixels/sec
FFP - Quad texture - 622.550415M pixels/sec
PS 1.1 - Simple - 1624.701538M pixels/sec
PS 1.4 - Simple - 1087.869507M pixels/sec
PS 2.0 - Simple - 1624.713745M pixels/sec
PS 2.0 PP - Simple - 1624.704956M pixels/sec
PS 2.0 - Longer - 817.713196M pixels/sec
PS 2.0 PP - Longer - 817.707825M pixels/sec
PS 2.0 - Longer 4 Registers - 655.036011M pixels/sec
PS 2.0 PP - Longer 4 Registers - 655.038696M pixels/sec
PS 2.0 - Per Pixel Lighting - 234.298447M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 234.296188M pixels/sec
Come vedi, al diminuire della frequenza delle RAM, i dati relativi al fill rate scendono, quindi suppongo che il collo di bottiglia sia la bandwidth. Nonostante ciò, sia a 800x600 che a 1280x1024 ottengo gli stessi risultati (anzi a 1280x1024 sono superiori, suppongo grazie alla minore incidenza di variabili attribuibili ai driver e ai dati geometrici).
Ciao. :)
yossarian
26-04-2005, 00:11
questi dati, relativi al pixel fillrate, dimostrano che la bandwidth influenza non solo il frame rate ma anche il fillrate; per avere ulteriore prova di questo, effettua un test a risoluzione bassissima (ad esempio 320x240), in modo da non essere comunque limitato dalla bandwidth, con e senza AA e Aniso (magari impostandoli a 4x e 16x rispettivamente): noterai una differenza minima tra i valori del pure fillrate, dovute, per lo più, al fatto che l'elaborazione è un po' più complessa con i filtri attivi (limite quindi del chip). Ripeti lo stesso esperimento a risoluzioni più elevate (1024x768 va più che bene) e confronta gli stessi dati (sicuramente, in questo caso, con i filtri on, sei bandwidth limited). All'aumentare della risoluzione (senza filtri attivi) aumenta il fillrate perchè, oltre ad aumentare i pixel per ogni frame, diminuisce il numero di "interruzioni" tra un frame e il successivo che rappresentano tempi di inattività (o di scarsa attività) per l'elaborazione (il test, se non ricordo male, non fa uso di immagini 3D e quindi non c'è calo dovuto alla maggiore complessità geometrica). La ram, d'altra parte, non è un contenitore da riempire e da svuotare ma compie un lavoro e ha dei tempi tecnici oltre i quali non può andare. Quindi la velocità di elaborazione dipende da due elementi: la velocità del chip e quella della ram. Se la ram lavora a 315 Mhz vuol dire che non può scambiare più di 10000 GB/sec con un bus di 128 bit. Se il chip ha una velocità teorica, per un certo tipo di elaborazione, di 12500 GB/sec di dati, il limite sarà, comunque, fissato dai 10000 GB della ram (e non c'è verso di andare oltre, tranne, ovviamente che con l'overclock della ram stessa, ma anche questa pratica ha un limite fisico invalicabile). In una situazione prettamente ideale, in cui non teniamo conto dei tempi morti, la situazione può essere schematizzata in questo modo:
se a 640x480 il chip ha bisogno di elaborare 2000 GB di dati per completare un frame, in 1 secondo elaborerà 5 frame, a 1600x1200 non sarà riuscito ad elaborarne nemmeno 1. Dopo 2 secondi avremmo 10 frame a 640x480 e solo 1 a 1600x1200; dopo 3 secondi il rapporto sarà 15:2 per poi diventare di 20:3, 25:4, 30:4.
Nel primo caso, il sistema non è limitato dalla bandwidth e il chip riceve senza problemi tutti i dati di cui, di volta in volta, ha bisogno per completare il frame. Nel secondo, invece, il sistema è limitato in banda e i dati che arrivano al chip, o che dal chip vanno verso la ram, sono in quantità superiore a quelli che la ram stessa può scambiare in un secondo. In un sistema "ideale" il fillrate resta, grosso modo, costante; in realtà, però, non abbiamo a che fare con un sistema ideale e il ritardo di alcuni dati (tenendo anche conto che buona parte delle operazioni si svolgono on chip) può causare l'inattività temporanea di qualche unità di calcolo o di un'intera pipeline (questo senza tener conto dei tempi tecnici del vertical blanking). Di conseguenza, una limitazione in banda rischia di influenzare negativamente anche il fillrate del chip. Questo perchè più il traffico aumenta e maggiori sono le probabilità che il controller non riesca a smaltirlo tutto per tempo, creando rallentamenti nell'elaborazione e diminuendo l'efficienza complessiva.
questi dati, relativi al pixel fillrate, dimostrano che la bandwidth influenza non solo il frame rate ma anche il fillrate; per avere ulteriore prova di questo, effettua un test a risoluzione bassissima (ad esempio 320x240), in modo da non essere comunque limitato dalla bandwidth, con e senza AA e Aniso (magari impostandoli a 4x e 16x rispettivamente): noterai una differenza minima tra i valori del pure fillrate, dovute, per lo più, al fatto che l'elaborazione è un po' più complessa con i filtri attivi (limite quindi del chip). Ripeti lo stesso esperimento a risoluzioni più elevate (1024x768 va più che bene) e confronta gli stessi dati (sicuramente, in questo caso, con i filtri on, sei bandwidth limited). All'aumentare della risoluzione (senza filtri attivi) aumenta il fillrate perchè, oltre ad aumentare i pixel per ogni frame, diminuisce il numero di "interruzioni" tra un frame e il successivo che rappresentano tempi di inattività (o di scarsa attività) per l'elaborazione (il test, se non ricordo male, non fa uso di immagini 3D e quindi non c'è calo dovuto alla maggiore complessità geometrica). La ram, d'altra parte, non è un contenitore da riempire e da svuotare ma compie un lavoro e ha dei tempi tecnici oltre i quali non può andare. Quindi la velocità di elaborazione dipende da due elementi: la velocità del chip e quella della ram. Se la ram lavora a 315 Mhz vuol dire che non può scambiare più di 10000 GB/sec con un bus di 128 bit. Se il chip ha una velocità teorica, per un certo tipo di elaborazione, di 12500 GB/sec di dati, il limite sarà, comunque, fissato dai 10000 GB della ram (e non c'è verso di andare oltre, tranne, ovviamente che con l'overclock della ram stessa, ma anche questa pratica ha un limite fisico invalicabile). In una situazione prettamente ideale, in cui non teniamo conto dei tempi morti, la situazione può essere schematizzata in questo modo:
se a 640x480 il chip ha bisogno di elaborare 2000 GB di dati per completare un frame, in 1 secondo elaborerà 5 frame, a 1600x1200 non sarà riuscito ad elaborarne nemmeno 1. Dopo 2 secondi avremmo 10 frame a 640x480 e solo 1 a 1600x1200; dopo 3 secondi il rapporto sarà 15:2 per poi diventare di 20:3, 25:4, 30:4.
Nel primo caso, il sistema non è limitato dalla bandwidth e il chip riceve senza problemi tutti i dati di cui, di volta in volta, ha bisogno per completare il frame. Nel secondo, invece, il sistema è limitato in banda e i dati che arrivano al chip, o che dal chip vanno verso la ram, sono in quantità superiore a quelli che la ram stessa può scambiare in un secondo. In un sistema "ideale" il fillrate resta, grosso modo, costante; in realtà, però, non abbiamo a che fare con un sistema ideale e il ritardo di alcuni dati (tenendo anche conto che buona parte delle operazioni si svolgono on chip) può causare l'inattività temporanea di qualche unità di calcolo o di un'intera pipeline (questo senza tener conto dei tempi tecnici del vertical blanking). Di conseguenza, una limitazione in banda rischia di influenzare negativamente anche il fillrate del chip. Questo perchè più il traffico aumenta e maggiori sono le probabilità che il controller non riesca a smaltirlo tutto per tempo, creando rallentamenti nell'elaborazione e diminuendo l'efficienza complessiva.
Bene, nell'esempio da te postato, dopo 1 secondo e 1/4 avrò eleborato il mio primo frame a 1600x1200, composto da 1.920.000 pixel. A 640x480, avrò invece elaborato poco (molto poco) più di 6 frame, per un totale anche qui di circa 1.900.000 pixel. Il pixel-rate quindi (fill-rate se preferisci) rimmarrà pressapoco uguale...
Quindi, anche se 1 frame a 1600x1200 impiegherà un tempo 6,25 volte maggiore ad essere completato rispetto ad un frame fatto a 640x480, il frame a 1600x1200 conterrà 6,25 volte più pixel ;)
Nel tuo esempio sono quindi limitato a entrambe le risoluzioni dalla banda:
-) a 640x480, nonostante il chip possa elaborare 12500 GB di dati, ne potrà avere a disposizione solo 10000 per un totale di 1.536.000 pixel renderizzati;
-) a 1600x1200 in 1 secondo non riesco a completare un frame; fermo restando che avrò elaborato dati per 10000 GB, avro completato solo l'80% del mio frame, quindi 1600*1200*80/100 pixel, cioè 1.536.000 pixel.
Naturalmente, come ben sottolinei tu, questo avverrà in situazioni ideali, cioè utopistiche :D
Ciao. :)
yossarian
26-04-2005, 14:25
Bene, nell'esempio da te postato, dopo 1 secondo e 1/4 avrò eleborato il mio primo frame a 1600x1200, composto da 1.920.000 pixel. A 640x480, avrò invece elaborato poco (molto poco) più di 6 frame, per un totale anche qui di circa 1.900.000 pixel. Il pixel-rate quindi (fill-rate se preferisci) rimmarrà pressapoco uguale...
Quindi, anche se 1 frame a 1600x1200 impiegherà un tempo 6,25 volte maggiore ad essere completato rispetto ad un frame fatto a 640x480, il frame a 1600x1200 conterrà 6,25 volte più pixel ;)
Nel tuo esempio sono quindi limitato a entrambe le risoluzioni dalla banda:
-) a 640x480, nonostante il chip possa elaborare 12500 GB di dati, ne potrà avere a disposizione solo 10000 per un totale di 1.536.000 pixel renderizzati;
-) a 1600x1200 in 1 secondo non riesco a completare un frame; fermo restando che avrò elaborato dati per 10000 GB, avro completato solo l'80% del mio frame, quindi 1600*1200*80/100 pixel, cioè 1.536.000 pixel.
Naturalmente, come ben sottolinei tu, questo avverrà in situazioni ideali, cioè utopistiche :D
Ciao. :)
L'esempio che ho fatto è relativo alla tua interpretazione (situazione ideale); nella realtà, nel primo caso ho bisogno di soli 2000 GB di dati per elaborare un frame e quello che accade è che, tra un frame e l'altro, il frame buffer viene svuotato; quindi non c'è affatto limitazione in banda. I 12500 GB sono la capacità massima teorica di elaborazione del chip e a 640x480 sfrutta appena 1/6 di questa capacità e 1/5 della banda a disposizione. Nel secondo caso, invece, il primo frame si avrà dopo circa 1,2 secondi; poi si ha lo svuotamento del frame buffer (di cui nel caso ideale non si tiene conto) e quindi il nuovo riempimento (che porta via altri 1,2 secondi). Questo senza tener conto di eventuali elaborazioni in post processing, del fatto che, ad esempio, texture più dettagliate non possono essere caricate interamente on chip e rallentano l'elaborazione, ecc.
Quindi, il limite in banda nel primo esempio, riferito ad una situazione reale, è solo apparente e si limita al caso in cui si consideri l'elaborazione come una serie continua di operazioni, senza alcuna interruzione o rallentamento, cosa che nella realtà è del tutto utopistica. La situazione in cui la capacità di calcolo di un chip sia superiore alla bandwidth è la più comune (soprattutto in caso di elaborazioni "semplici", in cui non si sia, ad esempio, shader bounded o non si richiedano prestazioni di texture lookup superiori alla condizione ideale del chip (quello che succede, ad esempio con Doom 3 e i chip ATi). Invece, il secondo caso è tipico di una situazione bandwidth limited (sempre nel caso ideale), dove la richiesta di dati per singolo frame supera l'ampiezza della banda passante.
Stavolta spero di essermi riuscito a far capire; in caso contrario non hai altro che da fare il test che ti ho consigliato nel post precedente per renderti conto della situazione.
ciao
p.s. il caso ideale non esiste
Franx1508
26-04-2005, 14:41
yoss vieni su nvitalia c'è una cosa molto curiosa... :)
L'esempio che ho fatto è relativo alla tua interpretazione (situazione ideale); nella realtà, nel primo caso ho bisogno di soli 2000 GB di dati per elaborare un frame e quello che accade è che, tra un frame e l'altro, il frame buffer viene svuotato; quindi non c'è affatto limitazione in banda. I 12500 GB sono la capacità massima teorica di elaborazione del chip e a 640x480 sfrutta appena 1/6 di questa capacità e 1/5 della banda a disposizione. Nel secondo caso, invece, il primo frame si avrà dopo circa 1,2 secondi; poi si ha lo svuotamento del frame buffer (di cui nel caso ideale non si tiene conto) e quindi il nuovo riempimento (che porta via altri 1,2 secondi). Questo senza tener conto di eventuali elaborazioni in post processing, del fatto che, ad esempio, texture più dettagliate non possono essere caricate interamente on chip e rallentano l'elaborazione, ecc.
Quindi, il limite in banda nel primo esempio, riferito ad una situazione reale, è solo apparente e si limita al caso in cui si consideri l'elaborazione come una serie continua di operazioni, senza alcuna interruzione o rallentamento, cosa che nella realtà è del tutto utopistica. La situazione in cui la capacità di calcolo di un chip sia superiore alla bandwidth è la più comune (soprattutto in caso di elaborazioni "semplici", in cui non si sia, ad esempio, shader bounded o non si richiedano prestazioni di texture lookup superiori alla condizione ideale del chip (quello che succede, ad esempio con Doom 3 e i chip ATi). Invece, il secondo caso è tipico di una situazione bandwidth limited (sempre nel caso ideale), dove la richiesta di dati per singolo frame supera l'ampiezza della banda passante.
Stavolta spero di essermi riuscito a far capire; in caso contrario non hai altro che da fare il test che ti ho consigliato nel post precedente per renderti conto della situazione.
ciao
p.s. il caso ideale non esiste
Grazia yossarian della tua pazienza,
ora ho capito.
Quello che ho illustrato sopra vale quindi solo nel caso ideale che, come hai ben detto tu, semplicemente non esiste! :)
Ciao grazie ancora! :)
Posto i risultati della mia 6600GT Agp, il sistema in questo caso conta poco (2800+barton, 1 Gb ram)
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce 6600 GT
Driver version: 6.14.10.7189
Display mode: 640x480 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------
FFP - Pure fillrate - 1762.800781M pixels/sec
FFP - Z pixel rate - 3554.157227M pixels/sec
FFP - Single texture - 1444.402344M pixels/sec
FFP - Dual texture - 985.281494M pixels/sec
FFP - Triple texture - 738.395020M pixels/sec
FFP - Quad texture - 587.160828M pixels/sec
PS 1.1 - Simple - 1773.357056M pixels/sec
PS 1.4 - Simple - 1772.912598M pixels/sec
PS 2.0 - Simple - 1774.076294M pixels/sec
PS 2.0 PP - Simple - 1773.894775M pixels/sec
PS 2.0 - Longer - 979.468933M pixels/sec
PS 2.0 PP - Longer - 979.414490M pixels/sec
PS 2.0 - Longer 4 Registers - 979.360352M pixels/sec
PS 2.0 PP - Longer 4 Registers - 979.282776M pixels/sec
PS 2.0 - Per Pixel Lighting - 295.512177M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 421.941986M pixels/sec
Lo ritengo un ottimo risultato, in ambito ludico rispetto alla 5900 (400/850 quindi cloccata a meno) acquisisce migliori effetti in Hl2 a parità di frame rate (acqua in ps 2.0 FP sostanzialmente e soft shadow sui personaggi e ambienti, o almeno più soft di quelle Dx 8.1), peggior Af, miglior FSAA, anche in Doom3 ha un buon vantaggio, ma minore rispetto ad Hl2.
In altri titoli se la giocano, da 1280 in su con i filtri attivati tendono a coincidere le prestazioni qualsiasi sia il titolo in questione. (merito dei 256 bit di banda delle ram)
Peccato che in PP non migliori come le FX.
Pk77
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.