KR20090107973A - Execution of retargetted graphics processor accelerated code by a general purpose processor - Google Patents

Abstract

PURPOSE: Execution of retargeted graphics processor accelerated code by a general purpose processor is provided to configure a general purpose processor in order to execute a translated application program. CONSTITUTION: A CPU(102) operates as the control processor of a computer system(100), managing and coordinating the operation of other system components. In particular, the CPU issues commands that control the operation of parallel processors(134) within a multithreaded processing subsystem(112). CPU writes a stream of commands for parallel processors to a command buffer, which may reside in a system memory(104), a subsystem memory(138), or another storage location accessible to both CPU and parallel processors. Parallel processors read the command stream from the command buffer and execute commands asynchronously with respect to the operation of CPU. System memory includes an execution image of an operating system, a device driver(103), and CUDA code(101) that is configured for execution by multithreaded processing subsystem. CUDA code incorporates programming instructions intended to execute on multithreaded processing subsystem. In the context of the present description, code refers to any computer code, instructions, and/or functions that may be executed using a processor.

Description

Execution of Retargeted Graphics Processor Accelerated Code by General-Purpose Processor {EXECUTION OF RETARGETTED GRAPHICS PROCESSOR ACCELERATED Code

Cross Reference of Related Application

This application is filed on April 9, 2008, entitled "System For Executing GPU-Accelerated Code on Multi-Core Architectures," US Provisional Serial No. 61 / 043,708 (Attorney Docket No. NVDA / SC-08-0007- Claiming priority of US0). This related application is incorporated herein by reference.

Field of technology

Embodiments of the present invention generally relate to compiler programs, and more specifically, for execution by a general-purpose processor having a shared memory and recorded for execution by a multi-core graphics processing unit. It relates to the targeted application program.

Modern graphics processing systems typically include a multicore graphics processing unit (GPU) that is configured to execute applications in a multithreaded manner. Graphics processing systems also include a memory having a portion shared between execution threads and a dedicated portion of each thread.

NVIDIA's Compute Unified Device Architecture (CUDA ™) technology allows programmers and developers to record software applications to solve complex computational problems such as video and audio encoding, modeling for oil and gas exploration, and medical imaging. Provide a C language environment that makes it possible. Applications are configured for parallel execution by a multicore GPU and typically rely on specific features of the multicore GPU. Since the same specific features are not available on a general purpose CPU, a software application written using CUDA may not be portable to run on a general purpose CPU.

As mentioned above, there is a need in the art for techniques to enable programmers to run written application programs on general purpose CPUs using a parallel programming model for execution on a multicore GPU, without the need for programmers to modify the application program. .

One embodiment of the present invention discloses a method of configuring a general purpose processor to execute a translated application program. The method comprises receiving a transformed application program from a recorded application program using a parallel programming model for execution on a multicore graphics processing unit and compiling the translated application program for execution by a general purpose processor. Generating the compiled code. The number of execution cores of the general purpose processor available to execute the compiled code is determined and the general purpose processor is configured to enable the number of execution cores. Compiled code is launched for execution by a general purpose processor, including the number of execution cores.

One advantage of the disclosed method is that application programs written using a parallel programming model for execution on multicore GPUs are portable without modification to general purpose CPUs. Portions of the application that depend on the specific features of the multicore GPU are translated by the translator for execution by the general purpose CPU. The application program is partitioned into areas of synchronization and independent instructions. Instructions are classified as convergent and divergent, and divergent memory references shared between regions are replicated. Thread loops are inserted to ensure accurate memory sharing between the various threads during execution by the general purpose CPU.

Thus, the present invention, briefly summarized above, may be described in more detail with reference to embodiments, some of which are illustrated in the accompanying drawings, in order that the features disclosed herein may be understood in detail. However, the present invention may tolerate other equally effective embodiments so the accompanying drawings only illustrate typical embodiments of the invention and should not be taken as limiting the scope of the invention.

In the following description, numerous specific details are set forth in order to provide a more complete understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without one or more of these specific details. In other instances, well-known features have not been described in order to avoid obscuring the present invention.

1 is a block diagram illustrating a computer system 100 configured to execute code described using CUDA. Computer system 100 includes a system memory 104 and a CPU 102 in communication over a bus path that includes a memory bridge 105. Memory bridge 105, which may be, for example, a northbridge chip, is connected to I / O bridge 107 via a bus or other communication path 106 (eg, a HyperTransport link). For example, the I / O bridge 107, which may be a southbridge chip, receives user input from one or more user input devices 108 (eg, keyboard, mouse) and transmits the path 106 and memory bridge 105. The input is passed through to the CPU 102. Multithreaded processing subsystem 112 is coupled to memory bridge 105 via a bus or other communication path 113 (eg, PCI Express, Accelerated Graphics Port, or HyperTransport link). In one embodiment, the multithreaded processing subsystem 112 is a graphics subsystem for delivering pixels to the display device 110 (eg, a conventional CRT or LCD based monitor). The system disk 114 is also connected to the I / O bridge 107. Switch 116 provides connections between I / O bridge 107 and other components, such as network adapter 118 and various add-in cards 120 and 121. Other components (not explicitly shown), including USB or other port connections, CD drives, DVD drives, film recording devices, etc., may also be connected to the I / O bridge 107. The communication paths that interconnect with the various components of FIG. 1 are Peripheral Component Interconnect (PCI), PCI Express (PCI-E), Accelerated Graphics Port (AGP), HyperTransport, or any other bus or point-to-point communication protocol. It may be implemented using any suitable protocols such as (s), and connections between different devices may use different protocols known in the art.

CPU 102 acts as a control processor of computer system 100, managing and coordinating the operation of other system components. In particular, CPU 102 issues instructions to control the operation of parallel processors 134 in multithreaded processing subsystem 112. In some embodiments, CPU 102 may reside in system memory 104, subsystem memory 138, or in another storage location accessible to both CPU 102 and parallel processors 134. Write a stream of instructions for parallel processors 134 to a buffer (not shown). Parallel processors 134 read the instruction stream from the instruction buffer and execute instructions asynchronously to the operation of the CPU 102.

System memory 104 includes CUDA code 101, device driver 103, and an execution image of an operating system configured for execution by multithreaded processing subsystem 112. CUDA code 101 includes programming instructions intended to be executed on the multithreaded processing subsystem 112. In the context of the present description, code refers to any computer code, instructions, and / or functions that may be executed using a processor. For example, in various embodiments, the code may include C code, C ++ code, and the like. In one embodiment, the code may include language extensions of computer languages (eg, extensions of C, C ++, etc.).

The operating system provides detailed instructions to manage and coordinate the operation of the computer system 100. The device driver 103 provides specific instructions for managing and coordinating the operations of the multithreaded processing subsystem 112, particularly the parallel processors 134. Moreover, device driver 103 may provide editing functionality for generating machine code specifically optimized for parallel processors 134. The device driver 103 may be provided with the CUDA ™ framework provided by NVIDIA Corporation.

In one embodiment, the multithreaded processing subsystem 112 is one or more parallel processors that may be implemented using one or more integrated circuit devices such as, for example, programmable processors, application specific integrated circuits (ASICs). Integrate 134. Parallel processors 134 may include circuitry optimized for graphics and image processing, including, for example, image output circuitry and graphics processing unit (GPU). In another embodiment, multithreaded processing subsystem 112 is integrated with one or more other system elements such as memory bridge 105, CPU 102, and I / O bridge 107 to provide a system on SoC. chip) can be formed. One or more parallel processors 134 may output data to the display device 110, or each parallel processor 134 may output data to the one or more display devices 110.

