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."
I just wish one benchmarking site would release the raw data in some kind of ascii based table. I would love wasting coutless hours of gnuploting, generating variations on plots like those.
Does anybody have a pool of varied cpu & motherboard machines, new and old? There are a couple of statiscal tools I would like to throw at the benchmarking problem - if only I had the data.
This post was compiled with `% gec -O`. email me if you need the sources
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!
Is anyone doing decent PCI cards these days? I realize I'm behind the times here, but my motherboard (Asus CUR-DLS) has no AGP slot, leaving me with a GeForce2. Still, my dual P3-1.26 ghz setup isn't far enough behind the game to warrant buying a whole new setup. I do have a couple 66mhz 64bit PCI slots going unused in the motherboard, any graphics cards go that route?
I have a DV cam with RCA inputs, and firewire, so my video card doesn't need to be able to capture, just a nice S-Video out for watching downloaded southparks on my Wega in the living room.
What, me worry?
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.
NVidia's developer site is why they will win the GPU war. Only because they help developers by prodiving an extensive forum in which they can educate themselves about their technologies. I recently started researching vertex programming, I went to NVidia's site and they had a entire SDK dedicated just to it. I haven't see anything like that on ATI's site. Keeping the people that develop for your hardware informed is the only way to win support, ATI hasn't realized that yet.
When its all said and done, I have to place my vote for nVidia, hands down. There are many reasons for this... howerver this is the most compelling...
nVidia Drivers page link
ATI Drivers page link
At home I run about 7 computers, a mix of linux winXp 2k and 98. The fact that my geforceX cards can and will run great in all of the above os's using proper driver support is all I need to buy from nVidia. Good customer support, and good OS support. That will bring in my dollars...
Try and find a Voodoo 4 or 5. They've got decent (Geforce 2ish) 3d capabilities, will work at 66Mhz in a PCI slot that supports it, and have quite decent linux drivers.
They're also dirt cheap on ebay, as WinXP and MacOSX don't support Voodoo cards, and people are selling them off for better cards.
You may also look for Mac cards - for the longest time, there was no AGP slot on the Mac, and I think you can get a Radeon PCI with mac roms. Flash it to be x86 compatible, and there you.
BBK
This is noting that having over 32MB of memory has proven to be of NO benefit in benchmarks outside of the occasional 1 or 2 FPS difference (and when you are getting over 100FPS any ways. . . .).
:)
Texture size is REALLY not a problem. Do you realize how fr*gin big textures can be byte wise before you get to being just plain old silly?
It is NOT the size of textures people, it is how COMPLICATED those textures can be.
Currently LOD is used in order to keep video cards from having to render full 256x256 textures when an object, say, only appears as 25 pixels in its entirety on the screen. You know, that sniper across the street with that gun? Yah that one, (duck).
This works quite well, until you get up close to the object. Shoddy unrealistic Bumpmapping (I highly disprove of bumpmapping, more on this later) can come into play at really close distances, and games like Serious Sam even make this look halfway decent, but it still is not real, or realistic.
The ONLY way to get good texturing done is to DISPENSE with the concept of textures all together. Polygons do not make this easy in themselves, and competing technologies can even make it worse. Some technologies like vertex coloring are a bit useful, but not much and they are just the texturing model relabled.
But once you DO dispense with textures, ooh yah.
Now for bumpmaps.
Bumpmaps are often times just a cheap shortcut to REAL modeling. Geometry deformation texturing is the next step, but until we get some video cards that can model each little crack and bump of an object we are not going to get anything near 100% photo-realism. Not to mention characters with actual nostrils. Yes there is a level of diminishing returns, but quite frankly, until I can model every last little crack bump and lump in a model and have it render real time on a home users computer, bumpmapping is what we are stuck with, and I don't like it.
But I repeat, I REPEAT, larger textures (and bumpmaps) are just a cheap low quality shortcut They DEFINITELY have a point of diminishing returns, and it is one that HAS ALREADY BEEN REACHED. Most new games do NOT do just plain old texturing any more, and a lot of what is happening now days in relationship to textures (Bilinear filtering and such) is just in fact ways to correct errors in the original texturing model of thinking. Or at least further refine the mathematical model used to show those textures.
But why do games look better you ask?
Mostly because video cards have any number of fancy TnL units that can independently create some rather nifty effects while working AROUND or OUTSIDE of the plain old texturing model. At the very least the texturing model of thinking has some. . . rather funky. . . math applied to it in an artistic manner with the results rendered to the screen.
Look at Nvidias werewolf model as an example.
The HAIRS on it look great.
The actual model though?
Hell looks like shit.
No it does.
Notice the face people. Horrid. The textures. It is not the modeler or textures fault, it is just a fact that, well hell, you CANNOT do realistic skin textures without using Pixar level technology.
Actualy, I recently read an article from awhile back that was an interview with someone at Pixar. They were describing the INSANE level of work that was necessary to even get something that SORT OF looked like a skin texture to render. The FF movie had kinda-sorta-maybe-ifyousquint real looking skin, it was nice, but it took a lot of work and it still was not perfect. Once again, diminishing returns.
While NVIDIA is doing good work in relation to getting various funky technologies out on the market that move around the texturing problem, as long as we rely on textures as our main source of coloring objects, we as a community of people who love to Blow Things Up are going to have problems.
Hell the very idea of textures themselves is exactly opposite to how existence works. Objects are not gray by default with colors added later. Objects are. . . . real. They exist. More or less. The color is an INTEGRAL PART of what an object is. You cannot separate the two.
In other words
I want molecular modeling please.
Need help treating your acne? Come here!
Probably not a bad idea to register your hardware (with those mail-in cards they include in the box (if nVidia doesn't, forgive me for my mistake. :)), making sure to select Linux as your OS. That way the real number counters get the message. :)
I agree.
> Texture size is REALLY not a problem.
It IS when your PC game is being ported to consoles and you ONLY have ~ 2.5 Megs of VRAM say like on a PS2 ! (Yes the PS2 has 4 Megs of VRAM, but you need space for the framebuffer and zbuffer.)
Now consoles make up for the lack of video memory by having a high bandwidth (i.e. PS2 can DMA ~20 Megs of Textures per frame) but I'd rather upload my textures ONCE, not every bloody frame. Yes, you be more efficient at texture uploads (draw the last model from the last frame, first this new frame, etc) but you're still tying up the BUS.
> The ONLY way to get good texturing done is to DISPENSE with the concept of textures all together.
I don't compeletely agree, but you raise an interesting point, because of the fact that textures are a form of (color) compression. If we take this to its logical conclusion we should be able to have a triangle PER pixel, and that would negate the need for textures. Unfortunately that has its own problems -- there's no way we can send a million vertices across because we'd saturate the bus! Doh! (Give a reward to the person in the back who said, well let's move to paramateric surfaces then!)
In the "Real World" (TM) we have a *unique* texture per pixel (ala ray tracing) however we don't have the memory to store that, unless we calculate them parametricaly. Sure we can get nice "marble" ala Perlin Noise, but it's going to be a while before we can mathmatically generate EVERY texture !
> But why do games look better you ask?
> Mostly because video cards have any number of fancy TnL units that can independently create some rather nifty effects while working AROUND or OUTSIDE of the plain old texturing model.
You'd be amazed at what multitexturing and multipass render does. Even a simple repeatable base texture with a "random" noise texture overlaid with a bump-map, looks OK.
> The color is an INTEGRAL PART of what an object is. You cannot separate the two.
You *can* get away with this, but you have to be aware of the tradeoffs. One common "solution" is to crank up the bit-depth.
i.e. If you use 16-bit color channels ala 64 bits per pixel, then you don't have to throw out your whole rendering functionality -- you just extend it. Not a perfect solution by any means, but "its good enough."
Take a look at "Titanic" The ship was rendered via tradional textures, and it looks pretty good. The hard part is getting that quality in real-time with so little memory ;-)
Cheers
--
"The issue today is the same as it has been throughout all history, whether man shall be allowed to govern himself or be ruled by a small elite." - Thomas Jefferson
...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.