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.

Let's talk about Drivers Doom3 Low Resolution
Comments Locked

36 Comments

View All Comments

  • jediknight - Wednesday, October 13, 2004 - link

    #15 - My bad to make such generalizations..

    but the fact that you can't even use an ATI card to play D3 doesn't bode well for Linux gaming...
  • jensend - Wednesday, October 13, 2004 - link

    #14- bunk. All you can take away from this review is that Windows "owns Linux for" D3 1.1 performance. You can't generalize this for game performance in general. Most games show a less than 5% difference.

    BTW, another article on the same topic with more detail is at http://www.linuxhardware.org/article.pl?sid=04/10/...
  • jediknight - Wednesday, October 13, 2004 - link

    I like the difference pictures.. although when you get up to 8x and 16x, they're probably unnecessary.

    But the thing to take away from this review is that Windows owns Linux for gaming performance.
  • icehot - Wednesday, October 13, 2004 - link

    Interesting article. Was it just me or are the difference maps just pure black? Also I dont think things like 16xAA are really needed, after 2x or 4x the differences between anything higher and the original image is negligable, and definately not noticeable when playing, maybe if you really take the time to admire the scenary, but who does that when fighting monsters??
  • Lwood - Wednesday, October 13, 2004 - link

    According to an article over at LinuxHardware.org, the Linux build of Doom 3 is currently less optimized than the Windows build.
    Most notably SSE2 code is missing (but will be added later) and GCC does not optimize as good as VC.net.
    Details here:
    http://www.linuxhardware.org/article.pl?sid=04/10/...
    I guess we can expect the gap to get smaller in later Doom 3 builds, but not to disappear entirely.
  • ViRGE - Wednesday, October 13, 2004 - link

    Kris, odd, I swear that I was only getting 2 graphs per page when I read the article. I don't know if Firefox is bugging out on me or what.
  • reljam - Wednesday, October 13, 2004 - link

    Kris, please put Windows and Linux numbers on the same graph, you know that people will want to see how they stack up against each other.

    Not clear on why you wouldn't want to do that.
  • jensend - Wednesday, October 13, 2004 - link

    Neither NV nor id has much of a reason to optimize heavily for linux, and it's entirely unsurprising that the windows version performs better. Nevertheless, I expect that the gap will close considerably as the Doom 3 engine matures.
  • Myrandex - Wednesday, October 13, 2004 - link

    The AA pictures won't work for me. When I click on them, I get a new window w/ the alert 'hold your mouse over the picture' and then the page doesn't load. When I hold my mouse over the original image, nothing happens. Also, the black pictures to the right of those are way to black to tell a thing about them. Interesting article though. I wonder if 16X AA would be playable in a lower resolution.
    Jason
  • Lwood - Wednesday, October 13, 2004 - link

    That bit about the 16x AA you can enable in Linux is surely interesting. Maybe you can try this on a less performance-demanding game than Doom 3.
    I'd love to see UT 2004 and Enemy Territory benchmarks for this mode... :-)

Log in

Don't have an account? Sign up now