CN100578542C - Graphics processing system and method for storing texture map data in the same - Google Patents

Abstract

The present invention relates to a graphics processing system and a method for storing texture map data in the graphics processing system, and more particularly, to a system and a method for managing graphics data. One embodiment of the present invention includes a graphics processing system that includes a texture management unit that organizes texture map data according to a texture tile-based format, wherein the texture map data spans at least one mip level. In addition, the graphics processing system includes a texture cache coupled to the texture management unit for receiving the reorganized texture map data from the texture management unit.

Description

Graphics processing system and method for storing texture map data in the graphics processing system

technical field

The present invention relates to graphics processing, and more particularly to systems and methods for graphics data management.

Background technique

As known in the background art, a computer graphics processing system needs to process a large amount of data, including texture data. Textures are digital images (usually rectangular) with a (u,v) coordinate space. The smallest addressable unit of a texture is a texel, which is assigned a specific (u, v) coordinate based on its position. In texture mapping operations, textures are mapped onto the surface of the graphical model to render the model to create the desired image. In the destination image, the texels are located at specific coordinates in the (x,y) coordinate system. The purpose of texture mapping is to provide a realistic appearance on the surface of an object.

Texture data is usually stored in system memory, which is a shared resource. In many computer systems, other components may attempt to access data used by the graphics processing system or utilize a shared system bus, both of which may result in increased data access times for the graphics processing system. Additionally, requesting data from system memory may take an excessive amount of time for other reasons. Therefore, accessing system memory may have a performance-inhibiting effect on the graphics processing system.

In modern computer graphics, texture processing can include many different types of texture mapping techniques, including cubic mapping, mipmapping, and various anisotropic mappings. Since the arithmetic and logical operations required to perform texture processing are very complex and numerous, it is necessary to use dedicated circuits for texture processing in addition to circuits for other graphics processing operations. Accordingly, such texture processing dedicated circuits may comprise a significant percentage of the hardware gates that make up a graphics processing unit.

Texture mapping is expensive in terms of computation and memory access. One technique to improve data accessibility is to provide texture data needed by the graphics system by providing texture data from system memory to the texture cache via a texture cache dedicated to storing texture data before the data needs to be textured. needed texture data and reduce the need to access system memory. This approach, in turn, reduces problems related to memory latency. However, memory latency continues to be an issue even with texture cache memory because the management and storage of texture data is not very efficient. Therefore, there is a need in the industry for improvements in memory storage of textured tile data.

Contents of the invention

The disclosed embodiments of the present invention provide a system and method for compressing and storing texture map data in a slice-major format.

One embodiment of the invention includes a graphics processing system including a texture management unit that organizes texture map data according to a texture slice-based format, wherein the texture map data spans at least one mip level. In addition, the graphics processing system further includes a texture cache memory, wherein the texture cache memory is coupled to the texture management unit and is used for receiving reorganized texture map data from the texture management unit. The texture management unit includes: a texture data formatter, configured to arrange the texture slices in the texture map data according to the texture slice-based format, wherein the texture slices with the same mip level are grouped and stored together, if The sum of all the texture slices with the same mip level is less than the size of a brick, then the texture slices with the same mip level are stored in the brick; the parameter calculation logic module is used to calculate the parameters of each texture slice in the texture map data; and an address calculation logic module, configured to use the parameters to calculate a cache memory address of each texture slice in the texture map data.

Another embodiment of the present invention includes a method for storing texture map data in a graphics processor, and the method can be roughly summarized by the following steps: grouping texture tiles of texture map data according to mip levels, wherein texture tiles with the same mip level Texture slices are grouped and stored together; if the sum of the size of a plurality of said texture slices is less than a tile, then a plurality of texture slices are arranged in said tiles according to the mode flag; calculate each mip level about each a parameter of the texture slice; calculating a memory address of each texture slice in the texture map data according to the parameters calculated in the previous step; and storing the reorganized texture slice in the texture cache memory.

Yet another embodiment of the present invention includes a method of storing texture map data in a graphics processor, and the method can be broadly summarized by the following steps: recombining texture tiles of texture map data into a texture tile-based format, wherein Texture slices with the same level of detail are grouped and stored together; if the total amount of all texture slices with the same level of detail is smaller than the size of the tile, then the texture slices with the same level of detail are stored in the same tile; calculations for each parameters of a texture slice, wherein these parameters are calculated for each level of detail; a new memory address for each texture slice in the texture map data is calculated based on the calculated parameters; and the restructured texture slice and the new memory address Stored in texture cache.

Other systems, methods, features and benefits of the invention will be, or become, apparent to one with skill in the art upon examination of the following figures and implementation. It is intended that all such additional systems, methods, features and benefits be included within this description, be within the scope of the invention, and be protected by the following claims.

Description of drawings

FIG. 1 is a block diagram of an embodiment of a multi-GPU system.

Figure 2 illustrates some basic elements of texture data management within a computer graphics system.

3 is a block diagram illustrating an exemplary L2 cache memory organization format.

