Computer graphics processing and selective visual display system – Computer graphics display memory system – Addressing
Reexamination Certificate
1999-08-31
2003-02-11
Tung, Kee M. (Department: 2671)
Computer graphics processing and selective visual display system
Computer graphics display memory system
Addressing
C711S203000, C345S545000
Reexamination Certificate
active
06518973
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention relates to computer graphics processing, and more particularly to the transfer of graphics data to a rendering subsystem.
2. Related Art
In a typical graphics system, graphics commands and data are created by a host processor in accordance with an application program. This information, known collectively hereinafter as graphics data, must then be transferred to graphics processing components which render an image based on the graphics data. A typical graphics system therefore comprises a host processor connected to a rendering subsystem. When transferring graphics data from a host processor to a rendering subsystem, some graphics systems use system memory as intermediate storage.
This is illustrated in FIG.
1
. Graphics system
100
comprises a host processor
105
. System memory
110
is connected to host
105
. As host
105
creates graphics data
115
in accordance with an application program, graphics data
115
is sent to memory
110
for storage. Host processor
105
is also connected to geometry engine
112
. Geometry engine
112
constitutes an initial processing module of the rendering subsystem. At appropriate intervals, host
105
will send a read command
120
to geometry engine
112
. Read command
120
serves to instruct the geometry engine
112
to read graphics data
115
from memory
110
. This effects the transfer of graphics data
115
from host
105
to geometry engine
112
. Geometry engine
112
can then process graphics data
115
to produce output
125
. Output
125
is then sent to subsequent modules in the rendering subsystem.
Memory
110
is illustrated in greater detail in FIG.
2
. Memory
110
comprises a plurality of graphics buffers. Two of these graphics buffers are illustrated in
FIG. 2
, a graphics buffer
205
and a graphics buffer
210
. Each comprises a series of memory locations. Graphics buffer
205
comprises memory locations
205
A through
205
n
. Likewise, graphics buffer
210
comprises memory locations
210
A through
210
n
. Each graphics buffer receives and stores graphics data from a host processor, pending subsequent access by a geometry engine.
Note that any graphics buffer has a finite size. Any attempt to write beyond the last location in a graphics buffer could result in the loss of graphics data. Hence, in current graphics systems that use buffering, an application that writes data to a graphics buffer must be aware of the size limitation of the graphics buffer. In particular, an application that writes data to a graphics buffer must repeatedly check on the amount of space remaining in a graphics buffer. If insufficient space is available in, say, graphics buffer
205
, then the write operation must be redirected to a new buffer, such as graphics buffer
210
.
This checking operation slows the transfer of graphics data from a host processor to a geometry engine. The transfer process is illustrated in
FIG. 3. A
transfer process
300
serves to transfer graphics data from a host processor to a geometry engine by way of graphics buffers in memory. Process
300
begins with a step
305
. In a step
310
, a value is obtained for the current pointer, representing the address of the next available memory location in a graphics buffer. This must be done before writing graphics data to the graphics buffer. In a step
315
, the address of the last memory location in the graphics buffer is obtained. This is the graphics buffer end address. Knowing the graphics buffer end address allows the application to be aware of the location in the graphics buffer beyond which the application must not write. In a step
320
the application obtains the size of the graphics data block that will be produced by the pending graphics command. This value represents the amount of memory that will be required by the pending command.
In a step
325
the value of the current pointer is added to the size of the graphics data block that will be produced by the pending command. This sum is compared to the graphics buffer end address. If the sum is less than the graphics buffer end address, there is sufficient space remaining in the graphics buffer to hold the graphics data of the pending command. Processing would then proceed to step
330
, in which the graphics data is written to the graphics buffer. In a step
335
the value of the current pointer is updated. The current pointer now indicates the position of the next available memory address in the graphics buffer. In a step
340
a query is made as to whether there is another command to be processed. If so, the process
300
returns to step
320
. In step
320
, the size of the memory requirement for the next command is obtained. If there is no additional command indicated in step
340
, then the process concludes with a step
345
.
If, in step
325
, it is determined that there was insufficient memory remaining in the current graphics buffer to contain the graphics data from the pending command, then processing continues at a step
350
. In step
350
, the contents of the graphics buffer are sent to the rendering subsystem. To send the contents of a graphics buffer to the rendering subsystem, a read command is issued by the host processor to the geometry engine. The geometry engine then reads the buffered graphics data.
In a step
360
a new graphics buffer is allocated to store the graphics data from the pending command, since there was insufficient capacity in the original graphics buffer. In a step
365
the current pointer is reset to point to the first available address in the new graphics buffer. The process then returns to step
315
. Here, the graphics buffer end address for the new graphics buffer is obtained.
Process
300
, however, can be slow. For every graphics command that must be processed, step
325
must be performed. Therefore, for every command, the amount of memory needed must be compared to the amount of memory available. This requires an arithmetic check before each command can be processed. Moreover, there is a branch in the processing of each command, illustrated as step
325
. If the logic of process
300
is implemented in software, step
325
represents a conditional branch instruction. Branching tends to be time consuming in modern computer architectures. Processors typically attempt to anticipate which branch will be chosen, and do a prefetch on the anticipated instructions. An incorrect guess by the processor means that the instructions in the anticipated branch must be discarded, and instructions from the other branch must be loaded. Hence, in light of the branching and arithmetic checking which must be performed for every graphics command, current graphics processing architectures that operate in the manner of process
300
tend to be time consuming.
What is needed, therefore, is a more efficient way to transfer graphics data from a host processor to a rendering subsystem in systems which use memory to buffer graphics data.
SUMMARY OF THE INVENTION
The invention provides a method, system, and computer program product for managing the efficient transfer of graphics data to a graphics rendering system. A graphics application program writes graphics data to graphics buffers that are allocated in virtual memory. Each graphics buffer comprises a plurality of memory locations, followed by a sentinel page. While the application is writing graphics data to a graphics buffer, a sentinel page at the end of the graphics buffer may be reached. If so, the operating system recognizes this condition as a graphics buffer page fault. In responding to this fault, the contents of the graphics buffer are transferred to the graphics rendering subsystem. In addition, the graphics data being output by the application is redirected to another graphics buffer.
Features and Advantages
The invention has the feature of incorporating a sentinel page in each graphics buffer. The invention has the additional feature of using the page fault handling process of a virtual memory operating system to facilitate efficient data transfer.
Th
Microsoft Corporation
Tung Kee M.
Woodcock & Washburn LLP
LandOfFree
Method, system, and computer program product for efficient... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method, system, and computer program product for efficient..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method, system, and computer program product for efficient... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3149686