NV30 fragment processor test results

According to further tests, this is what the NV30 fragment shader architecture looks like:

Code:

FLOAT/TEXTURE-UNIT (handles FP16, FP32 and texture)
  |
INTEGER-UNIT (handles FX12, 1-2 ops in parallel)
  |
INTEGER-UNIT (handles FX12, 1-2 ops in parallel)
  |
(loopback or output)

There are 4 of these pipelines, or 8 pipelines that output every other cycle. Take your pick. The only case where 8 non-integer operations per cycle have been observed is with PS1.1 style non-dependent texture fetches.


Unit description:

The FLOAT/TEXTURE unit can handle any instruction with any format of input or output. All instructions execute in one cycle, except for LRP,RSQ,LIT,POW which take 2 and RFL which takes 4.

The INTEGER unit can perform 1 generic integer operation or 2 parallel multiplies. There are some limitations on when the parallel multiplies can be done (see detailed tests at end).

When textures are fetched, nothing else can be done in the FLOAT/TEXTURE unit. The following INTEGER unit can use the fetched texture result freely. FLOAT/TEXTURE unit can perform one fetch if the coordinates come from a previous calculation (meaning 4 textures/cycle). If the coordinates come directly from inputs as in PS1.1, the unit can perform a pair of texture fetches (meaning 8 textures/cycle).

The total integer performance can be calculated by combining the FLOAT/TEXTURE unit and the two INTEGER units. This gives 5 multiplications or 3 generic integer operations per cycle.

It can also be speculated, that the INTEGER unit is able to perform one PS1.1-PS1.3 register combiner operation. It seems to have the required amount of MUL/ADD units.


Registers and performance:

Number of registers used affects performance. For maximum performance, it seems you can only use 2 FP32-registers. Every two new registers slow down things:

Code:

   4.23 cycles/pixel:  1 regs, 16 add instr, 1 mov instr
   4.23 cycles/pixel:  2 regs, 16 add instr, 1 mov instr
   4.66 cycles/pixel:  3 regs, 16 add instr, 1 mov instr
   4.66 cycles/pixel:  4 regs, 16 add instr, 1 mov instr
   6.08 cycles/pixel:  5 regs, 16 add instr, 1 mov instr
   6.08 cycles/pixel:  6 regs, 16 add instr, 1 mov instr
   8.52 cycles/pixel:  8 regs, 16 add instr, 1 mov instr
  13.67 cycles/pixel: 10 regs, 16 add instr, 1 mov instr
  14.36 cycles/pixel: 12 regs, 16 add instr, 1 mov instr
  19.74 cycles/pixel: 14 regs, 16 add instr, 1 mov instr
  20.64 cycles/pixel: 16 regs, 16 add instr, 1 mov instr

One can fit two FP16 registers into one FP32 register, so using FP16 doubles the number of registers you can use without lowering performance. With two registers as in these tests, the performance for both is identical.


Finally results for individual programs:

Test method: large number of full window quads were drawn and timed. Zbuffer disabled, color writes enabled. Result is cycles/pixel, which has been scaled by 4 (assuming 4 pipelines) and 0.947 (invented efficiency factor that makes all numbers very near integers).

Driver 43.45, Geforce FX5800 Ultra.

This gives the number of rounds the pixel has to make in the above architecture, assuming a new pixel goes to the pipeline every cycle, and assuming there are 4 pipelines. The operations assumed to be performed in each round are shown in the parenthesis.

The first number tells how many micro-ops the program takes when all instructions depend on the previous one. The second number corresponds to case with paired instructions, where every pair is dependent on the previous pair (there can be difference only when there are multiply instructions).

In the program description string each letter corresponds to one instruction:
a:FX12 add (same results for multiply-accumulate, not shown)
m:FX12 mul
A:FP16 add (FP32 has same speed)
M:FP16 mul (FP32 has same speed)
T:texture fetch with coordinates from register (dependent fetch)
S:texture fetch with coordinates directly from pixel inputs

Code:

rounds:  1.00  1.01  prog: a         (1:a          )
rounds:  1.00  1.00  prog: aa        (1:aa         )
rounds:  1.00  1.00  prog: aaa       (1:aaa        )
rounds:  2.00  2.00  prog: aaaa      (2:aaa,a      )
rounds:  2.00  2.00  prog: aaaaa     (2:aaa,aa     )
rounds:  2.01  2.01  prog: aaaaaa    (2:aaa,aaa    )
rounds:  3.01  3.01  prog: aaaaaaa   (3:aaa,aaa,a  )
rounds:  1.01  1.00  prog: A         (1:A          )
rounds:  1.00  1.00  prog: Aa        (1:Aa         )
rounds:  1.01  1.00  prog: Aaa       (1:Aaa        )
rounds:  2.00  2.01  prog: Aaaa      (2:Aaa,a      )
rounds:  2.00  2.01  prog: AA        (2:A,A        )
rounds:  2.01  2.01  prog: AAaa      (2:A,Aaa      )
rounds:  1.00  1.00  prog: T         (1:T          )
rounds:  1.00  1.00  prog: Ta        (1:Ta         )
rounds:  1.00  1.00  prog: Taa       (1:Taa        )
rounds:  2.00  2.00  prog: Taaa      (2:Taa,a      )
rounds:  2.00  2.00  prog: TT        (2:T,T        )
rounds:  2.01  2.01  prog: TTaa      (2:T,Taa      )
rounds:  1.00  1.00  prog: S         (1:S          )
rounds:  1.00  1.00  prog: Sa        (1:Sa         )
rounds:  1.00  1.00  prog: Saa       (1:Saa        )
rounds:  2.00  2.00  prog: Saaa      (2:Saa,a      )
rounds:  1.00  1.00  prog: SS        (1:SS         )
rounds:  1.00  1.00  prog: SSa       (1:SSa        )
rounds:  1.00  1.01  prog: SSaa      (1:SSaa       )
rounds:  2.00  2.00  prog: SSaaa     (2:SSaa,a     )
rounds:  1.00  1.00  prog: m         (1:m          )
rounds:  1.00  1.00  prog: mm        (1:mm         )
rounds:  1.01  1.00  prog: mmm       (1:mmm        )
rounds:  2.00  1.00  prog: mmmm      (2:mmm,m      )
rounds:  2.00  1.01  prog: mmmmm     (2:mmm,mm     )
rounds:  2.01  2.01  prog: mmmmmm    (2:mmm,mmm    )
rounds:  3.01  2.00  prog: mmmmmmm   (3:mmm,mmm,m  )
rounds:  1.00  1.00  prog: M         (1:M          )
rounds:  2.01  1.00  prog: Mmmm      (2:Mmm,m      )
rounds:  2.01  1.00  prog: Mmmmm     (2:Mmm,mm     )
rounds:  2.01  2.00  prog: Mmmmmm    (2:Mmm,mmm    )
rounds:  3.01  2.00  prog: Mmmmmmm   (3:Mmm,mmm,m  )
rounds:  2.00  2.00  prog: MM        (2:M,M        )
rounds:  2.01  2.01  prog: MMmm      (2:M,Mmm      )
rounds:  3.01  2.01  prog: MMmmmm    (3:M,Mmm,mm   )
rounds:  3.01  3.01  prog: MMmmmmm   (3:M,Mmm,mmm  )
rounds:  4.02  3.01  prog: MMmmmmmm  (4:M,Mmm,mmm,m)
rounds:  1.00  1.00  prog: T         (1:T          )
rounds:  1.01  1.00  prog: Tmm       (1:Tmm        )
rounds:  2.01  1.00  prog: Tmmm      (2:Tmm,m      )
rounds:  2.00  1.01  prog: Tmmmm     (2:Tmm,mm     )
rounds:  2.01  2.00  prog: Tmmmmm    (2:Tmm,mmm    )
rounds:  2.00  2.00  prog: TT        (2:T,T        )
rounds:  2.01  2.01  prog: TTmm      (2:T,Tmm      )
rounds:  3.01  2.01  prog: TTmmm     (3:T,Tmm,m    )
rounds:  3.01  2.01  prog: TTmmmm    (3:T,Tmm,mm   )
rounds:  3.01  3.01  prog: TTmmmmm   (3:T,Tmm,mmm  )
rounds:  1.01  1.01  prog: S         (1:S          )
rounds:  1.00  1.00  prog: Smm       (1:Smm        )
rounds:  2.00  1.00  prog: Smmm      (2:Smm,m      )
rounds:  2.00  1.00  prog: Smmmm     (2:Smm,mm     )
rounds:  2.01  2.01  prog: Smmmmm    (2:Smm,mmm    )
rounds:  1.00  1.00  prog: SS        (1:SS         )
rounds:  1.00  1.00  prog: SSmm      (1:SSmm       )
rounds:  2.01  1.01  prog: SSmmm     (2:SSmm,m     )
rounds:  2.01  1.00  prog: SSmmmm    (2:SSmm,mm    )
rounds:  2.01  2.00  prog: SSmmmmm   (2:SSmm,mmm   )