FIG. 4 illustrates an exemplary 32-bit texture image tile.

Figure 5 depicts a flowchart of an embodiment of a method for performing texture tile-based compression of brick-like texture data.

FIG. 6A illustrates Mode 0 for the embodiment in FIG. 5 .

FIG. 6B illustrates Mode 1 for the embodiment in FIG. 5 .

FIG. 7 depicts an embodiment of storing volumetric texture maps in a texture cache in a texture tile-based format.

Figure 8 depicts a flowchart of another embodiment of a method for performing texture tile-based compression of brick-like texture data.

Detailed ways

Having summarized various aspects of the invention, reference will now be made in detail to the description of the invention as illustrated in the drawings. While the invention will be described in conjunction with the drawings, it is not intended to limit the invention to the one or more embodiments disclosed herein. Rather, it is intended to cover all alternatives, modifications and equivalents as included within the spirit and scope of the invention as defined by the appended claims.

The systems and methods disclosed herein can be used to efficiently manage and organize texture data such that any texture data required, for example, for texture filter processing can be easily retrieved in a graphics processing system. Often, many different formats and sizes of texture data are received from system memory, and failure to take into account the size or composition of the data may result in an inefficient use of texture cache memory resources. One reason for this inefficiency is that there is too much delay in fetching texture data. Understandably, delays in retrieving texture tiling data cause delays in processing this data. Therefore, there is a need for a system and method for storing texture-like brick data more efficiently, so as to achieve fast processing of graphics data in a computer graphics environment.

Therefore, the present invention discloses a system and method for compressing and storing texture map data according to a texture tile-based format. A mipmap generally refers to a predetermined aggregation of images that accompany a primary texture. The intended aggregation of these images is simply a lower resolution replica of the main texture. Mipmaps are useful when viewing a particular object from a distance such that the object and surrounding textures become smaller. When viewing a smaller version of an object, based on the resolution class, switch to an appropriate mipmap image to render the appropriate texture resolution for the class. Compared to real-time calculations, using mipmaps reduces the time required to render an object by simply looking up a predetermined image.

Each mip level within a mipmap chain is assigned a level of detail (LOD) value to indicate the resolution level. The higher the LOD value, the smaller the image and the lower the resolution. That is, as the object is farther away from the viewer, the complexity of the object (eg in texture) becomes smaller. For the purposes of the nomenclature used herein, the term "level of detail" and the term "mip level" are used interchangeably between. For a given display, multiple surfaces may have to be stored. Each of these surfaces is stored in a continuous fashion. Furthermore, texture map data for such surfaces can be stored in several ways. As a non-limiting example, texture data may be stored according to a "mip-based" format. That is, the texture slices of the texture data are organized in such a way that the first texture slice (eg, texture slice 0) of each mip level is stored together. Therefore, texture slice 0 of mip level 1, texture slice 0 of mip level 2, texture slice 0 of mip level 3, etc. are all stored together in a contiguous manner. This process continues to the next texture slice of all mip levels (eg, texture slice 1), and so on. Alternatively, texture data can be stored according to mip level or in a "texture slice-based" format. Therefore, texture slice 0 of mip level 1, texture slice 1 of mip level 1, texture slice 2 of mip level 1, etc. are all stored together. That is, all texture tiles with the same mip level are stored together in a contiguous manner. This process continues for all texture tiles at the next highest mip level, and so on.

Usually texture map data is stored according to the mip-based format. Embodiments of the present invention focus on methods for storing texture data in a "texture tile-based" format. As further described herein, embodiments of the present invention increase the throughput of retrieving texture data by "squeezing" or compressing the data together so that smaller texture tiles do not occupy an entire texture tile in texture cache memory. Efficiency, thereby avoiding wasting memory space.

Generally, texture slices refer to 2D images used to reproduce 3D objects. A texel is a 2D point in an image and is the basic building block of a texture space for graphics processing. A texel is usually addressed by two coordinates (u and v). Textures are usually represented by arrays of texels. During texture mapping, a texture seek is performed to find out where the center of each texel falls on the texture. Because a textured surface may be at any distance and orientation relative to the viewer, a pixel does not usually correspond directly to a texel, and some form of filtering must be applied to determine the best color for the pixel, however ineffective or incorrect filtering will Appears as a processed image.

