Method and system for implementing fragment operation processing across a graphics bus interconnect

Description

FIELD OF THE INVENTION

The present invention is generally related to graphics computer systems.

BACKGROUND OF THE INVENTION

Generally, a computer system suited to handle 3D image data includes a specialized graphics processor unit, or GPU, in addition to a traditional CPU (central processing unit). The GPU includes specialized hardware configured to handle 3D computer-generated objects. The GPU is configured to operate on a set of data models and their constituent “primitives” (usually mathematically described polygons) that define the shapes, positions, and attributes of the objects. The hardware of the GPU processes the objects, implementing the calculations required to produce realistic 3D images on a display of the computer system.

The performance of a typical graphics rendering process is highly dependent upon the performance of the system's underlying hardware. High performance real-time graphics rendering requires high data transfer bandwidth to the memory storing the 3D object data and the constituent primitives. Thus, more expensive prior art GPU subsystems (e.g., GPU equipped graphics cards) typically include larger (e.g., 128 MB or larger) specialized, expensive, high bandwidth local graphics memories for feeding the required data to the GPU. Less expensive prior art GPU subsystems include smaller (e.g., 64 MB or less) such local graphics memories, and some of the least expensive GPU subsystems have no local graphics memory.

A problem with the prior art low-cost GPU subsystems (e.g., having smaller amounts of local graphics memory) is the fact that the data transfer bandwidth to the system memory, or main memory, of a computer system is much less than the data transfer bandwidth to the local graphics memory. Typical GPUs with any amount of local graphics memory need to read command streams and scene descriptions from system memory. A GPU subsystem with a small or absent local graphics memory also needs to communicate with system memory in order to access and update pixel data including pixels representing images which the GPU is constructing. This communication occurs across a graphics bus, or the bus that connects the graphics subsystem to the CPU and system memory.

In one example, per-pixel Z-depth data is read across the system bus and compared with a computed value for each pixel to be rendered. For all pixels which have a computed Z value less than the Z value read from system memory, the computed Z value and the computed pixel color value are written to system memory. In another example, pixel colors are read from system memory and blended with computed pixel colors to produce translucency effects before being written to system memory. Higher resolution images (images with a greater number of pixels) require more system memory bandwidth to render. Images representing larger numbers of 3D objects require more system memory bandwidth to render. The low data transfer bandwidth of the graphics bus acts as a bottleneck on overall graphics rendering performance.

Thus, what is required is a solution capable of reducing the limitations imposed by the limited data transfer bandwidth of a graphics bus of a computer system. What is required is a solution that ameliorates the bottleneck imposed by the much smaller data transfer bandwidth of the graphics bus in comparison to the data transfer bandwidth of the GPU to local graphics memory. The present invention provides a novel solution to the above requirement.

SUMMARY OF THE INVENTION

Embodiments of the present invention ameliorate the bottleneck imposed by the much smaller data transfer bandwidth of the graphics bus in comparison to the data transfer bandwidth of the GPU to local graphics memory.

In one embodiment, the present invention is implemented as a system for cooperative graphics processing across a graphics bus in a computer system. The system includes a bridge coupled to a system memory via a system memory bus. The bridge is also coupled to a GPU (graphics processor unit) via the graphics bus. The bridge includes a fragment processor for implementing cooperative graphics processing with the GPU coupled to the graphics bus. The fragment processor is configured to implement a plurality of raster operations on graphics data stored in the system memory. The graphics bus interconnect coupling the bridge to the GPU to can be an AGP-based interconnect or a PCI Express-based interconnect. The GPU can be an add-in card-based GPU or can be a discrete integrated circuit device mounted (e.g., surface mounted, etc.) on the same printed circuit board (e.g., motherboard) as the bridge.

In one embodiment, the graphics data stored in the system memory comprises a frame buffer used by both the fragment processor and the GPU. One mode of cooperative graphics processing involves the fragment processor implementing frame buffer blending on the graphics data in the system memory (e.g., the frame buffer). In one embodiment, the fragment processor is configured to implement multi-sample expansion on graphics data received from the GPU and store the resulting expanded data in the system memory frame buffer. In one embodiment, the fragment processor is configured to evaluate a Z plane equation coverage value for a plurality of pixels (e.g., per polygon) stored in the system memory, wherein the Z plane equation coverage value is received from the GPU via the graphics bus.

