Abstract:
A system has a graphics processing unit with a processor to monitor selected criteria and circuitry to initiate the storage of execution state information when the selected criteria reaches a specified state. A memory stores execution state information. A central processing unit executes a debugging program to analyze the execution state information.

Description:
BRIEF DESCRIPTION OF THE INVENTION 
   This invention relates generally to graphics processing. More particularly, this invention relates to a technique for capturing execution state of a program executing on a graphics processing unit to facilitate debugging operations. 
   BACKGROUND OF THE INVENTION 
   Currently there are very few tools available to software developers that provide visibility into the state of a graphics processing unit (GPU) or the state of a program executing on a GPU. Thus, it is difficult for software developers to identify the origin of problems that may be associated with programs that they are developing. For example, many GPUs have several shader processors that execute many instances of graphics shader programs, with initial shaders being used to position a triangle and a subsequent shader used to apply color. To understand a problem associated with a program running on a GPU it may be necessary to understand the state of each shader program instance on a step-by-step basis. Developers generally do not have access to the GPU processor or program state information required for this type of analysis. 
   Capturing state information associated with the operation of a central processing unit (CPU) is known. For example, in the case of an error in the CPU, it is known to capture all state information of the CPU at the time of the error. The state information may include register values, pointers, program counters, condition codes and the like. Various debugging tools may then be used to analyze the state information. 
   It would be desirable to be able to capture state information associated with the operation of a GPU. Ideally, this would be accomplished without dedicated circuitry required to capture the state information. In other words, it would be desirable to capture GPU state information using existing circuitry associated with the GPU. If such state information was made available to a developer, standard debugging tools could be used to analyze the state information and thereby provide developers with a new technique to improve their applications. 
   SUMMARY OF THE INVENTION 
   The invention includes a system with a graphics processing unit with a processor to monitor selected criteria and circuitry to initiate the storage of execution state information when the selected criteria reaches a specified state. A memory stores execution state information. A central processing unit executes a debugging program to analyze the execution state information. 
   The invention also includes a graphics processing unit with a processor to monitor selected criteria. A host interface coordinates the storage of execution state information in response to the selected criteria being satisfied. 
   The invention includes a method of operating a graphics processing unit in which graphics processing unit performance is monitored in accordance with selected criteria. Graphics processing unit execution state information is saved in response to satisfaction of the selected criteria. The graphics processing unit execution state information is then debugged. 

   
     BRIEF DESCRIPTION OF THE FIGURES 
     The invention is more fully appreciated in connection with the following detailed description taken in conjunction with the accompanying drawings, in which: 
       FIG. 1  illustrates a system configured in accordance with an embodiment of the invention. 
       FIG. 2  illustrates a GPU configured in accordance with an embodiment of the invention. 
       FIG. 3  is a more detailed view of a processing cluster of a GPU configured in accordance with an embodiment of the invention. 
       FIG. 4  illustrates processing operations associated with an embodiment of the invention. 
       FIG. 5  illustrates processing operations associated with an alternate embodiment of the invention. 
   

   Like reference numerals refer to corresponding parts throughout the several views of the drawings. 
   DETAILED DESCRIPTION OF THE INVENTION 
     FIG. 1  illustrates a system  100  configured in accordance with an embodiment of the invention. The system  100  includes a CPU  102  connected to a bridge  104  (e.g., a standard north bridge known in the art). A GPU  106  is also connected to the bridge  104 . The system  100  is configured to support the operations of the invention. In particular, the GPU  106  is configured to support debug operations in response to a debug instruction. The debug instruction may be a trap instruction, which utilizes existing GPU page fault mechanisms to initiate the saving of state information. Subsequently, the GPU operates with the CPU to save state information. Alternately, the debug instruction may be a breakpoint instruction added to an instruction set. The GPU processes the breakpoint instruction and operates with the CPU to save state information. In some embodiments, the GPU may have a single-instruction step mode, wherein the GPU acts as if a debug instruction followed each actual instruction. Debugging operations are performed on saved state information, regardless of the technique used to secure the state information. 
   When the GPU executes a debug instruction such as a trap instruction or breakpoint instruction, it causes a debugging event signal, which in some embodiments is a trap signal. The debugging event signal may be caused by an explicit debug instruction or it may be generated in response to the monitoring of specified criteria, such as a performance value, an error value or a register comparison value. In one embodiment of the invention, the trap instruction utilizes existing GPU page fault mechanisms to initiate the saving of state information. As known in the art, page faults occur in processors and CPUs in response to instruction accesses (e.g., load/store/branch/call) to virtual addresses that are not mapped to a physical address or are invalid. On a processor or CPU, a page fault invokes a page fault handler that establishes a virtual to physical mapping and resumes execution of the faulting instruction or signals an error if the address is invalid. If servicing the page fault will take a long time, the processor or CPU may switch contexts to another process or thread. The context switch results in state information being stored until the state information is needed in response to a subsequent context switch. Context switching may be time-expensive. In one embodiment of the invention, the GPU has a memory management unit that generates GPU page faults which are serviced by the CPU, and a debugging event signal invokes GPU page faults at a specific invalid address which informs the CPU to then perform GPU debugging operations. In one embodiment, the CPU causes a GPU context switch that saves debug state information in a memory. For example, the state information  118  may be captured in the frame buffer  120 , system memory  110  or memory  109  resident on the GPU  106 . 
   The memory  110  of  FIG. 1  stores an operating system (OS)  112 . As known in the art, operating systems control the virtual memory space associated with a computer. The virtual memory space includes valid page references and invalid page references. Reference to an invalid page results in a page fault. 
   The memory  110  also stores a debug driver  114 . The debug driver  114  includes executable instructions to specify the address of an invalid page reference that will create a page fault, and route this invalid address to the GPU  106  so that it may be stored as a trap address  108 . When the CPU  102  subsequently sees a request for the specified invalid page reference, it initiates debugging operations rather than service it as a normal page fault. In particular, the CPU  102  recognizes that a call to the invalid page reference is in response to a request for debugging operations and therefore the CPU  102  initiates a context switch. The context switch results in the saving of state information. Thereafter, the debugger  116  may analyze the state information. 
   The debugger  116  includes executable instructions to analyze state information. Standard techniques may be used to analyze the state information. However, in this implementation, the standard techniques are applied to GPU state information, not CPU state information.  FIG. 1  illustrates the state information  118  stored in memory  110  so that it may be operated on by the debugger  116 . The state information  118  may be routed from the frame buffer  120  using standard techniques. Alternately, the state information  118  may be directly routed from the memory  109  of GPU  106  to the memory  110 . 
     FIG. 1  also illustrates that a bus  130  (e.g., a PCI bus) is connected to the bridge  104 . A south bridge  132  may also be connected to the bus  130 . An additional bus  134  (e.g., an ISA bus) may be connected to the south bridge  132 . These components are shown for the purpose of demonstrating that the invention may be incorporated into a general computing platform. 
     FIG. 2  is a more detailed illustration of a GPU  106  implemented in accordance with an embodiment of the invention. In this embodiment, the GPU  106  includes a set of processing clusters  200 _A through  200 _N (also referred to as processors). To simplify the illustration, only processing cluster  200 _A is shown in detail. Each processing cluster  200  includes a processing controller  202  (or processor controller). The processing controller  202  includes a trap address register  204  to store the previously discussed trap address. 
   The processing controller  202  is in communication with a set of processors  206 _A through  206 _N. In one embodiment, each processor  206  is a multi-threaded processor. Under pre-determined conditions, as discussed below, a trap signal to be used as a debugging event is generated by a processor  206  and is applied on line  208  to the processing controller  202 . This causes the trap address register  204  to route its stored trap address over line  212  to the frame buffer controller  214 . In particular, the trap address is received by the translation look-aside buffer (TLB)  216  of the frame buffer controller  214 . The TLB  216  attempts to access the trap address. As previously indicated, the trap address is an address that is known to cause a page fault. Thus, an access to the trap address results in a page fault. The page fault is communicated over line  222  to the host interface  220 , which communicates the page fault to the CPU  102  via line  224 . The CPU  102  recognizes the specified page fault address as corresponding to a request for a debug operation. Therefore, the CPU  102  initiates a context switch. For example, the CPU  102  may apply a signal to the host interface  220  via line  224 . The host interface may then relay the signal to the processing controller  202 , which processes the context switch command in a standard manner to produce state information. Alternately, the host interface  220  may be configured to generate the context switch command in response to the page fault. Regardless of the implementation, all state information at the time of the page fault is captured and stored in memory (e.g., in the frame buffer  120 , system memory  110 , and/or GPU memory  109 ). In particular, to store state in the frame buffer  120 , the state information is routed from the processor  208 , to the frame buffer controller  214  over line or bus  212 . In turn, the frame buffer controller  214  stores the state information  118  in the frame buffer  120 . 
   The CPU  102  may also reply to the host interface  220  with instructions to halt additional processors  206  or particular threads operating on those processors. In one embodiment, the system is configured to halt all threads associated with a multi-threaded processor that produces a page fault. Alternately, the system is configured to halt all of the multi-threaded processors of a processing cluster  200 . In sum, the halt command may be configurable. The halt command is applied to the processing controller  202  over line  226 . Standard techniques are used to implement the halt operation. The host interface  220  may be configured to generate halt commands without reliance upon the CPU. 
     FIG. 3  is a more detailed illustration of a processing cluster  200 _A of the GPU  106 .  FIG. 3  illustrates that in this embodiment each processor  206  is a multi-threaded processor with a convoy  320  of threads  320 _ 1  through  320 _N. In other words, in this embodiment, each processor  206  includes circuitry to process a set of computational threads. 
   In one embodiment of the invention, each multi-threaded processor  206  is configured to recognize a trap instruction. The trap instruction is part of the instruction set that runs on each multi-threaded processor  206 . The trap instruction operates as a call to the trap address register  204 . As previously indicated, this results in the trap address within the trap address register being requested via the TLB  216 , which results in a page fault and the saving of state information. The trap instruction may be conveyed over line  302 . 
   In accordance with the invention, other techniques may be used to call the address in trap address register  204 , generate a page fault and save state information. As shown in  FIG. 3 , a logical OR gate  300  may be used to test for a variety of conditions that will result in the saving of state information. For example, a performance counter  304  may be used. The performance counter  304  may be used to track any metric associated with the operation of a processor  206 . For example, the performance counter  304  may count the number of instructions executed by a processor  206 . This may be done on a per thread basis or across all threads. When a count limit is reached, the performance counter  304  produces a digital high signal, which is applied to the logical OR gate, resulting in state information being saved. The performance counter  304  facilitates the saving of state information in incremental steps. This allows one to acquire state information on a step-by-step basis. 
   An error detector  308  may also be used in accordance with an embodiment of the invention. The error detector  308  may be configured to produce a digital high signal in the event that a processor  206  enters any number of states deemed to be error states. Preferably, the error states are configurable. This allows a developer to fetch state information under specified conditions. 
   A register value comparator  310  may also be used to test for other conditions that may trigger debug operations. For example, the register value comparator  310  may be configured to compare a current program counter value to an expected program counter value. This permits single step analysis of program instructions. 
     FIG. 4  illustrates processing operations associated with an embodiment of the invention. In one mode of operation, a GPU is monitored for a debug instruction  400 , such as a trap instruction or a breakpoint instruction. The GPU execution state information is then saved  402  through the coordinated operations of the GPU and the CPU. The final processing operation of  FIG. 4  is to debug the execution state information  404 . Once the state information is secured in accordance with the invention, standard techniques may be used to debug the state information. For example, debugger  116  of  FIG. 1  may be used to implement this operation. 
     FIG. 5  illustrates processing operations associated with another embodiment of the invention. This embodiment does not contemplate the use of a breakpoint instruction. Rather, this embodiment relies upon a trap instruction and a page fault mechanism. Initially, the GPU is monitored in accordance with selected criteria associated with a trap instruction. The selected criteria may be a performance value, an error value, a register comparator value, or a trap instruction. In response to the occurrence of a specified event, a trap signal is generated  502 . Thus, for example, as shown in  FIGS. 2 and 3 , a trap signal may be routed to the processing controller  202  via line  208 . 
   The next operation of  FIG. 5  is to produce a page fault  504 . As previously indicated, the trap address from the trap address register  204  may be routed to the TLB  216  of the frame buffer controller  214 . An attempt to access the address results in a page fault. 
   GPU state information is then saved  506 . The state information  118  may be stored in a memory (e.g., frame buffer  120 ). The state information  118  may also be routed to memory  110 . The final operation of  FIG. 5  is to debug the state information  508 . Debugger  116  may be used to implement this operation. 
   Those skilled in the art will appreciate that the invention provides a technique for securing state information associated with a GPU. Dedicated circuitry is not required to obtain this information. Instead, in the case of a trap instruction, the state information is secured by using resident page fault and context switch mechanisms. The invention strategically invokes page faults to secure state information. This is highly advantageous in a GPU environment, where it is difficult to create precise stop points, particularly in a multi-threaded environment. The invention provides a general debug tool for a GPU. 
   The invention may also be implemented with a GPU breakpoint instruction that does not rely upon a page fault mechanism. In such an embodiment, the breakpoint instruction is added to the instruction set. The instruction temporarily freezes the thread that executes it and generates a debugging event signal, e.g., on line  208  of  FIG. 2 . In the case of the breakpoint instruction, the trap address register is not utilized. Instead, the breakpoint instruction causes the processing controller  202  to send a signal on line  226  to the host interface  220 , which signals the CPU over line  224  that a GPU breakpoint has been reached. The breakpoint signal optionally freezes other threads in the same processor, and/or in other GPU processors. 
   The breakpoint instruction may be used in a selectable single step mode that executes one instruction per thread, then acts as if the GPU processor executed a breakpoint instruction following that instruction, causing a debugging event signal. The debugging program  116  in cooperation with the debug driver  114 , may issue an instruction to the host interface  220  to stop the GPU, read/write the state of frozen GPU threads, read a per-thread break bit to determine which threads have experienced a debugging event, modify their PCs, modify instructions, and then resume GPU execution. The debug driver  116  reads and writes GPU control registers  111  via the host interface  220  to access GPU state. Because the GPU is in a frozen state while debugging GPU programs, a second GPU may be used to provide a display for the CPU if desired. 
   The foregoing description, for purposes of explanation, used specific nomenclature to provide a thorough understanding of the invention. However, it will be apparent to one skilled in the art that specific details are not required in order to practice the invention. Thus, the foregoing descriptions of specific embodiments of the invention are presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed; obviously, many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications, they thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated. It is intended that the following claims and their equivalents define the scope of the invention.