Throttling of shaders based on resource usage in the graphics pipeline
The graphics pipeline dynamically throttles geometry waves based on buffer fullness and resource usage to balance resource allocation between geometry and pixel shaders, improving GPU performance by preventing resource monopolization and ensuring efficient processing.
Patent Information
- Application Number
- JP2023535353
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2020-12-16
- Filing Date
- 2021-12-14
- Publication Date
- 2026-02-02
- Estimated Expiration
- 2041-12-14
AI Technical Summary
Existing graphics processing units (GPUs) face performance issues due to static limits on compute units, which can lead to resource monopolization by geometry shaders, depriving pixel shaders of necessary resources, resulting in reduced performance during draw calls requiring more compute units.
Implementing a graphics pipeline that selectively throttles geometry waves based on buffer fullness, relative resource usage, and wave lifetime, using a primitive hub and shader processor input (SPI) to manage resource allocation between geometry and pixel shaders, ensuring balanced resource consumption.
Maintains balanced resource allocation by throttling geometry waves when they monopolize resources, preventing pixel shader starvation and enhancing overall GPU performance by optimizing resource usage.
Smart Images

Figure 0007809706000002 
Figure 0007809706000003 
Figure 0007809706000004
Abstract
Description
[Background technology]
[0001] A graphics processing unit (GPU) implements a graphics processing pipeline that simultaneously processes copies of commands retrieved from a command buffer. The graphics pipeline includes one or more shaders that execute using the graphics pipeline's resources and one or more fixed-function hardware blocks. The graphics pipeline is typically divided into a geometry portion, which performs geometry operations on patches or other primitives, such as triangles, formed from vertices and edges to represent portions of an image. Shaders within the geometry portion may include vertex shaders, global shaders, domain shaders, and geometry shaders. The geometry portion of the graphics pipeline is completed when the primitives produced by the geometry portion of the pipeline are rasterized (e.g., by one or more scan converters) to form a set of pixels that represent portions of the image. Subsequent processing on pixels is referred to as pixel processing and includes operations performed by shaders, such as pixel shaders, that execute using the graphics pipeline's resources. GPUs and other multithreaded processing units typically implement multiple processing elements (also referred to as processor cores or compute units) that simultaneously execute multiple instances of a single program on multiple data sets as a single wave. A hierarchical execution model is used to match the hierarchy implemented in the hardware. The execution model defines the kernel of instructions executed by every wave (also called a wavefront, thread, stream, or work item).
[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, in which: The use of the same reference numbers in different drawings indicates similar or identical items. [Brief explanation of the drawings]
[0003] [Figure 1] FIG. 1 is a block diagram of a processing system, according to some embodiments. [Figure 2] FIG. 1 illustrates a graphics pipeline configured to provide processing of high-order geometric primitives to generate a rasterized image of a three-dimensional (3D) scene at a predetermined resolution, according to some embodiments. [Figure 3] FIG. 1 is a block diagram of a portion of a graphics pipeline that implements shader throttling based on resource usage of different types of shaders, according to some embodiments. [Figure 4] FIG. 1 is a block diagram of a portion of a graphics pipeline that selectively launches geometry waves based on resource usage in the graphics pipeline, according to some embodiments. [Figure 5] FIG. 10 is a flow diagram of a method for determining counter values for selectively throttling geometry waves based on buffer fullness, according to some embodiments. [Figure 6] FIG. 10 is a flow diagram of a method for determining counter values for selectively throttling geometry waves based on relative resource usage of geometry shader waves and pixel shader waves, according to some embodiments. [Figure 7] FIG. 10 is a flow diagram of a method for determining counter values for selectively throttling geometry waves based on the lifetimes of a geometry shader wave or a group thereof, according to some embodiments. [Figure 8] 1 illustrates a first time interval representing a "no throttle" state before throttling geometry shader waves, according to some embodiments, in which sampling logic begins sampling. [Figure 9]FIG. 10 illustrates a second time interval including a transition from no throttling to throttling for a geometry shader wave, in accordance with some embodiments. [Figure 10] FIG. 10 illustrates a third time interval including a transition from throttling to no throttling due to a reduction in backpressure from the primitive hub, in accordance with some embodiments. [Figure 11] FIG. 10 illustrates a fourth time interval during which the transition from throttling to no throttling is completed, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION
[0004] Shaders, such as geometry shaders in the geometry portion of a GPU's graphics pipeline, emit waves to be processed by the shader. The results of the shader processing are passed to downstream entities, such as other shaders in the pipeline. For example, a geometry shader wave generator emits waves using a greedy algorithm that attempts to use as many graphics pipeline resources as possible. Primitives processed by the geometry shader are passed to one or more scan converters, which convert the primitives into pixels for processing in a pixel shader. Greedily emitting waves for processing in one shader can deprive downstream shaders of the resources needed to complete their operations on primitives or pixels. For example, if a geometry shader wave generator emits too many waves and the geometry shader monopolizes graphics pipeline resources, the pixel shader may not be able to access graphics pipeline resources to perform shading on pixels received from the scan converter. Some graphics pipelines are configured to limit the number of in-flight waves by constraining the number of compute units that can be assigned to a shader to process waves. However, a static limit on the number of available compute units typically reduces the performance of the graphics pipeline when executing draw calls that require a larger number of compute units.
[0005] 1-11 disclose embodiments of a graphics pipeline that maintains a balance between resources consumed by a first shader and a second shader by selectively issuing waves from the first shader based on a measure of graphics pipeline resources consumed by the first shader of a first type and the second shader of a second type. In some embodiments, the first shader is a geometry shader and the second shader is a pixel shader. The geometry shader selectively issues geometry waves based on the fullness of buffers that provide primitives to a scan converter and a measure of the relative allocation of resources to the geometry shader and the pixel shader. A primitive hub monitors the fullness of a set of first-in-first-out (FIFO) buffers that receive primitives from the geometry shader and provide the primitives to a set of scan converters that generate pixels based on the received primitives. The primitive hub throttles waves issued by the geometry shader using a stall signal implemented as a stall counter that increments to indicate the number of "dead" cycles. The number of dead cycles is determined based on the fullness of at least one of the FIFO buffers and is then decremented on each clock cycle. The geometry shader emits a wave in response to the stall counter having a predetermined value, such as 0.
[0006] The primitive hub provides a shader processor input (SPI) with feedback indicating fullness, and the SPI selectively throttles geometry shader waves based on the resource usage of the geometry shaders and pixel shaders. Some embodiments of the SPI determine the relative allocation of local data store (LDS) resources to in-flight geometry shader waves and in-flight pixel shader waves, the relative allocation of registers such as vector general-purpose registers (VGPR) to in-flight geometry shader waves and in-flight pixel shader waves, or a combination thereof. The SPI increments a stall counter in response to the relative allocation of resources to in-flight geometry shader waves and in-flight pixel shader waves exceeding a threshold indicating that the in-flight geometry shader waves are consuming resources and preventing the processing of the in-flight pixel shader waves. In some embodiments, the value of the stall counter is determined based on the lifespan of geometry shader waves in one or more geometry shader groups, and the stall counter is incremented if the lifespan exceeds the threshold.
[0007] FIG. 1 is a block diagram of a processing system 100 according to some embodiments. The processing system 100 includes or has access to a memory 105 or other storage component implemented using a non-transitory computer-readable storage medium, such as dynamic random-access memory (DRAM). However, in some cases, the memory 105 may be implemented using other types of memory, including static random-access memory (SRAM), non-volatile RAM, etc. The memory 105 is referred to as an external memory because it is implemented externally to the processing unit implemented in the processing system 100. The processing system 100 also includes a bus 110 for supporting communication between entities implemented in the processing system 100, such as the memory 105. Some embodiments of the processing system 100 include other buses, bridges, switches, routers, etc., which are not shown in FIG. 1 for clarity.
[0008] The techniques described herein, in various embodiments, may be utilized in any of a variety of parallel processors, such as vector processors, graphics processing units (GPUs), general-purpose GPUs (GPGPUs), non-scalar processors, highly parallel processors, artificial intelligence (AI) processors, inference engines, machine learning processors, other multi-threaded processing units, etc. FIG. 1 illustrates an example of a parallel processor, specifically a graphics processing unit (GPU) 115, according to some embodiments. The graphics processing unit (GPU) 115 renders images for presentation on a display 120. For example, the GPU 115 renders objects to generate pixel values that are provided to the display 120, which uses the pixel values to display images representing the rendered objects. The GPU 115 implements multiple compute units (CUs) 121, 122, and 123 (collectively referred to herein as “compute units 121-123”) that execute instructions simultaneously or in parallel. In some embodiments, the compute units 121-123 include one or more single instruction, multiple data (SIMD) units, and the compute units 121-123 are aggregated into a workgroup processor, a shader array, a shader engine, or the like. The number of compute units 121-123 implemented in the GPU 115 is a matter of design choice, and some embodiments of the GPU 115 include more or fewer compute units than shown in FIG. 1. The compute units 121-123 can be used to implement a graphics pipeline, as described herein. Some embodiments of the GPU 115 are used for general-purpose computing. The GPU 115 executes instructions, such as program code 125, stored in the memory 105, and the GPU 115 stores information, such as results of executed instructions, in the memory 105.
[0009] The processing system 100 also includes a central processing unit (CPU) 130 connected to the bus 110 and thus communicating with the GPU 115 and the memory 105 via the bus 110. The CPU 130 implements multiple processor cores 131, 132, and 133 (collectively referred to herein as "processor cores 131-133") that execute instructions simultaneously or in parallel. The number of processor cores 131-133 implemented in the CPU 130 is a matter of design choice, and some embodiments include more or fewer processor cores than shown in FIG. 1. The processor cores 131-133 execute instructions, such as program code 135, stored in the memory 105, and the CPU 130 stores information, such as results of the executed instructions, in the memory 105. The CPU 130 can also initiate graphics processing by issuing a draw call to the GPU 115. Some embodiments of CPU 130 include multiple processor cores (not shown in FIG. 1 for clarity) that independently execute instructions simultaneously or in parallel.
[0010] Input / Output (I / O) engine 145 handles input or output operations associated with display 120 and other elements of processing system 100, such as a keyboard, mouse, printer, external disk, etc. I / O engine 145 is coupled to bus 110 such that I / O engine 145 communicates with memory 105, GPU 115, or CPU 130. In the illustrated embodiment, I / O engine 145 reads information stored on external storage component 150, which is implemented using a non-transitory computer-readable storage medium, such as a compact disk (CD), digital video disk (DVD), etc. I / O engine 145 can also write information, such as results of processing by GPU 115 or CPU 130, to external storage component 150.
[0011] The processing system 100 implements a pipeline circuit for executing instructions in multiple stages of a pipeline. The pipeline circuit is implemented in some embodiments of the compute units 121-123 or the processor cores 131-133. In some embodiments, the pipeline circuit is used to implement a graphics pipeline that executes different types of shaders, including, but not limited to, vertex shaders, hull shaders, domain shaders, geometry shaders, and pixel shaders. The pipeline circuit also includes buffers that hold primitives generated by the shaders. In some embodiments, one or more buffers hold primitives generated by the geometry shader and then provide these primitives to the pixel shader. The pipeline circuit also includes a primitive hub that monitors buffer fullness. Wave emission from the geometry shader is throttled based on buffer fullness. A shader processor input (SPI) selectively throttles waves emitted by the geometry shader based on a signal from the primitive hub indicating fullness, an indicator of the relative resource usage of geometry waves and pixel waves in the graphics pipeline, or an indicator of the age of the geometry waves.
[0012] Figure 2 illustrates a graphics pipeline 200 configured to process high-order geometric primitives to generate a rasterized image of a three-dimensional (3D) scene at a predetermined resolution, according to some embodiments. Graphics pipeline 200 is implemented in some embodiments of processing system 100 shown in Figure 1. The illustrated embodiment of graphics pipeline 200 is implemented according to the DX11 specification. Other embodiments of graphics pipeline 200 are implemented according to other application programming interfaces (APIs), such as Vulkan, Metal, DX12, etc. Graphics pipeline 200 is subdivided into a geometry section 201, which includes portions of graphics pipeline 200 before rasterization, and a pixel processing section 202, which includes portions of graphics pipeline 200 after rasterization.
[0013] Graphics pipeline 200 can access storage resources 205, such as one or more memories or hierarchies of caches used to implement buffers and store vertex data, texture data, etc. In the illustrated embodiment, storage resources 205 include a local data store (LDS) 206 circuit used to store data and vector general purpose registers (VGPRs) used to store register values used during rendering by graphics pipeline 200. Storage resources 205 may be implemented using some embodiments of memory 105 shown in FIG. 1.
[0014] The input assembler 210 accesses information from storage resources 205 that is used to define objects that represent portions of a model of a scene. An example of a primitive is shown in Figure 2 as a triangle 211, although some embodiments of the graphics pipeline 200 process other types of primitives. A triangle 203 includes one or more vertices 212 (only one of each is shown in Figure 2 for clarity) connected by one or more edges 214. The vertices 212 are shaded during the geometry processing section 201 of the graphics pipeline 200.
[0015] Vertex shader 215, which is implemented in software in the illustrated embodiment, logically receives as input a single vertex 212 of a primitive and outputs a single vertex. Some embodiments of shaders, such as vertex shader 215, implement single instruction, multiple data (SIMD) processing so that multiple vertices are processed simultaneously. Graphics pipeline 200 implements a unified shader model so that all shaders included in graphics pipeline 200 have the same execution platform on a shared massive SIMD compute unit. Thus, shaders, including vertex shader 215, are implemented using a common set of resources, referred to herein as a unified shader pool 216.
[0016] The hull shader 218 operates on input high-order patches or control points used to define input patches. The hull shader 218 outputs tessellation coefficients and other patch data. In some embodiments, the primitives generated by the hull shader 218 are provided to the tessellator 220. The tessellator 220 receives objects (e.g., patches) from the hull shader 218 and generates information identifying primitives corresponding to the input objects, for example, by tessellating the input objects based on tessellation coefficients provided to the tessellator 220 by the hull shader 218. The tessellation subdivides input high-order primitives, such as patches, into a set of lower-order output primitives representing finer levels of detail, as indicated, for example, by tessellation coefficients that specify the granularity of the primitives generated by the tessellation process. Thus, a model of a scene is represented by a smaller number of high-order primitives (to save memory or bandwidth), and additional detail is added by tessellating the high-order primitives.
[0017] Domain shader 224 inputs the domain location and (optionally) other patch data. Domain shader 224 operates on the provided information and generates a single vertex for output based on the input domain location and other information. In the illustrated embodiment, domain shader 224 generates primitive 222 based on triangle 211 and tessellation factors. Geometry shader 226 receives the input primitive and outputs up to four primitives that are generated by geometry shader 226 based on the input primitive. In the illustrated embodiment, geometry shader 226 generates output primitive 228 based on tessellated primitive 222.
[0018] One stream of primitives is provided to one or more scan converters 230, and in some embodiments, up to four streams of primitives are concatenated into buffers within storage resources 205. Scan converters 230 perform shading operations and other operations such as clipping, perspective division, shearing, and viewport selection. Scan converters 230 generate sets of pixels 232 that are subsequently processed in pixel processing unit 202 of graphics pipeline 200.
[0019] In the illustrated embodiment, pixel shader 234 inputs a pixel flow (e.g., including set of pixels 232) and outputs zero or another pixel flow depending on the input pixel flow. Output merger block 236 performs blending, depth, stencil, or other operations on the pixels received from pixel shader 234.
[0020] Some or all of the shaders in graphics pipeline 200 perform texture mapping using texture data stored in storage resources 205. For example, pixel shader 234 may read texture data from storage resources 205 and shade one or more pixels using the texture data. The shaded pixels are then provided to a display for presentation to a user.
[0021] Figure 3 is a block diagram of a portion 300 of a graphics pipeline that implements shader throttling based on resource usage of different types of shaders, according to some embodiments. Portion 300 may be used to implement some embodiments of the graphics pipeline 200 shown in Figure 2. Commands are distributed to shader processor input (SPI) circuits 301, 302, and 303 (collectively referred to herein as "SPIs 301-303"), which submit waves for processing by corresponding shaders 311, 312, and 313 (collectively referred to herein as "shaders 311-313"). In the illustrated embodiment, shaders 311-313 are implemented as geometry shaders. For clarity, although not shown in Figure 3, SPIs 301-303 include (or are associated with) counters that are used to throttle wave submission for shaders 311-313, as described herein. Shaders 311-313 generate outputs including points, lines, triangles or other primitives that are provided to corresponding primitive assemblers (PAs) 321, 322, 323, collectively referred to herein as "PAs 321-323."
[0022] The primitive hub 325 receives primitives from the PAs 321-323 and distributes the primitives to the scan converters 331, 333, 333, collectively referred to herein as "scan converters 331-332." Some embodiments of the primitive hub 325 include a buffer complex (not shown in FIG. 3 for clarity) consisting of a set of first-in, first-out (FIFO) buffers associated with each of the PAs 320-123. Each set of buffers is associated with a corresponding one of the scan converters 331-333 such that the primitive hub 323 can selectively provide primitives from one of the PAs 321-323 to one of the scan converters 331-333 via the corresponding FIFO buffer. The primitive hub 323 also provides signals to the SPIs 301-303 indicating the fullness of the FIFO buffers and uses these signals to selectively throttle wave transmission as described herein. Scan converters 331-333 rasterize the received primitives to generate a set of pixels representing the primitives for display.
[0023] Some embodiments of SPI 301-303 collect data indicative of resource usage by shaders, including geometry shaders (such as geometry shader 226 shown in FIG. 2) and pixel shaders (such as pixel shader 234 shown in FIG. 2). The resource usage data is then used to selectively throttle wave submission. In some embodiments, SPI 301-303 implement resource usage counters (not shown in FIG. 3 for clarity) that are used to reduce the submission rate of geometry shader waves in response to determining that resource usage by a geometry shader is adversely affecting the pixel shader waves. Data obtained by SPI 301-303 includes the following: 1. The amount of resources used by in-flight geometry shader waves and pixel shader waves, taking into account LDS and VGPR consumption. The throttling circuit takes into account: a. Number of VGPRs used by in-flight geometry shader waves b. Number of VGPRs used by in-flight pixel shader waves c. Number of LDS chunks used by the in-flight geometry shader wave d. Number of LDS chunks used by the in-flight pixel shader wave
[0024] The data collection logic has two usage modes controlled by parameter values accessible and modifiable through the SPI. Mode 0 - The logic looks at the ratio of resources used by geometry shader waves to the total number of VGPRs available to the shader engine. This information can be used to limit resource usage by geometry shaders within the shader engine. Mode 1 - The logic looks at the ratio of resources used by geometry shaders to the sum of geometry shader resources and pixel shader resources. This information is used to limit the relative resource usage of geometry shaders and pixel shaders. 2. The number of cycles that a pixel shader wave is stalled due to unavailability of resources on a workgroup processor. The style count of a pixel shader is determined as follows: The throttling logic gets the stall signal from the resource allocator logic. The stall counter counts the number of cycles the stall signal is high and generates a stall count that is flopped to the next sample. The flopped stall count is multiplied by a factor of 2 if the pixel shader is wave 64. The maximum value of the stall count is equal to the programmed sample interval for wave 32 pixel shaders, and twice that value for wave 64 pixel shaders. The stall counter is reset to 0 at the time of sampling.
[0025] The graphics pipeline portion 300 may hide some latency within groups of waves emitted from geometry shaders. However, if the actual lifetime of a wave (or corresponding group) exceeds this value, the performance of the graphics pipeline degrades, and geometry shader wave groups begin to block resources for longer durations. Thus, when pixel shader waves are starved for resources, geometry shader groups with longer lifetimes potentially generate longer stalls per pixel than geometry shader groups with shorter lifetimes. Therefore, some embodiments of SPI 301-303 monitor the lifetime of geometry shader groups and compare the lifetime to a threshold. SPI 301-303 generate longer stalls to throttle wave emission from geometry shaders in response to the lifetime of a geometry shader group exceeding the threshold.
[0026] Figure 4 is a block diagram of a portion 400 of a graphics pipeline that selectively emits geometry waves based on resource usage in the graphics pipeline, according to some embodiments. Portion 400 of the graphics pipeline may be used to implement some embodiments of graphics pipeline 200 shown in Figure 1 and portion 300 of the graphics pipeline shown in Figure 3. Portion 400 includes primitive assemblers (PAs) 401, 402, and 403, collectively referred to herein as "PAs 401-403," that receive primitives from corresponding shaders, such as shaders 311-313 shown in Figure 3.
[0027] The primitive hub 405 includes sets 411, 412, 413 of buffers 415 (only one is labeled for clarity), each of which is associated with a corresponding scan converter 421, 422, 423, collectively referred to herein as "scan converters 421, 422, 423." The primitive hub 405 receives primitives from the PAs 401, 403, and stores copies of the primitives in corresponding buffers in each of the sets 411, 412, 413. The primitive hub 405 also monitors the fullness of the buffers 415 and determines whether to throttle wave transmission based on the fullness. In some embodiments, polling logic 425 in the primitive hub 405 polls the buffers 415 in the sets 411, 412, 413 at a programmed interval, such as every 1000 clock cycles, to determine their fullness. A rate limiter 430 in the primitive hub 405 increments the number of dead cycles used to throttle wave submissions for the geometry shader. In some embodiments, the rate limiter 430 uses a first value that indicates the number of dead cycles to add per increment and a second value that indicates the increment step. Thus, with each increment, the number of dead cycles is incremented by the second value, and with each decrement pulse, the dead cycles are decreased by the second value.
[0028] The graphics pipeline portion 400 includes a counter 435 that indicates the number of dead cycles used to selectively throttle wave submission. Some embodiments of the counter 435 are implemented within a corresponding SPI, such as SPIs 301-303 shown in FIG. 3. The primitive hub 405 provides a signal (e.g., backpressure) to the SPI that indicates monitored buffer fullness. In some embodiments, the backpressure is provided on the interface between the primitive hub 405 and the PAs 401-403. The backpressure indicates an estimate of the amount of geometry work waiting to be consumed after culling. For example, the backpressure is communicated as a two-bit status signal communicated from the primitive hub 405 to each SPI. The two bits represent the status of the buffer 415. In some embodiments, the status logic looks at all buffers 415 in the set 411-413 corresponding to each PA 401 and generates a status based on the buffer 415 that has the most entries and is therefore the most "full." As described herein, the SPI can operate in different modes. Table 1 shows the status represented by the status bits in some embodiments. The status logic is replicated for each PA 401-403. [Table 1]
[0029] 5 is a flow diagram of a method 500 for determining counter values for selectively throttling geometry waves based on buffer fullness, according to some embodiments. Method 500 is implemented in some embodiments of processing system 100 shown in FIG. 1, graphics pipeline 200 shown in FIG. 2, portion 300 of processing system shown in FIG. 3, and portion 400 of processing system shown in FIG. 4.
[0030] In block 505, the primitive hub monitors the buffer fullness of a set of FIFO buffers that receive data from one or more primitive assemblers and provide data to one or more scan converters for rasterization. In block 510, the primitive hub generates a status signal based on the buffer fullness. As described herein, the status signal can include a set of bits (e.g., two bits) having values that indicate different ranges of buffer fullness.
[0031] At block 515, the primitive hub provides a status signal to one or more SPIs. At block 520, a counter value is determined based on the status signal. For example, the counter value can be given a value determined based on a range of buffer fullness indicated by the status signal, such that the counter value is incremented by a greater amount when the buffer fullness is greater. As described herein, selective throttling of geometry waves is performed using a counter value determined based on buffer fullness in conjunction with counter values determined based on the relative resource usage of geometry shader waves and pixel shader waves, and counter values determined based on the lifetime of a geometry shader wave or group thereof.
[0032] 6 is a flow diagram of a method 600 for determining a counter value for selectively throttling geometry waves based on the relative resource usage of geometry shader waves and pixel shader waves, according to some embodiments. Method 600 is implemented in some embodiments of processing system 100 shown in FIG. 1, graphics pipeline 200 shown in FIG. 2, portion 300 of processing system shown in FIG. 3, and portion 400 of processing system shown in FIG. 4.
[0033] In block 605, the SPI monitors resource usage by geometry shader waves and pixel shader waves. In the illustrated embodiment, the SPI monitors LDS usage, VGPR usage, or a combination thereof by the geometry shader waves and pixel shader waves. In block 610, the SPI determines relative resource allocations to the geometry shader waves and pixel shader waves based on the LDS usage, VGPR usage, or a combination thereof, as described herein.
[0034] At decision block 615, the SPI determines whether the relative allocation is above a threshold. If so, the method 600 proceeds to block 620, where the SPI increments a value used to set a counter for selectively throttling the sending of geometry shader waves. If the relative allocation is not above the threshold, the method 600 proceeds to block 625, where the SPI maintains the counter at its current value. As described herein, the selective throttling of geometry waves is performed using a counter value determined based on the relative resource usage of the geometry shader waves and pixel shader waves in conjunction with a counter value determined based on buffer fullness at the primitive hub and a counter value determined based on the lifetime of a geometry shader wave or group thereof.
[0035] 7 is a flow diagram of a method 700 for determining a counter value for selectively throttling geometry waves based on the age of a geometry shader wave or a group thereof, according to some embodiments. The method 700 is implemented in some embodiments of the processing system 100 shown in FIG. 1, the graphics pipeline 200 shown in FIG. 2, the portion of the processing system 300 shown in FIG. 3, and the portion of the processing system 400 shown in FIG. 4.
[0036] At block 705, a geometry shader wave (or group of geometry shader waves) is emitted in the graphics pipeline. At block 710, the SPI determines the age of the geometry shader wave (or group), as described herein. At decision block 715, the SPI determines whether the age is above a threshold. If so, the method 700 proceeds to block 720, where the SPI increments a value used to set a counter for selectively throttling the emission of the geometry shader wave. If the age is not above the threshold, the method 600 proceeds to block 725, where the SPI maintains the counter at its current value. As described herein, the selective throttling of the geometry wave is performed using a counter value determined based on the age of the geometry shader wave (or group), in conjunction with a counter value determined based on buffer fullness in the primitive hub and a counter value determined based on the relative resource usage of the geometry shader wave and the pixel shader wave.
[0037] In some embodiments, a geometry shader wave is throttled by adding a stall signal having a predetermined value (e.g., a high value or 1) that is maintained until the stall count reaches another predetermined value, such as 0. While the stall signal remains high, resources are not granted and allocated to the geometry shader wave. The stall count is determined based on FIFO status data generated by the primitive hub, resource usage data generated by the SPI, and the lifespan of the geometry wave. For example, the stall count may be generated by applying an OR operation to select a maximum stall count from the three options disclosed above. In some embodiments, the minimum stall count is set to 0 and a maximum stall count of 1024 is used.
[0038] Throttling by the primitive hub (or based on backpressure generated by the primitive hub) is performed based on the value of a register field that controls the number of dead cycles indicated by the stall counter. The first field indicates the number of dead cycles added when transitioning from a "no throttling" state to a throttled state. The second field indicates the increment or decrement for the dead cycles on each sample. When throttling is enabled and the next geometry shader wave has been granted resources, the stall counter is loaded with the stall count and begins counting down. The number of dead cycles added is determined on a sample basis, but the count is used depending on the next geometry shader wave having been granted resources.
[0039] Throttling by the SPI is determined based on resource usage information, as described herein. In some embodiments, there are multiple triggers for throttling geometry shader wave submissions.
[0040] The first trigger is based on LDS usage by the geometry shader wave. In response to the measured usage exceeding a threshold, geometry shader wave dispatch is throttled. Some embodiments of the trigger generation logic use the following modes: Mode 0 - This mode looks at the LDS usage of the geometry shader group compared to the total LDS available in the shader engine. If this ratio is greater than or equal to a threshold, the first trigger is set. Valid register values are 0-9. This value is multiplied by 10 before the comparison. Mode 1 - This mode looks at the LDS usage of geometry shader waves compared to the total LDS used by geometry shader waves and pixel shader waves in the shader engine. If this ratio is greater than or equal to a threshold, a second trigger is set. Valid register values are 0-9. This value is multiplied by 10 before the comparison. Mode 2 - This mode does not look at usage. The first trigger is always set to this mode. Regardless of GS resource usage, geometry shader wave sending is throttled if PS waves are stalled.
[0041] The second trigger is based on VGPR usage by the geometry shader wave. In response to the measured usage exceeding a threshold, geometry shader wave dispatch is throttled. Some embodiments of the trigger generation logic use the following modes: Mode 0 - This mode looks at the number of VGPRs used by the geometry shader wave and compares it to the total number of VGPRs available in the shader engine. If this ratio is greater than or equal to a threshold, a second trigger is set. Valid register values are 0-9. This value is multiplied by 10 before the comparison. Mode 1 - This mode looks at the number of VGPRs used by the geometry shader wave and compares it to the total number of VGPRs used by the geometry shader wave and pixel shader wave in the shader engine. If this ratio is greater than or equal to a threshold, a second trigger is set. Valid register values are 0-9. This value is multiplied by 10 before the comparison. Mode 2 - This mode does not look at usage. The second trigger is always set to this mode. Regardless of geometry shader resource usage, geometry shader wave dispatch is throttled if pixel shader waves are stalled.
[0042] The third trigger is set based on the average number of cycles that the pixel shader wave is stalled. The number of cycles of the pixel shader wave stall is sampled at a predetermined time interval, for example, after a predetermined number of clock cycles. The third trigger is set when the following condition is met: 1. The current number of pixel shader stall cycles is greater than or equal to the calculated average stall cycles or the maximum sample count. 2. The current number of pixel shader stall cycles is greater than or equal to a threshold. If SPI throttling is enabled, the third trigger is set, and either the first or second trigger is set, the SPI throttle is active. The throttling logic and SPI use register fields that control the number of dead cycles indicated by the stall counter. The first field indicates the number of dead cycles added when transitioning from a "no throttling" state to a throttled state. The second field indicates the increment or decrement for dead cycles on each sample. When throttling is enabled and the next geometry shader wave is granted resources, the stall counter is loaded with the stall count and begins counting down. The number of dead cycles added is determined on a sample-by-sample basis, and the count is used depending on the next geometry shader wave being granted resources.
[0043] 8 shows a first time interval 800 representing a "no throttling" state prior to throttling geometry shader waves, according to some embodiments. In the illustrated embodiment, sampling logic begins sampling. After 100 clock cycles, the sampling logic detects a signal indicating that the FIFO buffer status is at 00 primitives. No throttling is applied.
[0044] Figure 9 shows a second time interval 900 including a transition from unthrottled to throttled for a geometry shader wave, according to some embodiments. After 1000 clocks, the status of the FIFO buffer in the primitive hub changes from 00 to 10. The maximum counter value is set to 256, which is equal to the throttle base * 4. The next geometry shader wave is granted resources after 1200 clocks. This is the first transition from an unthrottled state to a throttled state. The counter starts counting down and stalls until the counter reaches a predetermined value of 0.
[0045] Figure 10 shows a third time interval 1000 including a transition from throttling to no throttling due to a reduction in backpressure from the primitive hub, according to some embodiments. At 3000 clocks, a sample detects a change in the status of the FIFO buffer in the primitive hub from 10 to 01. The maximum counter value is set to 128. The next geometry shader wave is granted at 3100 clocks. The counter begins counting, and stall remains high for 128 clocks.
[0046] 11 illustrates a fourth time interval 1100 in which the transition from throttling to no throttling is complete, according to some embodiments. At 3500 clocks, sampling detects a change in the status of the FIFO buffer in the primitive hub from 01 to 00. The maximum counter value is set to 0. At 3600 clocks, sampling does not detect a change in the status of the FIFO buffer in the primitive hub. The maximum counter value remains 0.
[0047] As disclosed herein, in some embodiments, an apparatus includes a graphics pipeline configured to execute a first shader of a first type and a second shader of a second type; at least one buffer configured to hold primitives generated by the first shader and provide the primitives to the second shader; and a primitive hub configured to monitor at least one fullness of the at least one buffer, wherein emission of waves from the first shader is throttled based on the at least one fullness. In one aspect, the first shader is a geometry shader, the second shader is a pixel shader, and the at least one buffer is a first-in-first-out (FIFO) buffer. In another aspect, the apparatus includes a counter configured to indicate a number of dead cycles; and a shader processor input (SPI) configured to selectively throttle waves emitted by the geometry shader based on the counter. In yet another aspect, the primitive hub is configured to provide a feedback signal to the SPI indicating the at least one fullness, and the first number of dead cycles is determined based on the feedback signal.
[0048] In one aspect, the SPI is configured to determine at least one of a first relative allocation of local data store (LDS) resources to in-flight geometry shader waves and in-flight pixel shader waves and a second relative allocation of vector general purpose registers (VGPRs) to in-flight geometry shader waves and in-flight pixel shader waves. In another aspect, the SPI is configured to determine a second number of dead cycles by comparing the first relative allocation to a first threshold, comparing the second relative allocation to a second threshold, or a combination thereof. In yet another aspect, the SPI is configured to determine a third number of dead cycles based on determining a lifetime of at least one wave emitted by the geometry shader and comparing the lifetime of the at least one wave to at least one third threshold. In yet another aspect, a counter is incremented based on at least one of the first number, second number, and third number of dead cycles, and the counter is decremented at each clock cycle. In yet another aspect, the geometry shader emits a wave in response to the counter having a predetermined value.
[0049] In some embodiments, a method includes executing a first shader of a first type and a second shader of a second type on a graphics pipeline; monitoring at least one fullness of at least one buffer in a primitive hub of the graphics pipeline configured to hold primitives generated by the first shader and provide the primitives to the second shader; and selectively throttling waves emitted from the first shader based on the at least one fullness. In one aspect, the first shader is a geometry shader, the second shader is a pixel shader, and the at least one buffer is a first-in-first-out (FIFO) buffer. In another aspect, the method includes modifying a counter to indicate a number of dead cycles and selectively throttling waves emitted by the geometry shader based on the counter at a shader processor input (SPI). In yet another aspect, the method includes providing a feedback signal from the primitive hub to the SPI to indicate the at least one fullness; and determining a first number of dead cycles based on the feedback signal.
[0050] In one aspect, the method includes determining, in SPI, at least one of a first relative allocation of local data store (LDS) resources to in-flight geometry shader waves and in-flight pixel shader waves and a second relative allocation of vector general purpose registers (VGPRs) to in-flight geometry shader waves and in-flight pixel shader waves. In another aspect, the method includes determining, in SPI, a second number of dead cycles by comparing the first relative allocation to a first threshold, comparing the second relative allocation to a second threshold, or a combination thereof. In yet another aspect, the method includes determining, in SPI, a lifetime of at least one of at least one wave emitted by the geometry shader, and determining a third number of dead cycles based on comparing, in SPI, the lifetime of the at least one wave to at least one third threshold.
[0051] In one aspect, the method includes incrementing a counter based on at least one of a first number, a second number, and a third number of dead cycles, the counter being decremented at each clock cycle. In another aspect, selectively throttling waves emitted by the geometry shader includes emitting waves from the geometry shader in response to the counter having a predetermined value.
[0052] In some embodiments, an apparatus includes: a primitive hub configured to monitor the fullness of at least one of at least one buffer in a graphics pipeline configured to hold primitives generated by a geometry shader and provide the primitives to a pixel shader; and a shader processor input (SPI) configured to selectively throttle waves emitted by the geometry shader based on at least one of a signal from the primitive hub indicating the at least one fullness, an indication of relative resource usage of geometry waves and pixel waves in the graphics pipeline, and an indication of a lifetime of the geometry waves. In one aspect, the signal from the primitive hub includes two bits having values mapped to different ranges of at least one fullness.
[0053] A computer-readable storage medium includes any non-transitory storage medium or 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, magnetic tape, magnetic hard drives), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or flash memory), or micro-electromechanical systems (MEMS)-based storage media. The computer-readable storage medium (e.g., system RAM or ROM) may be internal to the computing system, the computer-readable storage medium (e.g., a magnetic hard drive) may be permanently attached to the computing system, the computer-readable storage medium (e.g., an optical disk or Universal Serial Bus (USB)-based flash memory) may be removably attached to the computing system, or the computer-readable storage medium (e.g., network-accessible storage (NAS)) may be coupled to the computer system via a wired or wireless network.
[0054] In some embodiments, certain aspects of the techniques described above are implemented by one or more processors of a processing system executing software. The software includes one or more sets of executable instructions stored or otherwise tangibly embodied in a non-transitory computer-readable storage medium. The software may include instructions and specific data that, when executed by one or more processors, operate the one or more processors to perform one or more aspects of the techniques 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 flash memory, a cache, a random access memory (RAM), or other non-volatile memory device(s). The executable instructions stored on the non-transitory computer-readable storage medium may be implemented as source code, assembly language code, object code, or other form of instructions that can be interpreted or otherwise executed by one or more processors.
[0055] In addition to the above, it should be noted that not all activities or elements described in the summary description are required, that some of the particular activities or devices may not be required, that one or more additional activities may be performed, and that one or more additional elements may be included. Furthermore, the order in which the activities are listed is not necessarily the order in which they are performed. Also, the concepts have been described with reference to specific embodiments. However, those skilled in the art will recognize that various modifications and variations can be made without departing from the scope of the invention as set forth in the claims. Accordingly, the specification and drawings should be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present invention.
[0056] Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and features from which any benefit, advantage, or solution may arise or be manifested are not construed as critical, essential, or essential features of any or all claims. Moreover, the specific embodiments described above are illustrative only, since the disclosed invention may be modified and practiced in different, but similar manners apparent to those skilled in the art having the benefit of the teachings herein. No limitations are intended to the details of construction or design herein shown, other than as described in the appended claims. It is therefore apparent that the specific embodiments described above may be altered or modified, and that all such variations are considered within the scope of the disclosed invention. Accordingly, the protection sought herein is set forth in the appended claims.
Claims
1. 1. An apparatus comprising: a graphics pipeline configured to execute a first shader of a first type and a second shader of a second type; at least one buffer configured to hold primitives generated by the first shader and provide the primitives to the second shader; a primitive hub configured to monitor the fullness of at least one of the at least one buffer; wave emission from the first shader is throttled based on the at least one fullness and a relative allocation of resources between the first shader and the second shader; Device.
2. the first shader is a geometry shader, the second shader is a pixel shader, and the at least one buffer is a first-in-first-out (FIFO) buffer.
10. The apparatus of claim 1.
3. a counter configured to indicate a number of dead cycles; a shader processor input (SPI) configured to selectively throttle waves emitted by the geometry shader based on the counter.
3. The apparatus of claim 2.
4. the primitive hub is configured to provide a feedback signal to the SPI indicative of the at least one fullness, and the first number of dead cycles is determined based on the feedback signal.
4. The apparatus of claim 3.
5. the SPI is configured to determine at least one of a first relative allocation of local data store (LDS) resources to in-flight geometry shader waves and in-flight pixel shader waves, and a second relative allocation of vector general purpose registers (VGPRs) to the in-flight geometry shader waves and the in-flight pixel shader waves; 5. The apparatus of claim 4.
6. the SPI is configured to determine a second number of dead cycles by comparing the first relative allocation to a first threshold, comparing the second relative allocation to a second threshold, or a combination thereof.
6. The apparatus of claim 5.
7. the SPI is configured to determine a third number of dead cycles by determining a lifetime of at least one wave emitted by the geometry shader and comparing the lifetime of the at least one wave with at least one third threshold.
7. The apparatus of claim 6.
8. the counter is incremented based on at least one of the first number, the second number, and the third number of dead cycles, and the counter is decremented on each clock cycle; 8. The apparatus of claim 7.
9. The geometry shader emits a wave in response to the counter having a predetermined value.
9. The apparatus of claim 8.
10. 1. A method comprising: executing a first shader of a first type and a second shader of a second type on a graphics pipeline; monitoring the fullness of at least one buffer in a primitive hub of the graphics pipeline configured to hold primitives generated by the first shader and provide the primitives to the second shader; selectively throttling waves emitted from the first shader based on the at least one fullness and a relative allocation of resources between the first shader and the second shader. method.
11. the first shader is a geometry shader, the second shader is a pixel shader, and the at least one buffer is a first-in-first-out (FIFO) buffer. The method of claim 10.
12. modifying the counter to indicate the number of dead cycles; and selectively throttling the waves emitted by the geometry shader based on the counter at a shader processor input (SPI). The method of claim 11.
13. providing a feedback signal from the primitive hub to the SPI to indicate the at least one fullness; determining a first number of dead cycles based on the feedback signal.
13. The method of claim 12.
14. determining, in the SPI, at least one of a first relative allocation of local data store (LDS) resources to in-flight geometry shader waves and in-flight pixel shader waves, and a second relative allocation of vector general purpose registers (VGPRs) to the in-flight geometry shader waves and the in-flight pixel shader waves; 14. The method of claim 13.
15. determining a second number of dead cycles in the SPI by comparing the first relative allocation to a first threshold, comparing the second relative allocation to a second threshold, or a combination thereof; 15. The method of claim 14.
Citation Information
Patent Citations
Synchronization of shader behavior
JP2014521183A
Techniques for safely and efficiently enqueueing and dequeueing data on a graphics processor
US20200004460A1