DirectX 7 Performance

Below you can see our DirectX 7 based video processor chart:

GF2 GTS 200 333 4 2 0.5 128 1600 25 5081 100.0% 100.0% 100.0% 100.0%
DirectX 7
7500 290 460 2 3 0.5 128 1740 36 7019 108.8% 138.1% 145.0% 130.6%
GF4 MX460 300 550 2 2 0.5 128 1200 38 8392 75.0% 165.2% 150.0% 130.1%
GF2 Ultra 250 460 4 2 0.5 128 2000 31 7019 125.0% 138.1% 125.0% 129.4%
GF2 Ti 250 400 4 2 0.5 128 2000 31 6104 125.0% 120.1% 125.0% 123.4%
GF4 MX440 8X 275 500 2 2 0.5 128 1100 34 7629 68.8% 150.2% 137.5% 118.8%
7500 LE 250 360 2 3 0.5 128 1500 31 5493 93.8% 108.1% 125.0% 109.0%
GF4 MX440 275 400 2 2 0.5 128 1100 34 6104 68.8% 120.1% 137.5% 108.8%
GF2 Pro 200 400 4 2 0.5 128 1600 25 6104 100.0% 120.1% 100.0% 106.7%
7500 AIW 250 333 2 3 0.5 128 1500 31 5081 93.8% 100.0% 125.0% 106.3%
GF2 GTS 200 333 4 2 0.5 128 1600 25 5081 100.0% 100.0% 100.0% 100.0%
GF4 MX440 SE 250 333 2 2 0.5 128 1000 31 5081 62.5% 100.0% 125.0% 95.8%
Radeon DDR 183 366 2 3 0.5 128 1098 23 5585 68.6% 109.9% 91.5% 90.0%
GF4 MX4000 275 400 2 2 0.5 64 1100 34 3052 68.8% 60.1% 137.5% 88.8%
GF4 MX420 250 333 2 2 0.5 64 1000 31 2541 62.5% 50.0% 125.0% 79.2%
Radeon LE 148 296 2 3 0.5 128 888 19 4517 55.5% 88.9% 74.0% 72.8%
GF2 MX400 200 166 2 2 0.5 128 800 25 2541 50.0% 49.8% 100.0% 66.6%
Radeon SDR 166 166 2 3 0.5 128 996 21 2533 62.3% 49.8% 83.0% 65.0%
7200 183 183 2 3 0.5 64 1098 23 1396 68.6% 27.5% 91.5% 62.5%
GF2 MX 175 166 2 2 0.5 128 700 22 2541 43.8% 49.8% 87.5% 60.4%
GeForce 256 DDR 120 300 4 1 0.5 128 480 15 4578 30.0% 90.1% 60.0% 60.0%
GF2 MX200 175 166 2 2 0.5 64 700 22 1266 43.8% 24.9% 87.5% 52.1%
GeForce 256 SDR 120 166 4 1 0.5 128 480 15 2533 30.0% 49.8% 60.0% 46.6%
7000 AGP^ 183 366 1 3 0 64 549 0 2792 34.3% 55.0% 0.0% 29.8%
7000 PCI^ 166 333 1 3 0 64 498 0 2541 31.1% 50.0% 0.0% 27.0%
Radeon VE^ 183 183 1 3 0 64 549 0 1396 34.3% 27.5% 0.0% 20.6%
* RAM clock is the effective clock speed, so 250 MHz DDR is listed as 500 MHz.
** Textures/Pipeline is the maximum number of texture lookups per pipeline.
*** Nvidia says their GFFX cards have a "vertex array", but in practice it generally functions as indicated.
**** Single-texturing fill rate = core speed * pixel pipelines
+ Multi-texturing fill rate = core speed * maximum textures per pipe * pixel pipelines
++ Vertex rates can vary by implementation. The listed values reflect the manufacturers' advertised rates.
+++ Bandwidth is expressed in actual MB/s, where 1 MB = 1024 KB = 1048576 Bytes.
++++ Relative performance is normalized to the GF2 GTS, but these values are at best a rough estimate.
^ Radeon 7000 and VE had their T&L Engine removed, and cannot perform fixed function vertex processing.

Now we're talkin' old school. There are those people in the world that simply can't stand the thought of having less than the latest and greatest hardware on the planet in their PC, and then there are people that have social lives. Okay, it's not that bad, but not everyone needs a super powerful graphics card. In fact, there are plenty of businesses running computers with integrated graphics that would be thoroughly outclassed be even the five year old GeForce 256. If you're only playing older 3D games or just want to get the cheapest non-integrated card you can find, DX7 cards fit the bill. A Home Theater PC that plays movies has no need for anything more, for instance. Or maybe you have a friend that's willing to just give you his old graphics card, and you want to know if it will be better than the piece of junk you already have? Whatever the case, here are the relative performance figures for the DX7 era cards.

