A Nouveau 3D Driver That Works For Old NVIDIA Hardware

[phoronix]

Phoronix: A Nouveau 3D Driver That Works For Old NVIDIA Hardware

While there is now DRM support in the Linux 2.6.33 kernel for the Nouveau driver that carries the bits for kernel mode-setting, 2D (EXA) acceleration, and other fundamental functions on NVIDIA graphics processors, the Gallium3D driver still is incomplete. Prior to focusing solely on Gallium3D for their OpenGL acceleration, the Nouveau project was working on a DRI driver for classic Mesa, but that work was dropped in 2008 to focus entirely on Gallium3D support...

http://www.phoronix.com/vr.php?view=Nzk1NA

[Tommy666]

the shit has been merged to mesa-master

[remm]

And the Nouveau 3D driver is now in Fedora 13
http://koji.fedoraproject.org/koji/b...buildID=154376

[mitch074]

I think the Geforce 2 MX is NV11.

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.

[Adarion]

NV20 covers the Geforce2 and Geforce4MX card families

I think the Geforce 2 MX is NV11.

[mitch074]

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.

[marcheu]

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.

[bridgman]

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...

[cb88]

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

[bridgman]

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.