Exception handler for sampling draw dispatch identifiers

Abstract

The drawing command that is bound to the shader / wavefront back to its origin. In various embodiments, a method of operating a graphics pipeline [206] and exception handling includes receiving an exception signal [306] at a command processor [202] of a graphics processing unit (GPU) indicating that a pipeline exception occurred at a shader stage [212B] of a graphics pipeline. The shader stage generates an exception signal in response to the pipeline exception and transmits the exception signal to the command processor. The command processor determines the address [225] of a command packet [224] responsible for the occurrence of the pipeline exception based on the exception signal.

Description

Background Art

[0001] Graphics processing devices can be implemented to implement a variety of image processing or other general processing applications. For example, a graphics processing unit (GPU, sometimes referred to as a general-purpose graphics processing unit) typically executes applications that benefit from a high degree of parallelism. Typically, a GPU is designed to process a series of instructions using one or more shader processors resident in the GPU, which may be referred to as shader instructions. In an example image processing application, a shader instruction defines one or more mathematical operations to be performed by the shader processor on the pixels that make up the image. By applying the shader instruction to the pixel, the pixel value is changed or evaluated according to the mathematical operation defined by the shader instruction. The shader instructions are organized into shader program codes called kernels, which define the functions or tasks performed by the GPU. In order to execute the kernel, the program code is divided into work items (e.g., the basic units of work in the GPU). BRIEF DESCRIPTION OF THE DRAWINGS

[0002] The present disclosure may be better understood, and its numerous features and advantages made apparent to those skilled in the art by referencing the accompanying drawings.The use of the same reference numbers in different drawings indicates similar or identical items.

[0003] Figure 1 is a block diagram of a processing system for implementing wavefront anomaly processing, according to some embodiments.

[0004] Figure 2 is a block diagram illustrating a GPU for implementing wavefront exception processing according to some embodiments.

[0005] Figure 3 is a block diagram illustrating exception handling by sampling draw dispatch identifiers according to some embodiments.

[0006] Figure 4 A flow chart illustrating a method of operating a graphics pipeline and exception handling by sampling draw dispatch identifiers according to some embodiments is shown. DETAILED DESCRIPTION

[0007] To perform graphics processing, the system's central processing unit (CPU) typically issues a call to the GPU, such as a draw call or a dispatch call, which includes a series of commands that instruct the GPU to draw an object according to the CPU's instructions. Because draw calls are processed through the GPU graphics pipeline, exceptions sometimes occur in the graphics pipeline due to hangs, crashes, failures, etc. Current implementations lack a mechanism to identify the source of the draw or dispatch, the corresponding pipeline shader where the exception occurred, where the wavefront came from in the shader, and the command buffer that issued the draw or dispatch to the shader. Current error reporting only notifies of the occurrence of a hang, but does not provide any detailed information about where the hang came from in the source code (i.e., event reporting rather than diagnostics).

[0008] To speed up debugging operations faster, Figures 1 to 4 A system and method for sampling the address of a draw or dispatch packet responsible for creating an exception by tying a shader / wavefront back to the draw command from which it originated is described. In various embodiments, a method of operating a graphics pipeline and exception handling includes receiving an exception signal at a command processor of a graphics processing unit (GPU) indicating that a pipeline exception has occurred in a shader stage of the graphics pipeline. The shader stage generates an exception signal in response to the pipeline exception and transmits the exception signal to the command processor. The command processor determines the address of the command packet responsible for the occurrence of the pipeline exception based on the exception signal. In some embodiments, the exception signal is received at an exception handler of the command processor. In some embodiments, the command processor stores the address associated with each draw or dispatch submitted to the graphics pipeline in a ring buffer. Furthermore, the command processor processes the header of a command packet in a command stream submitted to the GPU and advances a write pointer of the ring buffer for each storage of an address associated with each draw or dispatch. After the wavefront associated with each draw or dispatch completes processing through the graphics pipeline, the read pointer of the ring buffer is advanced. In this way, the command processor performs fine-grained logging of packet addresses and allows the shader to track which draw caused the failure in the event of an exception / hang all the way back to the user submitting work to the GPU.

[0009] Figure 11 is a block diagram of a processing system 100 for implementing wavefront anomaly processing, according to some embodiments. The computing system 100 includes a central processing unit (CPU) 102; a system memory 104; a graphics processing device 106, including a graphics processing unit (GPU) 108; and a display device 110, which are communicatively coupled together via a system data bus 112. As shown, the system data bus 112 connects the CPU 102, the system memory 104, and the graphics processing device 106. In other embodiments, the system memory 104 is directly connected to the CPU 102. In some embodiments, the CPU 102, portions of the graphics processing device 106, the system data bus 112, or any combination thereof may be integrated into a single processing unit. Additionally, the functionality of the graphics processing device 106 may be included in a chipset or some other type of dedicated processing unit or coprocessor.

