Computer graphics processing and selective visual display system – Computer graphics display memory system – For storing compressed data
Reexamination Certificate
2000-06-30
2004-04-20
Tung, Kee M. (Department: 2676)
Computer graphics processing and selective visual display system
Computer graphics display memory system
For storing compressed data
C345S422000, C345S556000, C709S241000
Reexamination Certificate
active
06724391
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates to graphics systems and, in particular, to mechanisms for processing depth or z-data for 3 dimensional (3D) graphics in a manner that is transparent to the user.
2. Background Art
Available computer systems typically include dedicated graphics resources to support the graphics-intensive applications that are prevalent today. Graphics applications, particularly those providing 3D effects, require rapid access to large amounts of graphics data.
A standard method for generating a 3D image begins with sets of primitives that represent the surfaces of each object in the image. Primitives are typically polygons such as triangles or rectangles that may be tiled to form a surface. An object that has a moderately complex shape may require thousands of primitives to represent its surface, and an image that includes multiple objects may require tens or even hundreds of thousands of primitives. Depth, color, texture, illumination and orientation data for each of these primitives must be processed and converted to pixel level data to generate a 3D image on a display device.
Image processing is often implemented through a 3D pipeline that includes a geometry or set-up phase and a rendering or scan-conversion phase. In the geometry phase, the orientation of each primitive and the location of any light sources that illuminate the primitive are determined with respect to a reference coordinate system and specified by vectors associated with the primitive's vertices. This vertex data is then transformed to a viewing or camera coordinate system and rotated to a desired orientation.
In the scan conversion phase, the graphics primitives for each object in an image are converted into a single set of pixel values that provide a 2D representation of the 3D image. The pixels that make up the 2D image are typically stored in the entries of a frame buffer from which the display is generated. A well-known mechanism for populating the frame buffer generates color values for each location of a primitive by interpolating the transformed vertex data for the primitive. Since primitive locations are specified in 3D space, multiple primitive locations may map to the same frame buffer entry (pixel) of the 2D display surface. The generated color value for a primitive location is stored in the frame buffer entry to which it maps or discarded, according to whether or not it is visible in the final image. During this phase, texture data may also be determined for the primitives.
One technique for determining which locations of each primitive are visible in the final image employs a z-buffer. The z-buffer includes an entry for each pixel in the frame buffer. Each z-buffer entry is initialized to zero or other reference value. Often, the reference value represents a back clipping plane of the image. During scan conversion, a z-value is determined for each location within the primitive and compared with the entry in the z-buffer to which the primitive location maps. If the value in the z-buffer is closer to the viewer than the z-value determined for the corresponding primitive location, the primitive location is not visible in the final image, and its color value is discarded. If the value in the z-buffer is further from the viewer than the z-value determined for the corresponding primitive location, the color value for the location is stored in the appropriate entry of the frame buffer. If the color value is not replaced before scan conversion completes, it is displayed in the final image.
Significant amounts of texture, color and z-data are transferred between memory and the graphics resources during the rendering stage. Since there may be tens to hundreds of pixels per primitive, these data transfers can place significant burdens on the bandwidth of the memory channel. The consequent reduction in memory bandwidth can reduce the performance of the graphics system. This is particularly true if the graphic system is implemented in a computer system that employs a unified memory architecture (UMA). For UMA-based computer systems, the central processor unit(s) (CPU) and graphics engine have equal access to main memory. Memory demands by the graphics engine can reduce CPU performance. In addition, memory demands by one unit of the graphics engine can reduce the performance of other units. For example, any bandwidth used to transfer z-data for z-testing is unavailable to the unit that determines pixel textures, and the loss in bandwidth can reduce its performance.
The present invention addresses these and other issues associated with memory bandwidth in graphics systems.
REFERENCES:
patent: 4612612 (1986-09-01), Woffinden et al.
patent: 4654790 (1987-03-01), Woffinden
patent: 4910656 (1990-03-01), Scales, III et al.
patent: 5371849 (1994-12-01), Peaslee et al.
patent: 5428761 (1995-06-01), Herlihy et al.
patent: 5696927 (1997-12-01), MacDonald et al.
patent: 5729669 (1998-03-01), Appleton
patent: 5808618 (1998-09-01), Kawano et al.
patent: 5812150 (1998-09-01), Lum
patent: 5819017 (1998-10-01), Akeley et al.
patent: 5864859 (1999-01-01), Franaszek
patent: 5870095 (1999-02-01), Albaugh et al.
patent: 5875454 (1999-02-01), Craft et al.
patent: 6014728 (2000-01-01), Baror
patent: 6104837 (2000-08-01), Walker
patent: 6188394 (2001-02-01), Morein et al.
patent: 6240419 (2001-05-01), Franaszek
patent: 6253287 (2001-06-01), Green
patent: 6348919 (2002-02-01), Murphy
patent: 6373482 (2002-04-01), Migdel et al.
patent: 6407741 (2002-06-01), Morein et al.
patent: 1 074 945 (2001-02-01), None
patent: PCT/US01/20114 (2001-06-01), None
Tom's Hardware Guide: Graphics Guide—Ati Radeon256 Preview, “Have a home project”, (http://www7.tomshardware.com/graphic/00q2/000425/radeon256-06.html) (May 17, 2000) pp. 1-3.
Tom's Hardware Guide: Graphics Guide—Ati Radeon256 Preview, “Have someone else do your home project”, (http://www7.tomshardware.com/graphic/00q2/000425/radeon256-01.html) (May 17, 2000) pp. 1-3.
Tom's Hardware Guide: Graphics Guide—Ati Radeon256 Preview, “Have someone else do your home project”, (http://www7.tomshardware.com/graphic/00q2/000425/index.html) (May 17, 2000) pp. 1-3.
Orenstein Doron
Peled Guy
Savranski Guiliermo
Sperber Zeev
Blakely , Sokoloff, Taylor & Zafman LLP
Intel Corporation
Tung Kee M.
LandOfFree
Mechanism for implementing Z-compression transparently does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Mechanism for implementing Z-compression transparently, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Mechanism for implementing Z-compression transparently will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3191433