Method and apparatus for data compression

Abstract

A method and apparatus for processing color data includes storing both fragment pointers and color data in a color buffer, storing a delta color compression (DCC) key indicating which color data to fetch for processing, and fetching the fragment pointers and color data for decompression based on the read DCC key.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 024,254, filed May 13, 2020, and U.S. Patent Application No. 17 / 135,978, filed December 28, 2020, which are incorporated by reference as if fully set forth herein. [Background technology]

[0002] In multisample antialiasing (MSAA) techniques for sampling images, each pixel has multiple sampling points to improve image quality. Each of these sampling points can have a unique color value. However, the sampling points of a pixel may share a common color value.

[0003] The values ​​are stored by only storing each common color value once (e.g., per fragment instead of once per sample). This data is stored in a color surface, and a fragment pointer (fmask) for each sample in the pixel is stored. This fragment pointer is stored in a separate fmask surface.

[0004] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which: [Brief explanation of the drawings]

[0005] [Figure 1] FIG. 1 is a block diagram of an example device capable of implementing one or more features of the present disclosure. [Figure 2] FIG. 2 is a block diagram of the device of FIG. 1 showing additional details. [Figure 3] FIG. 1 is a block diagram illustrating a graphics processing pipeline, according to an example. [Figure 4] 1 is a graphical representation illustrating aspects related to multisampled images. [Figure 5] FIG. 2 illustrates a compression format, according to an example. [Figure 6] 1 is an exemplary flow diagram of a conventional data processing method. [Figure 7] FIG. 1 is an exemplary flow diagram of a data processing method. DETAILED DESCRIPTION OF THE INVENTION

[0006] The method and apparatus are expanded upon in more detail below, but a method for data compression for color surfaces is briefly described here.

[0007] A method for processing color data includes storing fragment pointers and color data together in a color buffer, storing a delta color compression (DCC) key indicating which color data to fetch for processing, and fetching the fragment pointers and color data based on the DCC key read for decompression.

[0008] An apparatus for processing color data includes a memory and a processor operatively coupled to and in communication with the memory, the processor configured to co-store fragment pointers and color data in a color buffer in the memory, read a delta color compression (DCC) key indicating color data to fetch for processing, and fetch the fragment pointers and color data based on the read DCC key for decompression.

[0009] A non-transitory computer-readable medium for processing color data has instructions recorded thereon that, when executed by a processor, cause the processor to perform operations including storing fragment pointers and color data together in a color buffer, reading a delta color compression (DCC) key indicating color data to fetch for processing, and fetching the fragment pointers and color data based on the read DCC key for decompression.

[0010] 1 is a block diagram of an example device 100 capable of implementing one or more features of the present disclosure. Device 100 may include, for example, a computer, a gaming device, a handheld device, a set-top box, a television, a mobile phone, a server, a tablet computer, or any other type of computing device for generating graphic images. Device 100 includes a processor 102, a memory 104, a storage device 106, one or more input devices 108, and one or more output devices 110. Device 100 may also optionally include an input driver 112 and an output driver 114. It should be understood that device 100 may include additional components not shown in FIG. 1 .

[0011] In various alternatives, processor 102 includes a central processing unit (CPU), a graphics processing unit (GPU), a CPU and a GPU located on the same die, or one or more processor cores, each of which may be a CPU or a GPU. In various alternatives, memory 104 is located on the same die as processor 102 or is located separately from processor 102. Memory 104 includes volatile or non-volatile memory (e.g., random access memory (RAM), dynamic RAM, cache). In the embodiment shown in FIG. 1, processor 102 includes a CPU.

[0012] Storage devices 106 include fixed or removable storage devices (e.g., hard disk drives, solid state drives, optical disks, flash drives). Input devices 108 include, but are not limited to, keyboards, keypads, touchscreens, touchpads, detectors, microphones, accelerometers, gyroscopes, biometric scanners, or network connections (e.g., wireless local area network cards for transmitting and / or receiving wireless IEEE 802 signals). Output devices 110 include, but are not limited to, displays, speakers, printers, haptic feedback devices, one or more optics, antennas, or network connections (e.g., wireless local area network cards for transmitting and / or receiving wireless IEEE 802 signals).