[0010] CPU 102 executes programmed instructions stored in system memory 104, operates on data stored in system memory 104, sends instructions and / or data (e.g., work or tasks to be performed) to graphics processing unit 108 for completion, and configures portions of graphics processing device 106 for work to be performed by GPU 108. In some embodiments, system memory 104 includes dynamic random access memory (DRAM) for storing programmed instructions and data for processing by CPU 102 and graphics processing device 106.

[0011] In various embodiments, CPU 102 sends instructions intended for processing at GPU 108 to command buffer 119. In the illustrated embodiment, command buffer 119 is located in system memory 104 (e.g., system memory 104) coupled to bus 112. In other embodiments, CPU 102 sends graphics commands intended for GPU 108 to a separate memory communicatively coupled to bus 112. The command buffer temporarily stores a stream of graphics commands, which comprises input to GPU 108. In other embodiments, command buffer 119 is an indirect buffer (IB) that stores graphics commands separate from a main command buffer (not shown) employed by CPU 102. The use of an indirect buffer allows GPU 108 to process graphics commands and generate and store data for other graphics commands while CPU 102 performs other operations.

[0012] The graphics command stream includes, for example, one or more command packets and / or one or more state update packets. In some embodiments, the command packets include draw commands (also interchangeably referred to as "draw calls") that direct the GPU 108 to perform processing on image data to be output for display. For example, in some cases, the draw commands direct the GPU 108 to render pixels defined by a set of one or more vertices stored in memory (e.g., defined in a vertex buffer). In some embodiments, the geometric shapes defined by the set of one or more vertices correspond to a plurality of primitives to be rendered. Each draw command is associated with an address that identifies, for example, where the draw command is stored in the command buffer 119 and where the draw command is located in the program flow of the instruction set executed by the CPU 102. The address of the draw command thus provides an identifier for the draw command for debugging and other operations, as further described herein.

[0013] The GPU 108 receives and processes work transmitted from the CPU 102. For example, in various embodiments, the GPU 108 processes work to render and display graphics images on the display device 110, such as by using one or more graphics pipelines 114. The graphics pipeline 114 includes a fixed-function stage and a programmable shader stage. The fixed-function stage includes the typical hardware stages included in the fixed-function pipeline of a GPU. The programmable shader stage includes a streaming multiprocessor. Each of the streaming multiprocessors is capable of executing a relatively large number of threads simultaneously. In addition, each of the streaming multiprocessors can be programmed to perform processing tasks related to a wide range of applications, including but not limited to linear and nonlinear data transformations, filtering of video and / or audio data, modeling operations (e.g., applying physics to determine the position, velocity, and other properties of an object), and the like. In other embodiments, the graphics processing device 106 is used for non-graphics processing.

[0014] As also shown, the system memory 104 includes an application 116 (e.g., an operating system or other application), an application programming interface (API) 118, and a GPU driver 120. The application 116 generates calls to the API 118 for producing a desired set of results, typically in the form of a sequence of graphics images. The graphics processing device 106 includes a GPU data bus 122 that communicatively couples the GPU 108 to a GPU local memory 124. In various embodiments, the GPU 108 uses any combination of the GPU local memory 124 and the system memory 104 for memory operations. The CPU 102 allocates portions of these memories for the GPU 108 to perform work. For example, in various embodiments, the GPU 108 receives instructions from the CPU 102, processes the instructions to render graphics data and images, and stores the images in the GPU local memory 124. Subsequently, the GPU 108 displays the graphics images stored in the GPU local memory 124 on the display device 110. The GPU local memory 124 stores data and programming used by the GPU 108. Figure 1 As shown in , the GPU local memory 124 includes a frame buffer 126 that stores data for driving the display device 110 .

[0015] In various embodiments, the GPU 108 includes one or more computational units (such as one or more processing cores 128) that include one or more processing units 130 that execute one thread while executing other threads in a wavefront, such as according to a single instruction, multiple data (SIMD) execution model. The processing units 130 are also interchangeably referred to as SIMD units. The SIMD execution model is a model in which multiple processing elements share a single program control flow unit and program counter and therefore execute the same program, but can execute the program with different data. The processing cores 128 of the GPU 108 are also interchangeably referred to as shader cores or streaming multiprocessors (SMXs). The number of processing cores 128 implemented in the GPU 108 is a matter of design choice.

