NV30 are GeForce 5. The highest GeForce 4 code number is the NV28, the 4200 TI. The thing is, as you said, anything below NV30, with supposedly pixel shaders, requires some effort to use them. They are the first attempts for a programmable pipe and are thus crude implementations. Even GeForce 3 has pixel shaders (the nFinit FX engine), but it's pretty much useless. I was surprised to see GeForce 4 (non MX) cards being mentioned as Gallium3D friendly. I have an NV28M and anything involving pixel shaders that I've tried has failed. Maybe it's drivers related...
Ouch - I mixed these up one level.
NV1x: Geforce256, Geforce2
NV25+: Geforce4 Ti
NV30 are Geforce 5, indeed. They sport a NV2+ mode, which will be unused in Gallium in favour of the programmable shaders.
There was, at one time, talks about using an interpreter to use Gallium3D on NV2X. Current Mesa code uses NV2x' NV1x compatibility mode (which allows the use of NV1x driver code on NV2x, but of course, limited to NV1x capabilities). In essence, NV2x cards are underused.
That was some time ago though, I wonder what's up with that.
I think everyone agreed that it was theoretically possible to write driver code which would look at the requested shader processing, identify the cases which a fixed-function chip could handle (a lot of apps can still run on fixed-function chips today), then set the FF logic and proceed with the draw commands, and that's as far as it went. There are still some unanswered questions with that approach, like "what capabilities should the driver expose to the app and how do we manage that inside the driver stack ?".
Any Gallium3D-based 3D driver would normally expose shader support to the app, but some apps implement different code paths depending on what the driver supports and those apps may only work on fixed function chips if the app chooses fixed-function code paths based on the available driver extensions... then the 3D driver would turn the fixed function calls into shader code, pass that down to the Gallium3D HW driver, which would then translate the shader code back into fixed function operations... but which would fail if the app passed down "real" shader code rather than a shader implementation of fixed function operations. Maybe.
On the whole, implementing a traditional mesa stack for pre-shader chips seems like a better (if less interesting) solution.
The issue here is really just working with Gallium3D and older chips -- previous driver stacks, including the proprietary ones, had native support for fixed function GPUs. Gallium3D is the first low level API to be totally shader based...
Like I said in another post, I mixed up family names, so here it is in full glory:
- NV10 is the original Geforce256 model
- NV11 is the Geforce2 MX, a die shrink of Gf256
- NV15 is the Geforce2 (and Ti), which enabled all 'hidden' features present in Gf256.
- NV17 to NV19 cover Geforce4MX, nForce2 and Go cores: same feature set as before, but a vastly superior memory controller made the chip much more powerful, as the NV1x architecture had, up until then, been extremely bandwidth constrained.
- NV20 is the Geforce3: it had pretty much the same bandwidth limitations as NV1x up to NV15, but it had shaders capabilities.
- NV25 is the Geforce4 Ti: more capable and less memory constrained than the Gf3, it was vastly superior.
- NV28 is the Geforce4 Ti for AGP 3.0/8X: nothing new aside from that.
I fondly remember my Ti 4200/8X: I kept this card for years, and my brother made extensive use of it when he managed to fry his Radeon 9500.
The Nouveau Mesa driver will support these fixed functions cards, although I really thought that NV2x support was obtained through the integrated NV1x backward compatibility mode. Maybe that has changed.