Slashdot Mirror
Carmack on NV30 vs R300
Nexxpert writes "John Carmack has posted his thoughts on the NV30 vs R300 (featured via www.bluesnews.com. Highlights some of the shortcomings of Nvidia's next step as well as pointing out what they've done right. Interesting read." In particular the arb2 vs nv30 path differences mean that it's not as simple as saying "ATI roX0rs nVidia" or vice versa.(update: sorry bout the misspelling, don't know how I missed that)
We already know that the Radeon 9700 pro and the GeForce FX will run Doom III, and they are both going to look good doing it.
My concern is what is it going to look like on, lets say, a G4Ti4200 w/64 megs of ram, or the G4Ti4600 w/128 megs of ram. Are those of us not willing to spend 400 bucks on a new vid card (or for those of us stuck with a 4x AGP board, that plus a new mobo) going to have to turn 90% of the features off to run it at a good looking frame rate?
Thanks goes out to Carmack, its nice that he takes the time to give us a run down of the two cards that are battling for supremecy, especially since I like many of you are thinking about D3 when I evaluate my system and its need for being upgraded.
This is my sig. Its pathetic.
About the only thing I came away with is, if you do it the way a specific vendor wants, it kicks the crap outa the other one, otherwise the ATI may be a wee bit faster.
Close. I think the big thing he was trying to say was that ATI & NVidia in the ARB2 mode, ATI kicks the snot out of NVidia. But it's because ATI renders with less precision than NVidia.
So when both cards are in ARB2 mode, NVidia looks better, but ATI is faster.
$ finger johnc@idsoftware.com
t of Direct-X is the primary reason I have been attending the Windows
[idsoftware.com]
Welcome to id Software's Finger Service V1.5!
Name: John Carmack
Email:
Description: Programmer
Project:
Last Updated: 01/29/2003 18:53:43 (Central Standard Time)
Jan 29, 2003
NV30 vs R300, current developments, etc
At the moment, the NV30 is slightly faster on most scenes in Doom than the
R300, but I can still find some scenes where the R300 pulls a little bit
ahead. The issue is complicated because of the different ways the cards can
choose to run the game.
The R300 can run Doom in three different modes: ARB (minimum extensions, no
specular highlights, no vertex programs), R200 (full featured, almost always
single pass interaction rendering), ARB2 (floating point fragment shaders,
minor quality improvements, always single pass).
The NV30 can run DOOM in five different modes: ARB, NV10 (full featured, five
rendering passes, no vertex programs), NV20 (full featured, two or three
rendering passes), NV30 ( full featured, single pass), and ARB2.
The R200 path has a slight speed advantage over the ARB2 path on the R300, but
only by a small margin, so it defaults to using the ARB2 path for the quality
improvements. The NV30 runs the ARB2 path MUCH slower than the NV30 path.
Half the speed at the moment. This is unfortunate, because when you do an
exact, apples-to-apples comparison using exactly the same API, the R300 looks
twice as fast, but when you use the vendor-specific paths, the NV30 wins.
The reason for this is that ATI does everything at high precision all the
time, while Nvidia internally supports three different precisions with
different performances. To make it even more complicated, the exact
precision that ATI uses is in between the floating point precisions offered by
Nvidia, so when Nvidia runs fragment programs, they are at a higher precision
than ATI's, which is some justification for the slower speed. Nvidia assures
me that there is a lot of room for improving the fragment program performance
with improved driver compiler technology.
The current NV30 cards do have some other disadvantages: They take up two
slots, and when the cooling fan fires up they are VERY LOUD. I'm not usually
one to care about fan noise, but the NV30 does annoy me.
I am using an NV30 in my primary work system now, largely so I can test more
of the rendering paths on one system, and because I feel Nvidia still has
somewhat better driver quality (ATI continues to improve, though). For a
typical consumer, I don't think the decision is at all clear cut at the
moment.
For developers doing forward looking work, there is a different tradeoff --
the NV30 runs fragment programs much slower, but it has a huge maximum
instruction count. I have bumped into program limits on the R300 already.
As always, better cards are coming soon.
--------
Doom has dropped support for vendor-specific vertex programs
(NV_vertex_program and EXT_vertex_shader), in favor of using
ARB_vertex_program for all rendering paths. This has been a pleasant thing to
do, and both ATI and Nvidia supported the move. The standardization process
for ARB_vertex_program was pretty drawn out and arduous, but in the end, it is
a just-plain-better API than either of the vendor specific ones that it
replaced. I fretted for a while over whether I should leave in support for
the older APIs for broader driver compatibility, but the final decision was
that we are going to require a modern driver for the game to run in the
advanced modes. Older drivers can still fall back to either the ARB or NV10
paths.
The newly-ratified ARB_vertex_buffer_object extension will probably let me do
the same thing for NV_vertex_array_range and ATI_vertex_array_object.
Reasonable arguments can be made for and against the OpenGL or Direct-X style
of API evolution. With vendor extensions, you get immediate access to new
functionality, but then there is often a period of squabbling about exact
feature support from different vendors before an industry standard settles
down. With central planning, you can have "phasing problems" between
hardware and software releases, and there is a real danger of bad decisions
hampering the entire industry, but enforced commonality does make life easier
for developers. Trying to keep boneheaded-ideas-that-will-haunt-us-for-years
ou
Graphics Summit for the past three years, even though I still code for OpenGL.
The most significant functionality in the new crop of cards is the truly
flexible fragment programming, as exposed with ARB_fragment_program. Moving
from the "switches and dials" style of discrete functional graphics
programming to generally flexible programming with indirection and high
precision is what is going to enable the next major step in graphics engines.
It is going to require fairly deep, non-backwards-compatible modifications to
an engine to take real advantage of the new features, but working with
ARB_fragment_program is really a lot of fun, so I have added a few little
tweaks to the current codebase on the ARB2 path:
High dynamic color ranges are supported internally, rather than with
post-blending. This gives a few more bits of color precision in the final
image, but it isn't something that you really notice.
Per-pixel environment mapping, rather than per-vertex. This fixes a pet-peeve
of mine, which is large panes of environment mapped glass that aren't
tessellated enough, giving that awful warping-around-the-triangulation effect
as you move past them.
Light and view vectors normalized with math, rather than a cube map. On
future hardware this will likely be a performance improvement due to the
decrease in bandwidth, but current hardware has the computation and bandwidth
balanced such that it is pretty much a wash. What it does (in conjunction
with floating point math) give you is a perfectly smooth specular highlight,
instead of the pixelish blob that we get on older generations of cards.
There are some more things I am playing around with, that will probably remain
in the engine as novelties, but not supported features:
Per-pixel reflection vector calculations for specular, instead of an
interpolated half-angle. The only remaining effect that has any visual
dependency on the underlying geometry is the shape of the specular highlight.
Ideally, you want the same final image for a surface regardless of if it is
two giant triangles, or a mesh of 1024 triangles. This will not be true if
any calculation done at a vertex involves anything other than linear math
operations. The specular half-angle calculation involves normalizations, so
the interpolation across triangles on a surface will be dependent on exactly
where the vertexes are located. The most visible end result of this is that
on large, flat, shiny surfaces where you expect a clean highlight circle
moving across it, you wind up with a highlight that distorts into an L shape
around the triangulation line.
The extra instructions to implement this did have a noticeable performance
hit, and I was a little surprised to see that the highlights not only
stabilized in shape, but also sharpened up quite a bit, changing the scene
more than I expected. This probably isn't a good tradeoff today for a gamer,
but it is nice for any kind of high-fidelity rendering.
Renormalization of surface normal map samples makes significant quality
improvements in magnified textures, turning tight, blurred corners into shiny,
smooth pockets, but it introduces a huge amount of aliasing on minimized
textures. Blending between the cases is possible with fragment programs, but
the performance overhead does start piling up, and it may require stashing
some information in the normal map alpha channel that varies with mip level.
Doing good filtering of a specularly lit normal map texture is a fairly
interesting problem, with lots of subtle issues.
Bump mapped ambient lighting will give much better looking outdoor and
well-lit scenes. This only became possible with dependent texture reads, and
it requires new designer and tool-chain support to implement well, so it isn't
easy to test globally with the current Doom datasets, but isolated demos are
promising.
The future is in floating point framebuffers. One of the most noticeable
thing this will get you without fundamental algorithm changes is the ability
to use a correct display gamma ramp without destroying the dark color
precision. Unfortunately, using a floating point framebuffer on the current
generation of cards is pretty difficult, because no blending operations are
supported, and the primary thing we need to do is add light contributions
together in the framebuffer. The workaround is to copy the part of the
framebuffer you are going to reference to a texture, and have your fragment
program explicitly add that texture, instead of having the separate blend unit
do it. This is intrusive enough that I probably won't hack up the current
codebase, instead playing around on a forked version.
Floating point framebuffers and complex fragment shaders will also allow much
better volumetric effects, like volumetric illumination of fogged areas with
shadows and additive/subtractive eddy currents.
John Carmack
NVIDIA got where they are today by beating 3dfx on their own turf: high-end gaming performance. Remember when 3dfx released the Voodoo 4 & 5? More expensive than the GeForce256 but not decisively better performance. Now I'm hearing similar things about the GeForceFX vs. ATI's three month old Radeons. NVIDIA is getting bigger but they still aren't a huge company. Can they really afford to lose the lucrative high-end sales right now?
One thing NVIDIA does seem to have going well is their motherboard chipsets. The new nForce2 really kicks ass by all accounts. I remember a while back hearing about an ATI mobo chipset based on tech they acquired from ArtX, but apparently end-user mobo chipsets aren't ATI's plan.
Good luck, NVIDIA. Hope y'all can keep up the pace.
Never approach a vast undertaking with a half-vast plan.
"The fan only runs at full RPM when the card is doing a lot of 3d work. 2D stuff causes the fan to run a lot slower (not sure if it ever turns off completely tho)..."
From the [H]ard|OCP review:
"Using a decibel meter we tested the sound level of the GFFX at three feet away, directly in front of the exhaust vent. In 2D mode, the reading was 56dB."
I don't know about you, but I find 56 dB to be very noisy.
Site & blog: http://www.mayaposch.com
The NV30 runs the ARB2 path MUCH slower than the NV30 path.
Half the speed at the moment. This is unfortunate, because when you do an
exact, apples-to-apples comparison using exactly the same API, the R300 looks
twice as fast, but when you use the vendor-specific paths, the NV30 wins.
I'm betting that Carmack assumed NV30 would also use the ARB2 path with NV10/20 R200 for the older cards. When he found ARB2 ran like shit on NV30, he had to do a special NV30 path.
He's already dumped vendor-specific vertex programs. I bet ARB2 would have been the only next-generation fragment processor if the NV30 could have run it fast enough.
Carmack mentioned this, and its important not to gloss over...
There's a big difference between the drivers theoretical output, and the actual acheived output.
In testing at my job, we found that the ATI drivers typically performed very poorly in comparison to those released by nVidia on similar hardware. In addition, we often had more serious issues with bugs in ATI drivers than nVidia. Although the next great thing from nVidia isn't likely to outright dethrone the 9700, nVidia is constantly improving their driver technology, constantly making the layer between software and hardware thinner and thinner.
I currently have no clever signature witicism to add here.
"ATI did have superior 2D quality (to my eyes) and Video/DVD playback. Given I spend 90% on my time on a desktop, ATI had the right mix of features."
Have you looked at Matrox's product range lately?
If I were building a system for primary 2D operations, that's who I'd be buying from. Their cards are wonderful.
He never indicated which looked better, all he said was that ATI was faster in ARB2 mode, which may or may not be due to the differences in precision. Every review I've read indicates that ATI has either a slight or a major advantage in visual quality, depending on settings (ATI aquires a much bigger lead in quality as the settings are lowered.) and that ATI aquired a lead in speed as quality settings go up. Notably, the Radeon 9700 Pro also looks as good at 6x AA as the NV30 does at 8x AA.
"You've got an invalid haircut" -Warren Zevon - Life'll Kill Ya
ATI doesn't have any proprietary extensions for exposing the R300 shader functionality, only "ARB2" (ARB_vertex_program and ARB_fragment_program) so there's no way to do "specific" R300 path.
The leaked alpha does support ATI's two-sided stencil extension (ATI_separate_stencil) which is only implemented on R300.
> My guide is a zalman heatsink, a zalman powersupply, athlon 1.2, seagate 40 Gig HD, ATi radeon 9000(whitout fan) and a good motherboard without fan on the chipset.
Good advice, but all this will be futile if the system case doesn't reduce the noise that is generated by the internal components (or even amplifies it because of vibrations). Watch out for expensive aluminum cases which look cool but have no provisions against noise. Acoustically well-designed cases, such as this one from silentmaxx use several types of dampening materials with different noise absorption properties.
"There are already a million monkeys on a million typewriters, and Usenet is NOTHING like Shakespeare." - Blair Houghton
In addition, Carmack is, perhaps, singlehandedly responsible for preserving OpenGL as a viable alternative on PC. Remember when Microsoft was aggressively pushing Direct3D and steam was running out of OpenGL drivers for Windows 95, he said "no shit" and put out the 2nd installment of The 3D Game (and, subsequently, the engine) using OpenGL as the sole rendering backend. The manufacturers couldn't stand the pressure and rushed to update drivers.
My exception safety is -fno-exceptions.
n addition, Carmack is, perhaps, singlehandedly responsible for preserving OpenGL as a viable alternative on PC.
Well, I don't know about that. However, I would be willing to give him kudos though for implementing it in his games. We owe SGI a certain debt for making IRIS GL and documenting the api, then making the OpenGL "open". I suppose we could also give kudos to Evans and Sutherland for creating frame buffers, Postscript and "GL" as well.
Anyway, the whole reason SGI decided to open it up was pressure from the software developers. In order to be viable, they needed to have a wider variety of hardware choices and told SGI they would drop them if they did not open up the standard.
Currently we also have companies like Apple to thank for aggressively supporting it, integrating and improving OpenGL.
Visit Jonesblog and say hello.
Not quite. The FX card actually turns the fans full blast the second 3d is detected in software (ie: a DirectX/OpenGL call is made). I thought (hoped) it would be based on the running temperature of the card (hardware RPM control) but unfortunately, it isn't.
OK, I did some 3D imaging math about 10 years ago (when you had to code your own drivers to get SuperVGA mode under DOS), so I think I get what he's talking about: the problem of how to show the reflection of one object (or light source) off another object. I've never heard of "interpolated half-angle" or "specular highlights", or the "triangulation line". Anyone know what he is talking about?
You didn't get much beyond Gouraud shading, did you? :)
Of course, depending on your hardware ten years ago, specularity might not have been feaasible if you were doing something big and real-time. Certainly not with the standard PC of that era.
Hope that helps!
In post-9/11 America, the CIA interrogates YOU!
>But he mentioned something about next gen cards having less bandwidth. Does that make sense to anyone?
The RATIO of bandwidth to calculation speed is going to decrease. It is nothing short of miraculous that ram bandwidth has made the progress is has, but adding gates is cheaper than adding more pins or increasing the clock on external lines.
Bandwidth will continue to increase, but calculation will likely get faster at an even better pace. If all calculations were still done in 8 bit, we would clearly be there with this generation, but bumping to 24/32 bit calculations while keeping the textures and framebuffer at 8 bit put the pressure on the calculations.
John Carmack
Currently we also have companies like Apple to thank for aggressively supporting it, integrating and improving OpenGL.
That goes back to Carmack again. He went to Apple more than once evangelizing OpenGL, and his games have always been the Macworld showpieces on new hardware in the iMac era.
There'a also a slower version of the GeforceFX in the works, sans leafblower. It's reported to run at 400MHz core/800MHz memory (as opposed to 500/1000 for the "Ultra" leafblower version). It will likely get trounced by the 9700 and 9700 Pro in most performance and IQ areas, but it will be an alternate solution for you guys that want one of those nV30 based cards but don't want to risk having your cat sucked into the back of your computer.
Actually, it breaks down more like this: ATI does 96 bit precision, Nvidia can do 32, 64 and 128.
Your example with the truncation is a gross simplification, which goes into ATI's favour, but in reality there's way more precision than just 2 decimals...more like 6 for ATI and 8 for Nvidia...which makes a reasonably big difference in quality.
The numbers above are not entirely spot on (except for Nvidia's 128 bit precision, and I can't be arsed to find the exact other numbers), but the principle remains the same: grandparent had it right; ATI for speed, Nvidia for quality (on a ARB2 path...vendor specific paths lead to different results, but are you really going to play the game in anything other than true OpenGL?
-- Waht? Tehr's a preveiw buottn?