Providing 3D graphics across partitions of computing device

A computing device has a graphics hardware device employed to display graphics on a display, and is partitioned to include a video services partition (VSP) instantiated at least in part to provide graphics capabilities, and also to include a video client partition (VCP) instantiated at least in part to consume such graphics capabilities. The graphics hardware device is assigned to and controlled by the VSP. A shared video memory module is shared by the VCP and the VSP such that graphics information placed in the pages shared by the video memory module by the VCP is directly available to the VSP for further action such that graphics commands from the VCP are shunted by way of the pages shared by the video memory module across partitions from the VCP to the VSP to be acted upon by the graphics hardware device as controlled by the VSP.

TECHNICAL FIELD

The present invention relates to a system for providing a high-performance function such as three-dimensional (3D) graphics capabilities from one virtual machine operating in a partition on a computing device to another virtual machine operating in a partition on a computing device. More particularly, the present invention relates to providing such a system that maximizes throughput so as to be able to handle the volume of input and output typically incumbent in such 3D graphics.

BACKGROUND OF THE INVENTION

As should be appreciated, a virtual machine is a software application operating on a computing device for the purpose of emulating a hardware system. Typically, although not necessarily, the virtual machine is employed on the computing device to host a user application or the like while at the same time isolating such user application from such computing device or from other applications on such computing device. A different variation of a virtual machine may be written for each of a plurality of different computing device so that any user application written for the virtual machine can be operated on any of the different computing devices. Thus, a different variation of the user application for each different computing device is not needed.

Virtual machines traditionally have been unable to achieve high-performance 3D graphics due to the limitations of prior approaches to providing such virtual machines with graphics capabilities. In particular, prior approaches focused on device emulation, or used the same graphics protocols used over a network, with associated copying overhead. However, 3D graphics in particular require advanced visual effects with higher visual quality, and can only function well if 3D acceleration with good performance and appropriate capabilities are available.

New architectures for computing devices and new software now allow a single computing device to run a plurality of partitions, each of which can be employed to instantiate a virtual machine to in turn host an instance of an operating system. In such a computing device, a graphics hardware device of the computing device such as a graphics card with a graphics processor may be dynamically assigned to a particular partition so that the particular partition can directly control such graphics hardware device. Such particular partition, acting as a provider of 3D or video acceleration and display capabilities or a ‘video services partition’ (‘VSP’), can provide video services to another partition acting as a consumer of such capabilities or a ‘video client partition’ (‘VCP’). Thus, the VCP must communicate with the VSP to accomplish graphics-related operations.

In the course of a virtual machine emulating hardware, a significant amount of resources are consumed by inefficiencies associated with software emulation of each virtual hardware device. Thus, in the case of the VCP accessing the graphics hardware device in the course of performing video services, such inefficiencies and the overhead and complexity of device emulation may be overwhelming to the point that emulating the graphics hardware device is impractical. Even if proper emulation is achieved, performance is likely below acceptable standards due to the large amount of software processing required to emulate the graphics hardware device. Principally, such unacceptable performance is due to the fact that graphics data associated with the memory of one virtual machine must be transferred to the memory of another virtual machine in the course of producing graphics.

As may be appreciated, an analogous situation to one partition performing graphics services for another partition on a computing device may be one networked computing device providing graphics displaying services for a separate networked computing device according to a network graphics protocol. However, such a protocol likely does not provide for direct data sharing, and at times provides a more restrictive graphics interface to the producer of the graphics than is actually available locally to the displayer of such graphics.

Accordingly, a need exists for a system that allows a VSP on a computing device to provide high performance 3D graphics services to a VCP on the computing device. In particular, a need exists for such a system that allows the VSP to share resources and capabilities associated with the graphics hardware device with the VCP such that the VCP and VSP can directly share graphics data and the VCP can employ the same graphics interface that is available to the VSP at high performance.

SUMMARY OF THE INVENTION

The aforementioned needs are satisfied at least in part by the present invention in which a computing device has a graphics hardware device employed to display graphics on a display coupled to the computing device, and the computing device is partitioned to include a video services partition (VSP) instantiated at least in part to provide graphics capabilities, and also to include a video client partition (VCP) instantiated at least in part to consume such graphics capabilities. The graphics hardware device is assigned to and controlled in part by the VSP.