Parallel processors 134 advantageously comprise a highly parallel processor that includes one or more processing cores, each of which can simultaneously execute multiple threads, each thread being an instance of a program such as code 101. ). Parallel processors 134 can be used for linear and nonlinear data transformations, filtering of image and / or acoustic data, modeling operations (e.g., applying physics to determine the position, velocity, and other properties of objects), Image rendering operations (e.g., but not limited to, mosaic shader, vertex shader, geometry shader and / or pixel shader programs), It can be programmed to execute processing tasks related to a wide variety of applications. Parallel processors 134 transfer data from system memory 104 and / or local subsystem memory 138 to local (on-chip) memory, process the data and return the resulting data to system memory 104 and / or Write back to subsystem memory 138, and such data may be accessed by other system components including CPU 102 or other multithreaded processing subsystem 112.

The parallel processor 134 can have any amount of subsystem memory 138, including those that do not include the subsystem memory 138, and can optionally include the subsystem memory 138 and the system memory 104. It can be used in combination. For example, parallel processor 134 may be a graphics processor of an unified memory architecture (UMA) embodiment. In such embodiments, only a small or no dedicated subsystem memory 138 may be provided, and the parallel processor 134 will use the system memory 104 exclusively or almost exclusively. In UMA embodiments, parallel processor 134 is a separate chip with a high speed link (e.g., PCI-E) that connects parallel processor 134 to system memory 104 via a bridge chip or other communication means. It may be provided as or integrated into a bridge chip or processor chip.

