Abstract:
Write operations to a unit of compressible memory, known as a compression tile, are examined to see if data blocks to be written completely cover a single compression tile. If the data blocks completely cover a single compression tile, the write operations are coalesced into a single write operation and the single compression tile is overwritten with the data blocks. Coalescing multiple write operations into a single write operation improves performance, because it avoids the read-modify-write operations that would otherwise be needed.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation-in-part of co-pending U.S. patent application Ser. No. 11/555,639, filed Nov. 1, 2006, which is herein incorporated by reference. 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     Embodiments of the present invention relate generally to compressed data operations during graphics processing and more specifically to a system and method for avoiding read-modify-write performance penalties during compressed data operations. 
     2. Description of the Related Art 
     In graphics processing, compressed data is often employed for efficient memory usage. For example, the frame buffer of a graphics processing unit (“GPU”) typically stores graphics data in compressed form to realize storage efficiencies. The unit of memory for data stored in the frame buffer is called a “tile” or a “compression tile.” Compression tiles may store color data or depth data for a fixed number of pixels in compressed or uncompressed form. 
       FIG. 1  illustrates a GPU  102  including a rendering pipeline, known as a raster operations pipeline (“ROP”)  104 . ROP  104  is configured to handle data transfer operations to a frame buffer  110 , which is normally implemented as a DRAM, through a frame buffer interface  105 . The frame buffer  110  receives the data in blocks from the frame buffer interface  105  and stores it in the form of tiles. 
     Under some circumstances, the size of the blocks transferred by ROP  104  or another frame-buffer client may be smaller than the compression tile size. In these cases, storing a block in the frame buffer  110  involves identifying a tile that corresponds to the block and updating that tile to include data from the block, while leaving all remaining data in the tile unchanged. For an uncompressed tile, modifying the tile in-memory can be done because the uncompressed format of the tile allows modifying a portion of the tile without disturbing the contents of the remainder of the tile. However, as is commonly known, modifying compressed tiles in-memory is difficult because the dependent relationship among data stored in compressed format causes changes to one portion of the tile to disturb the remainder of the tile. Thus, for a compressed tile, updating the tile requires the frame buffer interface  105  to read the contents of the tile from the frame buffer  110 , decompress the tile contents, modify the uncompressed tile contents with the block of data to be written, and write back the uncompressed, modified tile to the frame buffer  110 . This process is expensive because modern DRAMs are not able to change from read to write mode quickly and because the operation causes the frame buffer  110  to de-pipeline, i.e., stop streaming accesses. 
     SUMMARY OF THE INVENTION 
     The present invention provides an improved method and system for handling compressed data. According to embodiments of the present invention, write operations to a unit of compressible memory, known as a compression tile, are examined to see if data blocks to be written completely cover a single compression tile. If the data blocks completely cover a single compression tile, the write operations are coalesced into a single write operation and the single compression tile is overwritten with the data blocks. Coalescing multiple write operations into a single write operation improves performance, because it avoids the read-modify-write operations that would otherwise be needed. 
     A processing unit according to an embodiment of the present invention includes a frame buffer having a plurality of compression tiles and a rendering pipeline that transfers a sequence of data blocks to be stored in the frame buffer. The data blocks may comprise depth data for a plurality of pixels or color data for a plurality of pixels. The size of the data blocks is less than the size of the compression tiles, so that any single data block write operation on a compression tile requires the data currently stored in the compression tile to be read, decompressed if it was compressed, and modified using the single data block. The modified data is then written into the compression tile. To avoid such read-modify-write operations, the frame buffer interface of the processing unit, according to an embodiment of the present invention, is configured to receive the sequence of data blocks from the rendering pipeline and determine if any multiple number of data blocks (2 or more) completely cover a single compression tile. If this condition is true, the multiple number of data blocks covering a single compression tile are combined and stored in the single compression tile as part of a single, coalesced write operation to the frame buffer. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       So that the manner in which the above recited features of the present invention can be understood in detail, a more particular description of the invention, briefly summarized above, may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments. 
         FIG. 1  illustrates a conventional GPU; 
         FIG. 2  illustrates a computing device in which embodiments of the present invention can be practiced; and 
         FIG. 3  is a flow diagram that illustrates the steps carried out during a write operation by a frame buffer interface shown in  FIG. 2 . 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 2  illustrates a computing device in which embodiments of the present invention can be practiced. The computing device  210  includes a central processing unit (CPU)  220 , a system controller hub  230  (sometimes referred to as a “northbridge”), a graphics subsystem  240 , a main memory  250 , and an input/output (I/O) controller hub  260  (sometimes referred to as a “southbridge”) which is interfaced with a plurality of I/O devices (not shown), such as a network interface device, disk drives, USB devices, etc. 
     The graphics subsystem  240  includes a GPU  241  and a GPU memory  242 . GPU  241  includes, among other components, front end  243  that receives commands from the CPU  220  through the system controller hub  230 . Front end  243  interprets and formats the commands and outputs the formatted commands and data to an IDX (Index Processor)  244 . Some of the formatted commands are used by programmable graphics processing pipeline  245  to initiate processing of data by providing the location of program instructions or graphics data stored in memory, which may be GPU memory  242 , main memory  250 , or both. Results of programmable graphics processing pipeline  245  are passed to a ROP  246 , which performs raster operations, such as stencil, z test, and the like, and saves the results or the samples output by programmable graphics processing pipeline  245  in a render target, e.g., a frame buffer  248 , through a frame buffer interface  247 . 
     ROP  246  is configured to handle data transfer operations to the frame buffer  248 , which is implemented as a DRAM, through the frame buffer interface  247 . The frame buffer interface  247  receives the data in fixed size blocks from ROP  246 , combines the data blocks to form combined blocks, and stores the combined blocks as full compression tiles within the frame buffer  248 . In the embodiment of the present invention illustrated herein, when performing certain blit operations, ROP  246  writes data in blocks of 128 bytes but the corresponding compression tile size is 256 bytes. Thus, one compression tile includes two data blocks. In other embodiments of the present invention, the compression tile size can be any integer multiple of the data block size. 
     The frame buffer interface  247  is configured to examine the blocks of data received from ROP  246  and control the timing of the writes to the tiles in the frame buffer  248 . If two blocks of data that are sequentially received are to be written to two halves of the same tile, the two write operations are coalesced into one write operation on the tile. The write operation includes combining the two data blocks and then writing the combined block onto the tile. In the preferred embodiment, the combined blocks are written onto the tile in uncompressed form. In an alternative embodiment, the combined blocks may be compressed and written onto the tile in compressed form. The correct result is ensured to be written onto the tile using this method because the entire tile is being overwritten. With this method, a copy operation such as a blit operation, which transfers data from a source to a destination can be efficiently carried out, because the write data stream will consist of a sequence of data block pairs, wherein each data block pair has the same write destination tile. As a result, the frame buffer  248  can continue to stream and can avoid de-pipelining to accommodate read-modify-writes. 
       FIG. 3  is a flow diagram that illustrates the steps carried out by the frame buffer interface  247  for each block of data received from ROP  246  during a write operation. In step  310 , each block of data is temporarily held in the frame buffer interface  247  for a fixed number of cycles, e.g., 100 cycles. The block of data is then examined for a match with a preceding block of data, i.e., to see if it and the preceding block of data are two halves of the same tile (step  312 ). If they are, the matching data blocks are combined into a single data block (step  314 ). In step  318 , the combined data block is written into the tile. 
     If no match is found in step  312  within the fixed number of cycles, flow proceeds to step  320 , where it is determined whether the tile being written to is compressed or not. If it is not compressed, the new block of data is written into the tile (step  322 ). If it is compressed, the compressed data is read from the frame buffer  248  (step  324 ) and decompressed (step  326 ). Then, in step  328 , the new block of data is overlaid on top of the decompressed data. In step  330 , the modified decompressed data is written into the tile. 
     In an alternative embodiment, end-of-transfer tokens are included at the end of a data transfer. In such embodiment, the decision block in step  312  is exited when the end-of-transfer token is received, and flow proceeds to either step  314  or step  320  upon receipt of the end-of-transfer token. 
     In a further embodiment, the frame buffer interface  247  holds data blocks for more than one compression tile. In such an embodiment, as a data block arrives, the frame buffer interface  247  determines if it corresponds to any of the pending compression tiles. If it is and it completes a compression tile, this data block and one or more other data blocks that cover the compression tile are written to the compression tile in a single write operation. If a compression tile is not completed within a predetermined time period, a write operation to this compression tile is performed as described in steps  320 ,  322 ,  324 ,  326 ,  328 , and  330 , above. Thus, in this embodiment, data blocks need not arrive in a strict sequence in order to be combined. 
     While foregoing is directed to embodiments in accordance with one or more aspects of the present invention, other and further embodiments of the present invention may be devised without departing from the scope thereof, which is determined by the claims that follow. Claims listing steps do not imply any order of the steps unless such order is expressly indicated.