Two phase rendering for computer graphics

Details Two phase rendering for computer graphics Two phase rendering for computer graphics

1998-09-18

2001-01-23

Nguyen, Phu K. (Department: 2772)

Computer graphics processing and selective visual display system

Computer graphics processing

Three-dimension

Reexamination Certificate

active

06177944

ABSTRACT:

TECHNICAL FIELD
This invention relates generally to a computer graphics system for processing and displaying graphical data representing three-dimensional objects and, more particularly, to methods for synchronizing and distribution work assignments in the graphics system consists of a host processor and a graphics adapter.
BACKGROUND OF THE INVENTION
Computer graphics systems are frequently used to model a scene having three-dimensional objects and display the scene on a two-dimensional display device (
31
) such as a cathode ray tube or liquid crystal display. Typically, the three-dimensional objects of the scene are each represented by a multitude of polygons (or primitives) that approximate the shape of the object. Rendering the scene for the display on the two-dimensional display device is a computationally intensive process. It is therefore frequently a slow process, even with today's microprocessors and graphics processing devices.
Referring to
FIG. 1
, a multiprocessor is a machine containing more than one data processor (e.g., host processor (
32
) and geometry processor (
38
)). The processors may be connected to each other by a bus or by a cross bar switch. Each of the processors may have an associated cache memory. The host processor and the geometry processor share a common system memory (
33
) through the bus or cross bar switch and the associated cache (if provided). Each processor may also have a private or local memory (
36
) that is not accessible to the other processors.
Each of the processors of the multiprocessor may execute an associated task. For example, an audio application or task may run on one processor while a video application may run on another processor. In this case each processor executes its task in a substantially independent manner without any strong interaction between the tasks running on the other processors.
In other cases, of most interest to this invention, a single task is partitioned into sub-tasks that are then executed cooperatively on two or more processors by assigning one processor to one sub-task. When several processors cooperate in this manner to execute a single task, they typically need to share, in a fair manner, common resources such as memory, as well as buffers, printers, and other peripherals. In addition, the processors typically need to communicate with one another so as to share information needed at checkpoints, to wait for other processors to complete a certain routine, to signal to other processors that the processor is done with its assigned sub-task, etc.
A master-slave system is the simplest implemented system that supports multiprocessing within a single job. In this master-slave system, a predefined processor is declared the master and is permitted to execute the operating system. The other processors, denoted slaves, may execute only user applications. In practice a master-slave system permits the slaves to perform some easily paralleled operating system functions. Unlike separate supervisors, a master-slave system permits true parallelism within a single job, but only for user applications. The operating system itself is essentially serial, with all but the most trivial functions executed on the unique master processor. For a modest number of processors and a computationally heavy work load, paralleling the user's applications may be adequate, and the master-slave system has the advantage of simplicity over the more ambitious symmetric systems.
The generic 3D graphics system as shown in
FIG. 1
consists of a host processor (
32
) and a graphics adapter (
30
) as a master-slave system with the host processor being the master and the graphics adapter being the slave. For most applications, part of the application runs on the host processor, and the rest runs on the graphics adapter.
FIG. 2
shows the processing steps for rendering an object in a 3D graphics system shown in FIG.
1
. The host creates work items and feeds them to the graphics adapter. With existing schemes the host processor waits for the graphics adapter (
14
) to return a status for the current work item before proceeding with the next work item (
11
) in the application. In such a master-slave system, the application goes through the scene database and sends down a set of objects (
11
) to be rendered along with its material properties, and attributes (
12
) such as location and, rasterization parameters, etc., to the graphics rendering system. See [Foley], which is incorporated herein by reference. Material properties could include shininess, emissivity, ambient color, diffuse color, specular color, texture, of the model. This work is done on the host processor being the master and corresponds to the first 3 boxes on the left column (
11
,
12
,
13
) in FIG.
2
. The graphics rendering is performed on the graphics adapter being the slave, and this rendering corresponds to the work listed in all the boxes on the middle and right columns in FIG.
2
. The graphics adapter receives objects from the host (
15
) and does the following. It first transforms the position of the objects from model coordinates into normalized device coordinates (NDC) (
16
). Referring to
FIG. 3
, the view volume (
31
), defined in NDC, determines which portion of space is visible to the viewer. Objects falling outside the view volume (
41
) are discarded from further processing (trivial rejection). Objects entirely contained in the view volume (
42
) remain unchanged and are sent to the lighting stage (trivial acceptance). Objects that intersect the boundary of the view volume (
43
,
44
) are clipped against the view volume, i.e., split into a portion inside and a portion outside the view volume; the inside portion is then sent to the lighting stage (
19
).
FIG. 3
shows the trivial accept (
42
), trivial reject (
41
), and clipped cases (
43
,
44
). The application sending the objects often can make use of the trivial accept/reject/clip (status) information (
21
of
FIG. 2
) for the object to
1. decide whether other objects need to be sent for the current frame by using hierarchical geometric models or by using inter-object visibility information,
2. decide whether this object needs to be sent for the next frame by using frame to frame coherence,
3. determine whether the object needs to be lighted, and
4. determine the level of tessellation required for the current or next frame.
The status returned could also be used by the host processor in several ways. For example, if previous data was rejected trivially the application may know that current data is also likely to be rejected because of the way the model is stored. So it may then decide to tessellate the current data (i.e., break up the geometric model into triangles) at a coarser level, i.e., with fewer triangles and speed up overall processing. The other rationale for this coarser tessellation is that, even if part of the current data is accepted (not rejected trivially), the triangles for the current data are likely to be near the corner of the viewing region, and the system may render such models with less detail, i.e., with fewer triangles.
Similarly, a status of trivial accept could signal to the application that objects have to drawn with more detail. For example, an application could send down a teapot with 100 triangles, and if the return status says that this teapot was accepted trivially, it can send down the same teapot with 5000 triangles. The teapot sent last would draw on top of the previous teapot. The ratio of accepts to rejects may also help the application to restructure the processing algorithm itself. The application may use bounding boxes around objects and do application level clipping if it knows that a high proportion of the objects are being rejected. If a high ratio of objects is being accepted, the application may turn off bounding box based clipping. Since the application responds to the clipping status as described above, after sending a work item, consisting of a group of objects, the application waits (
14
) for the graphics adapter to return the cli

Affiliated with

Also associated with

Rating

Two phase rendering for computer 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 Two phase rendering for computer graphics, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Two phase rendering for computer graphics will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2532390