Pixel wave attribute initialization

Abstract

A technique is described for avoiding the reinitialization of attributes of consecutive redundant pixel waves (301, 302, 303) when rendering graphical primitives (105, 110). The attributes of the first primitive are read from the parameter cache (240) and the first pixel wave is initialized. The attributes are stored in a block of the local datastore (250) associated with the compute unit (245) that renders the pixel wave. A tracking array is maintained to indicate the local datastore block that stores the attributes. When a second pixel wave associated with the first primitive is detected, the reading of the attributes is omitted based on the tracking array.

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims the priority of U.S. Patent Application No. 63 / 524748, filed on July 3, 2023, and U.S. Patent Application No. 18 / 478774, filed on September 29, 2023, both entitled "PIXEL WAVE ATTRIBUTE INITIALIZATION", the entire contents of which are incorporated herein by reference.

Background Art

[0002] In computer graphics processing, a primitive is a basic geometric entity that forms the smallest constituent elements of a graphic image. Examples of primitives include points, lines, and triangles. During the rendering process of a graphic image, primitives are associated with one or more pixels, which are the smallest controllable elements of the picture represented on the screen. The color, position, and other characteristics of these pixels determine the appearance of the primitive. A Graphics Processing Unit (GPU) processes these primitives during the rendering process to generate the final graphical output seen on the display.

[0003] A pixel wave represents a group of pixels that are processed together in parallel on a GPU, allowing the GPU to process many pixels at once to optimize speed and efficiency. To facilitate such processing, the pixels being processed may be grouped into a "wave." Each pixel within a pixel wave undergoes the same operation, such as through the execution of a pixel shader program (a type of computer program often used in 3D computer graphics to determine the final color of pixels in a rendered image). This approach to parallel processing leverages the fact that operations on pixels often involve similar calculations, enabling the GPU to process graphics data much faster and more efficiently than in sequential processing.

[0004] However, managing these pixel waves presents challenges in terms of resource utilization and power efficiency, particularly when dealing with large primitives that cover a significant portion of the display frame. Storing and initializing the pixel attributes of each wave can lead to redundancy and unnecessary power consumption, highlighting the need for improved techniques in pixel wave management. [Overview of the project] [Problems that the invention aims to solve]

[0005] The techniques described herein leverage common local data storage used by consecutive pixel waves associated with the same large primitive to avoid reinitializing the attributes of those consecutive pixel waves. In a first example, the method includes reading one or more attributes of a first primitive from a parameter cache to initialize a first pixel wave using one or more attributes, and, depending on whether a second pixel wave is determined to be associated with the first primitive, omitting reading one or more attributes from the parameter cache to initialize a second pixel wave.

[0006] In some embodiments, initializing a first pixel wave includes storing one or more attributes read from a parameter cache in one or more blocks of a local data store (LDS) associated with a compute unit allocated to render the first pixel wave. The method may further include maintaining a tracking array that indicates one or more LDS blocks in which the one or more attributes are stored. Maintaining the tracking array may include storing the tracking array in a parameter cache. In other embodiments, maintaining the tracking array includes setting bit values ​​at locations in the tracking array that correspond to LDS blocks in which at least one of the one or more attributes of the first primitive is stored.

[0007] The method may further include rendering a first pixel wave and a second pixel wave using one or more attributes stored in an LDS block. Determining that the second pixel wave is associated with the first primitive may include comparing the parameter cache addresses of one or more vertices associated with the second pixel wave with the parameter cache addresses of one or more vertices associated with the first primitive. In some embodiments, the method further includes identifying the first primitive as a large primitive based on at least one of the number of pixels associated with the first primitive, the amount of shader operation required to render the first primitive, and the amount of memory required to store the attributes associated with the first primitive.

[0008] In another example, the processing unit includes a parameter cache and a scheduling circuit configured to read one or more attributes of a first primitive from the parameter cache, initialize a first pixel wave using one or more attributes, and, depending on whether it is determined that a second pixel wave is associated with the first primitive, to omit reading one or more attributes from the parameter cache to initialize the second pixel wave.

[0009] The processing unit may further include a plurality of compute units, each associated with a local data store (LDS), and initializing the first pixel wave includes storing one or more attributes read from a parameter cache in one or more blocks of the LDS associated with any of the plurality of compute units, where one compute unit is any of the one or more compute units allocated to render the first pixel wave.

