more q3 smp questions

[nufan]

I have been looking around at all the benchmarks for quake3 running on smp machines, and i've made the following observations (which seem strange to me):

quake3 gets little or no boost (usually a decrease in performance!) at the higher-quality settings when using SMP. The lower the resolution and the lower the graphical settings the more smp seems to help. This seems a little strange to me, since you'd think there would be more computation at the higher gfx settings.

here's a quick table of results (using tnt2u.. sorry matrox drivers dont cut it yet) from http://2cpu.com/Games/q3tnt2gf.htm
(resolutions are default for gfx settings, all eyecandy (marks on walls, ejecting brass, etc. were turned off)
GFX - SMP0 - SMP1
-----------------
HQ: - 53.2 - 57.5
NRM: - 69.9 - 85.6
FST: - 78.1 - 101.5
FSTS: - 80.4 - 103.6

I see only two possible reasons for this: a) bottlenecks in hardware, and b) bottlenecks in software
a) The current crop of video cards has lots of nice features, but they are too video-card intensive to use together at resolutions greater than 800x600. - This is unlikely since putting a faster cpu gives you higher fps, yet it describes the current situation the best.
b) Quake and/or the video drivers arent too hot when it comes to smp. - For sure the matrox drivers aren't optimized well in win2k (come on guys! i'm begging! good win2k and good smp support!) and i have the feeling that smp in q3 isn't optimised as well as it could be. (yes, I know better than to expect a 2x increase in speed with 2 cpus)

anyone care to debate with me? i'm open to any and all comments, suggestions, corrections, flames, etc.

-]nufan[-

[absalom]

The limitation is fillrate, simply... fillrate. When you up the res, you give the graphics cards more load... not the cpu. This goes even more so when using 32-bit color/textures. The only case where having excessive cpu overhead in q3 would benefit is if your using A3D sound, handling high poly count, or if your not fillrate bound (like 800x600 using turbogl has proven). At 1024x768+, the cpu (especially a really fast cpu) is constantly waiting on the g400. The needed bandwidth is effectively doubled in that area, depending on the eyecandy involved. If you want 60fps at 1600x1200, then wait for a voodoo5 and it's gigapixel fillrate... if it will actually live up to the hype surrounding it. From what I've seen, neither the g400 or tnt2u have the fillrate to do 1024x768x32 at what I consider adequate fps (insanely overclocked or not). The geforce DDR does in most cases... IMO.

I'd consider the g400 win2k drivers to be very VERY beta. Let the matrox driver team worry about solidity after win2k hits the shelves for consumer use...

In my personal opinion, if you want to see SMP at it's best... run q3 in linux. The glx drivers are extremely flakey at best (agp support in linux is "newborn"). But, who better than the main guru who wrote the q3 engine to have also done the majority of the g400 glx driver. Carmack claims that it actually outperforms the current windows driver.... so take his word for it.

(As of today, I've had no success with getting glx to work on my machine, so I can't really confirm how well it works.)

[This message has been edited by absalom (edited 09 February 2000).]

[nufan]

So it is the video card.. I asked in a previous post what the limitations of the g400 are (see g400 theoretical limitations) and got the answer that the g400 had tons of headroom... and everyone was touting the g400s speed at 1024x32bit... oh well.. marketing hype i guess.

as far as the linux version, i'll run that when i can get the point release for q3linux, which will enable smp support. I actually bought the linux version and got the warez version for windows, and the same cd-key worked, so i couldnt be happier... best of both worlds.

I for one am glad that the folks at id are heavy into linux.. i remember doom and hearing that there was a linux ver of that back in the day...

sidenote: team overlay RULES! turn that option on if you play ctf in q3!

-]nufan[-