Computer graphics processing and selective visual display system – Computer graphics processing – Three-dimension
Reexamination Certificate
1999-03-17
2002-04-30
Nguyen, Phu K. (Department: 2671)
Computer graphics processing and selective visual display system
Computer graphics processing
Three-dimension
Reexamination Certificate
active
06380935
ABSTRACT:
CROSS REFERENCE TO MICROFICHE APPENDIX
Appendix A, which is part of the present disclosure, is included in a microfiche appendix consisting of 1 sheet of microfiche having a total of 31 frames, and the microfiche appendix is incorporated herein by reference in its entirety. Microfiche Appendix A is a listing of pseudo code for computer programs and related data that can be prepared in the language VERILOG for implementing circuitry including a synchronizer that receives and stores graphics data for the generation of a screen display, for use with one illustrative implementation of this invention as described more completely below.
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
BACKGROUND OF THE INVENTION
A personal computer
10
(
FIG. 1
) includes a graphics processor
14
that generates a display of a three-dimensional (abbreviated as “3D”) image on a screen
11
under the control of a central processing unit
15
. Graphics processor
14
forms the displayed image
19
from graphics primitives describing the surfaces to be displayed (e.g. soda-can
17
and table
18
), and the related render states (such as the soda-can texture and the table texture).
An image displayed on screen
11
is typically formed by colors of a two-dimensional array of picture elements (called “pixels”). The pixel colors are normally generated by an application program being executed by CPU
15
in terms of graphics primitives (e.g. triangles and strips) that define the boundaries of various surfaces in the image, and states (also called “render states”, e.g. texture, culling, and fog) that define the appearance of the to-be-displayed surfaces (e.g. brick, fur etc). CPU
15
normally specifies each graphics primitive in terms of its vertices. Moreover, CPU
15
specifies each state as two parts: a token (containing a name, such as fog), and a value (such as “on”).
A description (hereinafter “graphics API”) of the format of such states, commands, and primitives is provided in a book entitled “Graphics Programming with Direct 3D Techniques and Concepts” by Rob Glidden, Addison-Wesley Developers Press, Reading, Mass., 1997. For additional information, see the books (1) “OpenGL Reference Manual, The Official Reference Document for OpenGL, Release 1,” by OpenGL Architecture Review Board, Addison-Wesley Publishing Company, Reading, Mass., 1992 and (2) “OpenGL Programming Guide, Second Edition, The Official Guide to Learning OpenGL, Version 1.1,” by OpenGL Architecture Review Board, Addison-Wesley Developers Press, Reading, Mass., 1997.
In an example using the just-described API, when an image of soda-can
17
on table
18
is to be displayed, an application program executed by CPU
15
specifies one or more render commands, for example a “background” command that sets background to a certain color. Such commands may be followed by one or more primitives for soda-can
17
. Between a command and a primitive, the application program may specify one or more render states for soda-can
17
, such as a “texture” state that indicates the memory address of a texture to be applied to a subsequent soda-can primitive to generate a display of soda-can
17
. The graphics data (commands, render states, and primitives) that are generated by the application are normally processed by another program (called “graphics driver”) that is executed by CPU
15
.
In a tiled architecture, graphics processor
14
divides screen
11
into rectangular areas (called “tiles”) T
1
-TN, and each tile TI contains a number of pixels (e.g. 16 pixels) that form a portion of the displayed image. Each tile TI is held and processed one at a time in an on-chip memory (not labeled) included in graphics processor
14
(FIG.
1
). Tiles T
1
-TN can be of any rectangular shape, but typically might be 32 pixels high and 32 pixels wide. For a screen having 640×480 pixels, there may be 300 tiles arranged in a rectangle that is 20 tiles wide and 15 tiles high. As only one tile TI is held and processed at any time by graphics processor
14
, a given record (of render states and commands) must be sent N times by CPU
15
, once for each tile TI that is currently being processed.
SUMMARY OF THE INVENTION
In accordance with the invention, a method is performed in a computer graphics system (also called “graphics system”) to temporarily store at least two kinds of graphics data (namely graphics primitives and render commands) in two kinds of buffers. Specifically, render commands (e.g. clearing of z-buffer, no-op indicating that no operation is to be performed in the current cycle, and setting of background color) are stored in a common buffer (also called “broadcast buffer”) for later processing of the commands repetitively (once per tile, wherein the screen is subdivided into a number of tiles). The broadcast buffer is separate and distinct from a set of buffers (also called “tile buffers”) that are also included in the graphics system, each tile buffer corresponding to a specific tile in the screen.
A graphics primitive (e.g. a triangle or a strip that defines the boundary of a surface in an image to be displayed on a screen of the graphics system) is stored in one or more of the tile buffer(s). The one or more primitive(s) stored in a tile buffer are used to generate colors for pixels in the corresponding tile, so that a display of all tiles displays the image on the screen. In one embodiment, the graphics primitive (or a portion thereof) is stored in only buffers for those tiles that are affected by the primitive, although in an alternative embodiment the graphics primitive may be stored in all tile buffers. Use of a broadcast buffer that is used to hold render commands for all tiles eliminates the need for redundant storage of the render commands in each tile buffer, and therefore reduces the memory otherwise required in the graphics system.
On storage of a render command and also on storage of a graphics primitive, a graphics processor included in the graphics system normally stores additional information, e.g. a switch command in the broadcast buffer, and a switch command in one or more tile buffers (depending on the implementation the switch command may be stored either prior to or subsequent to storage of a packet or portion thereof in the respective buffer). During retrieval, the graphics processor uses the stored additional information to establish an order among the render commands and the graphics primitives, e.g. so that the graphics processor retrieves the commands and primitives from the respective buffers in the same order as the order in which the graphics processor received the commands and primitives relative to one another.
During retrieval of graphics data in the above-described example, on encountering a switch command in either type of buffer, the graphics processor switches to retrieving graphics data from the other type of buffer. For example, on encountering a switch command in a tile buffer, the graphics processor switches to retrieving graphics data from the broadcast buffer, and vice versa (i.e. bounces back and forth in a “ping pong” fashion). In the example, the graphics processor switches between the tile buffer and the broadcast buffer until reaching the end of one of these buffers, and thereafter retrieves any remaining graphics data from the other of these buffers, ignoring any further switch commands. Therefore, on retrieval, the graphics data (e.g. commands) from the broadcast buffer is interleaved with graphics data (e.g. primitives) from a tile buffer, and the interleaved graphics data is processed further in the normal manner, e.g. in the rendering of pixels for a tile.
Specifically, in one embodiment, a binning engine included in the graphics processor stores one or more packet(s) each containing
Heeschen Scott C.
Zhu Ming Benjamin
Nguyen Phu K.
Nvidia Corporation
Townsend and Townsend / and Crew LLP
LandOfFree
circuit and method for processing render commands in a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with circuit and method for processing render commands in a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and circuit and method for processing render commands in a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2914923