In this manner, embodiments of the present invention implement a much more efficient use of the limited data transfer bandwidth of the graphics bus interconnect, and thus dramatically improve overall graphics rendering performance in comparison to the prior art. Furthermore, the benefits provided by the embodiments of the present invention are even more evident in those architectures which primarily utilize system memory for frame buffer graphics data storage.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements.

FIG. 1 shows a computer system in accordance with one embodiment of the present invention.

FIG. 2 shows a diagram depicting fragment operation processing as implemented by a computer system in accordance with one embodiment of the present invention.

FIG. 3 shows a diagram depicting fragment processing operations executed by the fragment processor and the rendering operations executed by the GPU within a cooperative graphics rendering process in accordance with one embodiment of the present invention.

FIG. 4 shows a diagram depicting information that is transferred from the GPU to the fragment processor and to the frame buffer in accordance with one embodiment of the present invention.

FIG. 5 shows a flowchart of the steps of a cooperative graphics rendering process in accordance with one embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Reference will now be made in detail to the preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with the preferred embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following detailed description of embodiments of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be recognized by one of ordinary skill in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the embodiments of the present invention.

Notation and Nomenclature:

Some portions of the detailed descriptions, which follow, are presented in terms of procedures, steps, logic blocks, processing, and other symbolic representations of operations on data bits within a computer memory. These descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. A procedure, computer executed step, logic block, process, etc., is here, and generally, conceived to be a self-consistent sequence of steps or instructions leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a computer system. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the present invention, discussions utilizing terms such as “processing” or “accessing” or “executing” or “storing” or “rendering” or the like, refer to the action and processes of a computer system (e.g., computer system 100 of FIG. 1), or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

Computer System Platform:

FIG. 1 shows a computer system 100 in accordance with one embodiment of the present invention. Computer system 100 depicts the components of a basic computer system in accordance with embodiments of the present invention providing the execution platform for certain hardware-based and software-based functionality. In general, computer system 100 comprises at least one CPU 101, a system memory 115, and at least one graphics processor unit (GPU) 110. The CPU 101 can be coupled to the system memory 115 via the bridge component 105 or can be directly coupled to the system memory 115 via a memory controller internal to the CPU 101. The GPU 110 is coupled to a display 112. System 100 can be implemented as, for example, a desktop computer system or server computer system, having a powerful general-purpose CPU 101 coupled to a dedicated graphics rendering GPU 110. In such an embodiment, components would be included that are designed to add peripheral buses, specialized graphics memory, JO devices (e.g., disk drive 112), and the like. The bridge component 105 also supports expansion buses coupling the disk drive 112.

It should be appreciated that although the GPU 110 is depicted in FIG. 1 as a discrete component, the GPU 110 can be implemented as a discrete graphics card designed to couple to the computer system via a graphics bus connection (e.g., AGP, PCI Express, etc.), as a discrete integrated circuit die (e.g., mounted directly on the motherboard), or as an integrated GPU included within the integrated circuit die of a computer system chipset component (e.g., integrated within the bridge chip 105). Additionally, a local graphics memory 111 can optionally be included for the GPU 110 for high bandwidth graphics data storage. It also should be noted that although the bridge component 105 is depicted as a discrete component, the bridge component 105 can be implemented as an integrated controller within a different component (e.g., within the CPU 101, GPU 110, etc.) of the computer system 100. Similarly, system 100 can be implemented as a set-top video game console device such as, for example, the Xbox®, available from Microsoft Corporation of Redmond, Wash.

EMBODIMENTS OF THE PRESENT INVENTION