No special weighting was used, although with this generation of hardware you might want to pay closer attention to memory bandwidth than the other areas. Fill rate is still important as well, but vertex fill rate is almost a non-issue. In fact, these cards don't even advertise vertex rates - they were measured in triangle rates. Since they had a fixed-function Transform and Lighting (T&L) pipeline, triangles/sec was the standard unit of measurement. The vertex pipelines are listed as "0.5" for the DX7 cards, emphasizing that they are not programmable geometry processors. As luck would have it, 0.5 times clock speed divided by 4 also matches the advertised triangle rates, at least on the NVIDIA cards. Vertex rates are anywhere from two to four times this value, depending on whether or not edges are shared, but again these rates are not achievable with any known benchmark. One item worth pointing out is that the Radeon 7000 and VE parts have had their vertex pipeline deactivated or removed, so they are not true DX7 parts, but they are included as they bear the Radeon name.

Early adopters of the DX7 cards were generally disappointed, as geometry levels in games tended to remain relatively low. First, there was a demo called "Dagoth Moor Zoological Gardens" created for the launch of the original GeForce 256. It was created by a company called "The Whole Experience" and used upwards of 100,000 polygons. Unfortunately, they never released any commercial games using the engine (at least, none that we're aware of). Later, a different company at the launch of the GeForce 2 created a demo that had millions of polygons to show off the "future of gaming" - that company would eventually release a game based off of their engine that you might have hear of, Far Cry. Actually, Crytek Studios demoed for both the original GeForce 2 launch and the GeForce 3 launch. They used the same engine and the demo name "X-isle" was the same as well, but the GF3 version added support for some pixel shader and vertex shader effects. Four years after demonstrating the future, it finally arrived! Really, though, it wasn't that bad. Many games are in development for several years now, so you can't blame them too much for delaying. Besides, launching a game that only runs with the newest hardware is tantamount to financial suicide.

As far as performance is concerned, the GeForce2 was the king of this class of hardware for a long time. After the GeForce 3, NVIDIA revisited DX7 cards with the GF4MX line, which added additional hardware support for antialiasing and hardware bump mapping. While it only had two pixel pipelines in comparison to the 4 of the GF2, the higher core and RAM speeds generally allowed the GF4MX cards to match the GF2 cards, and in certain cases they beat it. The Radeon 7500 was also a decent performer in this class, although it generally trailed the GF2 slightly due to the 2x3 pixel pipeline, which could really only perform three texture operations if two of them came from the same texture. Worthy of mention is the Nforce2 IGP chipset, which included the GF4MX 440 core in place of the normally anemic integrated graphics most motherboards offer. Performance was actually more like the GF4MX420, due to the sharing of memory bandwidth with the CPU and other devices, but it remains one of the fastest performing integrated solutions to this day. Many cards were also crippled by the use of SDR memory or 64-bit buses - we still see such things with modern cards as well, of course. Caveat emptor, as they say. If you have any interest in gaming, stay away from 64-bit buses, and these days even 128-bit buses are becoming insufficient.

Bring on the Crazy Eighty Eight! Is it smaller than a bread box?
POST A COMMENT

43 Comments

View All Comments

  • JarredWalton - Thursday, October 28, 2004 - link

    43 - It should be an option somewhere in the ATI Catalyst Control Center. I don't have an X800 of my own to verify this on, not to mention a lack of applications which use this feature. My comment was more tailored towards people that don't read hardware sites. Typical users really don't know much about their hardware or how to adjust advanced settings, so the default options are what they use. Reply
  • Thera - Tuesday, October 19, 2004 - link

    You say SM2.0b is disabled and consumers don't know how to turn it on. Can you tell us how to enable SM2.0b?

    Thank you.

    (cross posted from video forum)
    Reply
  • endrebjorsvik - Wednesday, September 15, 2004 - link

    WOW!! Very nice article!!

    does anyone have all these datas collected into an exel-file or something??
    Reply
  • JarredWalton - Sunday, September 12, 2004 - link

    Correction to my last post. KiB and MiB and such are meant to be used for size calculations, and then KB and MB can be used for bandwidth calculations. Now the first paragraph (and my gripe) should be a little more clear if you didn't understand it already. Basically, the *bandwidth* companies (hard drives, and to a lesser extent RAM companies advertising bandwidth) proposed that their incorrect calculations stand and that those who wanted to use the old computer calculations should change.

    There are problems, however. HDD and RAM both continue to use both calculations. RAM uses the simplified KB and MB for bandwidth, but the accepted KB and MB (KiB and MiB now) for size. HDD uses the simplified KB and MB for size, but then they use the other KB and MB for sustained transfer rates. So, the proposed change not only failed to address the problem, but the proposers basically continue in the same way as before.
    Reply
  • JarredWalton - Saturday, September 11, 2004 - link

    #38 - there are quite a few cards/chips that were only available in very limited quantities.

    39 - Actually, that is only partially true. KibiBytes and MibiBytes are a *proposed* change as far as I am aware, and they basically allow the HDD and RAM people to continue with their simplified calculations. I believe that KiB and MiB are meant for bandwidths, however, and not memory sizes. The problem is that MB and KB were in existence long before KiB and MiB were proposed. Early computers with 8 KB of RAM (over 40 years ago) had 8192 bytes of RAM, not 8000 bytes. When you buy a 512 MB DIMM, it is 512 * 1048576 bytes, not 512 * 1000000 bytes.

    If a new standard is to be adopted for abbreviations, it is my personal opinion that the parties who did not conform to the old standard are the ones that should change. Since I often look at the low level details of processors and GPUs and such, I do not want to have two different meanings of the same thing, which is what we currently have. Heck, there was even a class action lawsuit against hard drive manufacturers a while back about this "lie". That was the solution: the HDD people basically said, "We're right and in the future 2^10 = KiB, 2^20 = MiB, 2^30 = GiB, etc." Talk about not taking responsibility for your acttions....

    It *IS* a minor point for most people, and relative performance is still the same. Basically, this is one of my pet peeves. It would be like saying, "You know what, 5280 feet per mile is inconvenient Even though it has been this way for ages, let's just call it 5000 feet per mile." I have yet to see any hardware manufacturers actually use KiB or MiB as an abbreviation, and software that has been around for decades still thinks that a KB is 1024 bytes and a MB is 1048576.
    Reply
  • Bonta - Saturday, September 11, 2004 - link

    Jarred, you were wrong about the abbreviation MB.
    1 MB is 1 mega Byte is (1000*1000) Bytes is 1000000 Bytes is 1 million Bytes.
    1 MiB is (1024*1024) Bytes is 1048576 Bytes.

    So the vid card makers (and the hard drive makers) actually have it right, and can keep smiling. It is the people that think 1MB is 1048576 Bytes that have it wrong. I can't pronounce or spell 1 MiB correctly, but it is something like 1 mibiBytes.
    Reply
  • viggen - Friday, September 10, 2004 - link

    Nice article but what's up with the 9200 Pro running at 300mhz for core & memory? I dun remember ATI having such a card.
    Reply
  • JarredWalton - Wednesday, September 8, 2004 - link

    Oops... I forgot the link from Quon. Here it is:

    http://www.appliedmaterials.com/HTMAC/index.html

    It's somewhat basic, but at the same time, it covers several things my article left out.
    Reply
  • JarredWalton - Wednesday, September 8, 2004 - link

    I received a link from Matthew Quon containing a recent presentation on the whole chip fabrication process. It includes details that I omitted, but in general it supports my abbreviated description of the process.

    #34: Yes, there are errors that are bound to slip through. This is especially true on older parts. However, as you point out, several of the older chips were offered in various speed grades, which only makes it more difficult. Several of the as-yet unreleased parts may vary, but on the X700 and 6800LE, that's the best info we have right now. The vertex pipelines are *not* tied directly to the pixel quads, so disabling 1/4 or 1/2 of the pixel pipelines does not mean they *have* to disable 1/4 or 1/2 of the vertex pipelines. According to T8000, though, the 6800LE is a 4 vertex pipeline card.

    Last, you might want to take note of the fact that I have written precisely 3 articles for Anandtech. I live in Washington, while many of the other AT people are back east. So, don't count on everything being reviewed by every single AT editor - we're only human. :)

    (I'm working on some updates and corrections, which will hopefully be posted in the next 24 hours.)
    Reply
  • T8000 - Wednesday, September 8, 2004 - link

    I think it is very good to put the facts together in such a review.

    I did notice three things, however:

    1: I have a GF6800LE and it has 4 enabled vertex pipes instead of 5 and comes with a 300/700 gpu/mem clock.

    2: Since gpu clock speeds did not increase much, they had to add more features (like pipelines) to increase performance.

    3: Gpu defects are less of an issue then cpu defects, since a lot of large gpu's offered the luxory of disabling parts, so that most defective gpu's can still be sold. As far as I know, this feature has never made it into the cpu market.
    Reply

Log in

Don't have an account? Sign up now