Parhelia 3DMark scores-Detailed

B

ben6

Regular
1024x768 32bit
no FAA no anisotropic 16x FAA no aniso 16x FAA aniso
3dmarks 6560 5451 4919
Game1 Low 98.2 77.1 67..2
Game1 High 40.2 39.1 36.6
Game2 Low 100.4 76.2 68.1
Game2 High 63.1 47.2 43.9
Game3 Low 102.0 87.7 78.9
Game3 High 49.9 47.1 44.7
Game4 24.5 18.6 13.7
Fill Single 746.5 713.0 707.3
Fill Multi 1663.5 2520.3 1653..5
High Poly 1 25,2 17.0 17.0
High Poly 8 11.0 10.1 10.1
RMBM 103.4 77.1 60.2
Dot3 75.6 59.5 39.6
Vertex Shader 77.6 42,3 26.0
Pixel Shader 66.8 49.6 41.6
Adv Pix Shader 59.2 40.8 28.1
Point Sprites 14.1 7.4 7.4


1280X1024
3dmarks 5007 4071 3596
Gane1 L 72.8 55.4 48.5
Game1 H 37.6 32.3 28.4
Gane2 L 70.6 54.2 48.8
Game2 H 47. 35.9 32.7
Game3 L 72.8 61.6 54.0
Game3 H 41.5 37.0 33..8
Game4 15.9 12.8 9.3
F S 715.1 688.5 688.5
F M 1796.8 2466.0 1783.6
H 1 L 23.4 14.7 14.7
H 8 L 10.7 9.3 9.4
EMBM 75.0 57.7 43.7
Dot3 48.6 39.9 27.6
Vertex 59.1 30.4 19.0
Pixel 48.3 35.4 30.5
APS 44.0 31.9 22.8
Point S 11.2 5.8 5.8

Note , I don't know why the fillrate increased so dramatically when using FAA without anisotropic filtering versus no FAA. Other than that one anomaly interesting performance no?

System P4-2Ghz i845 chipset, 512MB PC2100 DDR, SB Live (disabled) Parhelia 512 220/275 clock 18GB UDMA100 HDD 7200RPM, 2MB Cache, 9.5ms seek.

228 Parhelia drivers
 
What puzzles me a bit about your results is the dramatic reduction of Vertex-Shader Performance when combined with FAA & AF. In Theory, geometry and filtering parts of the chip should not have many things in common, at least not to a degree, where geometry performance could be in any way affected by filtering or texturing since they are coming quite a bit afterwards in a 3D-Pipe.

Or does Parhelia have to combine it's VS-Units as well as it's TMUs when filtering anisotropic, i.e. are the single Pipelines linked internally as a whole, so that, when AF is turned on and more (i guess it's eight) TMUs have to be used for that, the vertexshader linked to that Pipe cannot do anything helpful to geometry throughput anymore?
 
Quasar, the vertex shader tests still display things so the quality settings can influence the performance of the vertex shaders if its the pixel side that stalls and bottlenecks.

K-
 
Of course, Kristof.
But Pixel-throughput limiting the Vertex-Power of Parhelia to one quarter of it's normal performance?
Sounds like more, than just the infamous low-clocked Parhelia-Core, imho.
 
Quasar said:
Of course, Kristof.
But Pixel-throughput limiting the Vertex-Power of Parhelia to one quarter of it's normal performance?
Sounds like more, than just the infamous low-clocked Parhelia-Core, imho.
Click to expand...

Well, just look at the two different resolutions. 1280x1024 has 1.67 times the pixels of 1024x768. The score drops by a factor of 1.31. You can see that the test is significantly fill-rate limited, but also significantly vertex-limited. I don't think there is any resource sharing.

I think it would be very interesting to see 640x480x16 scores to see what the drivers/vertex engine is capable of.
 
Hrm , found out what was going on . I had ran 3dmark with 16x FAA and aniso then turned both off without restarting the program. My updated scores are now 6960 3dmarks 2500 mulittextured fillrate more details later
 
As you might have seen already ben6:
One thing about testing different settings in the drivers.
I noticed that when I did some test on my GF2 with fsaaview, the FSAA level wouldn't take effect in D3D until I'd turned off all DX programs. And that included IE. I think it was related to if there were flash animations on the page.

That was of course a different card, but it might work the same way for others.
 
You must log in or register to reply here.
Back
Top