Method and apparatus for simulated direct frame buffer access for graphics adapters

A method, data processing system, and computer instructions for simulating direct frame buffer access. A request for access to a frame buffer memory is received from an application. A portion of system memory is allocated for use as the frame buffer memory in response to receiving the request. A pointer to the portion of system memory is returned to the application. The application writes data to the portion of system memory, treating the portion of system memory like the frame buffer memory.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention provides an improved data processing system and in particular a method and apparatus for processing graphics data. Still more particularly, the present invention provides a method and apparatus for simulating direct frame buffer access in a data processing system.

2. Description of Related Art

Computer graphics concerns the synthesis or display of real or imaginary objects from computer-based models. In computer graphics systems, images are displayed on a display device to a user in two dimensional and three dimensional forms. These images are displayed using pixels. A pixel is short for a picture element. One spot in a rectilinear grid of thousands of such spots that are individually “painted” to form an image produced on the screen by a computer or on paper by a printer. A pixel is the smallest element that display or print hardware and software can manipulate in creating letters, numbers, or graphics. These pixels and information relating to these pixels are stored in a buffer.

One buffer in which this information may be stored is a frame buffer, which is an area of memory used to hold a frame of data. A frame buffer is typically used for screen display and is the size of the maximum image area on screen. This memory is a separate memory bank on a display adapter that holds a bitmapped image while the image is being “painted” or presented on screen.

One feature available on many graphics cards is direct frame buffer access (DFA). Typically, an application will request an area in the frame buffer memory, which may be on-screen or off-screen. In response, a pointer is returned to the application for the memory area. The application may then perform direct reads and writes to this memory area. This process allows the application to directly access the frame buffer memory on the graphics adapter. Such a feature is a prevalent function and mechanism provided on many graphics cards.

In some cases, this DFA function may be unavailable or unsupported. In these instances, an application designed to use DFA may be unable to function properly on the data processing system in which this function is not found. Therefore, it would be advantageous to have an improved method and apparatus for supporting DFA in a data processing system.

SUMMARY OF THE INVENTION

The present invention provides a method, data processing system, and computer instructions for simulating direct frame buffer access. A request for access to a frame buffer memory is received from an application. A portion of system memory is allocated for use as the frame buffer memory in response to receiving the request. A pointer to the portion of system memory is returned to the application. The application writes data to the portion of system memory, treating the portion of system memory like the frame buffer memory.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

With reference now to the figures and in particular with reference toFIG. 1, a pictorial representation of a data processing system in which the present invention may be implemented is depicted in accordance with a preferred embodiment of the present invention. A computer100is depicted which includes system unit102, video display terminal104, keyboard106, storage devices108, which may include floppy drives and other types of permanent and removable storage media, and mouse110. Additional input devices may be included with personal computer100, such as, for example, a joystick, touchpad, touch screen, trackball, microphone, and the like. Computer100can be implemented using any suitable computer, such as an IBM eServer computer or IntelliStation computer, which are products of International Business Machines Corporation, located in Armonk, N.Y. Although the depicted representation shows a computer, other embodiments of the present invention may be implemented in other types of data processing systems, such as a network computer. Computer100also preferably includes a graphical user interface (GUI) that may be implemented by means of systems software residing in computer readable media in operation within computer100.

With reference now toFIG. 2, a block diagram of a data processing system is shown in which the present invention may be implemented. Data processing system200is an example of a computer, such as computer100inFIG. 1, in which code or instructions implementing the processes of the present invention may be located. Data processing system200employs a peripheral component interconnect (PCI) local bus architecture. Although the depicted example employs a PCI bus, other bus architectures such as Accelerated Graphics Port (AGP) and Industry Standard Architecture (ISA) may be used. Processor202and main memory204are connected to PCI local bus206through PCI bridge208. PCI bridge208also may include an integrated memory controller and cache memory for processor202. Additional connections to PCI local bus206may be made through direct component interconnection or through add-in boards. In the depicted example, local area network (LAN) adapter210, small computer system interface SCSI host bus adapter212, and expansion bus interface214are connected to PCI local bus206by direct component connection. In contrast, audio adapter216, graphics adapter218, and audio/video adapter219are connected to PCI local bus206by add-in boards inserted into expansion slots. Expansion bus interface214provides a connection for a keyboard and mouse adapter220, modem222, and additional memory224. SCSI host bus adapter212provides a connection for hard disk drive226, tape drive228, and CD-ROM drive230. Typical PCI local bus implementations will support three or four PCI expansion slots or add-in connectors.