As noted above, any number of parallel processors 134 may be included in the multithreaded processing subsystem 112. For example, multiple parallel processors 134 may be provided on a single add-in card, or multiple add-in cards may be connected to the communication path 113, or one or more parallel processors 134 may be provided. It can be integrated into a bridge chip. If there are multiple parallel processors 134, such parallel processors 134 may be operated in parallel to process data with higher throughput than is possible with a single parallel processor 134. Systems incorporating one or more parallel processors 134 may be implemented in a variety of configurations and form factors, including desktop, laptop or handheld personal computers, servers, workstations, game consoles, embedded systems, and the like. It includes.

In some embodiments of parallel processors 134, single-instruction (multi-data) instruction issuing techniques are used to support parallel execution of multiple threads without providing multiple independent instruction units. In other embodiments, single-instruction, multiple-thread (SIMT) techniques are used to support parallel execution of a plurality of generally synchronized threads. Unlike the SIMD execution regime, in which all processing engines typically execute the same instructions, SIMT execution makes it easier to follow the divergent execution paths that different threads diverge through a given thread program. Those skilled in the art will understand that the SIMD processing regime represents a functional subset of the SIMT processing regime. Functional units in parallel processors 134 are integer and floating point operations (eg, addition and multiplication), comparison operations, Boolean operations (AND, OR, XOR), bit-shifting. And various algebraic functions (e.g., planar interpolation, trigonometric, exponential and logarithmic functions, etc.).

This series of instructions sent to a specific processing unit (not shown) within the processing core (not shown) of the parallel processors 134 constitutes a thread as previously defined herein, and the processing unit within one processing core. A collection of any number of threads executing concurrently across the domains is referred to herein as a "thread group." As used herein, "thread group" refers to a group of threads that execute the same program for different input data, and each thread of the group is assigned to a different processing unit of the processing core. The thread group may include fewer threads than the number of processing units, in which case some processing units will be idle during the cycles in which the thread group is processed. The thread group may include more threads than the number of processing units, in which case processing will occur over multiple clock cycles.

Since each processing core can support up to G thread groups simultaneously, up to G × M thread groups can run on the processing core at any given time, where M is the number of processing cores of the parallel processor 134. In addition, a plurality of related thread groups can be active simultaneously (in different phases of execution) within the processing core. This collection of thread groups is referred to herein as a "cooperative thread array (CTA)." 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 CUDA programming model reflects the system architecture of GPU accelerators. An exclusive local address space is available for each thread and a shared per-CTA address space is used to transfer data between threads within the CTA. Processing cores access out-of-chip “global” memory, which may include subsystem memory 138 and / or system memory 104.

The host portion of the CUDA application program is compiled using conventional methods and tools, while kernel functions specify CTA processing. At the highest level, the CUDA memory model separates host memory space from device memory spaces, allowing only host code and kernel code to directly access their respective memory spaces. Application programming interface (API) functions allow data to be copied between host memory space and device memory space. In shared memory CPU execution of the CUDA programming model, the CPU control thread can execute in parallel using parallel CTAs without potential data races. Host memory space is defined by the C programming language and device memory spaces are specified as global, constant, local, shared and texture. Every thread can access global, constant, and texture memory spaces. As described earlier, access to local space is limited to a single thread and access to shared space is limited to threads of the CTA. This memory model encourages the use of small memory spaces for low latency accesses, and encourages wise use of larger memory spaces, which typically have longer latency.

CUDA programs such as code 101 are typically organized as a set of synchronous or asynchronous executions of CTAs in one, two or three dimensions (eg, x, y and z). The 3-tuple index uniquely identifies the threads in the thread block. The thread blocks themselves are distinguished by implicitly defined two-tuple variables. The ranges of these indexes are defined at run time and the runtime environment checks whether the indexes conform to any hardware restrictions. Each CTA may be executed in parallel by parallel processor 134 along with other CTAs. Multiple CTAs can operate in parallel while each parallel processor 134 executes one or more CTAs. The runtime environment is responsible for managing the execution of the CUDA code 101 synchronously or asynchronously when requested. Threads in the CTA communicate and synchronize with each other using shared memory and a barrier synchronization primitive called synchthreads (). CUDA ensures that threads in a thread block continue to live at the same time, providing constructs for threads in the thread block to perform fast barrier synchronizations and local data sharing. Separate thread blocks within a CTA (defined by one or more dimensions) are out of order to follow in their creation, execution, or retirement. In addition, parallel CTAs are not allowed to access system calls containing I / O. The CUDA programming model only enforces global synchronization between parallel CTAs and provides intrinsic atomic operations for limited communication between blocks within the CTA.