[0010] In some embodiments, the processing unit further includes a tracking array for storing one or more indicators of one or more LDS blocks, each storing one or more attributes. The scheduling circuit may further be configured to maintain the tracking array, which includes storing the tracking array in a parameter cache.

[0011] Maintaining the tracking array may include setting bit values ​​at locations in the tracking array corresponding to LDS blocks where at least one of the one or more attributes of the first primitive is stored. In some embodiments, one or more allocated compute units are configured to render a first pixel wave and a second pixel wave using one or more attributes stored in one or more LDS blocks. In some embodiments, the scheduling circuit is further configured to identify the first primitive as a large primitive based on at least one of the number of pixels associated with the first primitive, the amount of shader operation required to render the first primitive, and the amount of memory required to store the attributes associated with the first primitive.

[0012] This disclosure will be better understood by referring to the accompanying drawings, and many of its features and advantages may become apparent to those skilled in the art. The use of the same reference numerals in different drawings indicates similar or identical items. [Brief explanation of the drawing]

[0013] [Figure 1] This diagram shows two large triangular primitives that together occupy the entire display frame. [Figure 2] This is a block diagram of a processing system suitable for implementing the selective initialization of redundant pixel waves, according to several embodiments. [Figure 3] This figure shows a sequence of stages in a Pixel Wave Attribute Tracking Array (PWATA) during processing of a sequence of large primitive pixel waves, according to one or more embodiments. [Figure 4] This figure shows an operational flow routine illustrating part of the instruction processing operation for rendering one or more primitives using one or more computing units, according to one or more embodiments. [Modes for carrying out the invention]

[0014] Large primitives are used in a variety of graphics rendering scenarios, including games (which may include large areas with substantially identical pixel attributes, such as sky, walls, and water, even in complex environments), video rendering and / or streaming, computer-aided design and modeling, and image / video editing. In each of these scenarios, large areas of the display are associated with the same pixel attributes, each of which may describe parameters such as color, texture, and depth.

[0015] Figure 1 shows two large triangular primitives 105 and 110 that together occupy the entire display frame 100. In many real-world applications (e.g., mobile benchmarks, games, video streaming, and other applications), pixel shader operations often involve large primitives that occupy a significant portion of the display frame. Furthermore, in various rendering operations, a graphics processing unit (GPU) invokes multiple pixel waves to run on one or more of its compute units (CUs) to render a single primitive. For example, in some scenarios, multiple pixel shaders may run on every pixel of the display frame 100 to render two large primitives 105 and 110 that collectively cover the entire screen.

[0016] In conventional methods, rendering each of the large primitives 105 and 110 involves initiating a read operation to access the attributes associated with each pixel wave associated with each of the large primitives 105 and 110. The attributes are then written to the local data store (LDS) within each CU, so that the attribute data for each pixel wave is stored in a processable state within each CU. However, since consecutive pixel waves may share common attributes and be assigned to the same LDS address, subsequent pixel waves can utilize this data without requiring a new cache-to-LDS cycle to rewrite those attributes. Therefore, in conventional methods, rendering large primitives typically redundantly initializes the pixel attributes of each pixel wave, regardless of whether those pixel waves are substantially identical, resulting in wasted resources and increased power consumption. In particular, the switching power used by the LDS contributes to higher power consumption, increased heat generation, and potentially shorter battery life (in mobile devices, etc.).

[0017] Embodiments of the technique described herein avoid reinitializing the attributes of consecutive pixel waves by leveraging a common local data storage used by consecutive pixel waves associated with the same large primitive. For each pixel wave, a scheduling circuit (sometimes called a shader processor input or SPI) begins reading the attributes of the corresponding primitive from a parameter cache (PC) circuit, and the PC circuit writes the attributes to the respective local data store (LDS) at the address assigned to the pixel wave by the scheduling circuit for each of the one or more compute units allocated to render the corresponding primitive. When a pixel wave has finished processing, the same LDS address may be assigned to another pixel wave of the same large primitive. If a preceding pixel wave does not overwrite the LDS location of the attributes, the attributes can be used by subsequent pixel waves without consuming a new processing (PC_LDS) cycle to rewrite the attributes. In such a situation, the initialization of one or more attributes in the subsequent pixel waves is considered redundant and may be omitted by the scheduling circuit accordingly. In certain embodiments, the described technique includes maintaining a pixel wave attribute tracking array (PWATA, also known as a scoreboard) to monitor and identify local datastore (LDS) locations where large primitive attributes are stored, enabling the system to quickly determine whether consecutive pixel wave attribute reinitialization is necessary or can be considered redundant.

