Design Feature: March 14, 1996

Like martial-arts dojos preparing for a meet, graphics chip and board makers are grooming their champions. At stake: a share in the demand for 3-D graphics accelerators, a market that vendors expect the gaming community to generate. Each vendor is trying to equip its champion with the optimum mixture of performance, features, and cost. The boon for designers is the wide availability of low-cost, 3-D graphics products with capabilities formerly available only in workstations. The risk is that the rules of the game aren't yet established.

The goal of 3-D graphics acceleration is to allow computers to quickly render 2-D images from descriptions of 3-D objects. That rendering must be fast enough to allow both objects and the user's apparent viewpoint to move at real-time speeds. The more objects comprising the scene and more realistic the resulting image, the better.

As with graphical-user-interface (GUI) and video acceleration in earlier graphics-device generations, vendors expect that 3-D acceleration will become a standard part of PC graphics during the next year. The drive to attain pervasive 3-D comes from the games community. Game developers find that gamers prefer interactive images that convey depth, perspective, and realism, over flat-looking animation. Providing real-time, interactive, 3-D graphics of even modest scene complexity is beyond the capability of 486-based PCs, however, and it bogs down Pentium-class machines. Acceleration becomes necessary to achieve the speed and image quality gamers expect.

Picture 1

For engineers and professional-level PC users, pervasive 3-D becomes an opportunity to attain workstationlike graphics performance on PCs for a few hundred dollars. The performance gains increase the utility of CAD and other design programs. The gains also open opportunities for 3-D enhanced user interfaces, such as the Internet's virtual-reality markup language (VRML). VRML allows users to develop Internet Web sites that let visitors navigate through a virtual world, rather than use a 2-D map to view and gather information. The interface, like games software, depends on the user's computer to generate the 3-D display from object descriptions.

3-D APIs are consolidating

While 3-D graphics have been an element of games and software in the past, such graphics have been limited to either static images or low-resolution, 3-D animation. Attaining high-resolution animation required porting of the software to specific 3-D acceleration hardware, limiting the available market. During the past year, however, the profusion of proprietary application- programming interfaces (APIs) for 3-D acceleration has consolidated into a few key interfaces. These include OpenGL, Microsoft's (Redmond, WA) Direct3D, and Apple Computer's (Cupertino, CA) QuickDraw3D.

With a limited number of interfaces that need porting to, game developers can economically develop games that use high-performance 3-D graphics. The availability of games with compelling graphics, in turn, will stimulate a market demand for 3-D acceleration. At least, that's what chip and board developers are hoping. The result is that 3-D accelerator chips and boards are appearing in droves (Table 1), with more on the way.

Capturing 3-D graphics acceleration in hardware at a gamer's cost point isn't easy, and vendors have had to make trade-offs between features and performance. There is little agreement on the optimum feature set, however, and reliable benchmarks for 3-D graphics are limited to OpenGL-based devices. As a result, designers must carefully evaluate the alternatives before choosing from this first generation of 3-D graphics accelerators.

The first step in evaluating the various available accelerators is to understand which operations within 3-D graphics generation the device is accelerating. Figure 1 shows the operations involved in producing a 3-D graphics display, known in the industry as the 3-D graphics pipeline. A database, which holds object descriptions and locations, feeds the pipeline. Objects typically comprise a collection of connected triangles. The database describes the objects as sets of coordinates (X,Y,Z) for the triangles' vertices. In addition, the database provides color and other information for each vertex.

The geometry stage is the first part of the 3-D pipeline. This stage handles the analytic geometry used to project the scene's 3-D objects onto the display screen's 2-D surface for a given viewpoint. This projection involves calculating the (X,Y) screen position of each triangle vertex using floating-point matrix operations. The calculation also retains the Z, or depth, information for later use in hidden-surface elimination. In addition, the geometry stage calculates a lighting factor for the triangle, based on the triangle's orientation relative to a light source. If the rendering stage that follows is to perform more than flat shading, the geometry section also calculates the starting point and rate of change (deltas) needed for interpolation.

