Hyp-X said:
The difference is:
- the R200 path uses normalization cubemaps for vector normalization, and uses a low order approximation to specular power.
- the R300 path uses arithmetic vector normalization (dp3/rsq/mul), and arithmetic specular power calculation (log/mul/exp).
The R200 path is likely bandwidth limited (the cubemap lookups can be stressful because of the non-standard read pattern).
The R300 path is likely shader computation limited.
The fact that the difference is small only shows how well balanced the R300 really is.
...
What is not clear is whether the NV30 path uses cubemaps and what kind of approximations used. I woldn't be surprised if using the FP unit for the rsq in normalization would be faster than using cubemaps (if everything else is using the FX combiners).
I had a response to this post started that I never quite finished, trying to figure out if it was more likely the NV3x path would use math or cubemap lookups to renormalize. (It seems clear from Carmack's Jan 17 .plan that, at that point, only the ARB2 path did this; but obviously that could have easily changed since.)
In that vein, I found it extremely interesting that one of the optimizations made by HL2's "mixed" DX9 mode--essentially their version of an NV3x path (although obviously without recourse to FX12 ops)--was that, unlike the full DX9 path, it often uses lookups to precalculated textures in place of doing the math with PS 2.0. While it was not specifically mentioned by name, the use of specular lighting and bump mapping has got to mean that one of the prime instances of this is for vector renormaliztion.
In other words, it's worth noting that in Valve's version of the NV3x path, they have apparently found it's a performance benefit to use a cubemap lookup instead of math to renormalize.
On the other hand, it's worth noting that the only NV3x card tested that seems a big gain from the "mixed" path is the 5900; the 5600 actually manages to
lose performance, and this is on top of other optimizations like more liberal use of the _pp hint and rewritten shaders. Of course the 5900 is the most likely to reap performance gains from a shader-for-bandwidth trade, because it has loads of ridiculous bandwidth to spare (particularly with no AA). The 5800 wasn't tested, of course, but I'd expect the opposite from it, seeing as how it's by far the most bandwidth starved card ever, uh, I mean, of the NV3x family.
It's not really clear of course that Doom3 would see a similar performance trade-off from this decision. You made the argument that NV3x should have the FP32 unit free to do normalization analytically, because most of its shader calculations will be using the FX12 units instead. I'm not sure that's entirely true when you consider that the FP32 unit shares functionality with the texture coordinate generators, and thus won't actually be free very often in a shader that's heavy on texture sampling, as I think the Doom3 lighting algorithm is. Of course you might expect it to be more free running Doom3's shaders than running the PS 2.0 shaders in HL2, which won't be making use of the FX12 units at all.
So where does that leave us? Unsure. On the one hand, we have a specific example of a developer, faced with the very same decision, essentially telling us that the way to optimize for NV3x is to use cubemaps, not math. On the other, the card that shows by far the greatest benefit from this optimization is the one that's supposed to be running the ARB2 path instead. Maybe the notion that NV35 is supposed to have identical performance on the NV3x and ARB2 paths can tell us the answer--that would presumably indicate the NV3x path normalizes with math after all, since it would appear to be a significant advantage for NV35 to use cubemaps instead.
Blah blah blah. I guess the best we can do is: it probably uses math but who knows. Incidentally, it's worth pointing out that on the off chance the NV3x path uses cubemap lookups like the R200 path, it should actually end up looking
worse than the R200 path run on the R3x0, right? (Same features enabled, but using primarily FX12 and FP16 instead of FP24.)
