Abstract:
The input/output request packet (IRP) handling technique includes determining if a received input/output request packet should receive a given handling. If the input/output request packet should receive the given handling, the input/output request packet is dispatched to a device specific dispatch input/output request packet handler. Otherwise, the input/output request packet is redirected to an operating system dispatch input/output request packet handler.

Description:
BACKGROUND OF THE INVENTION 
       [0001]    Conventional computing systems may include a discrete graphics processing unit (dGPU) or an integral graphics processing unit (iGPU). The discrete GPU and integral GPU are heterogeneous because of their different designs. The integrated GPU generally has relatively poor processing performance compared to the discrete GPU. However, the integrated GPU generally consumes less power compared to the discrete GPU. A heterogeneous graphics processing computing system attempts to utilize the discrete and integral computing devices to improve overall performance. 
         [0002]    In the conventional art, the operating system handles all input/output request packets (IRP) for graphics devices. Accordingly, in a graphics co-processing computing system, handling of IRPs is limited by any restrictions imposed, intentionally or unintentionally, by the operating system. Such restrictions may limit the overall performance. Therefore, there is a need to enable IRP handling techniques that are not limited by the operating system. 
       SUMMARY OF THE INVENTION 
       [0003]    The present technology may best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the present technology. 
         [0004]    Embodiments of the present technology are directed toward input/output request packet (IRP) handling techniques by a device specific kernel mode driver. In one embodiment, the technique includes receiving by a device specific kernel mode driver a dispatch table including a plurality of input/output manager function pointers from an input/output manager. The dispatch table including the plurality of input/output manager function pointers is sent from device specific kernel mode driver to an operating system kernel mode driver. A dispatch table including the plurality of input/output manager function pointers and a plurality of operating system function pointers is receiving by the device specific kernel mode driver from the operating system kernel mode driver. The dispatch table including the plurality of input/output manager function pointers and the plurality of operating system function pointers is stored by the device specific kernel mode driver. The device specific kernel mode driver also creates a dispatch table including the plurality of input/output manager function pointers and the plurality of operating system functions wherein one or more of the operating system function pointers are replaced by one or more device specific kernel mode driver function pointers. The dispatch table including the plurality of input/output manager function pointers and the plurality of operating system functions wherein one or more of the operating system function pointers are replaced by one or more device specific kernel mode driver function pointers are sent by the device specific kernel mode driver to an input/output manager. 
         [0005]    Thereafter, input/output request packets are received by a device specific kernel mode driver. The device specific kernel mode driver determines if any of the input/output request packets should receive a given handling. If an input/output request packet should receive the given handling, the input/output request packet is dispatched to a device specific dispatch IRP handler. If the input/output request packet should not receive the given handling the input/output request packet is redirected to an operating system dispatch IRP handler. 
         [0006]    In another embodiment, the technique includes passing a dispatch table including a plurality of input/output manager function pointers from an input/output manager to a device specific kernel mode driver. The dispatch table including the plurality of input/output manager function pointers is passed from the device specific kernel mode driver to an operating system kernel mode driver. A dispatch table including the plurality of input/output manager function pointers and a plurality of operating system function pointers is passed from the operating system kernel mode driver to the device specific kernel mode driver. The dispatch table including the plurality of input/output manager function pointers and the plurality of operating system function pointers is stored in a dispatch table of device specific kernel mode driver. A dispatch table including the plurality of input/output manager function pointers and the plurality of operating system functions wherein one or more of the operating system function pointers are replaced by one or more device specific kernel mode driver function pointers is passed from the device specific kernel mode driver to the input/output manager. 
         [0007]    Thereafter, input/output request packets are passed from an input/output manager to a dispatch function of the device specific kernel mode driver. The dispatch function determines if the input/output request packet should receive a given handling. The input/output request packet is dispatched from the dispatch function to a device specific dispatch IRP handler if the input/output request packet is to receive the given handling. Otherwise, the input/output request packet is redirected from the dispatch handler to an operating system dispatch IRP handler if the input/output request packet is not to receive the given handling. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0008]    Embodiments of the present technology are illustrated by way of example and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which: 
           [0009]      FIG. 1  shows a graphics co-processing computing platform, in accordance with one embodiment of the present technology. 
           [0010]      FIG. 2  shows a technique for initializing input/output request packet (IRP) handling, in accordance with one embodiment of the present technology. 
           [0011]      FIG. 3  shows a technique for IRP handling, in accordance with one embodiment of the present technology. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0012]    Reference will now be made in detail to the embodiments of the present technology, examples of which are illustrated in the accompanying drawings. While the present technology will be described in conjunction with these embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the scope of the invention as defined by the appended claims. Furthermore, in the following detailed description of the present technology, numerous specific details are set forth in order to provide a thorough understanding of the present technology. However, it is understood that the present technology may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the present technology. 
         [0013]    Embodiments of the present technology enable the ability to hook one or more IRPs and decide how to handle the IRPs. Embodiments may be utilized to provide a given handling for one or more hooked IRPs. 
         [0014]    Referring to  FIG. 1 , a graphics co-processing computing platform, in accordance with one embodiment of the present technology is shown. The exemplary computing platform may include one or more central processing units (CPUs)  105 , a plurality of graphics processing units (GPUs)  110 ,  115 , volatile and/or non-volatile memory (e.g., computer readable media)  120 ,  125 , one or more chip sets  130 ,  135 , and one or more peripheral devices  115 ,  140 - 160  communicatively coupled by one or more busses. The GPUs include heterogeneous designs. In one implementation, a primary GPU may be an integral graphics processing unit (iGPU) and a secondary GPU may be a discrete graphics processing unit (dGPU). The chipset  130 ,  135  acts as a simple input/output hub for communicating data and instructions between the CPU  105 , the GPUs  110 ,  115 , the computing device-readable media  120 ,  125 , and peripheral devices  115 ,  140 - 165 . In one implementation, the chipset includes a northbridge  130  and southbridge  135 . The northbridge  130  provides for communication between the CPU  105 , system memory  120  and the southbridge  135 . In one implementation, the northbridge  130  includes an integral GPU. The southbridge  135  provides for input/output functions. The peripheral devices  115 ,  140 - 165  may include a display device  140 , a network adapter (e.g., Ethernet card)  145 , CD drive, DVD drive, a keyboard, a pointing device, a speaker, a printer, and/or the like. In one implementation, the secondary GPU is coupled as a discrete GPU peripheral device  115  by a bus such as a Peripheral Component Interconnect Express (PCIe) bus. 
         [0015]    The computing device-readable media  120 ,  125  may be characterized as primary memory and secondary memory. Generally, the secondary memory, such as a magnetic and/or optical storage, provides for non-volatile storage of computer-readable instructions and data for use by the computing device. For instance, the disk drive  125  may store the operating system (OS), applications and data. In one implementation, the operating system may be a Windows Operating System from Microsoft Corporation in Redmond, Wash., U.S.A. The primary memory, such as the system memory  120  and/or graphics memory, provides for volatile storage of computer-readable instructions and data for use by the computing device. For instance, the system memory  120  may temporarily store a portion of the operating system, a portion of one or more applications and associated data that are currently used by the CPU  105 , GPU  110  and the like. 
         [0016]    Generally, the GPU attached to the display  140  is designated as the primary GPU  110  and the other GPU is designated as the secondary GPU  115 . However, the secondary GPU  115  may be the primary computational unit. In other implementation, the computation workload may be dynamically switched between the primary and secondary GPU  110 ,  115  based on processing performance, power consumption, and the like parameters. 
         [0017]    Referring now to  FIG. 2 , a technique for initializing IRP handling, in accordance with one embodiment of the present technology, is shown. During initialization of the graphics co-processing computing system, an input/output (I/O) manager  210  loads and initializes a device specific kernel mode driver (e.g., nvlddmkm.sys)  220  for a secondary GPU (e.g., dGPU)  115 . In one implementation, the I/O manager  210  calls a driver entry point (e.g., DriverEntry) to load the device specific kernel mode driver  220 . When calling the driver specific kernel mode driver  220 , the I/O manager  210  passes a dispatch table  224 - 1  in a driver object  222 - 1  to the device specific kernel mode driver  220 . The dispatch table  224 - 1  passed to the device specific kernel mode driver  220  includes pointers to one or more functions of the I/O manager  210 . 
         [0018]    The device specific kernel mode driver  220 , for the secondary GPU  115 , calls the OS graphics driver subsystem. In one implementation, the device specific kernel mode driver  220  calls an operating system (OS) kernel mode driver (e.g., dxgkrnl.sys)  230 . In one implementation, the device specific kernel mode driver  220  calls a driver entry point (e.g., DxgkInitialize) of the OS kernel mode driver  230 . The device specific kernel mode driver  220  passes a dispatch table  224 - 2  in a driver object  222 - 2  to the OS kernel mode driver  230 . The dispatch table  224 - 2  passed to the OS kernel mode driver  230  includes the I/O manager function pointers. 
         [0019]    After receiving the dispatch table  224 - 2 , the OS kernel mode driver  230  returns back to the device specific kernel mode driver  220 . When returning back to the device specific kernel mode driver  220 , the dispatch table  224 - 3 , passed in a driver object  222 - 3 , includes a plurality of pointers to functions of the OS kernel mode driver  230  and may also include the I/O manager function pointers. The plurality of functions pointers of the OS kernel mode driver  230  includes function pointers to OS dispatch IRP handlers  236 . The device specific kernel mode driver  220  stores a copy of the dispatch table  224 - 3  received from the OS kernel mode driver  230  as dispatch table  224 - 4 . The device specific kernel mode driver  220  also creates a dispatch table  224 - 5  by replacing one or more OS function pointers with one or more pointers to a dispatch handler in the device specific kernel mode driver  220 . The replaced function pointers are for calls that are to receive a given handling. In one implementation, the given handling may be a power control function. In one implementation, the function pointer to the OS dispatch IRP handler  236  in the OS dispatch table  224 - 3  that is for turning on or off the GPU, is replaced with a function pointer to the device specific kernel mode driver dispatch IRP handler  226  local to the device specific kernel mode driver  220 . 
         [0020]    The device specific kernel mode driver  220  for the secondary GPU  115  then returns back to the I/O manager  210 . When returning back to the I/O manager  210 , the dispatch table  224 - 5 , passed in a driver object  222 - 4 , includes a plurality of pointers to functions of OS kernel mode driver and the device kernel mode driver  220 . The function pointers to the device specific kernel mode driver  220  include pointers to the dispatch IRP handlers  226  of the device specific kernel mode driver  220 , and the dispatch table  224 - 4 . 
         [0021]    Accordingly, the I/O manager  210 , device specific kernel mode driver and OS kernel mode driver  230  pass around a dispatch table  224  in the driver object  222 . The I/O manager  210 , device specific kernel mode driver and OS kernel mode driver  230  each fill the dispatch table with their respective function pointers. The device specific kernel mode driver  220 , however, replaces one or more OS kernel mode driver  230  function pointers with pointers to the device specific kernel mode dispatch IRP handlers  226 . 
         [0022]    Referring now to  FIG. 3 , a technique for IRP handling, in accordance with one embodiment of the present technology, is shown. The I/O manager  210 , after creating an IRP in response to an I/O request for the user mode, plug-and-play manager, power manager, driver, or other system component, calls the dispatch function  228  of the device specific kernel mode driver  220  using function pointer in the dispatch table  224 - 5  stored by the I/O manager  210 . When calling the dispatch function  228 , the I/O manager passes a pointer to the IRP. The IRP is a data structure, including arguments and parameters such as buffer address, buffer size, I/O function type and/or the like, that describes the I/O request. The dispatch function  228  looks at the content of the IRP to determine whether or not to hook the IRP. If the dispatch function  228  determines that the IRP is to receive a given handling, the dispatch function  228  routes the IRP to the device specific dispatch IRP handler  226  local to the device specific kernel mode driver  220 . In one implementation, the dispatch function  228  may determine that a power control IRP, plug-and-play IRP or the like needs special handling and routs the power control IPR to the device specific dispatch IRP handler  226  local to the device specific kernel mode driver  220 . The device specific dispatch IRP handler  226  calls a function local to the device specific kernel mode driver  220  to handle the IRP and/or routes the IRP to a lower level driver, such as a bus filter driver  240  and/or bus driver  250 , if needed. For example, the dispatch function may determine that a start, set power, or go to sleep type I/O request for the secondary GPU  115  needs a given handling by the device specific dispatch IRP handler  226  of the device specific kernel mode driver  220 , instead of by the OS dispatch IRP handler  236  of the OS kernel mode driver  230 . If the IRP is completed through the device specific kernel mode driver  220 , the device specific kernel mode driver  220  reports completion back to the I/O manager  210 . 
         [0023]    If the IRP is not to receive the given handling, the dispatch function  228  redirects the IRP back to the OS dispatch IRP handler  236  of the OS kernel mode driver  230  using an OS function pointer in the dispatch table  224 - 4  stored by the device specific kernel mode driver  220 . In response, the OS dispatch IRP handler  236  of the OS kernel mode driver  230  calls a function of the OS kernel mode driver and/or routes the IRP to a lower driver, if needed. If the IRP is completed through the OS kernel mode driver  230 , the OS kernel mode driver  230  reports completion back to the I/O manager  210 . 
         [0024]    The given handling may be provided by the functions of the device specific kernel mode driver  220 , instead of the OS kernel mode driver  230 . Accordingly, embodiments of the present technology enable IRP handling techniques that are not limited by the operating system. 
         [0025]    The foregoing descriptions of specific embodiments of the present technology have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the present technology and its practical application, to thereby enable others skilled in the art to best utilize the present technology and various embodiments with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the claims appended hereto and their equivalents.