[0016] Each of the one or more processing cores 128 executes a corresponding instantiation of a specific work item to process incoming data, where the basic unit of execution in the one or more processing cores 122 is a work item (e.g., a thread). Each work item represents a single instantiation of a collection of parallel executions of kernels invoked on the device, for example, by commands to be executed in parallel. A work item is executed by one or more processing elements as part of a workgroup executing at a processing core 128. In various embodiments, the GPU 108 issues and executes work items comprising multiple groups of threads, which are executed simultaneously as "wavefronts" on a single processing unit 130. Multiple wavefronts are included in a "workgroup," which comprises a collection of work items designated to execute the same program. A workgroup is executed by executing each of the wavefronts that make up the workgroup. In some embodiments, wavefronts are executed sequentially on a single processing unit 130, or partially or fully in parallel on different SIMD units. In other embodiments, all wavefronts from a workgroup are processed on the same processing core 128. Wavefronts are interchangeably referred to as warps, vectors, or threads.

[0017] In some embodiments, wavefronts comprise instances of parallel execution of shader programs, where each wavefront comprises multiple work items that are executed simultaneously according to the SIMD paradigm (e.g., one instruction control unit executes the same instruction stream with multiple data) on a single processing unit 130. Scheduler 132 performs operations related to scheduling the various wavefronts on the different processing cores 128 and processing units 130, as well as other operations to orchestrate various tasks on graphics processing subsystem 106. In some embodiments, GPU 108 assigns an identifier (ID) to each wavefront to distinguish each wavefront from other wavefronts.

[0018] The parallelism provided by one or more processing cores 128 is suitable for graphics-related operations such as pixel value calculations, vertex transformations, tessellation, geometry shading operations, and other graphics operations. The graphics pipeline 114 receives graphics processing commands from the CPU 102 and, in turn, provides computational tasks to the one or more processing cores 128 for parallel execution. In some embodiments, the CPU 102 provides commands in the form of command packets, which, when provided sequentially, form a command stream. Each command packet includes a header identifying the command, the command's position in the command stream, and other control information. Some graphics pipeline operations, such as pixel processing, and other parallel computational operations require the execution of the same command stream or computation kernel on a stream or set of input data elements. Corresponding instantiations of the same computation kernel are executed simultaneously on multiple processing units 130 in one or more processing cores 128 to process such data elements in parallel. As referred to herein, for example, a computation kernel is a function comprising instructions declared in a program and executed on a processing core 128. This function is also referred to as a kernel, shader, shader program, or program.

[0019] In operation, and as follows about Figure 2 As described in greater detail, GPU 108 includes an exception handler configured to receive an exception signal from graphics pipeline 114 and, in response thereto, determine the address of a command packet responsible for the occurrence of the pipeline exception based on the exception signal. Figure 2 is a block diagram illustrating a GPU for implementing wavefront exception processing according to some embodiments. Those skilled in the art will recognize that Figure 2 The GPU 104 is merely an illustrative example and is not intended to be limiting, as the described operations and structures are employed in any suitable device in various embodiments. In the context of the GPU 104 as shown in this embodiment, the GPU 104 includes a command processor 202, a sequencer 204, a GPU local memory 124, and one or more graphics pipelines 114, such as a graphics pipeline 206 and a compute pipeline 208. Although the GPU local memory 124 is shown as part of the GPU 104, in other embodiments, the GPU local memory 124 is a memory unit separate from the GPU 104 or is located within the GPU 104. Figure 1 is implemented at the system memory 104.

[0020] The command processor 202 receives commands to be executed in a command stream 210 from the CPU 102 (e.g., via the command buffer and bus 112) and coordinates the execution of these commands at one or more graphics pipelines 114 of the GPU 108. Figure 1As discussed, the CPU 102 sends instructions intended for the GPU 108 to a command buffer. In various embodiments, the command buffer is located, for example, in the system memory 104, which is a separate memory coupled to the bus 112. The command processor 202 is implemented as a reduced instruction set computer (RISC) engine with microcode to implement logic including scheduling logic. In various embodiments, the command processor 202 is implemented in hardware, firmware, software, or a combination thereof. The command stream 210 includes one or more packets (e.g., packet 224) representing draw calls and / or dispatch commands. Each packet stores an address (e.g., draw command address 225) that identifies the corresponding draw call, dispatch command, or other operation.