Figure 1

The rendering stage takes the projected vertex data from the geometry section and uses it to render a solid triangle. In this stage, many options allow you to fill in the triangle given only the vertices. The simplest method is to make every pixel in the triangle the same color. This results in flat shading (Figure 2a), which produces an unnatural, artificial look.

A second method of filling the triangle, Gouraud shading, produces a more smooth, natural effect (Figure 2b). Gouraud shading takes the color- and lighting-correction factor for each vertex and then interpolates colors between the vertices to fill the triangle. A third method, Phong shading, calculates the lighting effect at each pixel, producing both smooth shading and shiny highlights.

The rendering stage may also employ antialiasing at triangle edges to smooth the stair-step effect created when drawing a diagonal line with rectangular pixels. The antialiasing calculations blend the colors of triangle edge pixels with the color of adjacent background pixels. The blending depends on what fraction of the pixel each color would occupy if the grid were finer. In effect, this step breaks each pixel into subpixels, draws the line, and then counts the number of subpixels in each color to determine the blending coefficient.

In addition to color shading, the rendering stage may employ texture mapping to fill triangles. Texture mapping projects a 2-D bitmap, or texture, onto the polygon, rather like covering the polygon with wallpaper. Texture mapping allows the rendered scene to contain fine detail without the need for additional polygons. A drawing of a brick wall, for example, would require dozens of shaded rectangles. A single rectangle with a texture-mapped brick pattern can produce the same effect. Texture mapping also allows use of irregular patterns, such as wood grains, to color polygons. A drawn wood grain would require thousands of shaded polygons.

The basic algorithm for texture mapping, like Gouraud shading, uses interpolation between vertices. Instead of directly calculating pixel values, however, texture-mapping interpolation uses addresses. Each vertex has an associated address within the texture map. The interpolation algorithm starts with these addresses and then finds the address of the appropriate texture-pixel, or "texel," for each point in the triangle. The texel value thus located becomes the pixel value for that point in the triangle.

Texture mapping also differs from shading by providing perspective correction. With shading, the color's rate of change (delta) is constant along each triangle edge. If this linear interpolation were applied to texture mapping, however, the textures would appear distorted (Figure 3). Instead, perspective-corrected texture mapping alters the deltas based on the Z-value for each pixel, increasing the rate of change for pixels that are farther away. The result is that patterns compress with distance.

Several methods for texture mapping exist. The simplest is point mapping. A point-mapped texture map uses the nearest texel to the interpolated address. Such point mapping makes nearby objects look blocky. It also has the effect of subsampling the texture pattern for distant objects, which produces aliasing effects. These aliasing effects can appear as missing lines or moire patterns, depending on the texture's regularity and fine detail. When the rendered objects or viewpoints are moving, the aliasing effects can also appear as flicker in the displayed image.

The rendering stage can reduce these artifacts by filtering the texels before drawing them. A bilinear filter reads the four texels nearest the calculated address and averages them, weighting each by its distance from the calculated address. This filter requires four times the bandwidth to the texture map that point mapping needs, however, because each rendered pixel needs four texel values. This method also blurs textures on distant objects, losing detail.

The use of prefiltered textures can retain detail and avoid aliasing while reading only one texel per pixel. This method, called MIP mapping, stores several versions of the texture pattern for use at varying distances. The rendering stage selects the texture version appropriate to the triangle's depth before mapping. This method has the drawback of requiring additional texture memory to hold the many versions of each texture. In addition, the image can still exhibit flickering during movement as the polygons switch from one MIP map to the next.

Combinations of these filtering methods also exist. A bilinear MIP map first chooses the appropriate map and then performs a bilinear interpolation within that map. A trilinear MIP map, one of the most advanced techniques available, uses four texels from each of two maps. It performs a bilinear filter on each map, then interpolates between the maps to produce the final pixel value. This method places severe demands on both memory and bandwidth, requiring multiple texture maps and eight texel reads per pixel.

