Memory interleaving technique for texture mapping in a graphics system

[0001] 1. Field of the Invention

[0002] This invention relates generally to the field of computer graphics and, more particularly, to a high performance graphics system which implements texture mapping.

[0003] 2. Description of the Related Art

[0004] A computer system typically relies upon its graphics system for producing visual output on the computer screen or display device. Early graphics systems were only responsible for taking what the processor produced as output and displaying that output on the screen. In essence, they acted as simple translators or interfaces. Modem graphics systems, however, incorporate graphics processors with a great deal of processing power. They now act more like coprocessors rather than simple translators. This change is due to the recent increase in both the complexity and amount of data being sent to the display device. For example, modem computer displays have many more pixels, greater color depth, and are able to display images that are more complex with higher refresh rates than earlier models. Similarly, the images displayed are now more complex and may involve advanced techniques such as anti-aliasing and texture mapping.

[0005] As a result, without considerable processing power in the graphics system, the CPU would spend a great deal of time performing graphics calculations. This could rob the computer system of the processing power needed for performing other tasks associated with program execution and thereby dramatically reduce overall system performance. With a powerful graphics system, however, when the CPU is instructed to draw a box on the screen, the CPU is freed from having to compute the position and color of each pixel. Instead, the CPU may send a request to the video card stating: draw a box at these coordinates. The graphics system then draws the box, freeing the processor to perform other tasks.

[0006] Generally, a graphics system in a computer (also referred to as a graphics system) is a type of video adapter that contains its own processor to boost performance levels. These processors are specialized for computing graphical transformations, so they tend to achieve better results than the general-purpose CPU used by the computer system. In addition, they free up the computer's CPU to execute other commands while the graphics system is handling graphics computations. The popularity of graphical applications, and especially multimedia applications, has made high performance graphics systems a common feature of computer systems. Most computer manufacturers now bundle a high performance graphics system with their systems.

[0007] Since graphics systems typically perform only a limited set of functions, they may be customized and therefore far more efficient at graphics operations than the computer's general-purpose central processor. While early graphics systems were limited to performing two-dimensional (2D) graphics, their functionality has increased to support three-dimensional (3D) wire-frame graphics, 3D solids, and now includes support for three-dimensional (3D) graphics with textures and special effects such as advanced shading, fogging, alpha-blending, and specular highlighting.

[0008] While the number of pixels is an important factor in determining graphics system performance, another factor of equal import is the quality of the image. Various methods are used to improve the quality of images, including anti-aliasing, alpha blending, and fogging, among numerous others. While various techniques may be used to improve the appearance of computer graphics images, they also have certain limitations. In particular, they may introduce their own aberrations and are typically limited by the density of pixels displayed on the display device.

[0009] As a result, a graphics system is desired which is capable of utilizing increased performance levels to increase not only the number of pixels rendered but also the quality of the image rendered. In addition, a graphics system is desired which is capable of utilizing increases in processing power to improve graphics effects.

[0010] Therefore, a graphics system may be configured to receive a stream of vertices from a host application executing on a host computer. The vertices specify triangles in a 3D coordinate space. The triangles represent a collection of 3D objects in the 3D world coordinate space. The graphics system may operate on the triangles to generate a video stream which represents the view of a virtual camera (or virtual observer) in the 3D world coordinate space. In particular, the graphics system may compute color values for each pixel that resides within each triangle (i.e. the two-dimensional footprint of the triangle in screen space). This process of assigning color values to pixels (or samples) internal to triangles may be referred to herein as triangle rasterization.

[0011] To obtain images that are more realistic, some prior art graphics systems have implemented a process referred to as texture mapping. Thus, triangle rasterization may include the application of one or more textures. In other words, graphics system may store one or more texture maps in a texture memory and may modify the color of pixels using the one or more texture maps. For example, pixels residing internal to a given triangle comprising part of a wall may be textured with a texture map, e.g., a texture map which gives the triangle the appearance of brick material.

[0012] In a graphics application, accesses of graphics data, such as texture map data, must be performed very quickly. Therefore, one goal of a graphics system is to improve the speed and efficiency of memory accesses of texture maps from a texture memory. One common method is to use a texture memory cache to improve the speed of accesses of texture maps from the texture memory. In general, accesses to texture maps exhibit considerable spatial locality. However, reliance on cache memories and caching techniques to take advantage of this spatial locality often results in fetching more data from memory than is required. This wastes memory bandwidth. In addition, in many instances the requested array of texels cannot be accessed from the texture buffer in a single read transaction. This results in access latencies which adversely affect system performance.

[0013] Therefore, an improved system and method is desired for optimally storing texture maps in a multi-memory system to guarantee access to all of the data in a single read transaction and/or with reduced or no over-fetching.

[0014] One embodiment of the invention comprises a graphics system and method for storing and accessing texture maps. The graphics system may include a plurality of memory devices for storing the texture maps. A graphics processor may couple to the plurality of memory devices to store texture maps in the memory devices and/or access texture maps from the memory devices.

[0015] In one embodiment, a texture map comprises a plurality of texels, wherein an NM array of texels corresponds to each pixel. For example, each NM array of texels may comprise a 22 array of texels. Neighboring pixels may share one or more texels. In other words, for two neighboring pixels, their respective NM arrays of texels may include one or more common texels. Where a 22 array of texels corresponds to each pixel, then in one embodiment neighboring pixels share at least two texels.

[0016] At least portions of the texels may be stored in respective ones of the plurality of memory devices, wherein neighboring (or spatially adjacent) texels are stored in separate ones of the memory devices in an interleaved fashion. Due to the interleaved nature of the storage of the texels, for each of the plurality of pixels, the plurality of memory devices are operable to output a respective NM array of texels for a respective pixel in parallel in a single read transaction. In other words, the texel data is interleaved in the plurality of memory devices to guarantee that, no matter which NM array of texels is accessed, each texel in the array is present in a different memory device or chip and hence are concurrently available. Thus the NM array of texels may be output concurrently or simultaneously, regardless of which array is accessed, i.e., regardless of which pixel is addressed. The NM array of texels may also be provided without over-fetching of non-requested texels.

[0017] When a read transaction is generated for an NM array of texels for a respective pixel, the plurality of memory devices output the NM array of texels for the respective pixel in parallel (concurrently) in a single cycle in response to the read transaction. Where the texels are addressed using a U,V addressing scheme, the texels in each 22 array of texels may have addresses U, V; U1, V; U, V1; and U1, V1. In other words, for any U,V address, a requesting device, such as the graphics processor, can access any NM array of texels having addresses U,V; U1, V; U, V1; and U1, V1. The plurality of memory devices are operable to output a respective NM array of texels having addresses U,V; U1, V; U, V1; and U1, V1; for a respective pixel in parallel in a single read transaction.

[0018] In one embodiment, each texel comprises a first portion and a second portion, e.g., a first half and a second half. The first and second portions of a respective texel may be stored in separate memory devices comprising a pair of memory devices to allow the respective texel to be output from the pair of memory devices in a single read transaction. In other words, the plurality of memory devices may comprise a plurality of pairs of memory devices, wherein each of the pairs of memory devices comprises a first memory device and a second memory device, and wherein each pair of memory devices is independently addressable. A first portion of each texel may be stored in a first memory device of a pair of memory devices and a second portion of each texel may be stored in a second memory device of the pair of memory devices. Each respective pair of memory devices may be operable to output a texel in response to the respective pair of memory devices receiving a single address.

