TW201342228A - Compute thread array granularity execution preemption - Google Patents

Abstract

One embodiment of the present invention sets forth a technique instruction level and compute thread array granularity execution preemption. Preempting at the instruction level does not require any draining of the processing pipeline. No new instructions are issued and the context state is unloaded from the processing pipeline. When preemption is performed at a compute thread array boundary, the amount of context state to be stored is reduced because execution units within the processing pipeline complete execution of in-flight instructions and become idle. If, the amount of time needed to complete execution of the in-flight instructions exceeds a threshold, then the preemption may dynamically change to be performed at the instruction level instead of at compute thread array granularity.

Description

Privilege array granulation execution priority calculation

The present invention is generally directed to program execution priorities, and more particularly to priority calculations for thread array granulation execution.

Priority is a mechanism for time division of a processor between multiple different applications. When there are multiple different applications that need to use the processor at the same time, one way to achieve advancement for all of these applications is to run each application for a short time slice on the processor. In the past, time division required that the processor pipeline be completely eliminated, and when the processor is idle, a different application is switched in to be executed by the processor pipeline. This time splitting mechanism has been referred to as "wait for idle" priority, and when the processor takes a long time to eliminate the work being performed on the processor pipeline, That is, it does not work well. For example, consider a graphics shader program that takes a very long time to operate, or in the worst case, a shader program with an infinite loop. In order to be able to time split between different applications, the length of time required for idle execution of each application must be limited, so long-running applications cannot effectively reduce the time slice available for other applications. .

Another mechanism that has been considered to implement priority is to stop or freeze the processor, then store all of the contents of the registers and pipeline flip-flops in the processor, and restore the processor later. The contents of all such registers and pipeline flip-flops. Storing and restoring all of these registers and pipeline flip-flops essentially results in a very large number of states being stored and restored. The time to store and restore this state reduces the time available to each of the applications during the time slices.

Therefore, there is a need in the art for a system and method for performing priority that does not require the storage of an application's entire state when the application is preempted. State, there is no need to wait for a processing pipeline to become idle to prioritize the application.

The present invention is a system and method for computing thread array granulation execution priorities. When the priority is initiated, the content status is unloaded from the processing pipeline. When the priority is executed at a computational thread array boundary, the amount of content state to be stored can be reduced because the execution unit within the processing pipeline completes the execution of the in-progress instruction and becomes idle. If the length of time required to complete the execution of the in-progress instructions exceeds a threshold, then the priority can be dynamically changed to the level of the instruction rather than the computational thread array granulation.

Various embodiments of the method of prioritizing the execution of program instructions in a multi-threaded system of the present invention include executing program instructions for using a first content in a processing pipeline within the multi-threaded system. Execution of the first content is performed at a compute thread array level to execute different program instructions that use a second content in the multi-threaded system. Execution of the execution of the program instructions using the first content is stored, and the different program instructions are executed using the second content in the processing pipeline.

Various embodiments of the present invention include a multi-threaded system for prioritizing the execution of program instructions. The multi-thread system includes a memory, a master interface, and a processing pipeline. The memory is configured to store program instructions corresponding to a first content and different program instructions corresponding to a second content. The master interface is coupled to the processing pipeline and is configured to perform execution of a program instruction using the first content at a compute thread array level to execute a different program instruction using a second content. The processing pipeline is configured to execute the program instructions using the first content, prioritize execution of the program instructions using the first content, execute the different program instructions using the second content, and store the first use The execution of the program instructions of the content is preceded by an instruction and execution of the different program instructions that use the second content.

This priority mechanism minimizes the number of states to be restored when an application is preempted and when the application resumes execution. In addition, long-running applications can be taken up in a very short time.

In the following description, numerous specific details are set forth to provide a more complete understanding of the invention. However, it will be understood by those 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 are not described in order to avoid obscuring the invention.

System Overview

The first figure illustrates a block diagram of a computer system 100 that is configured to implement one or more aspects of the present invention. Computer system 100 includes a central processing unit (CPU) 102 and a system memory 104 that communicate via an interconnect path including a memory bridge 105. The memory bridge 105 can be a north bridge wafer that is connected to an I/O (input/output) bridge 107 via a bus or other communication path 106 (e.g., a HyperTransport link). The I/O bridge 107 can be a south bridge chip that receives user input from one or more user input devices 108 (eg, a keyboard, mouse) and forwards the input via path 106 and memory bridge 105 to CPU 102. A parallel processing subsystem 112 is coupled to the memory bridge 105 via a bus or other communication path 113 (e.g., PCI Express, accelerated graphics, or HyperTransport coupling); in one embodiment, the parallel processing subsystem 112 is a A graphics subsystem that passes pixels to a display 110 (eg, a conventional CRT or LCD type monitor). A system disk 114 is also coupled to the I/O bridge 107. A switch 116 provides a connection between the I/O bridge 107 and other components such as the network adapter 118 and various embedded cards 120, 121. Other components (not explicitly shown), including USB or other port connections, CD drives, DVD drives, thin film recording devices, and the like, may also be coupled to I/O bridge 107. Interconnecting the communication paths of the various components in the first figure can be implemented using any suitable protocol, such as PCI (Peripheral Component Interconnect, Peripheral) Component Interconnect), PCI Express (PCI Express, PCI-E), AGP (Accelerated Graphics Port), HyperTransport, or any other bus or point-to-point protocol, and connections between different devices Different protocols as known in the art can be used.

In one embodiment, parallel processing subsystem 112 incorporates circuitry that can be optimized for graphics and video processing, including, for example, video output circuitry, and constitutes a graphics processing unit (GPU). In another embodiment, the parallel processing subsystem 112 incorporates circuitry that can be optimized for general purpose processing while retaining the underlying computing architecture, as will be described in more detail herein. In yet another embodiment, the parallel processing subsystem 112 can be integrated into one or more other system components, such as the memory bridge 105, the CPU 102, and the I/O bridge 107 to form a system-on-chip ( SoC, "System on chip").

It will be appreciated that the systems shown herein are merely illustrative and that many variations and modifications are possible. The connection topology, including the number and configuration of bridges, the number of CPUs 102, and the number of parallel processing subsystems 112 can all be modified as needed. For example, in some embodiments, system memory 104 is directly coupled to CPU 102 rather than through a bridge, while other devices communicate with system memory 104 via memory bridge 105 and CPU 102. In other alternative topologies, parallel processing subsystem 112 is coupled to I/O bridge 107 or directly to CPU 102, rather than to memory bridge 105. In still other embodiments, I/O bridge 107 and memory bridge 105 can be integrated into a single wafer. Large specific embodiments may include two or more CPUs 102, and two or more parallel processing subsystems 112. The particular components shown herein are all optional; for example, they can support any number of embedded cards or peripheral devices. In some embodiments, switch 116 is omitted and network adapter 118 and embedded cards 120, 121 are directly connected to I/O bridge 107.

