FireGL2's GT1000 Geometry Chip
The GT1000 chip is responsible for the T&L part of the OpenGL pipeline. It runs at 190 MHz and is thus clocked higher than the RC1000-chip. On the Quadro2 Pro both rasterizer and T&L unit are integrated on one chip. Both engines run at 250 MHz on the NVIDIA product. According to Diamond, the geometry engine manages 35 Gflops/sec. This translates into a polygon rate of 27 Mpolys/sec. On paper, the NVIDIA chip seems to have the upper hand here as well, considering it is rated at 31 Mpolys/s. While the Quadro2 Pro shows certain remnants of 3D-game optimizing, Diamond claims to have inserted a "100% OpenGL Geometry Pipeline" into their GT1000.
Feature Overview:
- Full Geometry Transform Processing
- Hardware Calculation of up to 16 light sources (more sources through software calculation)
- Calculating Texture Coordinates and Fog
- Multi Texturing Support
- Hardware Clipping
- Immediate Mode Rendering
- 190 MHz Clock
Who's Right? Customer Wishes Perceived
The FireGL2 doesn't care much for Windows 98 or ME. You will search in vain for drivers that would support the two 'toy-OSes'. This is due to the market position of the card as a pure OpenGL workstation product. Diamond drivers are currently restricted to Windows NT 4.0, Windows 2000 and UNIX - the OSes most widely used for workstations. From the beginning, Diamond offers driver optimizations for the most important command set extensions of current CPUs. 3DNow! is implemented for AMD Athlon, and for Pentium III and 4 we have SSE and SSE2 support respectively.
A look at the FireGL2 specs is disappointing at first, as fill rates are rather low compared to those of the Quadro2 Pro. Still, there's quite a competitive polygon rate. We interviewed several different companies that use professional OpenGL applications on a daily basis. During talks, we noticed a certain trend: While working on a graphics project, rendering of large textures is much less important than in 3D games, where it has become most essential. However, the modeling of objects requires very high polygon rates. As long as objects and scenes are still "under construction", most designers are handling them as wire frame models. Even looking at single views or scenes is done with simple shading models during production phase. Only at the final stage of a project the designer requires some kind of high rendering performance and thus fill rate. It shows that the user profile of a construction designer is completely different from that of a 3D-gamer. This explains why Diamond put little effort into the rasterizer. But even lay(wo)men can appreciate the connection between a wire frame model and the modeling process. Many of you might have seen Spielberg's dinosaur-movies. In "The Making of" you get a look behind the scenes and developers explain how the dinosaur-models were developed. You can spot it right away that the animations were exclusively done using wire frame models. Way towards the end after the scene sequence has been determined, finally the wire frame dinosaurs are 'dressed up' with complex textures and included into the movie.
Whether Diamonds philosophy paid off or not can be seen from the benchmarks in the next section.