The rasterization stage prepares the rendered triangles for display. This stage uses one of several approaches to ensure that objects in the foreground conceal objects in the background when drawn. One method is to presort the pixels before sending them to the frame buffer. By sorting pixels from back to front, the rasterization stage automatically draws background objects first and then covers them with foreground objects. The drawback is that the stage wastes time writing repeatedly into the areas of the frame buffer that contain overlapping objects. Sorting pixels front to back can avoid this overwrite by allowing the stage to write only the foremost pixel to the buffer. Front-to-back sorting, however, complicates the implementation of visual effects, such as fogging or alphablending (object transparency).

To avoid sorting of pixels, the rasterization stage can employ a Z-buffer. The Z-buffer is a memory array that holds the Z-value, or depth, of each pixel written to the frame buffer. Before writing to the frame buffer, the stage compares the current pixel Z-value to the one already in the buffer. The stage writes the current pixel into the frame buffer only if the pixel is closer to the viewer than is the existing entry. If alphablending is to occur, the stage would merge the two values.

Picture 2

One drawback to the use of a Z-buffer is the need for a large memory array, as many as 32 bits per display pixel, to hold the Z data. There is also considerable data traffic, because each pixel in every object requires a read-compare-write cycle for the Z-buffer, as well as to the frame buffer. In addition, the Z-buffer must be preset to infinite depth before each frame gets rendered.

These three stages of the 3-D pipeline are common to all 3-D graphics applications, although vendors may use different terms. The variations among 3-D graphics-accelerator devices occur in the choice of which steps get hardware assistance and which methods get employed. Most chip and board vendors agree that the minimum feature set gamers will accept includes Gouraud shading with perspective-corrected texture mapping. Features such as alphablending, bilinear filtering, and Z-buffering are more open to debate.

When offering hardware acceleration, most graphics-accelerator chips and boards focus on the rendering and rasterization stages. The geometry stage uses numerous floating-point calculations to project each triangle, making this stage expensive to implement in hardware. In addition, projection details, such as the viewing angle, and lighting details, such as the number of light sources, are application-specific.

There are a few devices, however, that provide hardware assistance with the geometry stage. One such device is S-MOS Systems' SPC1500 graphics-geometry processor. Designed for high-end applications, the device handles the transformation of coordinates, lighting, delta calculation, and perspective correction in a programmable, pipelined processor. It works in conjunction with the acceleration hardware for rendering in OpenGL applications. The company is actively developing drivers for other APIs.

Another device with geometry-stage acceleration is the Delta chip from 3Dlabs. This device doesn't accelerate the entire geometry stage, however. It provides only the delta and setup calculations for the shading and texture-mapping interpolation engines of the rendering stage. Those calculations, the company estimates, account for 70% of the total effort within the geometry stage. The chip works with both the high-end Glint 500PX and the lower-cost Permedia chips from 3Dlabs.

Most of the remaining 3-D graphics-accelerator chips depend upon the CPU to handle geometry calculations, with the expectation that the CPU is a Pentium. This expectation stems partly from the industry's belief that Pentium-based PCs are now the entry-level machines and will soon dominate the installed base. The other source of the expectation is more pragmatic: Other x86 CPUs have insufficient performance to handle the graphics calculations for 30-frame/sec, full-screen 3-D rendering.

Given the dependence on the CPU for geometry calculations, evaluating 3-D graphics accelerators becomes a major challenge. Vendors typically quote processing speeds in terms of the numbers of triangles the accelerators handle, with performance numbers usually exceeding 300,000 triangles/ sec. Tests on the Pentium, however, show that it can handle geometry calculations at a rate of 1000 triangles/ MHz of clock speed. Thus, a 100-MHz Pentium is a bottleneck in the 3-D graphics pipeline, providing only 100,000 triangles/sec to the graphics accelerator.

