Co-processing techniques on heterogeneous graphics processing units

Abstract

The graphics co-processing technique includes loading and initializing a device driver interface and a device specific kernel mode driver for a graphics processing unit on a primary adapter. A device driver interface and a device specific kernel mode driver for a graphics processing unit on an unattached adapter is also loaded and initialized without the device driver interface talking back to a runtime application programming interface or a thunk layer when a particular versions of an operating system will not allow the device driver interface on the unattached adapter to be loaded.

What is claimed is: 
     
         1 . One or more computing device readable media having computing device executable instructions which when executed perform a method comprising:
 injecting an application initialization routine, when an application starts, that includes an entry point that changes a search path for a display device interface to a search path of a shim layer library; and   loading the shim layer library, at the changed search path, that initializes a display device interface for a first graphics processing unit on a primary adapter and a display device interface for a second graphics processing unit on an unattached adapter, wherein the display device interface on the unattached adapter is initialized without calling back to a runtime application programming interface.   
     
     
         2 . The one or more computing device readable media having computing device executable instructions which when executed perform the method of  claim 1 , wherein the display device driver interface on the primary adapter comprises a user mode driver dynamic linked library (UMD.dll) for the first graphic processing unit. 
     
     
         3 . The one or more computing device readable media having computing device executable instructions which when executed perform the method of  claim 1 , wherein the display device driver interface on the unattached adapter comprises a user mode driver dynamic linked library (UMD.dll) for the second graphic processing unit. 
     
     
         4 . The one or more computing device readable media having computing device executable instructions which when executed perform the method of  claim 1 , wherein the application initialization routine comprises a dynamic linked library. 
     
     
         5 . The one or more computing device readable media having computing device executable instructions which when executed perform the method of  claim 1 , wherein the runtime application programming interface comprises a DirectX application programming interface (D3Dx.dll). 
     
     
         6 . The one or more computing device readable media having computing device executable instructions which when executed perform the method of  claim 1 , wherein the first graphics processing unit comprises an integrated graphics processing unit. 
     
     
         7 . The one or more computing device readable media having computing device executable instructions which when executed perform the method of  claim 1 , wherein the second graphics processing unit comprises a discrete graphics processing unit. 
     
     
         8 . The one or more computing device readable media having computing device executable instructions which when executed perform the method of  claim 1 , wherein the first graphics processing unit and the second graphics processing unit are heterogeneous graphics processing units. 
     
     
         9 . The one or more computing device readable media having computing device executable instructions which when executed perform the method of  claim 1 , further comprising:
 injecting the application initialization routine, when the application starts, that includes an entry point that identifies the application;   loading the shim layer library that also determines if the application has an affinity for execution of graphics commands on the second graphics processing unit;   executing the graphics commands from the application on the second graphics processing unit if there is an affinity; and   executing the graphics commands from the application on the first graphics processing unit if there is not an affinity.   
     
     
         10 . The one or more computing device readable media having computing device executable instructions which when executed perform the method of  claim 9 , wherein the shim layer library determines if the application has an affinity for execution of graphics commands on the second processing unit if the application is on a white list. 
     
     
         11 . The one or more computing device readable media having computing device executable instructions which when executed perform the method of  claim 9 , wherein the white list includes the identifier of one or more applications that perform better on the second graphics processing unit than the first graphics processing unit. 
     
     
         12 . One or more computing device readable media having computing device executable instructions which when executed perform a method comprising:
 loading a shim layer library, by the runtime application programming interface, instead of a device driver interface on a primary adapter;   loading the device driver interface on the primary adapter, by the shim layer library;   loading a device driver on an unattached adapter, by the shim layer library, wherein the display device interface on the unattached adapter is loaded without calling back to the runtime application programming interface;   determining, by the shim layer library, an affinity between an application and a second graphics processing unit;   processing graphics commands from the device driver interface on the unattached adapter to a device specific kernel mode driver of the second graphics processing unit through the shim layer library if the affinity between an application and the second graphics processing unit is determined; and   processing graphics commands from the device driver interface on the attached adapter to a device specific kernel mode driver of a first graphics processing unit through the runtime application programming interface if no affinity between an application and the second graphics processing unit is determined.   
     
     
         13 . The one or more computing device readable media having computing device executable instructions which when executed perform the method of  claim 12 , wherein the shim layer library has the same entry points as the device driver interface for the first graphics processing unit. 
     
     
         14 . The one or more computing device readable media having computing device executable instructions which when executed perform the method of  claim 12 , wherein the first graphics processing unit is an integral graphics processing unit and the second graphics processing unit is a discrete graphics processing unit having a different design than the integral graphics processing unit. 
     
     
         15 . A method comprising:
 loading and initializing a device driver interface and a device specific kernel mode driver for a graphics processing unit on a primary adapter; and   loading and initializing a device driver interface and a device specific kernel mode driver for a graphics processing unit on an unattached adapter without the device driver interface talking back to a runtime application programming interface when a particular versions of an operating system will not allow the device driver interface on the unattached adapter to be loaded.   
     
     
         16 . The method according to  claim 15 , further comprising:
 changing a search path for a display device interface to a search path of a shim layer library before loading the displayer device interface; and   loading the shim layer library, wherein the shim layer loads and initializes the device driver interface for the graphics processing unit on a primary adapter and loads and initializes the device driver interface for the graphics processing unit on an unattached adapter without the device driver interface talking back to the runtime application programming interface.   
     
     
         17 . The method according to  claim 15 , further comprising:
 determining an affinity between an application and a second graphics processing unit;   processing graphics commands from the device driver interface on the unattached adapter to the device specific kernel mode driver of the second graphics processing unit if the affinity between an application and a second graphics processing unit is determined; and   processing graphics commands from the device driver interface on the attached adapter to the device specific kernel mode driver of the first graphics processing unit f no affinity between an application and a second graphics processing unit is determined.   
     
     
         18 . The method according to  claim 17 , wherein determining the affinity between the application and the second graphics processing unit comprises determining if an identifier of the application is on a white list. 
     
     
         19 . The method according to  claim 18 , wherein the white list includes the identifier of one or more applications that perform better on the second graphics processing unit than the first graphics processing unit. 
     
     
         20 . The method according to  claim 15 , wherein the first graphics processing unit is a different design than the second graphics processing unit.