[0018] Embodiments of these technologies can help optimize the rendering of such large primitives, improving performance and reducing power consumption in mobile games or other scenarios where power efficiency is critical.

[0019] Figure 2 is a block diagram of a processing system 200 implementing selective initialization of redundant pixel waves in several embodiments. The processing system 200 includes a central bus 210, which facilitates communication between various components of the system by enabling efficient data exchange and synchronization between different processing units (e.g., CPU 215 and GPU 230), memory components (e.g., memory 225), and input / output mechanisms (e.g., I / O engine 280). Some embodiments of the processing system 200 include other buses, bridges, switches, routers, etc., which are not shown in Figure 2 for clarity.

[0020] Bus 210 is communicatively coupled to a central processing unit (CPU) 215 that coordinates the overall operation of the processing system 200. The CPU 215 includes multiple processor cores 221-223, enabling several tasks to be executed simultaneously (in parallel). These processor cores 221-223 are responsible for executing major software instructions, including system-level operations, application processes, and specific graphics-related functions. In some embodiments, one or more of the processor cores 221-223 operate to perform the same operation on different datasets (e.g., via Single Instruction Multiple Data, or SIMD processing). While three processor cores 221-223 are shown in the exemplary embodiment shown in Figure 2 to represent any M cores, the number of processor cores 221-223 implemented within the CPU 215 is a matter of design choice. Therefore, in other embodiments, the CPU 215 can contain any number of processor cores 221-223. Processor cores 221-223 execute instructions such as program code 225 stored in memory 225, and CPU 215 stores information such as the results of the executed instructions in memory 225. Furthermore, CPU 215 can initiate graphics processing by issuing a draw call to GPU 230.

[0021] The input / output (I / O) engine 280 connects the processing system 200 to external devices and peripherals such as a keyboard, mouse, printer, and external disk, enabling communication between them. One of the devices connected to the I / O engine 280 is the display 290, which visually presents graphics and other visual content processed by the processing system 200, including one or more large primitives optimized through the selective initialization of redundant pixel waves.

[0022] Memory 225 is also communicatively coupled to bus 210 and functions as primary data storage for the processing system 200, using a non-temporary computer-readable storage medium such as dynamic random-access memory (DRAM). However, in various embodiments, memory 225 is implemented using other types of memory, such as static random-access memory (SRAM) or non-volatile RAM. In the illustrated embodiment, memory 225 stores some or all of an operating system (OS) 226 that monitors and manages hardware resources, a graphics driver 228 that bridges the gap between software applications and the GPU 230 and translates application requests into hardware-level actions, and an application 229 that includes various software programs that can be executed by the user, some of which may generate graphical data or tasks that utilize one or more functions of the GPU 230.

[0023] The techniques described in this specification are, in various embodiments, used at least in part by GPU 230. GPU 230 includes, for example, any of various parallel processors, vector processors, coprocessors, accelerated processing units (APUs), general-purpose GPUs (GPGPUs), non-scalar processors, high parallel processors, artificial intelligence (AI) processors, inference engines, machine learning processors, other multi-threaded processing units, scalar processors, serial processors, or any combination thereof. GPU 230 processes specialized graphics and computing tasks and offloads such functions from CPU 215. For example, GPU 230 renders objects (e.g., groups of primitives) according to one or more shader programs to generate pixel values provided to display 290, and this display uses the pixel values to display an image representing the rendered objects.

[0024] To render objects, GPU 230 implements, for example, multiple computing units 245 that execute instructions from one or more applications 229 simultaneously or in parallel. For example, GPU 230 uses multiple GPU cores 251-253 via computing units 245 to execute instructions such as shader programs, ray tracing programs, graphics pipelines, etc. to render one or more objects.