In general, when discussing volume texture mapping mechanisms, several properties are common. First, when rendering volumetric textures, each texture slice is typically rendered separately on a slice-by-slice basis. When reading a volumetric texture, the direction of movement with respect to the textured surface is usually performed in a random fashion. When specifying a texture sample, three coordinates are assigned to a 3D (three-dimensional) texture (that is, a volume texture). Coordinates change in each of the three dimensions with generally equal chances. Thus, the probability of an object moving through a given tile is generally the same as the probability of an object moving within the same tile. As an illustration, assuming a 3D texture is defined by a (u, v, r) coordinate space, changes in the u and v directions will result in sampling within a given texture slice, while changes in the r direction will require sampling across Multiple texture slices for sampling. Therefore, it is preferable to store adjacent texture tiles at the same mip level as close as possible to each other in cache memory to allow more efficient data retrieval. Ideally, these contiguous texture tiles would be stored in the same cache page in the texture cache, and even in the same cache line. Typically, different views of a particular textured surface will cover some number of texture slices and mip levels. Thus, the generation of a view may be created by a rendering target array comprising texture tiles spanning a certain number of mip levels. As a non-limiting example, a certain view might include texture slices 0-5 and mip levels 1-3. Thus, this view is spanned across six texture slices and spans three different mip levels. To help ensure that a specific view can be captured with an integer number of texture slices and an integer number of mip levels, the texture data is stored as an array of 2D (two-dimensional) mipmaps. Additionally, texture data is organized into texture tiles grouped together by mip level and stored. Thus, all texture tiles at a given mip level are stored together, and all texture tiles at the next lower mip level are also grouped and stored together. In this way, texture tiles are stored in a "texture tile-based" format. Although the number of included texture tiles and spanned mip levels in the three dimensions (x, y, z) is arbitrary, mip-mapped volumetric textures are usually some power of 2 dimensions. As examples, a volumetric texture map might be 2048x2048x2048 or 211x211x211 pixels. At least one benefit of certain embodiments described herein is that texture data can be better managed and stored according to the characteristics discussed above.

Referring now to FIG. 1 , a simplified block diagram of a computer system 100 is illustrated. Computer system 100 includes CPU 102, system memory 104, and graphics processing system 110. CPU 102 can perform various functions, including determining information (such as viewpoint location) that can generate a graphical display. System memory 104 stores various data, including graphics display data such as texture data 106 . Based on information determined by CPU 102 and data stored in system memory 104, graphics processing system 110 generates display data for display device 130, such as a monitor. Texture maps are used to add texture to objects. Graphics processing system 110 renders texture tiles of a 3D object, which are essentially "stacked" to form the object. Once the 3D texture is created, the object is textured by adding the texture to the object to form an image.

The CPU 102 sends requests to the graphics processing system 110 via the system interface 108, including requests for processing and displaying graphics information. Graphics requests from CPU 102 are received by graphics processing system 110 and provided to front end processor 112, which generates a pixel stream containing pixel coordinates.

Information about pixel coordinates generated by the front-end processor 112 is provided to the texture filter 118 via the texture data management unit 114 and the texture cache system 116 . Texture data management unit 114 receives information from front end processor 112 and sends the data to texture cache system 116 to organize the data prior to storage.

Texture filter 118 then filters the information and generates texture data for each pixel by performing, for example, bilinear filtering, trilinear filtering, or a combination thereof. In addition to known texture filter elements such as linear interpolators and accumulators, texture filter 118 also includes programmable table filters to provide specific filtering operations in conjunction with other texture filter elements. Texture data is a component of the final color data sent to frame buffer 120 for use in generating a display image on display device 130 .

The texture cache system 116 may include multiple caches, including, for example, a level 1 (L1) cache and a level 2 (L2) cache. Texture information is stored in individual texels, which are used during graphics processing to define color data displayed at pixel coordinates. Texture data flows from system memory 104 to texture data management unit 114 , and then to texture cache system 116 , and then to texture filter 118 . It should be noted that for some embodiments, the texture data management unit 114 may be integrated in the texture cache system 116 .

Referring now to FIG. 2, some basic elements of a texture data management unit within a computer graphics system are illustrated. It should be noted that certain elements not necessary for describing the texture data management unit have been omitted for the sake of brevity. The computer graphics system 210 includes a texture data management unit 212 for receiving texture data 106 that is compressed and reassembled before being forwarded to the texture cache system 116 . For some embodiments, texture data management unit 212 includes texture data formatter 218 , parameter computation logic 220 , and address computation logic 214 .

Referring briefly to FIG. 3 , it is a block diagram of an L2 cache memory organization format according to an embodiment. As noted above, the texture cache system 116 may include multiple caches, including, for example, an L1 cache and an L2 cache. The L2 cache memory 310 may include a plurality of L2 pages 315 , and each page 315 may be divided into a plurality of L2 data lines 320 , and each L2 data line 320 is further divided into even blocks 340 and odd blocks 330 . Even blocks 340 are used to process texture data from even pipelines or cache lines, while odd blocks 330 are used to process texture data from odd pipelines or cache lines. Within each of odd blocks 330 , even blocks 340 , L2 is subdivided into banks 350 . Although it is disclosed that each block includes two banks, those skilled in the art will appreciate that the cache may include more or fewer banks. It should be noted that although the L2 data line 320 is shown as including 2 blocks, 4 banks, and 8 pages, those skilled in the art will appreciate the arrangement of blocks, banks, pages, and lanes having different architectures than the given example. Cache memory is still within the scope of this disclosure. Additionally, L2 cache memory 310 may include a plurality of L2 data lines 320 including, for example, 64, 128, 256, or 512. In addition, each L2 data line 320 may have varying widths including, for example, widths of 128, 256, 512, 1024, or 2048 bits.