Referring still to FIG. 1, embodiments of the present invention reduce constraints imposed by the limited data transfer bandwidth of a graphics bus (e.g., graphics bus 120) of a computer system. Embodiments of the present invention ameliorate the bottleneck imposed by the much smaller data transfer bandwidth of the graphics bus 120 in comparison to the data transfer bandwidth of the system memory bus 121 to system memory 115. This is accomplished in part by the bridge 105 implemented cooperative graphics processing in conjunction with the GPU 110 to reduce the amount data that must be transferred across the graphics bus 120 during graphics rendering operations. As shown FIG. 1, the bridge component 105 is a core logic chipset component that provides core logic functions for the computer system 100.

The cooperative graphics processing reduces the total amount data that must be transferred across the bandwidth constrained graphics bus 120. By performing certain graphics rendering operations within the bridge component 105, the comparatively high bandwidth system memory bus 121 can be used to access to graphics data 116, reducing the amount of data access latency experienced by these rendering operations. The resulting reduction in access latency, and increase in transfer bandwidth, allows the overall graphics rendering operations to proceed more efficiently, thereby increasing the performance of bandwidth-demanding 3D rendering applications. This cooperative graphics rendering process is described in further detail in FIG. 2 below.

FIG. 2 shows a diagram depicting a fragment operation processing process in accordance with one embodiment of the present invention. As depicted in FIG. 2, the GPU 110 is coupled to the bridge 105 via the low bandwidth graphics bus 120. The bridge 105 is further coupled to the system memory 115 via the high bandwidth system memory bus 121. FIG. 2 depicts a configuration whereby system memory 115 is used as frame buffer memory (e.g., graphics data 116) for the computer system (as opposed to a local graphics memory). The bridge 105 is configured to access to graphics data 116 via the high bandwidth system memory bus 121. The bridge 105 is also coupled to the GPU 110 via the graphics bus 120.

The bridge 105 includes a fragment processor 201 for implementing cooperative graphics processing with the GPU 110. The fragment processor 201 is configured to implement a plurality of raster operations on graphics data stored in the system memory. These raster operations executed by the fragment processor 201 suffer a much lower degree of latency in comparison to raster operations performed by the GPU 110. This is due to both the higher data transfer bandwidth of the system memory bus 121 and the shorter communications path (e.g., lower data access latency) between the fragment processor 201 and the graphics data 116 within the system memory 115.

Performing a portion of the raster operations, or all of the raster operations, required for graphics rendering in the fragment processor 201 reduces the amount of graphics data accesses (e.g., both reads and writes) that must be performed by the GPU 110. For example, by implementing fragment operations within the fragment processor 201, accesses to fragment data (e.g., graphics data 116) required for iterating fragment colors across multiple pixels can be performed across the high bandwidth system memory bus 121. For example, fragment data can be accessed, iterated across multiple pixels, and the resulting pixel color values can be stored back into the system memory 115 all across the high bandwidth system memory bus 121. The interpolation and iteration functions can be executed by the fragment processor 201 in conjunction with an internal RAM 215. Such fragment processing operations comprise a significant portion of the rendering accesses to the graphics data 116. Implementing them using a fragment processor within the bridge will effectively remove such traffic from the low bandwidth graphics bus 120.

In one embodiment, the fragment processor 201 substantially replaces the functionality of the fragment processor 205 within the GPU 110. In this manner, the incorporation of the fragment processor 201 renders the fragment processor 205 within the GPU 110 optional. For example, in one embodiment, the GPU 110 is an off-the-shelf card-based GPU that is detachably connected to the computer system 100 via a graphics bus interconnect slot (e.g., AGP slot, PCI Express slot, etc.). Such an off-the-shelf card-based GPU would typically incorporate its own one or more fragment processors for use in those systems having a conventional prior art type bridge. The graphics bus interconnect can be an AGP-based interconnect or a PCI Express-based interconnect. The GPU 110 can be an add-in card-based GPU or can be a discrete integrated circuit device mounted (e.g., surface mounted, etc.) on the same printed circuit board (e.g., motherboard) as the bridge 105. When connected to the bridge 105 of the computer system 100 embodiment, the included fragment processor(s) can be disabled (e.g., by the graphics driver).

Alternatively, the GPU 110 can be configured specifically for use with a bridge component having an internal fragment processor (e.g., fragment processor 201). Such a configuration provides advantages in that the GPU integrated circuit die area that would otherwise be dedicated to an internal fragment processor can be saved (e.g., thereby reducing GPU costs) or used for other purposes. In this manner, the inclusion of a fragment processor 205 within the GPU 110 is optional.

