Hull shader throttling based on tessellation factor in the graphics pipeline
By selectively throttling thread groups from hal shaders based on resource consumption measurements, the graphics processing pipeline achieves a balance between hal and domain shader resources, enhancing performance and preventing resource depletion.
Patent Information
- Application Number
- JP2023535510
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2020-12-15
- Filing Date
- 2021-12-01
- Publication Date
- 2025-03-25
- Estimated Expiration
- 2041-12-01
AI Technical Summary
The existing graphics processing pipeline faces challenges in maintaining a balance between the resources consumed by hal shaders and domain shaders, leading to potential degradation in performance due to static limits on computing units and inefficient resource allocation.
A system and technique are introduced to selectively throttle the initiation of thread groups from hal shaders based on measurements of resource consumption by both hal and domain shaders, using counters to estimate the primitive start time interval and adjust accordingly.
This approach effectively balances resource usage between hal and domain shaders, improving the overall performance of the graphics pipeline by preventing resource depletion and optimizing the processing of higher-order geometry primitives.
Smart Images

Figure 0007650980000001 
Figure 0007650980000002 
Figure 0007650980000003
Abstract
Description
[Background technology]
[0001] A graphics processing unit (GPU) implements a graphics processing pipeline that simultaneously processes copies of commands taken from a command buffer. The graphics pipeline includes one or more shaders that execute using the resources of the graphics pipeline and one or more fixed-function hardware blocks. The graphics pipeline is typically divided into a geometry portion that performs geometry operations on patches or other primitives, such as triangles, formed from vertices and edges and representing portions of an image. Shaders in the geometry portion may include vertex shaders, hull 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 the portion of the image. Subsequent processing on the pixels is called pixel processing and includes operations performed by shaders, such as pixel shaders, that execute using the resources of the graphics pipeline. GPUs and other multi-threaded 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 description of the drawings]
[0003] [Figure 1]FIG. 1 is a block diagram of a processing system according to some embodiments. [Diagram 2] FIG. 2 illustrates a graphics pipeline capable of processing high-order geometric primitives to generate a rasterized image of a three-dimensional (3D) scene at a given resolution, according to some embodiments. [Diagram 3] FIG. 2 is a block diagram of a first portion of a processing system that selectively throttles thread groups initiated by a hull shader circuit, according to some embodiments. [Figure 4] FIG. 13 is a block diagram of a second portion of a processing system that selectively throttles thread groups initiated by a hull shader circuit, according to some embodiments. [Diagram 5] FIG. 11 is a flow diagram of a first portion of a method for estimating primitive start time intervals for a domain shader using total and error counts in accordance with some embodiments. [Figure 6] FIG. 11 is a flow diagram of a second portion of a method for estimating a primitive start time interval for a domain shader using a total count and an error count in accordance with some embodiments. [Figure 7] FIG. 13 is a flow diagram of a method for selectively throttling wave initiation from a hull shader, according to some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0004] A hull shader circuit in the geometry portion of the graphics pipeline initiates waves of control points for patches that are processed by the hull shader. The hull shader also generates tessellation factors that indicate subdivisions of the patches. The patches and tessellation factors processed by the hull shader are passed to a tessellator in the graphics pipeline. The tessellator uses the tessellation factors to subdivide the patches into other primitives, such as triangles, before processing the tessellated primitives in the domain shader. Thus, a domain shader typically processes a larger number of primitives than a hull shader. For example, if the tessellation factor is 16 for a quad patch processed by the hull shader, the domain shader processes 512 triangles in response to receiving a patch from the hull shader. Patches are initiated by the hull shader circuit based on a greedy algorithm that attempts to use as many resources of the graphics pipeline as possible. Initiating hull shader waves based on a greedy algorithm can starve a domain shader of resources required to process tessellated primitives. Some graphics pipelines are configured to limit the number of waves in flight by constraining the number of compute units that can be allocated to a hull shader to process waves. However, a static limit on the number of available compute units can degrade the performance of a graphics pipeline when there is little or no amplification of primitives initiated by the hull shader, for example when the tessellation factor is less than or equal to 1.
[0005] 1-7 disclose systems and techniques for maintaining a balance between graphics pipeline resources consumed by a first shader and a second shader by selectively initiating waves from the first shader based on measurements 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 hull shader and the second shader is a domain shader that receives primitives from a tessellator. The hull shader generates tessellation factors, and the tessellator subdivides (or tessellates) the primitives based on the tessellation factors to generate a plurality of higher resolution primitives. The tessellation factors of the patches initiated by the hull shader circuitry are held in a buffer that provides the primitives to the domain shader. The throttling circuitry uses the tessellation factors to estimate the time interval required by the domain shader to initiate all primitives from the domain shader, e.g., the number of cycles required to process the higher resolution primitives in the domain shader. This time interval is referred to herein as the "primitive start time interval." Some embodiments of the throttling circuit include a bank of registers that store information indicating the number of high-resolution primitives (or cycles required to process high-resolution primitives) for a wave associated with a corresponding entry in the buffer. The stored information is used to set a value of a counter representing the primitive start time interval for the domain shader. For example, a sum counter is incremented by the number of cycles estimated to process the high-resolution primitives in the registers associated with the buffer entry that are written to the tessellator for processing. The sum counter is iteratively decremented (by the estimated primitive processing rate of the domain shader start logic) in response to the domain shader start logic completing processing of the higher resolution primitives associated with the patch.In some embodiments, an error counter is used to modify the sum counter based on a measurement of the actual time required to process a primitive in the domain shader before starting from the domain shader. The value of the error counter is increased in response to a measured latency, e.g., greater than the latency corresponding to the value of the sum counter, due to back pressure on the domain shader. The value of the error counter is decreased (or set to 0) in response to a measured processing time being less than or equal to the value of the sum counter. The combined sum and error counters are then decremented based on the tessellation factor of the completed patch. Waves are selectively started from the hull shader based on the value of the sum counter and the value of the error counter, if any.
[0006] 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 components implemented using a non-transitory computer-readable storage medium, such as Dynamic Random-Access Memory (DRAM). However, in some cases, the memory 105 can 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 outside of the processing unit implemented in the processing system 100. The processing system 100 also includes a bus 110 to support 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.
[0007] The techniques described herein may be utilized in various embodiments 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, in particular 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 computation units (CUs) 121, 122, 123 (collectively referred to herein as "computation units 121-123") that execute instructions simultaneously or in parallel. In some embodiments, the computation units 121-123 include one or more single instruction multiple data (SIMD) units, and the computation units 121-123 are aggregated into a workgroup processor, a shader array, a shader engine, or the like. The number of computation 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 computation units than shown in FIG. 1. The computation units 121-123 may 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.
[0008] The processing system 100 also includes a central processing unit (CPU) 130 connected to the bus 110 and thus in communication with the GPU 115 and the memory 105 via the bus 110. The CPU 130 implements multiple processor cores 131, 132, 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 are 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 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 the CPU 130 include multiple processor cores (not shown in FIG. 1 for clarity) that independently execute instructions simultaneously or in parallel.
[0009] An Input / Output (I / O) engine 145 handles input or output operations associated with the display 120 and other elements of the processing system 100, such as a keyboard, a mouse, a printer, an external disk, etc. The I / O engine 145 is coupled to the bus 110 such that the I / O engine 145 communicates with the memory 105, the GPU 115, or the CPU 130. In the illustrated embodiment, the I / O engine 145 reads information stored on an external storage component 150, which is implemented using a non-transitory computer-readable storage medium, such as a Compact Disk (CD), a Digital Video Disc (DVD), etc. The I / O engine 145 can also write information, such as results of processing by the GPU 115 or the CPU 130, to the external storage component 150.
[0010] Processing system 100 implements pipeline circuitry for executing instructions in multiple stages of a pipeline. The pipeline circuitry is implemented in some embodiments in compute units 121-123 or processor cores 131-133. In some embodiments, the pipeline circuitry 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. Some embodiments of processing system 100 include a hull shader circuit that initiates a thread group that includes one or more primitives. For example, compute units 121-123 in GPU 115 may be used to implement hull shader circuitry, as well as circuits for other shaders and throttling of wave initiation, as described herein. The hull shader circuitry also generates tessellation factors that indicate subdivision of primitives. A throttling circuit within the processing system 100 estimates a primitive start time interval for the domain shader based on the tessellation factor and selectively throttles the initiation of thread groups from the hull shader circuit based on the domain shader latency and the hull shader latency. In some cases, the throttling circuit includes a first counter that is incremented in response to initiating the thread group from the buffer and a second counter that modifies the first counter based on the measured latency of the domain shader.
[0011] 2 illustrates a graphics pipeline 200 capable of processing high-order geometric primitives to generate a rasterized image of a three-dimensional (3D) scene at a given resolution, according to some embodiments. The graphics pipeline 200 is implemented in some embodiments of the processing system 100 illustrated in FIG. 1. The illustrated embodiment of the graphics pipeline 200 is implemented according to the DX11 specification. Other embodiments of the graphics pipeline 200 are implemented according to other Application Programming Interfaces (APIs), such as Vulkan, Metal, DX12, etc. The graphics pipeline 200 is subdivided into a geometry processing unit 201, which comprises the portion of the graphics pipeline 200 before rasterization, and a pixel processing unit 202, which comprises the portion of the graphics pipeline 200 after rasterization.
[0012] Graphics pipeline 200 has access to 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 load 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.
[0013] An 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 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 geometry processing section 201 of graphics pipeline 200.
[0014] Vertex shader 215, 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.
[0015] The hull shader 218 operates on input high-order patches or control points used to define the input patches. The hull shader 218 outputs tessellation coefficients and other patch data, such as control points of the patches, that are processed in the hull shader 218. The tessellation coefficients are stored in storage resources 205 so that they may be accessed by other entities in the graphics pipeline 200. In some embodiments, the primitives generated by the hull shader 218 are provided to a tessellator 220. The tessellator 220 receives objects (such as patches) from the hull shader 218 and generates information identifying primitives that correspond to the input objects, e.g., by tessellating the input objects based on the tessellation coefficients generated by the hull shader 218. The tessellation subdivides the input high-order primitives, such as patches, into a set of lower-order output primitives that represent finer levels of detail, e.g., as indicated by tessellation coefficients that specify the granularity of the primitives generated by the tessellation process. Thus, a model of the scene is represented by a smaller number of higher order primitives (to save memory or bandwidth) and additional detail is added by tessellating the higher order primitives.
[0016] The domain shader 224 inputs the domain location and (optionally) other patch data. The 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, the domain shader 224 generates primitives 222 based on the triangles 211 and tessellation factors. The domain shader 224 starts the primitives 222 upon completion of processing. The geometry shader 226 receives input primitives from the domain shader 224 and outputs up to four primitives (per input primitive) generated by the geometry shader 226 based on the input primitives. In the illustrated embodiment, the geometry shader 226 generates output primitives 228 based on the tessellated primitives 222.
[0017] 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 in storage resources 205. Scan converter 230 performs shading operations and other operations such as clipping, perspective division, cutting, and viewport selection. Scan converter 230 produces a set of pixels 232 that are subsequently processed in pixel processing unit 202 of graphics pipeline 200.
[0018] 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.
[0019] 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.
[0020] 3 is a block diagram of a first portion of a processing system 300 for selectively throttling thread groups initiated by a hull shader circuit, according to some embodiments, which may be implemented in some embodiments of the processing system 100 shown in FIG.
[0021] A set of buffers 301, 302, 303, 304 (collectively referred to herein as "buffers 301-304") are used to store metadata associated with thread groups initiated by a hull shader circuit, such as hull shader 218 shown in FIG. 2. Buffers 301-304 are associated with different hull shader circuits (not shown in FIG. 3 for clarity) that initiate a thread group that includes one or more waves of primitives, such as a patch. In response to initiating a thread group for execution on a compute unit or SIMD, the hull shader circuit provides the metadata associated with the thread group to a corresponding one of buffers 301-304. Thus, each entry in buffers 301-304 includes metadata for the corresponding thread group.
[0022] The buffers 301-304 are associated with sets of counters 311, 312, 313, 314 (collectively referred to herein as "counter sets 311-314") having values that represent measured time intervals or latencies for processing the corresponding thread groups in the hull shader. Each of the counters in the counter sets 311-314 is associated with an entry in a corresponding one of the buffers 301-304. For example, the first counter in the counter set 311 is associated with the first entry in the buffer 301. The counters begin counting (e.g., incrementing or decrementing) when metadata is added to the corresponding entry in one of the buffers 301-304 in response to the hull shader circuitry starting the thread group.
[0023] Another set of buffers 321-324 has entries that store values indicating that a corresponding thread group has completed processing. For example, an entry in buffer 321 is written in response to a thread group initiated by a corresponding hull shader circuit completing execution on a compute unit. An entry in a buffer is used to stop counting by a corresponding counter in one of counter sets 311-314. The counter thus holds a value that represents a measured latency of the thread group, for example, as a number of cycles used to process the thread group. A subset of the values of the counters in counter sets 311-314 are provided to a second portion of processing system 300 via node 1, as described herein with respect to FIG. 4.
[0024] Arbiter 330 selects thread group metadata from buffers 301-304 in the order in which the thread groups are dispatched by the hull shader circuitry. For example, if a first thread group is dispatched by a hull shader circuitry associated with buffer 301 and then a second thread group is dispatched by a hull shader circuitry associated with buffer 302, arbiter 330 selects the thread group metadata from buffer 301 before selecting the thread group metadata from buffer 302. Arbiter 330 provides the metadata associated with the thread groups to a circuit that fetches tessellation factors for the thread groups via node 2, as described herein with respect to FIG.
[0025] 4 is a block diagram of a second portion of a processing system 300 that selectively throttles thread groups initiated by a hull shader circuit, according to some embodiments, which may be implemented in some embodiments of the processing system 100 shown in FIG.
[0026] A second portion of the processing system 300 shown in FIG. 4 includes a circuit 405 that fetches tessellation coefficients from memory 410 and performs processing on the tessellation coefficients and metadata received from the arbiter 330 shown in FIG. 3. Processing the metadata received from the arbiter 330 includes parsing the received thread group to identify the primitives (e.g., patches) that are included in the thread group. The patches, tessellation coefficients and associated metadata are then provided to a buffer 415. Each entry in the buffer 415 includes a patch and its associated tessellation coefficients and metadata. The information in the entries of the buffer 415 is then provided to a patch distributor 420 that distributes the information to output buffers associated with one or more tessellators (e.g., tessellator 220 shown in FIG. 2) and domain shaders (e.g., domain shader 224 shown in FIG. 2).
[0027] Circuit 405 also provides tessellation factors for primitives or patches in the thread group to registers 425 in hull shader throttle circuit 430. Each register in set of registers 425 stores an estimate of the number of primitives (e.g., triangles) generated from a patch based on the value of the tessellation factor applied to the patch for the thread group in the corresponding entry of buffer 415. Hull shader throttle circuit 430 also includes two counters used to throttle thread groups initiated from the hull shader. A first counter 435 has a value of a total count that represents a primitive initiation time interval for a domain shader circuit, e.g., a time interval used by a domain shader to process and initiate a set of primitives associated with one or more primitives provided by the hull shader. The first counter 435 is incremented in response to providing a patch (and associated tessellation factors and metadata) from buffer 415 to patch distributor 420. In some embodiments, the first counter 435 is incremented by an amount indicated by a corresponding register in set of registers 425. For example, the first counter 435 may be incremented by the number of primitives or patches in the register that corresponds to the patch provided from the entry in the buffer 415 .
[0028] A second counter 440 in the hull shader throttle circuit 430 has a value representing an error count indicating the difference between the measured downstream latency for the patch (e.g., the time interval for processing primitives by a domain shader) and the predicted downstream primitive start time interval as indicated by the tessellation factor, e.g., the number of primitives generated from the patch based on the tessellation factor. In some embodiments, the second counter 440 is incremented or decremented based on whether a read enable signal associated with the thread group arrives before or after the second counter 440 counts down to a predetermined value, such as 0. As described herein, the value in the second counter 440 is used to modify the first counter 435 based on the measured domain shader latency such that the value in the first counter 435 indicates the primitive start time interval required by the domain shader to process primitives after tessellation.
[0029] The hull shader throttling circuit 430 determines the latency of the hull shader based on the value of a counter indicating the measured latency of the thread groups initiated from the hull shader. The counter value is received from a register associated with the shader engine that processes primitives in the hull shader (via node 1), e.g., from the values in the counters in the counter set 311-314 shown in FIG. 3. In the illustrated embodiment, the counter value indicates the latency as the number of clock cycles required to process the corresponding thread group. The comparison circuit 445 retrieves a predetermined number of counter values, such as eight counter values for the last eight thread groups initiated by the hull shader, and uses the retrieved values to determine the average latency of the hull shader. The latency comparison circuit 445 compares the average latency of the hull shader to the primitive initiation time interval of the domain shader, as indicated by the total count in the first counter 435. The hull shader throttling circuit 430 then selectively throttles the initiation of thread groups from the hull shader circuit based on the comparison, as described herein.
[0030] Figure 5 is a flow diagram of a first portion of a method 500 for estimating primitive start time intervals for a domain shader using total and error counts, according to some embodiments. The method 500 is implemented in some embodiments of the processing system 100 shown in Figure 1, the graphics pipeline 200 shown in Figure 2, and the processing system 300 shown in Figures 3 and 4. In the illustrated embodiment, a throttling circuit is used to implement the method 500.
[0031] In block 505, the throttling circuit intercepts the write data for the thread group before it is written to a FIFO buffer, such as buffer 415 shown in Figure 4. The throttling circuit uses this information to estimate the number of primitives being generated based on the tessellation factors (tf1, tf2) associated with the thread group. For example, the number of primitives is equal to: 2*inside_tf1*inside_tf2 (for quad patches) floor(1.5*inside_tf1^2) (for triangles) factor1*factor2 (for contour lines) The number of primitives is then stored in a register that corresponds to an entry in the FIFO buffer used to store thread group data, such as one of registers 425 shown in FIG.
[0032] At block 510, a first counter indicating a total count is incremented by the number of primitives for which the corresponding thread group is being written. In the first read operation, a second counter indicating an error count is loaded with a value equal to the number of primitives at the current position in the buffer.
[0033] A first counter (total count) and a second counter (error count) begin counting down (or decrementing) at block 515. In some embodiments, the first and second counters count down by the product of the primitive rate of the tessellator and the number of tessellators.
[0034] At decision block 520, the throttling circuit determines whether the value of the second counter (the error count) reached 0 before the throttling circuit received a read enable signal. If so, the method 500 proceeds to block 540. If the second counter reached 0 before receiving a read enable signal indicating that the domain shader primitive start time interval is underestimated, the method 500 proceeds to block 525.
[0035] In block 525, the throttling circuit increments a second counter (error count) at each clock cycle until a read enable signal is received. If the value of the second counter reaches a maximum value, the value of the second counter is clamped to the maximum value to prevent the second counter from rolling over. In block 530, the throttling circuit receives a read enable signal. In block 535, the throttling circuit adds the value of the second counter to the current value of the first counter. Method 500 then proceeds to block 515.
[0036] In block 540, the throttling circuit receives a read enable signal before the value of the second counter reaches 0. The method 500 then proceeds to node 1, which connects block 540 to decision block 605 of FIG.
[0037] 6 is a flow diagram of a second portion of a method 500 for estimating primitive start time intervals for a domain shader using total and error counts according to some embodiments. Decision block 605 is connected to block 540 of FIG. 5 via node 1.
[0038] In decision block 605, the throttling circuit determines whether the error count is equal to 0 if a read enable signal is received. If so, the method 500 proceeds to block 610 where the next location is loaded into a second counter. The method 500 then proceeds to block 515 of FIG. 5 via node 2.
[0039] If the error count is not equal to 0 when the read enable signal is received, i.e., if the value of the error count is greater than 0, the method 500 proceeds to block 615. An error count greater than 0 indicates that the domain shader primitive start time interval is overestimated. Thus, in block 615, the throttling circuit subtracts the value of the second counter from the value of the first counter (the total count). The method 500 then proceeds to block 515 of FIG. 5 via node 2.
[0040] The first counter thus has a value indicative of the number of cycles between a thread group write and receipt of a subsequent read enable signal. The total count in the first counter thus indicates the total domain shader time / latency required to process primitives in the thread group that are generated after tessellation. The total count may thus be used to compare the domain shader latency to the hull shader latency and selectively throttle the initiation of waves from the hull shader to maintain a balance between the rates of thread group consumption in the hull shader and the domain shader.
[0041] Figure 7 is a flow diagram of a method 700 for selectively throttling wave initiation from a hull shader according to some embodiments. The method 700 is implemented in some embodiments of the processing system 100 shown in Figure 1, the graphics pipeline 200 shown in Figure 2, and the processing system 300 shown in Figures 3 and 4. In the illustrated embodiment, a throttling circuit is used to implement the method 500.
[0042] At block 705, the throttling circuit determines a total count indicated by a first counter in the throttling circuit that indicates a primitive start time interval for the domain shader. At block 710, the throttling circuit determines, for example, an average hull shader latency using values of counters associated with thread groups processed by the shader engine as described herein.
[0043] At decision block 715, the throttling circuit compares the total count to the hull shader latency to determine whether the total count is greater than 8 times the hull shader latency. If so, the comparison indicates that the hull shader is executing ahead of the domain shader and should be throttled. Thus, method 700 proceeds to block 720, where the hull shader is throttled to allow two in-flight thread groups per shader engine. If the total count is less than or equal to 8 times the hull shader latency, method 700 proceeds to decision block 725.
[0044] At decision block 725, the throttling circuit compares the total count to the hull shader latency to determine whether the total count is greater than four times the hull shader latency. If so, the comparison indicates that the hull shader is running ahead of the domain shader, but not as far ahead as if the total count were greater than eight times the hull shader latency. Nevertheless, the hull shader should be throttled. Thus, method 700 proceeds to block 730, where the hull shader is throttled to allow four in-flight thread groups per shader engine. If the total count is less than or equal to four times the hull shader latency, method 700 proceeds to decision block 735.
[0045] At decision block 735, the throttling circuit compares the total count to the hull shader latency to determine whether the total count is greater than twice the hull shader latency. If so, the comparison indicates that the hull shader is running ahead of the domain shader, but not as far ahead as if the total count were greater than four times the hull shader latency. Nevertheless, the hull shader should be throttled. Thus, method 700 proceeds to block 740, where the hull shader is throttled to allow eight in-flight thread groups per shader engine. If the total count is less than or equal to twice the hull shader latency, method 700 proceeds to block 745, where hull shader throttling is disabled.
[0046] 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.
[0047] 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 the 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 a flash memory, a cache, a random access memory (RAM), or other non-volatile memory device(s), etc. The executable instructions stored in 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.
[0048] In addition to the above, it should be noted that not all activities or elements described in the summary description are required, some of the specific activities or devices may not be required, one or more additional activities may be performed, and 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 appreciate that various changes and modifications can be made without departing from the scope of the invention as set forth in the claims. Thus, 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 invention.
[0049] Benefits, other advantages, and solutions to problems have been described above with respect to specific embodiments. However, the benefits, advantages, solutions to problems, and features by which any benefit, advantage, or solution may occur or be manifested are not to be construed as critical, essential, or essential features of any or all claims. Moreover, the specific embodiments described above are illustrative only, as 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 set forth in the appended claims. It is therefore apparent that the specific embodiments described above may be altered or modified, and all such variations are considered to be within the scope of the disclosed invention. Accordingly, the protection sought herein is set forth in the appended claims.
Claims
1. An apparatus comprising: a processor configured to estimate a primitive start time interval of a domain shader circuit based on tessellation factors generated by a hull shader circuit, and to throttle start of thread groups of the hull shader circuit based on the primitive start time interval. Device.
2. The hull shader circuit further comprises: the hull shader circuitry is configured to initiate the thread group including one or more primitives and generate tessellation factors indicative of a subdivision of the one or more primitives.
2. The apparatus of claim 1.
3. a tessellator configured to subdivide the one or more primitives into higher resolution primitives based on the tessellation factors.
3. The apparatus of claim 2.
4. the processor is configured to estimate a number of cycles for processing the higher resolution primitive in the domain shader circuit based on the tessellation factor, and to estimate the primitive start time interval based on the number of cycles.
4. The apparatus of claim 3.
5. a buffer including entries configured to store the thread groups initiated by the hull shader circuit; a set of registers corresponding to the entry in the buffer, the set of registers storing information indicating the primitive start time interval estimated for the thread group in the entry.
5. The apparatus of claim 4.
6. each register in the set of registers is configured to store information indicative of at least one of: a number of the higher resolution primitives in the thread group associated with the register; and a number of cycles required to process the higher resolution primitives in the thread group associated with the register.
6. The apparatus of claim 5.
7. a first counter that is incremented in response to starting a thread group from the buffer, the first counter being incremented by an amount indicated by a corresponding register in the set of registers; a second counter configured to modify the first counter based on the measured latency of the domain shader circuit.
7. The apparatus of claim 6.
8. the first counter indicates the primitive start time interval for the domain shader circuitry to process primitives after subdividing the one or more primitives into the higher resolution primitives based on the tessellation factor; 8. The apparatus of claim 7.
9. the second counter is incremented or decremented based on whether a read enable signal associated with the thread group arrives before or after the second counter counts down to zero.
9. The apparatus of claim 8.
10. The processor is configured to throttle initiation of thread groups of the hull shader circuitry based on a latency of the hull shader circuitry.
2. The apparatus of claim 1.
11. The processor is configured to determine the latency of the hull shader circuit based on a value of a counter indicating a number of primitives in the thread group that have been initiated from the hull shader circuit.
11. The apparatus of claim 10.
12. The processor is configured to determine a number of thread groups to be initiated by the hull shader circuit based on a comparison of the primitive start time interval of the domain shader circuit and the latency of the hull shader circuit.
12. The apparatus of claim 11.
13. 1. A method comprising: estimating a primitive start time interval for a domain shader circuit based on a thread group including one or more primitives and a tessellation factor generated by a hull shader circuit; throttling subsequent thread group initiation from the hull shader circuitry based on the primitive initiation time interval. method.
14. and further comprising subdividing the one or more primitives into higher resolution primitives based on the tessellation factors.
14. The method of claim 13.
15. estimating a number of cycles for processing the higher resolution primitive in the domain shader circuit based on the tessellation factor; and estimating the primitive start time interval based on the cycle number.
15. The method of claim 14.
16. storing a thread group initiated by the hull shader circuit in an entry of a buffer; storing information in a set of registers corresponding to the entry in the buffer indicating the primitive start time interval estimated for the thread group in the entry in the buffer.
16. The method of claim 15.
17. storing, in each register in the set of registers, information indicative of at least one of: a number of the higher resolution primitives in a thread group associated with the register; and a number of cycles required to process the higher resolution primitives in the thread group associated with the register.
17. The method of claim 16.
18. throttling the initiation of subsequent thread groups from the hull shader circuit is additionally based on a latency of the hull shader circuit.
14. The method of claim 13.
19. determining the latency of the hull shader circuit based on a value of a counter indicating a number of primitives in a thread group initiated from the hull shader circuit.
20. The method of claim 18.
20. An apparatus comprising: a set of registers configured to store information indicative of an estimated domain shader circuit latency for a thread group initiated by the hull shader circuit and stored in a buffer based on tessellation factors generated by the hull shader circuit; a first counter incremented in response to starting a thread group from the buffer, the first counter having a total count value representative of a primitive start time interval of the domain shader circuit; a second counter having a value based on a measured latency of the domain shader circuit, the value of the second counter being used to modify the first counter; a comparison circuit configured to throttle initiation of thread groups from the hull shader circuit based on the primitive initiation time interval. Device.
Citation Information
Patent Citations
Scalable parallel tessellation
EP3594905A1
Multiple World-Space Pipeline Shader Stages
JP2019535071A
Off Chip Memory for Distributed Tessellation
US20130169634A1