Apparatus and method of an improved stencil shadow volume operation

The computer graphics system is configured to improve the performance of a stencil shadow volume method for rendering shadows. The apparatus and methods utilize a combination of compressed and uncompressed stencil buffers in coordination with compressed and uncompressed depth data buffers. An uncompressed stencil buffer is capable of storing stencil shadow volume data for each pixel and a compressed stencil buffer is capable of storing stencil shadow volume data for a group of pixels. The compressed stencil buffer is utilized with a compressed stencil buffer cache to perform a stencil shadow volume operation more efficiently than present methods.

FIELD OF THE INVENTION

The present invention generally relates to computer graphics systems, and more particularly to a method and apparatus for generating a shadow effect using a shadow volumes approach.

BACKGROUND

As is known, the art and science of three-dimensional (“3-D”) computer graphics concerns the generation, or rendering, of two-dimensional (“2-D”) images of 3-D objects for display or presentation onto a display device or monitor, such as a Cathode Ray Tube (CRT) or a Liquid Crystal Display (LCD). The object may be a simple geometry primitive such as a point, a line segment, a triangle, or a polygon. More complex objects can be rendered onto a display device by representing the objects with a series of connected planar polygons, such as, for example, by representing the objects as a series of connected planar triangles. All geometry primitives may eventually be described in terms of one vertex or a set of vertices, for example, coordinate (x, y, z) that defines a point, for example, the endpoint of a line segment, or a corner of a polygon.

To generate a data set for display as a 2-D projection representative of a 3-D primitive onto a computer monitor or other display device, the vertices of the primitive are processed through a series of operations, or processing stages in a graphics-rendering pipeline. A generic pipeline is merely a series of cascading processing units, or stages, wherein the output from a prior stage serves as the input for a subsequent stage. In the context of a graphics processor, these stages include, for example, per vertex operations, primitive assembly operations, pixel operations, texture assembly operations, rasterization operations, and fragment operations.

In a typical graphics display system, an image database (e.g., a command list) may store a description of the objects in the scene. The objects are described with a number of small polygons, which cover the surface of the object in the same manner that a number of small tiles can cover a wall or other surface. Each polygon is described as a list of vertex coordinates (X, Y, Z in “Model” coordinates) and some specification of material surface properties (i.e., color, texture, shininess, etc.), as well as possibly the normal vectors to the surface at each vertex. For three-dimensional objects with complex curved surfaces, the polygons in general must be triangles or quadrilaterals, and the latter can always be decomposed into pairs of triangles.

A transformation engine transforms the object coordinates in response to the angle of viewing selected by a user from user input. In addition, the user may specify the field of view, the size of the image to be produced, and the back end of the viewing volume so as to include or eliminate background as desired.

Once this viewing area has been selected, clipping logic eliminates the polygons, (i.e., triangles) which are outside the viewing area and “clips” the polygons, which are partly inside and partly outside the viewing area. These clipped polygons will correspond to the portion of the polygon inside the viewing area with new edge(s) corresponding to the edge(s) of the viewing area. The polygon vertices are then transmitted to the next stage in coordinates corresponding to the viewing screen (in X, Y coordinates) with an associated depth for each vertex (the Z coordinate). In a typical system, the lighting model is next applied taking into account the light sources. The polygons with their color values are then transmitted to a rasterizer.

For each polygon, the rasterizer determines which pixel positions the polygon and attempts to write the associated color values and depth (Z value) into frame buffer cover. The rasterizer compares the depth values (Z) for the polygon being processed with the depth value of a pixel, which may already be written into the frame buffer. If the depth value of the new polygon pixel is smaller, indicating that it is in front of the polygon already written into the frame buffer, then its value will replace the value in the frame buffer because the new polygon will obscure the polygon previously processed and written into the frame buffer. This process is repeated until all of the polygons have been rasterized. At that point, a video controller displays the contents of a frame buffer on a display a scan line at a time in raster order.

With this general background provided, reference is now made toFIG. 1, which shows a functional flow diagram of certain components within a graphics pipeline in a computer graphics system. It will be appreciated that components within graphics pipelines may vary from system to system, and may also be illustrated in a variety of ways. As is known, a host computer10(or a graphics API running on a host computer) may generate a command list12, which comprises a series of graphics commands and data for rendering an “environment” on a graphics display. Components within the graphics pipeline may operate on the data and commands within the command list12to render a screen in a graphics display.