Referring now to FIG. 4 , it is a 32BPP (bits per pixel) texture image tile (hereinafter referred to as image tile) of an embodiment. Each page 360 in FIG. 4 is further divided into a number of tiles. As an example, each tile 420 shown in FIG. 4 is 16kB, and each tile 420 is further divided into multiple channels. In the example shown, the image tile 420 includes an 8×8 channel arrangement, a total of 64 channels, numbered Ch 0 to Ch 63. Finally, each channel 430 is further subdivided into individual texels. In the example shown, each channel 430 includes an 8x8 texel arrangement of a total of 64 texels. For the embodiments disclosed herein, the texture tiles in the texture map data are stored in the tiles 420 .

Referring again to FIG. 2, the texture data formatter 218 receives the texture data 106 and organizes the texture in a manner that facilitates more efficient retrieval of the data in the future. The texture data formatter 218 arranges the texture tiles within the texture data such that texture tiles at the same mip level are grouped together. The texture tiles are arranged according to increasing mip levels (ie, decreasing resolution levels). In this way, texture tiles are arranged according to a "texture tile-dominated" format. Furthermore, texture slices of texture data are "squeezed" or compressed within a tile in this way, so that individual texture slices that are smaller than the tile size do not occupy individual tiles and leave unused memory space. Thus, if all texture tiles of a given mip level fit into a single tile, only one tile is used to store all texture tiles of that mip level compressed.

If the texture data is reorganized in a tile-based format and compressed together, parameters associated with each tile within each mip level can be determined by the parameter calculation logic module 220 . These parameters are later used to determine the address of each texture tile within the reordered texture data so that the information can be fetched from the texture cache in the future. The parameter calculation logic module 220 calculates each of the following parameters for all mip levels: all texel sizes, texel width, texel height, texel index number (index, N), first texel (i.e., texel 0) The x and y offsets and the x stride value. The value for the size of all texture tiles is the number of tiles required to store all texture tiles with the same level of detail. In the event that all texture tiles at a given mip level can be "squeezed" or compressed into a single tile, all texture tile size values are set to zero to indicate such a configuration. Once the values of all parameters are calculated, the values are sent to the address calculation logic module 214 . Address calculation logic module 214 receives these values and calculates the addresses of all texture tiles that include texture data so that this data can be fetched from texture cache memory system 116 in the future.

The address calculation logic module 214 calculates the following parameters: the x and y offsets of the remaining texture tiles, the (x, y) coordinates of each texture tile at each mip level, and the image tiles required to store all the texture tiles in the texture map data total number of . Once all texture data has been rearranged and new address information has been determined, the texture data is ready to be stored. The new (x, y) coordinates associated with each mip level and the total number of tiles are sent to the texture cache system 116 . The texture data management unit 114 is coupled to the texture cache system 116 . It should be appreciated that texture data stored in texture cache memory now needs to be compressed and organized in a texture tile-based format in order to reduce access time and ultimately memory latency.

In addition, due to the efficient storage of texture data in memory, the amount of computing resources required to retrieve the data is reduced. It should also be appreciated that because the texture tiles are aligned with the appropriate memory addresses, the address calculation logic required to fetch the data is simplified. Finally, the present invention discloses an alternative volume texture mapping format that can be implemented using the same parameters known by those skilled in the art for volume texture mapping. The format of this alternative texture map format is based on the texture sheet-based format.

5 depicts a flowchart of an embodiment of a method for performing a texture-slice-based compression method for texture-like tile data. In the following steps, various parameters may be determined, which are then used to calculate the address of each texture tile stored in a tile-based tiling format according to certain embodiments. In this way, texture tiles can be efficiently stored to provide more efficient data access. In some embodiments the maximum volumetric texture size may be set to a size of 2k x 2k x 2k. For some embodiments, address computation can be further simplified by setting the maximum number of mip levels to a predetermined number, such as 12. For the following parameters the parameters are calculated for each mip level. For the purposes of the nomenclature used herein, the index number N is used to indicate the number of texture tiles. In addition, the index number d is used to indicate the mip level. As a non-limiting example, Slice[0][d] refers to texture slice[0] at mip level d.

The width and height of the tiles are measured in pixels, and the resolution is measured in terms of BPP (bit per pixel, bits per pixel). For the purposes of the nomenclature used herein, the term BPP is used interchangeably with the term BPE (bit per element). Each BPP value will have a corresponding tile width and tile height. As a non-limiting example, a BPP value (bits/pixel) of 32 corresponds to a tile width (TileWidth) of sixty-four pixels and a tile height (TileHeight) of sixty-four pixels. Table 1 below illustrates the different tile widths and heights for various BPP values:

Table 1 TileWidth and TileHeight values for various BPE values

BPE TileWidth eTW TileHeight eTH 128 32 5 32 5 64 64 6 32 5 32 64 6 64 6 16 128 7 64 6 8 128 7 128 7 4 256 8 128 7 1 512 9 256 8

