Computer graphics processing and selective visual display system – Computer graphic processing system – Plural graphics processors
Reexamination Certificate
2002-06-18
2004-11-02
Tung, Kee M. (Department: 2676)
Computer graphics processing and selective visual display system
Computer graphic processing system
Plural graphics processors
C345S422000, C345S559000, C345S545000
Reexamination Certificate
active
06812927
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to computer graphics, and more particularly to performing depth clear operations in the context of a computer graphics pipeline.
BACKGROUND OF THE INVENTION
Prior Art
FIG. 1A
is a block diagram of a digital processing system embodying the method and apparatus, in accordance with one embodiment. With reference to Prior Art
FIG. 1A
, a computer graphics system is provided that may be implemented using a computer
100
. The computer
100
includes one or more processors, such as processor
101
, which is connected to a communication bus
102
. The bus
102
can be implemented with one or more integrated circuits, and perform some logic functions; for example, a typical personal computer includes chips known as north bridge and south bridge chips. The computer
100
also includes a main memory
104
. Control logic (software) and data are stored in the main memory
104
which may take the form of random access memory (RAM). The computer also includes a hardware graphics pipeline
106
and a display
108
, i.e. a computer monitor.
The computer
100
may also include a secondary storage
110
. The secondary storage
110
includes, for example, a hard disk drive and/or a removable storage drive, representing a floppy disk drive, a magnetic tape drive, a compact disk drive, etc. The removable storage drive reads from and/or writes to a removable storage unit in a well known manner. Computer programs, or computer control logic algorithms, are stored in the main memory
104
and/or the secondary storage
110
. Such computer programs, when executed, enable the computer
100
to perform various functions. Memory
104
and storage
110
are thus examples of computer-readable media.
In one embodiment, the techniques to be set forth are performed by the hardware graphics pipeline
106
which may take the form of hardware. Such hardware implementation may include a microcontroller or any other type of custom or application specific integrated circuit (ASIC). In yet another embodiment, the method of the present invention may be carried out in part on the processor
101
by way of a computer program stored in the main memory
104
and/or the secondary storage
110
of the computer
100
. One exemplary architecture for the hardware graphics pipeline
106
will be set forth during reference to FIG.
1
B.
Prior Art
FIG. 1B
illustrates a more detailed diagram showing the internal structure of one exemplary embodiment of the hardware graphics pipeline
106
of FIG.
1
A. As shown, a geometry stage
153
is provided which transforms primitives into a screen-aligned coordinate system. Other computations may be performed by the geometry stage
153
such as lighting to determine the visual properties (e.g., color, surface normal, texture coordinates) of each vertex describing the primitives. The transformed vertices form the input for a rasterizer
154
. The rasterizer
154
computes a fragment for each pixel covered by each of the primitives. A coverage mask stored with the fragment indicates which portions of the pixel the fragment covers.
With continuing reference
FIG. 1B
, after optional multi-sampling, individual samples are sent to a raster-processor (ROP)
155
as if they were regular fragments. The raster-processor
155
performs various operations on the fragments, including z/stencil testing and color or alpha blending. This may require the raster-processor
155
to read a frame buffer memory
156
in order to retrieve the destination z-value or the destination color. To this end, the final pixel color and z-value are written back to the frame buffer memory
156
.
When all primitives in the scene have been rendered in this manner, the contents of the frame buffer memory
156
are scanned out by a video refresh unit
157
and sent to the display
108
.
Prior Art
FIG. 1C
illustrates an architecture for performing stencil and z-value functions in the context of the ROP
155
of Prior Art FIG.
1
B. As shown, a stencil value function module
180
and a z-value function module
182
are provided for performing various operations involving stencil values and z-values, respectively.
Associated with the stencil value function module
180
is a stencil state register
184
for storing information relating to pertinent stencil functions, stencil operations, the stencil reference value(s), etc. In use, the stencil value function module
180
is adapted to receive a stencil value from the frame buffer memory
156
and the information from the stencil state register
184
for conditionally enabling a stencil value write to the frame buffer memory
156
.
On the other hand, the z-value function module
182
is capable of receiving a z-value from the frame buffer memory
156
and a z-value associated with a particular pixel from the rasterizer
154
. With these inputs, the z-value function module
182
is adapted to conditionally enable a z-value write to the frame buffer memory
156
. In use, the output of the stencil value function module
180
and the z-value function module
182
may be combined with an AND function
186
for conditionally enabling a depth and color value write to the frame buffer memory
156
.
One operation carried out by the foregoing architecture is “z-value buffering,” whereby the z-values of the pixels are checked to ensure that the nearest object to the viewer is the one which is visible. To do this, each attempt to write to a pixel during rendering is checked against a stored frame buffer depth value in the existing data for that pixel, and the new data is written only if its depth value is less. In addition to these operations, there is a significant performance overhead associated with clearing the z-value buffer to infinity for each new frame. The impact of this operation can be substantial.
There are various techniques of utilizing the foregoing architecture and other various frameworks in order to reduce the number of depth clear operations in the hardware graphics pipeline
106
.
In one prior art system, a depth range of [0,1] is split into two pieces, [0,0.5] and [0.5,1]. First, a frame is rendered into [0,0.5] in the normal fashion, but with the maximum z-value scaled to 0.5 instead of 1.0. Then, the z-value function module
182
is reversed to render into [0.5,1]. This provides the same results (in most cases) as if one had cleared the z-value buffer to a maximum value. While this technique gets rid of all z-value clears and no hardware support is required, 1 bit of z-value precision is lost and it does not work for all applications (i.e. only those that touch every pixel of the z-value buffer every frame).
In a variant to the foregoing system, a depth range of [0,1] is split into N ranges: [0,1/N], [1/N,2/N], . . . , [(N−1)/N,1], and rendered into the farthest range. Every time an application clears the z-value buffer to the maximum value, it moves down one range. A clear operation may be performed when one needs to wrap. While this technique reduces the number of clears by factor of N, works for all applications, and requires no hardware support; it unfortunately loses log
2
(N) bits of z-value precision, which becomes prohibitively large. Further, the present technique does not work exactly right if an EQUAL or NOTEQUAL comparison function is used.
Still yet another prior art solution for reducing depth clears involves tag clears. Such method keeps a buffer on-chip that indicates what pixels in the z-value buffer have been cleared. One can use 1 bit per pixel if desired, but one can also get by with 1 bit per tile (where a tile can be whatever size desired). Having a bit set for a tile would mean, “all z-values in this tile equal 1.0” in a simple implementation. The present technique offers numerous advantages such as the fact that clears are almost free, it works for all applications, it works for color clears in some implementations, there is no loss in z-value precision, and reading the z-value of a cleared pixel
Alben Jonah M.
Cutler Scott P.
NVIDIA Corporation
Tung Kee M.
Zilka Kevin J.
Zilka-Kotab, PC
LandOfFree
System and method for avoiding depth clears using a stencil... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for avoiding depth clears using a stencil..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for avoiding depth clears using a stencil... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3324621