150 MHz core represents the maximum attainable clock speed at which our non MAX G400 will complete all benchmarks. The memory clock of the G400 cannot be adjusted independently of core clock. A core clock of 150 MHz requires a memory clock of 200 MHz. Thus, In order to compare G400 with TNT2 on a clock-per-clock basis, both accelerators were set at 150 MHz core and 200 MHz memory. The test rig is a Celeron clocked at 450 MHz. Quake3 Test and Expendable are the two benchmarks used.

Instead of showing framerates, performance figures are denoted in millions of pixels rendered onscreen per second (i.e. fillrate). The so-called fillrate is derived thus: framerate x resolution. ("Fillrate" is used loosely as it is not quite the same as the actual accelerator fillrate, which is a few times higher if depth complexity and multi-pass rendering are taken into consideration.) Graphs are plotted with fillrate as the Y-axis and screen resolution as the X-axis. Screen resolution is denoted by the number of onscreen pixels. For example, 640x480 resolution equals 307,200 onscreen pixels.

Z buffer is a buffer allocated in the frame buffer that is used to specify a "distance" or "depth" value from the camera view point (or front clipping plane). Early drivers for G400 had problems with 32-bit Z buffer support. This has since been rectified, but it seems unusual that 32-bit Z buffer is not enabled by default.

The MATROX G400 supports 16-bit Z, 24-Z (plus 8-bit stencil) and 32-bit Z. Like S3's Savage4 and ATI's Rage128, it is flexible enough to allow the application to independently choose between different color depths and Z buffer depths. For example, Unreal will use 32-bit Z even at 16-bit color depth. Unfortunately, TNT2 locks the Z buffer depth to the same value as the color depth. In this case, Unreal will fall back to 16-bit Z when the color depth chosen is 16-bit. Expendable uses 16-bit Z regardless of color depth. Then there is 'Quake3 Test ver 1.06' which also locks Z buffer depth to the color depth.