API for launching work on a processor

One embodiment of the present invention sets forth a technique for launching work on a processor. The method includes the steps of initializing a first state object within a memory region accessible to a program executing on the processor, populating the first state object with data associated with a first workload that is generated by the program, and triggering the processing of the first workload on the processor according to the data within the first state object.

BACKGROUND OF THE INVENTION

1. Field of the Invention

Embodiments of the present invention relate generally to processor architectures and, more specifically, an application program interface (API) for launching work on a processor.

2. Description of the Related Art

In conventional computer systems, the processing power of a central processing unit (CPU) may be augmented by a co-processor, such as a GPU. GPUs are specialized processors that are configured to efficiently perform graphics processing operations or other operations that would otherwise be performed by the CPU. Some conventional computer systems are configured with a hybrid graphics system that includes, for example, an integrated GPU (iGPU) disposed on the motherboard along with the CPU and a discrete GPU (dGPU) located on an add-in card that is connected to the motherboard via a Peripheral Component Interconnect Express (PCI Express or PCIe) expansion bus and slot.

Typically, in such systems, work on the co-processor can only be launched by the CPU. Such a limitation can result in several inefficiencies. For example, if the co-processor is to execute a series of related tasks, where task B is dependent on the execution of task A, then the CPU will first launch task A on the GPU, wait until task A completes, and then launch task B. In such a scenario, because the CPU has to wait until the GPU indicates that task A has completed and then initiate the execution of task B, many clock cycles are wasted, thus reducing the overall performance of the system.

As the foregoing illustrates, what is needed in the art is an approach for launching work on a processor in a more efficient manner.

SUMMARY OF THE INVENTION

One embodiment of the present invention sets forth a method for launching work on a processor. The method includes the steps of initializing a first state object within a memory region accessible to a program executing on the processor, populating the first state object with data associated with a first workload that is generated by the program, and triggering the processing of the first workload on the processor according to the data within the first state object.

One advantage of the disclosed technique is that work can be launched on a processor from within the processor itself, thus eliminating wasted cycles in between the launching of two different tasks.

DETAILED DESCRIPTION

FIG. 1illustrates a processing environment100configured to implement one or more aspects of the present invention. The processing environment100includes a processor102, a program accessible memory104, a processor driver106, a work launching application program interface (API)108and an application program110.

The processor102is coupled to the program accessible memory104and the processor driver106. In operation, the processor102includes one or more processor cores that each executes a sequence of instructions associated with and/or transmitted by the various elements of the processing environment100, such as the application program110. The processor102can be a general purpose processor or a more special purpose processor, such as a graphics processing unit (GPU). The program accessible memory104is a memory space, usually a random access memory (RAM), that temporarily stores data needed to execute instructions within the processor102. The data in the program accessible memory104can be set via software programs running within the system100at any given time.

In operation, software programs, such as application program110, interact with the processor102via the processor driver106. More specifically, the processor driver106transmits commands generated by the application program110to the processor102for execution. In some cases, to initiate execution of a particular workload within the processor102, the application program110interfaces with the processor102via the work launching API108. The work launching API108interfaces with the processor driver106and allows the application program110to launch workloads for execution on the processor102.

To launch a workload, the application program110interacts with different API commands of the work launching API108to (i) allocate memory space in the program accessible memory104for a state object, (ii) store state information needed to execute the workload within the state object and (iii) trigger the execution of the workload. In one embodiment, the same state object may be shared across multiple workloads triggered by the application program110via the work launching API108. In an another embodiment, where the processor102is a multi-threaded processor, different threads within the processor102may execute the same workload using different state objects stored within the program accessible memory104. In yet another embodiment, a workload that is dependent on a primary workload which is currently being executed by the processor102can be automatically launched for execution within the processor102when the primary workload has been fully executed.

FIG. 2is a timeline view200when launching work within the processing environment100ofFIG. 1, according to one embodiment of the invention. As shown, there are three different steps for launching work on the processor102, creating a state object202, populating the state object204and triggering the workload execution206.