With the bottleneck preventing direct comparison of accelerators, designers are left with only the spec sheets for comparison. Here, too, lie difficulties. A triangles/second performance rating is meaningless without additional information. Triangle size affects the rating; smaller triangles are easier to render. Display resolution also affects the rating. Disjointed triangles require more time to render than connected triangles, because the accelerator can reuse vertex calculations where triangles touch. The invocation of features such as perspective correction, Gouraud shading, and texture mapping with bilinear filtering all slow performance.

To adequately compare accelerator performance specifications, then, the ratings should all be based on the same feature set, display resolution, triangle size, and degree of triangle independence. Or, use an alternative rating scheme, such as the number of pixels per second the device can render. Unfortunately, there is little commonality among vendor's specifications and no benchmarks for APIs, other than OpenGL. The best designers can do for now is to run their own benchmark tests based on their applications' needs. Even then, the geometry bottleneck may render test results moot.

Regardless of how they settle the performance issue, designers need also to look at other graphics-accelerator characteristics. Important characteristics include the feature set, the memory architecture, and the supported APIs. For these first-generation 3-D graphics accelerators, such characteristics may be more important than performance numbers.

When evaluating the feature sets, designers need to look not only at the features supported, but also at which features work together. The candidate device may offer Gouraud shading, bilinear MIP mapping, and a 1280×1024-pixel resolution but not necessarily at the same time. Designers of PC-based systems also need to keep in mind the systems' 2-D graphical needs. Some 3-D accelerators work as adjuncts to conventional GUI-accelerated SVGA graphics boards. Some incorporate standard 2-D graphics capabilities with the 3-D. The S3 ViRGE adds video capability; the NVIDIA NV1 adds audio and video. The Chromatic Research Mpact includes all PC 2- and 3-D graphics, audio, video, MPEG, fax/modem, and videoconferencing functions in one chip set. Designers need to evaluate the performance of each function in such combination chip sets to ensure that incorporating 3-D acceleration doesn't compromise other system tasks.

Picture 3

The size and type of memory the graphics-accelerator chip set needs is another characteristic for designers to consider. The NVIDIA NV1 uses video RAM; the SGS-Thomson STG2000 is the same core but with a DRAM interface. Other accelerator chip sets may use extended data-out DRAM, synchronous DRAM, or synchronous graphics RAM. The cost and availability of memory may thus be critical design factors in accelerator choice.

On top of all the hardware considerations, designers must bear in mind the application software. A year ago, there were nearly as many 3-D APIs as there were applications. Software developers are now focusing on a few APIs, and the list may narrow further during 1997. Important APIs include OpenGL, Apple Computer's QuickDraw3D, Creative Labs' CGL, and Autodesk's (Sausalito, CA) Heidi, as well as Microsoft's Direct3D for Windows 95. Not every accelerator supports every API. Many devices targeted at the games market, for example, focus only on accelerating Direct3D. Unfortunately, Direct3D has suffered delays in its introduction and may not become widely available in time for some projects.

Thus, this early generation of 3-D graphics accelerators carries certain risks for early adopters. Inconsistency in specifications and a relative lack of benchmarks make evaluation difficult. Chip and board developers are anticipating a large market based on gaming demands. If that market fails to develop, vendors may discontinue their products. Vendors are guessing at the optimum mix of features. As the market matures, vendors may drop some features in later accelerator generations, blocking upward compatibility of early designs. Finally, the winnowing of APIs continues, leaving open the possibility that software support may vanish. Designers need to consider carefully their choice in 3-D graphics accelerators to avoid the knockout punch of market changes. They also need to be prepared to reconsider their bets when the next generation of champions enters the ring.

You can reach Technical Editor Richard A Quinnell at (719) 530-0560, fax (719) 530-0560. E-mail:ednquinnell@mcimail.com