ATI Radeon 9700 Dissected
Bender writes "The guys who laid out the future of real-time graphics a while back have now dissected ATI's Radeon 9700 chip. Their analysis breaks down performance into multiple components--fill rate, occlusion detection, pixel shaders, vertex shaders, antialiasing--and tests each one synthetically before moving on to the usual application tests like SPECviewperf and UT 2003. You can see exactly how this chip advances the state of the art in graphics, piece by piece. Interesting stuff."
a UT tech test has been around for months - anandtech has been using it for a while.
Epic released it so people would at least have a rough idea how one card would compare to another (I believe only relatively speaking, not in terms of absolute fps as the test was preliminary)
(I only skimmed through part of it, but it looks like if you have an ATI card, you may not have much luck with UT2K3.)
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
Tungsten Graphics were recently contracted by the weather channel to write accelerated xfree86 drivers for the Radeon. You can get a beta from their site. Given that ATI make their specs available and the influx of cash you'd expect the drivers to develop well.
:wq
Occlusion is a perfectly normal english word. Occlusion detection is an important feature in complex scenarios where algorithms like bsp-trees fail. It saves fillrate by not drawing fragments which would be overdrawn with opaque pixels anyway.
Perhaps I'm being pedantic here, but that's not what MIP mapping was for. Lance Williams invented it as an inexpensive means of texture antialiasing (see "Pyramidal Parametrics", Computer Graphics (SIGGRAPH) Vol 7, No 3, July 1983 (reprinted in Seminal Graphics)). Once the highest resolution texture map is defined, a "pyramid" of smaller, down-filtered, maps are created from that original source.
You cannot obtain more detail than that which is defined in that top level map.
Oh, incidentally, it is not a great idea to go swapping the MIP map levels in and out of (texture) memory because on true hardware the levels that the texels are read from are chosen by the hardware on a pixel-by-pixel basis. You could easily end up with texture aliasing if the hardware is forced to read inappropriate texture levels. (The P(o)S2, of course, has b'all texure memory and so developers often don't have a choice).
What you are probably looking for are solutions either based on virtual texturing (i.e. specific HW support for swapping texture data) or use of detail textures.
Simon
It's not just the pixelation or blurring that procedural shaders solve. Combined with other techniques such as bump and environment mapping, surfaces can be given depth without increasing the poly count. A texture can be be made to look like water without transmitting wave information to the video card. Just send a function.
The combination of pixel and vertex shaders allows stunning effects like flag that flaps in the wind and still casts the right shadows, and it's all done on the card (an example I stole from an NVidia presentation).
It's no cure-all, but it is another large step forward.
Why are you slamming ATI for releasing binary-only drivers, while hailing Nvidia? Nvidia does exactly the same thing.
What do you think the 1MB 'Module-nvkernel' file in their NVIDIA_kernel-1.0-nnnn.tar.gz is?
NVIDIA_kernel-1.0-2960> file Module-nvkernel
Module-nvkernel: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
You didn't seriously think the few snippets of C code in that package was the complete driver, did you? That's just a kernel wrapper for their binary blob.
The binary driver for the R8500 is indeed missing texture compression. However, ATI has a driver which does support s3tc since quite some time already, but it is not released yet - but don't ask me why. ATI also already demonstrated a 3d xfree/linux driver for the R9700 (they did a demo on it), but no release so far (and I haven't heard anything of a release plan neither).
The DRI people have some problems with supporting s3tc with the Radeon 7200/8500, but these are not technical problems, and they don't have anything to do with ATI - s3tc is covered by patents. mczak
For that matter, I'd like to do video editing at some point in the future (when I get a digital camcorder).
Video capture on Linux... from a "freebie" capture port on your video card??
Forget it man.
Video capture requires drivers AND applications. You buy a video card for Linux, and IF the manufacturer supports Linux, video drivers are all you get. ATI has drivers for Linux... but not even the 3D part. See what I mean?
The only way to get Linux capture drivers is to buy a dedicated capture card for Linux. That way you get what you paid for, with no "missing features" on the Linux side.
Besides, the way things improve and drop in price, you never want to buy this hardware BEFORE you are ready to begin using it.
Me? I have a MSI GeForce4 4400 (oc'd of course). Capture only works on Windows, but in a few years I expect Linux capture support to become a competitive feature... just like primitive driver support has become now.
I've used broadcast capture equipment, and while this capture port can be called a "toy", the MSI Video-In/Out port which handles uncompressed 720x480 fine (if your drive can not handle uncompressed YUV I sugest HuffYUV which is lossless compression).
Whatever you use, "realtime" MPEG compression sucks. It looks OK if you consider how hard your PC is working to do the job in software, but there's just no substitute for variable-bitrate multipass compression. CBR video creates fixed size files that are compromised everywhere... multipass VBR allows you to lower the "average" bitrate by 25%, AND give better quality (presuming you lower the bitrate floor and ceiling and have a good encoder).
I've transferred 8 hours of VHS to DVD so far. Did someone say Star Wars? I didn't. ;-)
With VHS, you shouldn't have to capture at 720x480 because of the limitations of VHS resolution on the VHS tape... you can get away with 360x480 (not a typo!) and then double the horizontal lines... a good capture card does this in hardware.
IF there's a way to use 360x480 on DVD and specify the aspect ratio as 8:3 (did I do that right?), you'd save a LOT of DVD space but I have not tested this. Until I figure that problem out, there's no advantage to capturing at this res... but it's worth mentioning if your hardware cannot keep up (you would have to stretch the video afterwards).
In short, dual boot... or fork out real cash for professional capture under Linux. You have a limited selection under Linux and will pay more until the market becomes more viable.
You'd also need to MASTER your DVD's under Windows. No authoring sw for Linux anywhere (AFAIK). Once you HAVE mastered your DVD, you CAN burn it under Linux using dvdrtools.
NVIDIA uses the same codebase for ther Windows, Mac OS ?, and Linux drivers. This same codebase will also be used for their FreeBSD drivers to come. Their unified driver architecture ensures that every platform the card runs on gets the latest version of the code and can take advantage of each card's features. So this is definitely a few notches above ATI who won't even produce drivers for my platform, let alone release full specifications to the public to write them.
As for the complaint that NVIDIA is no better than ATI because of a binary driver release: that is not NVIDIA's fault. NVIDIA tries to make as much of their driver open source as possible (which is kind of a necessity because of the plethora of kernel configurations out there). However, the closed-source portions are kept closed because of SGI's patents on OpenGL. Assign blame where blame is due, please.
Why bother.
Actually, it does matter with more FPS. Don't compare it to film, because even though they both use the term 'frame' they mean different things.
A 24 fps film means that each frame is recording 1/24th of a second. That means that if an object being filmed is moving fast enough, the frame will have motion blur. When strung together with the other frames, this will give the illusion of smooth movement. A 24 fps 3d engine, however, means that you have 24 static shots. There's no transition from point to point, unless you wind up rendering said inbetween shots. Or, put another way, a 5 fps film of a hand waving in front of the camera will produce five frames full of motion-blurred hand, which, when played, will look relatively smooth. A 5 FPS render, however, will have five static shots of a hand sitting motionless in space, and when played, the hand will appear to 'teleport' from spot to spot to spot.Or, put another way, record that hand with a standard camera shooting at five 'frames per second' not 'several frames, each 1/5th of a second exposure' and then string the negatives into a film reel, splicing in copies to make the whole thing last one second.
This is one of the reasons, I always thought, that 3dFX was trying to get their T-buffer out into the world, becuase then, yes, if you could LOCK the rendering at 30 FPS, and throw in motion and acceleration blur, it would still look better than a card rendering the exact same thing at 300 FPS.
Vintage computer games and RPG books available. Email me if you're interested.
I think the poster's point was that you have two choices for drivers with an ATi card:
a) Open-source drivers - No S3TC support, UT2K3 won't even run
b) Binary-only drivers sorely lacking in performance. (I don't even recall seeing any Linux binary drivers from ATi - Does he mean the XiG drivers you have to *pay extra for*?)
With Nvidia, your only choice for 3D is unfortunately the binary drivers. While I'd rather not have it be that way, NV's drivers are maintained from the *same* source base that ATi's are, and hence are kept as up-to-date as the Windows drivers. In fact, the Linux drivers often *outperform* NV's Windows drivers by 1-2 FPS. (Not a big difference, but the fact is that they are not only "as good", but they are FASTER.)
So overall, given that binary drivers are the ONLY real option for both cards, NVidia is the way to go because their binary drivers are *far* superior to ATi's.
retrorocket.o not found, launch anyway?
To show fps in Q3A, type this into the console /cg_drawfps 1
/timedemo 1 /demo demo0001
But you're probably looking for:
Horrendously offtopic, I know