[0013] Input driver 112 communicates with processor 102 and input device 108, allowing processor 102 to receive input from input device 108. Output driver 114 communicates with processor 102 and output device 110, allowing processor 102 to send output to output device 110. Note that input driver 112 and output driver 114 are optional components, and device 100 would operate in the same manner without input driver 112 and output driver 114. In an exemplary embodiment, output driver 114 includes an accelerated processing device ("APD") 116 coupled to display device 118. The APD accepts computational and graphics rendering commands from processor 102, processes the computational and graphics rendering commands, and provides pixel output to display device 118 for display. As described in further detail below, APD 116 includes one or more parallel processing units that perform calculations according to the single-instruction-multiple-data ("SIMD") paradigm. Thus, although various functions are described herein as being performed by or in conjunction with APD 116, in various alternatives, the functions described as being performed by APD 116 may additionally or alternatively be performed by other computing devices having similar capabilities that are not driven by a host processor (e.g., processor 102) and provide graphical output to display device 118. For example, it is contemplated that any processing system that performs processing tasks according to the SIMD paradigm may perform the functions described herein. Alternatively, it is contemplated that computing systems that do not perform processing tasks according to the SIMD paradigm may perform the functions described herein.

[0014] FIG. 2 is a block diagram of device 100 showing additional details regarding the execution of processing tasks on APD 116. Processor 102 maintains, within system memory 104, one or more control logic modules for execution by processor 102. The control logic modules include operating system 120, kernel-mode driver 122, and applications 126. These control logic modules control various aspects of the operation of processor 102 and APD 116. For example, operating system 120 communicates directly with hardware and provides an interface to the hardware for other software executing on processor 102. Kernel-mode driver 122 controls the operation of APD 116, for example, by providing an application programming interface (API) to software executing on processor 102 (e.g., applications 126) to access various features of APD 116. Kernel-mode driver 122 also includes a just-in-time compiler that compiles programs for execution by processing components of APD 116 (such as SIMD unit 138, described in more detail below).

[0015] APD 116 executes commands and programs for selected functions, such as graphics and non-graphics operations that are or may be suitable for parallel processing. APD 116 can be used to perform graphics pipeline operations, such as pixel operations, geometry calculations, and rendering of images to display device 118, based on commands received from processor 102. APD 116 also performs computational operations not directly related to graphics operations, such as operations related to video, physics simulation, computational fluid dynamics, or other tasks, based on commands received from processor 102.

[0016] The APD 116 includes a computation unit 132 that includes one or more SIMD units 138 that, at the request of the processor 102, perform operations in a parallel manner according to the SIMD paradigm. The SIMD paradigm allows multiple processing elements to share a single program control flow unit and program counter, thus executing the same program but executing it with or using different data. In one example, each SIMD unit 138 includes 16 lanes, each of which executes the same instruction simultaneously with other lanes in the SIMD unit 138 but can execute the instruction with different data. Lanes can be predictively switched off if not all lanes need to execute a given instruction. Prediction can also be used to execute programs with branching control flow. More specifically, for programs with conditional branches or other instructions where control flow is based on calculations performed by individual lanes, prediction of lanes corresponding to currently unexecuted control flow paths and serial execution of different control flow paths enables arbitrary control flow.

[0017] The basic unit of execution within the compute unit 132 is the work item. Each work item represents a single instantiation of a program executing in parallel on a particular lane. Work items can execute simultaneously as a “wavefront” on a single SIMD unit 138. One or more wavefronts are included in a “workgroup,” which contains a collection of work items designated to execute the same program. A workgroup can be executed by executing each of the wavefronts that make up the workgroup. Alternatively, a wavefront executes serially on a single SIMD unit 138, or partially or fully in parallel on different SIMD units 138. A wavefront can be thought of as the largest collection of work items that can execute simultaneously on a single SIMD unit 138. Thus, if a command received from the processor 102 indicates that a particular program is parallelized to an extent that it cannot be executed simultaneously on a single SIMD unit 138, the program is divided into wavefronts that are either parallelized on two or more SIMD units 138 or serialized on the same SIMD unit 138 (or both parallelized and serialized, as appropriate). The scheduler 136 performs operations related to scheduling the various wavefronts on the different compute units 132 and SIMD units 138 .

[0018] The parallel processing provided by the compute units 132 is well suited to graphics-related operations such as pixel value calculations, vertex transformations, and other graphics operations. Thus, in some cases, the graphics processing pipeline 134, which accepts graphics processing commands from the processor 102, provides computational tasks to the compute units 132 for execution in parallel.