The second figure illustrates a parallel processing subsystem 112 in accordance with one embodiment of the present invention. As shown, parallel processing subsystem 112 includes one or more parallel processing orders Elements (PPUs, "Parallel processing units") 202, each coupled to a partial parallel processing (PP, "Parallel processing") memory 204. In summary, a parallel processing subsystem includes a number U of PPUs, where U ≧ 1. (Several instances of the analog component are labeled here to identify the reference number of the object, and the number in parentheses identifies the desired instance). The PPU 202 and the parallel processing memory 204 can be implemented using one or more integrated circuit devices, such as a programmable processor, an application specific integrated circuit (ASIC), or a memory device. Or in any other technically feasible way.

Referring again to the first figure, in some embodiments, some or all of the PPUs 202 in the parallel processing subsystem 112 are graphics processors having a visualization pipeline that can be configured to execute with respect to the self-CPU 102 and/or system. The memory 104 generates a plurality of operations of the pixel data via the graphic data supplied from the memory bridge 105 and the bus bar 113, and interacts with the local parallel processing memory 204 (which can be used as a graphic memory, which includes, for example, a conventional image frame buffer. To store and update pixel data, pass pixel data to display device 110 and the like. In some embodiments, parallel processing subsystem 112 can include one or more PPUs 202 that are operable as graphics processors, and one or more other PPUs 202 for general purpose operations. The PPUs may be the same or different, and each PPU may have its own proprietary parallel processing memory device or no proprietary parallel processing memory device. One or more PPUs 202 may output data to display device 110, or each PPU 202 may output data to one or more display devices 110.

In operation, CPU 102 is the master processor of computer system 100 that controls and coordinates the operation of other system components. In particular, the CPU 102 issues commands to control the operation of the PPU 202. In some embodiments, CPU 102 writes a command stream to each PPU 202 to a data structure (not explicitly shown in the first or second figure), which may be located in system memory 104, parallel processing memory. Body 204 may be other storage locations that are simultaneously accessible by CPU 102 and PPU 202. An indicator directed to each data structure is written to a push-in buffer to initiate processing of the command stream in the data structure. PPU 202 reads from one or more push buffers The stream is streamed, and then the command is executed asynchronously with respect to the job of the CPU 102. Execution priority can be specified for each push-in buffer to control the scheduling of the different push-in buffers.

Referring now back to FIG. 2B, each PPU 202 includes an I/O (input/output) unit 205 that communicates with other portions of computer system 100 via communication path 113, which is coupled to memory bridge 105. (Or directly connected to the CPU 102 in an alternative embodiment). The connection of the PPU 202 to the rest of the computer system 100 can also vary. In some embodiments, parallel processing subsystem 112 is implemented as an embedded card that can be inserted into an expansion slot of computer system 100. In other embodiments, PPU 202 can be integrated on a single wafer, such as memory bridge 105 or I/O bridge 107, using a bus bridge. In still other embodiments, some or all of the components of PPU 202 may be integrated with CPU 102 on a single wafer.

In one embodiment, communication path 113 is a PCI-EXPRESS link in which a dedicated line is known to be assigned to each PPU 202 as is known in the art. It can also use other communication paths. An I/O unit 205 generates a packet (or other signal) for transmission over the communication path 113 and also receives all incoming packets (or other signals) from the communication path 113, directing the incoming packets to the appropriate components of the PPU 202. For example, commands regarding processing operations can be directed to a host interface 206, and commands for memory jobs (eg, read or written from parallel processing memory 204) can be directed to a memory crossbar switch. Unit 210. The master interface 206 reads each push-in buffer and outputs the command stream stored in the push-in buffer to a front end 212.

Each PPU 202 is preferably implemented as a highly parallel processing architecture. As shown in detail, PPU 202(0) includes a processing cluster array 230 that includes a number C of general processing clusters (GPC) 208, where C ≧ 1. Each GPC 208 can execute a large number (e.g., hundreds or thousands) of threads simultaneously, each of which is an instance of a program. In a variety of applications, different GPCs 208 can be assigned to handle different kinds of programs, or perform different types. The operation. The allocation of GPC 208 can vary depending on the workload of each program or operation.

The GPC 208 receives processing tasks to be performed by a work distribution unit within a task/work unit 207. The work distribution unit receives the metrics to compute processing tasks that are encoded into task mediation data (TMD) and stored in memory. The metrics directed to the TMD are included in the command stream stored as a push-in buffer and received by the front end unit 212 autonomous interface 206. A processing task that can be encoded into a TMD includes an index of the material to be processed, and state parameters and commands that define how the material is to be processed (eg, which program is to be executed). Task/work unit 207 receives tasks from front end 212 and ensures that GPC 208 is set to an active state prior to the start of the process specified by each of the TMDs. A priority may be specified for each TMD used to schedule the execution of the processing task.

The memory interface 214 includes a number D of partitioning units 215, each of which is directly coupled to a portion of the parallel processing memory 204, where D≧1. As shown, the number of compartments 215 is substantially equal to the number of DRAMs 220. In other embodiments, the number of compartments 215 may not be equal to the number of memory devices. Those skilled in the art will appreciate that DRAM 220 can be replaced by other suitable storage devices and can be designed for general use. Therefore, the detailed description can be omitted. Development targets, such as frame buffers or texture maps, which may be stored in different DRAMs 220, allow the partition unit 215 to write different portions of each development target in parallel to efficiently use parallel processing memory. 204 can use the bandwidth.

Any of the GPCs 208 can process data to be written to any of the DRAMs 220 in the parallel processing memory 204. The crossbar unit 210 is arranged to direct the output of each GPC 208 to the input of any of the segmentation units 215 or to another GPC 208 for further processing. The GPC 208 communicates with the memory interface 214 via the crossbar unit 210 to read or write from a plurality of external memory devices. In a specific embodiment, the crossbar unit 210 has a memory interface A connection of 214 communicates with I/O unit 205 and a connection to local parallel processing memory 204, thereby enabling the processing cores in different GPCs 208 to be associated with system memory 104 or not local to PPU 202. Other memory communicates. In the particular embodiment shown in the second figure, the crossbar unit 210 is directly coupled to the I/O unit 205. The crossbar unit 210 can use a virtual channel to separate the flow of traffic between the GPC 208 and the segmentation unit 215.

Again, GPC 208 can be programmed to perform processing on a wide variety of applications, including but not limited to linear and non-linear data conversion, filtering of film and/or sound data, modeling operations (eg, applying physical laws to determine Object position, velocity, and other properties), image development jobs (such as mosaic shaders, vertex shaders, geometry shaders, and/or pixel shader programs). The PPU 202 can transfer data from the system memory 104 and/or the partially parallel processing memory 204 to internal (on-wafer) memory, process the data, and write the resulting data back to the system memory 104 and/or locally parallel. Memory 204 is processed where the data is accessed by other system components, including CPU 102 or another parallel processing subsystem 112.

A PPU 202 can have any number of locally parallel processing memories 204, does not include local memory, and can use local memory and system memory in any combination. For example, a PPU 202 can be a graphics processor in a unified memory architecture (UMA, "Unified Memory Architecture") embodiment. In these specific embodiments, a few or no proprietary graphics (parallel processing) memory will be provided, and the PPU 202 will use system memory exclusively or substantially exclusively. In a UMA embodiment, a PPU 202 can be integrated into a bridge die or processor chip, or provided as a separate wafer having a high speed link (eg, PCI-EXPRESS) via a bridge A wafer or other means of communication connects the PPU 202 to the system memory.

As noted above, any number of PPUs 202 can be included in a parallel processing subsystem 112. For example, multiple PPUs 202 may be provided on a single embedded card, or multiple embedded cards may be connected to communication path 113, or one or more PPUs 202 Can be integrated into a bridge wafer. The PPUs 202 may be identical to each other or different from one another in a multi-PPU system. For example, different PPUs 202 can have different numbers of processing cores, different numbers of locally parallel processing memories, and the like. When there are multiple PPUs 202, those PPUs can operate in parallel to process data at a higher traffic than is possible with a single PPU 202. Systems incorporating one or more PPUs 202 can be implemented in a variety of configurations and style factors, including desktop, laptop, or palm-sized personal computers, servers, workstations, game consoles, embedded systems, and the like.

Multiple parallel task scheduling

Multiple processing tasks can be executed in parallel on GPC 208, and a processing task can generate one or more "child" processing tasks during execution. Task/work unit 207 receives the tasks and dynamically schedules the processing tasks and sub-processing tasks for execution by GPC 208.

The third A is a block diagram of the task/work unit 207 of the second diagram in accordance with an embodiment of the present invention. The task/work unit 207 includes a task management unit 300 and a work distribution unit 340. The task management unit 300 organizes tasks to be scheduled based on the degree of execution priority. For each level of priority, the task management unit 300 stores a list of links to metrics corresponding to the TMDs 333 of the tasks in the scheduler table 321 . The TMD 322 can be stored in the PP memory 204 or the system memory 104. The task management unit 300 accepts the tasks and stores the rates of the tasks in the scheduler table 321 out of the rate at which the task management unit 300 schedules tasks to perform, such that the task management unit 300 can be based on prioritization information or using other techniques. Scheduled tasks.

The work distribution unit 340 includes a task table 345, which has locations, and each location can be occupied by a TMD 322 of a task to be executed. The task management unit 300 can execute the scheduled task when there is an empty position in the task table 345. When there is no empty location, a higher priority task that does not occupy a location can evict a lower priority task that occupies a vacancy. When a task is evicted, the task is stopped, and if the execution of the task is not completed, the task is added to A list of links in the scheduler table 321 . When a sub-processing task is generated, the sub-processing task is added to a link string in the scheduler table 321. When the task is evicted, a task is removed from a location.

Task processing overview

FIG. 3B is a block diagram of a GPC 208 within one of the PPUs 202 of the second diagram in accordance with an embodiment of the present invention. Each GPC 208 can be arranged to execute a large number of threads in parallel, wherein the term "thread" refers to an instance of a particular program that is executed for a particular combination of input material. In some embodiments, a single instruction, multiple data (SIMD, "Single-instruction, multiple-data") instruction issuance technique is used to support parallel execution of a large number of threads without the need to provide multiple independent instruction units. In other embodiments, SIMT ("Single-instruction" (multiple-thread)" technology is used to support parallel execution of a large number of roughly synchronized threads, which are set to issue instructions using a common instruction unit. A set of processing engines into each of GPUs 208. Unlike a SIMD execution mode in which all processing engines basically execute the same instructions, SIMT's execution allows different threads to follow the different execution paths more immediately via a given thread. Those skilled in the art will appreciate that a SIMD processing specification represents a functional subset of a SIMT processing specification.

The operation of GPC 208 is preferably controlled via a pipeline administrator 305, which can assign processing tasks to a Streaming Multiprocessor (SM) 310. The pipeline manager 305 can also be arranged to control a work distribution crossbar 330 by specifying the destination of the processed data output of the SM 310.

In one embodiment, each GPC 208 includes M number of SMs 310, where M ≧ 1, each SMU 310 is configured to process one or more thread groups. At the same time, each SM 310 is preferably a functional unit that includes an identical combination that can be pipelined, allowing a new instruction to be issued before a previous instruction has been completed, as is known in the art. It can provide any combination of functional units. In a In a specific embodiment, the functional units support a variety of operations, including integer and floating point arithmetic (eg, addition and multiplication), comparison operations, Boolean operations (AND, OR, XOR), bit offsets, and multiple algebras. Functions of functions (such as plane interpolation, trigonometric functions, exponents, and logarithmic functions, etc.); and the same functional unit hardware can be utilized to perform different operations.

The series of instructions transmitted to a particular GPC 208 constitute a thread that, as previously defined herein, executes a certain number of threads in parallel across the parallel processing engine (not shown) within an SM 310. The collection is referred to herein as "warp" or "thread group". As used herein, a "thread group" represents a group of threads executing the same program in parallel for different input materials, each thread of the group being assigned to a different processing engine within an SM 310. . A thread group may include fewer threads than the number of processing engines within the SM 310, where some processing engines will be idle while the thread group is being processed. A thread group can also include more threads than the number of processing engines in the SM 310, where processing will occur over successive clock cycles. Because each SM 310 can support up to G thread groups in parallel, up to G*M thread groups can be executed in GPC 208 at any given time.

In addition, complex related thread groups (at different stages of execution) can be initiated within an SM 310 at the same time. The collection of this thread group is referred to herein as a "Cooperative thread array" (CTA, "thread array") or "thread array". The size of a particular CTA is equal to m*k, where k is the number of threads executing in parallel in a thread group, which is essentially an integer multiple of the number of parallel processing engines in SM 310, and m is at SM 310 The number of thread groups that are simultaneously started within. The size of a CTA is roughly determined by the number of hardware resources (such as memory or scratchpads) that the programmer and the CTA can use.

Each SM 310 includes a first order (L1) cache or a space for performing load and store operations in a corresponding L1 cache external to the SM 310. Each SM The 310 also has access to a second-order (L2) cache shared between all GPCs 208 and can be used to transfer data between threads. Finally, the SM 310 can also access "universal" memory external to the wafer, which can include, for example, parallel processing memory 204 and/or system memory 104. It should be understood that any memory external to the PPU 202 can be used as a general purpose memory. In addition, a 1.5th order (L1.5) cache 335 can be included within the GPC 208, configured to receive and maintain data extracted from the memory via the memory interface 214, including instructions, consistency data, and Constant data and provide the required information to SM 310. A particular embodiment having multiple SMs 310 in GPC 208 is preferably to share common instructions and data that are cached in L1.5 cache 335.

Each GPC 208 can include a Memory Management Unit (MMU) 328 that is configured to map virtual addresses to physical locations. In other embodiments, MMU 328 may be present within memory interface 214. The MMU 328 includes a set of page table entries (PTE, "Page table entries") for mapping a virtual location to a physical address of a tile, or a cache line index. MMU 328 may include a Translating Lookaside Buffer (TLB), or a cache that may exist within multiprocessor SM 310 or L1 cache or GPC 208. The physical address is processed to allocate surface data access locality to allow for efficient requirements interleaved in the segmentation unit. The cache line index can be used to determine whether a request for a cache line is fulfilled or missed.

In graphics and computing applications, a GPC 208 can be configured such that each SM 310 is coupled to a texture unit 315 for performing a texture mapping operation, such as determining a texture sample position, reading texture data, and filtering the texture data. The texture data is read from an internal texture L1 cache (not shown) or, in some embodiments, from the L1 cache in SM 310, and processed from a L2 cache, parallel processing memory 204 as needed. Or system memory 104 is extracted. Each SM 310 outputs the processed task to the work distribution crossbar 330 to provide the processed task to another GPC 208 for further processing, or to store the processed task via the crossbar unit 310 in an L2 fast. Take or parallelize memory 204 or system memory In body 104. A preROP (pre-scan fielding job) 325 is arranged to receive data from the SM 310, direct the data to the ROP unit in the compartment unit 215, optimize color mixing, organize pixel color data, and perform address translation. .

It will be appreciated that the core architecture shown herein is merely illustrative and that there are many variations and modifications possible. Any number of processing units, such as SM 310 or routing unit 315, preROP 325, may be included within a GPC 208. Moreover, although only one GPC 208 is shown, a PPU 202 can include any number of GPCs 208 that are preferably functionally similar to each other, so the execution behavior does not depend on which GPC 208 receives a particular processing task. Decide. Moreover, each GPC 208 preferably operates independently of other GPCs 208, using separate and distinct processing units, L1 caches, and the like.

It will be appreciated by those skilled in the art that the architecture described in the first, second, third and third B diagrams does not limit the scope of the invention in any way, and the techniques taught herein can be implemented in any suitable setting. Processing unit, including but not limited to one or more CPUs, one or more multi-core CPUs, one or more PPUs 202, one or more GPCs 208, one or more graphics or special purpose processing units or the like They do not depart from the scope of the invention.

In a particular embodiment of the invention, the PPU 202 or other processor of an arithmetic system is required to perform general operations using a thread array. Each thread in the thread array is assigned a unique thread ID that can be accessed by the thread during execution of the thread. The thread ID, which can be defined as a one-dimensional or multi-dimensional value, controls various aspects of the processing behavior of the thread. For example, a thread ID can be used to determine which portion of the input data set to be processed by a thread, and/or to determine which thread to generate or write in an output data set. Share.

A sequence of each thread instruction can include at least one instruction to define a cooperative behavior between the representative thread and one or more other threads of the thread array. For example, the sequence of instructions for each thread may include an instruction to suspend execution of the representative thread at a particular point in the sequence. In a row, until one or more of the other threads arrive at the particular point, an instruction of the representative thread stores a shared memory that the data is accessible to one or more of the other threads. An instruction of the representative thread is based on their thread ID to atomically read and update data stored in a shared memory accessible by one or more of the other threads, or the like. By. The CTA program may also include an instruction to calculate an address of the data to be read in the shared memory, using the address as a function of the thread ID. By defining appropriate functions and providing synchronization techniques, data can be written to a given location in shared memory by a thread of a CTA, and by a different prediction of the same CTA in a predictable manner. The thread reads from this location. Therefore, it is possible to support sharing any required data patterns in the thread, and any thread in a CTA can share data with any other thread in the same CTA. If so, the degree of data sharing in a CTA's thread is determined by the CTA program; therefore, it should be understood that in a particular application using CTA, according to the CTA program, a CTA's threads can Or do not need to actually share material with each other, the terms "CTA" and "thread array" are used synonymously herein.

Program execution and priority

Priority can be used to time divide a processor between multiple different applications, so the different applications are serialized and each executes a short time slice on the processor. Priority can also be used to offload the content currently being executed for other purposes. For example, the master interface 206 can prioritize a content when the CPU 102 initiates a channel preemption or a run list preemption, wherein one channel is a set of indicators pointing to processing work, and an application can include one or more Channels. A channel preemption is performed by clearing a valid bit in a random access memory item and writing to a preemptive register of one of the channels to be preempted. The designated channel is then unloaded from the PPU 202 while leaving the host and the engine.

A run list is preempted by writing an indicator to the run list register. This metric can point to a new run list or can point to the run list currently enabled. The run list preempts the unloading that is operating in a PPU 202. The master interface 206 then begins processing the first item on the run list associated with the indicator and searches for the first valid item with the pending job. The first channel is loaded into the PPU 202 on the run list with the pending work.

The master interface 206 can also prioritize a content being executed before a time slice expires when the content is exhausted (ie, the program) and another content is waiting to be executed. In a specific embodiment, the time slices are not equal in length, but are based on a method stream of each content, so a content having a dense method stream is different from a stream having a loose method stream. The content was assigned a larger time slice. The master interface 206 is arranged to indicate to the front end 212 when the master interface 206 does not have any method for an ongoing content. However, the master interface 206 does not initiate a content switch for the content being executed until the time slice assigned to the content has expired or the processing pipeline is idle and there is no method.

The fourth diagram is the processing pipeline of the master interface 206 and the task/work unit 207 through the GPC 208 in accordance with an embodiment of the present invention. The priority procedure has five phases controlled by the front end 212. A first phase (Phase 1) stops the processing in the current content. For the priority of the CTA level, this represents stopping work at the boundary of a CTA task. For instruction level priority, this represents stopping work at the boundary of an SM 310 instruction. If an interrupt or error occurs after the start priority and during phase 1, the front end 212 waits for the pending interrupt or the error is cleared before proceeding to stage 2.

Once the content is stopped (and any interruptions or errors are cleared), Phase 2 stores the state of the current content in memory. Phase 3 resets the engine before loading the state of a new content on stage 4 to the machine. Phase 5 resumes the processing of any work that was preempted in the previous Phase 1. When prioritizing a content, the main The control interface 206 selects a new content from the run list to execute, and instructs the front end 212 to begin content priority. The front end 212 sets the processing pipeline to perform the new content by completing the five stages of the priority procedure. After the five phases of the priority procedure are completed, the front end 212 transmits an acknowledgment (ACK) to the master interface 206. In one embodiment, a separate graphics processing pipeline (not shown in the fourth diagram) performs graphics-specific operations, and the front end 212 also waits for the graphics processing pipeline to become idle. Basically, the graphics processing methods are executed in a shorter time than the arithmetic processing methods, so waiting for the graphics processing pipeline to become idle can be completed when the processing pipeline completes the first phase of the priority procedure. At the same time, the amount of status information maintained in a graphics processing pipeline is substantially greater than the amount of state that is maintained in the (processing) processing pipeline. Waiting for the graphics processing pipeline to become idle can significantly reduce the amount of storage required to capture the state of the content.

Prior to prioritization, a content buffer that stores the CTA level (and instruction level) content state for a particular content is allocated by a program executing on CPU 102. The size of the content buffer that is allocated may be based on the number of PPU 202 configurations and the number of SMs 310.

To complete this first phase of the priority procedure, the front end 212 stops the master interface 206 from accepting the new method and outputs a preemptive command to the task/work unit 207. When the preemptive command is received by a processing unit, the processing unit stops outputting the operation to a downstream unit. The front end 212 waits for all downstream units to stop the output operation and then determines a content freeze signal to become the second stage of the priority procedure. The determination of the content freeze signal ensures that the processing pipeline does not perform any jobs based on the transactions for storing the content status. The front end 212 also determines whether a pending idle command being processed requires the front end 212 to wait for the processing pipeline to become idle. If so, the front end 212 interrupts the waiting for idle operation and stores content status information to indicate that a wait idle command is being directed to the content. In execution. When the content is restored, the wait for idle execution will be restarted by the front end 212.

When the task/work unit 207 receives the preemption command, the task/work unit 207 stops starting a new job. Finally, task/work unit 207 determines that the first two phases of the priority procedure have been completed and notifies front end 212 that the processing pipeline is idle. The front end 212 will then store the content state maintained within the task/work unit 207 prior to resetting the processing pipeline to complete the third phase of the priority procedure. When the instruction level priority is used, the content status maintained within GPC 208 is stored by GPC 208 itself. When the CTA level priority is used, GPU 208 is excluded, so the number of stored content states can be reduced.

Even after the task/work unit 207 stops starting work, the task/work unit 207 can receive additional work that may be generated by the GPC 208 during execution of the previous instruction. The task/work unit 207 buffers the additional work to be stored by the front end 212 as part of the content state of the task/work unit 207.

When the preemption command is received, the work distribution unit 340 stops starting the CTA. When the CTA level priority is made, the processing units, such as GPC 208, are excluded from the processing pipeline downstream of the work distribution unit 340, so no content status remains in those downstream processing units. Therefore, the number of content states can be reduced when the CTA level priority is made compared to the instruction level priority, which is because the instruction level priority does not need to exclude the downstream processing units.

The work distribution unit 340 determines which one of the GPCs 208 is about to perform the received work based on the information generated by the task management unit 300. Because GPC 208 is pipelined, a single GPC 208 can perform multiple tasks in parallel. The task management unit 300 schedules each processing task to be executed as a grid or queue. Work assignment unit 340 associates each CTA with a particular grid or queue for parallel execution of one or more tasks. CTAs belonging to a grid have implicit x, y, z parameters to indicate the location of individual CTAs within the grid. Work distribution unit 340 tracks the GPCs 208 that are available and initiates the CTAs when GPC 208 is available.

During the instruction level priority, the work distribution unit 340 transmits the preemption command to the pipeline manager 305 in the GPC 208. Pipeline manager 305 can include each A controller of the SM 310. Upon receipt of the preemptive command, the SM 310 stops issuing instructions and enters a capture processor. SM 310 also waits for all memory transactions associated with previously issued instructions to complete, ie, for all pending memory requests. A memory request is considered pending when a read request has not been returned and when a write request explicitly requested for an acknowledgment has not been received from the MMU 328. The pipeline manager 305 maintains information about the CTA and the thread group and tracks which CTAs are preempted by those thread groups.

Once the SM 310 in the GPC 208 has stopped issuing instructions and each SM 310 becomes idle, the capture processor unloads the content state of the CTAs operating on the GPC 208, and one or more of the capture processes A combination of the pipeline manager 305 and the front end 312 stores the content status. The status of the content that is unloaded and stored includes a scratchpad in the SM 310, a scratchpad in the pipeline manager 305, a scratchpad in the GPC 208, a shared memory, etc., all of which are stored in the graphics memory. A pre-defined buffer in . At the same time, those caches written by the cache (eg, L1.5 cache 335) within the GPC 208 are forced to leave the memory and the caches are disabled. Once all of the content status has been unloaded and stored, the capture processor will leave all initiated threads, thereby vacating SM 310 and GPC 208.

The capture processor then controls a signal from the SM 310 to the pipeline manager 305 to indicate that the first two phases of the priority procedure have been completed by the GPC 208 and that the GPC 208 is idle. The pipeline manager 305 reports to the work distribution unit 340, acknowledging (ACK) the preemption command to indicate that the first two phases of the priority procedure have been completed. This ACK is transmitted upstream of the work distribution unit 340 to the task management unit 300, and finally to the front end 212.

The pipeline manager 305 maintains status information for each thread group being executed within the GPC 208 when the preemption command is output by the work distribution unit 340. The status information indicates whether a thread group has left after completion of execution, or whether the thread group is preempted. This status information is stored by the pipeline manager 305 and can be used by the pipeline manager 305 to restore only those that are preempted. Group. When all of the threads in a thread group are removed after the pipeline administrator 305 receives the preemption command and before the trapping processor is entered to store the status information, the status information is not directed to the thread. The group is saved and the thread group is not restored. After the GPCs 208 are idle, the GPCs can be reset to complete the third phase of the priority procedure.

The front end 212 then completes the second phase of the priority procedure by writing the content state maintained by the front end 212. The front end 212 stores all of the scratchpads, and the random memory string is chained out to the internal state buffer of the preempted content. To complete this third phase of the priority procedure, the front end 212 determines a content reset signal, such as task/work unit 207 and GPC 208, received by the processing pipeline.

When a content is selected for execution, the master interface 206 needs to determine if the selected content is a previously pre-empted content. A content reload (ctx_reload) flag indicating whether a content is preempted is maintained by the master interface 206. When the master interface 206 determines that the selected content is preempted, the previously unloaded and stored content state is reloaded prior to execution recovery of the selected content. A content that has been preempted will be reloaded even when there is no way for the selected content, because there may be work generated by the SM 310 during execution of the methods and stored in the content state. a part.

When the master interface 206 initiates the priority, the front end 212 sends a message to the master interface 206 whether the content is idle. If the content is idle, that is, the processing pipeline is idle and has no pending memory requirements, the preempted content does not need to be reloaded before the execution of the content is restored. If the content is not idle, the master interface 206 stores the content reload status to be processed when the channel is reloaded.

There are also cases where the processing pipeline is already idle when the current terminal 212 master interface 206 receives the preemption command. When the processing pipeline is already idle, the front end 212 does not transmit a preemptive command to the task/work unit 207, but continues the second phase of the priority procedure. Therefore, the idle state of task/work unit 207 and GPC 208 must cause those units to receive a new content state or restore Repeat the content status. For example, task/work unit 207 must be in a state such that no tasks are running. The pipeline manager 305 must only recover the preempted thread group or CTA and must not resume the leaving thread group.

When the front end 212 completes the fourth phase of the priority program, the selected content state is read by a content buffer and loaded into the scratchpad and random processing memory chain. The content freeze signal is acknowledged by the front end 212 from the beginning of the second phase until the end of the fourth phase of the priority procedure. The determination of the content freeze signal ensures that the processing pipeline does not perform any jobs to store and restore the content state based on the transactions used by the front end 212.

The front end 212 initiates the fifth phase (stage 5) of the priority program by outputting a preemptive resume command to the task/work unit 207. After the task/work unit 207 receives the preemptive resume command, the task/work unit 207 does not determine a ready signal to the front end 212, so no new work can be transferred from the front end 212 to the task/work unit 207 until the priority The program is completed. The work distribution unit 340 in the task/work unit 207 receives the preemptive life, respectively, and restores the selected content state, replays the resumed tasks into the GPC 208, and restores the preempted CTA and the thread group. The group is returned to the pipeline manager 305 and the SM 310.

For example, a pipeline manager 305 outputs the preemptive resume command to set up another SM 310 to enter the "priority-recovery-start" mode. The pipeline manager 305 then transmits the preemptive CTAs and thread groups to the SM 310. After the pipeline manager 305 has restored all of the preempted thread groups, the pipeline manager 305 outputs a command to the SM 310 to indicate that the "priority-recovery-start" mode must be left. When using this CTA level priority, GPC 308 does not have any stored content status to reload, and does not have any thread group status to recover.

When the instruction level priority is used to recover a selected content, the GPC 308 reads the content status of the selected content from a content buffer and loads The registers and shared memory. The pipeline manager 305 restarts all of the preempted CTAs by transmitting the CTAs to the individual SMs 310 on which each CTA is executing in the order in which the CTAs are reported to be preempted. This technique ensures that each CTA is initiated in an SM 310 at the same physical CTA location occupied by the CTA when the content is preempted. The thread group is started with the same entity thread group ID. The benefit of restarting the thread group at the same location after the priority is because the thread group and CTA can guarantee that the memory and other resources available in the individual SM 310 will not be exceeded. Each SM 310 restores a scratchpad value, a program number, a stacking indicator, a valid mask for each thread group and the like.

Finally, the front end 212 acknowledges (ACK) the original preemption command to the master interface 206. The ACK indicates that the priority procedure has been completed and execution of the selected content has begun. Any previously preempted CTA has resumed execution in task/work unit 207 and GPC 208. When the instruction level priority is used, any previously preempted threads have resumed execution on the SM 310. The master interface 206 now begins to transfer new work to the graphics pipeline.

In a specific embodiment, the front end 212 acknowledges (ACK) the original preemption command after outputting the preemptive resume command to the task/work unit 207, and the task/work unit 207 buffers any new received after the preemptive resume command. Work until the completion of stage 5. Task/work unit 207 does not initiate any new (unrecovered) CTA until the priority procedure is completed. Therefore, the front end 212 does not know when to complete the fifth stage. If task/work unit 207 is unable to buffer all new work, task/work unit 207 negates the ready signal to front end 212. However, the front end 212 cannot distinguish that the ready signal is negated during or after the priority procedure.

Figure 5A illustrates an unloading method 500 for offloading a content state when a program is preempted in accordance with an embodiment of the present invention. Although the method steps are described in conjunction with the systems of the first, second, third, third, and fourth figures, Those skilled in the art will appreciate that any system configured to perform the method steps in any order is within the scope of the present invention.

At step 505, the master interface 206 outputs an instruction level preemption command to the front end 212 and initiates the offloading of the current content. At step 510, the front end 212 determines if the processing pipeline is idle, and if so, the front end 212 proceeds directly to step 545 to store the content state maintained by the front end 212.

If the front end 212 determines at step 510 that the processing pipeline is not idle, then at step 515 the front end 212 stops starting a new job for the current content. At step 520, the front end 212 outputs a preemptive command to the task/work unit 207. At step 525, task management unit 300 within task/work unit 207 stops issuing tasks to work distribution unit 340 and outputs the preemption command to work distribution unit 340. At step 525, the work distribution unit 340 also stops starting the CTA and outputs the preemption command to the pipeline manager 305. The pipeline manager 305 outputs the command level preemption command to the SM 310.

At step 525, SM 310 stops executing the instruction, and at step 530 SM 310 waits for any pending memory transactions to complete. Step 530 is repeated for each SM 310 until all of the memory transactions are completed. SM 310 indicates to pipeline manager 305 whether each thread group is left or preempted. When all of the pending memory transactions are completed, in step 535, the content state maintained in SM 310 is stored in a content buffer, and the content state maintained in pipeline manager 305 is also stored to The content buffer.

At step 540, the pipeline manager 305 reports to the work distribution unit 340 that the instruction level portion of the processing pipeline (e.g., SM 310 and GPC 208) is idle, and then the work distribution unit 340 is maintained in the work distribution unit for the current content store. The CTA level state in 340. The work distribution unit 340 reports to the task management unit 300 that it has completed the priority of this phase. The task management unit 30 then stores the task hierarchy state maintained in the task management unit 300. The task management unit 300 reports back to the front end 212 when the current state has been stored, and at step 545 the front end 212 stores the content maintained by the front end 212 for the current content. Status to the content buffer. At step 550, the front end 212 stores the stored content status for one of the preempted content indications and resets the processing pipeline.

FIG. 5B illustrates a recovery method 560 for restoring a state of content when a program preempted at the instruction level is restored in accordance with an embodiment of the present invention. Although the method steps are described in conjunction with the systems of the first, second, third, third, and fourth figures, those skilled in the art will appreciate that any system configured to perform the method steps in any order is Within the scope of the invention.

At step 565, the front end 212 initiates recovery of the stored content for one of the content selected by the host interface 206. At step 570, the front end 212 determines the content freeze signal to ensure that the processing pipeline does not perform any jobs based on the transactions used by the front end 212 to restore the content state. At step 575, the selected content state is read from a content buffer by the front end 212 and the task/work unit 207 and restored at the task and CTA level.

At step 580, each pipeline manager 305 outputs a command to set the individual SM 310 to enter the "preemptive-recover-start" mode, thereby setting the SM 310 to a suspend state. At step 580, the pipeline manager 305 transmits the preempted CTA and thread group to the SM 310, and the GPC 208 recovers the command layer maintained in the SM 310 for the selected content stored at step 535 and Content status (see Figure 5A). After recovering the CTA and instruction level status, the pipeline manager 305 outputs a command to the individual SM 310 to indicate that the "preemption-recover-start" mode must be left, and the front end 212 denies the content freeze signal at step 582. Steps 580 and 528 can be performed simultaneously. At step 585, the CTAs are initiated in the preempted order, and at step 590, the resumed content state of the selected content is used to resume execution. At step 590, the front end 212 also acknowledges (ACK) the signal to the master interface 206 that the instruction level preemption command has completed execution. The master interface 206 can now begin to transfer more work to the front end 212 by the push-in buffer. In a specific embodiment, task/work unit 207 determines and denies the content freeze, and is determined in the content freeze in step 570. Step 590 is then performed (by front end 212). The task/work unit buffers the new work from the push-in buffer until the instruction level preemption command has completed execution. This new work is not output by the task/work unit until the CTAs are initiated at step 585.

As previously mentioned, the state of the content being stored and restored may be reduced at the expense of potentially longer latency for preempting at the CTA level rather than preempting the in-run content at the instruction level. When a content is preempted at the CTA level, SM 310 completes execution of any enabled CTA, so the CTA state that needs to be stored is not maintained within pipeline manager 305 and GPC 208. However, the task level state required to initiate at least one additional CTA to perform the execution of the task is stored for the preempted content.

In a specific embodiment, the content is preempted at the task level, and the task/work unit 207 performs any execution of the task with at least one CTA initiated, so the task status does not need to be stored. Preemption at the task level may require initiation of one or more additional CTAs to complete execution of the task before the front end state is stored. When the task level is preempted, no state is stored for the task or CTA.

Figure 6A illustrates an unloading method 600 for offloading a content state when a program is preempted at a CTA level in accordance with an embodiment of the present invention. Although the method steps are described in conjunction with the systems of the first, second, third, third, and fourth figures, those skilled in the art will appreciate that any system configured to perform the method steps in any order is Within the scope of the invention.

At step 605, the master interface 206 outputs a CTA level preemption command to the front end 212 and initiates the offloading of the current content. At step 610, the front end 212 determines if the processing pipeline is idle, and if so, the front end 212 proceeds directly to step 645 to store the content state maintained by the front end 212.

If the front end 212 determines at step 610 that the processing pipeline is not idle, then at step 615 the front end 212 stops starting a new job for the current content. At step 620, front end 212 outputs a preemptive command to task/work unit 207. In the steps 625. The task management unit 300 in the task/work unit 207 stops issuing the task to the work distribution unit 340, and outputs the preemption command to the work distribution unit 340. The work distribution unit 340 stops starting the CTA, and at step 630, the work distribution unit 340 or the like with the GPC 208 becomes idle.

If the work distribution unit 340 determines at step 630 that the GPC 208 is not idle, then at step 635 the work distribution unit 340 determines if a timer has expired. The timer limits the number of clock cycles that the work distribution unit 340 will wait for the GPCs to become idle. The number of such clock cycles may be a stylized value, and in a particular embodiment, when the value is exceeded, the work distribution unit 340 performs priority at the instruction level rather than at the CTA level. If the work distribution unit 340 determines in step 635 that the timer has not expired, the work distribution unit 340 returns to step 630. Otherwise, when the timer has expired, the work distribution unit 340 proceeds to step 520 of the fifth A diagram to perform the priority at the instruction level.

When the GPCs are idle at step 630, the work distribution unit 340 stores the CTA level status maintained in the work distribution unit 340 for the current content at step 640. The work distribution unit 340 reports back to the task management member 300 that the current state has been stored. The task management unit 300 then stores the task hierarchy state maintained in the task management unit 300. The task management unit 300 reports back to the front end 212 when the current state has been stored, and at step 645 the front end 212 stores the content state maintained by the front end 212 for the current content to the content buffer. At step 650, the front end 212 stores the stored content status for one of the preempted content indications and resets the processing pipeline.

Figure 6B illustrates a recovery method 660 for restoring content status when a program preempted at the CTA level is restored in accordance with an embodiment of the present invention. Although the method steps are described in conjunction with the systems of the first, second, third, third, and fourth figures, those skilled in the art will appreciate that any system configured to perform the method steps in any order is Within the scope of the invention.

At step 665, the front end 212 initiates recovery of a content that was previously preempted at the CTA level. At step 670, the front end 212 determines the content freeze signal to confirm The processing pipeline is based on the transactions used by the front end 212 and does not perform any jobs to restore the content state. At step 675, the selected content state is read from a content buffer by the front end 212 and the task/work unit 207 and restored at the task and CTA level. At step 682, the content freeze signal is de-asserted.

At step 685, the CTAs that were preempted when this content was last run are restarted by the task/work unit 207 into the GPC 208. At step 690, the front end 212 acknowledges (ACK) the signal that the master interface 206 has completed the execution of the CTA level preemption command. The master interface 206 can now begin to transfer more work to the front end 212 by the push-in buffer. In a specific embodiment, task/work unit 207 determines and denies the content freeze, and proceeds to step 690 (by front end 212) after the content freeze is determined in step 670. The task/work unit buffers the new work from the push-in buffer until the instruction level preemption command has completed execution. This new work is not output by the task/work unit until the CTAs are restarted in step 685.

The ability to preempt a content at the instruction level or at the CTA level can be specified for each particular content. A long run time of content can be preempted at the instruction level to avoid a long delay between when the preemption is initiated and when the preemption is completed. A content that does not require long runtime but maintains a large number of states can be preempted at the CTA level to minimize the amount of stored state of the content.

An embodiment of the invention can be implemented as a program product for use by a computer system. The program of the program product defines the functions of the specific embodiments (including the methods described herein) and can be included on a variety of computer readable storage media. Exemplary computer readable storage media include, but are not limited to: (i) non-writable storage media (eg, a read-only memory device in a computer, such as a CD-ROM disc that can be read by a CD-ROM, flashing Memory, ROM chip, or any other kind of solid non-volatile semiconductor memory) on which information can be stored permanently; and (ii) writeable to a storage medium (such as a floppy disk in a disk drive) A slice, or a hard disk drive, or any kind of solid state random access semiconductor memory, on which information that can be changed can be stored.

The invention has been described above with reference to specific embodiments. It will be apparent to those skilled in the art that various modifications and changes can be made without departing from the spirit and scope of the invention. Accordingly, the foregoing description and drawings are to be regarded as illustrative

100‧‧‧ computer system

102‧‧‧Central Processing Unit

103‧‧‧Device Driver

104‧‧‧System Memory

105‧‧‧Memory Bridge

106‧‧‧Communication path

107‧‧‧Input/Output Bridge

108‧‧‧ Input device

110‧‧‧ display

112‧‧‧Graphic Processing Unit

113‧‧‧Communication path

114‧‧‧System Disc

116‧‧‧Switch

118‧‧‧Network Adapter

120,121‧‧‧ embedded card

202‧‧‧Parallel processing unit

204‧‧‧Parallel processing of memory

205‧‧‧Input/output unit

206‧‧‧Master interface

207‧‧‧Tasks/Working Units

208‧‧‧General Processing Cluster

210‧‧‧cross switch unit

212‧‧‧ front end

214‧‧‧ memory interface

215‧‧‧ segment unit

220‧‧‧Dynamic random access memory

230‧‧‧Process cluster array

300‧‧‧Task Management Unit

305‧‧‧Pipeline Administrator

310‧‧‧Streaming multiprocessor

315‧‧‧Line unit

321‧‧‧ Scheduler

322‧‧‧Mission agency information

325‧‧‧Pre-scanning field operations

328‧‧‧Memory Management Unit

330‧‧‧Work distribution crossbar

335‧‧‧L1.5 cache

340‧‧‧Works allocation unit

345‧‧‧Task Schedule

Therefore, a more detailed description of one of the embodiments of the present invention can be understood by reference to the specific embodiments, which are illustrated in the accompanying drawings. It is to be noted, however, that the appended drawings are merely illustrative of exemplary embodiments of the invention, and are not intended to limit the scope of the invention.

The first diagram illustrates a block diagram of a computer system configured to implement one or more aspects of the present invention; and the second diagram is a block diagram of a parallel processing subsystem of the computer system in accordance with the first embodiment of the present invention. 3 is a block diagram of a task/work unit according to a second diagram of an embodiment of the present invention; and FIG. 3B is a diagram of the parallel processing unit of the second diagram according to an embodiment of the present invention; A block diagram of a general processing cluster within one; a fourth block diagram of the processing pipeline in accordance with an embodiment of the present invention; and a fifth diagram illustrating an application when a program is preempted in accordance with an embodiment of the present invention An unloading method for uninstalling a content state; FIG. 5B illustrates a recovery method for restoring a content state when a preempted program is restored according to an embodiment of the present invention; FIG. 6A illustrates a specific method according to the present invention Another method of uninstalling the state of the content when a program is preempted in an embodiment; Figure 6B illustrates another recovery method for restoring the state of a content when a preempted program is restored, in accordance with an embodiment of the present invention.

Claims (10)

A method for prioritizing execution of a program instruction in a multi-threaded system, the method comprising: executing a program instruction using a first content in a processing pipeline within the multi-thread system; using the first content, The instruction level is preferentially executed to execute a different program instruction in the multi-thread system using a second content; storing an indication that the first content is executed using the first content; and in the processing pipeline Using the second content to execute the different program instructions. The method of claim 1, further comprising storing a portion of the first content state maintained in the processing pipeline during execution of the program instructions using the first content prior to executing the different program instructions Share. The method of claim 1, wherein using the first content priority execution further comprises storing each thread group storage being performed in a streaming multiprocessor when preemptively occurring at the instruction level The first content state. The method of claim 1, wherein the preempting of the execution of the first content further comprises determining that the streaming multiprocessor configured to execute the program instructions using the first content is idle. The method of claim 1, further comprising: determining that the processing pipeline is idle before executing the different program instructions; and resetting the processing pipeline without maintaining the processing of the first content in the processing pipeline The status of the content. A method for prioritizing execution of program instructions in a multi-threaded system, the method comprising: performing a first internal use in a processing pipeline within the multi-threaded system a program instruction; prioritizing execution of the first content at a computing thread array level to execute different program instructions using a second content in the multi-thread system; storing the first content using the first content The execution of the program instructions is preceded by an indication; and the different program instructions that use the second content are executed in the processing pipeline. The method of claim 6, further comprising performing execution of all of the computational thread arrays that have been initiated in the processing pipeline prior to executing the different program instructions, and storing is maintained to initiate an additional A thread content array is calculated and a first content state of execution of the program instructions that use the first content is completed. The method of claim 6, wherein the performing the preemption of the first content further comprises: performing execution of all computing thread arrays that have been initiated to execute in the processing pipeline; initiating at least one additional Executing a thread array to perform execution of the program instructions using the first content; and performing the execution of the additional computing thread array by the processing pipeline. The method of claim 6, wherein the preempting of the execution of the first content further comprises determining that the streaming multiprocessor configured to execute the program instructions using the first content is idle. The method of claim 6, further comprising: determining that the processing pipeline is idle before executing the different program instructions; and resetting the processing pipeline without being maintained in the processing pipeline for the first content storage The status of the content.