[0021] In some embodiments, the command processor 202 stores addresses associated with draws or dispatches submitted to the graphics pipeline 206 in a ring buffer (e.g., ring buffers 214, 216, and 218) in the GPU local memory 124. As described above, the address associated with each draw or dispatch is a memory address that indicates the memory location of the draw or dispatch command and provides an identifier for the draw or dispatch command relative to other commands. Ring buffers 214, 216, and 218 are storage structures that each manage the storage and retrieval of commands using two pointers: a write pointer and a read pointer. That is, each of the ring buffers 214, 216, and 218 is associated with its own corresponding write pointer and read pointer. The write pointer stores (i.e., points to) the address of the location of the ring buffer where the command is stored, while the read pointer points to the location of the ring buffer where the command was retrieved. As further described herein, the command processor 202 manipulates the values ​​of the write pointer and read pointer of each ring buffer 214, 216, and 218 to write and read commands to and from the corresponding ring buffer.

[0022] As further described below, the command processor 202 processes the headers of the command packets in the command stream 210 submitted to the GPU 108 to identify the address associated with the draw or dispatch command represented by the command packet. The command processor 202 stores the address at the location pointed to by the write pointer in the ring buffer 214 and advances the write pointer of the ring buffer 214. In some embodiments, the command processor also stores the wavefront identifiers of the wavefronts generated based on the draw commands. After the wavefront associated with each draw or dispatch is processed through the graphics pipeline, the command processor 202 advances the read pointer of the ring buffer 214. In this way, the command processor 202 performs fine-grained logging of draw and dispatch command addresses and allows the GPU 108 to track which draw command caused the failure in the event of an exception / hang.

[0023] In various embodiments, the command processor 202 manages multiple command buffers, keeps track of commands and work sent down into the GPU, and updates fences as the command stream reaches them. The command processor 202 also manages various specialized fixed-function logic, vertex assemblers (VAs), tessellators, geometry assemblers (GAs), rasterizers / interpolators, other shader stages, etc. Although in Figure 2 108 is shown as having one command processor 202, but those skilled in the art will recognize that in other embodiments, the GPU 108 includes any number and type of command processors for retrieving and executing packets from the hardware queue. In various embodiments, a "packet" refers to a memory buffer that encodes a single command. Different types of packets are stored in hardware queues, memory buffers, etc. Additionally, as used herein, the term "block" refers to a processing module included in an ASIC, an execution pipeline of a CPU, and / or a graphics pipeline of a GPU. In various embodiments, such processing modules include, but are not limited to, an arithmetic logic unit, a multiplication / division unit, a floating point unit, a color buffer, a vertex shader, a pixel shader, a clipping unit, or some other processing module apparent to those skilled in the art.

[0024] In some embodiments, if all address slots in the ring buffer 214 are currently occupied, the command processor 202 operation stops until the storage is ready (e.g., after all paths of the pipeline have completed processing, the completion count is incremented, and the tail read pointer 304 on the address storage at the ring buffer 214 can be released). Once the address has been stored, a sideband signal is sent per the stream counter. When a wave is transmitted, the command processor 202 stores the index from the current counter into the appropriate wave buffer location for possible later lookup. For multi-draw packets, the stored address is the address of the calling packet.