The parameter eTW in Table 1 corresponds to the number of bits required to represent the TileWidth. For example, 5 bits are required to store a TileWidth value of 32. Likewise, the parameter eTH corresponds to the number of bits required to represent TileHeight. As discussed further below, the parameters eTW and eTH are used for bit-wise operations. It should be noted that for the embodiments disclosed herein, the BPE value will be specific. Based on this value, the corresponding tile width and height can be known.

The method starts at step 510 by grouping texture tiles in a texture map according to mip levels. Next, in step 520, a plurality of texture slices are arranged in the same image tile according to the mode flag. In step 530, parameters about each texel are calculated for each mip level: all texel sizes (expressed in number of tiles), texel width, texel height, and texel index number. A texture tile size of zero means that all texture tiles are smaller than the tile size. In this case, the storage of tile texture data can be further "squeezed" or compressed into a single tile, so that the texture slice does not occupy the entire tile alone, and does not leave unused memory space, so this process is better. If the sum of all texels at a certain mip level is greater than one tile, then those texture tiles are aligned with the tile, and the number of tiles needed to store these texture tiles is calculated. Otherwise, if it is determined that the sum of all texture slices is less than a tile, then the texture width and height values are aligned with powers of two, and the values of all texture slice sizes are set to zero to indicate that multiple Texture slices are stored or "extruded" in a single image tile. The above parameters will be calculated for each mip level, and the number of mip levels will depend on the size of the volume texture map. As a non-limiting example, assuming that the volumetric texture size is set to a size of 2kx2kx2k, the parameters described above are calculated for d=0 to 11, a total of 12 mip levels.

The following parameters are then calculated: the x offset of slice[0] (ie, the first texture slice of each mip level), the y offset of slice[0], and the x stride value. It should be noted that the values of these parameters will depend on which mode is selected. In the embodiment of FIG. 5, two main modes are available for performing texture-slice-based storage of texture-like tile data, as indicated by the mode flags. In the first mode (ie, mode=0), the first texture slice (ie, slice[0]) of each mip level d is not aligned to zero. That is, slice[0] of each mip level is not aligned with the leftmost boundary of the tile storing the texture slice. In the second mode (ie, mode=1), the first texture slice (ie, slice[0]) of each mip level d is aligned to zero. That is, slice[0] at each mip level is aligned with the leftmost edge of the tile storing the texture slice. Referring briefly to FIGS. 6A and 6B, two modes for the embodiment in FIG. 5 are illustrated. As shown in FIG. 6A , the first texture slice of each mip level (ie, slice[0]) within the tile 610 is not aligned with the leftmost border of the tile 610 . This case corresponds to mode 0. In contrast, FIG. 6B shows that the first texture slice of each mip level is aligned with the leftmost border of the tile 620 . This situation corresponds to mode 1. Using more or fewer texture slices should be aware of the number of texture slices and mip levels needed to visually reproduce the object.

Referring again to FIG. 5, the x-step value is calculated depending on which mode (mode 0 or mode 1) is currently being used for texture tile-based storage of texture tile data. If using mode 0, the value of x-stride (represented by XStrideMip[d] below) is calculated using the x offset (represented by XoffsetMipSlice[0][d]) and the tile width, eTW, based on the following relationship:

XStrideMip[d]=(1<<eTW)-XOffsetMipSlice[0][d]; mode 0

The operator "<<" represents a bitwise left shift operation. If using mode 1 (that is, where slice[0] of each mip level is aligned with the leftmost border of the tile), the value XStrideMip[d] is only equal to the value of the tile width (TileWidth) (see Table 1 above middle).

The parameter XOffsetMipSlice[0][d] indicates the offset in the X direction of the first texture slice (that is, slice[0]) of a certain mip level d. In addition, the value YOffsetMipSlice[0][d] represents the offset in the Y direction of slice[0] of a certain mip level d. In the case of mode 1 where slice[0] (the first texture slice) at each mip level is aligned to the leftmost boundary of the pixel tile, the x-offset value is set to zero; otherwise, the previously Calculate the x-step value to calculate the x-offset value. Additionally, if the value of xoffset is not a power of two texels, the value is rounded to the nearest power of two value. For the value of x offset, XOffsetMipSlice[0][d] is then calculated based on the following relationship:

For mode 1, XOffsetMipSlice[0][d]=0

For mode 0, XOffsetMipSlice[0][d] =

XOffsetMipSlice[0][d]-1+(N[d-1]<<ew[d-1])&((1<<eXStrideMip[d]-1)-1)

The value YOffsetMipSlice[d] is also calculated considering whether the alignment mode is mode 0 or mode 1 . If mode 1 is used, the value YOffsetMipSlice[d] is determined by the following relation:

For mode 1, YOffsetMipSlice[0][d]=

YOffsetMipSlice[0][d-1]+(((N[d-1]<<ew[d-1])+(1<<eTW)-1)>>eTW)<<eh[d-1]

For mode 0, YOffsetMipSlice[0][d] =