In this regard, a parser14may retrieve data from the command list12and “parse” through the data to interpret commands and pass data defining graphics primitives along (or into) the graphics pipeline. In this regard, graphics primitives may be defined by location data (e.g., x, y, z, and w coordinates) as well as lighting and texture information. All of this information, for each primitive, may be retrieved by the parser14from the command list12, and passed to a vertex shader16. As is known, the vertex shader16may perform various transformations on the graphics data received from the command list. In this regard, the data may be transformed from World coordinates into Model View coordinates, into Projection coordinates, and ultimately into Screen coordinates. The functional processing performed by the vertex shader16is known and need not be described further herein. Thereafter, the graphics data may be passed onto rasterizer18, which operates as summarized above.

Thereafter, a z-test20is performed on each pixel within the primitive being operated upon. As is known, comparing a current z-value (i.e., a z-value for a given pixel of the current primitive) in comparison with a stored z-value for the corresponding pixel location performs this z-test. The stored z-value provides the depth value for a previously rendered primitive for a given pixel location. If the current z-value indicates a depth that is closer to the viewer's eye than the stored z-value, then the current z-value will replace the stored z-value and the current graphic information (i.e., color) will replace the color information in the corresponding frame buffer pixel location (as determined by the pixel shader22). If the current z-value is not closer to the current viewpoint than the stored z-value, then neither the frame buffer nor z-buffer contents need to be replaced, as a previously rendered pixel will be deemed to be in front of the current pixel.

Again, for pixels within primitives that are rendered and determined to be closer to the viewpoint than previously-stored pixels, information relating to the primitive is passed on to the pixel shader22which determines color information for each of the pixels within the primitive that are determined to be closer to the current viewpoint. Color information includes whether or not pixels are within a shadow. As known in the prior art, one method for determining shadowed regions in a scene is through the use of shadow volumes.

Reference is now made toFIG. 2, which illustrates the shadow volume approach of generating a shadow effect in a computer graphics system. The shadow volume34, as is known, defines the space in the shadow of a particular occluder32for a particular light source30. Each polygon facing a light source30is an occluder32and therefore generates a shadow volume34. A pixel38that falls within a shadow volume is rendered as being located in a shadow. The shadow volume method determines whether a pixel38,39falls within a shadow volume34by counting the number times the ray35between the pixel38,39and the viewer36enter33and exit37shadow volumes34. If the number of times a ray enters33shadow volumes34is the same as the number of times the ray exits37shadow volumes34then the pixel38,39is not in a shadow. For example, the ray35from the viewer36to pixel A38has one entry33into the shadow volume34and no exits37from the shadow volume34. Thus, pixel A38is in a shadow. Similarly, since the ray31from the viewer36to pixel B39enters33the shadow volume34one time and exits37the shadow volume34one time, pixel B39is not in a shadow.

Since the ray tracing technique is very time consuming, especially with multiple occluders and multiple light sources, the stencil shadow volume method simplifies the operation by performing a simple in/out counting method using a stencil buffer, sometimes referred to as a stencil buffer level2or SL2. The stencil buffer, SL2, stores and processes data for each pixel to perform a variety of functions including the stencil shadow volume method. Whether the pixel is in the shadow is determined by performing a z-test on the front-facing and back-facing polygons of shadow volumes relative to either the viewer or a maximum depth plane. For example, in one implementation of the stencil shadow volume approach, the stencil buffer value would be incremented if the front-facing polygon passes the z-test and the stencil buffer value would be decremented if the back-facing polygon passes the z-test. Thus, if the final stencil value is zero, the pixel is not in a shadow.

Referring now toFIG. 3, the stencil shadow volume method begins by clearing the stencil buffer40and rendering the scene with diffuse colors42. This rendering provides data for the color buffer and the depth buffer43, also referred to as the z-buffer. The z-buffer and color buffer updates are turned off44except for the stencil value that may reside in the z-buffer. For each light, the shadow volume is generated for each occluder and the front-facing polygons of the shadow volume are rendered46. The stencil buffer value is incremented47for each pixel on which a front-facing polygon is drawn. The same operation is performed with the back-facing polygons48, except the stencil buffer value is decremented49for each pixel on which a back-facing polygon is drawn. The pass where the stencil value is incremented and decremented is referred to as the stencil shadow volume pass. Objects in the shadow will be those having a non-zero stencil value50and are rendered accordingly. Objects not in the shadow will have a stencil value50of zero and are rendered with specular color52. The pass where the pixels outside a shadow are rendered with specular color is referred to as the specular color pass. Referring back toFIG. 1, once color information is computed by the pixel shader22, the information is stored within the frame buffer24.

