Computer graphics processing and selective visual display system – Computer graphics display memory system – Display list memory
Reexamination Certificate
1998-12-15
2002-01-15
Chauhan, Ulka J. (Department: 2671)
Computer graphics processing and selective visual display system
Computer graphics display memory system
Display list memory
C345S558000, C345S565000
Reexamination Certificate
active
06339427
ABSTRACT:
FIELD OF THE INVENTION
The invention relates generally to graphics processors and more particularly to graphics devices employing display command list handling mechanisms with another processor, such as a host processor.
BACKGROUND OF THE INVENTION
The programming of devices such as graphics processors across a multipurpose bus, such as PCI buses is becoming a bottleneck for proper graphics rendering or image generation mechanisms. Push architectures which typically have the host processor push commands to the graphics processor as a result of burstiness of the workload over multipurpose buses causes the host processor to waste time waiting to send commands. Hence, it would be desirable to have a different type of architecture that facilitates concurrency of processing between a host processor and a graphics processor chip of graphics related information.
To perform three dimensional rendering of images for multi media applications, games and other applications, a host processor typically perform some of the three dimensional generation tasks while a graphics processor or graphics chip performs the majority of the processing intensive mathematical computations. It is important in graphics generation systems to efficiently utilize a host processor's processing time since the host processor typically has many other functions to perform aside from generating 2D or 3D graphics images. Similarly, it is desirable to maximize the efficiency of the graphics processor to reduce costs and increase operational speeds. Also, a three dimensional graphics imaging pipeline, for example, may have a graphics processor perform basically all of the rendering and transformation functions. For example, a graphics processor may generate all of the pixels necessary to make an image appear in three dimensions including lighting and texturing and other surface rendering in addition to geometry transformations necessary to generate images. The geometry and lighting aspects of three dimensional imaging typically continuously takes large amounts of host processing time. To overcome, the burden on host processors, some known systems may, for example, use a separate chip to carryout the geometry transformations and another separate chip to perform the rendering operations due to the high processing loading requirements in generating three dimensional images. The geometry transformations include, for example, rotating an image and adding the requisite pixel data to make the image appear as though there has been lighting in a room or on the object. The rendering engines typically perform the drawing of the pixels on the screen. Such systems can be quite costly due to the dual chip configuration and operation.
Known systems also have the host processor generate the operational codes or drawing commands for the graphics processor through a software application. These command codes or operational codes are then sent to the graphics processor and stored in a command FIFO whereafter the graphics processor retrieves the command from the command FIFO and performs any requisite rendering operation. However, such systems typically are not able to accommodate high throughput since the command FIFO is typically limited in size. As previously noted, some systems attempt to provide more efficient and faster processing by having the host processor transfer command instructions to the graphics chip FIFO. One method is to use an interrupt based system wherein when the command FIFO is almost full, the graphics controller sends an interrupt to the host processor. The host processor typically has to poll or have other means of accounting for commands without polling the FIFO status. Another method is to have the graphics chip overflow commands from the command FIFO into graphics memory and/or host system memory. A problem arises with these systems because the FIFO can be almost full or almost empty a majority of the time depending upon the workload of the graphics processor. This requires the host processor to poll often, resulting in host processor operational inefficiencies. With the overflow method, large numbers of commands can be required to be stored resulting in costly use of memory.
Other systems are known that provide a display command list (operational codes) in graphics memory. The CPU or host processor pushes the commands and other information the graphics chip, such as after the CPU performs the geometric transformations on the data and then passes the processed transformation information to the graphics processor for rendering. It is desirable to have concurrency of graphics image generation between the host processor and the graphics processor to facilitate more efficient utilization of both host CPU and the rendering unit over long intervals to allow faster creation and rendering of three-dimensional images in less time. However, a problem arises with such systems because the host processor is continuously polling the graphics chip to determine what stage the graphics chip is in with particular data. With the polling system, the host processor typically asks the graphics chip if it can accept additional data for rendering. As such there may be unnecessary idle time for the graphics chip.
Other systems use a display command list in graphics memory instead of a command FIFO. However, writing the display command list in graphics memory uses up video memory which is a scarce resource, particularly when 3D imaging must be accomplished in short periods of time.
Finally, other known display list handlers store the display command list in host memory. The graphics processor is then commanded to obtain the data and process the command list obtained from the system memory. However, in such systems the host processor typically has to tell the graphics processor to get the command list and the host processor has to ask if it can push commands to inform the graphics processor to obtain the list. This again can result in idle time by the graphics chip and unnecessary overhead for the host processor due to the handshaking required to push commands. Currently graphics processors do not generally initiate communication back to the host processor.
Consequently, a need exists for an improved graphics display command list handling system and method that provides a reduction in host processor overhead while allowing a graphics processor to more efficiently obtain the command data to efficiently process graphics information.
REFERENCES:
patent: 5301287 (1994-04-01), Herrell et al.
patent: 5329615 (1994-07-01), Peaslee et al.
patent: 5371849 (1994-12-01), Peaslee et al.
patent: 5657479 (1997-08-01), Shaw et al.
patent: 5805905 (1998-09-01), Biswas et al.
patent: 5835779 (1998-11-01), Chang et al.
patent: 5856829 (1999-01-01), Gray, III et al.
patent: 5953020 (1999-09-01), Wang et al.
patent: 6092124 (2000-07-01), Priem et al.
patent: 6108014 (2000-08-01), Dye
patent: 6192428 (2001-02-01), Abramson et al.
Asaro Antonio
Laksono Indra
ATI International SRL
Chauhan Ulka J.
Vedder Price Kaufman & Kammholz
LandOfFree
Graphics display list handler and method does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Graphics display list handler and method, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Graphics display list handler and method will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2831515