The VCP has a user mode portion of a graphics driver (UMD) in a user mode portion of such VCP, where the UMD corresponds to and is developed for the graphics hardware device. The UMD receives graphics commands from an application at a user mode portion of the VCP and processes such commands to produce graphics commands that the graphics hardware device may utilize to produce graphics. The VCP also has a user mode runtime module in the user mode portion of such VCP for assisting the UMD in processing and delivering graphics commands of a particular type.

The VSP has a partition graphics context object in a kernel mode portion of such VSP, where the partition graphics context object corresponds to the VCP and represents the graphics state relating to the graphics hardware device with regard to the VCP. The VSP also has a kernel mode portion of the graphics driver (KMD) in the kernel mode portion of such VSP, where the KMD corresponds to and is developed for the graphics hardware device and also corresponds to the UMD. The KMD directly controls the graphics hardware device. The VSP in addition has a kernel mode runtime module in the kernel mode portion of such VSP, where the kernel mode runtime module corresponds to the user mode runtime module in the VCP for assisting the KMD in processing and delivery of graphics command of the particular type and for maintaining state for the graphics hardware device with regard to the VCP in the partition graphics context object.

The computing device also includes a shared video memory module shared by the VCP and the VSP, with a portion in the VCP and a portion in the VSP. The portions share pages of memory between the VCP and the VSP and manage graphics-related cross-partition notifications. Graphics information placed in the shared video memory module by the VCP is directly available to the VSP for further action such that graphics commands from the VCP are shunted by way of the shared video memory module across partitions from the VCP to the VSP to be acted upon by the graphics hardware device as controlled by the VSP.

DETAILED DESCRIPTION OF THE INVENTION

Computer Environment

FIG. 1and the following discussion are intended to provide a brief general description of a suitable computing environment in which the invention may be implemented. It should be understood, however, that handheld, portable, and other computing devices of all kinds are contemplated for use in connection with the present invention. While a general purpose computer is described below, this is but one example. Thus, the present invention may be implemented in an environment of networked hosted services in which very little or minimal client resources are implicated, e.g., a networked environment in which the client device serves merely as a browser or interface to the World Wide Web.

Although not required, the invention can be implemented via an application programming interface (API), for use by a developer, and/or included within the network browsing software which will be described in the general context of computer-executable instructions, such as program modules, being executed by one or more computers, such as client workstations, servers, or other devices. Generally, program modules include routines, programs, objects, components, data structures and the like that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments. Moreover, those skilled in the art will appreciate that the invention may be practiced with other computer system configurations. Other well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers (PCs), automated teller machines, server computers, hand-held or laptop devices, multi-processor systems, microprocessor-based systems, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network or other data transmission medium. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

A monitor191or other type of display device is also connected to the system bus121via an interface, such as a video interface190. A graphics interface182, such as Northbridge, may also be connected to the system bus121. Northbridge is a chipset that communicates with the CPU, or host processing unit120, and assumes responsibility for accelerated graphics port (AGP) communications. One or more graphics processing units (GPUs)184may communicate with graphics interface182. In this regard, GPUs184generally include on-chip memory storage, such as register storage and GPUs184communicate with a video memory186. GPUs184, however, are but one example of a coprocessor and thus a variety of co-processing devices may be included in computer110. A monitor191or other type of display device is also connected to the system bus121via an interface, such as a video interface190, which may in turn communicate with video memory186. In addition to monitor191, computers may also include other peripheral output devices such as speakers197and printer196, which may be connected through an output peripheral interface195.

One of ordinary skill in the art can appreciate that a computer110or other client device can be deployed as part of a computer network. In this regard, the present invention pertains to any computer system having any number of memory or storage units, and any number of applications and processes occurring across any number of storage units or volumes. The present invention may apply to an environment with server computers and client computers deployed in a network environment, having remote or local storage. The present invention may also apply to a standalone computing device, having programming language functionality, interpretation and execution capabilities.

Distributed computing facilitates sharing of computer resources and services by direct exchange between computing devices and systems. These resources and services include the exchange of information, cache storage, and disk storage for files. Distributed computing takes advantage of network connectivity, allowing clients to leverage their collective power to benefit the entire enterprise. In this regard, a variety of devices may have applications, objects or resources that may interact to implicate authentication techniques of the present invention for trusted graphics pipeline(s).

