[Dave Baumann]

During our testing of the GeForce FX 5800 Ultra for our preview the results and findings raised a number of different points that were not clear. I put some of these to NVIDIA to see what their explainations were, and NVIDIA's Tony Tamasi has replied.

You can read the Q&A at the end of the GeForce FX 5800 Preview, here.

[Nite_Hawk]

Wow, his replies are really defensive, it almost feels like he's attacking Dave for asking the hard questions. On the other hand, he's pretty frank with the ansewers which is nice. Still, the general tone of the QA was pretty harsh.

Nite_Hawk

[mczak]

No, we need to make sure that the definitions/specifications that we do use to describe these architectures reflect the capabilities of the architecture as accurately as possible.

Using antiquated definitions to describe modern architectures results in inaccuracies and causes people to make bad conclusions.

Sorry, but this is ridiculous. It might be true that "8x1", "pixel fillrate" etc. are "antiquated" definitions, so nvdia thinks it's ok to change the definitions without telling anybody they have changed , just so the terms describe their architecture in a more favorable light?

It's also funny how much he stresses that fp24 is just not good enough, considering nvidia tried to push ms to accept fp16 for PS2.0...

The bashing of ATI's AF algorithm is also quite unjustified, only the R200/RV250 use that 90-degree algorithm. The R300 will also apply maximum anisotropy to 45 degrees as well (though, the fact remains, the R300 will not filter all angles the same, but it's much less visible than on the R200).

[LeStoffer]

Interesting, because we now have a more precise picture of how nVidia will be trying to put GF FX in a better light than R300. I like the part on FP precision:

For example, NVIDIA uses FP32 for texture address calculation. In the case of dependent texture reads (e.g. a bumpy shiny object with a reflection map in a scene), full precision (FP32) for the texture address calculation is critical for getting a high-quality result.

Yes, but R300 use full precision (FP32) for [some] the texture address logic as well, while it's the core pixel shader that's only working at FP24.