Referring back toFIG. 2, for example, the stencil buffer value for pixel A38is incremented one time for the front-facing shadow volume polygon that would be rendered at the entry33and not decremented because there are no back-facing shadow volume polygons for pixel A38. The non-zero value remaining in the stencil buffer for pixel A38indicates that pixel A38is in a shadow. Similarly, the stencil buffer value for pixel B39is incremented one time for the front-facing shadow volume polygon that would be rendered at the entry33and decremented one time for the back-facing shadow volume polygon that would be rendered at the exit37. Since the stencil buffer value is zero, pixel B39is not in a shadow and would be rendered with specular color. Although the example inFIG. 2has a single occluder and a single light source, the stencil shadow volume approach works for multiple shadows created by multiple occluders and multiple light sources.

Reference is now made toFIG. 4, which illustrates a common implementation of a compressed z-data processing unit, sometimes referred to as ZL1. As is known, system performance is improved through the use of ZL1, which processes the z-data for a block or tile of multiple pixels. For pixels within a tile in which the z-data exceeds the range of the compression format associated with ZL1, the z-data must be processed at the pixel level in a pixel z-data processing unit, sometimes referred to as ZL2.

The ZL1and ZL2terminology generally stand for Z Buffer Level1and Z Buffer Level2. There are several names for this type of algorithm including Hyper Z and Heirarchy Z Buffer. The two levels of Z Buffers allow the storage of higher level depth information for a larger processing unit, such as a tile, and the storage of depth information for the smallest granularity, such as an individual pixel in a screen. One advantage of ZL1is to reduce the computing complexity of depth data in the rendering pipeline.

A tile generator60generates tile data for the tile of pixels, eight-by-eight for example, and sends a request to a cache64, called the ZL1cache. The tile data is sent to ZL162, which in turn communicates with the ZL1cache64. For the pixels having z-data that cannot be processed in ZL162, the z-data is processed in the pixel z-data processing unit66, ZL2, in coordination with a ZL2cache68. In this configuration ZL162can reject up to sixty-four pixels in one cycle and the non-rejected pixels are marked as accepted or retested to reduce the ZL266memory traffic.

Although ZL162reduces the memory read traffic for ZL266, the current solution cannot perform the stencil operation very efficiently. In this configuration, when the stencil operation is performed, ZL162just marks all pixels as retest to ensure that the stencil operation will not leak. The rejected pixels will also have a stencil operation requiring access to ZL266. Thus during the stencil operation, ZL162will be essentially by-passed resulting in significant memory traffic.

This is especially true when a ZL1tile (subtile) is accepted or rejected after a z-compare function. Since the stencil operation will happen even if the subtile passes the z-test, ZL162has to change the subtile from the ACCEPT state to the RETEST state and pass it down to ZL266. Currently ZL266, and the stencil buffer, SL2, may be combined such that the format of the ZL2/SL2processing unit is thirty-two bits having a twenty-four-bit z-value and eight bits of stencil value. In the ACCEPT/REJECT states, the entire thirty-two-bit z/stencil value has to be read just to use the eight bit stencil value. This results in significant inefficiencies in terms of memory bandwidth. Although one solution would be to use separated stencil buffer and z-buffer, this scheme would result in a very small memory request. For example, for eight pixels, the memory request for an eight-bit stencil value would only be sixty-four bits, resulting in a great waste of memory traffic.

Although the foregoing has only briefly summarized the operation of the various processing components and techniques for generating shadows, persons skilled in the art recognize that processing the graphics data is quite intense. Consequently, it is desired to improve processing efficiency wherever possible.

SUMMARY

Certain objects, advantages and novel features of the disclosure will be set forth in part in the description that follows and in part will become apparent to those skilled in the art upon examination of the following or may be learned with the practice of the disclosure. The objects and advantages of the invention may be realized and obtained by means of the instrumentalities and combinations particularly pointed out in the appended claims.

One embodiment of the present disclosure is directed to an apparatus configured to improve a stencil shadow volume operation, the apparatus for use in a computer graphics system comprising a compressed stencil buffer, where the compressed stencil buffer comprises compressed stencil shadow volume data record for a group of pixels.

Another embodiment of the present disclosure is directed to a system comprising a graphics processing unit configured to generate a shadow effect using a stencil shadow volume operation on a group of pixels. As is known to one skilled in the art, a group of pixels may comprise a single tile, a subtile, or more than a tile. The system further comprises a first stencil buffer and a first stencil buffer cache configured to communicate with the first stencil buffer.