FIG. 2provides a schematic diagram of an exemplary networked or distributed computing environment. The distributed computing environment comprises computing objects10a,10b, etc. and computing objects or devices110a,110b,110c, etc. These objects may comprise programs, methods, data stores, programmable logic, etc. The objects may comprise portions of the same or different devices such as PDAs, televisions, MP3 players, televisions, personal computers, etc. Each object can communicate with another object by way of the communications network14. This network may itself comprise other computing objects and computing devices that provide services to the system ofFIG. 2. In accordance with an aspect of the invention, each object10or110may contain an application that might request the authentication techniques of the present invention for trusted graphics pipeline(s).

It can also be appreciated that an object, such as110c, may be hosted on another computing device10or110. Thus, although the physical environment depicted may show the connected devices as computers, such illustration is merely exemplary and the physical environment may alternatively be depicted or described comprising various digital devices such as PDAs, televisions, MP3 players, etc., software objects such as interfaces, COM objects and the like.

There are a variety of systems, components, and network configurations that support distributed computing environments. For example, computing systems may be connected together by wire-line or wireless systems, by local networks or widely distributed networks. Currently, many of the networks are coupled to the Internet, which provides the infrastructure for widely distributed computing and encompasses many different networks.

In home networking environments, there are at least four disparate network transport media that may each support a unique protocol such as Power line, data (both wireless and wired), voice (e.g., telephone) and entertainment media. Most home control devices such as light switches and appliances may use power line for connectivity. Data Services may enter the home as broadband (e.g., either DSL or Cable modem) and are accessible within the home using either wireless (e.g., HomeRF or 802.11b) or wired (e.g., Home PNA, Cat 5 even power line) connectivity. Voice traffic may enter the home either as wired (e.g., Cat 3) or wireless (e.g., cell phones) and may be distributed within the home using Cat 3 wiring. Entertainment media may enter the home either through satellite or cable and is typically distributed in the home using coaxial cable. IEEE 1394 and DVI are also emerging as digital interconnects for clusters of media devices. All of these network environments and others that may emerge as protocol standards may be interconnected to form an intranet that may be connected to the outside world by way of the Internet. In short, a variety of disparate sources exist for the storage and transmission of data, and consequently, moving forward, computing devices will require ways of protecting content at all portions of the data processing pipeline.

The ‘Internet’ commonly refers to the collection of networks and gateways that utilize the TCP/IP suite of protocols, which are well-known in the art of computer networking. TCP/IP is an acronym for “Transmission Control Protocol/Internet Protocol.” The Internet can be described as a system of geographically distributed remote computer networks interconnected by computers processing networking protocols that allow users to interact and share information over the networks. Because of such wide-spread information sharing, remote networks such as the Internet have thus far generally evolved into an open system for which developers can design software applications for performing specialized operations or services, essentially without restriction.

Thus, the network infrastructure enables a host of network topologies such as client/server, peer-to-peer, or hybrid architectures. The “client” is a member of a class or group that uses the services of another class or group to which it is not related. Thus, in computing, a client is a process, i.e., roughly a set of instructions or tasks, that requests a service provided by another program. The client process utilizes the requested service without having to “know” any working details about the other program or the service itself. In a client/server architecture, particularly a networked system, a client is usually a computer that accesses shared network resources provided by another computer e.g., a server. In the example ofFIG. 2, computers110a,110b, etc. can be thought of as clients and computer10a,10b, etc. can be thought of as the server where server10a,10b,etc. maintains the data that is then replicated in the client computers110a,110b,etc.

A server is typically a remote computer system accessible over a remote network such as the Internet. The client process may be active in a first computer system, and the server process may be active in a second computer system, communicating with one another over a communications medium, thus providing distributed functionality and allowing multiple clients to take advantage of the information-gathering capabilities of the server.

Client and server communicate with one another utilizing the functionality provided by a protocol layer. For example, Hypertext-Transfer Protocol (HTTP) is a common protocol that is used in conjunction with the World Wide Web (WWW). Typically, a computer network address such as a Universal Resource Locator (URL) or an Internet Protocol (IP) address is used to identify the server or client computers to each other. The network address can be referred to as a Universal Resource Locator address. For example, communication can be provided over a communications medium. In particular, the client and server may be coupled to one another via TCP/IP connections for high-capacity communication.