[0019] Computation unit 132 is also used to perform computational tasks that are not related to graphics or that are not performed as part of the "normal" operation of graphics processing pipeline 134 (e.g., custom operations performed to supplement the operations performed on graphics processing pipeline 134). Applications 126 or other software executing on processor 102 send programs defining such computational tasks to APD 116 for execution.

[0020] Figure 3 is a block diagram illustrating additional details of the graphics processing pipeline 134 shown in Figure 2. The graphics processing pipeline 134 includes logical stages, each of which performs a specific function. The stages represent subdivisions of the functionality of the graphics processing pipeline 134. Each stage may be implemented partially or fully as a shader program executing within the programmable processing unit 202, or partially or fully as fixed-function, non-programmable hardware external to the programmable processing unit 202.

[0021] The input assembler stage 302 reads user-filled buffers (e.g., buffers filled with requests from software executed by the processor 102, such as applications 126) and assembles the data into primitives for use by the rest of the pipeline. The input assembler stage 302 can generate different types of primitives based on the primitive data contained in the user-filled buffers. The input assembler stage 302 formats the assembled primitives for use by the rest of the pipeline.

[0022] The vertex shader stage 304 processes the vertices of the primitives assembled by the input assembler stage 302. The vertex shader stage 304 performs various per-vertex operations such as transformation, skinning, morphing, and per-vertex lighting. Transformation operations include various operations for transforming the coordinates of vertices. These operations include one or more of a modeling transformation, a view transformation, a projection transformation, a perspective division, and a viewport transformation. As used herein, such transformations are considered to modify the coordinates or "position" of the vertices on which the transformation is performed. Other operations of the vertex shader stage 304 modify attributes other than coordinates.

[0023] The vertex shader stage 304 is implemented partially or completely as a vertex shader program that runs on one or more compute units 132. The vertex shader program is provided by the processor 102 and is based on a program pre-written by a computer programmer. The driver 122 compiles such a computer program to generate a vertex shader program having a form suitable for execution within the compute units 132.

[0024] The hull shader stage 306, tessellator stage 308, and domain shader stage 310 work together to implement tessellation, which converts simple primitives into more complex primitives by subdividing the primitives. The hull shader stage 306 generates patches for tessellation based on input primitives. The tessellator stage 308 generates a sample set for the patch. The domain shader stage 310 calculates vertex positions for vertices corresponding to the samples in the patch. The hull shader stage 306 and domain shader stage 310 may be implemented as shader programs executing on the programmable processing unit 202.

[0025] The geometry shader stage 312 performs vertex operations on a primitive-by-primitive basis. A variety of different types of operations can be performed by the geometry shader stage 312, including operations such as point splint expansion, dynamic particle system manipulation, farfin generation, shadow volume generation, single-pass rendering-cube map, per-primitive material swapping, and per-primitive material setting. In some cases, a shader program executing on the programmable processing unit 202 performs the operations of the geometry shader stage 312.

[0026] The rasterizer stage 314 accepts and rasterizes simple primitives generated upstream. Rasterization involves determining which screen pixels (or subpixel samples) are covered by a particular primitive. Rasterization is performed by fixed-function hardware.

[0027] The pixel shader stage 316 calculates the output values ​​of the screen pixels based on the primitives generated upstream and the results of rasterization. The pixel shader stage 316 can apply textures from texture memory. The operations of the pixel shader stage 316 are performed by shader programs running on the programmable processing unit 202.

[0028] The output merge stage 318 accepts the outputs from the pixel shader stage 316, merges them, and performs operations such as z-testing and alpha blending to determine the final color of the screen pixel.

[0029] Texture data defining textures is stored and / or accessed by texture unit 320. Textures are bitmap images that are used at various points within graphics processing pipeline 134. For example, in some cases, pixel shader stage 316 applies textures to pixels to improve the apparent rendering complexity (e.g., to provide a more "photorealistic" look) without increasing the number of vertices rendered.

[0030] In some cases, the vertex shader stage 304 uses texture data from the texture unit 320 to modify primitives to increase complexity, for example, by generating or altering vertices for improved aesthetics. In one example, the vertex shader stage 304 uses a height map stored in the texture unit 320 to modify vertex displacements. This type of technique can be used to generate more realistic-looking water, for example, by modifying the position and number of vertices used to render the water, compared to textures used only by the pixel shader stage 316. In some cases, the geometry shader stage 312 accesses texture data from the texture unit 320.