The body of each thread, called the kernel, is specified using CUDA and can be expressed in standard C using memory model annotations and barrier synchronization primitives. The semantics of a CUDA program is that each kernel is executed by every thread in the CTA in an order that does not violate the memory order implied by the barrier synchronization primitive. In particular, all shared memory references in the CTA that occur before the barrier synchronization primitive must be completed before any shared memory references that occur after the barrier synchronization primitive.

Each instance of a barrier synchronization primitive in kernel code represents a conceptually separate logical barrier and should be treated as static. Invoking a barrier synchronization primitive in both paths of an if-else structure is a foul when CUDA threads can take different branches of the structure. Although every thread in a thread block will reach one of the synchronization primitives, they each represent individual barriers that every thread must reach or no thread reaches. Thus, such a kernel will not run correctly. More generally, CUDA code is not guaranteed to execute correctly if the synchronization primitive is included in any control flow structure that behaves differently for different threads in the thread block.

2 is a block diagram illustrating a computer system 200 according to one embodiment of the invention. Computer system 100 includes a system memory 204 and a CPU 202 that communicate over a bus path that includes a memory bridge 205. For example, the memory bridge 205, which may be a northbridge chip, is connected to the I / O (input / output) bridge 107 via a bus or other communication path 106 (eg, a HyperTransport link). The CPU 202 generates an output for display on the display device 210 (eg, a conventional CRT or LCD based monitor).

The multithreaded processing subsystem 112 is not included in the computer system 200 and the CUDA code 101 is not adapted for execution by a general purpose processor such as the CPU 202. CUDA code 101 is adapted for execution by multithreaded processing subsystem 112 and is translated using translator 220 to produce translated code 201 that does not include barrier synchronization primitives. . In order for the CPU 202 to run the program represented by the code 101, the code 101 must first be translated into the code 201. The translated code can then be compiled for execution by the CPU 202 by the compiler 225. Compiler 225 may perform optimizations specific to CPU 202. Translating code refers to converting code written in a first computer language to a second computer language. Compiling the code refers to converting code written in a computer language (eg, source code) into another computer language (eg, object code). Translator 220 is described in conjunction with FIG. 3A and compiler 225 is described in relation to FIG. 4. Compiler 225 may be included in device driver 203 that is configured to interface between code 101, code 201, and CPU 202. Runtime environment 227 is configured to implement functions for compiled code, such as input and output, memory management, and the like. Runtime environment 227 also launches compiled code for execution by CPU 202. Translator 220 performs optimization transformations to serialize operations into a single CPU thread across the fine-grained threads of a CUDA thread group, while runtime environment 227 processes the thread groups to CPU. Schedule as work units for parallel processing by 202.

A major obstacle to the portability of CUDA applications designed to run on GPUs for execution by general purpose CPUs is the granularity of parallelism. Conventional CPUs do not support hundreds of hardware threads that a single CUDA CTA requires. Thus, the main goal of a system implementing a CUDA programming model on a general purpose CPU is to distribute task level parallelism across the available CPU cores. At the same time, the system must consolidate microthreads within a task into a single CPU thread to prevent excessive scheduling overhead and frequent intercore synchronization.

3A illustrates code 101 for example written for execution by a multicore graphics processing unit, such as, for example, multithreaded processing subsystem 112, according to one embodiment of the invention. Is a flowchart of method steps for translating into code 201 for execution by a general purpose processor such as < RTI ID = 0.0 > Translator 220 is configured to perform one or more steps shown in FIG. 3A to preserve the barrier synchronization primitive semantics used in code 101. Translator 220 "unrolls" parallel threads by partitioning code 101 around barrier synchronization primitives, reduces the use of shared state, improves the locality of references for memory access, and Insert thread loops to convert CUDA-specific code for execution by a general purpose processor. It is possible to achieve good execution performance using the CPU 202 to execute the code 201 without changing the CUDA code 101 targeted for execution by the multithreaded processing subsystem 112. Compiler 225 may utilize the capabilities of the vector instructions provided by CPU 202 and may perform optimizations when compiling code 201 for execution.