An operating system runs on processor202and is used to coordinate and provide control of various components within data processing system200inFIG. 2. The operating system may be a commercially available operating system such as Windows XP, which is available from Microsoft Corporation. Instructions for the operating system and applications or programs are located on storage devices, such as hard disk drive226, and may be loaded into main memory204for execution by processor202.

For example, data processing system200, if optionally configured as a network computer, may not include SCSI host bus adapter212, hard disk drive226, tape drive228, and CD-ROM230. In that case, the computer, to be properly called a client computer, includes some type of network communication interface, such as LAN adapter210, modem222, or the like. As another example, data processing system200may be a stand-alone system configured to be bootable without relying on some type of network communication interface, whether or not data processing system200comprises some type of network communication interface. As a further example, data processing system200may be a personal digital assistant (PDA), which is configured with ROM and/or flash ROM to provide non-volatile memory for storing operating system files and/or user-generated data.

The depicted example inFIG. 2and above-described examples are not meant to imply architectural limitations. For example, data processing system200also may be a notebook computer or hand held computer in addition to taking the form of a PDA. Data processing system200also may be a kiosk or a Web appliance.

The processes of the present invention are performed by processor202using computer implemented instructions, which may be located in a memory such as, for example, main memory204, memory224, or in one or more peripheral devices226-230.

Turning next toFIG. 3, a diagram of memory components used in providing a software simulation of direct frame buffer access for graphics adapters without direct frame buffer access support in hardware is depicted in accordance with a preferred embodiment of the present invention. The present invention provides a software mechanism for direct frame buffer access when a graphics adapter does not support this type of function.

In this example, application300request for an area of frame buffer memory302on graphics adapter304. Graphics adapter304may be implemented as graphics adapter218inFIG. 2. Normally, in response to this request, a pointer to this memory area is returned. When this function is not available, the mechanism of the present invention returns a pointer to a portion of system memory306. In these examples, system memory is the memory used by the operating system, such as, for example, memory204and memory224inFIG. 2.

Application300performs, reads and writes to system memory306thinking that this memory is actually a portion of frame buffer memory302. In this manner, application300believes that it is performing direct frames buffer access (DFA) writes.

During a selected period of time, data written by application300into system memory306is sent to frame buffer memory302. This period of time is selected as being the period of time during which the vertical retrace occurs for a monitor. A monitor is updated scan-line to scan-line from the top to the bottom of the screen. Data written to frame buffer memory302does not appear until the scan-line on which the pixel was located has been scanned by the electron gun in a monitor. In other words, a lag occurs between a DFA write and when the monitor shows a pixel change. Updates to on screen memory within frame buffer memory302are performed during the time in which the electron gun is in a vertical retrace mode, moving to the bottom right of the display back to the top left of the display, without the user noticing any glitches or tearing on the screen. Thus, data located in system memory306is written to frame buffer memory302during the vertical retrace period of the monitor in accordance with a preferred embodiment of the present invention.

With reference next toFIG. 4, a block diagram illustrating components used to provide software simulation of direct frame buffer access is depicted in accordance with a preferred embodiment of the present invention. In this example, application400sends a request for access to a buffer memory to graphics driver402in operating system404. Graphics driver402provides interface to hardware406. In this example, hardware406includes main memory204, main memory224, frame buffer memory302. Graphics driver402allocates a portion of system memory in response to receiving the request. A pointer to this memory is returned to application400, which performs reads and writes to the system memory.

Further, graphic driver402also copies the contents of system memory to the frame buffer memory. This copy process is performed during a vertical retrace period of the monitor.

Turning next toFIG. 5, a flowchart of a process for performing a direct frame buffer access is depicted in accordance with a preferred embodiment of the present invention. The process illustrated inFIG. 5may be implemented in an application, such as application300inFIG. 3.

The process begins by the application generating a request for frame buffer memory (step500). In this example, the application includes a width and height used to define the size of the memory needed by the application. The application then receives a pointer (step502). A determination is then made as to whether the pointer is valid (step504). In this example, a pointer is valid unless the pointer has a null value. If the pointer is valid, data is written to the memory using the pointer (step506). This pointer is a pointer to system memory. The application, however, believes that the pointer is to a portion of the frame buffer memory. Thereafter, the drawing surface is released when the application is finished reading and writing to the memory (step508) with the process terminating thereafter. In step508, the releasing of the drawing surface is performed to inform the device driver that the application is finished using that particular area of the frame buffer memory. This step also is performed to release the memory such that the device driver may make this memory available for reuse.

