Local boot in a worker processor

Abstract

The workgroup processor associated with the shader program interface is provided with a local launcher that is capable of launching shader threads partially or completely independently of the shader program interface. The local launcher maintains a local queue separately from the shader program interface. The local launcher allocates resources directly or through a request to the shader program interface for shader thread execution at the associated workgroup processor. In some implementations, the shader program interface leases resources to the local launcher in response to a request for resources, and terminates the lease when the local launcher notifies the shader program interface that execution of a shader thread is complete.

Description

Background Technology

[0001] Parallel processors, such as accelerator processors and graphics processing units (GPUs), implement graphics processing pipelines that concurrently process copies of commands retrieved from an command buffer. GPUs and other multithreaded processing units typically implement multiple processing elements (also known as processor cores, compute units, or workgroup processors) that execute different programs or, as a single “wave,” concurrently execute multiple instances of a single program across multiple datasets—that is, a group of threads running concurrently on the GPU. Hierarchical execution models are often used to match the hierarchical structure implemented in hardware. An execution model defines a kernel of instructions executed by one or more waves (also known as wavefronts, threads, streams, or work items). The graphics pipeline in a GPU includes one or more shader engines that use the resources of the graphics pipeline, such as compute units, memory, and caches, to execute computer programs commonly referred to as “shaders.” As the name suggests, shaders are traditionally used for graphics computation; however, in modern computing, shaders are often used as “computation shaders,” functioning as general-purpose software capable of performing work independently of the graphics processing pipeline. Attached Figure Description

[0002] This disclosure can be better understood by referring to the accompanying drawings, and its many features and advantages will be apparent to those skilled in the art. The same reference numerals are used in different drawings to denote similar or identical items.

[0003] Figure 1 It is a block diagram based on some specific implementations of the processing system.

[0004] Figure 2 A graphics pipeline, based on some specific implementations, is described that can process high-order geometric primitives to generate rasterized images of three-dimensional (3D) scenes at a predetermined resolution.

[0005] Figure 3 This is a block diagram illustrating the steps required to start a shader thread in a workgroup cluster architecture.

[0006] Figure 4 It is a block diagram of a workgroup cluster architecture based on some specific implementations, including a workgroup processor with a local initiator.

[0007] Figure 5 It is a data flow diagram based on some specific implementations of the local initiator leasing resources from the shader program interface to the workgroup processor in the workgroup cluster.

[0008] Figure 6This is a flowchart illustrating a method for starting shader threads at a workgroup processor using the local launcher of the workgroup processor in a workgroup cluster, based on some specific implementations. Detailed Implementation

[0009] Parallel processors (such as accelerated processing devices or GPUs) may include multiple shader engines, each comprising a corresponding number of computational units and a command processor coupled to the multiple shader engines. Based on one or more commands received for execution, multiple workgroups (sets of processing threads) are generated and assigned to the multiple shader engines for processing. The command processor receives one or more commands for execution and generates multiple workgroups based on those commands. Assigning each workgroup to a corresponding shader engine may include dynamically assigning each workgroup to the corresponding shader engine via a Shader Programming Interface (SPI), which acts as a scheduler associated with the corresponding shader engine, and other functions as described below.

[0010] In typical implementations, SPI manages the startup of all threads, which is performed by the corresponding workgroup processor. Typically, each SPI manages multiple workgroup processors and handles operations such as resource tracking, allocation, and wave setting. Therefore, workgroup processors cannot start threads independently of SPI. Instead, a workgroup processor needs to request thread startup via a command processor that interfaces with the SPI to initiate the thread. Commands generated based on the request are typically provided to the SPI via the command processor or related processes (e.g., using special registers), and because the SPI manages workload balancing and resource allocation within the workgroup processors, the thread is usually executed by a different workgroup processor than the requesting workgroup processor. This processing overhead limits the performance characteristics of the workgroup processor's thread startup. Additionally, conventional mechanisms for implementing context switching capabilities (such as takeover modes) control one or more workgroup processors, introducing further challenges in balancing the workgroup processors between SPI and the workgroup processors. To improve thread startup performance and overall computational efficiency, the implementations disclosed herein enable workgroup processors to start threads partially or completely independently of SPI.