[0025] The GPU 230 includes a plurality of computing units 245 for processing graphics tasks and computing tasks of the GPU 230 in parallel. In some embodiments, the CPU 215 and the GPU 230 have an equal number of processing cores, while in other embodiments, the CPU 215 and the GPU 230 have different numbers of processing cores. In the embodiment shown in FIG. 2, three GPU cores 251-253 representing any N GPU cores are presented, and these GPU cores 251-253 are organized and associated with each of any number of computing units (CUs) 245. Each CU 245 includes its own local data store (LDS) 250, which enables the shader cores 251-253 to quickly read and write data during processing. The LDS 250 is configured to store, for example, values, register files, operands, instructions, variables, result data (e.g., data obtained from the performance of one or more operations), flags, or any combination thereof that are necessary to perform one or more operations indicated in one or more instructions from the application 229, assist in performing one or more operations, or be useful in performing one or more operations. With respect to the various techniques described herein, the LDS 250 stores the attributes of large primitives and optimizes how these attributes are initialized to avoid redundancy such as pixel waves used to render these large primitives.

[0026] Each CU245 includes multiple GPU cores 251-253 that handle various tasks such as vertex shading, pixel shading, and other graphics-related computations. In particular, GPU cores 251-253 process pixel waves and benefit from the selective initialization of those pixel waves to improve efficiency. In various embodiments, the number of compute units 245 and the number of GPU cores 251-253 associated with each of them may be chosen as a matter of design choice. Thus, in other embodiments, the GPU230 can include any number of compute units 245 and / or processor cores 251-253. Some embodiments of the GPU230 are used for general-purpose computing. The GPU230 executes instructions such as program code (e.g., shader code, ray tracing code) contained in one or more applications 229 (e.g., shader programs, ray tracing programs) stored in memory 225, and the GPU230 stores information such as the results of the executed instructions in memory 225. In the illustrated embodiment, the memory 225 further includes, for example, part or all of the operating system (OS) 226 to provide an interface between the application 229 and the graphics driver 228.

[0027] In the illustrated embodiment, the operation of the GPU 230 is managed by the Shader Processor Input (SPI) 235. The SPI 235 includes scheduling circuitry that determines how tasks are allocated among the Compute Units (CUs) 245 and ensures that data attributes, such as pixel wave attributes, are available when needed. For example, the SPI 235 is responsible for managing a list of commands sent to the GPU 230 for processing and scheduling their execution. These commands are typically sequences of low-level instructions that specify various operations ranging from drawing primitives and setting their colors to updating textures. Each graphical primitive is at least partially defined by its vertices, each of which identifies a point in 3D space and may include additional associated data such as color, texture coordinates, normals, and other attributes important for rendering. The associated data or attributes of each vertex are stored at a specific location or address in the Parameter Cache (PC) 240. In certain embodiments, a unique identifier for any given primitive (e.g., a triangle) is based on a specific location in the PC 240 where its vertex data is stored.

[0028] The SPI235 ensures that received graphical instructions are executed in the correct order and that any necessary data from the PC240 is available to decode the commands and translate them into appropriate hardware instructions for execution by one or more CUs of the multiple computing units 245. In the illustrated embodiment, the SPI235 further optimizes the pixel wave attribute initialization process by coordinating the selective initialization of redundant pixel waves.

[0029] As part of the GPU230, a multi-level cache hierarchy is implemented and represented in a simplified manner by the cache 238. Within the cache 238, the PC240 stores attributes, including vertex data for each primitive, associated with different graphical primitives and used during the rendering process. The GPU230 further includes a crossbar (XBAR) 231 that acts as an intermediate switch connecting and managing data traffic between multiple compute units (CUs) 245, SPI 235, and the cache 238.

[0030] In various scenarios and architectures, a single pixel wave contains pixels from multiple primitives, and this is more likely for pixel waves invoked to render smaller primitives. In contrast, for pixel waves invoked to render larger primitives, all pixels are more likely to be associated with a single such large primitive, and therefore a single LDS block typically contains all the attribute data of that one large primitive. Thus, in various embodiments, the SPI (shader processor input) 235 uses one or more predetermined criteria to identify the large primitives being processed by the SPI 235, thereby identifying potentially redundant pixel waves to avoid reinitializing the attributes associated with one or more of those redundant pixel waves. For example, in certain embodiments, one or more of the following criteria are used: For example, identifying primitives in which all pixels exclusively belong to a particular pixel wave; identifying pixel waves associated with attributes limited to a single LDS block; identifying pixel waves associated with attributes limited to a single LDS block of a predetermined size (e.g., 512 bytes or another predetermined size); identifying primitives based on PC (Parameter Cache) 240 addresses corresponding to one or more defined vertices of the primitive; identifying primitives based on one or more subsequent pixel waves that show substantially identical sets of addresses in PC240, indicating association with a previously identified larger primitive. In various embodiments, upon receiving a primitive that satisfies one or more of these criteria or other predetermined criteria, the SPI235 recognizes the presence of a larger primitive. In certain embodiments, upon processing a pixel wave belonging to a different primitive, the SPI235 invalidates the previously detected larger primitive (e.g., by clearing its PWATA entry), as can be determined by variations in parameter cache addresses.

