Electrical computers and digital processing systems: multicomput – Computer-to-computer protocol implementing – Computer-to-computer data transfer regulating
Reexamination Certificate
2000-01-31
2003-09-09
Najjar, Saleh (Department: 2154)
Electrical computers and digital processing systems: multicomput
Computer-to-computer protocol implementing
Computer-to-computer data transfer regulating
C709S201000, C345S522000, C345S215000, C345S215000
Reexamination Certificate
active
06618759
ABSTRACT:
FIELD OF THE INVENTION
This invention relates generally to the field of computer graphics. More particularly, the invention relates to performing 3D graphics operations efficiently in a networked environment.
BACKGROUND
OpenGL in Networked Environments. OpenGL is a standard application programmer's interface (“API”) to hardware that accelerates 3D graphics operations. OpenGL is intended to be used with window systems such as the X Window System. In order that OpenGL may be used in an X Window System environment, an extension to the X Window System has been developed called GLX. For more complete information on the GLX extension to the X Window System and on how OpenGL can be integrated with the X Window System, see for example Mark K. Kilgard,
OpenGL Programming for the X Window System
(Addison-Wesley Developers Press 1996).
FIG. 1
illustrates a typical prior art implementation wherein single-screen 3D accelerated graphics operations are performed over a network in an X Window System environment. Two computer systems are used. Client host
100
is connected to server host
102
via LAN
104
or some other suitable network or system connection. As can be seen from the drawing, three processes are running on hosts
100
and
102
: An OGL/X client process
1806
runs on client host
100
. An X server process
108
and an OGL daemon process
110
process run on server host
102
. (For more information on this three-process model, see Kevin T. Lefebvre, et al., “An Overview of the HP OpenGL Software Architecture,” Hewlett-Packard Journal Vol. 49, No. 2, pp. 9-18 (May 1998), which article is hereby incorporated by reference in its entirety.) X server process
108
is one that includes the GLX extension. Both OGL/X client
106
and OGL daemon
110
have an OpenGL implementation that includes a device independent (“DI”) OGL layer
112
and a device dependent (“DD”) OGL layer
114
.
The purpose of OGL DI layer
112
and OGL DD layer
114
is to execute OpenGL commands and to drive 3D accelerated display hardware
116
. OGL DI layer
112
has one set of routines for local rendering and another set of routines for rendering over network
104
. The local versus remote modes are initialized by loading pointers to the desired set of routines in a dispatch table in OGL/Xlib dispatch layer
118
. Each OGL command that comes from application
120
will point to a particular entry in the dispatch table. By placing a different pointer in that entry, a different routine may be used to implement the OGL command corresponding to that entry. (For a more detailed discussion of this kind of dispatch table indirection, see for example U.S. Pat. No. 5,321,808, titled “Dual Process Display Server,” by Lawrence E. Rupp, which patent is hereby incorporated by reference in its entirety.)
In the example of
FIG. 1
, if the local mode is chosen, then OGL commands issued by application
120
will be rendered directly on the display hardware
116
that is coupled to host
1800
. But if the remote mode is chosen, as it would be in a networked environment, then OGL commands issued by application
120
will be routed to X server process
108
using the GLX extension protocol. From there, they are routed to OGL daemon process
110
which executes them and renders the result on the display hardware
116
coupled to server host
102
.
Network Bandwidth Conservation. When OpenGL is being used in remote mode in a networked environment such as that shown in
FIG. 1
, it is common for a great deal of traffic to pass from client host
100
to server host
102
over network connection
104
. This is particularly true in single-logical-screen applications wherein a single client host issues commands to numerous server hosts over the network. For this reason, network bandwidth can become an important performance limiter in many applications.
Command Buffering. One technique that has been employed in the past to conserve network bandwidth in this context has been the technique of buffering OpenGL commands within client host
100
before they are transmitted to server host
102
. For example, in
FIG. 1
, outgoing commands are buffered within client-side OGL command buffer
122
, which buffer is created and managed by client-side GLX library
123
. On the server side, incoming OGL commands are buffered in server-side OGL command buffer
124
. GLX extension
125
within X server process
108
creates, manages and fills server-side shared memory OGL command buffer
124
. OGL daemon
110
has a shared memory connection to OGL command buffer
124
, as shown at
126
. It uses shared memory connection
126
to read OGL command buffer
124
so that it can execute the commands stored therein. A direct inter-process connection between OGL daemon
110
and X server process
108
also exists, as shown at
126
. Using direct inter-process connection
126
, X server process
108
can, for example, communicate to OGL daemon
110
when shared memory OGL command buffer
124
is ready to be read.
A typical server-side process for receiving and consuming command buffers is summarized in the flow diagram of FIG.
2
. In step
200
, a new command buffer is received in server host
102
. Steps
202
,
204
and
206
represent a loop wherein a server side process repeatedly extracts commands from the received command buffer one at a time and executes them. When the buffer is completely consumed, a new buffer is received again in step
200
.
In higher-end applications requiring very high network bandwidth, multiple command buffers may be employed to further enhance performance. Such a multiple-buffer arrangement is described by Kevin Lefebvre, et al. in U.S. patent application Ser. No. 09/138,456, filed Aug. 21, 1998, titled “3D Graphics in a Single Logical Screen Display Using Multiple Remote Computer Systems,” now U.S. Pat. No. 6,249,299, which patent application is hereby incorporated by reference in its entirety.
Creation of Array Function Calls Downstream of the Application. Another technique that has been used to conserve network bandwidth has been the technique of converting vertex function calls issued by application software
120
into array function calls before transmitting them to server host
102
. Not only do array function calls conserve network bandwidth relative to vertex function calls, but they also yield faster rendering performance.
FIG. 3
is a flow diagram illustrating this technique according to a method described by Roland Hochmuth, et al. in U.S. patent application Ser. No. 09/302,659, filed Apr. 30, 1999, titled “Adaptive Buffering of Computer Graphics Vertex Commands,” now U.S. Pat. No. 6,337,689, which patent application is hereby incorporated by reference in its entirety. Among the OpenGL commands issued by application software
120
are: (1) vertex API commands
300
, also known as “VAPI commands,” such as glBegin, glVertex and glEnd; (2) glDrawArrays commands
302
; and (3) glDrawArraySet commands
304
. VAPI command routines
306
are used to buffer the information contained in VAPI commands
300
into data structures that can be used by a glDrawArrays function call. Similarly, glDrawArrays command routines
308
are used to buffer information contained in glDrawArrays commands
302
, as well in the structures created by VAPI command routines
308
, into data structures that can be used by a glDrawArraySet function call. Finally, glDrawArraySet routines
310
buffer glDrawArraySet function calls into client-side command buffer
122
. Periodically, client-side command buffer
122
is flushed to one or more server hosts
102
using network connection
104
.
The functionality of VAPI routines
306
is described in more detail by Hochmuth et al., supra, at
FIGS. 3-4
therein and in the accompanying text. The functionality of glDrawArrays routines
302
is described in more detail by Hochmuth et al., supra, at
FIGS. 5-14
therein and in the accompanying text. The functionality of glDrawArraySet routines
310
is described in more detail in both Hochmuth et al., supra, and in the Lefebvre et al. patent applicati
Brown John M
Lefebvre Kevin
Hart Kevin M.
Hewlett--Packard Development Company, L.P.
Najjar Saleh
LandOfFree
Immediate mode computer graphics command caching does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Immediate mode computer graphics command caching, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Immediate mode computer graphics command caching will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3105260