Ouch - I mixed these up one level.
Originally Posted by ioannis
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.
well apparently the nvidia driver does this to some extent already as a geforce2 is reported as supporting OpenGL 1.4 iirc so some of that must be in software magic
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...
Actually, this news needs a correction. The fixed function driver supports the whole nv20 family, which includes nv20, nv25 and nv28. That means the fixed driver supports all Geforce 3 and 4 Ti.
The gallium drivers are intended for nv30 and more, so that is geforce 5xxx and up.
Aaah, since we've got a Nouveau developer here... I thought the Mesa driver supported NV2x through NV1x compatibility mode, what's up with that?
And now it shows how much a TiNDC is required.
I think the Geforce 2 MX is NV11.
Originally Posted by mitch074
Like I said in another post, I mixed up family names, so here it is in full glory:
Originally Posted by Adarion
- 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.
the shit has been merged to mesa-master