[0031] Figure 3 shows successive stages of a Pixel Wave Attribute Tracking Array (PWATA) during processing of successive pixel waves in one or more embodiments. The PWATA facilitates efficient initialization of pixel wave attributes for identified large primitives, reducing the number of processing cycles by, for example, avoiding redundant initialization of those attributes. In some embodiments, the PWATA is stored in a parameter cache (PC) 240 of the GPU 220, enabling quick access to the stored parameters for use when processing successive pixel waves 301, 302, and 303.

[0032] As described elsewhere in this specification, the contents of PC240 are typically provided as part of graphical instructions sent to the GPU (e.g., draw commands or rendering instructions), and PC240 generally stores them as part of the process of parsing those graphical instructions, their associated graphical primitives, and other related data. Thus, as described above, PC240 stores the parameters of graphical primitives processed by CU245 for rendering or other GPU-related tasks. In the context of graphical processing, these attributes typically include information such as vertex positions, colors, texture coordinates, normals, and other data describing the primitive to be rendered. PWATA functions to track which LDS blocks have already been initialized with the attributes of a particular large primitive. In certain embodiments and scenarios, SPI235 may process other additional shader types (e.g., compute shaders, geometry shaders, etc.) along with pixel shader processing, such as through interleaving or some other configuration. In such a scenario, when the SPI235 invokes a non-pixel shader wave, it clears the specific PWATA entry corresponding to the LDS block assigned to the wave that is unrelated to the identified large primitive.

[0033] The interaction between the SPI235 (not shown separately in Figure 3), LDS250, and PC240 during the processing of pixel waves 301, 302, and 303 results in different bit patterns being reflected when PWATA tracks attribute data stored in LDS250 for those consecutive pixel waves 301, 302, and 303. Thus, Figure 3 shows three consecutive states associated with each of those consecutive pixel waves, in particular, that the processing of the first pixel wave 301 results in PWATA state 310, the processing of the second subsequent pixel wave 302 (after any number of zero or more additional pixel waves) results in PWATA state 320, and the processing of the third pixel wave 303 (which may occur again after any number of zero or more additional pixel waves since the previous pixel wave 302) results in PWATA state 330. In each of the PWATA states 310, 320, and 330, the rows correspond to individual compute units (CU_001 to CU_n, where n represents the total number of compute units 245), and the columns correspond to LDS blocks (LDSB_001 to LDSB_max, where max represents the total number of storage blocks in the LDS corresponding to each of those CUs 245). In particular, each block of the LDS 250 stores a predetermined amount of data (e.g., 512B or other amounts), but each corresponding location in the PWATA stores a single bit to track the contents of each LDS associated with a particular compute unit. Specifically, as each consecutive pixel wave 301, 302, and 303 is processed, the bits in each of the PWATA states 310, 320, and 330 track where the attribute data for those consecutive pixel waves is stored in the corresponding LDS of each CU.

[0034] When the first pixel wave 301 is processed, the PWATA state 310 registers a specific bit at position 315 associated with LDSB_004 in row CU_003. This bit signifies the initialization of a specific LDS block corresponding to position 315 in the PWATA, which stores the attributes of the large primitive associated with the pixel wave 301. Attributes that may be vertex data, color, and texture mapping are loaded from the PC240 by the SPI235 and written to the specific LDS block for access by the compute unit (CU_003) assigned to process the pixel wave 301. Furthermore, the SPI235 updates the PWATA state 310 to set a specific bit at position 315 associated with the specific LDS block of the assigned compute unit CU_003, thereby tracking the initialization of the attributes associated with the pixel wave 301.