Other embodiments of the present disclosure are directed to methods for implementing a stencil shadow volume method in a computer graphics system. In this regard, one embodiment of such a method, among others, performs the stencil shadow volume method using a tile stencil buffer in conjunction with a pixel stencil buffer.

DETAILED DESCRIPTION

Having summarized various aspects of the present disclosure, reference will now be made in detail to the description of the disclosure as illustrated in the drawings. While the disclosure will be described in connection with these drawings, there is no intent to limit it to the embodiment or embodiments disclosed therein. On the contrary, the intent is to cover all alternatives, modifications and equivalents included within the spirit and scope of the disclosure as defined by the appended claims.

It is noted that the drawings presented herein have been provided to illustrate certain features and aspects of embodiments of the disclosure. It will be appreciated from the description provided herein that a variety of alternative embodiments and implementations may be realized, consistent with the scope and spirit of the present disclosure.

As summarized above, the present application is directed to embodiments of apparatus, systems and methods of implementing a stencil shadow volume operation in a computer graphics system through the use of the hardware feature of a compressed stencil data processing unit, sometimes referred to as SL1, similar to the compressed z-data processing unit, ZL1. It will be appreciated by one of ordinary skill in the art that the term buffer, as used below in reference to the stencil and z-data processing units, may include the memory and requisite logic to accomplish the associated data processing.

Reference is made briefly toFIG. 5, which illustrates certain basic components of an embodiment of the invention. The interoperation of these components in carrying our certain functions will be understood by reference from the description that follows. As illustrated, the computer graphics hardware500may contain a graphics processing unit510and memory520. As an alternative, the memory520could be system or host memory or incorporated into the graphics processing unit510. The memory520may include specific allocations for a z-buffer, ZL2530, and a stencil buffer, SL2540. The ZL2530and SL2540data structures may also be combined into a single buffer550where, for example, the data record is thirty-two bits with twenty-four bits for the z-value532and eight bits for the stencil value542. As is known, the ZL2/SL2buffer550stores a record for each pixel.

The memory520may also include an allocation for a compressed z-buffer, ZL1560which, for example, stores the z-data562for a group of pixels. As is known, the group of pixels may be a tile, a subtile or more than one tile. Additionally, the memory520may include a compressed stencil buffer, SL1570which, for example, stores the stencil value572for a tile of pixels. As is known, a tile of pixels can be eight-by-eight pixels, eight-by-sixteen pixels or other dimensions determined to produce a desired level of performance.

The graphics processing unit510may also include a cache512, used by SL1570, and a cache511, used by ZL1560, each configurable to allocate portions of the respective caches512,511to store SL1570and ZL1560records. The graphics processing unit510may also include a cache514, configurable to allocate a portion to store the ZL2/SL2550records. The caches512,511and514are respectively referred to as SL1cache, ZL1cache and ZL2/SL2cache. The graphics processing unit510may further include logic516for controlling ZL1560, SL1570, ZL2530and SL2540in, for example, a stencil shadow volume operation. The logic516may also be configured to perform compression of depth data and stencil shadow data. The logic516may further be configured to generate uncompressed stencil shadow data542. Additionally, the logic516may be configured to selectively merge compressed stencil shadow data572and uncompressed stencil shadow data542associated with SL1570and SL2540.

Reference is now made toFIG. 6, illustrating an example of a tile format. In one embodiment of the invention, the tile610is comprised of sixty-four pixels640configured, for example, in an eight-by-eight arrangement. The tile610may also be divided into four subtiles620, where, for example, each subtile is eight-by-two pixels. The tile610may be further divided into sixteen b locks630where, for example, each block is four pixels in a two-by-two configuration.

An example of a data record format for SL1570is illustrated inFIG. 7. In one embodiment, the stencil data572in SL1comprises a record for each tile610and corresponds to the tiles in ZL1560.FIG. 7illustrates an example of a data record format700for an eight-by-eight tile610having four eight-by-two subtiles620. The tile610is further divided into sixteen two-by-two blocks630. The record700includes an eight-bit reference value710for the tile; a three-bit reference value720for each of the sixteen blocks; a one-bit delta value730for each of the sixty-four pixels; and a one-bit SL1subtile dirty bit740for each of the four subtiles.

