Pipe Confusion

thanks

 

It's a bit offtopic, but can anyone point me some sort of a diagram of the vertex pipeline in NV3x.
All I remember is that the VS processing in the FX series GPU's is performed by a "plain" array of mini-SIMD/FP units, forming the "virtual" Vertex Shader pipes (suppose, they are visible AS regular VS pipes to the driver/API).

 

The array story was just a way to avoid saying "We've one less geometry unit than ATI".

 

Hey Tridam,

I see your definition is of the pixel configurations is - how to put it - a bit more "technical" and more accurate than my definition. A agree to that. I will accept your definition. 8)

But I have one doubt, about the way certain NV3x cards were handling those 2x2 or 4x1 situations.

As far as I know the 4x1 configuration was only possible with the NV31, NV34 and NV36 only if no shaders at all were used, basically in Directx-7 situations. The moment any shaders had to be handled, the cards instantly switched to the 2x2 configuration. So basically 4x1 is for no use, in my oppinion. I am not sure, but I think this was the situation also with NV30 and NV35. Also I think the NV34 couldn`t do the 4x1 "trick".

All in all I must admit, the NV3x was a pretty interesting architecture. I feel I`m gonna miss it


They way NV3x could use the "legacy" register-combiners for less complex shaders, the way the "shader compiler" did all the "hacks" in order to direct as much as possible shader instructions towards the combiners, stuff like that

By the way... what`s the story with the nv shader compiler now, with the 6-Series ? I am sure it is active and used, but what are the aspects now ?
( I know that it does some instruction re-ordering to better use the dual-issued and co-issued characteristics of the NV4x core ) . I would love to read some more in-depth article on this topic.

 

I think NV (for the NV3X gen) vastly underestermated the requirement of 'advanced sequencers' (in hardware) that distribute work to the ALUs and dynamically manage registers. This was a basic requirement for shader processing.

The early versions of NV3X's shader compiler was very basic. Pre-computed (prob hand-coded) shaders were supplied in the driver to replace the versions bundeled with games (and benchmarks ).
Later on the shader compiler was more efficent (but the shader replacements stayed).

In NV40 it was mentioned that it had the 'Shader Instruction Dispatcher' in hardware. Add that to doubling the register file (allowing 8 FP16 and 4 FP32 temps), spliting the primary ALU into two ALUs (distubuting the instructions and duplicating one MUL, I think), more flexible i.e co-issue, the addition of dual-issue, adding the 'SFU' units Special Function Units and FP16 normalization units Etc). All this (and more that I've prob missed) added up to make it a much faster shader processor.

NV40 had a shader compiler developed at the same time as the hardware (also it was mentioned that some hardware changes were made to better help the compiler schedule 'to the hardware'). Shader replacement remains for NV40 but to much less extent then NV3X.

G70 is said to have no shader replacements at all (anyone tested this yet). This makes sence as NV40 shader replacements wouldn't be optimal (lack of extra MADDs for the first shader unit etc).