In step 300 the translator 220 is executed by a multi-core GPU, such as a multithreaded processing subsystem 112 or a processor including one or more parallel processors 134, for example CUDA code 101. Receive the recorded code 101. The code received in step 300 is represented as a control flow graph composed of basic block nodes connected by edges. Each basic block specifies the operations performed by the target environment, such as, for example, the CPU 202. In step 305 translator 220 partitions CUDA code 101 around barrier synchronization primitives to generate partitioned code. The partitioned code is shown in FIGS. 3B and 3C and the partitioning process is described with respect to these figures. A synchronization partition is an area of code in which the order of operations is entirely determined by the control flow and data flow characteristics of the basic blocks within the partition. Partitions have the property that thread loops can be inserted around partitions to run parallel threads. The control flow graph can be used to create a sync partition control flow graph by replacing each synchthreads primitive with an edge and separating the base block node into different partitions.

The code partitioned at step 310 is classified such that each statement is identified as either converging or diverging. Partitioned code can include expressions and statements. An expression is a calculation that may involve named variables, implicit threadIDs, and constants made by a programmer, but without side-effects or assignments. Simple statements are defined as expressions that result in a single assignment. A general sentence may represent a barrier, control flow condition or loop structure, or a sequential block of sentences. CTA dimensions x, y and z are propagated through the code to determine whether each operation depends on one or more CTA dimensions. Operations referring to threadIDs (thread identifiers) of dimensions x, y and / or z are considered divergent because a thread referring to the CTA dimension may diverge during execution from other threads of the same CTA. For example, operations that depend on threadID.x diverge in the x dimension. Other operations that do not depend on threadID.x converge. Divergent statements require thread loops for each CTA dimension they refer to.

The code partitioned in step 315 is optimized for performance using the classification information to generate the optimized code. For example, instructions within a partition may be reordered to fuse the operations and fall within the same thread loop where those operations that are equally classified are grouped together and inserted in step 325. The operations are arranged so that operations with fewer threadID dimensions in their variation vector proceed with operations that depend on more threadID dimensions. This reordering is effective because the statement must have a bearance vector that is a superset of the bearance vector of the states it depends on. Thus states having only one dimension in the bearance vector may not depend on any state having a different dimension or more than one dimension in the bearance vector.

In step 320 thread-local memory references of the optimized code are promoted to array references as needed, ensuring that each instance of the object has a unique location for storing a value. In particular, data transferred from one partition to another needs to be copied and made available to each partition. A variable that satisfies one of the conditions of a local variable with cross-partition dependency (assigned to one partition and referenced by another partition) is promoted to an array reference.

In step 320 the translator 220 promotes thread-local memory references to array references. The program shown in Table 1 includes synchronization barrier primitives and divergent references.

The program shown in Table 1 is partitioned into a first partition before the synchthreads primitive and a second partition after the synchthreads primitive. The second partition includes references (leftIndex and rightIndex) that are calculated in the first partition and depend on the CTA dimension. If divergence references are not promoted, the second partition will incorrectly use the values calculated by the last iteration of the first partition. The second partition should use the calculated value for each corresponding iteration of threadId.x of the first partition. To ensure that the calculation is correct, divergence references are promoted as shown in Table 2.

In step 325 thread loops are generated for statements that include threadID dimensions in the bearance vectors. Adaptive loop nesting is used to simultaneously evaluate the transforms equivalent to loop swapping, loop fission and loop invariant removal to achieve the best deduplication. Nested loops are dynamically created to best fit the application by values of each dimension of the threadID tuple, rather than assuming a particular loop nesting or evaluating an application based on that nesting. After the statements are sorted in step 315, loops may be generated for threadID dimensions only around those statements that include that dimension in their bearance vector. To eliminate loop overhead, translator 220 can fuse adjacent group of sentences with one group having a vector of vectors, one group being a subset of another group.