[0031] Specific compression formats are presented herein for compressing and storing image data. The compression formats are useful for compressing multisampled images, among other applications. Figure 4 is a graphical representation 400 illustrating aspects related to multisampled images. The various functional units shown in the figures and / or described herein, including, but not limited to, processor 102, input driver 112, input device 108, output driver 114, output device 110, accelerated processing device 116, scheduler 136, graphics processing pipeline 134, compute unit 132, and SIMD unit 138, may be implemented as a general-purpose computer, processor, or processor core, or as a program, software, or firmware stored on a non-transitory computer-readable storage medium or another medium executable by a general-purpose computer, processor, or processor core.

[0032] In FIG. 4, several pixels (e.g., pixel 1, pixel 2, pixel 3) are shown. A multisampled image includes a grid of these pixels. Each pixel includes one or more samples (e.g., sample 1, sample 2, sample 3, sample 4). A sample is a specific location within a pixel that has a specific color. Each sample can have a color that is different from the colors of other samples within the same pixel. In FIG. 4, the shading of each sample represents the color assigned to the sample.

[0033] Three different pixels are shown. Pixel 1 has a fragmentation degree of 1. Therefore, pixel 1 is completely unfragmented and all samples within pixel 1 have the same color. Pixel 1 can be represented as a single fragment, shown as pixel 1, fragment 1. A "fragment" is a portion of a pixel where all samples have the same color.

[0034] Pixel 2 has a fragmentation level of 2. The two samples on the left have one color, and the two samples on the right have a different color. So pixel 2-fragment 1 has the two samples on the left, and pixel 2-fragment 2 has the two samples on the right.

[0035] Pixel 3 has a fragmentation degree of 3. Pixel 3, fragment 1 contains the top left sample. Pixel 3, fragment 2 contains the right two samples. Pixel 3, fragment 3 contains the bottom left sample. The compression format describes how to compress the data describing these pixels for storage in one or more hardware buffers.

[0036] 5 is a diagram illustrating a compressed format 500, according to an example. An image is shown to illustrate the correlation between the data stored in the compressed format and an image. The image includes image units, each of which includes one or more pixels. An image unit is a portion of an image that includes one or more pixels.

[0037] The compressed format includes the contents of a metadata buffer and a color buffer. In some implementations, the metadata buffer and the color buffer are physical buffers, such as a cache, configured to store the data described herein. In other implementations, one or both of these buffers represent data stored in any memory structure, such as a cache, memory, non-volatile memory, or any other storage device.

[0038] The metadata buffer stores metadata compression units (data describing the compression), and the color buffer stores color data compression units. Each combination of one metadata compression unit and one color data compression unit forms a compression unit. Each metadata compression unit is associated with only one compression unit, and each color data compression unit is associated with only one compression unit.

[0039] A compression unit is compressed data for an image unit of an image. In some implementations, a compression unit is a fixed amount of data and can have "empty" or "unused" space depending on the amount of data needed to compress the corresponding image unit. In some such implementations, the metadata buffer and color buffer each represent dedicated memory, such as a dedicated cache memory, or a dedicated portion of memory, such as a cache memory. In some such implementations, each compression unit corresponds to one or more cache lines. In other implementations, a compression unit is a variable amount of data and compression units are packed together to reduce the total amount of data for an image.

[0040] The metadata compression unit stores, for example, the fragmentation degree and data size, and in some implementations the sampling rate. Additionally, the metadata unit can indicate that the compressed data has fragmentation, and the fragmentation degree is stored within the compressed data.

[0041] Alternatively, the metadata unit may indicate that a form of compression is present, which may indicate that the compressed data size is smaller than the size of a block, and the compressed data may indicate that fragmentation is present and to what extent.

[0042] The fragmentation degree indicates the maximum fragmentation degree of pixels in the image unit corresponding to the compression unit that includes the metadata compression unit. The fragmentation degree is shown in FIG. 4. The metadata compression unit also stores a data size, which indicates the size of the corresponding color data compression unit (i.e., the number of bits of the color data compression unit that belongs to the same compression unit as the metadata compression unit).

[0043] Each color data compression unit includes one or more fragment color pointers and one or more items of fragment color data. The fragment color pointer indicates which fragment color a particular sample for a particular pixel has. In some examples, each color data compression unit includes one fragment color pointer for each sample in the corresponding image unit. Thus, each color data compression unit includes a number of fragment color pointers equal to the number of samples in the corresponding image unit.

