Image Quality
Some readers and 3Dlabs have raised the issue of the image quality of the NVIDIA NV10 chips. ViewPerf ProCDRS-02 does screen captures during each of the 10 sub tests; one of these is a full screen and the other is just a small portion that is used for quality checking. The screen captures are stored in a lossless *.pgn format. The full screen captures for sub test #4 (smooth shaded) were reviewed using Paint Shop Pro Ver. 6 for flaws.
In all cases excepting the TNT2U, the full image captures had many slight mostly one pixel flaws! In general the GVX1 and VX1 had somewhat fewer flaws than the Quadro DDR, the ELSA GLoria II Quadro SDR and the GeForce SDR. The TNT2U image had several multiple pixel flaws and was clearly the worst performer on this test.
On all the images lots of pixel flaws were observed around the truck's door handle as shown in the table below:
Quadro DDR - 3.65 Driver |
ELSA GLoria II - ELSA Driver |
GeForce 256 SDR - 3.65 Driver |
TNT2U - 3.65 Driver |
3Dlabs GVX1 |
3Dlabs VX1 |
Notice that the observed flaws are the same for the Quadro and GeForce cards even though different drivers were used. The two 3Dlabs cards give similar results even though one uses an on card GPU and the other used the Pentium III SSE instructions to do the T&L.
What causes these problems? A reasonable guess would be that some of these problems are due to the lack of enough numeric precision in the T&L pipeline. Computer math is not precise, for engineering computations the IEEE 64 bit FP format is normally used and it has about 15 places of accuracy. The IEEE 32 bit FP format with about 7 places of precision is typically used in software based graphics processing. The two Quadro's and the GVX1 use on card GPU's with unspecified precision but almost certainly less that the IEEE 32 bit floating point format. The VX1 uses the Intel Pentium III SSE instructions which according to Intel sacrifices precision for speed:
"We decided to offer two modes of FP arithmetic: IEEE compliance for applications that need exact single-precision computation and a Flush-To-Zero (FTZ) mode for real-time applications. Full IEEE support ensures greater future applicability of the extensions for applications that require full precision and portability, while FTZ mode along with fast hardware support for masked exceptions enables high-performance execution. FTZ mode returns a zero result in an underflow situation during computation if the exceptions are masked. Most real-time 3D applications would use the FTZ mode since they are not sensitive to a slight loss in precision, especially if they can get faster execution by using the FTZ mode."
"A basic building block operation in geometry involves computing divisions and square roots. For instance, transformation often involves dividing each x, y, z coordinate by the W perspective coordinate. Similarly, specular lighting contains a power function, which is often emulated using an approximation function that requires a division. Also, normalization is another common geometry operation, which requires the computation of 1/square-root. In order to optimize these cases, the new extensions introduce two approximation instructions: RCP and RSQRT. These instructions are implemented via hardware lookup tables and are inherently less precise (12 bits of mantissa) than the full IEEE-compliant DIV and SQRT (24 bits of mantissa). However, these instructions have the advantage of being much faster than the full precision versions."
The marketplace currently
rewards those vendors that get the high frame rates ( on Quake, Pro/E, etc.
) and does
not put much premium on rendering quality; until that fact changes, it is
doubtful if the quality of the rendering will improve.
0 Comments
View All Comments