What's Wrong with NVIDIA?

Getting to the meat of the problem, how can it be that NVIDIA could perform so poorly in a native DirectX 9 code path and do better, but not extremely, in their own special "mixed mode." In order to understand why, we have to look at the modifications that Valve made to the NV3x code path; taken directly from Gabe Newell's presentation, here are the three major changes that were made:

Special Mixed Mode for NV3x
- Uses partial-precision registers where appropriate
- Trades off texture fetches for pixel shader instruction count (this is actually backwards, read further to learn more)
- Case-by-case shader code restructuring

So the first change that was made is to use partial-precision registers where appropriate. Well, what does that mean? As we've mentioned in previous articles, NVIDIA's pixel shading pipelines can either operate on 16 or 32-bit floating point numbers, with the 32-bit floats providing greater precision. Just like on a CPU, the actual FPUs that are present in the pixel shader units have a fixed number of local storage locations known as registers. Think of a register as nothing more than a place to store a number. With the NV3x architecture, each register can either hold one 32-bit floating point value or it can be used as two 16-bit floating point registers. Thus, when operating in 16-bit (aka partial precision) mode, you get twice as many physical registers as when you're running in 32-bit mode.

Note that using 32-bit floating point numbers doesn't increase the amount of memory bandwidth you're using. It simply means that you're cutting down the number of physical registers to which your pixel shader FPUs have access. What happens if you run out of registers? After running out of registers, the functional units (FPUs in this case) must swap data in and out of the graphics card's local memory (or caches), which takes a significantly longer time - causing stalls in the graphics pipeline or underutilization of the full processing power of the chip.

The fact that performance increased when moving to partial-precision (16-bit) registers indicates that NVIDIA's NV3x chips may have fewer usable physical registers than ATI's R3x0 series. If we're correct, this is a tradeoff that the NVIDIA engineers have made and it is to conserve die space, but we're not here to criticize NVIDIA's engineers, rather explain NVIDIA's performance here.

Next, Gabe listed the tradeoff in pixel shader instruction count for texture fetches. To sum this one up, the developers resorted to burning more texture (memory) bandwidth instead of putting a heavier load on computations in the functional units. Note that this approach is much more similar to the pre-DX9 method of game development, where we were mainly memory bandwidth bound instead of computationally bound. The fact that NVIDIA benefited from this sort of an optimization indicates that the NV3x series may not have as much raw computational power as the R3x0 GPUs (whether that means that it has fewer functional units or it is more picky about what and when it can execute is anyone's guess).

The final accommodation Valve made for NVIDIA hardware was some restructuring of shader code. There's not much that we can deduce from this other than the obvious - ATI and NVIDIA have different architectures.

ATI & Valve - Defining the Relationship Improving Performance on NVIDIA
Comments Locked

111 Comments

View All Comments

  • Anonymous User - Friday, September 12, 2003 - link

    Anand, when using the Print Article feature in Mozilla 1.4, I was shown only graphs from one map throughout. For instance, after clicking Print Article, all graphs were of the bug level. Hitting F5 showed them all to be of techdemo. In both cases, some graphs didn't correspond to your comments.

    This may be b/c the article was just posted, but thought I'd give you a heads-up anyway.

    Thanks for the interesting read, and hopefully we'll see screenshots of the differences between the DX8.0. 8.1, 8.2, NV3x, and DX9 modes soon (the only thing lacking from this article, IMO)!
  • Anonymous User - Friday, September 12, 2003 - link

    .. goddammit, all the flashes are arranged improperly. (Techdemo on bugbait pages, city on techdemo...) FIX IT.
  • Anonymous User - Friday, September 12, 2003 - link

    I was hoping anand would compair a 128mb 9800pro to a 256mb one, guess I'll still have to wait =(
  • Anonymous User - Friday, September 12, 2003 - link

    Hey Anand, you have a 9500 Pro lying around?

    Eh, well, it doesn't need to be included anyway. We all know how it would do: 5% worse than the 9700 Pro.
  • Anonymous User - Friday, September 12, 2003 - link

    #5 & #6 : +1
    I ll keep my G4 Ti 4200@300/600.
    I m sure HL² will still rocks in DX 8.1
  • Anonymous User - Friday, September 12, 2003 - link

    Where are the numbers with AA/AF enabled? I know the article intimates that there's a negligible performance hit, but I'd still like to see the numbers.
  • Anonymous User - Friday, September 12, 2003 - link

    Man, the Ti series has been doing this for a while!

    http://www.amdmb.com/article-display.php?ArticleID...
  • Anonymous User - Friday, September 12, 2003 - link

    I feel the same way about the GF4Ti series. Never did like the FXes much...
  • Anonymous User - Friday, September 12, 2003 - link

    Hahahahaha.

    Go you Ti4600, GO! I BELIEVE IN THE Ti4600!

    If all I am going to lose is a bit of image quality, then no great loss. At least it isn't back to 640x480!

  • Anonymous User - Friday, September 12, 2003 - link

    Wow 9800 pro barely edges out 9700 pro. 9600 pro seems to be the best deal if people are still waiting to upgrade.

    Obviously Nvidia lost this round with nv30 and nv35.

Log in

Don't have an account? Sign up now