[0019] For example, in a first embodiment, where each NM array of texels comprises a 22 array of texels, each texel is 32 bits, the plurality of memory devices comprise 8 memory devices, and the memory devices are 16 bit memories, then each of the memory devices stores 16 bits (one half) of a respective texel. Thus, 16 bits of each texel may be stored in one memory device of a pair, and the other 16 bits may be stored in another memory device of the pair. A texel may be stored in and accessed from a respective memory device pair as described above.

[0020] In a second embodiment, for each of the plurality of pixels, the plurality of memory devices are operable to output a respective NM array of texels for at least two respective neighboring pixels in parallel in response to a single read transaction. For example, in one exemplary embodiment, where each NM array of texels comprises a 22 array of texels, each texel is 16 bits, the plurality of memory devices comprise 8 memory devices, and the memory devices are 16 bit memories, then each of the memory devices stores a respective 16 bit texel. In this exemplary embodiment, for each of the plurality of pixels, the plurality of memory devices are operable to output a respective 22 array of texels for each of two respective neighboring pixels in parallel in a single read transaction.

[0021] In a third embodiment, where each texture map is a 3-D texture map, an NMO array (3-D array) of texels corresponds to each pixel. In this embodiment, for each of the plurality of pixels, the plurality of memory devices are operable to output a respective NMO array of texels for a respective pixel in parallel in a single read transaction. For example, in one exemplary embodiment, where each texture map is a 3-D texture map, a 222 array of texels corresponds to each pixel, each texel is 16 bits, the plurality of memory devices comprise 8 memory devices, and the memory devices are 16 bit memories, then each of the memory devices stores a respective 16 bit texel. In this exemplary embodiment, for each of the plurality of pixels, the plurality of memory devices are operable to output a respective 222 array of texels for a respective pixel in parallel in a single read transaction.

[0022] In one embodiment, each texture map comprises a body portion and a border portion. The body portion of the texture map (without borders) may have a size that is a power of 2 in each dimension. Thus, for a 2D texture map, the width and height of the texture map is a power of 2 in size. For a 3D texture map, the width, height, and length of the texture map is a power of 2 in size. Since memory pages are a power of 2 in size, the body portion of the texture map may be efficiently stored in memory. The border portion of the texture map may be a 1 texel-wide strip around the body portion of the texture map. Since the body portion of the texture map is a power of 2 in size, the body portion plus the border portion is not a power of 2 in size. Thus, storage of the body and border portions of the texture map would be inefficient.

[0023] In one embodiment of the invention, the body and border portions of the texture map are stored in separate areas of memory (e.g., in different memory address spaces). However, the texel interleaving described above is preserved, whereby neighboring texels in the body and border portions may be stored in separate ones of the memory devices in an interleaved fashion. Thus, for respective pixels which include texels from both the body portion and border portion of the texture map, the plurality of memory devices are operable to output a respective NM array of texels for the respective pixel in parallel in a single read transaction. In other words, the texel data is interleaved in the plurality of memory devices to guarantee that, no matter which NM array of texels is accessed, (even if the array requires some body texels and some border texels), each texel in the array is present in a different memory device or chip and hence all of the texels in the array are concurrently available. The upper address bits of texels in the border portion may not be interleaved to allow for efficient packing.

[0024] The foregoing, as well as other objects, features, and advantages of this invention may be more completely understood by reference to the following detailed description when read together with the accompanying drawings in which:

[0025] FIG. 1 is a perspective view of one embodiment of a computer system;

[0026] FIG. 2 is a simplified block diagram of one embodiment of a computer system;

[0027] FIG. 3 is a functional block diagram of one embodiment of a graphics system;

[0028] FIG. 4 is a functional block diagram of one embodiment of the media processor of FIG. 3;

[0029] FIG. 5 is a functional block diagram of one embodiment of the hardware accelerator of FIG. 3;

[0030] FIG. 6 is a functional block diagram of one embodiment of the video output processor of FIG. 3;

[0031] FIG. 7 illustrates rendering of samples in a polygon;

[0032] FIG. 8 illustrates a graphics processor coupled to a plurality of memory devices, wherein the memory devices store texture maps;

[0033] FIG. 9 illustrates memory interleaving using various types of texture address scrambling patterns;

[0034] FIG. 10 illustrates an alternative representation of memory interleaving in 64 bit 2D;

[0035] FIG. 11 illustrates memory interleaving of borders with the body of the texture;

[0036] FIG. 12 illustrates the manner in which edge borders are stored for 2D textures;

[0037] FIG. 13 illustrates low order bit scrambling for body address scrambling;

[0038] FIG. 14 illustrates high order bit scrambling for body address scrambling;

[0039] FIG. 15 illustrates SDRAM bank scrambling; and

[0040] FIG. 16 illustrates border SDRAM scrambling.

[0041] While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present invention as defined by the appended claims. Note, the headings are for organizational purposes only and are not meant to be used to limit or interpret the description or claims. Furthermore, note that the word may is used throughout this application in a permissive sense (i.e., having the potential to, being able to), not a mandatory sense (i.e., must). The term include, and derivations thereof, mean including, but not limited to. The term connected means directly or indirectly connected, and the term coupled means directly or indirectly connected.

[0042] Incorporation by Reference

[0043] U.S. Pat. No. 6,246,422 titled Efficient Method for Storing Texture Maps in Multi-Bank Memory issued on Jun. 12, 2001, whose inventors are Brian Emberling and Michael G. Lavelle, is hereby incorporated by reference in its entirety as though fully and completely set forth herein.

[0044] Computer SystemFIG. 1

[0045] FIG. 1 illustrates one embodiment of a computer system 80 that includes a graphics system. The graphics system may be included in any of various systems such as computer systems, network PCs, Internet appliances, televisions (e.g. HDTV systems and interactive television systems), personal digital assistants (PDAs), virtual reality systems, and other devices which display 2D and/or 3D graphics, among others.

[0046] As shown, the computer system 80 includes a system unit 82 and a video monitor or display device 84 coupled to the system unit 82. The display device 84 may be any of various types of display monitors or devices (e.g., a CRT, LCD, or gas-plasma display). Various input devices may be connected to the computer system, including a keyboard 86 and/or a mouse 88, or other input device (e.g., a trackball, digitizer, tablet, six-degree of freedom input device, head tracker, eye tracker, data glove, or body sensors). Application software may be executed by the computer system 80 to display graphical objects on display device 84.

[0047] Computer System Block DiagramFIG. 2

[0048] FIG. 2 is a simplified block diagram illustrating the computer system of FIG. 1. As shown, the computer system 80 includes a central processing unit (CPU) 102 coupled to a high-speed memory bus or system bus 104 also referred to as the host bus 104. A system memory 106 (also referred to herein as main memory) may also be coupled to high-speed bus 104.

