Patent Application
20090276563
The disclosure is generally related to computer architecture. In particular it is related to systems and methods for efficiently managing incremental state updates.
A graphics processing unit (GPU) is a processor chip that is dedicated to performing the calculations necessary to render graphics objects on a computer display. The GPU may be a dedicated device, several devices or integrated into a larger device (e.g., a north bridge device or a CPU). A common workflow inside a GPU involves updating the values of constants in a memory array and then performing a draw operation using the constants as data. A GPU whose memory array contains a given set of constants may be considered to be in a particular “state”.
In graphics processing chips it is common to set up the state of the chip, perform a draw operation, and then make only a small number of changes to the state before the next draw operation. Most of the state settings, e.g. values of constants in memory, remain the same from one draw operation to the next.
In a typical GPU there is long latency in the graphics pipeline. A draw operation must wait many processor clock cycles for data to be fetched from memory. It is inefficient to leave the processor idle during this time. A better use of processor resources is to have several draw operations in process at the same time, each operating on its own state setting. Potentially dozens, or even hundreds, of draw operations, each needing its own state setting, might be running in a GPU at any given time.
One way to enable simultaneous processing of multiple draw operations is to provide multiple copies of all state registers. That way each draw operation can operate on its own copy of the chip state without waiting for earlier operations to finish. This solution is expensive in terms of chip real estate, however. The die size increases quickly as more and more copies of the memory are required. Updating the data within all the copies is also time consuming.
What are needed are systems and methods for efficiently managing incremental state updates in a processor.
The drawings are heuristic for clarity.
A system and method for efficiently managing incremental state updates in a processor are described herein. The description is cast in terms applicable to a graphics processor; however, it will become clear that the system and method are applicable to any processor in which multiple threads require access to sets of state information which differ from one another by only a relatively small number of state changes.
In graphics processors the set of data required by one draw operation is often not very different from that required by the next draw operation. For example, often only a few constants in RAM are updated between draw operations. The system and method described herein take advantage of this property to create an efficient system for managing these incremental updates such that multiple operations can be processed at once.
In typical operation the CPU, running a driver program, writes commands into a memory buffer and these commands are executed by the command processor. The command processor initiates a draw operation by sending a set of updates to constants to the CFILE and sending a draw command to the programmable shader processor. The shader processor creates threads and executes a drawing program. (The shader processor is but one example of a programmable processor. Any programmable processor running threads that access constants in the CFILE may benefit from the systems and methods described herein.)
The threads created by the shader processor operate with constant data stored in the CFILE. When a thread needs data it sends a request for that data to the CFILE; the CFILE supplies the necessary data to the thread. The CFILE can accommodate data requests from more than one thread at a time. If too many threads request data from the CFILE and the CFILE cannot accommodate the requests, it sends a stall signal to the command processor. Finally when threads finish, the shader processor sends a thread done signal and the identification of the last thread in a batch to both the CFILE and the command processor.
The CFILE is the unit within the GPU that manages incremental state updates in such a way that multiple threads within the GPU can each operate, in effect, on their own set of state data.
In
The shift register holds updates to the constants stored in the RAM. Each address in the RAM holds a constant, for example a 128 bit number. Each address in the shift register holds a constant plus an address of a memory location in the RAM and a time stamp as called out in item 360. In the exemplary embodiment, larger values of a time stamp denote a later-in-time update. As an example, in
Consider now an example of CFILE operation. Suppose at time 0 the command processor issues an update/draw command; i.e. the command processor sends updates to constants to the CFILE and a draw command to the shader processor. Suppose further that one of the constants updated is the one corresponding to address 147 of RAM and that the shader processor initiates several threads to execute the draw operation. Each of the threads carries time stamp 0.
Instead of writing the updated constant value to address 147 of RAM, the CFILE writes the value to the shift register along with the address (147) and time stamp (0) information. As other update/draw commands are issued by the command processor, updated constants are written to the shift register with their corresponding RAM addresses and time stamps. Newer updates push older updates toward higher addresses in the shift register. The oldest updates drain into the RAM.
Now suppose that one of the threads from the time 0 draw operation needs to access the value of the constant stored in RAM address 147. The thread first checks the shift register to see if there are any updates corresponding to the address (147) it needs. If there are not any updates with the corresponding address, the thread uses the value stored in the RAM at the desired address. If, however, there are updates in the shift register with the corresponding address, then the thread uses the one of those updates that has the most recent time stamp that is not later than the thread's time stamp.
In
In this way, the shift register provides threads with the state of the GPU (i.e. constants stored in the RAM) that existed at the time the threads were created. Threads access constants stored in RAM if those constants have not been updated since the thread was created. The shift register provides updated constants to threads based on the time stamps of the threads and the constants.
The shift register cannot accumulate updates indefinitely as it only contains a finite number of addresses. In
Now suppose that at a later time, e.g. time 1, a second update/draw operation sends to the CFILE updates to 64 constants. In response, the CFILE writes the 64 constants left in the shift register from the previous operation to RAM and stores the 64 new constant updates in the shift register, each with its corresponding RAM address and time stamp 1. The shader processor starts several new threads, each with time stamp 1.
The CFILE is now full. No new updates can be accommodated. The CFILE sends a stall signal to the command processor as shown in
Next,
Next,
Next,
Next,
The CFILE is now ready for more updates, including for example, the 8 updates which had to wait in
To reiterate, the batch of updates pointed to by the oldest pointer is permitted to overwrite constants in RAM as no thread ever needs older constants. The total number of new updates is equal to the sum of the number of updates in the batches from one newer than the oldest, through the newest.
A stall condition is created whenever the number of new updates reaches the number of addresses in the shift register. A stall condition is also created when the number of batches of updates reaches the number of memory addresses in the time stamp manager. If the time stamp manager has 32 memory addresses, it can only keep track of 32 batches of updates. Although this example used a time stamp manager having 32 memory addresses, a recent implementation used a time stamp manager having 64 memory addresses. The number of memory addresses used is a matter of engineering convenience.
In the description above, threads and updates are tagged by time stamp. However, the value of a time stamp in system clock units may be a relatively large number. In some implementations it may be simpler to keep track of the ages of threads and updates. Age is calculated as the difference between the system clock at the time the thread or update was created and the current system clock. Age is often a smaller number than time stamp and therefore may be an easier quantity to manipulate. The operation of the systems and methods described herein is not significantly changed by the choice of age or time stamp.
In the description above, the shift register is positioned before the RAM; i.e. updates are first written to the shift register and then drained to the RAM. However, the system and method described herein could just as easily be implemented with the most recently updated version of the state stored in the RAM and progressively older updates stored in the shift register (or other overflow buffer).
Furthermore, the shift register (or other overflow buffer, FIFO, etc) could also be implemented as sets of age pointers. The system could be maintained with pointers and never move data around in RAM at all, but simply update pointers (age, address pairs) to locate the proper data. In this implementation the overflow buffer is virtualized in pointers.
Aspects of the invention described above may be implemented as functionality programmed into any of a variety of circuitry, including but not limited to electrically programmable logic and memory devices as well as application specific integrated circuits (ASICs) and fully custom integrated circuits. Some other possibilities for implementing aspects of the invention include: microcontrollers with memory (such as electronically erasable programmable read only memory (EEPROM)), embedded microprocessors, firmware, software, etc. The software could be hardware description language (HDL) such as Verilog and the like, that when processed is used to manufacture a processor capable of performing the above described functionality. Furthermore, aspects of the invention may be embodied in microprocessors having software-based circuit emulation, discrete logic (sequential and combinatorial), custom devices, and hybrids of any of the above device types. Of course the underlying device technologies may be provided in a variety of component types, e.g., metal-oxide semiconductor field-effect transistor (MOSFET) technologies like complementary metal-oxide semiconductor (CMOS), bipolar technologies like emitter-coupled logic (ECL), polymer technologies (e.g., silicon-conjugated polymer and metal-conjugated polymer-metal structures), mixed analog and digital, etc.
As one skilled in the art will readily appreciate from the disclosure of the embodiments herein, processes, machines, manufacture, means, methods, or steps, presently existing or later to be developed that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized according to the present invention. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, means, methods, or steps.
The above description of illustrated embodiments of the systems and methods is not intended to be exhaustive or to limit the systems and methods to the precise form disclosed. While specific embodiments of, and examples for, the systems and methods are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the systems and methods, as those skilled in the relevant art will recognize. The teachings of the systems and methods provided herein can be applied to other systems and methods, not only for the systems and methods described above.
In general, in the following claims, the terms used should not be construed to limit the systems and methods to the specific embodiments disclosed in the specification and the claims, but should be construed to include all systems that operate under the claims. Accordingly, the systems and methods are not limited by the disclosure, but instead the scope of the systems and methods are to be determined entirely by the claims.
