Abstract: Circuits, methods, and apparatus that provide parallel execution relationships to be included in a function call or other appropriate portion of a command or instruction in a sequential programming language. One example provides a token-based method of expressing parallel execution relationships. Each process that can be executed in parallel is given a separate token. Later processes that depend on earlier processes wait to receive the appropriate token before being executed. In another example, counters are used in place to tokens to determine when a process is completed. Each function is a number of individual functions or threads, where each thread performs the same operation on a different piece of data. A counter is used to track the number of threads that have been executed. When each thread in the function has been executed, a later function that relies on data generated by the earlier function may be executed.

Abstract: Circuits, methods, and apparatus that provide parallel execution relationships to be included in a function call or other appropriate portion of a command or instruction in a sequential programming language. One example provides a token-based method of expressing parallel execution relationships. Each process that can be executed in parallel is given a separate token. Later processes that depend on earlier processes wait to receive the appropriate token before being executed. In another example, counters are used in place to tokens to determine when a process is completed. Each function is a number of individual functions or threads, where each thread performs the same operation on a different piece of data. A counter is used to track the number of threads that have been executed. When each thread in the function has been executed, a later function that relies on data generated by the earlier function may be executed.

Abstract: One embodiment of the present invention sets forth a method for sharing graphics objects between a compute unified device architecture (CUDA) application programming interface (API) and a graphics API. The CUDA API includes calls used to alias graphics objects allocated by the graphics API and, subsequently, synchronize accesses to the graphics objects. When an application program emits a “register” call that targets a particular graphics object, the CUDA API ensures that the graphics object is in the device memory, and maps the graphics object into the CUDA address space. Subsequently, when the application program emits “map” and “unmap” calls, the CUDA API respectively enables and disables accesses to the graphics object through the CUDA API. Further, the CUDA API uses semaphores to synchronize accesses to the shared graphics object. Finally, when the application program emits an “unregister” call, the CUDA API configures the computing system to disregard interoperability constraints.

Abstract: One embodiment of the present invention sets forth a method for sharing graphics objects between a compute unified device architecture (CUDA) application programming interface (API) and a graphics API. The CUDA API includes calls used to alias graphics objects allocated by the graphics API and, subsequently, synchronize accesses to the graphics objects. When an application program emits a “register” call that targets a particular graphics object, the CUDA API ensures that the graphics object is in the device memory, and maps the graphics object into the CUDA address space. Subsequently, when the application program emits “map” and “unmap” calls, the CUDA API respectively enables and disables accesses to the graphics object through the CUDA API. Further, the CUDA API uses semaphores to synchronize accesses to the shared graphics object. Finally, when the application program emits an “unregister” call, the CUDA API configures the computing system to disregard interoperability constraints.

Abstract: One embodiment of the present invention sets forth a technique for representing and managing a multi-architecture co-processor application program. Source code for co-processor functions is compiled in two stages. The first stage incorporates a majority of the computationally intensive processing steps associated with co-processor code compilation. The first stage generates virtual assembly code from the source code. The second stage generates co-processor machine code from the virtual assembly. Both the virtual assembly and co-processor machine code may be included within the co-processor enabled application program. A co-processor driver uses a description of the currently available co-processor to select between virtual assembly and co-processor machine code. If the virtual assembly code is selected, then the co-processor driver compiles the virtual assembly into machine code for the current co-processor.

Abstract: A virtual architecture and instruction set support explicit parallel-thread computing. The virtual architecture defines a virtual processor that supports concurrent execution of multiple virtual threads with multiple levels of data sharing and coordination (e.g., synchronization) between different virtual threads, as well as a virtual execution driver that controls the virtual processor. A virtual instruction set architecture for the virtual processor is used to define behavior of a virtual thread and includes instructions related to parallel thread behavior, e.g., data sharing and synchronization. Using the virtual platform, programmers can develop application programs in which virtual threads execute concurrently to process data; virtual translators and drivers adapt the application code to particular hardware on which it is to execute, transparently to the programmer.