3B is a conceptual diagram illustrating an input code 101 translated to partitioned code 350, in accordance with an embodiment of the present invention. Input code 330 includes code sequences 331 and 332 that are configured for execution by multithreaded processing subsystem 112 and separated by synchronization barrier instruction 336. All threads of the CTA will complete execution of code sequence 331 before any of the threads begins execution of code sequence 332. Translator 220 partitions input code 330 to generate partitioned code 350, partition 351 includes instructions represented by code sequence 331 and partition 352 includes code sequence 332. Contains the commands represented by). Thread loop 353 is inserted around partition 352 to ensure that the synchronization semantics are maintained when partitioned code 350 is executed by a general purpose processor that does not natively support synchronization barrier instructions. In this example, code partition 351 may include convergent references and partition 352 may include divergent references. Thus, thread loop 353 is inserted around partition 352.

In step 352 of FIG. 3A, translator 220 adds thread loops (such as thread loop 353) to optimized code to generate code 201 that is translated for execution by CPU 202. Insert it. Each partition can have a thread loop inserted for each CTA dimension. One example of synchronous partitioning and thread loop insertion is shown in Tables 3 and 4. The program shown in Table 3 is translated into the program shown in Table 4.

The program in Table 3 uses explicit synchronization to ensure accurate sharing of memory among the various threads of the CTA. Translator 220 partitions the program into two partitions, each of which depends on the x CTA dimension. Thus, a thread loop is inserted around each of the two partitions to ensure that the translated program performs the operations in the correct order.

A simpler technique for translating a program for execution by a general purpose processor inserts explicit thread loops into each CTA dimension, eliminating the need to determine dimension dependencies for references within the same partition. For example, the program shown in Table 5 is translated into the program shown in Table 6. Note that one or more of the thread loops inserted in Table 5 may not be needed because the program was created without determining the dimension dependencies.

3C is a conceptual diagram illustrating input code 333 translated to optimized code 360, in accordance with an embodiment of the present invention. Input code 333 includes code sequences 334 and 338 that are configured for execution by multithreaded processing subsystem 112 and separated by synchronization barrier instruction 335. All threads of the CTA will complete execution of code sequence 334 before any one of the threads begins execution of code sequence 338. Translator 220 partitions input code 333 to generate partitioned code 360, partition 361 includes instructions represented by code sequence 334 and partitions 362, 364, 365. Includes instructions represented by code sequence 338.

Partition 362 includes a first portion of instructions that emanate at a first CTA level. Partition 364 contains the second subsection ¶ of converging instructions. Partition 365 includes a third portion of instructions emitted at the second CTA level. Thread loop 363 is inserted around partition 362 to ensure that the synchronization semantics are maintained when partitioned code 360 is executed by a general purpose processor that does not natively support synchronization barrier instructions. Thread loop 363 is repeated on the first CTA dimension. Thread loop 366 is inserted around partition 365 to repeat on the second CTA dimension.

Table 7 shows an example CUDA kernel and Table 8 shows the translation of the CUDA kernel for execution by a general purpose processor. The exemplary kernel multiply the list of small matrices. Each thread block computes one small matrix multiplication outside the list, but each thread calculates one element of the resulting matrix for that block.

Note that the statement in row (9) of Table 7 has a bearance vector of (x, y) because col depends on the x dimension and the row depends on the y dimension. Since the z dimension is never used, loops that repeat on z are not inserted. Conventional cost analysis techniques may be used to determine cases such as sentences 5 and 6 of the exemplary kernel shown in Table 7. Since each depends only on one threadID dimension, selecting the nesting order of either of the x and y index loops will force duplicate execution of the statement, or force a duplicate loop outside the partition's main loop nesting.

4 is a flowchart of method steps for execution of translated code 201 by a general purpose processor, such as CPU 202, in accordance with an embodiment of the present invention. In step 400 the compiler 225 optionally performs CPU specific optimizations to generate the compiled code by compiling the translated code 201. In step 405 the number of execution cores 400 available to the CPU 202 is determined by the device driver 203. The translated code 201 can be automatically scaled for execution on execution cores available for improved performance. In step 410 the runtime environment 227 or device driver 203 configures the CPU 202 to enable the number of execution cores to execute the translated code 201.

Runtime environment 227 can create multiple operating system (OS) runtime threads, which can be controlled by environment variables. Basically, the number of cores in the system can be used as the number of OS runtime threads. In step 410, a value of the number of CUDA threads to be launched can be obtained and statistically partitioned by the number of runtime threads. Each runtime thread executes some of the compiled code sequentially and waits on the barrier. When all runtime threads reach the barrier, the CTA completes. In step 415 the runtime environment 227 or device driver 203 launches the compiled code for execution by the CPU 202.

