A post to a thread called [g200-dev]G400 specs released gives John Carmack's take on what the newly-released specs mean for Quake III Arena appearance and performance on Matrox G200 and G400 accelerators under Linux, talking about the G400's standout performance on hi-resolution testing:

Very little has changed, so it should be easy to have the driver support both G200 and G400 from the same binary. I want to set a good example for the windows vendors and not proliferate lots of different driver versions...

Speaking of which, I do worry about all the configuration hassles with the current driver. I would really like to see an option-free makefile. Even the MTRR issue could be dealt with by just locally copying the necessary kernel header so any system could compile it and let it fail at runtime.

What the g400 will give us:

stencil buffer support. This should be straightforward to add and get working.

multitexture support. If glx is extended for it (is there an official ARB spec for multitexture over glx?) we can use it immediately. We could also do the "fake multitexture" hack for the g200 as an option.

Anisotropic texture filtering. We need a new OpenGL enum for this, and I think it would be worthwhile.

More texture filtering levels. Not a big deal until gigantic textures in huge open areas are used more commonly.

"Bump mapping". This, along with some of the other texture combiner modes, would need an extension to expose. I would not call it a high priority. Its not as usefull as it sounds.

Depth buffer in AGP option. AGP 4x transfers. Doesn't help until we get good agp support in the kernel.

It WON'T give us noticably better Q2/Q3 timedemo scores unless multitexture is supported, because at reasonable resolutions we are currently not saturating the G200. You will be able to run at your desktop resolution with all rasterization features turned on, though. The G400 ran away from the field in our last high-res benchmarking.