[0049] Host processor 102 may include one or more processors of varying types, e.g., microprocessors, multi-processors and CPUs. The system memory 106 may include any combination of different types of memory subsystems such as random access memories (e.g., static random access memories or SRAMs, synchronous dynamic random access memories or SDRAMs, and Rambus dynamic random access memories or RDRAMs, among others), read-only memories, and mass storage devices. The system bus or host bus 104 may include one or more communication or host computer buses (for communication between host processors, CPUs, and memory subsystems) as well as specialized subsystem buses.

[0050] In FIG. 2, a graphics system 112 is coupled to the high-speed memory bus 104. The graphics system 112 may be coupled to the bus 104 by, for example, a crossbar switch or other bus connectivity logic. It is assumed that various other peripheral devices, or other buses, may be connected to the high-speed memory bus 104. It is noted that the graphics system 112 may be coupled to one or more of the buses in computer system 80 and/or may be coupled to various types of buses. In addition, the graphics system 112 may be coupled to a communication port and thereby directly receive graphics data from an external source, e.g., the Internet or a network. As shown in the figure, one or more display devices 84 may be connected to the graphics system 112.

[0051] Host CPU 102 may transfer information to and from the graphics system 112 according to a programmed input/output (I/O) protocol over host bus 104. Alternately, graphics system 112 may access system memory 106 according to a direct memory access (DMA) protocol or through intelligent bus mastering.

[0052] A graphics application program conforming to an application programming interface (API) such as OpenGL or Java 3D may execute on host CPU 102 and generate commands and graphics data that define geometric primitives such as polygons for output on display device 84. Host processor 102 may transfer the graphics data to system memory 106. Thereafter, the host processor 102 may operate to transfer the graphics data to the graphics system 112 over the host bus 104. In another embodiment, the graphics system 112 may read in geometry data arrays over the host bus 104 using DMA access cycles. In yet another embodiment, the graphics system 112 may be coupled to the system memory 106 through a direct port, such as the Advanced Graphics Port (AGP) promulgated by Intel Corporation.

[0053] The graphics system may receive graphics data from any of various sources, including host CPU 102 and/or system memory 106, other memory, or from an external source such as a network (e.g. the Internet), or from a broadcast medium, e.g., television, or from other sources.

[0054] Note while graphics system 112 is depicted as part of computer system 80, graphics system 112 may also be configured as a stand-alone device (e.g., with its own built-in display). Graphics system 112 may also be configured as a single chip device or as part of a system-on-a-chip or a multi-chip module. Additionally, in some embodiments, certain of the processing operations performed by elements of the illustrated graphics system 112 may be implemented in software.

[0055] Graphics SystemFIG. 3

[0056] FIG. 3 is a functional block diagram illustrating one embodiment of graphics system 112. Note that many other embodiments of graphics system 112 are possible and contemplated. Graphics system 112 may include one or more media processors 14, one or more hardware accelerators 18, one or more texture buffers 20, one or more frame buffers 22, and one or more video output processors 24. Graphics system 112 may also include one or more output devices such as digital-to-analog converters (DACs) 26, video encoders 28, flat-panel-display drivers (not shown), and/or video projectors (not shown). Media processor 14 and/or hardware accelerator 18 may include any suitable type of high performance processor (e.g., specialized graphics processors or calculation units, multimedia processors, DSPS, or general purpose processors).

[0057] In some embodiments, one or more of these components may be removed. For example, the texture buffer may not be included in an embodiment that does not provide texture mapping. In other embodiments, all or part of the functionality incorporated in either or both of the media processor or the hardware accelerator may be implemented in software.

[0058] In one set of embodiments, media processor 14 is one integrated circuit and hardware accelerator is another integrated circuit. In other embodiments, media processor 14 and hardware accelerator 18 may be incorporated within the same integrated circuit. In some embodiments, portions of media processor 14 and/or hardware accelerator 18 may be included in separate integrated circuits.

[0059] As shown, graphics system 112 may include an interface to a host bus such as host bus 104 in FIG. 2 to enable graphics system 112 to communicate with a host system such as computer system 80. More particularly, host bus 104 may allow a host processor to send commands to the graphics system 112. In one embodiment, host bus 104 may be a bi-directional bus.

[0060] Media ProcessorFIG. 4

[0061] FIG. 4 shows one embodiment of media processor 14. As shown, media processor 14 may operate as the interface between graphics system 112 and computer system 80 by controlling the transfer of data between computer system 80 and graphics system 112. In some embodiments, media processor 14 may also be configured to perform transformations, lighting, and/or other general-purpose processing operations on graphics data.

[0062] Transformation refers to the spatial manipulation of objects (or portions of objects) and includes translation, scaling (e.g. stretching or shrinking), rotation, reflection, or combinations thereof. More generally, transformation may include linear mappinga (e.g. matrix multiplications), nonlinear mappings, and combinations thereof.

[0063] Lighting refers to calculating the illumination of the objects within the displayed image to determine what color values and/or brightness values each individual object will have. Depending upon the shading algorithm being used (e.g., constant, Gourand, or Phong), lighting may be evaluated at a number of different spatial locations.

[0064] As illustrated, media processor 14 may be configured to receive graphics data via host interface 11. A graphics queue 148 may be included in media processor 14 to buffer a stream of data received via the accelerated port of host interface 11. The received graphics data may include one or more graphics primitives. As used herein, the term graphics primitive may include polygons, parametric surfaces, splines, NURBS (non-uniform rational B-splines), sub-divisions surfaces, fractals, volume primitives, voxels (i.e., three-dimensional pixels), and particle systems. In one embodiment, media processor 14 may also include a geometry data preprocessor 150 and one or more microprocessor units (MPUs) 152. MPUs 152 may be configured to perform vertex transformation, lighting calculations and other programmable functions, and to send the results to hardware accelerator 18. MPUs 152 may also have read/write access to texels (i.e. the smallest addressable unit of a texture map) and pixels in the hardware accelerator 18. Geometry data preprocessor 150 may be configured to decompress geometry, to convert and format vertex data, to dispatch vertices and instructions to the MPUs 152, and to send vertex and attribute tags or register data to hardware accelerator 18.

[0065] As shown, media processor 14 may have other possible interfaces, including an interface to one or more memories. For example, as shown, media processor 14 may include direct Rambus interface 156 to a direct Rambus DRAM (DRDRAM) 16. A memory such as DRDRAM 16 may be used for program and/or data storage for MPUs 152. DRDRAM 16 may also be used to store display lists and/or vertex texture maps.

[0066] Media processor 14 may also include interfaces to other functional components of graphics system 112. For example, media processor 14 may have an interface to another specialized processor such as hardware accelerator 18. In the illustrated embodiment, controller 160 includes an accelerated port path that allows media processor 14 to control hardware accelerator 18. Media processor 14 may also include a direct interface such as bus interface unit (BIU) 154. Bus interface unit 154 provides a path to memory 16 and a path to hardware accelerator 18 and video output processor 24 via controller 160.

[0067] Hardware AcceleratorFIG. 5