The block data is, for example, represented by a four-bit nibble with a three-bit carry. The four bits each represent a pixel delta value for each of the four pixels in the block. The three-bit carry value represents the reference value for the block. This data format is based in the concept that an adjacent pixels' stencil value difference is usually not greater than one for a statistically significant percentage of pixels. Although the adjacent pixels' stencil value difference cannot be greater than one in SL1, a dynamic range of −4 to +4 is possible for the pixels using the coding scheme as shown in Table 1.

Reference us now made toFIG. 8, which illustrates one example of logic in ZL1for determining the status of the subtiles. The first step is to check the value of a D_Mask bit for the subtile800. The D_Mask is a bit in the ZL1record and indicates whether the subtile should be drawn. If the value of the D_Mask is zero810then the state of the subtile is REJECT860. If, in the alternative, the D_Mask for the subtile has a value of one810, then the value of a T_Mask for the subtile is checked820. The T_Mask is a bit in the ZL1record and indicates whether the subtile should be retested. If the T_Mask for the subtile has a value of zero830then the state of the subtile is ACCEPT850. If the T_Mask value for the subtile is one830then the state of the subtile is RETEST840. These states are utilized to determine if the subtile is suitable for the SL1operation.

Reference is now made toFIG. 9, which illustrates the implementation of one embodiment of the present invention, described hereinafter. It should be appreciated that implementation of a compressed stencil buffer, SL1, in a stencil shadow volume approach may be accomplished in many different ways and this description merely represents one embodiment of the present invention.

After the status of a subtile of compressed z-data is determined and classified as either RETEST, ACCEPT or REJECT, a determination is made as to whether or not the subtile should be processed by SL1912. If the subtile is RETEST914, then the subtile is not suitable for SL1processing and the stencil operation on that subtile is performed at the pixel or block level in SL2930. If the subtile status is REJECT or ACCEPT then a determination is made as to whether the subtile information will compress916. This determination is based on the capacity of the SL1data record format to accommodate the subtile data. If the data will not compress into a format defined by the data record format then the subtile stencil data is flushed to SL2918. If the subtile stencil data will compress into SL1according to the SL1data record format then the stencil operation is performed on that subtile in SL1940.

When the stencil operation is performed on a subtile in SL1940, the SL1preprocess920, as discussed below, makes an SL1request to the SL1cache922and places the cache information for the subtile stencil record in the SL1FIFO924. The SL1operation926performs the increment and decrement operations consistent with a stencil shadow volume method and merges the compressed data into SL2930. Additionally, in one embodiment, the SL1operation926performs checks to verify that overflow or underflow conditions in the stencil data record are addressed to prevent data corruption or loss. Examples of these functions are discussed in greater detail below.

Reference is now made toFIG. 10, which illustrates an example of the SL1preprocess discussed above. In one embodiment, any subtile in ZL1that has an ACCEPT or REJECT status requires an SL1record1010. An SL1cache hit test1020is performed on the SL1cache and the SL1entry is put into a deep FIFO218in order to compensate for the memory access latency. If the cache hit test is a miss1030, then an SL1memory request is generated1040.

Reference is now made toFIG. 11, which illustrates a process sequence block diagram of the SL1increment operation1100in one embodiment of the invention. The first step in the SL1increment operation is to determine if the tile reference value is at the maximum value1110based on the format of the stencil data record. If the tile reference is at the maximum value then SL1will flush the stencil data for the entire tile1120to SL2for the stencil process to be performed, for example, on the pixel level. If the tile reference value is not at the maximum value, then the increment process will determine if every subtile in the tile has an ACCEPT status1140. If the tile is fully ACCEPT, then the tile reference value is incremented1130and the increment operation is complete. If the tile does not have a fully ACCEPT status, then the blocks are checked for an overflow condition1150. If any of the pixels in a block is in overflow then the block is in an overflow condition. If none of the blocks in a subtile are in an overflow condition then the subtile is incremented1160. The stencil data for any subtile having a block in an overflow condition is flushed to SL21170for the stencil process to be performed, for example, on the pixel level. Operations on the pixel level may be performed in a block or other logical group of pixels.

By way of example, consider the increment operation on a subtile in a compressed stencil buffer record, where the tile reference value is between the minimum and maximum values and the tile is divided into four subtiles respectively referenced as A, B, C, and D. Assume, for example, that subtile C does not have an accept status due to an underflow condition in at least one of the sixteen blocks in that subtile and that no other blocks in the tile have an underflow condition. Further, assume that subtile D does not have an accept status due to an overflow condition in at least one of the sixteen blocks in that subtile and that no other blocks in the tile have an overflow condition. Since subtiles A, B, and C do not have any overflowing blocks, the block reference values for all blocks in those subtiles is incremented. Since subtile D cannot be incremented due to the overflow of one block reference value, the stencil values for all pixels in subtile D are flushed to the pixel stencil buffer.

