Computer graphics processing and selective visual display system – Computer graphic processing system – Plural graphics processors
Reexamination Certificate
2000-06-09
2004-01-13
Tung, Kee M. (Department: 2676)
Computer graphics processing and selective visual display system
Computer graphic processing system
Plural graphics processors
C345S541000, C345S552000
Reexamination Certificate
active
06677952
ABSTRACT:
BACKGROUND AND SUMMARY OF THE INVENTION
The present application relates to computer graphics rendering systems and methods, and particularly to handling of texture data used by rendering accelerators for 3D graphics.
Background: 3D Computer Graphics
One of the driving features in the performance of most single-user computers is computer graphics. This is particularly important in computer games and workstations, but is generally very important across the personal computer market.
For some years the most critical area of graphics development has been in three-dimensional (“3D”) graphics. The peculiar demands of 3D graphics are driven by the need to present a realistic view, on a computer monitor, of a three-dimensional scene. The pattern written onto the two-dimensional screen must therefore be derived from the three-dimensional geometries in such a way that the user can easily “see” the three-dimensional scene (as if the screen were merely a window into a real three-dimensional scene). This requires extensive computation to obtain the correct image for display, taking account of surface textures, lighting, shadowing, and other characteristics.
The starting point (for the aspects of computer graphics considered in the present application) is a three-dimensional scene, with specified viewpoint and lighting (etc.). The elements of a 3D scene are normally defined by sets of polygons (typically triangles), each having attributes such as color, reflectivity, and spatial location. (For example, a walking human, at a given instant, might be translated into a few hundred triangles which map out the surface of the human's body.) Textures are “applied” onto the polygons, to provide detail in the scene. (For example, a flat carpeted floor will look far more realistic if a simple repeating texture pattern is applied onto it.) Designers use specialized modelling software tools, such as 3D Studio, to build textured polygonal models.
The 3D graphics pipeline consists of two major stages, or subsystems, referred to as geometry and rendering. The geometry stage is responsible for managing all polygon activities and for converting three-dimensional spatial data into a two-dimensional representation of the viewed scene, with properly-transformed polygons. The polygons in the three-dimensional scene, with their applied textures, must then be transformed to obtain their correct appearance from the viewpoint of the moment; this transformation requires calculation of lighting (and apparent brightness), foreshortening, obstruction, etc.
However, even after these transformations and extensive calculations have been done, there is still a large amount of data manipulation to be done: the correct values for EACH PIXEL of the transformed polygons must be derived from the two-dimensional representation. (This requires not only interpolation of pixel values within a polygon, but also correct application of properly oriented texture maps.) The rendering stage is responsible for these activities: it “renders” the two-dimensional data from the geometry stage to produce correct values for all pixels of each frame of the image sequence.
The most challenging 3D graphics applications are dynamic rather than static. In addition to changing objects in the scene, many applications also seek to convey an illusion of movement by changing the scene in response to the user's input. Whenever a change in the orientation or position of the camera is desired, every object in a scene must be recalculated relative to the new view. As can be imagined, a fast-paced game needing to maintain a high frame rate will require many calculations and many memory accesses.
FIG. 2
shows a high-level overview of the processes performed in the overall 3D graphics pipeline. However, this is a very general overview, which ignores the crucial issues of what hardware performs which operations.
Hardware Acceleration
Since rendering is a computationally intensive operation, numerous designs have offloaded it from the main CPU. An example of this is the GLINT chip described below.
Parallelism in Graphics Processing
Due to the large number of at least partially independent operations which are performed in rendering, many proposals have been made to use some form of parallel architecture for graphics (and particularly for rendering). See, for example, the special issue of Computer Graphics on parallel rendering (September 1994). Other approaches may be found in earlier patent filings by the assignee of the present application and its predecessors, e.g. U.S. Pat. No. 5,195,186, all of which are hereby incorporated by reference.
The “GLINT” Pipelined Rendering Architecture
A pioneering development in rendering architectures was described in U.S. Pat. No. 5,594,854. The GLINT▪ architecture provides a graphics processing chip which uses a deep pipeline of multiple asynchronous units, separated by FIFOs, to achieve a high net throughput in 3D rendering. Besides the output interface to the frame buffer, a separate interface is to a local buffer which can be used for data manipulation (such as Z-buffering). Preferably reads and writes to the local buffer are provided by separate stages of the pipeline. Preferably some of the individual units include parallel paths internally. Preferably some of the individual units are connected to look ahead by more than one stage, to keep the pipeline filled while minimizing the use of expensive deep FIFOs.
The message-passing architecture of the presently preferred embodiment provides a long pipeline, in which the individual stages of the pipeline operate asynchronously. To optimize performance, stages of the pipeline may have internally parallel structure. (However, this is a basically quite different processing paradigm from the parallel rendering environments being explored by many workers.)
Where possible, data is kept on chip (registered) between blocks. However, of course, memory access is sometimes necessary. Thus, although most of the blocks are two-port blocks, some are multi-port to permit memory access. FIFO buffering is typically used for interface between the blocks. In many cases, one-deep FIFO's can be used, with appropriate look-ahead connections for timing control. However, in other stages, significantly deeper FIFO's are used, to avoid “bubbles” in the pipeline and optimize processor utilization.
The overall architecture of this innovative chip is best viewed using the software paradigm of a message passing system. In this system all the processing blocks are connected in a long pipeline with communication with the adjacent blocks being done through message passing. Between each block there is a small amount of buffering, the size being specific to the local communications requirements and speed of the two blocks.
The message rate is variable and depends on the rendering mode. The messages do not propagate through the system at a fixed rate typical of a more traditional pipeline system. If the receiving block can not accept a message, because its input buffer is full, then the sending block stalls until space is available.
The message structure is fundamental to the whole system as the messages are used to control, synchronize and inform each block about the processing it is to undertake. Each message has two fields—a data field and a tag field. The data field will hold color information, coordinate information, local state information, etc. The tag field is used by each block to identify the message type so it knows how to act on it.
A particular advantage of this architecture is that it inherently provides a very high degree of design for testability. Moreover, this is achieved without adding any special diagnostic hardware paths or registers. By providing appropriate commands to the chip, any desired input can be sent to any block within the pipeline. Thus modifications to the architecture can be tested very rapidly, and debugging can rapidly pinpoint any faults which may be present.
A particular advantage of this architecture is that it permits a very efficient test strat
3Dlabs Inc. Ltd.
Groover III Robert O.
Tung Kee M.
LandOfFree
Texture download DMA controller synching multiple... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Texture download DMA controller synching multiple..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Texture download DMA controller synching multiple... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3257637