YOffsetMipSlice[0][d]=YOffsetMipSlice[0][d-1]+(n[d-1]<<(ew[d-1]+eh[d-1]-eXStrideMip[d-1]))

In step 540, the memory address of each texture tile within the texture map is calculated based on the parameters calculated above. The offset for each texture tile N of a certain mip level is then calculated for the x and y directions. As discussed above, the parameter XOffsetMipSlice[N] indicates the offset in the X direction of texture slice N of a certain mip level. In addition, the value YOffsetMipSlice[N] is the offset in the Y direction of the texture slice N of a certain mip level. These offsets are used to calculate new (x,y) coordinates for each texture tile. The x- and y-direction offsets of slice[0] at each mip level are aligned to memory addresses zero or powers of two. For an embodiment where the offset in the x direction is zero, slice[0] (of each mip level) will always be aligned with the left border of the tile. Also, the x-step value will be equal to the tile width like TileWidth. Finally, it should be noted that if multiple texture tiles are smaller in size than one tile, they are "squeezed" or compressed into a single tile so that each texture tile does not each occupy the entire tile. Compression is performed in a tile-major fashion, where texture tiles with the same mip-level value are grouped together. Finally, in step 550, the rearranged texture tiles are stored in texture cache for future fetches.

Referring to Figure 6A, which illustrates different parameters used to calculate the address of each texture tile at different mip levels. The offset of slice[0] for each mip level may be aligned with zero or with an address value that is a power of two. Specifically, two different modes can be indicated for storage purposes. Mode 0 may be used to indicate that slice[0] of each mip level is not aligned with zero (ie, not aligned with the leftmost border of the tile).

Referring now to FIG. 7 , an embodiment for storing volumetric texture maps in a texture tile-based format within a texture cache is depicted. As shown, texture tiles are stored in a tile-major format, where texture tiles at the same mip level are stored together in a contiguous manner. It should also be appreciated that texture tiles are "squeezed" or compressed together so that individual texture tiles that are smaller than a tile do not take up an entire tile, leaving wasted memory space. As depicted in FIG. 7, texture tiles are also stored in consecutive pages within the texture cache (page N through page (N+2)). As discussed earlier, it is often beneficial to store texture tiles at the same mip level close together in memory, texture tiles may preferably be stored in the same cache page and even within the same cache line ( If possible), this speeds up data access and ultimately leads to a reduction in memory latency.

Figure 8 depicts a flowchart of another embodiment of a method for performing texture tile-based compression of brick-like texture data. The method starts at step 810, rearranging the texture tiles in the texture map data according to the texture tile-based format. Next, in step 820, if the sum of the sizes of all the texture tiles with the same level of detail is smaller than the size of a tile, store the texture tiles with the same level of detail in a tile. In step 830, parameters for each texture tile are calculated. A new memory address for each texture tile within the texture map data is then calculated in step 840 according to the parameters calculated in step 830 . Finally, in step 850, the rearranged texture tile is stored in the texture cache along with the new memory address.

As those skilled in the art can understand, any processing description or steps in the flowchart should be understood as representing logic, program code segments or parts including one or more executable instructions implementing specific logical functions, and alternative embodiments It is within the scope of preferred embodiments of the present invention wherein, depending on the functionality involved, functions may be performed in an order different from that shown or discussed (including substantially concurrent or reverse order execution).

Furthermore, it should be emphasized that the embodiments described above are only examples of possible embodiments. Many changes and modifications may be made to the above-described embodiments without departing from the principles of the invention. All such modifications and variations are intended to be included herein within the scope of this invention and protected by the following claims.

For example, based on the description provided by the present invention, those skilled in the art should understand that the embodiment includes a graphics processing unit, and the graphics processing unit includes a texture management unit, and the texture management unit is used to organize the texture map according to the texture sheet-based format data, where the texture map data spans at least one mip level. In addition, the graphics processing system includes a texture cache memory, wherein the texture cache memory is coupled to the texture management unit, and used for receiving reorganized texture map data from the texture management unit.

In some embodiments, the graphics processing unit further includes a texture data formatter, which arranges texture slices in the texture map data according to a texture slice-based format; a parameter calculation logic module, which is used for each a texture slice calculation parameter; and an address calculation logic module, which is used for determining the cache memory address of each texture slice in the texture map data by using the calculated parameter.

In other embodiments, the texture data formatter can further be used to store multiple texture tiles in the same tile if the texture tile is smaller than a tile. In other embodiments, the texture data formatter may arrange the texture tiles within the texture map data according to mode 0 or mode 1, where mode 0 indicates that the first texture tile at each mip level is the leftmost of the tile storing the texture tile Boundary aligned, and where mode 1 indicates that the first texture tile of each mip level is not aligned with the leftmost boundary of the tile storing the texture tile.