[0068] One or more hardware accelerators 18 may be configured to receive graphics instructions and data from media processor 14 and to perform a number of functions on the received data according to the received instructions. For example, hardware accelerator 18 may be configured to perform rasterization, 2D and/or 3D texturing, pixel transfers, imaging, fragment processing, clipping, depth cueing, transparency processing, set-up, and/or screen space rendering of various graphics primitives occurring within the graphics data.

[0069] Clipping refers to the elimination of graphics primitives or portions of graphics primitives that lie outside of a 3D view volume in world space. The 3D view volume may represent that portion of world space that is visible to a virtual observer (or virtual camera) situated in world space. For example, the view volume may be a solid truncated pyramid generated by a 2D view window, a viewpoint located in world space, a front clipping plane and a back clipping plane. The viewpoint may represent the world space location of the virtual observer. In most cases, primitives or portions of primitives that lie outside the 3D view volume are not currently visible and may be eliminated from further processing. Primitives or portions of primitives that lie inside the 3D view volume are candidates for projection onto the 2D view window.

[0070] Set-up refers to mapping primitives to a three-dimensional viewport. This involves translating and transforming the objects from their original world-coordinate system to the established viewport's coordinates. This creates the correct perspective for three-dimensional objects displayed on the screen.

[0071] Screen-space rendering refers to the calculations performed to generate the data used to form each pixel that will be displayed. For example, hardware accelerator 18 may calculate samples. Samples may comprise points that have color information but no real area. Samples allow hardware accelerator 18 to super-sample, or calculate more than one sample per pixel. Super-sampling may result in a higher quality image.

[0072] Hardware accelerator 18 may also include several interfaces. For example, in the illustrated embodiment, hardware accelerator 18 has four interfaces. Hardware accelerator 18 has an interface 161 (referred to as the North Interface) to communicate with media processor 14. Hardware accelerator 18 may receive commands and/or data from media processor 14 through interface 161. Additionally, hardware accelerator 18 may include an interface 176 to bus 32. Bus 32 may connect hardware accelerator 18 to boot PROM 30 and/or video output processor 24. Boot PROM 30 may be configured to store system initialization data and/or control code for frame buffer 22. Hardware accelerator 18 may also include an interface to a texture buffer 20. For example, hardware accelerator 18 may interface to texture buffer 20 using an eight-way interleaved texel bus that allows hardware accelerator 18 to read from and write to texture buffer 20. Hardware accelerator 18 may also interface to a frame buffer 22. For example, hardware accelerator 18 may be configured to read from and/or write to frame buffer 22 using a four-way interleaved pixel bus.

[0073] The vertex processor 162 may be configured to use the vertex tags received from the media processor 14 to perform ordered assembly of the vertex data from the MPUs 152. Vertices may be saved in and/or retrieved from a mesh buffer 164.

[0074] The render pipeline 166 may be configured to rasterize 2D window system primitives and 3D primitives into fragments. A fragment may contain one or more samples. Each sample may contain a vector of color data and perhaps other data such as alpha and control tags. 2D primitives include objects such as dots, fonts, Bresenham lines and 2D polygons. 3D primitives include objects such as smooth and large dots, smooth and wide DDA (Digital Differential Analyzer) lines and 3D polygons (e.g. 3D triangles).

[0075] For example, the render pipeline 166 may be configured to receive vertices defining a triangle, to identify fragments that intersect the triangle.

[0076] The render pipeline 166 may be configured to handle fall-screen size primitives, to calculate plane and edge slopes, and to interpolate data (such as color) down to tile resolution (or fragment resolution) using interpolants or components such as:

[0077] r, g, b (i.e., red, green, and blue vertex color);

[0078] r2, g2, b2 (i.e., red, green, and blue specular color from lit textures);

[0079] alpha (i.e. transparency);

[0080] z (i.e. depth); and

[0081] s, t, r, and w (i.e. texture components).

[0082] In embodiments using supersampling, the sample generator 174 may be configured to generate samples from the fragments output by the render pipeline 166 and to determine which samples are inside the rasterization edge. Sample positions may be defined by user-loadable tables to enable stochastic sample-positioning patterns.

[0083] Hardware accelerator 18 may be configured to write textured fragments from 3D primitives to frame buffer 22. The render pipeline 166 may send pixel tiles defining r, s, t and w to the texture address unit 168. The texture address unit 168 may determine the set of texels that are addressed by the fragment(s), as well as the interpolation coefficients for the texture filter, and write texels to the texture buffer 20. The texture buffer 20 may be interleaved to obtain as many neighboring texels as possible in each clock. The texture filter 170 may perform bilinear, trilinear or quadlinear interpolation. The pixel transfer unit 182 may also scale and bias and/or lookup texels. The texture environment 180 may apply texels to samples produced by the sample generator 174. The texture environment 180 may also be used to perform geometric transformations on images (e.g., bilinear scale, rotate, flip) as well as to perform other image filtering operations on texture buffer image data (e.g., bicubic scale and convolutions).

[0084] In the illustrated embodiment, the pixel transfer MUX 178 controls the input to the pixel transfer unit 182. The pixel transfer unit 182 may selectively unpack pixel data received via north interface 161, select channels from either the frame buffer 22 or the texture buffer 20, or select data received from the texture filter 170 or sample filter 172.

[0085] The pixel transfer unit 182 may be used to perform scale, bias, and/or color matrix operations, color lookup operations, histogram operations, accumulation operations, normalization operations, and/or min/max functions. Depending on the source of (and operations performed on) the processed data, the pixel transfer unit 182 may output the processed data to the texture buffer 20 (via the texture buffer MUX 186), the frame buffer 22 (via the texture environment unit 180 and the fragment processor 184), or to the host (via north interface 161). For example, in one embodiment, when the pixel transfer unit 182 receives pixel data from the host via the pixel transfer MUX 178, the pixel transfer unit 182 may be used to perform a scale and bias or color matrix operation, followed by a color lookup or histogram operation, followed by a min/max function. The pixel transfer unit 182 may then output data to either the texture buffer 20 or the frame buffer 22.

[0086] Fragment processor 184 may be used to perform standard fragment processing operations such as the OpenGL fragment processing operations. For example, the fragment processor 184 may be configured to perform the following operations: fog, area pattern, scissor, alpha/color test, ownership test (WID), stencil test, depth test, alpha blends or logic ops (ROP), plane masking, buffer selection, pick hit/occlusion detection, and/or auxiliary clipping in order to accelerate overlapping windows.

[0087] Texture Buffer 20

[0088] Texture buffer 20 may include several SDRAMs. Texture buffer 20 may be configured to store texture maps, image processing buffers, and accumulation buffers for hardware accelerator 18. Texture buffer 20 may have many different capacities (e.g., depending on the type of SDRAM included in texture buffer 20). In some embodiments, each pair of SDRAMs may be independently row and column addressable. In one embodiment of the invention, the memory devices comprising the texture buffer 20 stores texture map data in an interleaved format to allow for efficient texture memory accesses.

[0089] Frame Buffer 22

[0090] Graphics system 112 may also include a frame buffer 22. In one embodiment, frame buffer 22 may include multiple 3D-RAM memory devices (e.g. 3D-RAM64 memory devices) manufactured by Mitsubishi Electric Corporation. Frame buffer 22 may be configured as a display pixel buffer, an offscreen pixel buffer, and/or a super-sample buffer. Furthermore, in one embodiment, certain portions of frame buffer 22 may be used as a display pixel buffer, while other portions may be used as an offscreen pixel buffer and/or sample buffer.

