Computer graphics processing and selective visual display system – Computer graphics processing
Reexamination Certificate
2001-03-01
2004-12-14
Courtenay, III, St. John (Department: 2126)
Computer graphics processing and selective visual display system
Computer graphics processing
C345S629000, C719S328000
Reexamination Certificate
active
06831635
ABSTRACT:
FIELD OF THE INVENTION
The present invention provides a new and improved software interface as a layer between application developers and the graphics pipeline that renders and processes the graphics data.
BACKGROUND OF THE INVENTION
For the vast majority of applications, application programmers rely on or utilize some form of software interface to interact with a computer and its associated devices. For graphics applications, developers or programmers typically utilize a graphics software interface, such as a 3D graphics application programming interface (API), to facilitate the interaction with constituent parts of a graphics system. Programmers typically rely on software interfaces to peripherals and devices so that they can focus on the specifics of their application rather than on the specifics of controlling a particular device and so that their efforts are not duplicated from application to application. However, even after generations of software interfaces, there are certain aspects of today's software interfaces that do not provide the level of performance desired and thus can be improved.
There are several reasons why previous generation graphics software interfaces do not meet the needs of today's graphics applications and systems. One type of resource contention issue that sometimes occurs is due to the demands of multiple devices and applications requiring graphics system resources simultaneously. For example, if multiple applications running simultaneously are maintaining connections to multiple surfaces from various objects of the graphics system, sometimes these connections to surfaces can become severed or disconnected. When multiple applications have connections between surfaces and objects, more system resources, such as memory space, are utilized resulting in an increased likelihood of a disconnection. For instance, while a user may generally toggle back and forth between executing applications, if the connection to surface memory for any one application is severed, a user may have to restart the application or begin certain portions of the application again in order to recreate a proper connection. Today's 3D graphics APIs check for severing of connections in a redundant fashion, wasting computing resources, and consequently there is a need for an improved technique for checking for the persistence of connections between object space and surface space.
Since graphics peripherals and other specialized graphics hardware and integrated circuits (ICs) are generally designed for specific tasks, they are much better than the host processor at performing certain types of functions. For example, a video card may have special purpose hardware that can copy or process pixels much faster than the CPU. A high level interface using a multi-purpose processor may not take advantage of the specialized functionality and may also include additional lines of code that in the long run can consume valuable computer resources, especially when repeated over and over as can be the case with graphics applications. Thus, one of the problems with current 3D graphics architectures is an over-reliance on general host computing resources. This over-reliance on general processing has led to major advances in specialized graphics chips designed primarily for the purpose of improving the performance of graphics applications.
Other failings in today's graphical software interfaces are due to advances in hardware technology that have enabled the ability to move functionality previously implemented in software into specialized hardware. An example of this is the way in which graphics rendering and processing functionality has been merged or pushed into specialized graphics hardware that can operate, on average, at orders of magnitude faster than previous generations. In the last two years, graphics hardware has been matching or beating the expectations of Moore's law, creating a whole new universe of high performance devices and 3D graphics chips that can perform specialized tasks at previously unheard of rates and efficiency. This in turn has left pre-existing software interfaces lagging behind the functionality of the hardware devices and the graphics community, and in certain cases, the software interfaces are currently limiting this increased hardware functionality. This can be the case, for example, when the execution of the commands of the software interface becomes the rate determining step of a graphics operation that could otherwise be performed more efficiently with hardware. Thus, in addition to the problems identified above, it would be desirable to address with software solutions the increased functionality of today's graphics hardware at various points between developers, the 3D graphics API and the new hardware.
For example, in the past, when a developer switched graphics data from one memory location to another, the developer had to deal with switching the data i.e., by destroying and recreating the data. In this regard, there are two types of ‘containers’ that today's graphics APIs present to a developer for use: one for pixels and one for polygons. Essentially, by passing arguments to the graphics API (placing data into the containers), the developers can manipulate and render various chunks of data. Once these containers are filled with data, there are various places, such as system memory or on a 3D card or chip, where this data may be stored for further manipulation. The filling and placement of the containers is achieved via various components or function calls of the graphics API. The decision as to where to place this data is generally a performance issue. Data for which fast access is not necessary can be stored in system memory, whereas data for which speed of access is more important may be stored on a graphics chip designed for ultra fast access.
As mentioned, it is sometimes desirable for a developer to switch data or chunks of data from one memory location to another memory location at different stages of processing. In the past, when a developer desired to switch data from one memory location to another, the developer had to deal with switching the data i.e., destroying the data in the old location and recreating the data in the new location. Previously, this may not have caused a performance decrease because, relative to today, the bandwidth for high performance processing on a graphics board or chip was low. This may have actually given the developer more flexibility to place data in an environment in which it would be processed most efficiently. With limited options, this task was not overly burdensome even though the developer had to custom code the switching of data for each application.
Given the complexity and high performance rewards of using today's hardware, which may have their own memory on board or on chip, it would be advantageous to be able to automatically transition data objects between memory types to enable the seamless switching of data. It would in theory be desirable to keep all data on the faster hardware chip memory to process data. However, in reality, there is little room for such on chip graphics data, sometimes as few as a hundred (high speed) registers. Thus, typically a cache managing algorithm optimizes the tradeoff between host system memory and video memory on the 3D card or chip so as to keep a maximum amount of data for processing in graphics hardware memory without causing overflow. Previously, a developer would have to write such a cache managing algorithm for every application and the cache managing algorithm would have to be individually tailored to the programming task at hand. Thus, it would be desirable to enable the software interface to hide the optimal cache managing algorithm from the developer so that the developer need not be concerned with the optimal tradeoff of system resources, and so that efficient switching of data can take place behind the scenes, thereby simplifying the developer's task.
Another area in which such a software solution is desirable in view of tod
Boyd Charles N.
Noyle Jeff M. J.
Toelle Michael A.
Courtenay III St. John
Nguyen V. H.
Woodcock & Washburn LLP
LandOfFree
Method and system for providing a unified API for both 2D... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and system for providing a unified API for both 2D..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for providing a unified API for both 2D... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3329488