NVIDIA Quadro DDR

by Gary Jones on January 25, 2000 11:44 AM EST

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. 

 

CPU Utilization Final Words
Comments Locked

0 Comments

View All Comments

Log in

Don't have an account? Sign up now