Computer graphics processing and selective visual display system – Computer graphics display memory system – Texture memory
Reexamination Certificate
1999-07-16
2002-08-20
Tung, Kee M. (Department: 2671)
Computer graphics processing and selective visual display system
Computer graphics display memory system
Texture memory
C345S541000, C345S502000, C345S582000, C709S241000
Reexamination Certificate
active
06437788
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
This invention relates to operation of computer systems, and more particularly to management of graphics displays for computer systems.
2. Description of the Related Art
Computer graphics workstations are used to generate high-quality graphics images, often three-dimensional, and to run applications programs in a windowed environment. A windowed environment allows a display device to present the output from several applications on a single physical output medium, e.g., a CRT display or monitor. The output display of an application is typically presented in one or more “windows” in a windowed environment. One or more unique “contexts” may be associated with the application area of each window. The contexts define the properties and parameters of the window area for that application. Thus, context refers to the data used by a graphics system to control the rendering process, i.e., a process through which a displayable image is generated. To enhance performance, computer graphics systems are moving toward the use of multiple graphics threads, each thread potentially having its own graphics context.
Graphics clients are typically compute-intensive and demanding on system bus bandwidth, and the threads for graphics clients can run on multiple processors in an attempt to satisfy their requirement for host processing cycles. Whenever the graphics system switches between clients, the state information must be saved and restored at many places in the graphics pipeline.
Increasingly, computer graphics systems are supporting multiple 2D and 3D contexts. For example, a graphics system may have in one window a high quality rendering of an airplane being developed. In another window there may be an interactive dialog in which the designer can change the properties of the airplane or make inquiries about it. In yet another window there may be a clock, and in still another window an inter-office mailing application may be running.
An operating system such as AIX supports the concept of ‘virtual graphics adapters,’ which means that each graphics process appears to have exclusive, direct access to the adapter hardware. To accomplish this illusion, the AIX operating system, in conjunction with the graphics adapter device driver, saves and restores the state of the adapter, known as a graphics context switch. Thus, a single hardware resource is time-shared with multiple graphics processes.
As the functionality and complexity of graphics accelerators increase, the amount of state information that must be save and restored during a graphics context switch is also growing, specifically in the area involving texture management. For example, applications creating complex, texture-intensive images may require large amounts of texture memory. For performance reasons, this memory resides on the adapter, and for some newer adapters is mega-bytes in size. To ‘virtualize’ adapters with large on-board texture memory, the device driver must save and restore all the adapter's state, including texture memory, associated with a graphics process. The memory used to save this state information is obtained from the memory pool used within the operating system. The problem is that this state information becomes large when adapters. with on-board texture memory are being used. It only takes a few graphics processes using an adapter with a large texture memory to impact the operating system by reducing its available system memory.
In addition, managing texture memory can result in a complex device driver since the application program interfaces (APIs) have all the information about texture memory and how it has been allocated. Information about how the texture memory is allocated would need to be available to the driver otherwise all texture memory would need to be saved/restored, prohibiting any optimization (i.e., save only what needs to be saved). Thus, in prior arrangements, a disadvantage has been that the complexity of texture management has been in the driver, in kernel space, rather than being in user space.
SUMMARY OF THE INVENTION
It is therefore one object of the present invention to provide an improved method of managing graphics displays for computer systems, particularly by using threads.
It is another object of the present invention to provide an improved graphics texture management method and system for computer graphics displays.
It is yet another object of the present invention to provide improved context-switching in graphics display management for computer systems in which the graphics adapter is virtualized.
The above as well as additional objects, features, and advantages of the present invention will become apparent in the following detailed written description.
According to one embodiment of the invention, a computer system having a graphics display with texture management employs a graphics adapter with texture memory. The graphics adapter is ‘virtualized’ by the operating system. When making a graphics context switch, the state of the graphics adapter including texture memory is saved and restored. Threads are used to trigger rapid and frequent context switches. A graphics process that will use texture memory in the adapter reserves a thread which is registered with the driver, for use during a graphics context switch. The thread calls into the operating system where it is blocked by the driver until a graphics context switch associated with this thread is initiated. At that time, the thread is unblocked by the driver to allow the texture manager to do the saving of texture memory. During the save portion of the graphics context switch the graphics driver saves the current hardware state of the adapter, and the special purpose texture thread is unblocked, and saves texture memory and calls back into the driver where it is blocked. The save operation also passes an indication to the texture manager that a save is in progress. During the restore portion of the graphics context switch the driver restores the state of the adapter to that of another graphics process, except for texture memory. The special purpose texture thread associated with the new graphics process is unblocked, passed an indication that a restore operation is in progress, and restores textures as required and calls back into the driver where it is blocked in the kernel. The driver completes the context switch and the graphics process is dispatched. Basically, what is preferred is to remove the complexity of texture management from the driver (in kernel space) to a user space texture manager.
REFERENCES:
patent: 5896141 (1999-04-01), Blaho et al.
patent: 6208361 (2001-03-01), Gossett
patent: 6252600 (2001-06-01), Kohli et al.
Milot Paul Joseph
Pafumi James Anthony
Stelzer Robert Paul
McBurney Mark E.
Tung Kee M.
LandOfFree
Synchronizing graphics texture management in a computer... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Synchronizing graphics texture management in a computer..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Synchronizing graphics texture management in a computer... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2972108