Reference is now made toFIG. 12, which illustrates a process sequence block diagram of the SL1decrement operation1200in one embodiment of the invention. The first step in the SL1decrement operation is to determine if the tile reference value is at the minimum value1210based on the format of the stencil data record. If the tile reference is at the minimum value then SL1will flush the stencil data for the entire tile1220to SL2for the stencil process to be performed, for example, on the pixel level. If the tile reference value is not at the minimum value, then the decrement process will determine if every subtile in the tile has an ACCEPT status1240. If the tile is fully ACCEPT, then the tile reference value is decremented1230and the decrement operation is complete. If the tile does not have a fully ACCEPT status, then the blocks are checked for an underflow condition1250. If any of the pixels in a block is in underflow then the block is in an underflow condition. If none of the blocks in a subtile are in an underflow condition then the subtile is decremented1260. The stencil data for any subtile having a block in an underflow condition is flushed to SL21270for the stencil process to be performed, for example, on the pixel level. Operations on the pixel level may be performed in a block or other logical group of pixels.

Using the compressed stencil buffer record of the above example, consider the decrement operation. Since subtiles A, B, and D do not have any overflowing blocks, the block reference values for all blocks in those subtiles is decremented. Since subtile C cannot be decremented due to the underflow of one block reference value, the stencil values for all pixels in subtile C are flushed to the pixel stencil buffer. In the alternative, if all subtiles in the tile of the above example have an accept status, then the tile reference value is modified in accordance with the corresponding increment or decrement operation.

As discussed above, when the subtile dirty flag is set in SL1, the SL1data is merged into SL2. The merge operation addresses the situation where the final stencil value is distributed in both SL1and SL2. The merge operation can either happen in the stencil shadow volume pass or the specular color pass. In the stencil shadow volume pass, as illustrated inFIG. 13, the subtile may be in the condition of overflow or underflow1310. When this occurs, the state of the subtile will be converted from ACCEPT to RETEST1320. Additionally, a SM_Mask is generated1330to merge the data from SL1into SL2. The SM_Mask is an extra mask added by the output of SL1to indicate if the merge of SL1and SL2is enabled. The final value, which is the sum of SL1+SL2, is written into SL21340. After the data is merged to SL2, the SL1subtile dirty bit is reset to zero1350to indicate that the subtile is clean and the subtile stencil value can be cleared1360. This dynamic merge reduces the chance of overflow and underflow for each subtile.

Reference is now made toFIG. 14. In the specular color pass, a bit in the ZL1control register triggers the SL1and SL2merge operation. This bit is set when the specular pass begins1410if the SL1tile dirty bit in ZL11420is set and the subtile dirty bit in SL11430is set. The SM_Mask1440is set to signal ZL2to merge SL1and SL2before the stencil compare1450and then to write the sum of SL1and SL2back to SL21460.

The SL1/SL2merge is signaled, as discussed above, by the SM_Mask bit being set for the subtile. Reference is now made toFIG. 15, which illustrates the general merge process. The SM_Mask value is read from SL11510. In the case where the SM_Mask value is zero1530, no operations are performed on the SL1data1520. Otherwise, where the SM_Mask value is one1530, the sum of the values in SL1and SL2is generated1540and this final value is written to SL21550.

Brief reference is now made toFIG. 16, which illustrates one embodiment of the compressed stencil buffer in a stencil shadow volume operation. A tile stencil shadow record is generated1610, which corresponds to a tile, where the tile is subdivided into a plurality of subtiles, which are further subdivided into a plurality of blocks of multiple pixels. Additionally, and in cooperation with the tile stencil shadow record, a pixel stencil shadow record is generated1620to accommodate a stencil shadow value for each pixel. The pixel stencil shadow record is necessary in the case where the stencil shadow data exceeds the capacity of the tile stencil shadow record. Additionally, a tile depth value record is generated1630corresponding to the depth data of the pixels in the tile stencil shadow record. A stencil shadow volume operation is performed1640, where the operation is performed utilizing the tile stencil shadow record when possible. Where the tile stencil shadow record cannot accommodate the stencil shadow operation, the operation is performed at the pixel level utilizing the pixel stencil shadow record.