Code:

rounds:  1.00  1.00  prog: Amm       (1:Amm        )
rounds:  1.01  1.00  prog: Aam       (1:Aam        )
rounds:  1.00  1.00  prog: Ama       (1:Ama        )
rounds:  1.00  1.00  prog: Aaa       (1:Aaa        )
rounds:  2.00  1.00  prog: Ammm      (2:Amm,m      )
rounds:  2.00  1.00  prog: Aamm      (2:Aam,m      )
rounds:  2.00  2.00  prog: Amam      (2:Ama,m      )
rounds:  2.00  2.00  prog: Aaam      (2:Aaa,m      )
rounds:  2.00  1.01  prog: Amma      (2:Amm,a      )
rounds:  2.00  2.00  prog: Aama      (2:Aam,a      )
rounds:  2.00  2.01  prog: Amaa      (2:Ama,a      )
rounds:  2.00  2.01  prog: Aaaa      (2:Aaa,a      )
rounds:  2.00  1.00  prog: Ammmm     (2:Amm,mm     )
rounds:  2.00  2.00  prog: Aammm     (2:Aam,mm     )
rounds:  2.00  2.00  prog: Amamm     (2:Ama,mm     )
rounds:  2.00  2.00  prog: Aaamm     (2:Aaa,mm     )
rounds:  2.00  2.00  prog: Ammam     (2:Amm,am     )
rounds:  2.00  2.01  prog: Aamam     (2:Aam,am     )
rounds:  2.00  2.00  prog: Amaam     (2:Ama,am     )
rounds:  2.00  2.00  prog: Aaaam     (2:Aaa,am     )
rounds:  2.01  2.00  prog: Ammma     (2:Amm,ma     )
rounds:  2.00  2.01  prog: Aamma     (2:Aam,ma     )
rounds:  2.00  2.00  prog: Amama     (2:Ama,ma     )
rounds:  2.00  2.01  prog: Aaama     (2:Aaa,ma     )
rounds:  2.00  2.00  prog: Ammaa     (2:Amm,aa     )
rounds:  2.00  2.00  prog: Aamaa     (2:Aam,aa     )
rounds:  2.00  2.00  prog: Amaaa     (2:Ama,aa     )
rounds:  2.01  2.01  prog: Aaaaa     (2:Aaa,aa     )

More test cases were used to come to these conclusions (especially for the organization of the FX12 units). The second column in the second list above shows the performance for different cases in the integer combiners.

There are probably errors in these tests, and there may be cases where performance is lower due to some limitation not observed. There could also be cases where 8 float-operations/cycle were possible, but at least with common operations such cases were not found.

In any case the overall performance should hopefully be accurate.

 

The performance numbers don't really tell how many units are involved, just how many results we get each cycle. There could be four texture units that can do one trilinear or two bilinear. Or there could be 8 texture units, two connected to each fragment processor. The actual hardware wiring is probably much more complicated than the simple diagram.

From my tests, it seems that to get 8 texture fetches per cycle, the fetches have to be paired and nondependent. One can do integer operations after the pair as if the pair were a single FP operation, which suggest they are done in parallel at least from the fragment processors perspective.

The number of cycles a texture fetch takes is variable depending on how many samples are needed. For example you can even get 8 trilinear or anisotropic samples/cycle, if they happen to require just magnification (meaning they are effectively bilinear).

The texture used is a mipmapped 16x16 RGBA texture (4 components). It is small enough to fit into caches and give constant performance.