[0011] Figure 1 , Figure 2 and Figures 4 to 6Systems and techniques for providing local boot capabilities to workgroup processors in processors such as GPUs are illustrated. The specific implementations disclosed herein enable workgroup processors to “self-service” boot requests when possible, while still allowing the SPI to provide work and manage associated workgroup processors as appropriate. In some implementations, the workgroup processor local boot mechanism provides orders of magnitude improvements in thread boot performance, enabling finer-grained dispatching, local consumption of data within compute units, and significantly improved performance in highly variable workloads. For example, the local boot mechanism improves the performance of application programming interfaces (APIs) utilizing work graphics by allowing workgroup processors to schedule work themselves without submitting requests to work scheduling mechanisms such as command processors. Additionally, enabling resources to be allocated by either the local bootloader or the SPI allows for better allocation of workloads that utilize both simultaneously, such as graphics functions running concurrently with compute functions.

[0012] Providing a local initiator within a workgroup processor allows the local initiator to handle local dispatches without the overhead associated with conventional initiation mechanisms that rely on requests made to the SPI. In some implementations, the local initiator coordinates with the SPI and manages resources independently of the SPI by allocating resources, notifying the shader interface of allocations, and managing its own local dispatch queue. In some implementations, the local dispatch queue within the workgroup processor is accessible and controlled only by the workgroup processor. However, in some implementations, one or more of the local initiator, SPI, workgroup processor, and local dispatch queue can be directly addressed or controlled by the user, allowing the user to finely implement specific tasks on a particular workgroup processor and manage the operation of the SPI for optimization. In other implementations, the user can provide preferences or votes for preferred operations of the local initiator, SPI, workgroup processor, and local dispatch queue, for example, via user-accessible drivers, allowing the local initiator and / or SPI to override preferences or votes in scenarios where significantly more efficient operation can be achieved using configurations other than those specified by the user-defined preferences or votes.

[0013] In some implementations, when a workgroup processor needs to start a thread, it determines the required resources, allocates them, and does not return the resources to the SPI until the request can be satisfied. In other implementations, the workgroup processor requests resources directly from the SPI. As long as the local queue is not empty and the workgroup processor is not idle, it continues to allocate resources to itself and manage the execution of locally started threads without communicating directly with the SPI, because the workgroup processor can continue processing tasks independently of the SPI. Once the local queue is exhausted, the workgroup processor begins to release resources back to the SPI. In some implementations, enabling the workgroup processor to operate independently of the SPI drastically reduces startup latency, allows for self-scheduling, and has minimal impact on existing applications, as existing applications can still start work via the SPI as needed. Software that does not use the local startup mechanism is unaffected by the local startup mechanism and continues to run unmodified while the software is provided with work via the SPI. New software written to utilize the local startup mechanism can do so easily because the total integration cost is a finite number of new opcodes (operation codes, e.g., machine language instructions specifying the operations to be performed), and resource management can be performed by hardware.

[0014] Figure 1 This is a block diagram of a processing system 100 implementing local boot capability according to some specific implementations. The processing system 100 includes or has access to memory 105 or other storage components implemented using non-transitory computer-readable media such as dynamic random access memory (DRAM). However, in some cases, memory 105 is implemented using other types of memory, including static random access memory (SRAM), non-volatile RAM, etc. Memory 105 is referred to as external memory because it is implemented outside the processing units 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 memory 105. Some specific implementations of the processing system 100 include other buses, bridges, switches, routers, etc., which are not shown for clarity. Figure 1 As shown in the image.

[0015] In different specific implementations, the techniques described herein are employed at any of the various parallel processors, such as vector processors, GPUs, general-purpose GPUs (GPGPUs), nonscalar processors, highly parallel processors, artificial intelligence (AI) processors, inference engines, machine learning processors, other multi-threaded processing units, etc. Figure 1Examples of parallel processors according to some specific implementations, and in particular, examples of GPU 115, are illustrated. GPU 115 typically renders images for presentation on display 120. For example, GPU 115 renders objects to produce pixel values ​​provided to display 120, which uses these pixel values ​​to display an image representing the rendered objects. GPU 115 implements multiple shader engines, such as shader engine 118, each of which includes multiple workgroup processors (WGPs) 121, 122, 123 (collectively referred to herein as “WGPs 121 to 123”) capable of executing instructions individually or in parallel. Shader engine 118 is typically implemented using shared hardware resources of GPU 115, such as compute unit 124. In some specific implementations, shader engine 118 is used to implement shaders such as geometry shaders, pixel shaders, etc. Typically, shader engine 118 is a logical grouping of processing hardware, which in some specific implementations includes, for example, one or more processors, compute units, processing chiplets, processor cores, and / or caches.

