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.
I was doing ok for the first paragraph or so.
Then my brain went *beep* *beep* *beep*
And I lost everything.
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.
He tried to kill me with a forklift!
Notice that Carmack has no R300 path. Why is that? I can think of two possible explanations instantly.
One is that ATI has optimized for the standard ARB2 path, and a specific R300 path wouldn't make much difference. In that case, my response would be, kudos ATI for promoting the standard, but speak positively of the performance of NV30.
The other possibility I can think of is that the lack of an R300 path is punishment for ATI leaking the Doom III alpha version. In that case I wonder how much the Radeon 9700 Pro would gain from an R300 specific path.
It certainly isn't a lack of time to develop the ATI path; there is an R200 path for older Radeon cards, and the Radeon 9700 has been available to developers for quite a bit longer than the GeforceFX has.
I'm "Keen" on continuing it.
"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.
Noise is becoming a big problem. I now putting zalman stuff in all my computers. 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.
thank you
louis
$ 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
I was holding out on nVidia's new card, but now I've given up on that idea. With more and more people using PCs as multimedia devices (watch DVDs, listen to music, etc), a fan that puts out almost 60Db of noise is unacceptable.
I really wanted to go away from ATI this time around, but it appears I'll have to wait a little longer. I'm sure nVidia will [eventually] release a fanless, 1-slot version. I just wonder if it will be too little too late.
These are both the "new hotness" but with the noise of the nVidia I forsee it becoming "old and busted" quite soon.
Not to mention ATi's next card...
...really need to concentrate on spelling people's names correctly. When they can't even spell John Carmack's name right, something is seriously wrong.
mbbac
I've been running ATI cards on my desktop since the mach64 chip days. When I got my 9700 in August, I NEVER thought I'd still have a chip that was competitive with nVidia's best offering in 3D. I never bought ATI cards because they were best in 3D or driver quality - they never were better. 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. Now they finally are competitive with nVidia's 3D.
After we started to get benchmarks showing matched performance, the remaining questions were left to DX9 and the more complex shaders. From Carmack's comments and the shadermark tests that are showing up, it appears that ATI is anywhere from competitive to superior in the DX9 2.0 shaders, as well. It does look like NV30 can indeed run deeper/higher precision shaders, but we will have to wait to see if games ever do show with shaders deeper than the LCD between NV30 and R300.
Carmack does mention that nVidia promised that "compiler improvements" will increase the NV30 shader performance. (Better scheduling of parallel pipes?)
The astounding bottom line is that as of Jan 2003, the 9700 is not shown to be inferior in any way to an as-yet unreleased flagship product from the king of 3d on the mainstream desktop.3 Cheers for ATI.
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 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.
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.
update: sorry bout the misspelling, don't know how I missed that
psst... it's spelled about...
So long, michael. Don't let the door hit you...
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