Thus,FIG. 2illustrates an exemplary networked or distributed environment, with a server in communication with client computers via a network/bus, in which the present invention may be employed. In more detail, a number of servers10a,10b, etc., are interconnected via a communications network/bus14, which may be a LAN, WAN, intranet, the Internet, etc., with a number of client or remote computing devices110a,110b,110c,110d,110e, etc., such as a portable computer, handheld computer, thin client, networked appliance, or other device, such as a VCR, TV, oven, light, heater and the like in accordance with the present invention. It is thus contemplated that the present invention may apply to any computing device in connection with which it is desirable to process, store or render secure content from a trusted source, and to any computing device with which it is desirable to render high performance graphics generated by a virtual machine.

In a network environment in which the communications network/bus14is the Internet, for example, the servers10can be Web servers with which the clients110a,110b,110c,110d,110e, etc. communicate via any of a number of known protocols such as HTTP. Servers10may also serve as clients110, as may be characteristic of a distributed computing environment. Communications may be wired or wireless, where appropriate. Client devices110may or may not communicate via communications network/bus14, and may have independent communications associated therewith. For example, in the case of a TV or VCR, there may or may not be a networked aspect to the control thereof. Each client computer110and server computer10may be equipped with various application program modules or objects135and with connections or access to various types of storage elements or objects, across which files may be stored or to which portion(s) of files may be downloaded or migrated. Thus, the present invention can be utilized in a computer network environment having client computers110a,110b, etc. that can access and interact with a computer network/bus14and server computers10a,10b, etc. that may interact with client computers110a,110b, etc. and other devices111and databases20.

Providing 3D Graphics Across Partitions of Computing Device

Turning now toFIG. 3, a computing device10includes a hardware graphics hardware device12that is employed to display 3D graphics or the like on a display14coupled to the computing device10. The computing device10has been partitioned to include a video services partition (VSP)16instantiated at least in part to provide 3D or video acceleration and display capabilities, and also to include a video client partition (VCP)18instantiated at least in part to consume such capabilities. As shown, the graphics hardware device12has been dynamically assigned to the VSP16and thus is under the direct control of such VSP16.

In the present invention, the VSP16and VCP18are configured such that the VSP16provides high performance processing such as 3D graphics to the VCP18. In addition, the VSP16is configured to provide such high performance processing to a plurality of such VCPs18. In particular, and as will be set forth in more detail below, each VCP18accessing the VSP16is represented therein by a partition graphics context object20(FIG. 4) that provides for the VCP18certain pieces of the graphics stack and other items that are unique to each VCP18, among other things.

Normally, graphics software managing a graphics hardware device12has certain state that is relevant to the graphics hardware device12and not to any particular process, where at least some of the state of the graphics hardware device12is visible or settable by processes. With the partition graphics context object20for each VCP18, each VCP18can get a distinct copy of such state so that processes within the VCP18see such distinct copy of such state. As may be appreciated, the state as represented by any particular partition graphics context object20can be swapped in to become the corresponding real state of the graphics hardware device12. Such swapping in of state is accomplished without disrupting semantics seen by each VCP18. By way of example and not limitation, such state may include the set of graphics data regions that the VCP18has configured to display on a graphics output device.

As may be appreciated, the partition graphics context object20may contain the collection of visible graphics surfaces currently being virtually output to virtual displays by the VSP16. Such visible graphics surfaces may or may not be actually visible on actual display output hardware at any given time. The partition graphics context object20may also contain a collection of representations of graphics rendering contexts that have been created by the VSP16. Such graphics rendering contexts are distinct from the partition graphics context object20.

Turning now toFIG. 4, it is seen that graphics operations initiated by the VCP18and serviced by the VSP16are serviced by the following elements in the following manner.FIG. 4presumes that the computing device10ofFIG. 3and each partition16,18thereof are functionally operated to include both a user mode and a kernel mode. As may be appreciated, the user mode is a generally non-privileged state where executing code is forbidden by the hardware from performing certain operations, such as for example writing to memory not assigned to such code. Generally such forbidden operations are those which could destabilize the operating system or constitute a security risk. In terms of the operating system, the user mode is an analogous non-privileged execution mode where the running code is forbidden by the kernel from performing potentially dangerous operations such as writing to system configuration files, killing other processes, rebooting the system, and the like.