In one embodiment, the internal fragment processor 205 within the GPU 110 can be used by the graphics driver in conjunction with the fragment processor 201 within the bridge 105 to implement concurrent raster operations within both components. In such an embodiment, the graphics driver would allocate some portion of fragment processing to the fragment processor 201 and the remainder to the fragment processor 205. The graphics driver would balance the processing workloads between the bridge component 105 and the GPU 110 to best utilize the high bandwidth low latency connection of the bridge component 105 to the system memory 115. For example, to best utilize the high bandwidth system memory bus 121, it would be preferable to implement as large a share as possible of the fragment processing workloads within the bridge component 105 (e.g., fragment processor 201). This would ensure as large a percentage of the fragment operations as is practical are implemented using the low latency high bandwidth system memory bus 121. The remaining fragment processing workloads would be allocated to the fragment processor 205 of the GPU 110.

Implementing fragment processing operations within the bridge component 105 provides an additional benefit in that the amount of integrated circuit die area within the GPU 110 that must be dedicated to “bookkeeping” can be reduced. Bookkeeping logic is used by conventional GPUs to keep track of accesses to the graphics data 116 that are “in-flight”. Such in-flight data accesses are used to hide the latency the GPU 110 experiences when reading or writing to the graphics data 116 across the low bandwidth graphics bus 120. In general, in-flight data accesses refer to a queued number of data reads or data writes that are issued to the graphics data 116 that have been initiated, but whose results have yet to be received.

Bookkeeping logic is used to keep track of such in-flight accesses and, for example, to make sure storage is on hand when read results from the graphics data 116 arrive and to ensure the graphics data 116 is not corrupted when multiple writes have been issued. The more complex the bookkeeping logic, the more in-flight data accesses the GPU can maintain, and thus, the more the effects of the high latency can be hidden. By offloading fragment processing operations to the bridge 105 (e.g., fragment processor 201), the demands placed on any bookkeeping logic within the GPU 110 is reduced.

In this manner, embodiments of the present invention implement a much more efficient use of the limited data transfer bandwidth of the graphics bus interconnect, and thus greatly improves overall graphics rendering performance in comparison to the prior art architectures. Furthermore, the benefits provided by the embodiments of the present invention are even more evident in those architectures which primarily utilize system memory for frame buffer graphics data storage.

FIG. 3 shows a diagram depicting fragment processing operations executed by the fragment processor 201 and the rendering operations executed by the GPU 110 within a cooperative graphics rendering process in accordance with one embodiment of the present invention. As depicted in FIG. 3, the fragment processor 201 implements its accesses to the frame buffer 310 via the high bandwidth system bus 121. The GPU 110 implements its accesses to the frame buffer 310 via the low bandwidth graphics bus 120.

The FIG. 3 embodiment shows the functions included within the fragment processor 201. As shown in FIG. 3, the fragment processor includes those raster operations such as frame buffer blending 321 and Z buffer operations, and other operations such as compression, and multi-sample expansion. For example, the frame buffer blending module 321 blends fragment colors into the pixel data of the frame buffer 310. Generally, this involves interpolating existing pixel colors with fragment colors and iterating those resulting values across the multiple pixels of a polygon. Such frame buffer blending involves a large number of reads and writes to the frame buffer 310 and thus directly benefits from the high bandwidth and low latency afforded by the system memory bus 121.

The Z buffer blending module 322 evaluates depth information per fragment of a polygon and iterates the resulting depth information across the multiple pixels. As with color blending, Z buffer blending involves a large number of reads and writes to the frame buffer 310 and similarly benefits from the high bandwidth and low latency of the system memory bus 121.