[0044] For a given sample, the corresponding fragment color pointer indicates or points to the corresponding fragment color. In some implementations, the order of the fragment color pointers within the color data compression unit allows identification of which fragment color pointer corresponds to which sample.

[0045] In an example with two samples per pixel, the first fragment color pointer (e.g., least significant bit) corresponds to the first sample of the first pixel in the image unit, the second fragment color pointer (e.g., next least significant bit) corresponds to the second sample of the first pixel, the third fragment color pointer (e.g., next least significant bit) corresponds to the first sample of the second pixel in the image unit, and the fourth fragment color pointer (e.g., next least significant bit) corresponds to the second sample of the second pixel in the image unit.

[0046] In implementations where the sampling rate is stored in the metadata compression unit, the sampling rate indicates the number of samples per pixel in the corresponding image unit.

[0047] The fragment colors in the color data compression unit contain the actual color values ​​of a particular fragment. As explained, each fragment color pointer indicates which of these fragment colors actually applies to the corresponding fragment. Like the fragment color pointers, in some implementations, the fragment colors are arranged sequentially in the color data compression unit, with each fragment color pointer identifying an individual fragment color data item for the corresponding sample. In some examples, the fragment colors are specific to individual pixels. In other words, each pixel stores one or more color fragments, and the fragment color pointer selects, for each pixel, which fragment color is the color for the corresponding sample.

[0048] The fragment color data itself can be compressed. An exemplary compression scheme for fragment color data is Delta Color Compression (DCC), which stores a base color (e.g., the color for any of the samples in a pixel or other compression group, such as an image unit) and a color delta for each other sample, where the color delta is the difference between the base color and the actual color of the corresponding sample.

[0049] The fragment color pointer and fragment color data may be of variable length. In one example, the length of each fragment color pointer is equal to the number of bits required to represent the maximum number of fragments in each pixel. In one example, four fragments are allowed in each pixel, meaning that each pixel in the image unit is allowed to have a maximum of four fragments. In this example, the size of the fragment color pointer for each sample is two bits (two bits can represent four possible values). In another example, the maximum number of fragments in each pixel of the image unit is two, meaning that each pixel can contain a maximum of two fragments, therefore the size of the fragment color pointer for each sample is one bit. In some examples, each fragment color can have a different length because the compression algorithm can generate data of different sizes. Furthermore, if only a single fragment is included (i.e., one fragment), no fragment pointers are stored (e.g., they are of length 0) because all samples point to the first fragment.

[0050] 6 is an exemplary flow diagram 600 of a conventional compression method. In step 610, the cmask surface is read. In step 620, the cmask surface is decoded to find how much of the fmask needs to be fetched.

[0051] Once it is determined in step 620 how much of the fmask needs to be fetched, the fmask is fetched (step 630) and the DCC key is read (step 640). A fragment operation is performed and the amount of color data is read (step 650).

[0052] Next, the DCC-compressed color data is read (step 660), and the color data is decompressed based on the DCC key (step 670). In conventional methods, there are two surfaces to describe the entire color data: the color data fragment itself and the fmask data, which is pointer information to the color data fragment. That is, in conventional compression methods, there are two pairs of surfaces: one pair of surfaces for the fragment pointer and compression metadata (the fmask and cmask surfaces), and the other pair for the color surface and its metadata (the color data fragment and DCC key).

[0053] 7 is an example flow diagram of a data processing method 700. In step 710, the DCC key is read. Color data is then fetched based on the DCC key, including the fmask data (step 720). In step 730, the color data (including color fragments and DCC compression) is decompressed. Alternatively, only the DCC is compressed and the color data is stored in the cache in fragment-compressed form. Alternatively, the color data can be stored fully compressed. In this scenario, decompression occurs when the cache is accessed to process pixels / samples, and then recompressed when the data is written back to the cache.

[0054] In the exemplary method 700, the data fetched in step 720 includes fragment pointers for the data (e.g., fmask data) and the color fragment data itself. Once the data is fetched, it may be stored in a fully compressed format, or the DCC is expanded and stored in a fragment-compressed format. The data may also be fully expanded.

