Matrox Millennium G400 & G400MAX

From the start Matrox had a unique presence in the industry, like ATI and now 3dfx/STB, they were both manufacturers of their own boards as well as their own graphics chips. Following in the age-old Matrox tradition, the G400 will only be featured on Matrox manufactured boards and does offer quite a few significant advantages over its predecessor, the G200.

According to Matrox, the technology behind the G400 is very similar to that of the G200, making driver updates easier to maintain across both technologies. Matrox told AnandTech that they are still committed to releasing a full OpenGL ICD for the G200, and if anything, the similarities between the G400 and G200 architecture will allow this to happen even easier. For those of you that thought Matrox would dump support for the G200 just because they have a new flagship, here's a reason to give Matrox a chance (now if Matrox fails to accomplish this, which is highly doubtful, feel free to let 'em have it).

As with most of the newly released (or announced) graphics accelerators, the Matrox G400 does boast AGP 2X and 4X compatibility. While many companies are being quite ambiguous about whether their products support AGP 4X out of the box, Matrox's G400 will be shipping with both AGP 2X and 4X compliance out of the box. What this means is that a few months down the line, when Intel's 820 chipset (aka Camino) is released, you can pop your G400 in a i820 board and enjoy increased performance due to the G400's ability to take advantage of AGP 4X transfer rates.

One of the most marketable features the G200 carried was its Vibrant Color Quality (VCQ) rendering, interestingly enough, VCQ isn't really a technology at all, rather a system Matrox defined. The G400, naturally, is back with a new "version" of VCQ rightfully entitled Vibrant Color Quality2 (VCQ2). VCQ2 offers the same advantages the original VCQ rendering system offered, which was basically the ability to render all scenes with 32-bit accuracy internally, then dither the final image down to 16 bits of color per pixel. This gave Matrox the best looking 16-bit rendering available at the time, needless to say that the G400 renders all scenes internally with 32-bit accuracy and then dithers them to 16 bits of color per pixel provided that you are set to render in 16-bit color mode.

If you're not running in 16-bit mode, then you have the option of enabling what Matrox likes to call VCQ2. Basically VCQ2 is a combination of a 32-bit color mode, a 32-bit Z-Buffer, and the same 32-bit accuracy performed with all internal calculations. This combination provides for the absolute best possible visual experience available in a game, unfortunately for Matrox, the G400 isn't the only chipset with this capability. The NVIDIA Riva TNT2 is also capable of achieving the same image quality in this case, the only limiting factor here is the design of the board and the RAMDAC which will make the picture look somewhat (albeit barely noticeable) less crisp as that of a G400. Matrox also boasts support for what is known as Stencil Buffering, or the ability to render only the visible part of a scene, a performance booster in ideal cases.

Matrox can't claim that they're 100% unique with the idea behind VCQ2, but since the term is copyrighted, they can always claim that no other company has VCQ2. Bottom line? Don't get fooled by the marketing, you're not getting anything special with VCQ2, NVIDIA has had this for a while now.

What's the performance hit when running in VCQ2? The performance hit when going from 32-bit color to 16-bit color rendering is next to nothing. If you're looking for numbers, the drop is only 6% in Quake2 [demo1.dm2] on a 16MB G400 (not the MAX) at 1024 x 768, which isn't bad at all considering you only have 16MB of frame buffer to work with. The drop plummets to under 3% with the G400MAX on the same Pentium III 500 system at the same resolution, the only difference being the 32MB frame buffer on the MAX. Under Direct3D tests, enabling the 32-bit Z-buffer doesn't seem to hinder performance to any noticeable degree, however the G400's OpenGL ICD does not yet support 32-bit Z-buffering under OpenGL applications, so there is no way to test the performance hit under 32-bit Z happy games such as Quake 3 Arena. According to Matrox's engineers, the performance drop should be negligible, but it's always best to be sure. Matrox assured AnandTech that the OpenGL ICD would eventually support 32-bit Z-buffering, however in its current revision it does not.