[0025] like Figure 2 As shown in FIG, in this example, command processor 202 includes a sequencer 204 (also known as an instruction scheduler) that is configured to manage the various processing cores (e.g., Figure 1The sequencer 204 is a block diagram of a process flow diagram of a processor core 128 of a processor core 128. For example, in some embodiments, the sequencer 204 receives vertex vector data from a vertex grouper and tessellator (VGT, not shown for ease of illustration). The sequencer 204 manages vertex vector and pixel vector operations, vertex and pixel shader input data management, memory allocation for derived resources, thread arbitration for multiple SIMD units 130 and resource types, control flow and ALU execution of the processing core, shader and constant addressing, and other control functions. In addition, the sequencer 204 is the main controller of the shader pipeline interpolator (SPI, not shown for ease of illustration) and the various processing cores. Wavefronts are assigned by the sequencer 204, which generates threads from the wavefronts and sequences these threads to be executed at the corresponding SIMD units 130.

[0026] One or more graphics pipelines 114 (such as graphics pipeline 206 and compute pipeline 208) include several stages 212, including stage A 212A, stage B 212B, and run-through stage N 212N. In various embodiments, the various stages 212 each represent a stage of the graphics pipeline 114 that performs various aspects of a draw call or dispatch call. In various embodiments, the one or more graphics pipelines 114 include various fixed-function stages and programmable shader stages. The fixed-function stages and programmable shader stages are configured to perform designated functions along the one or more graphics pipelines 114. In some embodiments, the fixed-function stages are implemented in hardware and are configured to perform a single, dedicated function. The fixed-function stages are conventional hardware-implemented stages employed in traditional fixed-function graphics pipelines.

[0027] In some embodiments, the programmable shader stage of the graphics pipeline 208 includes a processor module that is programmed to perform specific functions. In one embodiment, the graphics pipeline 108 includes a specialized processor called a shader processor that is well-suited for highly parallel code and not well-suited for scalar code. The programmable shader stage is implemented as one or more shader programs that are executed at the shader processor of the graphics pipeline 206. In some examples, the shader processor is referred to as a "shader unit" or "unified shader" and performs geometry, vertex, pixel, or other shading operations to render graphics.

[0028] According to various aspects of the present disclosure, command processor 202 receives commands from command stream 210 and coordinates the execution of these commands at one or more graphics pipelines 114. Command processor 202 maintains one or more ring buffers (shown in this example as 214, 216, and 218) (or other similar circular queues / first-in-first-out (FIFO) buffers) in memory for each of the one or more graphics pipelines 114, where each ring buffer tracks the addresses of commands and packets processed by command processor 202, depending on whether the pipeline handles dispatch, drawing, or both.

[0029] Graphics pipeline 206 is capable of performing both computation (e.g., drawing) and dispatch (also known as a game pipeline), and therefore, command processor 202 maintains two separate ring buffers for each graphics pipeline. Figure 2 As shown in FIG, the command processor 202 stores command addresses in a first ring buffer 214 and a second ring buffer 216 of the graphics pipeline 206. The first ring buffer 214 stores the addresses of draw commands submitted to the graphics pipeline 206. The second ring buffer 216 stores the addresses of dispatch commands submitted to the graphics pipeline 206. The ring buffer 218 stores the addresses of dispatch commands submitted to the compute pipeline 208. The compute pipeline 208 does not handle draw commands and therefore does not have a corresponding ring buffer for tracking draws. In other embodiments, the GPU 108 includes a pipeline (referred to as an OS pipeline) that is capable of issuing only draws and is therefore associated with only a single ring buffer for draws (in a manner similar to the compute pipeline 208).

[0030] As follows about Figure 3 Described in more detail, the command processor 202 stores the virtual address associated with each command (draw command or dispatch) issued by the command processor 202 in corresponding ring buffers 214 and 216 for processing at the pipeline 114. In various embodiments, when the command processor 202 processes the header of a draw packet or dispatch packet, the command processor 202 identifies the address of the location in the command buffer 119 where the draw packet or dispatch packet is stored (i.e., the source address of the packet) and stores the identified address in the corresponding ring buffers 214, 216, and 218. In this way, the command processor 202 records each draw command (or dispatch command) submitted to the pipeline 114 for processing and the identifier of its associated wavefront (generally referred to herein as a "draw dispatch identifier").

[0031] In other embodiments, it also depends on how the draw commands or dispatch commands are stored or identified at the processor 100. For example, in some embodiments, the draw commands or dispatch commands may be direct commands generated by the CPU 102, indirect commands generated by the GPU 108, commands with an embedded count to identify how many times the command will be executed, etc. In these embodiments, the command processor 202 stores different information at the ring buffers 214, 216, and 218. For example, for commands that include an embedded count, the command processor 202 stores the address of the command at multiple entries in the ring buffer 214 to match the embedded count.

[0032] Conventional GPUs typically do not track the origins of individual wavefronts. Therefore, when encountering an exception (e.g., an error, crash, hang, malfunction, etc.), the GPU only knows that the exception occurred, but not where it originated. For example, in some scenarios, multiple draws are sent along the graphics pipeline, and any one of these draws could be the cause of the exception. Instead, GPU 108 is configured to trace the source of the exception back to the individual draw (or dispatch) command that created each individual wavefront.

[0033] For the purpose of illustration, and as follows Figure 3 As described in more detail, upon encountering an exception, the graphics pipeline 114 sends an exception signal to the exception handler 220 at the command processor 202 to request the draw dispatch identifier for the command that caused the exception. Figure 2 2 as being implemented within sequencer 204 of GPU 108, but in other embodiments, exception handler 220 is implemented at a different location within GPU 108 without departing from the scope of this disclosure. Exception handler 220 includes the necessary logic to receive exception signals and retrieve the draw dispatch identifier for the draw or dispatch command that generated the exception from ring buffers 214, 216, and 218.

[0034] See now Figure 3 , shows a block diagram of an exception handling operation by retrieving a draw dispatch identifier according to some embodiments. For ease of illustration, Figure 3 1 shows only a portion of the GPU 108. As shown, when the command processor 202 processes the header of a draw packet (or dispatch packet in various embodiments), the command processor 202 writes the address of the location of the command buffer 119 storing the draw (or dispatch) command and the corresponding wavefront identifier to the ring buffer 214 in the memory 124, and advances the position of the write pointer 302 with each write operation. Thus, for each draw, the command processor 202 records the location and wavefront ID of the relevant draw command in the memory 124.

[0035] In addition, the command processor 202 also maintains a read pointer 304 for the ring buffer 214. When wavefront processing is complete, the graphics pipeline 206 returns a completion event for graphics (or an EOP / EOS event for computation) to advance the read pointer 304. Therefore, from the perspective of the command processor, the position of the read pointer 304 indicates which draw (or dispatch) the command processor 202 is currently waiting for a response to. When the graphics pipeline 206 completes execution of a wavefront for a draw (or dispatch), the bottom of the pipeline advances the read pointer 304 to the next slot and allows the previous slot (associated with the completed draw) to be reused.

[0036] In various embodiments, the shader stage is configured to determine the occurrence of a pipeline exception during execution of the graphics pipeline. As shown, shader stage B 212B is configured to generate an exception signal 306 in response to, for example, an exception (such as a hang or other graphics pipeline error). In various embodiments, exception signal 306 is an output attribute of shader stage 212B. Therefore, unlike conventional programmable shader stages, shader stage 212B is configured to recognize when a pipeline exception occurs, transfer control away from graphics pipeline 206, and send exception signal 306 to exception handler 220. In various embodiments, any one of shader stages 212 can determine the occurrence of a pipeline exception and send exception signal 306 to exception handler 220.

[0037] In the event that the exception handler 220 is called (e.g., upon receiving the exception signal 306 at the exception handler 220), the wavefront request command processor 202 executed at the graphics pipeline 206 retrieves the draw or dispatch command identifier and the wavefront identifier stored at the ring buffer 214 by issuing a read operation to the location of the ring buffer 214 pointed to by the read pointer 304. Thus, in the example shown, the exception handler 220 determines that the wavefront that caused the fault originated from the draw or dispatch command ABC. This identifier is reported back to, for example, the CPU 102 (or other location in the system 100) to notify the source of the exception.

[0038] Figure 4 A flowchart illustrating a method 400 of operating a graphics pipeline and handling exceptions by sampling draw dispatch identifiers according to some embodiments is shown. The graphics pipeline may be Figure 1 Graphics pipeline 119 or Figure 2 Graphics pipeline 220.

[0039] At block 402, the command processor stores the address of each draw or dispatch submitted to the corresponding pipeline. Figures 2 to 3When the command processor 202 processes the header of a draw packet (or dispatch packet in various embodiments), the command processor 202 writes the command buffer address and associated wavefront identifier of the draw call (or dispatch) out to the ring buffer 214 in the memory 124, and advances the write pointer 302 with each operation. Thus, for each draw, the command processor 202 records in the memory 124 the location and ID from which the draw was taken.

[0040] At block 404, the graphics pipeline determines that a pipeline exception occurred during execution of a wavefront. Figure 3 , shader stage B 212B is configured to generate an exception signal 306 in response to, for example, an exception, such as a hang or other graphics pipeline error, and to send the exception signal 306 to the exception handler 220. A pipeline exception is a predefined condition associated with executing a portion of the work specified for a shader stage of the graphics pipeline 206. A pipeline exception may be, for example, a lack of resources, a lack of memory space, a lack of data, a divide by zero error, a hang, a fault, etc. In various embodiments, any of the shader stages 212 can determine the occurrence of a pipeline exception and send the exception signal 306 to the exception handler 220.

[0041] At block 406, a command processor of a graphics processing unit (GPU) receives an exception signal indicating that a pipeline exception has occurred. Figure 3 , the exception signal 306 is received at the exception handler 220. In the event of an exception handler call (e.g., the exception signal 306 is received at the exception handler 220), at block 408, the executing wavefront requests an index / address lookup to obtain an identifier for the draw or dispatch command that caused the exception from the ring buffers 214, 216, and 218. In some embodiments, this identifier is reported to the CPU 102 (or elsewhere in the system 100) to indicate the source of the pipeline exception.

[0042] In this way, if a wavefront hangs and a shader exception is issued by an application executing at GPU 108, the wavefront error can be traced back to its source. By providing a read pointer to the ring buffer in memory, the exception handler is able to determine the address of the draw or dispatch that caused the wavefront error, providing additional visibility into designs and error reporting that is not typically available in conventional GPUs.

[0043] As described herein, in some embodiments, a method includes: receiving an exception signal at a command processor of a graphics processing unit (GPU) indicating that a pipeline exception occurred in a shader stage of a graphics pipeline; transmitting the exception signal to the command processor; and determining an address of a command packet responsible for the occurrence of the pipeline exception based on the exception signal. In one aspect, receiving the exception signal includes: receiving the exception signal at an exception handler of the command processor. In another aspect, the method includes: storing, in a ring buffer, an address associated with each draw or dispatch submitted to the graphics pipeline.

[0044] In one aspect, the method includes processing a header of a command packet in a command stream submitted to a GPU; and advancing a write pointer of a ring buffer for each store of an address associated with each draw or dispatch. In another aspect, the method includes advancing a read pointer of the ring buffer after a wavefront associated with each draw or dispatch completes processing through a graphics pipeline. In another aspect, the command packet includes a draw call. In another aspect, the command packet includes a dispatch.

[0045] As described herein, in some embodiments, a system includes: a command processor, wherein the command processor is configured to: receive an exception signal indicating that a pipeline exception has occurred in a shader stage of a graphics pipeline; and determine the address of a command packet responsible for the occurrence of the pipeline exception based on the exception signal. In one aspect, the system includes an exception handler at the command processor, which is configured to receive the exception signal. In another aspect, the shader stage of the graphics pipeline is configured to generate an exception signal in response to the pipeline exception. In another aspect, the command processor is further configured to: store an address associated with each draw or dispatch submitted to the graphics pipeline at a ring buffer. In another aspect, the command processor is further configured to: process a header of a command packet in a command stream received at the command processor; and after storing the address associated with each draw or dispatch, advance a write pointer of the ring buffer.

[0046] In one aspect, the command processor is further configured to advance a read pointer of the ring buffer after a wavefront associated with each draw or dispatch completes processing through the graphics pipeline. In another aspect, the command packet includes a draw call, and the command processor stores addresses associated with the draw call in a first ring buffer. In another aspect, the command stream includes a dispatch call, and the command processor stores addresses associated with the dispatch call in a second ring buffer separate from the first ring buffer.

[0047] As described herein, in some embodiments, a non-transitory computer-readable medium embodies a set of executable instructions for operating at least one processor to: receive an exception signal indicating a pipeline exception occurred in a shader stage of a graphics pipeline; and determine, based on the exception signal, the address of a command packet responsible for the occurrence of the pipeline exception. In one aspect, the set of executable instructions further operate the at least one processor to: store an address associated with each draw or dispatch submitted to the graphics pipeline in a ring buffer. In another aspect, the set of executable instructions further operate the at least one processor to: process a header of a command packet in a command stream received at the command processor; and, after storing the address associated with each draw or dispatch, advance a write pointer of the ring buffer. In another aspect, the set of executable instructions further operate the at least one processor to: advance a read pointer of the ring buffer after a wavefront associated with each draw or dispatch completes processing through the graphics pipeline. In another aspect, the command packet includes a draw call, and the command processor stores the address associated with the draw call in a first ring buffer.

[0048] Computer-readable storage media include any non-transitory storage media or a combination of non-transitory storage media that can be accessed by a computer system during use to provide instructions and / or data to the computer system. Such storage media may include, but are not limited to, optical media (e.g., compact discs (CDs), digital versatile discs (DVDs), Blu-ray discs), magnetic media (e.g., floppy disks, tapes, or magnetic hard disks), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or flash memory), or storage media based on microelectromechanical systems (MEMS). In some embodiments, the computer-readable storage medium is embedded in a computing system (e.g., system RAM or ROM), fixedly attached to a computing system (e.g., a magnetic hard drive), removably attached to a computing system (e.g., an optical disc or flash memory based on a universal serial bus (USB)), or connected to a computer system via a wired or wireless network (e.g., a network accessible storage device (NAS)).