The work launching API108provides functions that can be issued by the application program110for each of the above steps. For creating a state object at step202, the work launching API108provides functions for initializing a specified portion of memory within the program accessible memory104that is to be allocated to a state object needed for executing a workload. The state object208,210and212illustrate state objects that have been initialized by the application program110. The structure of the state object may be pre-defined or may be dynamic based on a specification provided by the application program110. For populating the state object at step204, the work launching API108provides functions for setting different pre-determined pieces of state information within the state object. State information can include specifying a number of threads that will be executing the workload, memory management information or texture information in the case of graphics processing. Examples of specific functions providing by the work launching API108for setting state information in the state object are listed below. For triggering the workload execution at step208, the work launching API108provides functions for submitting the state object and launching the execution of the workload using the state object within the processor102.

FIG. 3is a flow diagram of method steps for launching a workload generated by an application program on a processor, according to one embodiment of the invention. Although the method steps are described in conjunction with the system forFIG. 1, persons skilled in the art will understand that any system configured to perform the method steps, in any order, is within the scope of the invention.

The method300begins at step302, where the work launching API108receives an instruction from the application program110to initialize a state object within the program accessible memory104. The application program110, via at least one function provided by the work launching API108, specifies a size of memory to be allocated to the state object. In response, at step304, the state object specified by the application program110is created within the program accessible memory104.

At step306, the work launching API108receives state information from the application program110for storing in the state object created at step304. The application program110, via at least one function provided by the work launching API108, specifies the different pieces of state information that are to be set within the state object. In response, at step308, the state object is populated with the state information specified by the application program110.

At step310, the work launching API108receives an indication from the application program110that a workload associated with the state object should be triggered within the processor102. At step314, the execution of the workload is triggered within the processor102.

FIG. 4is a conceptual diagram of an exemplary computing device400configured to implement one or more aspects of the present invention. The computing device400includes a central processing unit (CPU)402, a system interface404, a system memory410, a GPU450, a GPU local memory460and a display470.

The CPU402connects to the system memory410and the system interface404. The CPU402executes programming instructions stored in the system memory410, operates on data stored in system memory410and communicates with the GPU450through the system interface404, which bridges communication between the CPU402and GPU450. In alternate embodiments, the CPU402, GPU450, system interface404, or any combination thereof, may be integrated into a single processing unit. Further, the functionality of GPU450may be included in a chipset or in some other type of special purpose processing unit or co-processor. The system memory410stores programming instructions and data for processing by the CPU402. The system memory410typically includes dynamic random access memory (DRAM) configured to either connect directly to the CPU402(as shown) or alternately, via the system interface404. The GPU local memory460is any memory space accessible by the GPU450including local memory, system memory, on-chip memories, and peer memory. In some embodiments, the GPU450displays certain graphics images stored in the GPU local memory460on the display470.

In one embodiment, the GPU450includes a number M of SPMs (not shown), where M≧1, each SPM configured to process one or more thread groups. The series of instructions transmitted to a particular GPU450constitutes a thread, as previously defined herein, and the collection of a certain number of concurrently executing threads across the parallel processing engines (not shown) within an SPM is referred to herein as a “warp” or “thread group.” As used herein, a “thread group” refers to a group of threads concurrently executing the same program on different input data, with one thread of the group being assigned to a different processing engine within an SPM. A thread group may include fewer threads than the number of processing engines within the SPM, in which case some processing engines will be idle during cycles when that thread group is being processed. A thread group may also include more threads than the number of processing engines within the SPM, in which case processing will take place over consecutive clock cycles. Since each SPM can support up to G thread groups concurrently, it follows that up to G*M thread groups can be executing in GPU450at any given time.

Additionally, a plurality of related thread groups may be active (in different phases of execution) at the same time within an SPM. This collection of thread groups is referred to herein as a “cooperative thread array” (“CTA”) or “thread array.” The size of a particular CTA is equal to m*k, where k is the number of concurrently executing threads in a thread group and is typically an integer multiple of the number of parallel processing engines within the SPM, and m is the number of thread groups simultaneously active within the SPM. The size of a CTA is generally determined by the programmer and the amount of hardware resources, such as memory or registers, available to the CTA.

The system memory410includes an application program412, application data414, the work launching API108, a GPU driver418and GPU driver data420. The application program412generates calls to a the work launching API108as previously described in order to create state objects within the GPU local memory460and trigger the execution of workloads on the GPU450using those state objects.

Table 1 includes a list of functions provided by the work launching API108for creating and populating state objects as well as triggering the execution of workloads on the processor102.

In view of the foregoing, the scope of the present invention is determined by the claims that follow.