[0091] Video Output ProcessorFIG. 6

[0092] A video output processor 24 may also be included within graphics system 112. Video output processor 24 may buffer and process pixels output from frame buffer 22. For example, video output processor 24 may be configured to read bursts of pixels from frame buffer 22. Video output processor 24 may also be configured to perform double buffer selection (dbsel) if the frame buffer 22 is double-buffered, overlay transparency (using transparency/overlay unit 190), plane group extraction, gamma correction, psuedocolor or color lookup or bypass, and/or cursor generation. For example, in the illustrated embodiment, the output processor 24 includes WID (Window ID) lookup tables (WLUTs) 192 and gamma and color map lookup tables (GLUTs, CLUTs) 194. In one embodiment, frame buffer 22 may include multiple 3DRAM64s 201 that include the transparency overlay 190 and all or some of the WLUTs 192. Video output processor 24 may also be configured to support two video output streams to two displays using the two independent video raster timing generators 196. For example, one raster (e.g., 196A) may drive a 12801024 CRT while the other (e.g., 196B) may drive a NTSC or PAL device with encoded television video.

[0093] DAC 26 may operate as the final output stage of graphics system 112. The DAC 26 translates the digital pixel data received from GLUT/CLUTs/Cursor unit 194 into analog video signals that are then sent to a display device. In one embodiment, DAC 26 may be bypassed or omitted completely in order to output digital pixel data in lieu of analog video signals. This may be useful when a display device is based on a digital technology (e.g., an LCD-type display or a digital micro-mirror display).

[0094] DAC 26 may be a red-green-blue digital-to-analog converter configured to provide an analog video output to a display device such as a cathode ray tube (CRT) monitor. In one embodiment, DAC 26 may be configured to provide a high resolution RGB analog video output at dot rates of 240 MHz. Similarly, encoder 28 may be configured to supply an encoded video signal to a display. For example, encoder 28 may provide encoded NTSC or PAL video to an S-Video or composite video television monitor or recording device.

[0095] In other embodiments, the video output processor 24 may output pixel data to other combinations of displays. For example, by outputting pixel data to two DACs 26 (instead of one DAC 26 and one encoder 28), video output processor 24 may drive two CRTs. Alternately, by using two encoders 28, video output processor 24 may supply appropriate video input to two television monitors. Generally, many different combinations of display devices may be supported by supplying the proper output device and/or converter for that display device.

[0096] Sample-to-Pixel Processing Flow

[0097] In one set of embodiments, hardware accelerator 18 may receive geometric parameters defining primitives such as triangles from media processor 14, and render the primitives in terms of samples. The samples may be stored in a sample storage area (also referred to as the sample buffer) of frame buffer 22. The samples may be computed at positions in a two-dimensional sample space (also referred to as rendering space). The sample space may be partitioned into an array of bins (also referred to herein as fragments). The storage of samples in the sample storage area of frame buffer 22 may be organized according to bins (e.g. bin 300) as illustrated in FIG. 7. Each bin may contain one or more samples. The number of samples per bin may be a programmable parameter.

[0098] The samples may then be read from the sample storage area of frame buffer 22 and filtered by sample filter 22 to generate pixels. In one embodiment, the pixels may be stored in a pixel storage area of frame buffer 22. The pixel storage area may be double-buffered. Video output processor 24 reads the pixels from the pixel storage area of frame buffer 22 and generates a video stream from the pixels. The video stream may be provided to one or more display devices (e.g. monitors, projectors, head-mounted displays, and so forth) through DAC 26 and/or video encoder 28. In one embodiment, as discussed above, the sample filter 22 may filter respective samples to generate pixels, and the pixels may be provided as a video stream to the display without any intervening frame buffer storage, i.e., without storage of the pixels.

[0099] FIG. 8Exemplary Graphics System

[0100] FIG. 8 illustrates an embodiment of a portion of the graphics system. As shown, graphics processor (e.g. hardware accelerator) 18 couples to a texture memory 20 comprising a plurality of memory devices 202. The memory devices 202 may comprise a plurality of pairs of memory devices 202. In the embodiment shown in FIG. 8, the system comprises 4 pairs of SDRAM memory devices 202, i.e., 8 total memory devices. The pairs of memory devices are referred to as Set A, Set B, Set C, and Set D. Each set includes a subset, e.g., Set A includes Subset A0 and Subset A1, and so forth.

[0101] The graphics processor 18 may store texture maps in the memory devices 202 and/or access texture maps from the memory devices 202. The memory devices 202 may thus be used to store texture maps used in the rendering process. Thus the memory devices 202 may comprise the texture buffer 20. The texture buffer 20 may have eight SDRAMs. In one set of embodiments, each pair of SDRAMs may be independently row and column addressable, to allow arbitrary addressing of 22 texture footprints. Furthermore, within each pair, the two SDRAMs may receive independent column addresses.

[0102] In one embodiment, a texture map comprises a plurality of texels, wherein an NM array of texels corresponds to each pixel. For example, each NM array of texels may comprise a 22 array of texels. Neighboring pixels may share one or more texels. In other words, for two neighboring pixels, their respective NM arrays of texels may include one or more common texels. Where a 22 array of texels corresponds to each pixel, then in one embodiment neighboring pixels share at least two texels. The graphics system may include various texture modes, e.g., 2D and 3D modes, and 8, 16, 32 or 64 bit texels.

[0103] Memory Interleaving

[0104] According to one embodiment of the invention, at least portions of the texels may be stored in respective ones of the plurality of memory devices 202, wherein neighboring (or spatially adjacent) texels are stored in separate ones of the memory devices in an interleaved fashion. Due to the interleaved nature of the storage of the texels, for each of the plurality of pixels, the plurality of memory devices are operable to output a respective NM array of texels for a respective pixel in parallel in a single read transaction. In other words, the texel data is interleaved in the plurality of memory devices to guarantee that, no matter which NM array of texels is accessed, each texel in the array is present in a different memory device or chip 202 and hence all of the texels in the array are concurrently available. Thus the NM array of texels may be output concurrently or simultaneously, regardless of which array is accessed, i.e., regardless of which pixel is addressed.

[0105] Therefore, for each of the plurality of pixels, the graphics processor 18 is operable to access any NM array of texels for any respective pixel in a single read transaction, e.g., in a single clock cycle. The access may also be performed with reduced or no over-fetching. In other words, the graphics processor 18 is operable to generate a read request for an NM array of texels, and as a result the plurality of memory devices 202 composing the texture buffer in one embodiment operate to output just the NM array of texels, without any over-fetching of unwanted texel data. In another embodiment, the plurality of memory devices 202 may be operable to output the requested NM array of texels and also output a non-requested, but neighboring or spatially adjacent, NM array in a pre-fetch fashion to possibly anticipate the next request.