As may also be appreciated, the kernel mode or privileged mode is the mode in which the operating system and related core components run. Code running in the kernel mode has unlimited access to the system memory and external devices that are assigned to the partition16,18. Generally, the amount of code running in kernel mode is minimized, both for purposes of security and elegance. Roughly speaking, a user of a computing device10interfaces therewith most directly through the user mode and applications operating therein, while the computing device10interfaces with external devices, including the graphics hardware device12, most directly through the kernel mode.

With the user and kernel modes as set forth above, then, and still referring toFIG. 4, it is seen that in one embodiment of the present invention the VCP18has in the user mode portion thereof a user mode portion of a graphics driver22as written by an independent hardware vendor (IHV UMD22). Presumably, the IHV UMD22receives graphics commands from some application at the user mode of the VCP18and processes such commands to produce graphics commands that may be executed by the graphics hardware device12to produce graphics. A user mode portion of a graphics driver as written by an independent hardware vendor is generally known or should be apparent to the relevant public and therefore need not be set forth herein in any detail. Accordingly, the IHV UMD22may be any appropriate IHV UMD22without departing from the spirit and scope of the present invention. Critically, and as should now be understood, in the present invention, the IHV UMD22runs in the VCP18even though the corresponding independent hardware vendor kernel mode driver24(IHV KMD24) is running in the kernel mode portion of the VSP16and not in the kernel mode portion of the VCP18.

Note that just as the VCP18has an instance of the IHV UMD22to handle graphics commands from applications running at such VCP18, so too may the VSP16have an instance of the IHV UMD22to handle graphics commands from applications running at such VSP16(not shown). Of course, in the special case of the VSP16, all graphics commands are processed entirely within such VSP16and need not be forwarded across partitions16,18.

The VCP18may have in the user mode portion thereof one or more user mode runtime modules26. As may be appreciated, the user mode runtime module26assists the IHV UMD22in processing graphics commands. By way of example and not limitation, a first user mode runtime module26may be employed to help in processing graphics commands of a first type, a second user mode runtime module26may be employed to help in processing graphics commands of a second type, etc. A user mode runtime module26is generally known or should be apparent to the relevant public and therefore need not be set forth herein in any detail. Accordingly, each user mode runtime module26may be any appropriate user mode runtime module without departing from the spirit and scope of the present invention. Typically, such a user mode runtime module26may at appropriate times call into a corresponding VCP kernel mode runtime module28in the kernel portion of the VCP18to initiate graphics operations, adjust state at the graphics hardware device12, and the like.

The VCP kernel mode runtime module28in the kernel portion of the VCP18is as was alluded to above the module in such kernel portion of such VCP18that assists in processing graphics commands. As with the user mode runtime module26, the VCP kernel mode runtime module28is generally known or should be apparent to the relevant public and therefore need not be set forth herein in any detail. Accordingly, the VCP kernel mode runtime module28may be any appropriate kernel mode runtime module without departing from the spirit and scope of the present invention. Note that inasmuch as graphics commands may potentially emanate from with the kernel mode portion of the VCP18, such VCP18may also have in such kernel portion thereof provision for receiving graphics commands from kernel mode components30that make direct calls into the VCP kernel mode runtime module28.

Absent the present invention and in the prior art case, a call into the kernel mode runtime module28would result in graphics operations being scheduled and memory being managed in the same partition16,18in which the call is made. However, with the present invention, and critically, the calls, operations, related memory pages, and other related information are shunted or shared between the VCP18and the VSP16. The capability to share between the VCP18and the VSP16is an integral part of the invention inasmuch as the VSP16controls the graphics hardware device12and not the VCP18.

Still referring toFIG. 4, the aforementioned capability to share between the VCP18and the VSP16is achieved in one embodiment of the present invention by way of a shared video memory module32. As seen, such shared video memory module32may be constructed to include two portions, one in the VCP18and the other in the VSP16. Together, the two portions share appropriate pages of memory between the two partitions16,18and manage graphics-related cross-partition notifications. The shared video memory module32although not generally known should nevertheless be apparent to the relevant public and therefore need not be set forth herein in any detail. Accordingly, the shared video memory module32may be any appropriate shared video memory module without departing from the spirit and scope of the present invention.