In other embodiments, the parameters include texel size in terms of number of tiles, texel width, texel height, and texel index per texel. For some embodiments, the parameters further include the x offset of tile 0, which indicates the address offset in the x direction of the first texture tile of each mip level; the y offset of texture tile 0, which indicates the address offset of each mip level the offset in the y-direction of the first texel at the mip level; and the x-stride value, which indicates the total width of each set of texels at each mip level. For some embodiments, parameters are computed for each mip level. For some embodiments, if mode is 1, the x-offset of the first texture tile is set to 0. For some embodiments, if mode is 0, the x-offset of the first texture tile is rounded to a power of two. For some embodiments, the cache address for each texture tile within the texture map data includes a new value x indicating the x-coordinate of each texture tile; a new value y indicating the y-coordinate of each texture tile; and Image brick index number, which indicates the total number of image bricks required to store all texture tiles in the texture map data.

According to other embodiments of the present invention, a method for storing texture map data in a graphics processor is provided, and the method can be roughly summarized by the following steps: group texture tiles of texture map data together according to mip level; arranging a plurality of texture tiles in the same tile; calculating parameters about each texture tile of each mip level; calculating a memory address of each texture tile in the texture map data according to the calculated parameters; and rearranging The texture slices are stored in the texture cache memory.

In some embodiments, arranging the texture tiles further includes aligning the first texture tile of each mip level along the leftmost border of the tile storing the texture tiles when the mode flag is set to 1. For some embodiments, the arrangement of texture tiles further includes aligning the first mip level of each mip level along the rightmost border of the last texture tile in the next lower mip level when the mode flag is set to 0. textured slices. In one embodiment, calculating parameters includes calculating texture width; calculating texture height; calculating the texture slice size of each tile; calculating the texture slice index number of each texture slice; the address offset in the x direction of the first texture tile of a mip level; calculate the y offset of texture tile 0, which indicates the address offset in the y direction of the first texture tile of each mip level; and calculate The x-stride value that indicates the total width of each set of texture tiles at each mip level. For some embodiments, computing the memory address of each texture tile within the texture map data includes computing a new value x indicating an x-coordinate of each texture tile; computing a new value y indicating a y-coordinate of each texture tile; And calculating a tile index indicating the total number of tiles required to store all texture tiles within the texture map data.

According to other embodiments of the present invention, a method for storing texture map data in a graphics processor is provided, and the method can be roughly summarized by the following steps: rearranging the texture slices of the texture map data in a texture slice-based format, The texture slices with the same level of detail can be grouped together; if the sum of all texture slices with the same level of detail is less than the size of a tile, then the texture slices with the same level of detail are stored in a tile; for each calculating a parameter for each texture tile at the level of detail; calculating a new memory address for each texture tile within the texture map data according to the calculated parameter; and storing the rearranged texture tile and the new memory address in a texture cache .

For some embodiments, computing the parameters for each texture tile includes computing the number of tiles required to store all texture tiles with the same level of detail; computing the size of the texture; computing the texture tile index number for each texture tile; computing the texture The x offset of slice 0, which indicates the address offset in the x direction of the first texture slice of each level of detail; the y offset of texture slice 0, which indicates the address offset of the first texture slice of each level of detail at an address offset in the y direction; and calculating an x stride value indicating the total width of each set of texture tiles for each level of detail. For some embodiments, storing texture tiles with the same level of detail within a tile further includes aligning the first texture tile of each level of detail along the rightmost border of the tile. For some embodiments, storing texture tiles with the same level of detail in a tile further includes aligning the first texture tile for each detail level immediately after the last texture tile for the next lower detail level. For some embodiments, calculating the new memory address includes calculating the (x,y) coordinates for each rearranged texture tile for each mip level and calculating the total number of tiles required to store all the texture tiles within the texture map data.

A brief description of the symbols in the drawings is as follows:

100: Computer Systems

102: CPU

104: System memory

106: Texture data

108: System interface

110: Graphics processing system

112: Front-end processor

114: Texture data management unit

116: Texture cache system

118: Texture Filter

120: frame buffer

130: display device

210: Computer Graphics Systems

212: texture data management unit

Claims (12)

1. graphic system is characterized in that it comprises:

The texture administrative unit, in order to the format organization texture maps data of basis based on texture tile, wherein said texture maps data are crossed at least one mip grade; And

The texture quick access to memory, wherein said texture quick access to memory is coupled to described texture administrative unit, and in order to receive the described texture maps data behind tissue from described texture administrative unit;

Wherein said texture administrative unit comprises:

The data texturing formatter, in order to according to based on the texture tile in the described texture maps data of the format permutation of texture tile, the texture tile that wherein has identical mip grade is grouped and is stored in together, if have identical mip grade all described texture tile summation less than one the picture brick size, the described texture tile that then will have described identical mip grade is stored in the described picture brick;

The calculation of parameter logic module is in order to calculate the parameter of each texture tile in the described texture maps data; And

The address calculation logic module is calculated the memory cache address of each texture tile in the described texture maps data in order to use described parameter.

2. graphic system according to claim 1 is characterized in that, described data texturing formatter is arranged texture tile in the described texture maps data according to a pattern 0 or a pattern 1,

