Work drawing scheduler specific implementation

By introducing a global scheduler and a local scheduler into the processor, using a shared cache and independent scheduling mechanism, the problem of long scheduling time in the hierarchical scheduling parallel processor is solved, and more efficient system performance is achieved.

CN119895392APending Publication Date: 2025-04-25ADVANCED MICRO DEVICES INC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202380067307.0
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2022-09-29
Filing Date
2023-09-22
Publication Date
2025-04-25

AI Technical Summary

Technical Problem

In the hierarchical scheduling parallel processor, the scheduling time of the work project is relatively long, resulting in a degradation of system performance.

Method used

Design a processor that includes a global scheduler and multiple local schedulers to communicate through a shared cache, schedule work items independently, and work stealing through a global scheduler when necessary for improved parallelism.

Benefits of technology

It reduces scheduling delay, improves the scheduling efficiency of work items in the work queue, and enhances the overall performance of the system.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119895392A_ABST
    Figure CN119895392A_ABST
Patent Text Reader

Abstract

Systems, apparatus, and methods for implementing a hierarchical scheduler. In various implementations, a processor includes a global scheduler and a plurality of independent local schedulers, where each of the local schedulers is coupled to a plurality of processors. In one implementation, the processor is a graphics processing unit, and the processor is a computing unit. The processor also includes a shared cache that is shared by the plurality of local schedulers. Each of the local schedulers also includes a local cache used by the local scheduler and a processor coupled to the local scheduler. To schedule work items for execution, the global scheduler is configured to store one or more work items in the shared cache and transmit an indication to a first local scheduler of the plurality of local schedulers that causes the first local scheduler to retrieve the one or more work items from the shared cache. After retrieving the work item, the local scheduler is configured to schedule the retrieved work item for execution by a coupled processor. Each local scheduler of the plurality of local schedulers is configured to schedule work items for execution independently of the schedules performed by the other local schedulers.
Need to check novelty before this filing date? Find Prior Art

Description

Background Art

[0001] Related technical description

[0002] Graphics processing applications typically include a workflow of vertex and texture information and instructions for processing such information. The various work items (also called "commands") may be prioritized according to some order and queued in a system memory buffer for subsequent retrieval and processing. The scheduler receives the instructions to be executed and generates one or more commands to be scheduled and executed on a processing resource such as a graphics processing unit (GPU).

[0003] In conventional parallel processors for hierarchical work scheduling, the local scheduler may reside outside the shader engine, so that the local scheduler needs to communicate through additional hierarchy levels, thereby increasing latency, and thus work items in the work queue may have longer scheduling times.

[0004] In view of the foregoing, there is a need for improved systems and methods for hierarchically scheduling work items in a parallel processor. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Advantages of the methods and mechanisms described herein may be better understood by referring to the following description in conjunction with the accompanying drawings, in which:

[0006] Figure 1 is a block diagram of a specific implementation of a computing system.

[0007] Figure 2 is a block diagram of one specific implementation of a graphics processing unit.

[0008] Figure 3 is a block diagram illustrating a parallel processor implementing a hierarchical scheduler.

[0009] Figure 4 is a general flow chart illustrating hierarchical scheduling of work items.

[0010] Figure 5 is a general flow chart illustrating locally scheduling work items in a parallel processor.

[0011] Figure 6 is a generalized flow chart illustrating a method of transmitting work items by a local dispatch controller.

[0012] Figure 7 is a general flow chart illustrating a method for global work scheduling by a processor. DETAILED DESCRIPTION

[0013] In the following description, many specific details are set forth to provide a thorough understanding of the methods and mechanisms presented herein. However, it will be appreciated by those of ordinary skill in the art that various specific implementations may be practiced without these specific details. In some cases, well-known structures, components, signals, computer program instructions, and techniques are not shown in detail to avoid blurring the methods described herein. It should be understood that, for simplicity and clear illustration, the elements shown in the accompanying drawings are not necessarily drawn to scale. For example, the size of some of these elements may be enlarged relative to other elements.

