Computer graphics processing and selective visual display system – Computer graphic processing system – Graphic command processing
Reexamination Certificate
1999-01-19
2002-03-26
Chauhan, Ulka J. (Department: 2671)
Computer graphics processing and selective visual display system
Computer graphic processing system
Graphic command processing
C345S553000, C345S520000
Reexamination Certificate
active
06362825
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to graphics systems and, more particularly, to graphics system performance optimization techniques.
2. Related Art
Computer graphics systems are commonly used for displaying two- and three-dimensional graphical representations of objects on a two-dimensional video display screen. Current computer graphics systems provide highly detailed representations and are used in a variety of applications.
In a typical computer graphics system, an object or model to be represented on the display screen is broken down into graphics primitives. Primitives are basic components of a graphics display and include, for example, points, lines, triangles, quadrilaterals, triangle strips and polygons. Typically, a hardware/software scheme is implemented to render, or draw, the graphics primitives that represent a view of one or more models being represented on the display screen.
Generally, primitives of a three-dimensional object to be rendered are defined by a host computer in terms of primitive data. For example, when the primitive is a triangle, the host computer may define the primitive in terms of the X, Y, Z and W coordinates of its vertices, as well as the red, green and blue and alpha (R, G, B and &agr;) color values of each vertex. Additional primitive data may be used in specific applications. Rendering hardware interprets the primitive data to compute the display screen pixels that represent each primitive, and the R, G and B color values for each pixel.
A graphics interface is typically provided to enable graphics applications located on the host computer to efficiently control the graphics system. The graphics interface provides specific commands that are used by a graphics application executing on the host computer to specify objects and operations, producing an interactive, three-dimensional graphics environment. Such a graphics interface is typically implemented with software drivers.
For example, the OpenGL® standard defines an application program interface (API) that provides specific commands that are used to specify objects and operations to produce interactive, three-dimensional applications. (OpenGL is a registered trademark of Silicon Graphics, Inc.). OpenGL is a streamlined, hardware-independent interface designed to be implemented on many different hardware platforms. As such, in computer systems which support OpenGL, the operating systems and graphics application software programs can make calls to the computer graphics system according to the standardized API without knowledge of the underlying hardware configuration. The OpenGL standard provides a complete library of low-level graphics manipulation commands for describing models of three-dimensional objects (the “GL” of OpenGL refers to “Graphics Library”). This standard was originally based on the proprietary standards of Silicon Graphics, Inc., but was later transformed into an open standard which is used in high-end graphics-intensive workstations and, more recently, in high-end personal computers. The OpenGL standard is described in the OPENGL PROGRAMMING GUIDE, version 1.1 (1997), the OPENGL REFERENCE MANUAL, version 1.1 (1997), and a book by Segal and Akeley (of SGI) entitled THE OPENGL GRAPHICS SYSTEM: A SPECIFICATION (Version 1.2), all of which are hereby incorporated by reference in their entirety.
A graphics system typically maintains state values that represent the current state of various aspects of object models. Graphics systems generally behave as a state machine; a specified state value remains in effect until it is changed by the graphics application through the issuance of an API command, also referred to herein as a graphics call, to the graphics system through the graphics software interface. Thus, all vertices are rendered in accordance with a current value of applicable state variables in the graphics system.
By providing detailed control over the manner in which primitives and their vertices are rendered in the graphics system, the graphics software interface provides software developers with considerable flexibility in creating graphics application software programs. A graphics software application may be structured in any one of many different configurations to implement a desired function or to achieve a desired result in the graphics system. For example, graphics applications may generate a different graphics call sequence to achieve the same rendering of the same model.
It is well known that some graphics call sequences and the manner in which primitives, vertices and states specified in the sequence are implemented are more efficient than others. That is, although multiple graphics applications may achieve the same rendering of the same model, certain graphics applications may, due to the contents of the graphics call sequence that they generate, cause the graphics system to perform unnecessary operations, or to perform certain operations in a manner that requires greater overhead than is otherwise necessary.
Generally, graphics call sequences generated by a graphics application are stored in a memory prior to being executed by the graphics system. When stored for execution by the graphics system, such graphics call sequences are commonly referred to as a display list. The memory dedicated to the temporary storage of these graphics call sequences is commonly referred to as a display list memory. In conventional graphics systems, overhead is associated with the storage of these graphics call sequences in the display list memory (“storage overhead”). For example, when generating a single graphics primitive using the OpenGL graphics library, a glBegin() graphics call is first issued to indicate the start of a particular type of the primitive. The glBegin() graphics call is followed by an appropriate number of glVertex() graphics calls specifying the vertices of the identified primitive, followed by a glEnd() graphics call to indicate the end of the primitive. A number of different graphics calls may be located between a glBegin()/glEnd() graphics call pair. Such graphics calls include graphics vertex calls as well as graphics calls that set state variables. All such graphics calls are referred to herein as vertex-related graphics calls. The glBegin()/glEnd() pair and all graphics calls interposed between the two are collectively and generally referred to herein as a primitive data set. Other graphics calls that do not occur between a glBegin() and glEnd() graphics call are referred to herein as non-vertex-related graphics calls. One particular type of non-vertex-related graphics call are graphics calls that alter the modal state of the graphics system. A primitive data set representing, for example, a single independent triangle, includes a glBegin() call, followed by three glVertex() calls to generate the three vertices of the triangle primitive, followed by a glEnd() call. As a result, five graphics calls or commands are processed to generate a single triangle primitive. All five of these commands in the primitive data set are stored in the display list memory. A display list generated by a typical graphics application often contains millions of graphics primitive data sets. The overhead associated with the storage of a large number of primitive data sets in the display list memory can impose a significant burden on the efficiency of the graphics system.
Furthermore, when a primitive data set is executed, execution of the glBegin() command at the beginning of each primitive data set typically incurs some execution overhead by the graphics system, such as verifying the validity of the identified primitive, and configuring the graphics hardware to render the specified primitive. Thus, the total execution overhead associated with executing the glBegin() commands in a typical graphics call sequence can be significant.
Some graphics system optimization schemes perform post-processing of the display list subsequent to its generation by an application program. Such post-processing techniques generally requ
LandOfFree
Real-time combination of adjacent identical primitive data... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Real-time combination of adjacent identical primitive data..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Real-time combination of adjacent identical primitive data... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2860179