Input/output request packet handling techniques by a device specific kernel mode driver

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.

BACKGROUND OF THE INVENTION

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.

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

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.

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.

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.

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.

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.

DETAILED DESCRIPTION OF THE INVENTION

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.

Referring toFIG. 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 sets130,135, and one or more peripheral devices115,140-160communicatively 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 chipset130,135acts as a simple input/output hub for communicating data and instructions between the CPU105, the GPUs110,115, the computing device-readable media120,125, and peripheral devices115,140-165. In one implementation, the chipset includes a northbridge130and southbridge135. The northbridge130provides for communication between the CPU105, system memory120and the southbridge135. In one implementation, the northbridge130includes an integral GPU. The southbridge135provides for input/output functions. The peripheral devices115,140-165may include a display device140, 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 device115by a bus such as a Peripheral Component Interconnect Express (PCIe) bus.

The computing device-readable media120,125may 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 drive125may 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 memory120and/or graphics memory, provides for volatile storage of computer-readable instructions and data for use by the computing device. For instance, the system memory120may temporarily store a portion of the operating system, a portion of one or more applications and associated data that are currently used by the CPU105, GPU110and the like.

Generally, the GPU attached to the display140is designated as the primary GPU110and the other GPU is designated as the secondary GPU115. However, the secondary GPU115may be the primary computational unit. In other implementation, the computation workload may be dynamically switched between the primary and secondary GPU110,115based on processing performance, power consumption, and the like parameters.

Referring now toFIG. 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) manager210loads and initializes a device specific kernel mode driver (e.g., nvlddmkm.sys)220for a secondary GPU (e.g., dGPU)115. In one implementation, the I/O manager210calls a driver entry point (e.g., DriverEntry) to load the device specific kernel mode driver220. When calling the driver specific kernel mode driver220, the I/O manager210passes a dispatch table224-1in a driver object222-1to the device specific kernel mode driver220. The dispatch table224-1passed to the device specific kernel mode driver220includes pointers to one or more functions of the I/O manager210.

The device specific kernel mode driver220, for the secondary GPU115, calls the OS graphics driver subsystem. In one implementation, the device specific kernel mode driver220calls an operating system (OS) kernel mode driver (e.g., dxgkrnl.sys)230. In one implementation, the device specific kernel mode driver220calls a driver entry point (e.g., DxgkInitialize) of the OS kernel mode driver230. The device specific kernel mode driver220passes a dispatch table224-2in a driver object222-2to the OS kernel mode driver230. The dispatch table224-2passed to the OS kernel mode driver230includes the I/O manager function pointers.

After receiving the dispatch table224-2, the OS kernel mode driver230returns back to the device specific kernel mode driver220. When returning back to the device specific kernel mode driver220, the dispatch table224-3, passed in a driver object222-3, includes a plurality of pointers to functions of the OS kernel mode driver230and may also include the I/O manager function pointers. The plurality of functions pointers of the OS kernel mode driver230includes function pointers to OS dispatch IRP handlers236. The device specific kernel mode driver220stores a copy of the dispatch table224-3received from the OS kernel mode driver230as dispatch table224-4. The device specific kernel mode driver220also creates a dispatch table224-5by replacing one or more OS function pointers with one or more pointers to a dispatch handler in the device specific kernel mode driver220. 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 handler236in the OS dispatch table224-3that is for turning on or off the GPU, is replaced with a function pointer to the device specific kernel mode driver dispatch IRP handler226local to the device specific kernel mode driver220.

The device specific kernel mode driver220for the secondary GPU115then returns back to the I/O manager210. When returning back to the I/O manager210, the dispatch table224-5, passed in a driver object222-4, includes a plurality of pointers to functions of OS kernel mode driver and the device kernel mode driver220. The function pointers to the device specific kernel mode driver220include pointers to the dispatch IRP handlers226of the device specific kernel mode driver220, and the dispatch table224-4.

Accordingly, the I/O manager210, device specific kernel mode driver and OS kernel mode driver230pass around a dispatch table224in the driver object222. The I/O manager210, device specific kernel mode driver and OS kernel mode driver230each fill the dispatch table with their respective function pointers. The device specific kernel mode driver220, however, replaces one or more OS kernel mode driver230function pointers with pointers to the device specific kernel mode dispatch IRP handlers226.

Referring now toFIG. 3, a technique for IRP handling, in accordance with one embodiment of the present technology, is shown. The I/O manager210, 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 function228of the device specific kernel mode driver220using function pointer in the dispatch table224-5stored by the I/O manager210. When calling the dispatch function228, 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 function228looks at the content of the IRP to determine whether or not to hook the IRP. If the dispatch function228determines that the IRP is to receive a given handling, the dispatch function228routes the IRP to the device specific dispatch IRP handler226local to the device specific kernel mode driver220. In one implementation, the dispatch function228may 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 handler226local to the device specific kernel mode driver220. The device specific dispatch IRP handler226calls a function local to the device specific kernel mode driver220to handle the IRP and/or routes the IRP to a lower level driver, such as a bus filter driver240and/or bus driver250, 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 GPU115needs a given handling by the device specific dispatch IRP handler226of the device specific kernel mode driver220, instead of by the OS dispatch IRP handler236of the OS kernel mode driver230. If the IRP is completed through the device specific kernel mode driver220, the device specific kernel mode driver220reports completion back to the I/O manager210.

If the IRP is not to receive the given handling, the dispatch function228redirects the IRP back to the OS dispatch IRP handler236of the OS kernel mode driver230using an OS function pointer in the dispatch table224-4stored by the device specific kernel mode driver220. In response, the OS dispatch IRP handler236of the OS kernel mode driver230calls 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 driver230, the OS kernel mode driver230reports completion back to the I/O manager210.

The given handling may be provided by the functions of the device specific kernel mode driver220, instead of the OS kernel mode driver230. Accordingly, embodiments of the present technology enable IRP handling techniques that are not limited by the operating system.