[0014] A system, apparatus and method for implementing a hierarchical scheduler in a computing system, as described herein. In various specific implementations, a processor includes a global scheduler configured to communicate with a plurality of local schedulers, wherein each of the local schedulers is coupled to a plurality of processors. In one specific implementation, the processor is a graphics processing unit and the processor is a computing unit. The processor also includes a shared cache shared by the plurality of local schedulers. Each of the local schedulers also includes a local cache used by the local scheduler and a processor coupled to the local scheduler. In order to schedule work items for execution, the global scheduler is configured to store one or more work items in the shared cache and to transmit an indication to a first local scheduler among the plurality of local schedulers, the indication causing the first local scheduler to retrieve the one or more work items from the shared cache. After retrieving the work item, the local scheduler is configured to schedule the retrieved work item for execution by the coupled processor. Additionally, each local scheduler of the plurality of local schedulers is configured to schedule work items for execution independently of scheduling performed by other local schedulers, and in various implementations direct communication between local schedulers is not required or present. These and other features are described herein.

[0015] Reference now Figure 1 , a block diagram of one implementation of a computing system 100 is shown. In one implementation, computing system 100 includes at least processors 105A-N, control unit 110, input / output (I / O) interface 120, bus 125, memory controller 130, network interface 135, memory device 140, power supply 145, power management unit 150, display controller 160, and display 165. In other implementations, computing system 100 includes other components and / or computing system 100 is arranged in a different manner. Processors 105A-N represent any number of processors included in system 100, where the number of processors varies depending on the implementation.