What do you mean by components and register space? Perspective textures and cubemaps have the same number of input coordinates (3) and the same number of outputs (4 for RGBA texture).

When I mentioned register limitations, I meant temporary registers (R1,R2,...) which you use to store intermediate results. In addition there are input and output registers (colors, texture coordinates, result), using which doesn't add extra slowdown. However, there seem to be limitations on where input registers can be efficiently used. Using a texcoord or color in fp-calculation costs an extra cycle. This makes the register connections look something like:

Code:

temporary registers (R0,R1,..,H0,H1,..)
  |
FLOAT (perhaps does DDX/DDY for dependent fetches)
  | \
  | TEXTURE <-- f[TEX0],f[TEX1],.. (DDX/DDY is free)
  | /  
INTEGER <-- f[COL0],f[COL1]
  |
INTEGER <-- f[COL0],f[COL1]
  |
(loopback to temporary registers or output)

If input regs are used in the unit they are connected to, using them is free. If they are used for FLOAT/TEXTURE coords, an extra round is needed to first store them into a temp register. For example "ADD R0,f[TEX0],f[TEX0]" takes two rounds.

I tried cube maps, and they are as fast as normal textures, meaning NV30 can fetch 8 cube-maps/cycle if coordinates come from inputs, or 4 cube-maps/cycle if coordinates come from temp registers.

Older NV_fragment_program specs say (this line is no longer present in latest specs though): "Fragment program instructions using the fragment attribute registers f[FOGC] or f[TEX0] through f[TEX7] will be carried out at full fp32 precision, regardless of the precision specified by the instruction."

From my tests it seems texture coordinates are handled as FP32 and the result can be stored to FP32 or FP16 with same performance.

 

Yes you are right. Integer units can be bypassed or the float data just flows through unchanged.

Program length doesn't seem to matter. Program is probably loaded from memory and long programs would only be slower in bandwidth limited cases. I also tried texture fetches and they went the same speed (with a small texture that fits in caches).

Code:

     0.95 rounds: 1 add cwrite
     2.00 rounds: 2 add cwrite
     4.00 rounds: 4 add cwrite
     8.01 rounds: 8 add cwrite
    16.03 rounds: 16 add cwrite
    32.06 rounds: 32 add cwrite
    64.14 rounds: 64 add cwrite
   128.23 rounds: 128 add cwrite
   256.40 rounds: 256 add cwrite
   512.81 rounds: 512 add cwrite
  1002.50 rounds: 1000 add cwrite

Register usage order doesn't seem to matter either. Just the number of individual registers you use. In the tests below, there were 240 "ADD R0,R0,R0" instructions at the start, and then 16 instructions that push the number of registers used to the specified number. Using different amount of instructions (tried 32 and 256) gives the same performance ratio between the cases.

Code:

 256.39 rounds: 2 regs, 256 instr
 277.92 rounds: 4 regs, 256 instr
 357.52 rounds: 6 regs, 256 instr
 476.16 rounds: 8 regs, 256 instr
 727.96 rounds: 10 regs, 256 instr

It seems the compiler optimizes MOV instructions away. Adding them doesn't slow things, unless they move between different types of registers (int to float for example).

For all operations I tried too variants (example for ADD):

dependent:
ADD R0,R0,R0
ADD R0,R0,R0
ADD R0,R0,R0
ADD R0,R0,R0
...
ADD o[COL0],R0,R0

paired:
ADD R0,R0,R0
ADD R1,R1,R1
ADD R0,R0,R0
ADD R1,R1,R1
...
ADD o[COL0],R0,R1

The performance was always the same, except for FX12 multiplies. In the end I attributed this to having the capability for two parallel multiplications in the integer unit.

Even though the above programs are trivial (initial value of all registers is 0 and so the result is 0) the driver doesn't seem to optimize them. Of course writing code like the above doesn't make sense, so why spend time optimizing it. The driver does optimize away calculations whose results are never used and seems to reorder instructions (moving FX12 instructions to between FP instructions).

I tried separately to load some data (texture coordinates/colors) into registers before some tests, but it always just added 1-2 cycles to the total which was consistent with a few extra load instructions. I also tried instruction triples for multiplies, but that didn't go faster than pairs.