First texture tile of wherein said pattern 0 each described mip grade of expression is aimed at the leftmost border of the described picture brick that stores described texture tile; And

Described first texture tile of wherein said pattern 1 each described mip grade of expression is not aimed at the described leftmost border of the described picture brick that stores described texture tile.

3. graphic system according to claim 1 is characterized in that, described parameter comprises:

The texture tile size of calculating with the number of described picture brick;

The texture width;

The texture height;

The texture tile index number of described each texture tile;

The x skew of texture tile 0, it indicates the address offset of first texture tile on the x direction of each described mip grade;

The y skew of texture tile 0, it indicates the address offset of described first texture tile on the y direction of each described mip grade; And

The x value of striding, it indicates the overall width of each set of the texture tile of each described mip grade;

Wherein said parameter is calculated at each described mip grade.

4. graphic system according to claim 1 is characterized in that, the described memory cache address of each texture tile in the described texture maps data comprises:

New value x, the x coordinate of described each texture tile of its indication;

New value y, the y coordinate of described each texture tile of its indication; And

Picture brick index number, its indication store the required total number as brick of all described texture tile in the described texture maps data.

5. the method for a storing texture diagram data in graphic process unit is characterized in that it comprises:

According to the texture tile grouping of mip grade with the texture maps data, the texture tile that wherein has identical mip grade is grouped and is stored in together;

If the summation of the size of a plurality of described texture tile then is arranged in a plurality of described texture tile in the described picture brick according to mode flags less than a picture brick;

Parameter at each each described texture tile of mip rating calculation;

Storage address according to each texture tile in the described texture maps data of described calculation of parameter; And

To be stored in the texture quick access to memory through the described texture tile after arranging.

6. according to claim 5 in graphic process unit the method for storing texture diagram data, it is characterized in that, arrange texture tile and more be included in described mode flags and be set under 1 the situation, aim at first texture tile of each mip grade along the leftmost border of the described picture brick that stores described texture tile; Be set in described mode flags under 0 the situation, along first texture tile of accurate each the mip grade of rightmost bound pair of the last texture tile in next low mip grade.

7. according to claim 5 in graphic process unit the method for storing texture diagram data, it is characterized in that calculating parameter comprises:

Calculate the texture width;

Calculate the texture height;

Calculating texture tile size, the value of described texture tile size is the number of the required picture brick of all texture tile that store described each mip grade;

Calculate the texture tile index number of each texture tile;

Calculate the x skew of texture tile 0, it indicates the address offset of first texture tile on the x direction of each mip grade;

Calculate the y skew of texture tile 0, it indicates the address offset of described first texture tile on the y direction of each mip grade; And

Calculate the x value of striding, it indicates the overall width of each set of the texture tile of each mip grade.

8. according to claim 5 in graphic process unit the method for storing texture diagram data, it is characterized in that the storage address of calculating each texture tile in the described texture maps data comprises:

Calculate new value x, it indicates the x coordinate of each texture tile;

Calculate new value y, it indicates the y coordinate of each texture tile; And

Calculating is as the brick index number, and its indication stores the required total number as brick of all described texture tile in the described texture maps data.

9. the method for a storing texture diagram data in graphic process unit is characterized in that it comprises:

According to based on the texture tile in the format permutation texture maps data of texture tile, the texture tile that wherein has the same detail grade is grouped and is stored in together;

If have described same detail grade all described texture tile summation less than one the picture brick size, the described texture tile that then will have described same detail grade is stored in the described picture brick;

Calculating is about the parameter of each texture tile, and wherein said parameter is to calculate at each detail grade;

New memory address according to each texture tile in the described texture maps data of described calculation of parameter; And

Described texture tile and new memory address through arranging are stored in the texture quick access to memory.

10. according to claim 9 in graphic process unit the method for storing texture diagram data, it is characterized in that the parameter of calculating about each texture tile comprises:

Calculate and store the required number of all texture tile as brick with described same detail grade;

Calculate the size of described texture maps data;

Calculate the texture tile index number of each texture tile;

Calculate the x skew of texture tile 0, it indicates the address offset of first texture tile on the x direction of each detail grade;

Calculate the y skew of texture tile 0, it indicates the address offset of described first texture tile on the y direction of each detail grade; And

Calculate the x value of striding, it indicates the overall width of each set of the texture tile of each detail grade.

11. according to claim 9 in graphic process unit the method for storing texture diagram data, it is characterized in that, the described texture tile that will have a described same detail grade be stored in described as more comprise in the brick following manner one of them:

First texture tile along accurate each detail grade of the rightmost bound pair of described picture brick; And

Aim at first texture tile of each detail grade, so that described first texture tile is immediately following after the last texture tile of next low detail grade.

12. according to claim 9 in graphic process unit the method for storing texture diagram data, it is characterized in that, calculate the new memory address and comprise:

Calculate x, the y coordinate of each texture tile of each mip grade through arranging; And

Calculate the required total number of all described texture tile that stores in the described texture maps data as brick.

Images