Note that in general, a partition16,18cannot access memory owned by another partition16,18unless the owning partition16,18gives explicit permission. Therefore, in order for a process in the VCP18to access the contents of a graphics allocation, the memory pages that back such graphics allocation must be explicitly shared by the VSP16to the VCP18by the shared video memory module32.

Accordingly, and critically, with the shared video memory module32, graphics commands, information, and the like as generated by the IHV UMD22in the user mode portion of the VCP18may be placed by the IHV UMD22or the like in the pages that have been shared by the shared video memory module32, and by doing so such graphics commands, information, and the like are directly available to the corresponding IHV KMD24running in the kernel mode portion of the VSP16for further action. Significantly, such graphics command, information, and the like need not be copied, reformatted, re-transmitted, or the like, with the result being that graphics can be executed with high performance and throughput and with less overhead and superfluous action.

As was noted above, the VSP16is configured to provide high performance processing to a plurality of such VCPs18and thus has for each VCP18accessing the VSP16a corresponding partition graphics context object20that provides for the VSP18state that is relevant to the graphics hardware device12, where such state includes certain pieces of the graphics stack and other items that are unique to each VCP18, among other things. Each VCP18thus has a corresponding distinct instance of state information so that processes within the VCP18see such appropriate instance of such state. As may be appreciated, the state information set forth in the partition graphics context object20for each corresponding VCP18is known or should be apparent to the relevant public and therefore need not be set forth herein in any detail. Accordingly, such state information may be any appropriate state information without departing from the spirit and scope of the present invention.

In the prior art, and as may be appreciated, the VCP kernel mode runtime module28in the kernel portion of the VCP18would perform most functionality associated with scheduling graphics commands and rendering of graphics to the graphics hardware device12and most functionality associated with managing graphics memory allocations. However, inasmuch as the VSP16is now performing such functionality, the VSP16in one embodiment of the present invention has a VSP kernel mode runtime module34in the kernel portion of such VSP16to in fact perform such functionality. Thus, the VCP kernel mode runtime module28now need not perform most of the aforementioned functionality, and if in fact the VCP kernel mode runtime module28does include such functionality, such included functionality is not employed unless for some reason the VCP18becomes a VSP16at some point.

To summarize, then, in the present invention, the VSP kernel mode runtime module34in the VSP16is active and is used to satisfy graphics requests made by code running in both partitions16,18. The path from processes and kernel mode modules in the VSP16(not shown) is similar to the path from processes in the VCP18except that the path in the VSP16leads directly to the VSP kernel mode runtime module34rather than indirectly by cross-partition sharing, as with the VCP18. Note that in the present invention, the VSP kernel mode runtime module34includes functionality necessary to address the multiple partition graphics context objects20. Thus, such VSP kernel mode runtime module34treats each partition graphics context object20as if a separate machine graphics context, with a separate set of corresponding active display surfaces and the like.

As may be appreciated, in the present invention, the VSP kernel mode runtime module34includes a graphics memory manager and a graphics scheduler. Such manager and such scheduler are each a single instance that are respectively concerned with each VCP18instantiated on the computing device10and in particular each graphics command emanating therefrom. Thus, such manager and such scheduler remain part of the true per-graphics hardware device12state and are not duplicated, as is the case with state in the partition graphics context object20. The video memory manager of the VSP kernel mode runtime module34manages memory that is used to hold graphics-related allocations. Such memory can be video RAM, regular RAM, or the like. The video scheduler of the VSP kernel mode runtime module34schedules when individual contexts from VCPs18are allowed to run on the graphics processing unit of the graphics hardware device12. Because the video memory manager and video scheduler are managing memory and scheduling for all graphics rendering contexts regardless of which partition16,18graphics rendering contexts are associated with, the present invention is highly efficient. In particular, it is much more efficient to have a single video memory manager and video scheduler managing all graphics memory and scheduling rather than to have such functionality split across partitions16,18.