[0035] When the second pixel wave 302 is processed at some point later, the SPI235 again adjusts the lookup of attribute data. As described herein, pixel wave 302 may be one or more consecutive pixel waves that occur after pixel wave 301 associated with the large primitive associated with pixel wave 301. Based on the parameter cache address associated with pixel wave 302, the SPI235 determines that pixel wave 302 is associated with the same large primitive and that the attribute data for pixel wave 302 is stored in the LDS block corresponding to position 316. By checking position 316 for a PWATA state 320 holding the value "1" from the processing of any of the consecutive pixel waves that occur after pixel wave 302, the SPI235 determines that the attributes of pixel wave 301 are already stored in the LDS block corresponding to the PWATA state 320 at position 316. Therefore, by identifying the positive bit at position 316 of PWATA state 320, the SPI235 avoids reinitializing these LDS blocks with the same pixel wave attribute data that was previously stored during the processing of the previous pixel wave associated with the same identified large primitive.

[0036] When the SPI235 receives a subsequent third pixel wave 303 for processing, it determines, based on the parameter cache address associated with that pixel wave 303, that it is associated with a different primitive than those associated with pixel waves 301 and 302. Therefore, the SPI235 clears PWATA, resetting all bits to "0", and then sets the bit corresponding to the LDS block where the attributes of pixel wave 303 are stored (in this example, position 318 of PWATA state 330). Similar to pixel waves 301 and 302, the attributes of pixel wave 303 are loaded by the SPI235 from PC240 and written to the LDS block for access by the compute unit (CU_003) assigned to process pixel wave 303.

[0037] Therefore, through the unfolding PWATA states 310, 320, and 330 shown in Figure 3, the GPU230 (particularly the SPI235) utilizes PWATA to avoid the redundant attribute initialization process associated with consecutive pixel waves of the same large primitive.

[0038] Figure 4 shows an operational flow routine 400 that partially illustrates the operation of, for example, the SPI235 (see Figure 2) when processing instructions for rendering one or more primitives using one or more computing units (e.g., one or more computing units 245 in Figure 2) according to one or more embodiments. The flow routine 400 facilitates the pixel wave attribute initialization process with the aim of reducing redundancy and thereby improving overall rendering efficiency.

[0039] Routine 400 begins in block 405, where the SPI receives graphical instructions for rendering one or more primitives, such as via a draw call to the embedded GPU (e.g., GPU 230 in Figure 2). Such graphical instructions are typically encapsulated within a draw command or rendering command, conveying details of each specified primitive, such as vertex positions, color, and texture coordinates. The routine then proceeds to block 410.

[0040] In block 410, the SPI identifies a large primitive among those specified by the graphical instruction received in block 405. As described elsewhere in this specification, in various embodiments, such large primitives are identified based on various criteria, such as (as an unrestricted example) the number of pixels contained by the primitive, the fact that the associated pixel wave attributes occupy a particular memory space constraint (e.g., stored within a single LDS block), and the consistency of the parameter cache addresses associated with one or more vertices of the primitive. The routine proceeds to block 415.

[0041] In block 415, the SPI invokes one or more pixel waves (pixel waves) associated with the large primitive identified in block 410. These pixel waves correspond to a region or subset of the primitive that will be rendered as a result of the graphical instruction received in block 405. The routine then proceeds to block 420.

[0042] In block 420, the SPI checks the state of the Pixel Wave Attribute Tracking Array (PWATA) to determine whether the pixel wave attributes associated with the identified large primitive are already stored in one or more LDS blocks. If the PWATA indicates that the pixel wave attributes associated with the large primitive are already stored in the LDS, routine 400 skips to block 440, omitting the initialization step and saving processing resources.

[0043] If, in block 420, PWATA determines that attribute data associated with the large primitive identified in block 410 is not already stored in the LDS (as described elsewhere in this specification, for example with respect to Figure 3), then routine 400 proceeds to block 425 and begins reading attributes from the parameter cache for the identified large primitive. The routine then proceeds to block 430.

[0044] In block 430, the SPI stores the attributes retrieved in block 425 in a designated LDS block corresponding to the compute unit (CU) allocated to process the pixel wave of that large primitive. The routine then proceeds to block 435.

[0045] In block 435, the SPI updates the PWATA state so that the attributes of the identified large primitives indicate the LDS block stored in block 430. This allows the SPI to identify the stored state of those attributes when processing subsequent pixel waves. The routine then proceeds to block 440.

[0046] In block 440, if the PWATA was updated in block 435, or if block 420 determines that the pixel wave attributes were already stored in the LDS during the processing of the previous pixel wave, the pixel wave being processed (pixel waveform) is rendered using the attributes stored in the local data storage. In either case, the SPI uses the attributes retrieved from the LDS block of the assigned CU. The routine then proceeds to block 445.