It is unfortunate that the spec is lax on this point because FP32 is also important to match the FP precision for any work that is done on the CPU (whether Pentium4 or Athlon). Some applications still do load balancing by performing some geometry processing on the CPU. If some math is done in FP32 on the CPU (CPUs don't recognize the FP24 format) and other math is done at FP24 on the GPU, you will get errors.

Okay, the R300 is only limited to FP24 in the pixel shader so here comes the hurdle according to nVidia:

Because pixel shading units are now capable of rendering geometry, they need to have the same precision as the vertex shading unit. Advanced pixel shading programs can render data to a texture that is subsequently read back into the Vertex Shading Engine for additional geometric processing.

A bit of bollox IMHO. R300's pixel shader will read from and write to FP32 on the fly. So when do you really need that kind of precision? For normal maps? I thought displacement mapping had to be pre-sampled on both R300 and NV30 anyway. :?

I really don't buy this before we're working with Vertex Shader 3.0.

[antlers]

The responses in this interview ranged from the disingenuous to the dishonest. I'll mention a couple of points

So, modern applications render the Z buffer first. Then they render the scene to various 'textures' such as depth maps, shadow maps, stencil buffers, and more. These various maps are heavily biased toward Z and stencil rendering. Then the application does the final rendering pass on the visible pixels only. In fact, these pixels are rendered at a rate that is well below the 'peak' fill rate of the GPU because lots of textures and shading programs are used. In many cases, the final rendering is performed at an average throughput of 1 pixel per clock or less because sophisticated shading algorithms are used. One great example is the paint shader for NVIDIA's Time Machine demo . That shader uses up to 14 textures per pixel.

The only currently available "modern application" that does this is 3dMark03, and NVidia insists that it is doing it the wrong way. Evidently, NVidia is betting heavily that all developers adopt the Doom 3 model--especially to the extent of using proprietary NVidia extensions (such as those used by the Time Machine demo).

The NV30 GPU is the world's fastest GPU. It delivers better game performance across the board than any other GPU.

This is arguable at best. At high image quality settings in current games, the R9700 appears to be faster in some cases than the GeForce FX Ultra. To the limited extent that this statement is true, it applies only to the Ultra variant of the NV30, which apparently was released mainly to be benchmarked by reviewers and seems not destined to be widely available. If we are going to talk about limited availability boards, why not include the commercially available products with multiple R300 chips?

For the case of anti-aliasing, both Z and stencil operations are performed at the fragment (the AA sub-pixel sample) level. Otherwise, you would get errors at the fragment level, and those errors would propagate to the pixel level.

In other words with MSAA the pipeline provides 8 samples/cycle instead of 8 pixels/cycle. Using the same nomenclature, do you say the R300 provides 16 pipes when rendering with MSAA?

in fact, for lower power and quieter operation, you actually want some of the chip to be idle some of the time if it means that the parts that are active are more efficient at processing the current tasks.

This would mean something if the Ultra could run without the high-speed fan while processing a less-demanding 3d game. I've seen no mention that this is the case. 3d card noise really wasn't much of an issue before the Ultra was unveiled, anyway.

32-bit floating point precision is absolutely required for texture address calculations and texture lookups for dependent texture reads that are used for bump mapping, reflections, etc; 24-bit is not enough to get the right answer.

24-bit is perfectly adequate in most cases (see ATI's car demo)

For example, NVIDIA uses FP32 for texture address calculation. In the case of dependent texture reads (e.g. a bumpy shiny object with a reflection map in a scene), full precision (FP32) for the texture address calculation is critical for getting a high-quality result.

Humus' Mandelbrot demo is one big texture address calculation. Do the current drivers force it to run FP32 all the way through, regardless of precision hints, because it is used for texture lookups? (Hint, hint, Dave)

ATI's solution is tailored for older first person shooter applications that have square walls and a flat floor.

Of course, he is talking about the solution found in ATI's previous generation.

[Joe DeFuria]

Sorry, but this is ridiculous. It might be true that "8x1", "pixel fillrate" etc. are "antiquated" definitions, so nvdia thinks it's ok to change the definitions without telling anybody they have changed , just so the terms describe their architecture in a more favorable light?

Pretty much my thoughts exactly on that question. As soon as I read:

"No, we need to make sure that the definitions/specifications that we do use to describe these architectures reflect the capabilities of the architecture as accurately as possible."

My reaction was, "well, tell that to your marketing dept who is using definitions/specifications to describe your architecture in a way that is not accurate.

And then he goes into a diatribe about how (my interpretation) "theoretical numbers are never reached anyway, so who cares?"

This is a good one:

Tom's Hardware declared "NVDIA takes the crown" and HardOCP observed that NV30 outpaces the competition across a variety of applications and display modes.

Imagine that...nVidia giving props to [H] and Tom.

A few more quotes that I'd like to respond to:

Not all pixels are textured, so it is inaccurate to say that fill rate requires texturing.

I would also say it's inaccurate to say that a pixel requires a texture....but it also doesn't require color? (The FX cannot write more than 4 non-textured (but colored) pixels per clock either.)

For the case of anti-aliasing, both Z and stencil operations are performed at the fragment (the AA sub-pixel sample) level. Otherwise, you would get errors at the fragment level, and those errors would propagate to the pixel level.

Could anyone tell me how that reponse addresses the question? (What happens to stencil rate when MSAA is used?) Is he saying that stencil CAN'T be used when MSAA is used? (Or that it will require an additional pass compared to rendering witout stencil?)

As a consumer, you don't really care whether or not all of the transistors are busy or idle at any particular time -

Not really true. As a consumer, I care about cost. And generally speaking, the more that transistors sit around "idle", that's less bang for my buck that I'm getting.

Taken to the extreme....if I pay $400 for a GeForceFX, and all I do is run Excel and other 2D operations....that's a big waste.

In general , I see a lot of hypocricy concerning 24bit not being "enough" and their push to have 16 bit acceptable for DX9 shaders....

This was a gem....on drivers:

Our end users love it because they know the board they buy today will deliver even more performance in the future.

Right...as opposed to users preferring to get the most out of the hardware from day 1.

[Anonymous]

That was the biggest crock of outright horse shit i have ever read. He replied with completely Dishonest, and sometimes just Misleading "At best" information.

I am just sickened...

How can he Talk crap about ATi's FP24 beign inferior whenthe QUESTION was how can the FX qualify for DX9 when Its drivers force to fp16 BELLOW the needed requirement. Not to mention that their FP32 is TO SLOW TO USE in any kind of real game sinario.

Then his comments about ATI's AF and 45'... What a bunch of total *******!!!! The R300 fixed that problem.

Thats just a coupple. There are problems with the Integrity of every one of his statements.

DAMN!! Richard Huddy was correct. These guys have lost it.

[MuFu]

Originally Posted by Anonymous

Its drivers force to fp16 BELLOW the needed requirement.

Has this been proven yet?

MuFu.

[Arun]

I'd have been satisfied by the pipeline explanation if he didn't end like this:

And, I want to emphasize that what end users care most about is not pixels per clock, but actual game performance. The NV30 GPU is the world's fastest GPU. It delivers better game performance across the board than any other GPU. Tom's Hardware declared "NVDIA takes the crown" and HardOCP observed that NV30 outpaces the competition across a variety of applications and display modes.

Now I just realized it was just another lame PR response

Now, I kinda think that it's true the current way to think about pipelines is not the good one.
But what nVidia is trying to do here, is making sure there's no standard so they'll be able to call the NV40 "32x32" while, in practice, it might be something more like "10x1" :P

A better way to see this would be:
MIPS/clock x Bilinear Textures/clock or Trilinear Textures/clock

That would be, in the NV30's case:
450/500 x 8 or 4
Or, pretty much:
1 x 8 or 4

And in the R300's case:
3400 / 325 x 8 or 4
10 x 8 or 4

Err, suddently, the NV30 doesn't look so good
Sounds like that's why nVidia doesn't want a standard :P

for lower power and quieter operation, you actually want some of the chip to be idle some of the time if it means that the parts that are active are more efficient at processing the current tasks.

That makes some sense.
The problem is that they don't seem to have applied that to the rest of the design :P
So that comment is worthless PR crap IMO.

But...

One other thing to recognize is that even in new floating point applications, there is still a mix of integer, short floating point, and full floating point operations. When both data types and operation precisions are present, we can use BOTH the integer and floating pipelines and get twice the throughput

That's a very interesting thing, on the other hand!
AFAIK, didn't check the DX9 SDK PS stuff for a few weeks, there's only two levels of precision with PS2.0. & PS3.0.
And that's _pp & nothing at all. In the case of _pp, it's FP16. In the case of nothing at all in an instruction which could use _pp, it's FP32. In the case of nothing at all in an instruction which can't use _pp, it's FP16.

And there's no way to use the integer power of the NV30

Cg, however, does have native support for it. But does it actually work when using DX9?

This could be a quite important point indeed, as such an advantage can indeed be quite signifiant.

Oh, and...

Originally Posted by Anonymous

Then his comments about ATI's AF and 45'... What a bunch of total *******!!!! The R300 fixed that problem.

No it didn't

The R2xx only works perfectly at 0 & 90 degree
The R3xx "fix" is making it work perfectly at 45 degree.
Saying wether it's superior or not to nVidia's unified approach is another story. But saying it doesn't have disadvantages is simply false.


Uttar

[SirPauly]

In general , I see a lot of hypocricy concerning 24bit not being "enough" and their push to have 16 bit acceptable for DX9 shaders....

So true, imho.

[kyleb]

well i am left with more questions than answers from the responces he gave. most importantly i would like to know one thing; what planet is this guy on?

[Anonymous]

The R3xx "fix" is making it work perfectly at 45 degree.
Saying wether it's superior or not to nVidia's unified approach is another story. But saying it doesn't have disadvantages is simply false

BS.

The R300 FIXES the 45' error issue. And Further Nv30's method is far from an honest approach. I am sure that Dave was sent the information on the subject . Many websites were.

[rwolf]

Ah, it was nice to hear Nvidia's perspective on things. Sure there was a little BS in there, but for the most part it was very informative.

Good Question Dave and good responses Nvidia.

[Johnny Rotten]

Originally Posted by Anonymous

That was the biggest crock of outright horse shit i have ever read. He replied with completely Dishonest, and sometimes just Misleading "At best" information.

I am just sickened...

How can he Talk crap about ATi's FP24 beign inferior whenthe QUESTION was how can the FX qualify for DX9 when Its drivers force to fp16 BELLOW the needed requirement. Not to mention that their FP32 is TO SLOW TO USE in any kind of real game sinario.

Then his comments about ATI's AF and 45'... What a bunch of total *******!!!! The R300 fixed that problem.

Thats just a coupple. There are problems with the Integrity of every one of his statements.

DAMN!! Richard Huddy was correct. These guys have lost it.

Hi Hellbinder!

[Anonymous]

[Anonymous]

Hi Hellbinder!,

Who the hell is Hellbinder????

[Anonymous]

Ah, it was nice to hear Nvidia's perspective on things. Sure there was a little BS in there, but for the most part it was very informative

You have got to be kidding me.. A little BS??? nice to hear their perspective???? It was a crock! Informative??? Informing you of what exactly.. There is not even one single Straight honest reply in the entire thing!!

[kyleb]

Originally Posted by Anonymous

Hi Hellbinder!,

Who the hell is Hellbinder????

the forum member that obviously forgot to log in when he wrote that anonymous post above.

[John Reynolds]

Originally Posted by Anonymous

Hi Hellbinder!,

Who the hell is Hellbinder????

Oh, someone who posts from the exact same IP as you.

[andypski]

Originally Posted by Anonymous

You have got to be kidding me.. A little BS??? nice to hear their perspective???? It was a crock! Informative??? Informing you of what exactly.. There is not even one single Straight honest reply in the entire thing!!

However, it certainly informs you exactly what nVidia would like you to believe...

How much of that reflects reality... well...

[Snyder]

Wow.
Congrats Dave, this Q&A is IMO the best part of the preview - great questions, and Mr. Tamasi's answers are quite interesting...

[Hellbinder]

Oh, someone who posts from the exact same IP as you.

HA!.. I dont think so...

[kyleb]

that was your writeing up there though eh Hellbinder?

[Hellbinder]

eh???

[Tagrineth]

THE TAGRINETH™ BRAND PR-REVERSER™ TRANSLATOR:

No, we need to make sure that the definitions/specifications that we do use to describe these architectures reflect the capabilities of the architecture as accurately as possible.

Using antiquated definitions to describe modern architectures results in inaccuracies and causes people to make bad conclusions. This issue is amplified for you as a journalist, because you will communicate your conclusion to your readership. This is an opportunity for you to educate your readers on the new metrics for evaluating the latest technologies.

"No, we need to make sure that all the facts clearly show that we're better than the competition. See, these old terms? They actually tell the truth about our product! And it's not pretty! So let's just sweep the old, useful terminology out for the skewed terms that show how superiour our product is."

Not all pixels are textured, so it is inaccurate to say that fill rate requires texturing.

For Z+stencil rendering, NV30 is 8 pixels per clock. This is in fact performed as two 2x2 areas as you mention above.

For texturing, NV30 can have 16 active textures and apply 8 textures per clock to the active pixels. If an object has 4 textures applied to it, then NV30 will render it at 4 pixels per 2 clocks because it takes 2 clock cycles to apply 4 textures to a single pixel.

"See, what you used to think was 'fill rate', is in fact just 'texturing rate' - or the rate at which pixels are put out onto your screen. We like to think 'fill rate' means the rate at which our core does maths internally, even if the final rasterisation is still done the same way as you think you're used to from years of old, outdated competitors' products.

You see, by the conventional terminology, the truth comes out that we have an underperforming core! So we have to use totally useless, roundabout jargon to make it sound like 4 rendered pixels per clock is wonderful and new!"

For the case of anti-aliasing, both Z and stencil operations are performed at the fragment (the AA sub-pixel sample) level. Otherwise, you would get errors at the fragment level, and those errors would propagate to the pixel level.

"See, we can't answer that... cos if we do, we'll be admitting that our pipelines really can't do as much as the competitors. So in this case, let's just state the obvious and repeat something that was more or less implied in your question in the first place."

The applications choose the precision level of precision and may or may not use it as efficiently as possible.

"Well, if we really processed at FP32, you really think any of those benchmarks would be faster on our product? Jeeze... some people..." (hint: outright lie)

We also continue to optimize our drivers over time. NVIDIA's driver strategy is to have an initial driver that ships with new GPUs that is fast, stable and compatible. Once that initial driver is released, we go back and do another round of performance tuning to create a "Detonator" release that brings even more performance to both newer and older NVIDIA GPUs. Our end users love it because they know the board they buy today will deliver even more performance in the future

"Contrary to what some crackheads like John Carmack (what's so special about this guy anyway?) would have you believe, our driver teams are really a large number of monkeys. See, we do a great little trick whereby first the hardware engineers will actually make a driver that's stable and compatible, so the people are impressed by the compatibility when they buy it. Then we put the monkeys to work, randomly churning out some junk. Every month or two, by sheer random chance, a monkey will put out routines that run much faster than the old ones, but at the cost of breaking a bunch of other ones - but nothing slows down! And eventually, the odds play out that the monkeys give such a great boost in performance that nobody notices half the games out there won't run in the first place! Isn't life wonderful?"

According to DirectX 9 spec, FP24 is allowed, but we at NVIDIA believe it is insufficient to avoid errors for a variety of texture and geometry calculations. So we designed our products to use FP32. For example, NVIDIA uses FP32 for texture address calculation. In the case of dependent texture reads (e.g. a bumpy shiny object with a reflection map in a scene), full precision (FP32) for the texture address calculation is critical for getting a high-quality result.

"Well... we'd love to be honest here (really!)... but really. I can't change now, can I! I'll lose what little credibility I may once have had! So anyway, since Microsoft actually did something right, and didn't accept FP16, we really have to downplay the competitor's much faster and still perfectly good quality processing depth. So... yeah. Fuck low precision. Only the highest for us! (quick, hide the monkeys' latest FP16 speed hacks!)"

And, of course, drivers would fail WHQL if they fail to meet minimum WHQL requirements such as FP24 or higher for texture address calculation.

"I think I'll just state the obvious again... and gloss over the fact that we don't even have a WHQL driver yet anyway. "

The techniques used in the "Balanced" setting and the "Aggressive" are used specifically to give the end user more performance. NVIDIA added these settings to give end users more options to balance quality versus performance. I would classify this as "adaptive" Trilinear. If the user wants the classic Trilinear algorithm applied to every pixel, then the user chooses the "Application" setting and uses the video configuration options in the application itself to choose Trilinear. If the user wants to use the adaptive algorithms in NV30, then he or she can choose the "balanced" setting which is more conservative, or the aggressive setting.

"Mmm... you really got us on that one. Think, think... ah, here we go. See, ATi really nailed us in this one, so we had Carrot Top working nonstop on a way to catch up to the competitors' performance. We came up with something that looks like crap - but it does look better than regular filtering! - but performs almost as good as the competitor! RAH RAH GO US!"

You mentioned that ATI delivers maximum anisotropy at the 90 degree angles but you failed to highlight the fact that they deliver lower anisotropy at other angles (most notably 45 degrees). This is a clever trick but the consequence of this is image quality that varies by the angle of the polygon. In contrast, NVIDIA's solution delivers equivalent anisotropy (and therefore equivalent *quality*) at every polygon angle

"Gah! You pinned us... let's think here... ah! Here's a way to slam our competitor! So anyway, let's just ignore our semi-decent performing modes and look at the somewhat ridiculously slow but great-looking mode. See, our competitor's previous product didn't do anything special at 45º angles - but ours does best at that angle! Isn't it great! (quick! hide the 'balanced' and 'aggressive' screenshots that show we do even worse at 45º than our competitor did!)"

ATI's solution is tailored for older first person shooter applications that have square walls and a flat floor. NVIDIA's solution is tailored for modern applications that use a lot more geometry to make the environment richer. Rounded walls, outdoor terrain and vegetation are key elements of next-generation applications and those features cause more polygons to intersect the screen at non-90-degree angles.

"Building on the above, the competitor's old product so embarrassed us performance-wise with their AF, that we'll just once again gloss over how bad our own 45º filtering is in our performance modes..."

(aside: aggressive and balanced both at 8x if you want to see just how bad nVidia's 45º angles are!)

NV30's implementation is different from Radeon 8500 because it was designed by NVIDIA, with a different design philosophy. No two 3D architectures are exactly the same between different vendors.

"Mmm... I'm running out of drivel here! MUST THROW OUT MORE STUFF HE ALREADY KNOWS TO CONFUSE HIM!"

EDITOR'S NOTE: The above recently received the National Captain Obvious Award™! Congrats to NVIDIA Corp for a wonderful pat on the back! (aside: I'm shocked nobody else saw that horrific line...)

(final aside - if you want me to keep up the PR-REVERSER™ TRANSLATOR for other Q&A sessions I'll be more than happy to. )