[0016] In some specific implementations, WGP 121 to 123 include one or more Single Instruction Multiple Data (SIMD) units and a computation unit 124, etc. For example... Figure 1 As shown, WGP 121 to 123 also include a local initiator 112, which is implemented as any set of cooperative hardware, software, or a combination thereof, which is partially or completely independent of, for example, SPI (see example...). Figure 3 and Figure 4 This executes functions and computations associated with startup threads (such as compute shader threads). The number of WGP 121 to 123 implemented in GPU 115 is a matter of design choice, and some specific implementations of GPU 115 include more than Figure 1The diagram shows more or fewer WGPs. In some implementations, WGPs 121 to 123 implement the graphics pipeline discussed herein. Typically, WGPs 121 to 123 are logical groups of processing hardware, which in some implementations include, for example, one or more processors, compute units, processing chiplets, processor cores, and / or caches. In some implementations, WGPs 121 to 123 can be selectively addressed or controlled independently of each other, or as a group of two or more WGPs, allowing GPU 115, shader engine 118, and / or the user to control which WGPs 121 to 123 perform specific tasks or distribute tasks among multiple WGPs. In some implementations, GPU 115 is used for general-purpose computing. GPU 115 executes instructions such as program code 125 stored in memory 105, and GPU 115 stores information, such as the results of the executed instructions, in memory 105.

[0017] The processing system 100 also includes a central processing unit (CPU) 130, which is connected to bus 110 and thus communicates with GPU 115 and memory 105 via bus 110. CPU 130 implements multiple processor cores 131, 132, and 133 (collectively referred to herein as "processor cores 131 to 133") that execute instructions concurrently or in parallel. The number of processor cores 131 to 133 implemented in CPU 130 is a matter of design choice, and some specific implementations include more than... Figure 1 The example illustrates more or fewer processor cores. Processor cores 131 to 133 execute instructions (such as program code 125 stored in memory 105), and CPU 130 stores information (such as the results of the executed instructions) in memory 105. CPU 130 is also capable of initiating graphics processing by issuing a draw call to GPU 115. Processor cores 131 to 133 execute instructions individually or in parallel.

[0018] Input / output (I / O) engine 145 handles input or output operations associated with display 120 and other components of processing system 100, such as keyboard, mouse, printer, external disk, etc. I / O engine 145 is coupled to bus 110, enabling it to communicate with memory 105, GPU 115, or CPU 130. In the illustrated embodiment, I / O engine 145 reads information stored on external storage component 150, which is implemented using a non-transitory computer-readable medium such as optical disc (CD), digital video disc (DVD), etc. I / O engine 145 is also capable of writing information to external storage component 150, such as the results of processing performed by GPU 115 or CPU 130.

[0019] Processing system 100 implements pipelined circuitry for executing instructions at multiple stages of the graphics pipeline. The pipelined circuitry is implemented in some specific implementation of WGP 121-123 or processor cores 131-133, or both. In some specific implementations, the pipelined circuitry of WGP 121-123 is used to implement a graphics pipeline that executes different types of shaders (e.g., program code for rendering graphics or performing other tasks), including but not limited to vertex shaders, shell shaders, domain shaders, geometry shaders, and pixel shaders. Some specific implementations of processing system 100 include one or more caches that hold information written to the cache by the shaders in response to the completion of a wave or wave group (such as a geometry shader wave group). The information written to the cache is subsequently read out during the execution of other waves or wave groups (such as pixel shader waves). Some specific implementations of the geometry shader generate a first wave group, and the shader program interface initiates the first wave group for shader execution. The scan converter generates a second wave for execution on a shader based on the results of processing a first wave group in one or more shaders. The first wave group is selectively throttled based on a comparison between the first wave group in execution and the second wave group awaiting execution on at least one shader engine. In other specific implementations, WGP 121 to 123 use a local startup mechanism to launch threads partially or completely independently of SPI, as described below. Figures 4 to 6 The discussion further describes this. The cache retains information written to it in response to the first wave of groups completing execution on the shaders. Information is read from the cache in response to read requests issued by the second wave.

[0020] Figure 2 A graphics pipeline 200, according to some specific implementation, is described, capable of processing high-order geometric primitives to generate rasterized images of three-dimensional (3D) scenes at a predetermined resolution. Figure 1 The graphics pipeline 200 is implemented in some specific embodiments of the processing system 100 shown. The illustrated specific embodiment of the graphics pipeline 200 is implemented according to the DX11 specification. Other specific embodiments of the graphics pipeline 200 are implemented according to other application programming interfaces (APIs) such as Vulkan, Metal, and DX12. The graphics pipeline 200 is subdivided into a geometry processing section 201 that includes the portion of the graphics pipeline 200 before rasterization and a pixel processing section 202 that includes the portion of the graphics pipeline 200 after rasterization.

