Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1997-07-25
2001-11-06
Oberley, Alvin (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C702S108000
Reexamination Certificate
active
06314470
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of The Invention
The present invention relates generally to computer graphics systems and, more particularly, to the evaluation and control of graphics applications in a computer graphics system.
2. Related Art
Computer graphics systems are commonly used for displaying two- and three-dimensional graphics 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 may include, for example, points, lines, 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 objects being represented on the display screen.
The basic components of a computer graphics system typically include a computer graphics library that contains software routines that control graphics hardware in response to function calls issued by a graphics application. The graphics hardware may include, for example, a geometry accelerator, a rasterizer and a frame buffer. The system may also include other hardware such as texture mapping hardware. The geometry accelerator receives primitive data from a graphics application located on the host computer that defines the primitives that make up the model view to be displayed. The geometry accelerator performs transformations on the primitive data and performs such functions as lighting, clipping and plane equation calculations for each primitive. The output of the geometry accelerator, referred to as rendering data, is used by the rasterizer and the texture mapping hardware to generate final screen coordinate and color data for each pixel in each primitive. The pixel data from the rasterizer and the pixel data from the texture mapping hardware are combined and stored in the frame buffer for display on the video display screen.
The graphics library typically provides an application program interface (API) to enable graphics applications executing on the host computer to efficiently control the graphics system. Commonly, the OpenGL® standard is utilized to provide a graphics library API to the graphics system. (OpenGL is a registered trademark of Silicon Graphics, Inc.).
The OpenGL software interface provides specific commands that are used to specify objects and operations to produce interactive, three-dimensional graphics applications. 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 the OPENGL SPECIFICATION, version 1.1 (1997), all of which are hereby incorporated by reference in their entirety. The graphics library may be logically divided into software routines which are accessible through the API and routines or modules which control the graphics pipeline and device specific modules which contain software dedicated to the control of specific implementations of the graphics hardware components.
It is often necessary to evaluate and control the operations of the graphics application which is currently communicating with the graphics system. For example, the integrity of thie graphics application may need to be verified, the timing and efficiency of the graphics application may need to be evaluated, the proper and efficient use of graphics system resources may need to be determined or the extent to which specific aspects of the API are utilized may need to be established. These and other test, evaluation and monitoring operations may need to be performed during the initial design and integration of the graphics application as well as during subsequent modifications to either the graphics application or the graphics system. Conventional systems and techniques for performing such evaluation and control fimctions have been time consuming, inefficient, limited in their diagnostic capabilities and often difficult to use.
Conventional approaches typically include the use of a test and measurement library for providing some type of diagnostic tool access to the computer graphics system. This library is often referred to as an intercept library due to its logical placement between the graphics application that is being evaluated and the released graphics library, such as an OpenGL-conforming graphics library, with which it communicates.
The intercept library has the same set of entry points as the released graphics library. Thus, when implemented, the intercept library replaces the released graphics library and intercepts the graphics API calls generated by the graphics application. When the routines in the intercept library are called they either perform pre-programmed operations and/or interact with a specific diagnostic tool. When their specific processing is completed, the intercept library functions call the released graphics library API entry point to invoke the desired operations within the computer graphics system.
There are number of drawbacks to this approach. A primary drawback is that the intercept library generally does not provide access, or attach, to a currently executing graphics application but instead requires the graphics application to be initiated in a manner that allows subsequent access. For example, in one common approach, the intercept library is implemented as an archived library. In this implementation, the graphics application which is normally linked to the graphics library, must be relinked with the intercept library to provide the intercept library access to the graphics application. In another common approach, the intercept library is implemented as a shared library. In this implementation, the graphics application must be re-initiated so as to load the intercept library rather than the released graphics library. In both implementations, this is often a time-consuming procedure which interferes with the software test and evaluation process, particularly since the test and evaluation process is an interactive one which is repeated often as system faults are identified.
In addition, this conventional approach cannot be implemented when the computer graphics system behaves unexpectedly. When an unanticipated graphics system response occurs during normal operations, the intercept library is unable to assist in the determination of the cause of the behavior since it is not linked to the graphics application during normal operations. The graphics application must be relinked or at least be stopped and reinitiated and the graphics application executed in such a manner so as to recreate the undesirable system response. However, since the nature of such system behavior is unpredictable, the problematic system responses are often difficult to replicate in the evaluation and control mode of operation, such as when performing testing, monitoring or other diagnostic procedures.
Another drawback to this approach is that when the intercept library is present it induces significant performance degradation to the graphics application regardless of whether it is currently performing any evaluatio
Barzee Rex A.
Dugger James G.
Dyer Don W.
Lefebvre Kevin T.
Ward Alan D.
Bullock, Jr. Lewis A.
Hewlett -Packard Company
Oberley Alvin
LandOfFree
System and method for asynchronously accessing a graphics... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for asynchronously accessing a graphics..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for asynchronously accessing a graphics... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2576242