Computer graphics processing and selective visual display system – Computer graphics processing – Three-dimension
Reexamination Certificate
1999-03-17
2001-11-27
Nguyen, Phu K. (Department: 2671)
Computer graphics processing and selective visual display system
Computer graphics processing
Three-dimension
Reexamination Certificate
active
06323860
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 render state controller 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 geometry of surfaces to be displayed (e.g. soda-can
17
and table
18
), and render states (such as the soda-can texture and the table texture) that indicate the colors to be displayed in the surfaces.
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 render states (e.g. texture, culling, and fog) that define the appearance of the surfaces (e.g. brick, fur, etc). CPU
15
normally specifies each graphics primitive in terms of its vertices. Moreover, CPU
15
specifies each render state as two parts: a name (such as texture), and a value (such as brick).
A description (hereinafter “graphics API”) of the format of such render states and primitives is provided in a book entitled “OpenGL Reference Manual, The Official Reference Document for OpenGL, Release 1,” by OpenGL Architecture Review Board, Addison-Wesley Publishing Company, Reading, Massachusetts, 1992. See also the related book entitled “OpenGL Programming Guide” by Jackie Neider, Tom Davis, and Mason Woo, Addison-Wesley Publishing Company, Reading, Massachusetts, and another book entitled “3D Computer Graphics: A User's Guide for Artists and Designers” by Andrew S. Glassner, Design Press, New York.
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 states for soda-can
17
, followed by one or more primitives for soda-can
17
, and thereafter specifies one or more render states for table
18
, followed by one or more primitives for table
18
.
According to the API, the definition of render states is “sticky” in the sense that once a render state is specified, that render state need not be specified again until changed, i.e. each render state is effective for all graphics primitives that follow the render state, until the render state is changed. Therefore, if image
19
is to be shown as foggy, the application program being executed by CPU
15
merely turns on the fog state once, prior to specifying the soda-can primitives, and the fog state remains effective for the table primitives even though not explicitly specified. The graphics data (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
. CPU
15
(when programmed with the graphics driver) “binds” the render states to the primitives by supplying these data together to graphics processor
14
.
In a tiled architecture, graphics processor
14
divides screen
11
into rectangular areas (called “tiles”) T
1
-TP, 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
-TP 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.
SUMMARY OF THE INVENTION
In accordance with the invention, a controller (also called “render state controller”) included in a graphics processor performs a method to postpone the processing of one or more changes in render states (also called “modes”) that are being received from a central processing unit (CPU) until after one or more tiles that are affected by a graphics primitive are identified (e.g. by use of a bounding box around the primitive to identify tiles within the bounding box, or by visiting an area enclosed by vertex tiles and edge tiles of the primitive, to identify only tiles covered by the primitive in a precise manner).
In one embodiment, the render state controller implements the method by: (1) storing the value(s) of one or more render state(s), (2) receiving one or more primitive(s) affected by the render state(s), (3) with respect to a tile that is affected by a received primitive, identifying from among all render states, those render states whose values have changed (relative to values previously associated with that affected tile), (4) retrieving the value(s) of the changed render state(s), and (5) associating the affected tile with the value(s) of the render state(s) identified as having changed. In this embodiment, the just-described acts (3)-(5) are repeated for each tile that is affected by each received primitive, so that only the changed render states for the affected tiles are associated with each primitive.
In one implementation, the render state controller performs the just-described acts (1)-(5) on graphics data for a frame that is subsequent to another frame currently being rendered by a rendering pipeline that processes graphics data one tile at a time. In another implementation, the render state controller performs the just-described acts (1)-(5) on graphics data for a frame that is same as the frame currently being rendered by a rendering pipeline that operates on two or more tiles simultaneously (e.g. the rendering pipeline may include a number of tile renderers, each tile renderer operating on a single tile or on tiles in a single column (or row) of the screen).
Delaying the processing of render state changes (by use of a technique referred to as “deferred render state binding”) until after identification of affected tiles and until after identification of changed render states eliminates the need to later on process (e.g. during rendering) render state(s) for one or more tiles that are not affected by a primitive, and render state(s) that have not changed, thus saving the down-stream processing power and memory bandwidth that would be otherwise required. Therefore, deferred render state binding eliminates the need to process every change in render state for every tile (as required in the prior art). Instead, only the changes in render state(s) for affected tiles are processed as described herein.
In one example, a primitive for a soda-can fits within a tile in the upper-left corner of the screen, and the soda-can primitive and the render state changes (such as the soda-can texture) are not further processed (in one implementation) for the remaining tiles in the screen, such as the tile in the lower-right corner of the screen. In this example, if there are 300 tiles in the screen, the down-stream processing of primitive and render state changes is eliminated for 299 tiles (because such proce
Heeschen Scott C.
Zhu Ming Benjamin
Nguyen Phu K.
Nvidia Corporation
Townsend and Townsend / and Crew LLP
LandOfFree
Circuit and method for deferring the binding of render... 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 deferring the binding of render..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Circuit and method for deferring the binding of render... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2591261