[0055] When stored in fragment-compressed format, the fragment color data and the fragment pointers are stored in separate data structures, which can provide easier processing. Also, if the fragmentation degree is below a certain level, the data can be stored in fragment-compressed format. For example, if the fragmentation degree is 1, it can be stored in fragment-compressed format. In this case, any storage required for the fragment pointers may not need to be present (e.g., if there is only one fragment, all of the fragment pointers point to that fragment).

[0056] There may be performance advantages to storing data in a fragment-compressed format. For example, if full coverage is the blended pixels on a single fragment pixel, then blending can be done once for the entire pixel. However, if the pixel is fully expanded, the information that all samples have the same value may be lost, so the blender needs to perform the blending operation once per sample instead of once per pixel.

[0057] It should be understood that many variations are possible based on the disclosure herein, and although features and elements are described above in particular combinations, each feature or element can be used alone without other features and elements, or in various combinations with or without other features and elements.

[0058] The various functional units shown in the figures and / or described herein, including, but not limited to, processor 102, input driver 112, input device 108, output driver 114, output device 110, acceleration processing device 116, scheduler 136, graphics processing pipeline 134, compute unit 132, and SIMD unit 138, may be implemented as a general-purpose computer, processor, or processor core, or as a program, software, or firmware stored on a non-transitory computer-readable storage medium or another medium executable by the general-purpose computer, processor, or processor core. The provided methods may be implemented in a general-purpose computer, processor, or processor core. Suitable processors include, by way of example, general-purpose processors, special-purpose processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), and / or a state machine. Such processors can be produced by configuring a manufacturing process using the results of processed hardware description language (HDL) instructions and other intermediate data such as a netlist (such instructions can be stored on a computer-readable medium). The result of such processing can be a mask work that is then used in a semiconductor manufacturing process to produce a processor implementing features of the present disclosure.

[0059] The methods or flow diagrams provided herein may be implemented in a computer program, software, or firmware embodied in a non-transitory computer-readable storage medium for execution by a general-purpose computer or processor. Examples of non-transitory computer-readable storage media include read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (e.g., internal hard disks and removable disks), magneto-optical media, and optical media (e.g., CD-ROM disks and digital versatile disks (DVDs)).

Claims

1. 1. A method for processing color data, comprising: storing first color data in a color buffer in a fragment-compressed format based on a fragmentation degree of the first color data, the fragmentation degree being related to a number of different color fragments associated with a pixel; storing second color data in the color buffer in fully compressed form based on the fragmentation degree of the second color data; fetching a fragment pointer and either the first color data or the second color data from the color buffer, wherein the fetching includes using a delta color compression (DCC) key for either the first color data or the second color data to perform decompression; the color buffer is a memory that stores the fragment pointer and color data; the storing and fetching are performed in an order determined by a graphics processing pipeline; method.

2. The method of claim 1, further comprising: storing the expanded color data after said fetching.

10. The method of claim 1.

3. The method of claim 2, further comprising storing the color data in a compressed format prior to said fetching.

10. The method of claim 1.

4. further comprising: developing the color data. The method of claim 3.

5. and further comprising: expanding the color data using the DCC key to form DCC data.

10. The method of claim 1.

6. storing the DCC data in a fragment-compressed format. The method of claim 5.

7. the color data and the fragment pointer for the DCC are stored in separate data structures within the color buffer; The method of claim 6.

8. the DCC data is stored in a fragment-compressed format based on the fragmentation degree of the first color data or the second color data; The method of claim 6.

9. If the fragmentation degree is equal to 1, the DCC data is stored in a fragment-compressed format.

9. The method of claim 8.

10. 1. An apparatus for processing color data, comprising: a memory for storing a color buffer; a processor operatively coupled to the memory, the processor communicating with the memory; The processor: storing first color data in a color buffer in a fragment-compressed format based on a fragmentation degree of the first color data, the fragmentation degree being related to a number of different color fragments associated with a pixel; storing second color data in the color buffer in fully compressed form based on the fragmentation degree of the second color data; fetching a fragment pointer and either the first color data or the second color data from the color buffer, wherein the fetching uses a delta color compression (DCC) key for either the first color data or the second color data to perform decompression; and the color buffer is a memory that stores the fragment pointer and color data; the storing and fetching are performed in an order determined by a graphics processing pipeline; Device.

11. the processor stores the developed color data in the memory after the fetching; 11. The apparatus of claim 10.

