Doom3 Linux and Windows Battlegrounds

The Test

Below, you can see our test rig configuration. The ATI cards have been removed, since they do not run on the Linux configuration.

Performance Test Configuration
Processor(s):	AMD Athlon 64 3800+ (130nm, 2.4GHz, 512KB L2 Cache)
RAM:	2 x 512MB Mushkin PC-3200 CL2 (400MHz)
Motherboards:	MSI K8T Neo2 (Socket 939)
Memory Timings:	Default
Hard Drive(s):	Seagate 7200.7 120GB SATA
Video Card(s):	GeForce 6800 Ultra 256MB GeForce 6800 128MB GeForceFX 5950 Ultra 256MB GeForceFX 5900 Ultra 128MB GeForceFX 5700 Ultra 128MB GeForceFX 5600XT 128MB
Operating System(s):	SuSE 9.1 Professional (kernel 2.6.8-14-default) Windows XP SP2
Driver:	NVIDIA 1.0-6111 Detonator 61.77

Our testing procedure is very simple. We take our various video cards and run respective time demos while using our AnandTech FrameGetter utility. We rely on in-game benchmarks for some of our tests as well. We post the average frames per second scores calculated by the utility. Remember, FG calculates the frames per second every second, but it also tells us the time our demo ran, and how many frames it took. This average is posted for most benchmarks, but where we want to illustrate important differences, we also show the average FPS per second.

For Doom3, we do not run the "timedemo" command, only the "playdemo" command. Timedemo changes the speed of the playback - that's not what we are interested in, since it skews our results in FrameGetter. We also appended a "-" after the demo to enable pre-caching.

Much to our delight, version 0.1.0 of our FrameGetter utility that we released last week works correctly with Doom3. For Windows, we are still using FRAPS to record our timedemo information, although we are working actively on getting the AnandTech FrameGetter ported over to Windows.

All of our benchmarks are run three times and the highest scores obtained are taken - and as a general trend, the highest score is usually the second or third pass at the timedemo. Why don't we take the median values and standard deviation? For one, IO bottlenecks tend to occur due to the hard drive and memory, even though they "theoretically" should behave the same every time we run the program. Memory hogs like Doom3 and UT2004 that tend to also load a lot of data off the hard drive are notorious for behaving strangely on the first few passes, even though we are using the pre-caching option.