This patent document contains information subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent, as it appears in the U.S. Patent and Trademark Office files or records, but otherwise reserves all copyright rights whatsoever.
The present invention is related to embedded systems having 3D graphics capabilities. In other respects, the present invention is related to a graphics pipeline, a mobile phone, and memory structures for the same.
Embedded systems, for example, mobile phones, have limited memory resources. A given embedded system may have a main memory and a system bus, both of which are shared by different system hardware entities, including a 3D graphics chip.
Meanwhile, the embedded system 3D chip requires large amounts of bandwidth of the main memory via the system bus. For example, a 3D graphics chip displaying 3D graphics on a quarter video graphics array (QVGA) 240×320 pixel screen, at twenty frames per second, could require a memory bandwidth between 6.1 MB per second and 18.4 MB per second, depending upon the complexity of the application. This example assumes that the pixels include only color and alpha components.
Memory bandwidth demands like this can result in a memory access bottleneck, which could adversely affect the operation of the 3D graphics chip as well as of other hardware entities that use the same main memory and system bus.
An embedded device is provided which comprises a device memory and hardware entities including a 3D graphics entity. The hardware entities are connected to the device memory, and at least some of the hardware entities perform actions involving access to and use of the device memory. A grid cell value buffer is provided, which is separate from the device memory. The buffer holds data, including buffered grid cell values. Portions of the 3D graphics entity access the buffered grid cell values in the buffer, in lieu of the portions directly accessing the grid cell values in the device memory, for per-grid cell processing by the portions.
Other features, functions, and aspects of the invention will be evident from the Detailed Description of the Invention that follows.
The present invention is further described in the detailed description, which follows, by reference to the noted drawings by way of non-limiting exemplary embodiments, in which like reference numerals represent similar parts throughout the several views of the drawings, and wherein:
To facilitate an understanding of the following Detailed Description, definitions will be provided for certain terms used therein. A primitive may be, e.g., a point, a line, or a triangle. A triangle may be rendered in groups of fans, strips, or meshes. An object is one or more primitives. A scene is a collection of models and the environment within which the models are positioned. A pixel comprises information regarding a location on a screen along with color information and optionally additional information (e.g., depth). The color information may, e.g., be in the form of an RGB color triplet. A screen grid cell is the area of a screen that may be occupied by a given pixel. A screen grid value is a value corresponding to a screen grid cell or a pixel. An application programming interface (API) is an interface between an application program on the one hand and operating system, hardware, and other functionality on the other hand. An API allows for the creation of drivers and programs across a variety of platforms, where those drivers and programs interface with the API rather than directly with the platform's operating system or hardware.
A 3D graphics entity 20 is connected to system bus 14. 3D graphics entity 20 may comprise a core of a larger integrated system (e.g., a system on a chip (SoC)), or it may comprise a 3D graphics chip, such as a 3D graphics accelerator chip. The 3D graphics entity comprises a graphics pipeline (see
Buffer 22 holds data used in per-pixel processing by 3D graphics entity 20. Buffer 22 provides local storage of pixel-related data, such as pixel information from buffers within main memory 16, which may comprise one or more frame buffers 24 and Z buffers 26. Frame buffers 24 store separately addressable pixels for a given 3D graphics image; each pixel is indexed with X (horizontal position) and Y (vertical position) screen position index integer values. Frame buffers 24, in the illustrated system, comprise, for each pixel, RGB and alpha values. In the illustrated embodiment, Z buffer 26 comprises depth values Z for each pixel.
A microprocessor (one of hardware entities 18) and main memory 16 operate together to execute an application program (e.g., a mobile phone 3D game, a program for mobile phone shopping with 3D images, or a program for product installation or assembly assistance via a mobile phone) and an application programming interface (API). The API facilitates 3D rendering for a application, by providing the application with access to the 3D graphics entity. The application may be developed in a work station or desktop personal computer, and then loaded to the embedded device, which in the illustrated embodiment comprises a wireless mobile communications device (e.g., a mobile phone).
Setup stage 23 performs computations on each of the image's primitives (e.g., triangles). These computations precede an interpolation stage (otherwise referred to as a shading stage 25 or a primitive-to-pixel conversion stage) of the graphics pipeline. Such computations may include, for example, computing the slope of a triangle edge using vertex information at the edge's two end points. Shading stage 25 involves the execution of algorithms to define a screen's triangles in terms of pixels addressed in terms of horizontal and vertical (X and Y) positions along a two-dimensional screen. Texturing stage 27 matches image objects (triangles, in the embodiment) with certain images designed to add to the realistic look of those objects. Specifically, texturing stage 27 will map a given texture image by performing a surface parameterization and a viewing projection. The texture image in texture space (u,v) (in texels) is converted to object space by performing a surface parameterization into object space (x0, y0, z0). The image in object space is then projected into screen space (x, y) (pixels), onto the object (triangle).
In the illustrated embodiment, blending stage 29 takes a texture pixel color from texture stage 27 and combines it with the associated triangle pixel color of the pre-texture triangle. Blending stage 29 also performs alpha blending on the texture-combined pixels, and performs a bitwise logical operation on the output pixels. More specifically, blending stage 29, in the illustrated system, is the last stage in 3D graphics pipeline 21. Accordingly, it will write the final output pixels of 3D graphics entity 20 to frame buffer(s) 24 within main memory 16. An additional graphics pipeline stage (not shown) may be provided between shading stage 25 and texturing stage 27. That is, a hidden surface removal (HSR) stage (not shown) may be provided, which uses depth information to eliminate hidden surfaces from the pixel data—thereby simplifying the image data and reducing the bandwidth demands on the pipeline.
A local buffer 28 is provided, which may comprise a buffer or a cache. Local buffer 28 buffers or caches pixel data obtained from shading stage 25. The pixel data may be provided in buffer 28 from frame buffer 24, after population of frame buffer 24 by shading stage 25, or the pixel data may be stored directly in buffer 28, as the pixel data is interpolated in shading stage 25.
As shown in
More specifically, in act 52, the triangle pixels for the given triangle will be stored locally at act 54, and the per-triangle processing will commence process actions not requiring triangle pixels at act 56. Actions not requiring triangle pixels may include, for example, the inputting of alpha, RGB diffused, and RGB specular data; the inputting of texture RGB, and alpha data; and the inputting of control signals, all to an input buffer (see input buffer 86, in
In a per-pixel processing act 58, a given pixel is obtained from the local buffer at act 60. The per-pixel processing actions are then executed on the given pixel at act 62. In act 64, the processed pixels of the triangle are stored locally and written back to the frame buffer (if the processed pixel is now dirty).
The local buffer from which the given pixel is obtained (in act 60) may comprise a local buffer, a local queue, a local Z-buffer, and/or a local cache. In the illustrated embodiment, the local buffer comprises a local cache dedicated to frame buffer data used in per-pixel processing by the 3D graphics pipeline. The cache comprises a pixel buffer mechanism to buffer pixels and to allow access to and processing of the buffered pixels by later portions of the graphics pipeline (in the illustrated embodiment, the texturing and blending stages). Those portions succeed the shading portion of the graphics pipeline. In the illustrated embodiment, those portions are separate graphics pipeline stages.
The per-triangle processing portion of the graphics pipeline, together with the 3D graphics cache, collectively comprise a new object enable mechanism to enable prefetching by the cache of pixels of the new object (a triangle in the illustrated embodiment). The per-object processing portion of the graphics pipeline processes portions of the new triangle pixels. Where processed pixels from a previous triangle coinciding with the new triangle pixels are already in the cache, the cache does not prefetch those coinciding pixels.
Triangle pixel address buffer 76 has a pixel address input for identifying the address of a first pixel of the current cache line corresponding to the triangle being currently processed by per-triangle processing portion 70. Triangle pixel address buffer 76 also has an “enable, new triangle” input, for receiving a signal indicating that a new triangle is to be processed and enabling operation of the cache, at which point memory accesses are checked within the contents of the cache, and, when there is a cache miss, memory requests are made through the bus interface.
Blending portion 74 comprises an input buffer 86, a blending control portion 88, a texture shading unit 90, an alpha blending unit 92, a rasterization code portion (RasterOp) 94, and a result buffer 96.
Input buffer 86 has an output for indicating that it is ready for input from the texture stage. It comprises inputs: for alpha RGB diffused and RGB specular data; for texture RGB and alpha data; and for controls. It also has an input that receives the “enable, new triangle” signal. Input buffer 86 outputs the appropriate data for use by texture shading unit 90, which forwards pixel values to alpha blending unit 92. Alpha blending unit 92 receives input pixels from frame buffer prefetch cache 84, and is thus able to blend the texture information with the pre-textured pixel information from the frame buffer via frame buffer prefetch cache 84. The output information from alpha blending unit 92 is forwarded to RasterOp device 94, which executes the rasterization code. The results are forwarded to result buffer 96, which returns each pixel to its appropriate storage location within frame buffer prefetch cache 84.
A given pixel may be represented using full precision in the graphics core, while its precision may be reduced when packing in the frame buffer. Accordingly, a given pixel may comprise 32 bits of data, allowing for eight bits for each of R, G, and B, and eight bits for an alpha value. At the same resolution, if the depth value Z is integrated into each pixel, each pixel will require 48 bits. Each such pixel may be packed, thereby reducing its precision, as it is stored in cache 84. Out color converter 82 and in color converter 84 are provided for this purpose, i.e., out color converter 80 converts 24 bit pixel data to 32 bit pixel data, while in color converter 82 converts 32 bit pixel data to 24 bit pixel data.
Referring back to
Every time a cache miss occurs, checked on a per-cache-line basis grouped from the linear pixel address inputs, the missed cache line is fetched by prefetch mechanism 91. That fetch occurs through accessing the frame buffers stored in main memory 16 via system bus 14. A write back of a cache line will occur when the cache line is missed and the associated dirty bit is set or when the whole cache is invalidated. The size of a cache line is based on a given integer number of pixels. In the illustrated embodiment, the cache line size is eight consecutive pixels with a linear pixel addressing scheme, disassociating the cache from varying frame buffer formats in the system. This translates to 16 bytes in consecutive memory addresses for a 16 bpp frame buffer, 24 bytes for a 24 bpp frame buffer, and 32 bytes for a 32 bpp frame buffer.
The illustrated prefetching mechanism 91 takes advantage of the processing time in the blending process, and prefetches a next cache line identified by the next triangle pixel address within triangle pixel address buffer 76. Before the next cache line pixel group arrives at blending portion 74, the cache line accesses for that group are prefetched. Prefetch mechanism 91 determines if the next cache line access is a cache miss. If the cache line access is also “dirty,” the cache content is written-back before performing the prefetch associated with the cache miss. In this way, cache line fetches are pipelined with the pixel processing time of the next group of pixels, and the pixel processing time is hidden inside the bus access delay, which further reduces the effect of the bus access delay.
A collection of cache lines, e.g., 64 cache lines or 512 pixels, makes up a complete cache. The number of cache lines can be increased (thereby increasing the size of the cache) to gain performance, again at the expense of circuit area and power consumption. Direct mapping of the cache to the screen buffer is disassociated with the actual screen size setting. Since the pixels reside in consecutive memory addresses from the top-left screen corner to the lower-right corner, using a 64 8-pixel line cache as an example, for a 320×240 maximum resolution, there are only 9600 cache line locations in the screen. Out of that, only 150 unique locations per line can be mapped to 28 addresses. Therefore, using a simple address translation, pixel address bits [8:3] can be used as the tag index, and bits [16:9] can be used as the tag I.D. bits.
Pixel data transfers between cache control unit 78 and main memory 16 are mediated through a bus interface block 19 (see
The tag portion of pixel address register 102 determines whether there is a tag hit or miss. In other words, the tag portion comprises a cache line identifier. The index portion of pixel address register 102 indicates the cache position for a given pixel address. The portion to the right of pixel address register 102, between bits 2 and 0, comprises information concerning the start to finish pixels in a given line. Line start/count register 104 receives this information, and outputs a control signal to counter 106 for controlling when data concerning the cache position is input to an address input of tag RAM 108. When cache control 112 provides a write enable signal to tag RAM 108, the addressed data will be input into tag RAM 108 through an input location “IN.” Data is output at an ouput location “OUT” of tag RAM 108 to a compare mechanism 114. The tag portion of pixel address register 102 is also input to compare mechanism 114. If the two values correspond to each other, then a determination is made that the data is in the cache and a hit signal is input to cache control mechanism 112. Depending upon the output of tag RAM 108, a valid or dirty signal will also be input into cache control 112.
Cache control mechanism 112 further receives a next in queue valid signal indicating that a queue access address is valid, and a next line start/count signal indicating that a next line within the cache is being started, and causing a reset of the count for that line.
Data RAM 110 is used for cache data storage. Tag RAM 108 stores cache line identifiers. Gate 126a facilitates the selection between the cache data storage at data RAM 110 and the prefetch buffer 122, for outputting the selected pixel in destination pixel register 124. A cache enable gate 126c controls writing of data back to the main memory through bus interface 116. Color converters 118 and 120 facilitate the conversion of the precision of the pixels from one resolution to another as data is read in through bus interface 116, or as it is written back through bus interface 116.
In cache subsystem 100, the pixel addresses coming into pixel address register 102 are bundled into cache line accesses. Cache control mechanism 112 determines if the address at the top of this queue is a cache hit or miss. If this address is a hit, cache line access is pushed onto a hit buffer. Two physical banks of the cache data RAM 110 may be provided in the prefetch cache, one for RGB and the other for alpha. The alpha bank is disabled (clock-gated) if the alpha buffer is disabled and if the output format is in the RGB mode. Otherwise, both alpha and color may be fetched to maintain the integrity of the cache. The input data to the data path and blending portion 74 of the circuit shown in
As illustrated above, referring to, for example,
Prefetching mechanism 86 attempts to take advantage of the processing time needed in the portion of the pixel blending process not yet requiring per-pixel processing. Specifically, as indicated at act 56 in the process shown in
The number of cycles required for a read exceeds the number of cycles required for a write. Accordingly, whenever a write request is made, for example, by the hidden surface removal stage 165, the write is postponed by storing the write data in temporary storage 163, until such time as a read access is requested by hidden surface removal stage 165.
This allows the read latency to be hidden, by overlapping the writing of data to the depth buffer memory 160 with the time between which a read access is made and the time at which the data to be read is transferred from depth buffer memory 160 to the requesting entity, in this case, the hidden surface removal pipeline stage 165.
As illustrated in
A prefetching mechanism 170 may be provided to prefetch depth values from the depth buffer memory 160 and store those values in temporary storage 163. Accordingly, when a hidden surface removal stage 165 requests a given depth value, temporary storage 163, functioning as a cache, may not have this pixel depth value, resulting in a “miss,” prompting prefetching mechanism 170 to obtain the requested depth value. Prefetching mechanism 170 prefetches a number of values, i.e., M values, by requesting a complete addressed buffer unit.
Each element described hereinabove may be implemented with a hardware processor together with computer memory executing software, or with specialized hardware for carrying out the same functionality. Any data handled in such processing or created as a result of such processing can be stored in any type of memory available to the artisan. By way of example, such data may be stored in a temporary memory, such as in a random access memory (RAM). In addition, or in the alternative, such data may be stored in longer-term storage devices, for example, magnetic disks, rewritable optical disks, and so on. For purposes of the disclosure herein, a computer-readable media may comprise any form of data storage mechanism, including such different memory technologies as well as hardware or circuit representations of such structures and of such data.
While the invention has been described with reference to certain embodiments, the words which have been used herein are words of description, rather than words of limitation. Changes may be made, within the purview of the appended claims, without departing from the scope and spirit of the invention in its aspects. Although the invention has been described herein with reference to particular structures, acts, and materials, the invention is not to be limited to the particulars disclosed, but rather extends to all equivalent structures, acts, and materials, such as are within the scope of the appended claims.
This application claims the benefit of provisional U.S. Application Ser. No. 60/550,027, entitled “Pixel-Based Frame Buffer Prefetch Cache for 3D Graphics,” filed Mar. 3, 2004.
Number | Date | Country | |
---|---|---|---|
60550027 | Mar 2004 | US |