[0049] In some embodiments, certain aspects of the technology described above are implemented by one or more processors of a processing system that executes software. The software includes one or more sets of executable instructions stored or otherwise tangibly embodied on a non-transitory computer-readable storage medium. The software may include instructions and certain data that, when executed by one or more processors, manipulate the one or more processors to perform one or more aspects of the technology described above. The non-transitory computer-readable storage medium may include, for example, a magnetic or optical disk storage device, a solid-state storage device (such as a flash memory), a cache, a random access memory (RAM), or one or more other non-volatile memory devices. The executable instructions stored on the non-transitory computer-readable storage medium may be in the form of source code, assembly language code, object code, or other instruction formats that are interpreted or otherwise executable by one or more processors.

[0050] It should be noted that not all activities or elements described above in the general description are required, a portion of a specific activity or device may not be required, and one or more other activities may be performed, or multiple elements may be included to supplement the elements described. In addition, the order in which the activities are listed is not necessarily the order in which the activities are performed. Moreover, the concepts have been described with reference to specific embodiments. However, it will be understood by those skilled in the art that various modifications and changes may be made without departing from the scope of the present disclosure as set forth in the claims below. Therefore, this specification and drawings are to be regarded as illustrative rather than restrictive, and all such modifications are intended to be included within the scope of the present disclosure.