[0021] The graphics pipeline 200 accesses storage resources 205, such as a hierarchy of one or more memories or caches for storing buffered data, vertex data, and texture data. In the illustrated specific implementation, storage resource 205 includes Local Data Sharing (LDS) 206 circuitry for sharing data among threads in a workgroup without interfacing with the cache / memory hierarchy. Storage resource 205 also includes one or more caches 207 for caching frequently used data. Cache 207 is used to implement parameter buffers. As discussed herein, a wave or wave group (referred to herein as a shader stage of the graphics pipeline or a shader) executed on a shader in the graphics pipeline 200 completes its execution by writing the results of processing the wave or wave group into cache 207. Shaders further down the graphics pipeline 200 may issue read requests to read information from cache 207, such as the results of processing by a wave or wave group previously executed on the shader. Figure 1 Some specific implementations of the system memory 105 shown implement the storage resource 205.

[0022] The assembler 210 accesses information from storage resource 205 about objects used to define parts of a model representing a scene. Examples of primitives are shown in... Figure 2 The primitive is shown as triangle 211, but other types of primitives are processed in some specific implementations of the graphics pipeline 200. Triangle 211 includes one or more vertices 212 connected by one or more edges 214. Vertices 212 are colored during the geometry processing section 201 of the graphics pipeline 200.

[0023] In the illustrated implementation, the software-implemented vertex shader 215 logically receives a single vertex 212 of a primitive as input and outputs a single vertex. Some implementations of shaders such as vertex shader 215 implement SIMD processing at a shared massive single instruction multiple data (SIMD) computation unit, enabling concurrent processing of multiple vertices. In some implementations, the graphics pipeline 200 implements a unified shader model, such that all shaders included in the graphics pipeline 200 have the same execution platform on the shared massive SIMD computation unit. In some implementations, the shader including vertex shader 215 is implemented using a common resource set referred to herein as the unified shader pool 216.

[0024] Shell shader 218 operates on input higher-order patches or control points used to define input patches. Shell shader 218 outputs tessellation factors and other patch data such as control points of patches processed in shell shader 218. Tessellation factors are stored in storage resource 205, so that tessellation factors can be accessed by other entities in the graphics pipeline 200.

[0025] The tessellation unit 220 receives objects (such as patches) from the shell shader 218. In some implementations, primitives generated by the shell shader 218 are provided to the tessellation unit 220. The tessellation unit 220 generates information identifying primitives corresponding to the input objects, for example, by tessellling the input objects based on tessellation factors generated by the shell shader 218. Tessellation subdivides the input high-order primitives (such as patches) into a set of low-order output primitives that represent a finer level of detail, for example, as indicated by the tessellation factors that specify the granularity of the primitives produced by the tessellation process. Thus, the scene model is represented by a smaller number of higher-order primitives (to save memory or bandwidth), and additional detail is added by tessellling the higher-order primitives.

[0026] Domain shader 224 takes the input domain location and (optionally) other patch data. Domain shader 224 operates on the provided information and generates a single vertex for output based on the input domain location and other information. In the illustrated specific implementation, domain shader 224 generates primitive 222 based on triangle 211 and tessellation factor. Domain shader 224 initiates primitive 222 in response to completion of processing.

[0027] Geometry shader 226 receives input primitives from domain shader 224 and outputs up to four primitives (per input primitive) generated by geometry shader 226 based on the input primitives. In the illustrated embodiment, geometry shader 226 generates output primitive 228 based on tessellated primitive 222. Some embodiments of geometry shader 226 generate wavegroups initiated by the corresponding SPI in the associated WGP. In other embodiments, the WGP is independent of the SPI initiation thread, as described below. Figures 4 to 6 The discussion further describes this. In response to the completion of execution on the shader engine, the wavegroup writes the output back to cache 207.

[0028] A primitive stream is provided to one or more scan converters 230, and in some implementations, up to four primitive streams are cascaded to a buffer in storage resource 205. Scan converter 230 performs shading operations and other operations such as clipping, perspective splitting, trimming, and viewport selection. Scan converter 230 generates a set of 232 pixels, which are subsequently processed in the pixel processing section 202 of the graphics pipeline 200. Some implementations of scan converter 230 provide a request to read information from cache 207 by sending a request to a shader programmable interface implemented in the graphics pipeline 200.