[0047] In block 445, the SPI determines whether there are any additional pixel waves (pixel waves) associated with the currently identified large primitive that are awaiting processing. If so, the routine proceeds to block 420 to process the next pixel wave. Conversely, if all pixel waves for the identified large primitive have been processed, the routine returns to block 410 to identify and process the next large primitive.

[0048] In some embodiments, the apparatus and techniques described above are implemented in a system including one or more integrated circuit (IC) devices (also referred to as integrated circuit packages or microchips), such as the systems, operations, and components described above with reference to Figures 2 to 4. Electronic design automation (EDA) and computer-aided design (CAD) software tools can be used to design and manufacture these IC devices. These design tools are typically represented as one or more software programs. One or more software programs include computer-executable code for operating a computer system to operate with code representing the circuit of one or more IC devices in order to perform at least part of the process of designing or adapting a manufacturing system for manufacturing the circuit. This code may include instructions, data, or combinations of instructions and data. Software instructions representing the design or manufacturing tools are typically stored in a computer-readable storage medium accessible to the computing system. Similarly, code representing one or more stages of designing or manufacturing an IC device is stored in and accessed from the same or different computer-readable storage medium.

[0049] Computer-readable storage media include any non-temporary storage media or combination of non-temporary storage media that are accessible 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 tapes, 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 microelectromechanical system (MEMS) based storage media. Computer-readable storage media (e.g., system RAM or ROM) may be built into the computing system, computer-readable storage media (e.g., magnetic hard drives) may be permanently mounted to the computing system, computer-readable storage media (e.g., optical disks or Universal Serial Bus (USB) based flash memory) may be detachably mounted to the computing system, and computer-readable storage media (e.g., network-accessible storage (NAS)) may be connected to the computer system via a wired or wireless network.

[0050] One or more of the elements described above are circuits designed and configured to perform the corresponding operations described above. Such circuits are, in at least some embodiments, hardcoded circuits (e.g., corresponding parts of application-specific integrated circuits, ASICs, or a set of logic gates, memory elements, and other components selected and arranged to perform assigned operations), programmable circuits (e.g., corresponding parts of field-programmable gate arrays, FPGAs, or programmable logic devices, PLDs), or one or more processors, or a combination thereof, that execute software instructions causing one or more processors to perform assigned actions. In some embodiments, the circuits for a particular element are selected, arranged, and configured by one or more computer implementation design tools. For example, in some embodiments, the sequence of operations for a particular element is defined in a specified computer language, such as a register transfer language, and the computer implementation design tool selects, configures, and arranges the circuits based on the defined sequence of operations.

[0051] In this disclosure, different entities (which may be referred to in various ways as “components,” “units,” “devices,” “circuits,” “circuit modules,” etc.) are described or claimed to be “configured” to perform one or more tasks or operations. This explicit phrase—an entity configured to perform one or more tasks—is used herein to refer to a structure (i.e., a physical thing such as an electronic circuit). More specifically, this explicit phrase is used to indicate that the physical structure is configured to perform one or more tasks while in operation. A structure can be said to be “configured to perform some task even when the structure is not currently in operation. A “memory device configured to store data” is intended to include, for example, an integrated circuit having a circuit that stores data while in operation, even when the integrated circuit in question is not currently in use (e.g., no power is connected to it). Thus, entities described or enumerated as “configured to perform several tasks” refer to something physical, such as a device, a circuit, or memory that stores executable program instructions to perform a task. This phrase is not used herein to refer to something intangible. Furthermore, the term “configured to” is not intended to mean “configurable to.” For example, an unprogrammed field-programmable gate array is not considered "configured to perform some specific function," but it can be "configurable to perform that function" after programming. In addition, stating in the attached claims that a structure is "configured to perform one or more tasks" is not explicitly intended to be interpreted as having a means-plus-function element.

[0052] In some embodiments, certain aspects of the technology described above are implemented by one or more processors of a processing system that executes the software. The software includes one or more sets of executable instructions, which are stored in a non-temporary computer-readable storage medium or otherwise clearly embodied. The software may also include instructions and specific data, which, when executed by one or more processors, operate the one or more processors to execute one or more aspects of the technology described above. Non-temporary computer-readable storage mediums may include, for example, magnetic or optical disk storage devices, solid-state storage devices such as flash memory, caches, random-access memory (RAM), or other non-volatile memory devices (one or more). Executable instructions stored in a non-temporary computer-readable storage medium can be implemented as source code, assembly language code, object code, or other instruction forms that can be interpreted or otherwise executed by one or more processors.