[0106] One embodiment of the interleaving is illustrated below, wherein A, B, C, C, a, b, c, and d are the 8 memory devices or chips, and the memory devices are grouped into 4 pairs, these being Aa, Bb, Cc, Dd. Thus, Aa refers to subsets A0 and A1 in FIG. 8, and so on.

	Aa	Bb	Cc	Dd
	Cc	Dd	Aa	Bb
	Aa	Bb	Cc	Dd
	Cc	Dd	Aa	Bb

[0107] One embodiment of the graphics system provides 6 address scrambling modes to accommodate all of the different texel footprints. The 6 address scrambling modes include accumulation buffer mode, two imaging modes, and 3D modes. The accumulation buffer mode treats texture memory as a linear buffer. The other modes are optimized to be able to fetch as many texels per cycle as possible. The imaging modes (bicubic and convolve) use the 2D modes and are optimized both for texturing (22) and for imaging (41 and 42) footprints. The 3D modes are optimized to fetch 222 in one cycle (8 and 16-bit only due to memory bandwidth).

[0108] One embodiment of the invention utilizes a texture address mapping algorithm that has been designed to meet the following requirements:

[0109] Able to read 4 texels in a 22 pattern in 1 cycle

[0110] Desired to be able to read 8 texels in 1 cycle: 2 of 22 (2D) or 222 (3D) in 8-bit or 16-bit mode.

[0111] (2D modes) Able to read 4 texels in V (i.e. V0 to V3; U, Q constant) for 44 (33) filter kernel. Desired to be able to read 8 (two sets of 14 texels) with 8- or 16-bit texels.

[0112] Desired to be able to write 64 bits per clock cycle in U major order (V,Q constant) in any scrambling mode.

[0113] Desire as few scrambling modes as possible.

[0114] FIG. 9 illustrates memory interleaving according to various texture address scrambling patterns or modes. The letters in FIG. 9 refer to the SDRAM sets shown in FIG. 8, the subscripts refer to the subset numbers, and the prime symbol () refers to which byte of the 16-bit SDRAM bus is being used. The circles in FIG. 9 show which patterns of texels can be read in one cycle without conflict. A conflict occurs when the same symbol (e.g., B0) is used twice in a given group. Note that the 42 groups only work in certain circumstances (subject to alignment and tile boundary crossing).

[0115] The mode 302 (upper left in FIG. 9) is used where texels are 32 bits in 2D or 3D or where texels are 16 bits in 3D. As shown in mode 302 of FIG. 9, in 2D any 22 array of pixels (represented by A, B, C, and D) can be accessed concurrently in one read cycle, and in 3D any 222 array of pixels can be accessed concurrently in one read cycle.

[0116] In an exemplary embodiment of mode 302, each NM array of texels comprises a 22 array of texels, each texel is 32 bits, the plurality of memory devices comprise 8 memory devices, the memory devices are 16 bit memories, and each of the memory devices stores 16 bits (one half) of a respective texel. Thus, 16 bits of each texel may be stored in one memory device of a pair, and the other 16 bits may be stored in another memory device of the pair. A texel may be stored in and accessed from each respective memory device pair. Due to the memory interleaving, any 22 array of texels may be accessed in a single read cycle.