[0029] In the illustrated implementation, pixel shader 234 takes a pixel stream (e.g., including pixel set 232) as input and outputs zero or another pixel stream in response to the input pixel stream. Output merger block 236 performs blending, depth, stencil, or other operations on the pixels received from pixel shader 234. Some or all shaders in graphics pipeline 200 use texture data stored in storage resource 205 to perform texture mapping. For example, pixel shader 234 may read texture data from storage resource 205 and use the texture data to shade one or more pixels. The shaded pixels are then provided to the display for presentation to the user.

[0030] Figure 3 This is a block diagram of a workgroup cluster architecture 300 illustrating the steps required to start a shader thread (i.e., a specific instantiation of a shader to perform a specific task or computation set). This is already present in processing systems (such as...) Figure 1 The processing system 100 shown) and the graphics pipeline (such as Figure 2 The graphical pipeline 200 shown in the diagram uses a workgroup cluster architecture 300 in some specific implementations. However, as noted above, various aspects of the workgroup cluster architecture 300 limit startup efficiency and overall performance in some cases.

[0031] The workgroup cluster architecture 300 includes a shader engine 302, which includes a shader program interface (SPI) 304 and a command processor (CP) 306. The shader program interface (SPI) manages a work queue 305, such as requests to start threads. The command processor (CP) receives requests, for example, from one of several associated WGPs 308 or from other software or hardware via memory 310. When a WGP such as WGP 308-2 needs to start a new thread to perform operations related to data 312 stored in WGP 308-2, WGP 308-2 typically must store the request and data 312 in memory 310, causing the CP 306, which monitors memory 310 for such requests, to register the request and provide instructions to the SPI 304 to add the work associated with the request to its queue 305.

[0032] When a WGP such as WGP 308-1 is available, SPI 304 assigns work to WGP 308-1 and provides the data 312 required to perform the work. Although interfacing with SPI 304 to perform complex tasks such as drawing calls results in efficient allocation of the corresponding work in WGP 308, for more granular operations where a single WGP (such as WGP 308-2) can perform the work independently, the inefficiency described above, due to the roundabout method of starting threads by submitting requests to SPI 304 via CP 306 and memory 310, is that WGP 308 cannot start threads independently of SPI 304. This results in relatively high costs in terms of latency and data movement.

[0033] Figure 4 This is a block diagram based on some specific implementations, including a workgroup cluster architecture 400 of WGP 408-1 to 408-4 with a local initiator 112. Figure 1 The processing system 100 shown and Figure 2 The illustrated graphical pipeline 200 implements a workgroup cluster architecture 400 in some specific implementations. For example, through... Figure 3 and Figure 4 A comparison shows that, Figure 4 The 400 workgroup cluster architecture includes many... Figure 3 Similar components to the workgroup architecture 300 include the shader engine 118, CP 306, and SPI404. However, Figure 4The WGP 408 in the workgroup cluster architecture 400 includes local startup software or circuitry (referred to herein as "local initiator" 112) that is partially or completely independent of the SPI 404 in launching threads (such as compute shader threads) and is able to manage its own local work queue 414 separately from the SPI queue 305. However, in cases of complex operations such as draw calls, the SPI 404 is still able to allocate work and launch threads in the WGP as needed. Therefore, while one WGP (such as WGP 408-1) is executing a thread launched by the local initiator at WGP 408-1, other WGPs (such as WGP 408-2, 408-3, and 408-4) are still able to receive work from the SPI 404 in the usual manner. Typically, the local initiator 112 includes hardware and / or software configured to receive instructions from a user or another hardware or software component (such as SPI 404 or shader engine 118), perform tasks such as managing their own local work queues 414 separately from SPI queue 305, and communicate with SPI 404 and / or shader engine 118 to obtain or return resources required for operation, such as memory, cache, or compute unit 124. Therefore, in some specific implementations, the local initiator 112 includes one or more processors, read-only memory, random access memory, queues, I / O engines, drivers, and / or software algorithms that implement aspects of the local initiator 112 as described herein.

[0034] Software configured to utilize the performance enhancements provided by the local initiator 112 will typically use specific API calls designed to utilize the local initiator 112, while more complex operations such as draw calls will still be issued to one or more SPI 404s in a conventional manner to efficiently distribute the workload across multiple WGP 408s. In other words, in some implementations, the determination of whether to start a thread at the local initiator 112 or at the SPI 404 is based on software instructions in the API calls. In this way, work designed to utilize the local initiator 112 will not interfere with work designed to be distributed across the WGP 408 via the SPI 404. It is worth noting that, although Figure 4 Four WGPs are illustrated, but in different specific implementations, more or fewer WGPs are associated with each SPI 404.

[0035] Because the local launcher 112 is configured to start the shader thread at one of the WGPs in WGP 408, the use of Figure 3 The above-mentioned inefficiency arises from using a workgroup cluster architecture with 300 threads to start threads. Specifically, it is not as... Figure 3In contrast, the WGP 408 must start the thread by submitting a request to the SPI 304 via CP 306 and memory 310, rather than... Figure 4 In the workgroup cluster architecture 400, WGP 408 can start threads independently of or in coordination with SPI 404, without waiting for SPI 404 to start threads, assign work to available WGP 408, and transfer related data 312 to the available WGP. Conversely, in some implementations, the local initiator 112 allocates resources directly independently of SPI 404 and notifies SPI 404 of the acquired resources, or requests resource allocation directly from SPI 404. In some implementations, the resource set is dedicated by SPI 404 to one or more WGP 408s. In some implementations, one or more WGP 408s are dedicated to the local initiation functionality performed by SPI 404.

[0036] By coordinating with SPI to manage resources and launch shader threads, the local initiator 112 can accelerate the execution of shader threads without interfacing with system memory or communicating directly with SPI. Therefore, when WGP 408 is in the process of executing a particular shader thread and needs to perform additional tasks such as further computation or other work, the local initiator 112 accelerates the launch of shader threads performing additional tasks by allowing WGP 408 to launch threads internally with low latency and without burdening limited system memory bandwidth. This can be particularly useful in machine learning implementations where many fine-grained decisions or computations determine how a particular process will be performed and which datasets the shader thread will need to utilize to do so.

[0037] In some implementations, the local initiator 112 coordinates with the SPI 404 by either directly transmitting a list of allocated resources to the SPI 404 or storing such a list in a cache or memory accessible by the SPI 404. This allows the SPI 404 to monitor allocated resources and avoid allocating those resources to other workgroups or workloads until the local initiator 112 releases the resources back to the SPI 404. While the local initiator 112 coordinates with the SPI 404 in such implementations, in some implementations, the local initiator can do so indirectly, for example, through a cache, and thus limit its overall resource usage. In other implementations where the local initiator 112 is independent of the SPI 404 initiation thread, the local initiator 112 does not communicate with the SPI 404; instead, the SPI 404 monitors the activity and resources of the WGP 408 to identify resources in use by listening to the activity of the WGP 408 (e.g., by monitoring the performance or execution of the WGP 408).

[0038] In some implementations, SPI 404 leases resources or provides resource credits to local initiator 112 in response to a request to allocate resources received from local initiator 112. These resource credits can be used to reserve a specific resource or a portion of a resource, or otherwise associate with a specific resource or a portion of a resource. When local initiator 112 notifies SPI 404 that a shader thread has completed execution, the SPI terminates the lease or adds the resource credits back to the global pool of resource credits managed by SPI 404. In some implementations, local initiator 112 does not need to communicate directly or with SPI 404 in a low-latency manner. Therefore, local initiator 112 can operate more efficiently, thereby improving overall performance and limiting the burden on memory bandwidth and other limited resources, such as the processing power of CP 306 or SPI 404. Typically, when local initiator 112 starts threads independently of SPI 404, the time required to start shader threads is minimized, while coordinating with SPI 404 to manage resources or start shader threads allows SPI 404 to operate more efficiently. By allowing software to determine the balance between shader thread startup latency and SPI404 efficiency and latency, developers can leverage the appropriate balance to accelerate the execution of relatively more important tasks while allowing for the appropriate de-priority of less important tasks.

[0039] Figure 5 This is a data flow diagram (500) illustrating the coordinated resource leasing process from the shader program interface to the local initiator of WGP within the workgroup cluster, based on some specific implementations. Figure 1 The processing system 100 shown Figure 2 The graphic pipeline 200 shown and Figure 4 The data flow diagram 500 illustrates some specific implementations of the workgroup cluster architecture 400. For example... Figure 5 As shown, at box 502, the local launcher (such as...) Figure 4 A local bootloader in local bootloader 112) from SPI (such as Figure 4The SPI (404) requests resources. In response to this request, at box 504, the SPI leases the resources to the local initiator. After receiving the resources at box 506, at box 508, the local initiator starts a set of shader threads (e.g., workgroups), such as compute shader threads. As shown in decision box 510, the resources are held by the local initiator until the thread execution is complete, and at box 512, the local initiator returns the resources to the SPI, which terminates the lease at box 514. In some implementations, the local initiator requests and returns resources in a piecemeal manner, rather than requesting and returning resources all at once, such that only resources required by short-lived operation windows are held by the local initiator, and additional resources are requested or directly allocated, and unused resources are returned in a more granular manner (e.g., not only before but also after the execution of a particular thread).

[0040] Figure 6 This is a flowchart of method 600, which uses the WGP local launcher to start shader threads at WGP in a workgroup cluster, based on some specific implementations. Figure 1 The processing system 100 shown Figure 2 The graphic pipeline 200 shown and Figure 4 The illustrated workgroup cluster architecture 400 is implemented in some specific ways using method 600. At block 605 of method 600, the local initiator (such as...) Figure 4 A local launcher (one of the local launchers 112) launches a shader thread at a WGP (such as WGP 408-1) that contains local launcher 112 or is otherwise associated with that local launcher.

[0041] In some implementations, the shader thread is started in response to whether additional work needs to be done at the WGP or in response to an API call. At box 610, the local initiator is independent of the SPI (such as...). Figure 4 The thread is started via SPI 404. Alternatively, at box 615, the local initiator starts the thread in coordination with SPI. To allocate the resources required for the execution of the thread, the local initiator independently or in conjunction with SPI (such as...) Figure 4 The SPI 404 coordinates the allocation of resources, as described above. Figure 4 and Figure 5 As described in the discussion. Specifically, the local initiator acquires resources either by requesting resources from the SPI or by obtaining resources independently of the SPI, and optionally by notifying the SPI of the acquired resources to assist the SPI in maintaining a global view of WGP resource usage. Therefore, the various specific implementations disclosed herein implement a distributed control system for launching shader threads that does not create a bottleneck by relying on the SPI to launch each thread.

[0042] In some specific implementations, the apparatus and techniques described above (such as those referenced above) are implemented in systems comprising one or more integrated circuit (IC) devices (also referred to as integrated circuit packages or microchips). Figure 1 , Figure 2 and Figures 4 to 6 (Described local startup functionality). Electronic design automation (EDA) and computer-aided design (CAD) software tools can be used in the design and manufacture of these IC devices. These design tools are typically represented as one or more software programs. One or more software programs include code executable by a computer system to manipulate the computer system to operate on code representing one or more IC devices to perform at least a portion of the process used to design or adapt a manufacturing system to manufacture the circuit. The code may include instructions, data, or a combination of instructions and data. Software instructions representing 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 the design or manufacture of an IC device may be stored in and accessed from the same computer-readable storage medium or different computer-readable storage media.

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

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

[0045] One or more of the aforementioned elements are circuits designed and configured to perform the corresponding operations described above. In at least some embodiments, such circuitry is any one or a combination of the following: hard-coded circuitry (e.g., a corresponding portion of an Application-Specific Integrated Circuit (ASIC) or a set of logic gates, memory elements, and other components selected and arranged to perform the operations), programmable circuitry (e.g., a corresponding portion of a Field-Programmable Gate Array (FPGA) or Programmable Logic Device (PLD), or one or more processors executing software instructions that cause one or more processors to perform the actions. In some embodiments, the circuitry of a particular element is selected, arranged, and configured by one or more computer-implemented design tools. For example, in some embodiments, the sequence of operations for a particular element is defined in a specified computer language (such as register-transfer language), and the computer-implemented design tools select, configure, and arrange the circuitry based on the defined sequence of operations.

[0046] In this disclosure, in some instances, different entities (which are referred to differently as “components,” “units,” “devices,” “circuits,” “engines,” “workgroups,” “starters,” “interfaces,” etc.) are described or claimed to be “configured” to perform one or more tasks or operations. The expression “[entity] is configured to [perform one or more tasks]” is used herein to refer to a structure (e.g., a physical element (such as an electronic circuit) or an algorithm in software executed by such a physical element). More specifically, this expression is used to indicate that the physical structure is arranged to perform the one or more tasks during operation. A structure may be referred to as “configured” to perform a task even when the structure is not currently operating. Thus, an entity described or stated as “configured” to perform a task refers to a physical element (such as a device, circuit, or memory storing program instructions executable to perform the task) or an algorithm executed using that physical element. This phrase is not used herein to refer to intangible things. Furthermore, the term “configured to” is not intended to mean “configurable as.” For example, an unprogrammed field-programmable gate array will not be considered "configured" to perform a particular function, but it may be "configurable" to perform that function after programming. Additionally, the statement in the appended claims that a structure is "configured" to perform one or more tasks is not expressly intended to be interpreted as having components plus functional elements.

[0047] It should be noted that not all activities or elements described above in the general description are essential. A particular activity or part of the apparatus may not be essential, and one or more additional activities may be performed, or elements may be included in addition to those described. Furthermore, the order in which the activities are listed is not necessarily the order in which they are performed. Additionally, these concepts have been described with reference to specific embodiments. However, those skilled in the art will understand that various modifications and changes can be made without departing from the scope of this disclosure as set forth in the following claims. Therefore, the specification and drawings are to be considered illustrative rather than restrictive, and all such modifications are intended to be included within the scope of this disclosure.

[0048] The benefits, other advantages, and solutions to problems have been described above with respect to specific embodiments. However, the benefits, advantages, solutions to problems, and any features that may lead to or make any benefit, advantage, or solution appear or become more significant should not be construed as key, essential, or fundamental features of any or all claims. Furthermore, the specific embodiments disclosed above are merely illustrative, as the disclosed subject matter can be modified and practiced in different but equivalent ways that will be apparent to those skilled in the art who benefit from the teachings herein. No limitation is intended on the details of the constructions or designs shown herein, except as described in the following claims. Therefore, it will be apparent that the specific embodiments disclosed above can be altered or modified, and all such changes are considered to be within the scope of the disclosed subject matter. Therefore, the protection sought herein is as set forth in the following claims.

Claims

1. An apparatus, the apparatus comprising: A shader engine, the shader engine including a plurality of workgroup processors and a shader program interface SPI, the plurality of workgroup processors being configured to execute shader threads, the shader program interface SPI being configured to assign the shader threads to execute at one or more of the workgroup processors; and A local launcher, associated with one of the plurality of workgroup processors, wherein the local launcher is configured to assign shader threads to execute at the workgroup processor and allocate one or more resources of the shader engine to the workgroup processor to start the shader threads for execution.

2. The apparatus of claim 1, wherein the local initiator is configured to: initiate the shader thread independently of the SPI; or coordinate with the SPI to initiate the shader thread.

3. The apparatus of claim 2, wherein the coordination includes communicating with the SPI to allocate resources for the shader thread.

4. The apparatus of claim 3, wherein the local initiator: obtains the resource by requesting the resource from the SPI; or obtains the resource independently of the SPI.

5. The apparatus of claim 4, wherein the coordination comprises: The acquired resources are notified to the SPI.

6. An apparatus comprising: A shader engine, the shader engine including a plurality of workgroup processors and a shader program interface SPI, the plurality of workgroup processors being configured to execute shader threads, the shader program interface SPI being configured to assign the shader threads to execute at one or more of the workgroup processors; and A local launcher, associated with one of the plurality of workgroup processors, wherein the local launcher is configured to coordinate with the SPI to allocate resources for shader threads executing at the workgroup processor.

7. The apparatus of claim 6, wherein the local initiator: obtains the resource by requesting the resource from the SPI; or obtains the resource independently of the SPI.

8. The apparatus of claim 7, wherein the SPI responds to the request to lease the resource to the local initiator.

9. The apparatus of claim 8, wherein when the shader thread completes execution, the local initiator notifies the SPI, and in response to the notification, the SPI terminates the lease.

10. The apparatus of claim 6, wherein the coordination comprises: The acquired resources are notified to the SPI.

11. A method, the method comprising: A shader thread is started at the workgroup processor using a local initiator associated with both the workgroup processor of the shader engine and the shader program interface SPI, the shader program interface SPI being configured to assign the shader thread to execute at the shader engine, wherein starting includes: assigning the shader thread to execute at the workgroup processor and allocating one or more resources of the shader engine to the workgroup processor.

12. The method of claim 11, wherein the startup is performed independently of the SPI or in coordination with the SPI.

13. The method of claim 12, wherein the local initiator communicates with the SPI to allocate resources for the shader thread.

14. The method of claim 13, wherein the initiation comprises: The resource is obtained by requesting the resource from the SPI.

15. The method of claim 13, wherein the initiation comprises: It acquires resources independently of the SPI and notifies the SPI of the acquired resources.

Images