[0053] In addition to the foregoing, it should be noted that not all activities or elements described in the summary are required, and certain activities or parts of devices may not be required, and 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 does not necessarily indicate 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 understand that various modifications and variations can be made without departing from the scope of the invention as described in the claims. Therefore, the specification and drawings should be considered illustrative rather than restrictive, and all of these variations are intended to fall within the scope of the invention.

[0054] Benefits, other advantages, and solutions to problems have been described above with respect to specific embodiments. However, benefits, advantages, solutions to problems, and features that may give rise to or manifest any benefits, advantages, or solutions are not to be construed as essential, necessary, or indispensable features to any or all of the claims. Furthermore, the disclosed invention can be modified and implemented in different but similar ways, in ways that are obvious to those skilled in the art who are interested in the teachings of this specification; therefore, the specific embodiments described above are merely illustrative. There are no limitations to the details of the configuration or design shown herein beyond those described in the appended claims. Accordingly, the specific embodiments described above may be modified or altered, and it is clear that all such modifications are within the scope of the disclosed invention. Accordingly, the protection sought herein is described in the appended claims.

Claims

1. Reading one or more attributes of a first primitive from the parameter cache and initializing a first pixel wave using said one or more attributes, The process includes, in response to determining that a second pixel wave is associated with the first primitive, omitting the process of reading one or more attributes from the parameter cache to initialize the second pixel wave, method.

2. Initializing the first pixel wave includes storing the one or more attributes read from the parameter cache in one or more blocks of a local data store (LDS) associated with the compute unit allocated to render the first pixel wave. The method according to claim 1.

3. This includes maintaining a tracking array that indicates one or more LDS blocks in which the one or more attributes described above are stored, The method according to claim 2.

4. Maintaining the tracking array includes storing the tracking array in the parameter cache. The method according to claim 3.

5. Maintaining the tracking array includes setting a bit value at a location in the tracking array corresponding to an LDS block where at least one of the one or more attributes of the first primitive is stored. The method according to claim 3.

6. The process includes rendering the first pixel wave and the second pixel wave using one or more attributes stored in the LDS block. The method according to any one of claims 2 to 5.

7. Determining that the second pixel wave is associated with the first primitive includes comparing the parameter cache addresses of one or more vertices associated with the second pixel wave with the parameter cache addresses of one or more vertices associated with the first primitive. The method according to claim 1.

8. Identifying the first primitive as a large primitive based on at least one of the following: the amount of pixels associated with the first primitive, the amount of shader operation required to render the first primitive, and the amount of memory required to store the attributes associated with the first primitive. The method according to claim 1.

9. Parameter cache and A scheduling circuit is provided, The aforementioned scheduling circuit is Reading one or more attributes of the first primitive from the parameter cache and initializing the first pixel wave using the one or more attributes, In response to determining that the second pixel wave is associated with the first primitive, the process of initializing the second pixel wave by reading one or more attributes from the parameter cache is omitted. It is configured to do, Processing unit.

10. It has multiple computing units, each associated with a local data store (LDS), Initializing the first pixel wave includes storing the one or more attributes read from the parameter cache in one or more blocks of the LDS associated with any of the plurality of computing units, The aforementioned computing unit is one of one or more computing units allocated to render the first pixel wave. The processing unit of claim 9.

11. The system includes a tracking array for storing one or more indicators of one or more LDS blocks in which the one or more attributes described above are stored. The processing unit according to claim 10.

12. The scheduling circuit is configured to maintain the tracking array, Maintaining the tracking array includes storing the tracking array in the parameter cache. The processing unit according to claim 11.

13. Maintaining the tracking array includes setting a bit value at a location in the tracking array corresponding to an LDS block where at least one of the one or more attributes of the first primitive is stored. The processing unit according to claim 11.

14. One or more assigned computing units are configured to render the first pixel wave and the second pixel wave using the one or more attributes stored in one or more LDS blocks. A processing unit according to any one of claims 10 to 13.

15. The scheduling circuit is configured to identify the first primitive as a large primitive based on at least one of the following: the amount of pixels associated with the first primitive, the amount of shader operation required to render the first primitive, and the amount of memory required to store the attributes associated with the first primitive. The processing unit of claim 9.

Images