Turning back to step504, if the pointer is not valid, the process returns to step500. In returning to step500, another request is made for frame buffer memory. In this request, however, the size of the memory is changed, usually to a smaller size.

Turning now toFIG. 6, the flowchart of a process for allocating memory is depicted in accordance with a preferred embodiment of the present invention. The process illustrated inFIG. 6, may be implemented in a software component in an operating system, such as graphics driver402inFIG. 4.

The process begins by receiving a request for frame buffer memory from an application (step600). This request typically includes a memory size that is desired by the application. The memory size may be defined using parameters, such as a width and height. An allocation process is performed to allocate system memory using the request (step602). A determination is then made as to whether the allocation of the memory was successful (step604).

If the allocation of system memory was successful, the drawing surface was locked (step606). By locking the drawing surface, the device driver provides exclusive access to the application for that area of memory. In these examples, the feature applies to the frame buffer memory to prevent multiple applications from accessing the memory in attempting to write directly to the screen. In writing directly to the screen, each application locks the area of memory before writing data to that area of the memory. Next, vertical retrace interrupts are enabled (step608). These interrupts are used to identify when data may be copied from the system memory, allocated in response to the request, to the frame buffer memory. An interrupt is received or detected when the vertical retrace period begins. During this period of time, data may be copied from the system memory to the frame buffer memory without causing tears or glitches to the display. Thereafter, a pointer to the system memory is returned to the application (step610) with the process terminating thereafter.

With reference again to step604, if the allocation of the memory was not successful, a null pointer is returned to the application (step612) with the process terminating thereafter.

With reference next toFIG. 7, a flowchart of a process for freeing memory is depicted in accordance with a preferred embodiment of the present invention. The process illustrated inFIG. 7may be implemented in a software component in the operating system, such as graphics driver402inFIG. 4.

The process begins by receiving a request to release the drawing surface (step700). This request is received from the application. An application releases or frees a drawing surface before the application ends execution. Such a request may be made by an application when the application is finished with a screen of information that is being displayed. For example, if a user playing a game requests to see information about a score, the application may request an area of frame buffer memory, draw the score information to that area, copy that information in that area to the visible area of the frame buffer, let the user respond, then when the user is finished, the application releases the original area of the frame buffer memory. These operations may occur hundreds of times in a game as the user traverses screens.

Then, the system memory area of the drawing surface is copied to the off-screen frame buffer area in the frame buffer memory during vertical retrace (step702). Step702and704are performed to insure that the last screen of data is copied for the application. The application writes data to the system memory area believing that this data is being written directly to the frame buffer. The application is unaware of the vertical interrupts upon which the device driver is relying upon to copy the system memory area to the frame buffer. After the application finishes writing data, the application immediately releases the memory exacting that the data has already been displayed on the screen or is located in some other area on the frame buffer. However, depending on the timing of the vertical retrace, the writes made by the application may be only reflected in the system memory and not in the frame buffer. At this point, the device driver ensures that one last copy of data from the system memory to the frame buffer is performed. This copy is made to ensure that the last drawing performed by the application is reflected in the frame buffer and not just in the system memory.

Next, the vertical interrupts are disabled (step704). The vertical interrupts are disabled because data no longer needs to be copied from the system memory to the frame buffer memory. The drawing surface is then unlocked (step706). The system memory is freed (step708), with the process terminating thereafter.

With reference next toFIG. 8, a flowchart of a process for updating a display is depicted in accordance with a preferred embodiment of the present invention. The process illustrated inFIG. 8may be implemented in a software component, such as graphics driver402inFIG. 4.

The process begins by monitoring for a vertical retrace interrupt (step800). A determination is made as to whether a vertical retrace interrupt has been detected (step802). If a vertical retrace interrupt has been detected, the system memory area of the drawing surface is copied to the frame buffer area (step804), with the process terminating thereafter. Otherwise, the process returns to step800.

Thus, the present invention provides an improved method, apparatus, and computer instructions for providing a direct frame buffer access function to applications in data processing systems in which this function is unsupported in the hardware. The mechanism of the present invention simulates a direct frame buffer access function using a memory other than that of the frame buffer. In these examples, system memory is allocated. A pointer to this allocated memory is returned to the application. The application reads and writes to this memory, using the pointer, as if the memory were in the frame buffer. The mechanism of the present invention copies data from the allocated memory from the direct frame buffer to display the data. The copying or moving of data is performed during a period of time in which data may be written to the frame buffer without causing glitches or tears that may be noticed by the user. In these examples, the period of time is during the vertical retrace.