[0117] The mode 304 (upper right in FIG. 9) is used where texels are 16 bits in 2D. As shown in mode 304 of FIG. 9, where the texels are only 16 bits each, then the memory interleaving can be configured such that 2 pixels worth of texture data (two 22's of texels) can be accessed simultaneously as long as the two pixels are relatively close or spatially adjacent (neighboring) to one another, which is common in rasterization. More generally, for each of the plurality of pixels, the plurality of memory devices are operable to output a respective NM array of texels for at least two respective neighboring pixels in parallel in response to a single read transaction.

[0118] In an exemplary embodiment of mode 304, each NM array of texels comprises a 22 array of texels, each texel is 16 bits, the plurality of memory devices comprise 8 memory devices, the memory devices are 16 bit memories, and each of the memory devices stores a respective 16 bit texel. In this exemplary embodiment, for each of the plurality of pixels, the plurality of memory devices are operable to output a respective 22 array of texels for each of two respective neighboring pixels in parallel in a single read transaction.

[0119] The mode 306 (middle left in FIG. 9) is used where texels are 16 bits in 3D. In mode 306 of FIG. 9, where the texel array is 3D and the texels are 16 bits each, then the memory interleaving can be configured such that any 222 array of texels can be accessed in a single cycle. More generally, in mode 306, where each texture map is a 3-D texture map, an NMO array (3-D array) of texels corresponds to each pixel. In this embodiment, for each of the plurality of pixels, the plurality of memory devices are operable to output a respective NMO array of texels for a respective pixel in parallel in a single read transaction.

[0120] In one exemplary embodiment of mode 306, each texture map is a 3-D texture map, a 222 array of texels corresponds to each pixel, each texel is 16 bits, the plurality of memory devices comprise 8 memory devices, the memory devices are 16 bit memories, and each of the memory devices stores a respective 16 bit texel. In this exemplary embodiment, for each of the plurality of pixels, the plurality of memory devices are operable to output a respective 222 array of texels for a respective pixel in parallel in a single read transaction.

[0121] The remaining modes 308, 310, and 312 are extensions of the memory interleaving described herein for different texel bit sizes for 2D and/or 3D.

[0122] FIG. 10 illustrates an alternative representation of interleaving in 64 bit 2D. In this example, in each clock cycle, one entry can be taken from each of the 4 sets. This illustrates operation of the 41 (2 channel) and 21 (4 channel) footprints.

[0123] The scrambled data from the memory devices (e.g., SDRAMs) 202 may be sent to FIFO memories and unscrambled after being read out of these FIFOs.

[0124] Thus, in various of the modes described above, when a read transaction is generated for an NM array of texels for a respective pixel, the plurality of memory devices output the NM array of texels for the respective pixel in parallel (concurrently) in a single cycle in response to the read transaction. Where the texels are addressed using a U,V addressing scheme, the texels in each 22 array of texels may have addresses U, V; U1, V; U, V1; and U1, V1. In other words, for any U,V address, a requesting device, such as the graphics processor, can access any NM array of texels having addresses U,V; U1, V; U, V1; and U1, Vl. The plurality of memory devices are operable to output a respective NM array of texels having addresses U,V; U1, V; U, V1; and U1, V1; for a respective pixel in parallel in a single read transaction.

[0125] Texture Bodies and Borders

[0126] The texture buffer 20 (i.e., the memory devices 202) may store texels organized as tiles. A tile is equivalent to a page of memory, and represents the range of texels which can be accessed without incurring a page miss. In general, page misses are undesirable because they negatively impact performance. In one embodiment, each texture map comprises a body portion and a border portion. The body portion of the texture map (without borders) may have a size that is a power of 2 in each dimension. Thus, for a 2D texture map, the width and height of the texture map is a power of 2 in size. For a 3D texture map, the width, height, and length of the texture map is a power of 2 in size. Since memory pages are a power of 2 in size, the body portion of the texture map may be efficiently stored in memory. The border portion of the texture map may be a 1 texel-wide strip around the body portion of the texture map. Since the body portion of the texture map is a power of 2 in size, the body portion plus the border portion is not a power of 2 in size. Thus, storage of the body and border portions of the texture map would be inefficient.

[0127] In one embodiment of the invention, the body and border portions of the texture map are stored in separate areas of memory (e.g., in different memory address spaces). However, the texel interleaving described above is preserved, whereby neighboring texels in the body and border portions may be stored in separate ones of the memory devices in an interleaved fashion. Thus, for respective pixels which include texels from both the body portion and border portion of the texture map, the plurality of memory devices are operable to output a respective NM array of texels for the respective pixel in parallel in a single read transaction. In other words, the texel data is interleaved in the plurality of memory devices to guarantee that, no matter which NM array of texels is accessed, (even if the array requires some body texels and some border texels), each texel in the array is present in a different memory device or chip and hence all of the texels in the array are concurrently available. The upper address bits of texels in the border portion may not be interleaved to allow for efficient packing Therefore, in one embodiment borders are interleaved with the main body of the texture. This may waste some memory in the border storage, but improves performance when image borders are used. FIG. 11 illustrates an example that shows how the borders are interleaved with 16-bit 2D textures:

[0128] Exemplary Embodiment

[0129] The following provides details of one exemplary embodiment of the present invention. It is noted that the present invention may be implemented in various different ways, as desired.

[0130] Texture Border Storage

[0131] In one embodiment, borders are stored in a separate location from the main body of the texture images, as defined by a Border Base Register. This simplifies address calculation for texels within the texture image, and allow for some performance improvement by packing neighboring texels together.

[0132] In 2D mode, the storage order is: bottom border, top border, left border, right border. To simplify addressing, all edge borders are of sizeMAX (width, height, depth, 16-bytes). This may be slightly wasteful if the texture map is not square/cubic, but simplifies calculations. In 3D mode, the far border plane is stored first (r<0.0), then the near border plane (r>1.0), and then sets of bottom/top/left/right borders as in the 2D case. Note that there are (Size2) of these sets of edge borders. For the mip map case, the above patterns repeat for each MIP level.

[0133] Base Addresses of Borders

[0134] The base address of the level 0 border is stored in the Border Base Register. The addresses of the borders for other mip levels are computed by the hardware. The base address in this register is preferably 4k-byte aligned.

[0135] In one embodiment, the borders are tightly packed. In this embodiment, however, afinding the base address of a particular MIP level's border given the border base is difficult (especially in the 3D mode). Since the border data is tightly packed (no wasted memory), it may be very difficult to compute the starting address of a particular MIP level's borders. This is because in 3D mode, each border section contains 2 border planes (near and far), and Depth2 sets of edge borders (top, bottom, left, right). The size of this set of borders is: (width*depth*2(depth2)*2*(width2height)). This coupled with the fact that width, depth and height aren't necessarily of what they were on the previous level (since the texture may not be square/cubic) makes this difficule to calculate.

[0136] In another embodiment, the borders are not tightly packed. When calculating the border storage area, the main texture is assumed to be square/cubic with dimensions (MAX(width, depth, height, 16-bytes))³. This simplifies the calculation, and wastes no memory for square/cubic textures. This also reduces memory waste when the textures have a relatively small aspect ratio or for large textures. The formula for the area of a particular 3D border is now: (6n²12n8), where nMAX (Width, Height, Depth). To enforce alignment restrictions, borders are considered to be at least 16 bytes long.

[0137] Furthermore, as described above, borders are interleaved (scrambled) in the same way as the core texture (body portion of the texture) so that the texture memory controller won't thrash (multiple page or tile misses) when reading both border and core texels. This comes at the cost of taking 1-4 the storage for the vertical borders (depending on bytes per texel).

[0138] One method to calculate the Base Address of the borders for a particular Mip Level is to use a lookup table. The function takes (size and level), and returns the base address. SizeMAX (Width, Height, Depth), and Level is the MIP level which you're looking for the border address. Note that level is never greater than size. The lookup table implements the formula described above.

[0139] 2D Borders

[0140] FIG. 12 illustrates the manner in which edge borders are stored for 2D textures.

[0141] The 4 edge borders are stored: bottom, top, left, right. The borders are allocated space as though they are of sizemax(width,height). The corner texels belong to the left and right borders.

[0142] The border texels are low-order scrambled exactly like the body of the texture (Set, Subset, Byte). This increases performance and eases the unscrambling operation. The address bits above those fields are linear addresses.

[0143] The horizontal texture borders may only use Sets A and B for the Top and Sets C and D for the Bottom edge. This allows these edges to fully utilize memory by treating the top and bottom as though they have the same starting address and are interleaved by the sets. The address is exactly like the low order scrambling (including Set1V0). The address range for horizontal borders is 0 . . . size-1.

[0144] The vertical borders may not be fully packed, however. The low-order scrambling dictates that 16-bit textures only use subset 1 (wasting of the memory), and 8-bit textures only use subset 1, byte 1 (wasting of memory). This loss is inconsequential for textures at least 6464 or 323232. Also note that 32-bit texels do not waste any memory.

[0145] The vertical borders include the corner texels, and thus the address range is -1 to size. For this reason (and to ensure correct scrambling), the left and right borders are padded with 16-bytes on each side (the V1 and Vsize texels use part of this 16 byte padding). The last border has a 32-byte pad (instead of 16 bytes) to make the entire border set 64-byte aligned. The next mipmap level's borders start at that point.

[0146] 3D Borders

[0147] 3D borders are stored in the following order: far plane, near plane, Size2 of edge borders (bottom, top, left, right). Width, Height and Depth are treated as though they are max(width, height, 16-bytes).

[0148] The near and far border planes are low-order scrambled preferably exactly like the body of the texture, and are assumed to be square. The address bits above that are set to:

[0149] The edge borders are stored preferably exactly like the 2D borders, with Size2 sets of edge borders. The next mip map level's borders are stored immediately after the last edge border of the current level.

[0150] Body Address Scrambling

[0151] The following describes one embodiment of the body address scrambling. The address scrambling takes UVQ values and performs the memory interleaving for texels within the body of the texture map (not borders). This process is divided into two sections: the lower bits (Tile, Set, Subset and Byte), and the upper address bits (Row and Bank). The low order bits primarily determine how many texels can be fetched in one cycle, while the higher order bits determine how often Tile- or Page-misses occur. More specifically, the low-order scrambling determines physically which SDRAM (and on which half of the 16-bit bus) the texel data will be stored. This unit only processes texels which are not in the border.

[0152] The Lower address bits have a fixed scrambling pattern, depending on the Texel Size (8-64 bit), and the dimension (2D or 3D).

[0153] The Upper address bit packing is flexible. All of the UVQ bits not used in the Lower Address packing are assembled as: UVQ, then the result is shifted right to remove any unused bits in each of U, V and Q. For example, if the Width64, then only U5:0 is used and Q and V will be shifted left to fill the space which U11:6 would have taken.

[0154] In one embodiment, the process summary is:

[0155] Swap Umsb and Bank0 if mipmapping enabled

[0156] Create low-order bit scrambling (7-1 mux based on mode)

[0157] Create high-order bit scrambling (7-1 mux based on mode)

[0158] Compact upper bits

[0159] XOR Bank bits as needed

[0160] The final output is a linear SDRAM address of the form:

[0161] AddrRow12:0, Col9, Bank1:0, Tile7:0, Set1:0, Subset, Byte,

[0162] regardless of whether Col9 and Bank1 actually exist in SDRAM.

[0163] Low Order Bit Scrambling

[0164] FIG. 13 illustrates Low-order bit scrambling to accomplish memory interleaving. FIG. 13 illustrates low order bit scrambling for various modes, i.e., FIG. 13 illustrates the process of logical to physical address conversion for various modes. The Subset, Set0, and Set1 values indicate which of the 8 memories are accessed.

[0165] The color bit is only for 64-bit mode, and is 0 for the Red/Green pair, and 1 for the Blue/Alpha pair.

[0166] In one embodiment, the low order bits (Tile, Set, Subset, Byte) are not packed, in order to make scrambling easier and to ensure that the scrambling works correctly with a texture of any aspect ratio.

[0167] High Order Bit Scrambling

[0168] FIG. 14 illustrates high order bit scrambling for various modes according to one embodiment. FIG. 15 illustrates SDRAM bank scrambling. In FIG. 15, the numbers 0, 1, 2 and 3 are used to represent banks and how they relate to texel tiles (groups of neighboring texels). The high order bits are not used to implement memory interleaving as described herein, and hence are not discussed in detail. In addition, the SDRAM bank scrambling is not used in the memory interleaving, and thus is not described in detail herein.

[0169] Final Output

[0170] The final output of the body address is as follows:

[0171] Body_AddrRow12:0, Col9, Bankl, Bank0, Tile, Set, Subset, Byte

[0172] If the SDRAM does not physically have 9 column address bits or 2 bank bits, then those bits will automatically become the LSBs of the row field. The sort unit takes the address from this unit as one linear address and divides it up into Row, column, bank, etc. based on the type of SDRAM being used. In other words, if an SDRAM only has 8 column bits, the Col9 field in Body addr is still valid, but it represents Row0. Sort should use all bits in Body_addr, regardless of num_cols9 and num_banks4.

[0173] Border Offset and Scramble

[0174] The graphics system includes a unit (the Border Offset and Scramble Unit) which calculates the border offset and scramble. FIG. 15 illustrates the border memory scrambling. This unit calculates the address of a particular image border texel within a particular mipmap level, given the size of this level's texture map. The Border Base unit calculates the starting address for the borders for each mipmap level.

[0175] 2D texture maps have 4 edge borders per mip level: top, bottom, left and right.

[0176] 3D texture maps have 4 edge borders per slice (in Q), plus two border planes (which also have edge borders). The Detail texture map has no borders.

[0177] Edge borders are accessed via the direct port in U or V major. The direct port can read or write 2 texels at a time (8/16-bit mode), either in ascending U (for top and bottom) or in V (for left and right) edge borders.

[0178] The Border Offset and Scramble unit is similar to the Body Address Scramble, but is specially built to handle borders. This unit can only take 4 addresses per cycle. The border packing is sufficiently different from the packing in the main body of the texture map to warrant a separate unit. The reason for 4 and not 8 is: preferably do not pair texels if borders are involved, and in 3D mode (with image borders), texture memory can't be guaranteed to read all 8 texels in one cycle so the read is split into two 4-texel reads over two cycles.

[0179] To simplify storage calculation for borders, texture maps are assumed to be square, with the each dimension being: log2_lengthMAX (W, H, D), where D0 for 2D mode. This wastes some memory, but is relatively insignificant compared to the body of the texture map.

[0180] The operation of the border address scrambling is as follows:

[0181] First, calculate dimensions of the texture map at this level. In all modes, start by subtracting Level from W, H, D:

[0182] WWLevel, HHLevel, DDLevel (but don't allow to go negative).

[0183] For 2D Texture Maps:

[0184] There are 4 edge borders: top, bottom, left right. The corners are owned by the Left and Right borders. The test to see which edge a pixel falls in are:

[0185] Left: U1

[0186] Right: U2W

[0187] Bottom: V1 AND not Left or Right

[0188] Top: V2H AND not Left or Right

[0189] log2_lengthMAX (W, H)

[0190] length2log2_length

[0191] BPTbytes per texel (1, 2, 4 or 8)

[0192] Horizontal (top, bottom) and vertical (left, right) borders are treated separately. Horizontal borders are completely packed, and are:

[0193] Vertical borders own the corner texels, and are:

[0194] This is because vertical borders are not fully packed. Leaving them less packed allows them to be interleaved correctly with the body of the texture map.

[0195] There is some padding (16-bytes between edges) to account for the corner texels which are owned by the vertical borders. The starting address of the various edges are:

[0196] Bottom and Top: 0

[0197] To find the address of a particular texel, use the normal address scrambling for Set, Subset, Byte, and just U or V for the upper bits (U for Top/Bottom, V for Left/Right). Finally, add in the offset for the desired edge as shown above. V should be treated as a signed number (offset could be 1 into left and right borders). This address will then be added to the border base in a later unit.

[0198] For example, the address of a texel in the Left border in 2D, 16-bit mode is: AddrV12:2, V0, U1V1, U0, 0size_h*216 The add is signed, but the result should be positive (V is never lower than 1). This signed add must be handled carefully (sign-extend V12).

[0199] The reason the Left and Right borders are not densely packed is that the scrambling includes U1 and U0 in the Subset and Byte fields.

[0200] 3D Texture Maps:

[0201] The 3D textures are packed in this order: Far Plane, Near Plane, Edges (top/bottom, left, right) for Far through Near planes.

[0202] The 3D border algorithm is:

[0203] Determine if this texel is in an Edge or Plane border

[0204] Find the starting address of that particular plane or edge border

[0205] Determine the address of the texel within that border

[0206] log2_lengthMAX (W, H, D)

[0207] length2log2_length

[0208] BPT bytes per texel (1, 2, 4 or 8)

[0209] There are 2 plane borders and length2 sets of edge borders. Each plane border has a size (in bytes) of:

[0210] and each edge border is stored exactly like the 2D case. Plane borders are interleaved (scrambled) exactly like the body of the texture map, with the upper address bits set to:

[0211] A pixel is in a border if any of the coordinates are 1, or in U2W, V2H or Q2D. A pixel is in the plane borders if Q1 or Q2D, and U and V are not in borders. Otherwise, the pixel is in an edge border.

[0212] The starting addresses for the borders are:

[0213] Far Plane: 0

[0214] Near Plane: plane_area

[0215] Far Plane Edge Borders: 2*plane_area

[0216] The offsets into 3D plane and edge borders are shown in FIG. 15.

[0217] The memory used by each set of edges is:

[0218] so the starting address for a particular set of edges is:

[0219] Q can be in the range 1 . . . Depth, and thus 1 is added to Q.

[0220] Total 3D border storage for 1 mipmap level:

[0221] The address for a particular texel is then:

[0222] the address from the scrambling tablethe plane or edge offset, above.

[0223] The above describes one embodiment of the present invention. It is noted that the present invention may be implemented in various different ways, as desired.

[0224] Although the embodiments above have been described in considerable detail, other versions are possible. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications. Note the section headings used herein are for organizational purposes only and are not meant to limit the description provided herein or the claims attached hereto.