Abstract: One embodiment of the present invention sets forth a technique for representing and managing a multi-architecture co-processor application program. Source code for co-processor functions is compiled in two stages. The first stage incorporates a majority of the computationally intensive processing steps associated with co-processor code compilation. The first stage generates virtual assembly code from the source code. The second stage generates co-processor machine code from the virtual assembly. Both the virtual assembly and co-processor machine code may be included within the co-processor enabled application program. A co-processor driver uses a description of the currently available co-processor to select between virtual assembly and co-processor machine code. If the virtual assembly code is selected, then the co-processor driver compiles the virtual assembly into machine code for the current co-processor.

Abstract: One embodiment of the present invention sets forth a technique for representing and managing a multi-architecture co-processor application program. Source code for co-processor functions is compiled in two stages. The first stage incorporates a majority of the computationally intensive processing steps associated with co-processor code compilation. The first stage generates virtual assembly code from the source code. The second stage generates co-processor machine code from the virtual assembly. Both the virtual assembly and co-processor machine code may be included within the co-processor enabled application program. A co-processor driver uses a description of the currently available co-processor to select between virtual assembly and co-processor machine code. If the virtual assembly code is selected, then the co-processor driver compiles the virtual assembly into machine code for the current co-processor.

Abstract: One embodiment of the present invention sets forth a technique for unifying the addressing of multiple distinct parallel memory spaces into a single address space for a thread. A unified memory space address is converted into an address that accesses one of the parallel memory spaces for that thread. A single type of load or store instruction may be used that specifies the unified memory space address for a thread instead of using a different type of load or store instruction to access each of the distinct parallel memory spaces.

Abstract: A system, method, and computer program product are provided for compiling code adapted to execute utilizing a first processor, for executing the code utilizing a second processor. In operation, code adapted to execute utilizing a first processor is identified. Additionally, the code is compiled for executing the code utilizing a second processor that is different from the first processor and includes a central processing unit. Further, the code is executed utilizing the second processor.

Abstract: One embodiment of the present invention sets forth a technique for unifying the addressing of multiple distinct parallel memory spaces into a single address space for a thread. A unified memory space address is converted into an address that accesses one of the parallel memory spaces for that thread. A single type of load or store instruction may be used that specifies the unified memory space address for a thread instead of using a different type of load or store instruction to access each of the distinct parallel memory spaces.

Abstract: One embodiment of an instruction decoder includes an instruction parser configured to process a first non-operative instruction and to generate a first event signal corresponding to the first non-operative instruction, and a first event multiplexer configured to receive the first event signal from the instruction parser, to select the first event signal from one or more event signals and to transmit the first event signal to an event logic block. The instruction decoder may be implemented in a multithreaded processing unit, such as a shader unit, and the occurrences of the first event signal may be tracked when one or more threads are executed within the processing unit. The resulting event signal count may provide a designer with a better understanding of the behavior of a program, such as a shader program, executed within the processing unit, thereby facilitating overall processing unit and program design.

Abstract: Methods, apparatuses, and systems are presented for updating data in memory while executing multiple threads of instructions, involving receiving a single instruction from one of a plurality of concurrently executing threads of instructions, in response to the single instruction received, reading data from a specific memory location, performing an operation involving the data read from the memory location to generate a result, and storing the result to the specific memory location, without requiring separate load and store instructions, and in response to the single instruction received, precluding another one of the plurality of threads of instructions from altering data at the specific memory location while reading of the data from the specific memory location, performing the operation involving the data, and storing the result to the specific memory location.

Abstract: A virtual architecture and instruction set support explicit parallel-thread computing. The virtual architecture defines a virtual processor that supports concurrent execution of multiple virtual threads with multiple levels of data sharing and coordination (e.g., synchronization) between different virtual threads, as well as a virtual execution driver that controls the virtual processor. A virtual instruction set architecture for the virtual processor is used to define behavior of a virtual thread and includes instructions related to parallel thread behavior, e.g., data sharing and synchronization. Using the virtual platform, programmers can develop application programs in which virtual threads execute concurrently to process data; virtual translators and drivers adapt the application code to particular hardware on which it is to execute, transparently to the programmer.