Slashdot Mirror
ATI vs. NVIDIA: The Next Generation
doppler writes: "There's a killer graphics card round-up at TR today that compares the new GeForce4 and Radeon 8500 128MB cards against each other in extensive testing. Very good stuff. Most interesting: a visual representation of a texture upload problem in OpenGL on the Radeon 8500 chip."
As an amateur game programmer, I must say I prefer NVIDIA-based cards to ATI-based cards, simply because NVIDIA takes care of their customers.
I've used the latest flavours of the ATI Radeon series, and the drivers always seem to be a bit unstable. Downloading updated drivers doesn't always fix the problem, either; sometimes, it makes the problems worse. It's hard to tell whether they're even trying. It seems ATI, at this point, is just trying to keep up with NVIDIA in terms of speed, rather than in both speed, quality, and stability.
NVIDIA, on the other hand, fixes bugs properly *the first time*. They don't really produce many bugs, either, which means they can put forth more effort toward making everything more featureful.
There's no contest, in my opinion. NVIDIA wins, hands down. It will take quite a bit for ATI to change my mind, or the minds of my game programming colleagues, about this one.
Firingsquad just posted a report about the new GeForce TI 4200. They're coming out with two seperate versions, one with 64mb of faster memory, and one with 128mb of slower memory. The 64mb one was faster in the benchmarks that they ran, even though it was $20 cheaper than the other variant. Plus, it even beat their comparison TI 4400 in some of the benchmarks.
But it gets better. The TI 4200 can be overclocked to speeds comparable to the TI 4600, Nvidia's fastest card. Get the fastest performance available for half the cost!
NVidia deserves a lot of credit -- especially from Linux folks -- for their top notch drivers. Installation is a snap (two tarballs, sudo make install), and once they're up and running, they're very stable and quick. And they're maintained. New versions are released fairly often, and the very latest cards are supported as well. I tried a radeon card once, but prompty returned it because there were no drivers, and only after a while did they finally appear.
I've sent NVidia some mail stating that because of their support for my OS, I plan to continue buying their products. It's good to give them that kind of feedback, I think.
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
Instead of bruteforcing polygons the MAN'S way, ATI decided to be a bunch of sissies and implement HyperZ technology. 'Discard unseen pixels'? BAH! I'd much rather have these unseen pixels rendered than let them go to waste. Their proprietary TRUFORM technology is good, if you like seeing rounding errors (see Serious Sam SE's shotgun model). Moreover, their names are misleading. 'Pixel tapestry', 'Charisma Engine' - what do these names mean? How can a pixel have tapestry?
Meanwhile, NVIDIA continues its dedication to their customers by giving them 128MB of VRAM; conveniently providing the customer with 32 extra MB of VRAM to use as a RAMdrive. Instead of fudging around with names like ATI does, they've simply decided to follow 3DFX's naming scheme and simply name their cards GeForce(n + 1). I look forward to the day when the GeForce requires an input from the +5V power supply.
...refresh rates with framerates above the refresh rate of the monitor.
Strangely, most people don't seem to realize that this is a BAD THING, unless your app is running at an integer multiple of your monitor refresh rate.
To make it simple, imagine your monitor scans at 60 Hz. So every 60th of a second (16.67 msec) you get a whole new frame drawn on the screen. Assume, for sake of argument, that drawing the screen takes zero time. It's just instantaneous.
To achieve smooth motion, the same amount of time must pass between each frame. This is guaranteed if your application renders 60 frames per second. Unless you drop a frame somewhere, you'll see one rendered frame for every screen refresh, and you'll perceive smooth motion.
But what if you drive your screen at 60 Hz, but your application renders 95 frames per second. (Assume that it's exactly 95 fps all the time, rather than a variable frame rate, just to make the math work out for this example.)
When you run your game or whatever, the clock starts at zero. The first frame from the graphics pipeline is in the display buffer, so when the monitor gets ready to draw the screen, it draws frame zero.
10.53 msec later, the application has drawn the second frame, so it swaps buffers. The display buffer now has frame 1 in it. The application now starts drawing frame 2.
But the graphics card isn't ready to draw frame 1 on the monitor until a little over 6 msec later, at t = 16.67. At that time, though, the application hasn't finished drawing frame 2 yet, so frame 1 is still in the display buffer. The monitor draws frame 1. Game frame 1 comes after game frame 0, so we're still in sync.
During this time, the application has been working on frame 2. It finishes frame 2 at t = 21.05 msec and swaps buffers. Frame 2 is now in the display buffer, and the application starts drawing on frame 3.
The monitor is ready to draw frame 2 at t = 33.33 msec. So it reaches for the frame from the display buffer... but what's this? The frame in the display buffer isn't frame 2. It's frame 3! We dropped a frame somehow!
In the meantime, at t = 31.58 msec, the application had finished drawing frame 3. It swapped buffers again, before the graphics card got a chance to display frame 2. Frame 2 disappeared from the display buffer, never having been shown on the monitor. That's a dropped frame, and it's a bad thing.
Games aren't hard-real-time applications, of course. They run freely, sometimes drawing frames more quickly, and sometimes less quickly, depending on the load. This is okay. But don't just assume that because your game runs consistently at a rate higher than your monitor, you won't be dropping frames. In fact, you'll drop frames like crazy, at a rate determined by how far your game frame rate is from your monitor rate, in modulo arithmetic.