Articles: Graphics
 

Bookmark and Share

(7) 
Pages: [ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 ]

GeForce 6600 GT: Theoretical Tests

Fill Rate Tests

Traditionally we open up the cycle of theoretical tests with MDolenc Fillrate Tester, a flexible and useful tool for measuring the scene fill rate as well as the efficiency of executing pixel shaders in different color/Z write modes.

Everything is changing dramatically in the course of the first test. The GeForce 6600 GT starts out by being worse than the RADEON 9800 XT at single-texturing and with no textures but finds itself ahead of its rivals at rendering two textures already. The GeForce 6800 GT belongs to another class, of course, and its results are given for the comparison’s sake only. So why is the GeForce 6600 GT so poor in the first two cases, with zero and one texture?

Obviously, the fill rate of the GeForce 6600 is limited by the memory bus bandwidth there. When rendering less than two textures, the GPU processes 8 pixels per clock and refreshes the values in the frame and Z-buffers each clock. When rendering 2, 3 or 4 textures, however, it theoretically requires 2, 3 and 4 clocks, respectively, to output the same 8 pixels, and the burden on the memory bus alleviates.

The RADEON 9800 XT, unlike the GeForce 6600, has a 256-bit memory bus, so its results at rendering a small amount of textures are higher, notwithstanding the lower clock rate and the lower theoretical speed maximum. Its results are simple less limited by the memory bandwidth.

Z-writes disabled, everything remains the same, save for the worse results of the GeForce FX 5950 Ultra with 1, 2 or 3 textures.

This time the performance of the GeForce 6600 GT with disabled color writes is higher than that of the GeForce 6800 GT, despite the difference in the number of their pipelines. It’s hard to account for this fact, as theoretically, the GeForce 6600 GT with support of UltraShadow II technology can perform up to sixteen Z-writes per clock when color writes are disabled.

It is possible that the Z-check and Z-write units of this test don’t work with single pixels, but rather with blocks of them that correspond in size to the tiles that the HSR unit(s) can process. This helps to overcome the theoretical maximum. The GeForce 6600 GT works at a higher clock rate than the GeForce 6800 GT and this allows the new graphics card to be faster despite having fewer pixel pipelines.

Next go the texturing speed tests from 3DMark03:

The results in 3DMark03 confirm the Fillrate Tester’s report: the GeForce 6600 GT is far from the theoretical limit at single-texturing as it is being limited by the memory bandwidth and the efficiency of the frame-buffer and Z-buffer caching algorithms.

As a result, the GeForce 6600 GT is slower than the RADEON 9800 XT which also has eight pixel pipelines, a lower core frequency, but a higher memory bandwidth (256-bit memory bus).

The load on the memory bus decreases dramatically at multi-texturing, as the graphics processor, busy with rendering so many textures and spending more clocks to process pixels, accesses the frame-buffer and the Z-buffer less frequently. As the outcome, we have numbers similar to the theoretical texturing speed of the GeForce 6600 GT.

We would like to note that the 128-bit memory bus and the rather low efficiency at rendering a small number of textures are no catastrophe for the GeForce 6600 GT. This “weakness” can only show up in old games where high speed with few textures is among the main requirements to the graphics card. New games like Far Cry or Doom 3 usually employ much more textures and extensively use pixel shaders. Being engaged into executing pixel shaders, the graphics processor won’t notice that it lacks the memory bandwidth – the bus won’t be a bottleneck anymore. We will check out this supposition in our tests of the GeForce 6600 GT in real gaming applications.

 
Pages: [ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 ]

Discussion

Comments currently: 7
Discussion started: 09/07/04 09:37:30 AM
Latest comment: 10/28/04 11:58:34 PM

View comments

Add your Comment