In one embodiment, the fragment processor 201 is configured to use a Z plane equation coverage value to iterate depth information across multiple pixels of a polygon. In such an embodiment, the depth and orientation of a polygon in 3-D space is defined using a Z plane equation. The Z plane equation is used by the fragment processor 201 to determine depth information for each constituent pixel covered by the polygon, and is a much more compact method of describing depth information for a polygon than by using a list of Z values for each fragment of the polygon. Additional description of Z plane raster operations can be found in commonly assigned U.S. Patent Application “Z PLANE ROP” by Steve Molnar, filed on Jun. 28, 2004, Ser. No. 10/878,460, which is incorporated herein in its entirety.

The compression module 323 compresses and decompresses per pixel data for storage and retrieval from the frame buffer 310. For example, in some rendering operations a given pixel can have multiple value samples, with a number of bits per sample. For example, in a case where each pixel of a display includes 8 sample points, the compression module 323 would compress/decompress the data describing such sample points for easier access to and from the frame buffer 310.

The multi sample expansion module 324 performs multi sample expansion operations on the fragment data. For example, depending upon the application (e.g., anti-aliasing) the sample expansion module 324 can expand sample information from one sample point per pixel into eight sample points per pixel. Thus it is desirable to perform the sample expansion in the fragment processor 201 for storage into the frame buffer 310 as supposed to the GPU 110.

Referring still to FIG. 3, in the present embodiment, texture operations and lighting operations are still performed by the GPU 110 (e.g., module 331 and module 332). The texture operations and lighting operations can proceed much more quickly since the relatively limited bandwidth of the graphics bus 120 is free from the traffic that has been moved to the fragment processor 201.

FIG. 4 shows a diagram depicting information that is transferred from the GPU 110 to the fragment processor 201 and to the frame buffer 310 in accordance with one embodiment of the present invention. FIG. 4 shows a case illustrating the benefits by using the fragment processor 201 to perform Z value iteration and multi sample color expansion in accordance with one embodiment of the present invention. As shown in FIG. 4, the GPU 110 can be configured to transfer pre-expanded color values and Z plane equation coverage values to the fragment processor 201 for iteration and expansion. This results in a very compact transfer of data across the low bandwidth graphics bus 120 to the fragment processor 201.

For example, as opposed to sending individual pixels and their values, the GPU 110 sends fragments to the fragment processor 201. These fragments are pre-expanded. The fragments undergo multi sample expansion within the fragment processor 201. Multi sample expansion is used in applications involving anti-aliasing and the like. A typical multi sampling expansion would take one sample of one fragment and expanded it into four samples (e.g., 4× anti-aliasing) or eight samples (e.g., 8× anti-aliasing). This much larger quantity of data is then transferred to the frame buffer 310 across the high bandwidth system memory bus 121 as opposed to the low bandwidth graphics bus 120. For example, in a typical anti-aliasing application, a given pixel can be expanded from one sample comprising 32 bits into eight samples comprising 32 bits each.

Similarly, the Z plane equation can be expanded into 4×, 8×, etc. samples per pixel by the fragment processor 201 from the plane equation for the original polygon. The resulting expanded Z data is then transferred from the fragment processor 201 across the high bandwidth system memory bus 121 to the frame buffer 310.

FIG. 5 shows a flowchart of the steps of a cooperative graphics rendering process 500 in accordance with one embodiment of the present invention. As depicted in FIG. 5, process 500 shows the basic steps involved in a cooperative graphics rendering process as implemented by a fragment processor (e.g., fragment processor 201) of a bridge (e.g., bridge of 105) and the GPU (e.g., GPU 110) of a computer system (e.g., computer system 100 of FIG. 2).

Process 500 begins in step 501, where the fragment processor 201 receives fragment pre-expanded color values from the GPU 110 via the graphics bus 120. In step 502, the fragment processor 201 performs a multi sample color value expansion for a plurality of pixels. In step 503, the fragment processor 201 receives a Z plane equation coverage value from the GPU 110. In step 504, the fragment processor 201 performs a Z plane iteration process to generate iterated Z values for a plurality of pixels. In step 505, as described above, the fragment processor 201 stores the resulting expanded color values and the resulting expanded Z values into the frame buffer 310 via the high bandwidth system memory bus 121. Subsequently, in step 506, the GPU 110 accesses the expanded color values and expanded Z values to render the image.

The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, and many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the claims appended hereto and their equivalents.