[0051] Benefits, other advantages, and solutions to problems have been described above with respect to specific embodiments. However, the benefits, advantages, solutions to problems, and any features that may cause any benefit, advantage, or solution to appear or become more prominent should not be construed as key, required, or essential features of any or all of the claims. Furthermore, the specific embodiments disclosed above are illustrative only, as the disclosed subject matter may be modified and practiced in different but equivalent manners that will be apparent to those skilled in the art having the benefit of the teachings herein. No limitation to the details of construction or design shown herein is intended, except as described in the claims below. Therefore, it is apparent that the specific embodiments disclosed above may be altered or modified, and all such variations are considered to be within the scope of the disclosed subject matter. Accordingly, the protection sought herein is as set forth in the claims below.

Claims

1. A method comprising: For each draw or dispatch submitted to a graphics pipeline of a graphics processor, storing an address associated with the submitted draw or dispatch, each submitted draw or dispatch including one or more instructions directing the graphics processor to draw an object; receiving, at a command processor, an exception signal indicating that a pipeline exception has occurred within the graphics pipeline; An address of a command packet associated with the pipeline exception is determined based on the exception signal and the storing.

2. The method of claim 1 , wherein receiving the abnormal signal comprises: The exception signal is received at an exception handler of the command processor.

3. The method of claim 1 or claim 2, wherein: Storing addresses associated with each draw or dispatch submitted to the graphics pipeline includes storing the associated addresses at a ring buffer.