12. the processor stores the color data in compressed form in the memory prior to said fetching; 11. The apparatus of claim 10.

13. The processor develops the color data.

13. The apparatus of claim 12.

14. the processor uses the DCC key to expand the color data to form DCC data; 11. The apparatus of claim 10.

15. the processor stores the DCC data in fragment-compressed format; 15. The apparatus of claim 14.

16. the color data and the fragment pointer for the DCC are stored in separate data structures within the color buffer; 16. The apparatus of claim 15.

17. The DCC data is stored in a fragment-compressed format based on the degree of fragmentation.

16. The apparatus of claim 15.

18. If the fragmentation degree is equal to 1, the DCC data is stored in a fragment-compressed format.

18. The apparatus of claim 17.

19. 1. A computer-readable storage medium for processing color data, the computer-readable storage medium having instructions recorded thereon that, when executed by a processor, cause the processor to perform operations, the operations comprising: storing first color data in a color buffer in a fragment-compressed format based on a fragmentation degree of the first color data, the fragmentation degree being related to a number of different color fragments associated with a pixel; storing second color data in the color buffer in fully compressed form based on the fragmentation degree of the second color data; fetching a fragment pointer and either the first color data or the second color data from the color buffer, wherein the fetching includes using a delta color compression (DCC) key for either the first color data or the second color data to perform decompression; the color buffer is a memory that stores the fragment pointer and color data; the storing and fetching are performed in an order determined by a graphics processing pipeline; A computer-readable storage medium.

20. The method of claim 20, further comprising storing the expanded color data after said fetching.

20. The computer-readable storage medium of claim 19.

21. 1. A method for processing color data, comprising: compressing and storing first data in a fragment-compressed format based on a fragmentation degree of the first data, the fragmentation degree being related to a number of different color fragments associated with a pixel; compressing second data in a fully compressed format based on the fragmentation degree of the second data and storing the second data in the color buffer; compressing and storing compressed data, the compressed data including information related to compression of the first data or the second data; fetching and processing the first data or the second data as color data based on information stored in the compressed data; the first data includes fragment color data and associated fragment pointers, the second data includes color data in fully compressed form, the compressed data including a Delta Color Compression (DCC) key; the compressing, storing, and fetching are performed in an order determined by a graphics processing pipeline; method.

22. the first data includes fragment color data and a fragment pointer associated with the fragment color data; 22. The method of claim 21.

23. the fragment color data and the fragment pointer are stored in separate data structures within the color buffer that stores the first data and the second data; 23. The method of claim 22.

24. the fetching uses the DCC key to indicate color data of the first data or the second data; The method comprises: expanding the color data using the DCC key to form DCC data; 22. The method of claim 21.

25. The DCC data is stored in a fragment-compressed format based on the degree of fragmentation.

25. The method of claim 24.

26. If the fragmentation degree is equal to 1, the DCC data is stored in a fragment-compressed format.

26. The method of claim 25.

27. 1. An apparatus for processing color data, comprising: Memory and a processor operatively coupled to the memory, the processor communicating with the memory; The processor: compressing and storing first data in a fragment-compressed format based on a fragmentation degree of the first data, the fragmentation degree being related to a number of different color fragments associated with a pixel; compressing second data in a fully compressed format based on the fragmentation degree of the second data and storing the second data in the color buffer; compressing and storing compressed data, the compressed data including information related to compression of the first data or the second data; fetching and processing the first data or the second data as color data based on information stored in the compressed data; and the first data includes fragment color data and associated fragment pointers, the second data includes color data in fully compressed form, the compressed data including a Delta Color Compression (DCC) key; the compressing, storing, and fetching are performed in an order determined by a graphics processing pipeline; Device.

28. the first data includes fragment color data and a fragment pointer associated with the fragment color data; 28. The apparatus of claim 27.

29. the fragment color data and the fragment pointer are stored in separate data structures within the color buffer that stores the fragment pointer and the fragment color data; 29. The apparatus of claim 28.

30. the fetching uses the DCC key to indicate color data of the first data or the second data; The processor: and configuring the color data to be expanded using the DCC key to form DCC data.

28. The apparatus of claim 27.

31. the DCC data is stored in a fragment-compressed format based on the fragmentation degree of the first data and the second data.

31. The apparatus of claim 30.

32. If the fragmentation degree is equal to 1, the DCC data is stored in a fragment-compressed format.

32. The apparatus of claim 31.

Images