[0016] In one implementation, processor 105A is a general purpose processor, such as a central processing unit (CPU). In one implementation, processor 105N is a data parallel processor with a highly parallel architecture. Data parallel processors include graphics processing units (GPUs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc. In one implementation, processor 105N is a GPU that provides pixels to display controller 160 to drive to display 165. In some implementations, processors 105A-N include multiple data parallel processors. In one implementation, control unit 110 is a software driver executed on processor 105A. In other implementations, control unit 110 includes control logic independent of processors 105A-N and / or incorporated in processors 105A-N. Typically, control unit 110 is any suitable combination of software and / or hardware.

[0017] The memory controller 130 represents any number and type of memory controllers accessed by the processors 105A-N. The memory controller 130 is coupled to any number and type of memory devices 140. The memory devices 140 represent any number and type of memory devices. For example, the types of memory in the memory devices 140 include dynamic random access memory (DRAM), static random access memory (SRAM), NAND flash memory, NOR flash memory, ferroelectric random access memory (FeRAM), etc.

[0018] The I / O interface 120 represents any number and type of I / O interfaces (e.g., a peripheral component interconnect (PCI) bus, a PCI-Extended (PCI-X), a PCIE (PCI Express) bus, a Gigabit Ethernet (GBE) bus, a Universal Serial Bus (USB)). Various types of peripheral devices (not shown) are coupled to the I / O interface 120. Such peripheral devices include (but are not limited to) a display, a keyboard, a mouse, a printer, a scanner, a media recording device, an external storage device, a network interface card, etc. The network interface 135 is used to receive and send network messages over a network. The bus 125 represents any type of bus or structure having any number of links for connecting different components of the system 100 together.

[0019] In one implementation, queue 142 is located in memory device 140. In other implementations, queue 142 is stored in other locations within system 100. Queue 142 represents any number and type of queues allocated in system 100. In one implementation, queue 142 stores rendering tasks to be performed for frames being rendered. In one implementation, rendering tasks are queued in queue 142 based on input received via network interface 135. For example, in one scenario, input is generated by a user of a video game application and sent to system 100 over a network (not shown). In another implementation, input is generated by a peripheral device connected to I / O interface 120.

[0020] In one implementation, the power management unit 150 manages the supply of power from the power supply 145 to the components of the system 100, and the power management unit 150 controls various power performance states of the components within the system 100. In response to receiving updates from the control unit 110, the power management unit 150 causes other components within the system 100 to increase or decrease their current power performance states. In various implementations, changing the power performance state includes changing the current operating frequency of the device and / or changing the current voltage level of the device. When the power performance state of the processor 105A-N is reduced, this generally results in taking longer to complete the computing task that the processor 105A-N is performing.

[0021] In one implementation, the control unit 110 sends a command to the power management unit 150 to operate one or more processors 105 in a relatively high power performance state in response to determining that the number of tasks of the processor exceeds a threshold, a specific quality of service requirement needs to be met, etc.

[0022] In various implementations, computing system 100 is a computer, a desktop computer, a mobile device, a server, or any of various other types of computing systems or devices. It should be noted that the number of components of computing system 100 varies from implementation to implementation. For example, in other implementations, there are more than 100 components. Figure 1 More or less than the number of each component shown. Note also that in other implementations, the computing system 100 includes Figure 1 Other components not shown in the figure and / or one or more components of the components shown in the computing system 100 are omitted. In addition, in other specific implementations, the computing system 100 is configured to be different from Figure 1 Constructed in the manner shown.

[0023] Now turn to Figure 2, which shows a block diagram of another specific implementation of the computing system 200. In one specific implementation, the system 200 includes a GPU 205, a system memory 225, and a local memory 230, which belongs to the GPU 205. The system 200 also includes other components not shown to avoid obscuring the figure. The GPU 205 includes at least a command processor 235 (also known as a "global scheduler"), a shader engine 280, a memory controller 220, a shared cache 270, a level 1 (L1) cache 265, and a level 2 (L2) cache 260. In one specific implementation, each of the shader engines 280 includes a plurality of workgroup processors 282, wherein each workgroup processor includes one or more compute units 255. In various specific implementations, each compute unit includes one or more single instruction multiple data (SIMD) processors. It should be noted that the compute units 255 may also be referred to herein as "multiple processing elements". In other specific implementations, the GPU 205 includes other components, omitting one or more of the components shown, having multiple instances of the components (even if Figure 2 In one embodiment, the circuitry of GPU 205 includes ( Figure 1 ) processor 105N.

[0024] In various implementations, computing system 200 executes any of a variety of types of software applications. As part of executing a given software application, a host CPU (not shown) of computing system 200 issues a rendering task to be executed on GPU 205. Command processor 235 receives commands from the host CPU and issues corresponding rendering tasks to compute unit 255. The rendering tasks executed on compute unit 255 read and write data to global data share 270, L1 cache 265, and L2 cache 260 within GPU 205. Although not shown in FIG. Figure 2 200, but in one implementation, the compute units 255 also include one or more caches and / or local memories within each compute unit 255. In various implementations, the compute units 255 execute any number of frame-based applications that are rendering frames to be displayed, streamed, or consumed in real time. In one implementation, the queues 232 are stored in the local memory 230. In other implementations, the queues 232 are stored in other locations within the system 200. The queues 232 represent any number and type of queues allocated in the system 200. In one implementation, the queues 232 store rendering tasks to be performed by the GPU 205.

[0025] In one specific implementation, the performance settings of GPU 205 are adjusted based on the number of rendering tasks for the current frame stored in queue 232 and based on the amount of time remaining before the next video sync signal. In various specific implementations, the performance settings of GPU 205 are adjusted so that the rendering tasks are completed before the next video sync signal while also achieving power consumption targets. In one specific implementation, the performance settings are adjusted by a control unit (not shown). The control unit can be a software driver executed on a CPU (not shown), or the control unit can include control logic implemented in a programmable logic device (e.g., FPGA) or control logic implemented as dedicated hardware (e.g., ASIC). In some cases, the control unit includes a combination of software and hardware.

[0026] In one implementation, the performance setting of the GPU 205 corresponds to a specific power setting, power state, or operating point of the GPU 205. In one implementation, the control unit uses dynamic voltage and frequency scaling (DVFS) to change the frequency and / or voltage of the GPU 205 to limit power consumption to the selected power allocation. Each individual frequency and voltage setting may correspond to an individual performance setting. In one implementation, the performance setting selected by the control unit controls a phase-locked loop (PLL) unit (not shown) that generates a corresponding clock signal and distributes it to the GPU 205. In one implementation, the performance setting selected by the control unit controls a voltage regulator (not shown) that provides a supply voltage to the GPU 205. In other implementations, other mechanisms may be used to change the operating point and / or power setting of the GPU 205 in response to receiving a command from the control unit to reach a specific performance setting.

[0027] In various implementations, the shader engines 280 correspond to different scheduling domains. In a specific implementation, each shader engine 280 also includes a local work graph scheduler (WGS) (also interchangeably referred to as a local scheduler) associated with a set of work group processors (WGP) 282, local caches, and asynchronous dispatch controllers (ADCs). The various schedulers and command processors described herein handle queue-level allocations. During work execution, the WGS executes work locally in an independent manner. In other words, the work group scheduler of a given shader engine can schedule work without considering the local scheduling decisions of other shader engines, that is, the WGS does not interact with other WGSs of other scheduling domains. Instead, the local scheduler uses a private memory area for scheduling and as a scratch space. Figure 3 An example implementation of a processor including the above elements is illustrated in FIG.

[0028] Now go to Figure 3, a parallel processor 300 implementing hierarchical scheduling domains is shown. In a specific implementation, the parallel processor 300 includes a plurality of scheduling domains 304. Each scheduling domain 304 corresponds to a shader engine. As shown, each shader engine 304 includes a plurality of work group processors (WGPs) 308, wherein each work group processor includes one or more computing units (not shown). Each of the shader engines 304 is configured to execute a plurality of work items received from a command processor (also referred to as a "global scheduler") 316 outside the scheduling domain 304. In a specific implementation, each scheduling domain also includes a local work graph scheduler (WGS) 306 (or "local scheduler") and a local cache 310. Each shader engine 304 also includes an asynchronous dispatch controller (ADC) 312, which is configured to emit locally scheduled work to distribute work items received by the global processor 316. In a specific implementation, the ADC 312 can execute the emitter thread to the WGS 306 by selecting one or more work items from the external cache 314. In various implementations, while each of the shader engines 304 includes a local cache 310, the cache 314 is shared by the shader engines 304. In this manner, data may be communicated between the shader engines 304. In an exemplary implementation, each of the WGS and the global scheduler may access a separate mailbox that a given entity may use to communicate with another entity in the system without using the main memory subsystem of the parallel processor 300. In one example, a dedicated mailbox 320 for the global scheduler may be located in the cache 314. Additionally, each WGS 306 may also have a dedicated mailbox 322, which, in one implementation, may be located in the cache 310 associated with the WGS 306. Other possible locations for the dedicated mailboxes are contemplated and within the scope of the present disclosure.

[0029] In a specific implementation, the WGS 306 is configured to directly access the local cache 310, thereby avoiding the need to communicate through a higher level scheduling hierarchy. In this way, scheduling latency is reduced and finer granularity scheduling can be achieved. That is, the WGS 306 can schedule work items to one or more WGPs 308 more quickly and on a more local basis. In addition, the structure of the shader engine 304 allows a single WGS 306 to be used for each shader 304, thereby making the shader engine 304 easier to expand. For example, because each shader engine in the shader engine 304 is configured to perform local scheduling, additional shader engines can be easily added to the processor.

[0030] In operation, the WGS 306 is configured to communicate with one or more WGPs 308 via a local cache 310. The WGS 306 is further configured to receive a first set of work items from a global processor 316 and schedule the first set of work items for execution by the WGP 308. In one specific implementation, the first set of work items is transmitted as a wave group by the ADC 312 via the local cache 310. The ADC 312 located directly within the shader engine 304 builds the wave group to be transmitted to the one or more WGPs 308. In one specific implementation, the WGS 306 schedules the work items to be transmitted to the one or more WGPs 308, and then communicates the work schedule directly to the ADC 312 using local atomic operations (or "functions"). In a specific implementation, the scheduled work items are stored in one or more local work queues stored in the local cache 310. In addition, the ADC 312 builds a wave group including the scheduled work items stored in the one or more local work queues, and then transmits the scheduled work items to the one or more WGPs 308 as a wave group. However, in some implementations, one or more WGPs may also be configured to support a given local scheduler running on the WGS to offload processing tasks, thereby assisting the WGS scheduling operations.

[0031] In a specific implementation, once the first set of work items is consumed at one or more WGPs 308, the WGS 306 can notify the global processor 316 through the external cache 314 using one or more global atomic operations. In one example, the WGS 306 writes an underutilization signal to the external cache 314 to indicate that it is currently underutilized (i.e., capable of performing more work than it is currently performing). The global processor 316 detects the underutilization indication by accessing the external cache 314. In one specific implementation, in response to detecting such underutilization indication, the global processor 316 is configured to identify a second set of work items of the WGS 306. In one example, the global processor 316 queries one or more different shader engines 302 in the same hierarchical level to identify the remaining work items from such one or more shader engines 302. Once these work items are identified, these work items are stored in the external cache 314, from which they are scheduled by the WGS 306 and transmitted by the ADC 312 to the one or more WGPs 308.

[0032] As previously described, the parallel processor 300 includes a plurality of shader engines 302, each having at least one WGS 306 for local scheduling operations. In one specific implementation, each WGS 306 in a given shader engine is configured to operate independently of the WGS 306 in one or more other shader engines 302. That is, the WGS 306 of a given shader engine 302 does not communicate with other WGS 306 located in another shader engine 302.

[0033] Now turn to Figure 4 , a specific implementation of a method 400 for scheduling work items is shown. A local scheduler receives one or more work items from a global scheduler (block 402). In a specific implementation, the local scheduler is included in a shader engine of a parallel processor. In one example, the local scheduler selects one or more work items from an external cache associated with the global scheduler. Once the local scheduler obtains the work item for consumption, the local scheduler schedules the new work item for execution by the work group processor of the shader engine. The dispatching of the work item to the work group processor is accomplished via an asynchronous dispatch controller (ADC), which dispatches / transmits one or more work items to one or more work group processors included in the shader engine (block 404). In a specific implementation, the local scheduler writes the work item to a local queue in a local cache of the shader engine, and the ADC transmits the work item to one or more work group processors from the local queue. In addition, the WGP is configured to allocate, de-allocate, and use the local cache as needed during processing. In various specific implementations, if the identified work item is too large to be dispatched, the work is divided into smaller work items before queuing them for dispatch.

[0034] When the local scheduler has queued the work item for dispatch, the local scheduler stores an indication (e.g., a command) for the ADC to indicate that the work is ready to be executed. For example, the command may be queued in a command queue monitored by the ADC. When the ADC detects such a command, the ADC starts transmitting the work item to the workgroup processor. In one specific implementation, the ADC communicates with the workgroup processor to identify the location of the work to be consumed in the local cache. In response to the indication from the ADC, one or more workgroup processors may consume one or more work items (box 406). When the workgroup processor processes the work item, zero, one or more new work items may be generated. If a new item is generated (box 407), the new item is queued or otherwise stored locally (box 409), and it is determined whether the shader engine is considered to be overloaded due to excessive work (box 411). In various specific implementations, determining that the shader engine is overloaded includes comparing the number of work items with a threshold, the number of work items currently waiting for local scheduling (i.e., pending work items), etc. If this situation is not detected, the process returns to box 404, where processing continues.

[0035] If an overload condition is detected (block 411), the global scheduler is notified (block 413), and one or more work items are sent (or "exported") from the shader engine to the external shared cache 415. In this way, work items are transferred from one shader engine to another shader engine. In various specific implementations, when an overload condition is detected, the local scheduler transmits a signal, stores an indication at a location accessible to the global scheduler, or otherwise alerts the global scheduler. After exporting one or more work items, if the work item is still in the shader engine (block 408), processing continues at block 404. Otherwise, if the local scheduler determines that there is no work item available for scheduling (conditional block 408, "no" branch), the local scheduler provides an underutilized indication at the external cache of the global processor (block 410). In a specific implementation, the global processor detects the underutilized indication via the external cache and transmits the corresponding indication to another shader engine. In response, the other shader engine exports the remaining work items and writes the work items to the external shared cache so that the work items can be used for redistribution. After the new work item is available at the external cache, the local scheduler may retrieve (or otherwise receive) the new work item to be scheduled (block 412) and write the new work item to its local cache. Once the local scheduler picks the new work item, the method continues to block 404, where the ADC may transmit the new work item for consumption at one or more work group processors, as described above.

[0036] Now turn to Figure 5, shows a specific implementation of a method 500 for scheduling work items. A local scheduler of a shader engine is configured to schedule one or more work items for processing by a workgroup processor of the shader engine (block 502). In an example, the local scheduler may use local atomic operations to schedule work items written to a local queue in a local cache of the shader engine. In the event that the local scheduler determines that the local queue is empty (conditional block 504, "yes" branch), the local scheduler may notify a global scheduler (e.g., Figure 3 The local scheduler has no work to schedule. In response, the global scheduler is configured to determine whether other shader engines have excess work available. If so, the global scheduler dispatches the excess work by storing it in a cache shared by the shader engines (e.g., Figure 3 The global scheduler then dispatches the exported work to the shader engine that previously indicated that it had no work. In response, the local scheduler retrieves and schedules work for execution on the shader engine. In this way, work that would have remained queued on another shader engine can begin execution, and overall parallelism and performance are improved. This may be referred to as "stealing work" from another shader engine, and the indication provided by the shader engine that it has lost work may be referred to as a "work stealing" indication (block 510). In a specific implementation, the local scheduler may send work stealing by storing an underutilization indication in the external cache of the global processor.

[0037] Otherwise, if the local queue is not empty (conditional block 504, "no" branch), the local scheduler determines whether a work item is available for queuing (conditional block 506). If no work item is to be queued (conditional block 506, "no" branch), the local scheduler issues work stealing again as shown in block 510. Otherwise, if a work item is available for queuing (conditional block 506, "yes" branch), the local scheduler further determines whether at least one work item includes a draw call (conditional block 508). If no work item indicates a draw call, the method 500 may terminate (conditional block 508, "no" branch). Otherwise, the local scheduler issues a draw call (block 512). Then, the local scheduler may again queue work items to be scheduled (block 514), and the method 500 may continue to block 502, where these queued work items are scheduled by the local scheduler.

[0038] Now turn to Figure 6, a specific implementation of a method 600 for transmitting a work item by a dispatch controller (ADC) is shown. In various specific implementations, when a local scheduler of a shader engine initiates the scheduling of a work item, the local scheduler stores or otherwise transmits an indication that can be detected by the ADC. The indication includes a command (601) stored in a command queue monitored by the ADC. If the ADC determines that the work item to be emitted is available (conditional block 602, "yes" branch), the ADC initiates the emission of the available work item to the work group processor. The ADC identifies one or more WGPs to which the work will be distributed and the location where the work item is currently stored in the local cache (block 604). For example, in one specific implementation, the WGP and the work item location are indicated by a command. Based on the command, the ADC communicates with the identified WGPs to cause them to consume the work item (block 606). In the case where the ADC determines that no work item is available for emission (conditional block 602, "no" branch), the ADC continues to monitor (block 601).

[0039] Now turn to Figure 7 , shows a specific implementation of a method for global scheduling of work items. The global scheduler starts all local schedulers in a given hierarchy (block 702). For example, referring to Figure 3 , all local schedulers 306 of the shader engine 304 correspond to the same level in the scheduling hierarchy. Once these local schedulers are started, the global processor distributes work items to each started local scheduler (block 704). In a specific implementation, the global processor can store work items in an external shared cache (e.g., Figure 3 The external cache may store the work items in a work queue local to the global processor, from which the global processor distributes the work items to the local scheduler. The global scheduler may then communicate a signal directly to the local scheduler indicating that work is available and where the work is stored. In response, the local scheduler may retrieve and schedule the work items, such as Figure 5 described.

[0040] Then, the global processor may determine whether there are one or more work items to be distributed (conditional block 706). If the global processor determines that the work items are available in the local queue (conditional block 706, "yes" branch), the global processor selects a local scheduler to distribute the remaining work items (box 710). Otherwise, if there are no remaining work items in the local queue (conditional block 706, "no" branch), the global processor determines whether there are work items to be distributed in the global queue (conditional block 708). If such work items are available (conditional block 708, "yes" branch), the method 700 continues to box 710, where the global processor selects one or more local schedulers to distribute the work items. Otherwise, if there are no such work items remaining (conditional block 708, "no" branch), the global processor may determine whether all local schedulers are exhausted (i.e., have completed their work) (conditional block 712). If the global processor determines that all local schedulers are exhausted (conditional block 712, "yes" box), the method 700 ends. However, if all local schedulers have not been exhausted (conditional block 712, "no" block), the global scheduler attempts to steal work from one or more shader engines to distribute to other shader engines (block 714). As described above, when a shader engine has excess work, such work can be redistributed to other shader engines that have no (or less) work to improve overall performance. Method 700 continues to block 702, and the process repeats.

[0041] In some implementations, the local scheduler is configured to monitor / poll memory locations for indications that work is available. For example, a dedicated memory location (or "mailbox") is maintained for each local scheduler, in which a semaphore type indication is maintained. When the global scheduler has work for a given local scheduler, the global scheduler stores an indication or message for the given local scheduler in its mailbox. In various implementations, the local scheduler may use the mailbox to communicate with the global scheduler. For example, the local scheduler may notify the global scheduler that the local scheduler needs more work by writing to the mailbox. These and other implementations are possible and contemplated.

[0042] In other specific implementations, each local scheduler (i.e., WGS) in the shader engine can access a dedicated mailbox to communicate with the global scheduler in a point-to-point manner. That is, whenever the local scheduler communicates with the global scheduler (e.g., to transmit work stealing, overload or other indications), the local scheduler bypasses the internal memory subsystem of the parallel processor and sends a message directly to the dedicated mailbox associated with the global scheduler. In addition, the global scheduler can access the messages stored in the dedicated mailbox and respond with appropriate messages, which are then stored in the dedicated mailbox of the local scheduler. In a specific implementation, each local scheduler can only access a single mailbox, while the global scheduler can access multiple mailboxes. In several other specific implementations, one or more mailboxes can also be implemented in a work graph processor (WGP) based on various specific implementations of the parallel processor described herein. In the example, each WGP can be associated with a dedicated mailbox, and similar to the mailbox implemented for the local scheduler, each WGP can only access a single mailbox at a time to communicate separately with another WGP, a local scheduler or a global scheduler.

[0043] It should be emphasized that the above specific implementation is only a non-limiting example of a specific implementation. Once the above disclosure is fully understood, many variations and modifications will become apparent to those skilled in the art. It is intended that the following claims be interpreted as covering all such variations and modifications.

Claims

1. A processor, comprising: Global scheduler; a plurality of local schedulers, each local scheduler being coupled to the plurality of processors; and Shared cache; In response to detecting an instruction from the global scheduler, one of the plurality of local schedulers is configured to: retrieving one or more work items from the shared cache; and The one or more work items are scheduled for execution.

2. The processor of claim 1, wherein each of the local schedulers is coupled to a local cache, and each local scheduler is configured to store work items to be executed in the local cache.

3. The processor of claim 2, wherein each of the local schedulers is coupled to a dispatch controller, the dispatch controller being configured to emit work items stored in the local cache for execution.

4. The processor of claim 3, wherein the dispatch controller is configured to monitor a command queue configured to store commands from a local scheduler, the commands indicating that work items ready for execution have been stored in the local cache. 5 . The processor of claim 1 , wherein each local scheduler of the plurality of local schedulers is configured to schedule work items for execution independently of the other local schedulers.

6. The processor of claim 1 , wherein to schedule work items for execution, the global scheduler is configured to: storing one or more work items in the shared cache; and An indication is transmitted to a first local scheduler of the plurality of local schedulers to cause the first local scheduler to retrieve the one or more work items from the shared cache.

7. The processor of claim 6, wherein the indication identifies a location in the shared cache where the one or more work items are stored.

8. The processor of claim 1 , wherein to transfer the selected work item from a first local scheduler of the plurality of local schedulers to a second local scheduler of the plurality of local schedulers, the processor is configured to: causing the first local scheduler to store the selected work item in the shared cache; and An indication is transmitted to the second local scheduler, the indication causing the second local scheduler to retrieve the selected work item from the shared cache.

9. The processor of claim 8, wherein the processor is configured to transfer the selected work without direct communication between the first local scheduler and the second local scheduler.

10. A method comprising: detecting, by a local scheduler of a processor, an indication from a global scheduler of the processor; Responsive to the indication, retrieving one or more work items from the shared cache; as well as The one or more work items are scheduled by the local scheduler for execution by one or more processors coupled to the local scheduler.

11. The method according to claim 10, further comprising: Work items to be executed in a local cache are stored by the local scheduler.

12. The method according to claim 11, further comprising: The work items are transmitted from the local cache to the processor by a dispatch controller.

13. The method according to claim 12, further comprising: A command queue is monitored by the dispatch controller, the command queue being configured to store commands from the local scheduler indicating that the work items ready for execution have been stored in the local cache.

14. The method according to claim 10, further comprising: The local scheduler schedules the one or more work items independently of one or more other local schedulers of the processor, wherein the global scheduler is a first level of a hierarchical scheduler and the local scheduler and the one or more other local schedulers are a second level of the hierarchical scheduler.

15. The method of claim 10, wherein to schedule the work items for execution, the method comprises the global scheduler: storing one or more work items in the shared cache; and An indication is transmitted to a first local scheduler of a plurality of local schedulers to cause the first local scheduler to retrieve the one or more work items from the shared cache.

16. The method of claim 15, wherein the indication identifies a location in the shared cache where the one or more work items are stored.

17. The method according to claim 10, further comprising: Transferring the selected work item from a first local scheduler of a plurality of local schedulers to a second local scheduler of the plurality of local schedulers, wherein the transferring comprises: causing the first local scheduler to store the selected work item in the shared cache; and An indication is transmitted to the second local scheduler, the indication causing the second local scheduler to retrieve the selected work item from the shared cache.

18. The method of claim 17, wherein the processor is configured to transfer the selected work without direct communication between the first local scheduler and the second local scheduler.

19. A computing system, the computing system comprising: Central processing unit; Memory controller; and A graphics processing unit, the graphics processing unit comprising: Global scheduler; a plurality of local schedulers, each local scheduler coupled to the plurality of processors; and Shared cache; In response to detecting an instruction from the global scheduler, one of the plurality of local schedulers is configured to: retrieving one or more work items from the shared cache; and The one or more work items are scheduled for execution.

20. The computing system of claim 19, wherein the global scheduler is configured to communicate with the plurality of local schedulers via the shared cache.