4. The method of claim 3, further comprising: processing a header of the command packet in a command stream submitted to the graphics processor; as well as For each store to the address associated with each draw or dispatch, the write pointer of the ring buffer is advanced.

5. The method of claim 3, further comprising: After the wavefront associated with each draw or dispatch completes processing through the graphics pipeline, the read pointer of the ring buffer is advanced. The method of claim 1 , wherein the command packets comprise draw calls. The method of claim 1 , wherein the command grouping comprises dispatching.

8. A system comprising: A command processor, wherein the command processor is configured to: storing one or more addresses associated with each draw or dispatch submitted to a graphics pipeline of a graphics processor, each submitted draw or dispatch comprising one or more instructions directing the graphics processor to draw an object; receiving an exception signal indicating that a pipeline exception occurred at a shader stage of the graphics pipeline; and An address of a command packet associated with the pipeline exception is determined based on the exception signal and the stored one or more addresses.

9. The system of claim 8, further comprising: An exception handler at the command processor is configured to receive the exception signal.

10. The system of claim 8 or claim 9, wherein the shader stage of the graphics pipeline is configured to generate the exception signal in response to the pipeline exception.

11. The system of claim 8 or 9, wherein Storing the one or more associated addresses includes storing an address associated with each draw or dispatch submitted to the graphics pipeline at a ring buffer.

12. The system of claim 11, wherein the command processor is further configured to: processing headers of the command packets in a command stream received at the command processor; and After storing the address associated with each draw or dispatch, the write pointer of the ring buffer is advanced.

13. The system of claim 11 , wherein the command processor is further configured to: After the wavefront associated with each draw or dispatch completes processing through the graphics pipeline, the read pointer of the ring buffer is advanced.

14. The system of claim 11, wherein the command packet comprises a draw call, and the command processor stores addresses associated with the draw call at a first ring buffer.

15. The system of claim 14, wherein the command stream includes a dispatch call, and the command processor stores addresses associated with the dispatch call at a second ring buffer separate from the first ring buffer.

Images