Translator 220, compiler 225, and runtime environment 227 are used to convert CUDA application programs into code for execution by a general purpose CPU. The CUDA programming model supports bulk synchronous task parallelism, where each task consists of fine-grained SPMD threads. The use of the CUDA programming model has been limited to programmers who wish to write specialized code for execution by GPUs. This specialized code can be switched for execution by a general purpose CPU without the programmer having to rewrite the CUDA application program. The three key concepts supported by CUDA are SPMD thread blocks, barrier synchronization and shared memory. Translator 220 performs optimization transformations for serializing operations into a single CPU thread and transforming a CUDA application program across the grainy threads of the CUDA thread block.

While the above is directed to embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. For example, aspects of the invention may be implemented in hardware or software or a combination of hardware and software. One embodiment of the invention may be implemented as a program product for use with a computer system. The program (s) of the program product define the functions of the embodiments (including the methods described herein) and may be included on various computer-readable storage media. Exemplary computer-readable storage media include (i) non-writable storage media (e.g., CD-ROM disks, flash memory readable by a CD-ROM drive) in which information is stored permanently. Read-only memory devices in a computer, such as ROM chips or any type of solid-state non-volatile semiconductor memory); And (ii) a recordable storage medium (eg, floppy disks in a diskette drive or hard disk drive or any type of solid state random access semiconductor memory) in which modifiable information is stored. . Such computer-readable storage media are embodiments of the invention when performing computer-readable instructions that direct the functions of the invention. Thus, the scope of the invention is determined by the following claims.

1 is a block diagram illustrating a computer system.

2 is a block diagram illustrating a computer system according to one embodiment of the invention.

3A is a flow diagram of method steps for translating code written for execution by a multicore graphics processing unit into code for execution by a general purpose processor, in accordance with an embodiment of the present invention.

3B is a conceptual diagram illustrating an input code translated into a partitioned code, in accordance with an embodiment of the present invention.

3C is a conceptual diagram illustrating input codes that are translated into optimized codes, in accordance with one embodiment of the present invention.

4 is a flow diagram of method steps for executing code translated by a general purpose processor, in accordance with an embodiment of the present invention.

<Description of the symbols for the main parts of the drawings>

100: computer system

101: code

102: CPU

103: device drivers

104: system memory

Claims (10)

A computing system configured to execute a translated application program, the computing system comprising: A general purpose processor configured to execute a compiler; A system memory coupled with the processor and configured to store the translated application program and compiled code; Compiler-The compiler receives the translated application program transformed from an application program recorded using a parallel programming model for execution on a multicore graphics processing unit, and compiles the translated application program to generate the general purpose. Generate compiled code for execution by a processor; Device driver-the device driver is configured to determine the number of execution cores of the general purpose processor available for executing the translated application program, and to enable the number of execution cores. Configured to configure a general purpose processor; And A runtime environment configured to launch the compiled code for execution by the general purpose processor, including the number of execution cores Computing system comprising a. The method of claim 1, The translated application program includes a first loop nest around a first area of a partitioned application program such that any thread of a thread of a cooperating thread array is in a second area of the partitioned application program. Computing system to ensure that all threads of the cooperative thread array complete execution of the first region of the partitioned application program before starting execution. The method of claim 2, And the first loop is repeated on one or more dimensions of the cooperative thread array. The method of claim 1, The translated application program is generated by partitioning the application program into regions of synchronization independent instructions to generate a partitioned application program, and inserting a loop around at least one region of the partitioned application program, And said loop is repeated on a cooperative thread array dimension corresponding to a number of threads executed simultaneously by parallel processors within said multicore graphics processing unit. The method of claim 4, wherein And a first region of the partitioned application program includes instructions before a synchronization barrier instruction, and a second region of the partitioned application program includes instructions after the synchronization barrier instruction. The method of claim 5, And additional loops are inserted around at least one area of the partitioned application program to generate the translated application program, the additional loops being repeated on different cooperative thread array dimensions. The method of claim 4, wherein And said partitioned application program is classified to identify each statement as one of converging or diverging with respect to said cooperative thread array dimension. The method of claim 1, The general purpose processor is further configured to execute the compiled code. The method of claim 1, The general purpose processor is further configured to perform optimizations specific to the general purpose processor. The method of claim 1, And said application program written using a parallel programming model for execution on a multicore graphics processing unit is a Compute Unified Device Architecture (CUDA) application program.

Images