Parhelia Fill rate or CPU limited??

[DegreeC]

Greebe,
I'll take your word as the definitive answer. After I'm finished unlocking and probably overclocking my XP2400, I'll have to evaluate the need for another CPU/motherboard. Thanks.

[WyWyWyWy]

Damn typo sorry damn typo.
I actually do mean:

In fact I often use 4xFSAA when actually playing games, because I found 4xFSAA gives better quality than 16xFAA even though it is slower... well at least in LiveForSpeed.

Performance is about 20% to 30% lower than 16xFAA.

[DegreeC]

WyWyWyWy,
Yeah, that makes more sense. I'll have to give 4X FSAA a try, although I doubt it will give playable frame rates. What kind of frame rate are you getting in LiveforSpeed? Have you tried Nascar Racing 2002 or Grand Prix4 in surround mode?

[WyWyWyWy]

I got about 50fps average on LFS 16xFAA with everything maxed 1280x960.
about 35 to 40fps average with 4xFSAA.

Sorry I can't try surround mode as I need to have a TV connected for movies.... saying that, I tried dualhead window mode surround, about 30fps (IIRC) 16xFAA in stretch, an 6fps (lol!) in dual independent.

[Novdid]

Originally posted by chhfchhf
4x FSAA is based at multysample
16x FAA is based at supersample
multysample brings lots of data to excute,so need more band width.
supersample needs enhanced fillrate.
in quality,4x FSAA will do good performance.
when use 16x FAA , it is little different with 4x FSAA
but ,when use 4x FSAA,it is slowly than 16x FAA

You got one thing wrong there my friend, The Parhelia 4x FSAA is just plain supersampling.

[Roark]

DegreeC, my comment is intended to indicate that by using any current generation or last generation game you are going to see a large amount of the performance being CPU bound by the inherent design of the game. There is really no cheap or easy way to determine how much of the specific game running is cpu bound because of the game itself versus how much its cpu bound because of the drivers. Its not impossible to do, just takes the right software. and a lot of time on your hands.

My personal experience is that their OpenGL stack is really really CPU bound. using glquake and uncapping the framerates it tops at about 115FPS on my system. on similar systems with NVidia or ATI cards in them people see double or triple those numbers. and since enabling features (ie, FAA or Ansio) drops performance by about 5-15fps total thats a pretty good indication that it wasn't GPU bound. and considering that glquake is just how old i am pretty positive that the application isn't exactly CPU bound at the moment.

DirectX has always been and always will be Matrox's strong point (especially since 2D isn't anymore) so i would expect it to be quite a bit less CPU bound in DX compared to OGL, but i honestly have not put any effort into testing it...

[Greebe]

(especially since 2D isn't anymore)

Pardon?

[DegreeC]

Roark,
I have to agree that OpenGL drivers do not appear to be Matrox's strong suit. In my limited testing of Games like IL-2 and NR2002, the DirectX framerates are about 20% btetter than the OpenGL numbers. Alas, the surround gaming resolution is limited to 1920X480 in DirectX. Even with 16X FAA this resolution isn't very pretty.

[Kruzin]

Originally posted by DegreeC
Alas, the surround gaming resolution is limited to 1920X480 in DirectX.

This is only true of DX7 games. DX8 games can go to higher resolultions.

[Roark]

Originally posted by Greebe
Pardon?

*cough*banding*cough*

Although thats not really a 2d thing... kinda is kinda isn't...

there are other things i've seen where the GUI Acceleration in XP causes issues with DX apps when running, the overlay problems (although Matrox has stated that its because they are using a more advanced overlay scheme and developers need to follow suite... still, "more advanced" should not mean "old apps won't work", especially ones that were designed around the Gxxx series and work perfectly on them), i see a lot of font corruption when FAA and GlyphAA are both in use (including the complete failure to draw text using certain fonts), etc...

signal quality is one thing... but the data contained in the signal is another... both have to be good for it to be a good 2d card...

granted, almost all of these problems in some way shape or form tie occur only when you are running 3d applications... so its arguable... but this is not particularly the thread for it to be discussed in detail...

[Greebe]

poppycock

and if it's not to discussed then it shouldn't have entered the conversation in the first place

[Kurt]

Originally posted by chhfchhf
sir, i did a examination a moument ago
when core/ram at 200/500 ,3dmark2001pro point is 6704
when core/ram at 166/415 ,3dmark2001pro point is 59xx
when core/ram at 207/550 ,3dmark2001pro point is 6795
i find that the score is not altered distinctly when core/ram changed.

the Band width of parhelia is 512*200=10GB/s
the band width of ram is 256*500=16GB/s

i consider the GPU is not full load in the benchmark!

Greebe (or whomever knows best), what chhfchhf means is that the limitation is not on memory bandwith but on the core that can't "process" more than 10GB/s as opposed to 16GB/s for the memory subsystem, according to his calculations.

The question is: are they valid?

If so, the memory subsystem is of importance when it can't feed the GPU core. But what of the memory bus efficiency? and that of the GPU? i.e., what's their usable bandwith? There's no way the memory will supply 16GB/s, that's only peak bandwith. If efficiency is 50% (which is already pretty good) we'd be at only 8GB/s. Same story for the GPU.

Can anyone provide an NDA-approximated yes-or-noed answer?

[chhfchhf]

kurt:
i do not consider the core can't fit the ram.
the Parhelia is very oddity!
My Parhelia's fillrate is 24xxMP/s

[Kurt]

I understand what you say.

I think your tests show that the Parhelia chip is too slow.

The P chip has some fast parts and some slow parts. The fast parts need fast memory. The slow parts do not need the fast memory.

The test show (I think) that the P chip is not very well balanced in its performance. Sometimes memory is more important, sometimes the chip speed is more important. So it is difficult to obtain faster speeds in programs when you cannot know if the chip or the memory can go faster.

(I hope its clear )