As was disclosed above, in the present invention, with the IHV UMD22running in the user mode portion of the VCP18, a corresponding independent hardware vendor kernel mode driver24(IHV KMD24) is running in the kernel mode portion of the VSP16and not in the kernel mode portion of the VCP18. As may be appreciated, such IHV KMD24directly controls the graphics hardware device12and is not necessarily aware of the fact that some of the graphics commands are coming from a different partition18. Such IHV KMD24as written by an independent hardware vendor is generally known or should be apparent to the relevant public and therefore need not be set forth herein in any detail. Accordingly, the IHV KMD24may be any appropriate IHV KMD24without departing from the spirit and scope of the present invention. Note that with the IHV KMD24in the kernel mode portion of the VSP16, the kernel mode portion of the VCP18need not have any such IHV KMD24, unless for some reason the VCP18becomes a VSP16at some point. As should now be evident, no IHV KMD24is needed at the VCP18inasmuch as the VCP18does not actually have primary control of the graphics hardware device12. Instead, all graphics operation and state management operation command pathways are set up and managed by the VSP16that controls the graphics hardware device12.

As may be appreciated, the present invention is particularly useful in connection with a computer-type user interface that can utilize high-performance 3D graphics capabilities of a graphics hardware device12to draw a graphically-rich interface. Thus, advanced visual effects are provided, with higher visual quality than is possible using older 2D-only graphics. However, such an interface can only function well if 3D acceleration with good performance and appropriate capabilities is available. Correspondingly, video playback is provided, using accelerated scaling and color space conversion capabilities of the graphics hardware device12. Both the advanced visual effects and the video playback capabilities benefit from the relatively high performance and support for myriad graphics capabilities offered by the present invention, which can function with existing graphics hardware devices12and also with future generation graphics hardware devices12.

The present invention relies on work already accomplished that allows multiple partitions16,18, etc. to be operating on a computing device10, each partition essentially comprising a virtual machine running a separate operating system or the like. In variations of the present invention:

A portion of a graphics driver runs in the VCP18, resulting in what is believed to be a maximum performance since work performed in the VCP18is not repeated in the VSP16;

No portion of the graphics driver runs in the VCP18, which functions as long as the graphics interface of the VSP16is backward-compatible with the graphics interface of the VCP16—strict compatibility call-for-call is not required as long as high-performance translation is provided from the VCP18graphics interface to the VSP16graphics interface.

With the present invention, the desktop surface may be shared between VCPs18such that the contents of the desktop surface of a first VCP18can be drawn onto the desktop surface of a second VCP18. Likewise, two VCPs18can share a desktop surface so that at least some processes running in one VCP18appear on the desktop surface of the other VCP18. Such a function can be employed to simulate processes running in the same partition18even though actually running in separate partitions18.

The present invention can be employed to implement a protected video path by creating one or more trusted partitions18that are trusted not to divulge content flowing through such path, and by restricting the sharing of memory pages that contain protected media to other partitions18that are also trusted. Here, the graphics hardware device12would be assigned to a trusted partition16. Restricting the sharing of any pages here would include restricting the sharing of pages that are the result of a rendering operation that used protected content as a source, such as a displayed primary surface of a trusted partition18. In effect, any page that is an output of a render operation becomes protected media if any input of the render operation was protected media.

Since only trusted partitions18would have access to protected content, any mixing of protected and non-protected content must be done by a trusted partition18, and once mixed, the result remains protected content. Similarly, protected content can be shared only among partitions18that are all trusted. Note, though, that in some instances a trusted partition18may allow a non-trusted partition18to specify certain items, such as for example the screen position of protected content. Such a non-trusted partition18thus can be permitted to do most of the work of visually decorating a graphics pane, with the result being that the amount of code in the trusted partition18is minimized, and also that protected content can be displayed in a visually mixed manner with non-protected content.

Conclusion

The programming necessary to effectuate the processes performed in connection with the present invention is relatively straight-forward and should be apparent to the relevant programming public. Accordingly, such programming is not attached hereto. Any particular programming, then, may be employed to effectuate the present invention without departing from the spirit and scope thereof.

In the present invention, a system is provided that allows a VSP16on a computing device10to provide high performance 3D graphics services to a VCP18on the computing device10. The VSP16shares resources and capabilities associated with a graphics hardware device12with the VCP18such that the VCP18and VSP16can directly share graphics data and the VCP18can employ the same graphics interface that is available to the VSP16at high performance.

It should be appreciated that changes could be made to the embodiments described above without departing from the inventive concepts thereof. It should be understood, therefore, that this invention is not limited to the particular embodiments disclosed, but it is intended to cover modifications within the spirit and scope of the present invention as defined by the appended claims.