Historical-based graphic power optimization of perceived power

Abstract

Systems, apparatuses, and methods for implementing efficient power optimization in a computing system are disclosed. The system management unit records an operation frequency required by the computing component to execute the first task. The system management unit stores the recorded frequency of operation in a data array of the computing system or any other predetermined memory location. The system management unit uses the recorded operating frequency to determine an operating frequency for performing one or more other tasks.

Description

Background Art

[0001] Description of Related Technologies

[0002] When designing a computer or other processor - based system, many design factors must be considered. A successful design requires various trade - offs among power consumption, performance, heat output, etc. For example, designing a computer system that emphasizes high performance enables greater power consumption. Conversely, sometimes the design of a battery - powered portable computer system may emphasize reducing power consumption at the expense of some performance. Regardless of the specific design goal, a computing system generally has a given amount of available power during operation. This power must be distributed among the various components within the system - - a portion of the power is allocated to the central processing unit, another portion to the memory subsystem, a portion to the graphics processing unit, and so on. During operation, how power is distributed among the system components may also change.

[0003] Although it should be understood that power must be distributed within the system, how power is distributed can significantly affect system performance. For example, if too much of the system power budget is allocated to a task that achieves a minimal performance improvement, the power distribution efficiency is low. Similarly, for a device where power savings are crucial, if power is distributed solely based on performance improvement, this may also lead to adverse results. Traditionally, the power distribution unit in a computing system may distribute power only by using the parameters available during task execution, without necessarily considering the distribution efficiency and / or the sensitivity of the processing unit to power state changes.

[0004] In view of the above, there is a need for improved systems and methods for efficiently distributing power to a processing system. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The advantages of the methods and mechanisms described herein can 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 another specific implementation of a computing system.

[0008] Figure 3 is a block diagram of a specific implementation of a task scheduler.

[0009] Figure 4 is a block diagram of a specific implementation of a system management unit.

[0010] Figure 5 illustrates a method for recording one or more parameters of a task scheduled to be executed.

[0011] Figure 6 Illustrates a method for performing one or more tasks based on recorded parameters.

[0012] Figure 7 Illustrates a timeline graph depicting changes in the operating frequency during the rendering of a frame. Detailed Description

[0013] In the following description, numerous specific details are set forth to provide a thorough understanding of the methods and mechanisms presented herein. However, one of ordinary skill in the art should recognize that various specific implementations may be practiced without these specific details. In some instances, well-known structures, components, signals, computer program instructions, and techniques have not been shown in detail to avoid obscuring the methods described herein. It should be understood that, for simplicity and clarity of illustration, the elements shown in the figures are not necessarily drawn to scale. For example, the dimensions of some of these elements may be exaggerated relative to other elements.

[0014] Systems, apparatuses, and methods for achieving efficient power optimization in a computing system are disclosed. A system management unit records the operating frequency of a computing component, such as a central processing unit (CPU) or a graphics processing unit (GPU), when performing a first task. In one example, the operating frequency indicates the clock speed of the CPU or GPU. The system management unit stores the recorded operating frequency in a data array of the computing system or any other predetermined memory location. The system management unit then uses the recorded operating frequency to determine the operating frequency for performing one or more other tasks. In doing so, the computing component optimizes the power consumed for performing one or more other tasks. For example, during the execution of a second task similar to the first task (e.g., rendering successive frames in a scene), the computing component operates at a threshold operating frequency without consuming additional power, where the threshold operating frequency is determined using the recorded operating frequency. Additionally, when increasing power consumption results in a greater performance improvement, the computing component consumes additional power for the task. For example, the system management unit may be a system management circuit or a system management circuitry.

[0015] Now refer to Figure 1, a block diagram of a specific implementation of a computing system 100 is shown. In this specific implementation, the illustrated computing system 100 includes a system-on-chip (SoC) 105 coupled to a memory 160. However, a specific implementation where one or more of the illustrated components of the SoC 105 are not integrated onto a single chip is possible and contemplated. In some specific implementations, the SoC 105 includes multiple processor cores 110A through 110N and a GPU 140. In the illustrated specific implementation, the SoC 105, the memory 160, and other components (not shown) are part of a system motherboard 102, and one or more of the peripheral devices 150A through 150N and the GPU 140 are discrete entities (e.g., daughter boards, etc.) coupled to the system motherboard 102. In other specific implementations, the GPU 140 and / or one or more of the peripheral devices in the peripheral devices 150 may be permanently mounted on the board 102 or otherwise integrated into the SoC 105. It should be noted that the processor cores 110A through 110N may also be referred to as processing units or processors. The processor cores 110A through 110N and the GPU 140 are configured to execute instructions of one or more instruction set architectures (ISAs), which may include operating system instructions and user application instructions. These instructions include memory access instructions, which may be translated and / or decoded into memory access requests or memory access operations for the memory 160.

[0016] In another specific implementation, the SoC 105 includes a single processor core 110. In a multi-core specific implementation, the processor cores 110 may be the same as each other (i.e., symmetric multi-core), or one or more cores may be different from the other cores (i.e., asymmetric multi-core). Each processor core 110 includes one or more execution units, cache memory, a scheduler, a branch prediction circuit, etc. In addition, each processor core 110 is configured to issue access requests to the memory 160, which serves as the main memory of the computing system 100. Such requests include read requests and / or write requests, and are initially received by a bridge 120 from the corresponding processor core 110. Each processor core 110 may also include a queue or buffer for holding in-flight instructions that have not yet completed execution. This queue may be referred to herein as an "instruction queue". Some of the instructions in the processor core 110 may still be waiting for their operands to become available, while other instructions may be waiting for an available arithmetic logic unit (ALU). Instructions waiting for an available ALU may be referred to as pending ready instructions. In one specific implementation, each processor core 110 is configured to keep track of the number of pending ready instructions.

[0017] In the illustrated specific implementation, the Input / Output Memory Management Unit (IOMMU) 135 is coupled to the bridge 120. In one specific implementation, in the computing system 100, the bridge 120 serves as a north bridge device, and the IOMMU 135 serves as a south bridge device. In other specific implementations, the bridge 120 can be a fabric, switch, bridge, any combination of these components, or another component. A variety of different types of peripheral buses (e.g., Peripheral Component Interconnect (PCI) bus, PCI Extended (PCI-X), PCI Express (PCIE) bus, Gigabit Ethernet (GBE) bus, Universal Serial Bus (USB)) can be coupled to the IOMMU 135. Various types of peripheral devices 150A to 150N can be coupled to some or all of the peripheral buses. Such peripheral devices 150A to 150N include (but are not limited to) keyboards, mice, printers, scanners, joysticks, or other types of game controllers, media recording devices, external storage devices, network interface cards, etc. At least some of the peripheral devices 150A to 150N coupled to the IOMMU 135 via the corresponding peripheral bus can use Direct Memory Access (DMA) to issue memory access requests. These requests (which can include read requests and write requests) are transmitted to the bridge 120 via the IOMMU 135.

[0018] In some specific implementations, the SoC 105 includes a Graphics Processing Unit (GPU) 140, which is configured to be coupled to a display 145 (not shown) of the computing system 100. In some specific implementations, the GPU 140 is a separate and different integrated circuit from the SoC 105. The GPU 140 performs various video processing functions and provides the processed information to the display 145 for output as visual information. The GPU 140 can also be configured to perform other types of tasks scheduled to the GPU 140 by an application scheduler. The GPU 140 includes "N" computing units for performing tasks of various applications or processes, where "N" is a positive integer. The "N" computing units of the GPU 140 are also referred to as "processing units". Each computing unit of the GPU 140 is configured to issue an access request to the memory 160.

[0019] In a specific implementation, the memory controller 130 is integrated into the bridge 120. In other specific implementations, the memory controller 130 is separate from the bridge 120. The memory controller 130 receives memory requests transmitted from the bridge 120. Data accessed from the memory 160 in response to a read request is transmitted by the memory controller 130 to the request agent via the bridge 120. In response to a write request, the memory controller 130 receives the request and the data to be written from the request agent via the bridge 120. In the case where there are multiple memory access requests to be processed at a given time, the memory controller 130 arbitrates between these requests. For example, when the power budget allocated to the memory controller 130 limits the total number of requests that can be executed on the memory 160, the memory controller 130 may prioritize critical requests while delaying non-critical requests.

[0020] In some specific implementations, the memory 160 includes multiple memory modules. Each memory module in the memory modules includes one or more memory devices (e.g., memory chips) mounted thereon. In some specific implementations, the memory 160 includes one or more memory devices mounted on a motherboard or other carrier on which the SoC 105 is also mounted. In some specific implementations, at least a portion of the memory 160 is implemented on the die of the SoC 105 itself. Specific implementations with combinations of the above specific implementations are also possible and are contemplated. In a specific implementation, the memory 160 is used to implement a random access memory (RAM) for use with the SoC 105 during operation. The implemented RAM can be a static RAM (SRAM) or a dynamic RAM (DRAM). The DRAM types used to implement the memory 160 include (but are not limited to) double data rate (DDR) DRAM, DDR2 DRAM, DDR3 DRAM, etc.

[0021] Although Figure 1 not explicitly shown in the figure, the SoC 105 may also include one or more cache memories inside the processor core 110. For example, each processor core 110 may include an L1 data cache and an L1 instruction cache. In some specific implementations, the SoC 105 includes a shared cache 115 shared by the processor cores 110. In some specific implementations, the shared cache 115 is a level 2 (L2) cache. In some specific implementations, each of the processor cores 110 has an L2 cache implemented therein, and thus the shared cache 115 is a level 3 (L3) cache. The cache 115 may be part of a cache subsystem including a cache controller.

[0022] In one specific implementation, the system management unit 125 is integrated into the bridge 120. In other specific implementations, the system management unit 125 can be separate from the bridge 120 and / or the system management unit 125 can be implemented as multiple individual components at multiple locations in the SoC 105. The system management unit 125 is configured to manage the power states of the various processing units of the SoC 105. In one specific implementation, the system management unit 125 uses dynamic voltage and frequency scaling (DVFS) to change the frequency and / or voltage of the processing units to limit the power consumption of the processing units to a selected power allocation.

[0023] The SoC 105 includes a plurality of temperature sensors 170A through 170N, which represent any number of temperature sensors. It should be understood that although sensors 170A through 170N are shown on the left side of the block diagram of the SoC 105, the sensors 170A through 170N can be distributed throughout the SoC 105 and / or can be located near the main components of the SoC 105 in an actual specific implementation of the SoC 105. In one specific implementation, there are sensors 170A through 170N for each of the cores 110A through 110N, the computing units of the GPU 140, and other main components. In this specific implementation, each of the sensors 170A through 170N tracks the temperature of the corresponding component. In another specific implementation, there are sensors 170A through 170N for different geographical regions of the SoC 105. In this specific implementation, the sensors 170A through 170N are distributed throughout the SoC 105 and are positioned to track the temperature of different regions of the SoC 105 to monitor for the presence of any hot spots in the SoC 105. In other specific implementations, other schemes for positioning the sensors 170A through 170N within the SoC 105 are possible and are contemplated.

[0024] SoC 105 also includes a plurality of performance counters 175A through 175N, which represent any number and type of performance counters. It should be understood that although the performance counters 175A through 175N are shown on the left side of the block diagram of SoC 105, the performance counters 175A through 175N can be distributed throughout the SoC 105, and / or can be located within the main components of the SoC 105 in the actual implementation of the SoC 105. For example, in one implementation, each of the cores 110A through 110N includes one or more of the performance counters 175A through 175N, the memory controller 130 includes one or more of the performance counters 175A through 175N, the GPU 140 includes one or more of the performance counters 175A through 175N, and other performance counters 175A through 175N are used to monitor the performance of other components. The performance counters 175A through 175N can track various different performance metrics, including the instruction execution rate of the cores 110A through 110N and the GPU 140, the memory bandwidth consumed, the row buffer hit rate, the cache hit rate of various caches (e.g., instruction cache, data cache), and / or other metrics.

[0025] In one implementation, SoC 105 includes a phase-locked loop (PLL) unit 155 that is coupled to receive a system clock signal. The PLL unit 155 includes a plurality of PLLs that are configured to generate corresponding clock signals and distribute them to each of the processor cores in the processor cores 110 and to other components of the SoC 105. In one implementation, the clock signals received by each of the processor cores in the processor cores 110 are independent of each other. Additionally, in this implementation, the PLL unit 155 is configured to separately and independently control and vary the frequency of each of the clock signals provided to the respective processor cores in the processor cores 110. The frequency of the clock signal received by any given processor core in the processor cores 110 can be increased or decreased according to the power state assigned by the system management unit 125. The various frequencies of the clock signals output from the PLL unit 155 correspond to different operating points of each of the processor cores in the processor cores 110. Thus, by varying the frequency of its respective received clock signal, a change in the operating point of a particular one of the processor cores in the processor cores 110 is achieved.

[0026] For purposes of the present disclosure, an operating point may be defined as an operating frequency (or clock frequency), and may also include an operating voltage (e.g., a supply voltage provided to a functional unit). Increasing the operating point of a given functional unit may be defined as increasing the frequency of the clock signal provided to the unit, and may also include increasing its operating voltage. Similarly, decreasing the operating point of a given functional unit may be defined as decreasing the clock frequency, and may also include decreasing the operating voltage. Limiting the operating point may be defined as limiting the clock frequency and / or the operating voltage to a specified maximum value under a particular set of conditions (but not necessarily the maximum limit for all conditions). Thus, when limiting the operating point of a particular processing unit, it may operate at a clock frequency and operating voltage up to the specified value under the current set of conditions, but may also operate at clock frequency and operating voltage values less than the specified value.

[0027] In cases where changing the respective operating points of one or more processor cores 110 includes changing one or more respective clock frequencies, the system management unit 125 changes the state of the digital signal provided to the PLL unit 155. In response to these signal changes, the PLL unit 155 changes the clock frequencies of the affected processing cores 110. Additionally, the system management unit 125 may also cause the PLL unit 155 to inhibit providing the respective clock signals to the corresponding processor cores in the processor cores 110.

[0028] In the illustrated specific implementation, SoC 105 also includes a voltage regulator 165. In other specific implementations, the voltage regulator 165 can be implemented separately from SoC 105. The voltage regulator 165 supplies a power supply voltage to each processor core in the processor cores 110 and also supplies a power supply voltage to other components of SoC 105. In some specific implementations, the voltage regulator 165 provides a power supply voltage that is variable according to a specific operating point. In some specific implementations, each of the processor cores in the processor cores 110 shares a voltage plane. Thus, in this specific implementation, each of the processor cores in the processor cores 110 operates at the same voltage as the other processor cores in the processor cores 110. In another specific implementation, the voltage planes are not shared, and thus the power supply voltage received by each processor core 110 is set and adjusted independently of the corresponding power supply voltage received by the other processor cores 110. Thus, in a specific implementation with non-shared voltage planes, the operating point adjustment including the adjustment of the power supply voltage can be selectively applied to each processor core 110 independently of other operating point adjustments. In the case where changing the operating point includes changing the operating voltage of one or more of the processor cores 110, the system management unit 125 changes the state of the digital signal provided to the voltage regulator 165. In response to the change in the signal, the voltage regulator 165 adjusts the power supply voltage provided to the affected processor core 110. In the case where the power of one of the processor cores in the processor cores 110 is to be removed (i.e., gated), the system management unit 125 sets the state of the corresponding signal in the signal so that the voltage regulator 165 does not supply power to the affected processing core 110.

[0029] In various specific implementations, the computing system 100 can be any one of a computer, a laptop computer, a mobile device, a server, a network server, a cloud computing server, a storage system, or various other types of computing systems or devices. It should be noted that the number of components of the computing system 100 and / or SoC 105 can vary depending on the specific implementation. The number of each component / sub-component can be more or less than the Figure 1 number shown. It should also be noted that the computing system 100 and / or SoC 105 may include Figure 1 other components not shown. Additionally, in other specific implementations, the computing system 100 and SoC 105 are constructed in a manner different from Figure 1 that shown.

[0030] Now turning to Figure 2 , a block diagram of a specific implementation of the system management unit 210 is shown. The system management unit 210 is coupled to the computing units 205A to 205N, the memory controller 225, the phase-locked loop (PLL) unit 230, and the voltage regulator 235. The system management unit 210 can also be coupled to Figure 2One or more other components not shown. Computing units 205A through 205N represent any number and type of computing units (e.g., CPUs, GPUs, FPGAs, etc.), and computing units 205A through 205N may also be referred to as processors or processing units. In some specific implementations, the computing units include either or both of general-purpose computing circuitry and special-purpose computing circuitry. For example, in one specific implementation, at least one computing unit is a central processing unit (CPU), and another computing unit is a graphics processing unit (GPU).

[0031] System management unit 210 includes control unit 240, power distribution unit 215, and power management unit 220. In the example shown, power management unit 220 is shown as including logging unit 202. In some specific implementations, control unit 240 is configured to determine how to allocate power in the computing system. In one scenario, in response to detecting a specific condition, control unit 240 determines the power budget allocated to various circuits within the computing system. In some specific implementations, system management unit 210 provides information for making power allocation decisions to one or both of power distribution unit 215 and power management unit 220. Various such specific implementations and combinations are possible and are contemplated. In one scenario, the above condition is a condition that requires reducing the power consumption of the computing system (or some component(s) of the computing system). Such a condition may occur because the system has reached the maximum allowed power or the allocated power. Alternatively, such a condition may occur due to thermal conditions (e.g., the maximum operating temperature has been reached). In response to detecting the condition, control unit 240 evaluates various parameters, including one or more of the currently running tasks, task types, stages of a given task, and so on. In another scenario, such a condition may be intentionally enforced by some policy / mechanism implemented by the combined hardware and system software / firmware to attempt to reach the software-dependent optimal operating point of the desired power performance settings. In various such specific implementations, when a software application is executing (at runtime), certain attributes of the software application being executed on the hardware are tracked and used when making decisions at each point in time. It should be noted that although power management unit 220 is shown as being included in system management unit 210, in other specific implementations, power management unit 220 and / or logging unit 202 are located elsewhere. For example, in one specific implementation, the location of power management unit 220 and logging unit 202 is with graphics processing unit 140 or some other unit. In such cases, graphics processing unit 140 is allocated a power budget by control unit 240 and power distribution unit 215 and operates to manage the operating frequency of the circuitry within graphics processing unit 140 within the given power budget. These specific implementations and other specific implementations are possible and are contemplated.

[0032] The power distribution unit 215 is configured to allocate a power budget to each of the computing units 205A to 205N, allocate a power budget to the memory subsystem including the memory controller 225, and / or allocate a power budget to one or more other components. For the host system, the total amount of power available to the power distribution unit 215 for distribution to components can be restricted. The power distribution unit 215 receives various inputs from the computing units 205A to 205N, which include the status of the miss state holding registers (MSHRs) of the computing units 205A to 205N, the instruction execution rate of the computing units 205A to 205N, the number of instructions ready to execute pending in the computing units 205A to 205N, the instruction and data cache hit rates of the computing units 205A to 205N, the memory bandwidth consumed, and / or one or more other input signals. The power distribution unit 215 can utilize these inputs to determine whether the computing units 205A to 205N have tasks to perform, and then the power distribution unit 215 can adjust the power budgets allocated to the computing units 205A to 205N based on these determinations (e.g., via the control unit 240). The power distribution unit 215 also receives inputs from the memory controller 225, which include the memory bandwidth consumed, the total number of requests in the pending request queue, the number of critical requests in the pending request queue, the number of non-critical requests in the pending request queue, and / or one or more other input signals. The power distribution unit 215 can utilize the status of these inputs to determine the power budget allocated to the memory subsystem.

[0033] The PLL unit 230 receives the system clock signal and includes any number of PLLs, which are configured to generate corresponding clock signals and distribute these clock signals to each of the computing units 205A to 205N and to other components. The power management unit 220 is configured to transmit control signals to the PLL unit 230 to control the clock frequencies supplied to the computing units 205A to 205N and the clock frequencies supplied to other components. The voltage regulator 235 supplies a power supply voltage to each of the computing units 205A to 205N and supplies a power supply voltage to other components. The power management unit 220 is configured to transmit control signals to the voltage regulator 235 to control the voltages supplied to the computing units 205A to 205N and the voltages supplied to other components. The memory controller 225 is configured to control the memory (not shown) of the host computing system or device. For example, the memory controller 225 issues read, write, erase, refresh, and various other commands to the memory.

[0034] In an exemplary embodiment, the power management unit 220 manages the operating frequency and power consumption of the system in a power management mode. For example, in the power management mode, the power management unit 220 reduces the operating frequency of a computing unit with low sensitivity (or relatively lower sensitivity compared to other computing units) to the clock frequency in order to save power. For example, for a computing unit performing a compute-bound task, the power management unit 220 increases the clock frequency to improve performance. On the other hand, for a memory-bound task, the power management unit 220 does not increase the frequency because such an increase will not result in performance improvement (or the desired improvement).

[0035] The recording unit 202 is configured to record one or more parameters associated with the execution of a given task, such that the power management unit 220 can use the recorded parameters to manage the power consumption of the computing unit for subsequent tasks based on the power budget determined by the power distribution unit 215. In one embodiment, the recording unit 202 determines when to record one or more parameters associated with a given task at least in part based on an indication of a change in the characteristics of a set of tasks including the given task.

[0036] In one example, when a set of tasks includes rendering multiple frames, the recording unit 202 determines that the parameters of a frame need to be recorded when the length of the frame (e.g., the amount of time taken to render the frame, or the number of clock cycles to render the frame) exceeds the length of the previously rendered frame. Additionally, the recording unit 202 triggers the recording of one or more parameters in response to detecting a recording condition, which includes but is not limited to: two or more consecutive frames taking the same (or similar) amount of time to render, two or more consecutive frames being determined to use the same or similar average frequency during rendering, rendering two or more consecutive frames with the same or similar starting frequency, etc.

[0037] In one embodiment, the one or more parameters recorded by the recording unit 202 include at least the operating frequency. In one example, these operating frequencies indicate the clock frequencies supplied to the computing units 205A to 205N and to other components to perform a given task. The recording unit 202 is configured to record the operating frequencies used by the computing unit during the execution of a given task, and then the power management unit 220 uses the recorded operating frequencies to control the clock frequencies supplied to one or more computing components for other subsequent tasks that are "relatively similar to" the given task. In a non-limiting example, when the given task includes rendering a frame, two frames are relatively similar if they have the same length, are consecutive, or are within the same scene.

[0038] Referring to the specific implementation of rendering a frame described above, record the operation frequency used during the rendering of a given portion of the frame and store it in a data array (or other data structure). The frequency used during the rendering of the corresponding portion of the frame can be recognized. For example, each such element of the data structure can be recognized as corresponding to a portion of the frame and each such element stores the corresponding frequency. Then, during the rendering of a later frame, these recorded frequencies are used for the later frame. Other specific implementations are envisioned.

[0039] In another specific implementation, one or more parameters further include the power state of the computing component when performing a given task, and the sensitivity of the computing unit to changes in the power state. In one example, based on the type of task being executed, the type of unit executing the task, the current operating frequency, the current power consumption, etc., the sensitivity of the computing unit to power changes can indicate how sensitive the performance of the unit is to changes in the power state. Based on the recorded power state and the sensitivity of the computing unit to changes in the power state of a given task, the power management unit 220 manages the power consumption of the computing unit for subsequent tasks that are relatively similar to the given task.

[0040] In one specific implementation, the system management unit 210 is supplemented with a power throttling unit (not shown) for managing the power consumption of the computing components of the SoC 105. In one example, when the SoC 105 is not operating in a power management mode (e.g., when the power management unit 220 is disabled, fails, or is otherwise unavailable), the power throttling unit determines the amount of power (or operating frequency) to supply to the computing components. For example, when it is determined to initiate recording of one or more parameters associated with a given task, the power management unit 220 enters an operating mode in which it does not change the operating frequency to manage power consumption (i.e., disables the power management mode of the unit). In the specific implementations described herein, disabling the power management unit 220 and / or the power management mode refers to disabling changes in the operating frequency of the computing unit. For example, as discussed above, temporarily disable the change in the operating frequency of the circuitry associated with rendering a frame. However, even when the power management unit 220 and / or the power management mode is disabled, other power management functions such as the dynamic power management of one or more GPU cores, the GPU deep sleep function, clock gating, etc. can be in an active state. That is, when the power management unit 220 is in an inactive state, the control unit 240 and / or the power throttling unit can continue to determine how to allocate power in the computing system.

[0041] In one specific implementation, since the power management unit 220 is configured to save power in the power management mode, the power consumed by the computing unit executing a set of tasks may be less than the power already allocated by the power distribution unit 215. For example, if a given power budget has been allocated to the computing unit, the computing unit may ultimately consume less power than the power that has been allocated. For example, by throttling or otherwise limiting the operating frequency during the rendering of a frame, the allocated power budget consumed will be less than otherwise. In such cases, there is said to be a power "quota" (i.e., an unused power budget).

[0042] Furthermore, in various specific implementations, in the case where the power management mode is disabled, the computing unit consumes the available power in order to maximize performance. In other words, if it is determined that there is a power quota, the quota is reported to a given unit. In response to detecting that a power quota is available, the operating frequency of a given unit can be increased in order to utilize the available excess power. In such specific implementations, the given unit selects various operating frequencies based on the reported available power. Such reported available power can represent currently unused accumulated power, or previously accumulated unused power. For example, after the power management mode is disabled and there is a power quota (e.g., the power allocated such that it can operate at a higher frequency is still available), the computing unit operates at an operating frequency closer to the maximum allowable frequency rather than at the operating frequency of the throttled value.

[0043] To identify the operating frequencies corresponding to non-power quota periods, one or more methods are used. As will be described in more detail below, the rendering of a frame (or the execution of the type of task being observed) is monitored. If a given condition is detected, it is assumed that any existing (or possibly existing) power quota has been consumed (or "exhausted"). For example, when rendering a frame, if there is a power quota, the operating frequency of the rendering unit can be increased to a relatively high rate, as discussed above. If power throttling is subsequently disabled, as the power quota is consumed, the operating frequency will begin to decrease. At a certain point in time, the operating frequency will no longer reflect the power quota. In this case, since the same (or the same average) frequency is used, the rendering of similar frames will take a similar amount of time. Generally speaking, successive frames are usually highly similar. When a relatively significant change in the rendering time between frames is detected, this usually indicates a scene change. In addition to the rendering time being similar, if the rendering of the first frame has a default starting frequency and the next frame is also rendered at the same starting frequency, this can also indicate such a condition. Once such a condition is detected, in one specific implementation, these exemplary conditions for triggering the recording can indicate that after the power management mode is disabled, the operating frequency has reached a relatively stable state. Other possible scenarios indicating that the operating frequency has reached a relatively stable state are envisioned.

[0044] Then, the operation frequency is recorded, and the operation frequency can be used as a reference operation point for the system management unit 210 to determine the operation frequency for performing other subsequent tasks. Similarly, taking the rendering of frames as described above as an example, when the corresponding operation frequencies are the same when starting to render two consecutive frames, a steady state is considered to be reached. Then, the operation frequency of the second frame is stored as a reference operation point.

[0045] Using these recorded parameters can advantageously facilitate the implementation of efficient power savings because the power quota accumulated by the system management unit 210 is not immediately consumed when it becomes available. In addition, the system management unit 210 continues to manage power consumption based on the recorded frequencies, and the saved power can be used only for tasks where an increase in its power consumption would result in a greater performance improvement.

[0046] Now referring to Figure 3 , a specific implementation 300 of a task scheduler is shown. In one specific implementation, the task scheduler 302 assigns tasks in a task queue to multiple computing units of a SoC (e.g., Figure 1 's SoC 105). The task scheduler 302 receives multiple inputs for determining how to schedule tasks to the various computing units of the SoC. The task scheduler 302 also collaborates with a system management unit (e.g., Figure 2 's system management unit 210) to determine an optimal task schedule for scheduling the tasks to be processed to the computing units of the SoC. The multiple inputs utilized by the task scheduler 302 include the quality of service (QoS) 306 requirements of the queued tasks, the task arrival timestamps 310, and the corresponding device preferences 308 (e.g., CPU, GPU). In other specific implementations, the task scheduler 302 utilizes other inputs to determine an optimal task schedule 314 for the tasks to be processed 312. In various specific implementations, information about the proposed task schedule 314 and the task type 316 is communicated to or otherwise made available to the system management unit 210.

[0047] In one specific implementation, the task scheduler 302 attempts to minimize the execution time of tasks on the assigned computing units and the waiting time of tasks, such that the increase in the temperature of the computing units executing the assigned tasks remains below the currently available temperature margin. The task scheduler 302 also attempts to schedule tasks such that the sum of the execution time of a given task plus the waiting time of the given task remains less than or equal to the time indicated by the QoS setting of the given task. In other specific implementations, other examples of algorithms for the task scheduler are possible and are contemplated.

[0048] In another specific implementation, the system management unit 210 uses the device preference 308 to determine whether a given task is computationally limited or memory limited. Additionally, the system management unit 210 ascertains the power state of the computing unit for executing the given task 312 based on the proposed power state 318. Based on the information regarding whether the task 312 is computationally limited or memory limited, and the power state of the computing unit, the power allocation unit 215 allocates from the power budget the power consumed by the computing unit for executing the task 312. Based on the power allocated by the power allocation unit 215 and the device preference 308, the power management unit 220 is configured to manage the power supply to the computing unit in the following ways: that is, increasing the power supply, decreasing the power supply, or keeping the power supply constant.

[0049] In one example, when the power management unit 220 increases the power supply to the computing unit for executing the given task 312, a portion of the previously accumulated power quota is consumed. On the other hand, if the power supply is decreased, more power quota is accumulated. Additionally, the stability of the power-related parameters or frequency-related parameters during the execution of the task 312 indicates the consumption of the power quota.

[0050] Figure 4 Illustrated is a system management unit 410 including a control unit 422, a power allocation unit 414, and a power management unit 418. The power management unit further includes a recording unit 402 and a workload / domain unit 404. The control unit 422 is configured to determine how to allocate power in the computing system. The power allocation unit 414 is configured to allocate a power budget to one or more computing units (not shown) at least in part based on the tasks received from the task scheduler 406. Additionally, the power management unit 418 manages the operating frequency and power consumption of the system in the power management mode.

[0051] The system management unit 410 is also shown as being configured to receive any number of various system parameters corresponding to the conditions, operations, or states of the system, as shown by 420A to 420N. In the example shown, the parameters are shown to include the operating temperature 420A of a given unit, the current drawn by a given unit 420B, the operating frequency 420C of a given unit, a frame marker 420D (e.g., indicating the start and end of a frame), etc. Other parameters are possible and are contemplated. For example, in some specific implementations, one or more of the parameters 420 also include a frame marker 420D that includes information related to a single frame being rendered, such as the frame length (e.g., the amount of time taken to render the frame), a frame performance marker, a frame start frequency, etc.

[0052] In various embodiments, one or more parameters are reported from other units or parts of the system (e.g., based on sensors, performance counters, other event / validity detection, or other means). In some embodiments, one or more parameters are tracked within the system management unit 410. For example, the system management unit 410 tracks the current power performance state of components within the system, the duration of the power performance state, previously recorded parameters, and so on. Additionally, the system management unit 410 is configured to receive task-related information 406 from a task scheduler (e.g., Figure 3 the task scheduler 302). For example, such information may include the proposed task scheduling, task type, and proposed power state.

[0053] In Figure 4 an example, the workload / domain unit 404 includes data indicating the sensitivity of various parts of the computing system to power state changes. In other embodiments, the workload / domain unit 404 is configured to calculate such data. For example, in one embodiment, the workload / domain unit 404 includes characterization data that is generated by executing various workloads and evaluating the performance associated with power state changes. In some embodiments, the data includes characterization data generated offline. In other embodiments, the data includes characterizations generated at runtime. In yet other embodiments, the characterization data maintained by the workload / domain unit 404 is programmable and can be updated at runtime based on the comparison of predicted power / performance changes with actual power / performance changes. In one embodiment, the workload / domain unit 504 includes circuitry configured to perform calculations representing the relationship between task type, power state changes, and predicted performance changes.

[0054] In some embodiments, the workload / domain unit 404 is also configured to determine how the characteristics of a given task within a given set of tasks differ from previously executed tasks. Any change in a given characteristic can indicate to the recording unit 402 to initiate recording of one or more parameters of the given task. As previously mentioned, when a set of tasks includes rendering a frame, the characteristics at least include the frame length, and the one or more parameters at least include the operating frequency of the computing unit when executing the given task. The recording unit 402 can provide the recorded operating frequency to one or both of the power distribution unit 414 and the power management unit 418 for making power distribution decisions. Various such embodiments and combinations are possible and are contemplated.

[0055] Now turning to Figure 5 , an exemplary method 500 for recording one or more parameters associated with a given task is illustrated. As previously described, the system management unit (e.g., Figure 4The system management unit 410) is configured to record one or more parameters associated with the execution of a given task. In an exemplary embodiment, the one or more recorded parameters may be used by the system management unit 410 to manage the power and performance parameters of one or more subsequent tasks. The system management unit 410 determines a change in the characteristics of a set of tasks, where the given task is part of the set of tasks, and determines whether to trigger recording based on the change. Once it is determined to trigger recording, a recording unit (e.g., Figure 4 recording unit 402) records one or more parameters associated with the given task and stores the recorded parameters in a data array. The recorded parameters are accessed by a power management unit (e.g., power management unit 418) to manage the power and performance of one or more subsequent tasks. In one embodiment, the one or more parameters at least include the operating frequency of a computing unit that executes a set of tasks.

[0056] For simplicity, method 500 is described using an example, where a set of tasks includes a plurality of frames to be rendered by a computing unit, such that the given task represents rendering different frames. In general, Figure 5 the method first determines when to record task parameters without a power budget. As described above, if the length of time to render a frame changes by a certain threshold amount, which may be fixed or programmable, this may indicate that a scene change has occurred. Thus, any previously determined frequency for rendering a frame may no longer be applicable to the new scene. As such, a new frequency for rendering subsequent frames is determined. Additionally, the characteristics of the set of tasks that are checked for change include the length of time taken to render each frame, and the one or more parameters at least include the operating frequency of a given computing unit for rendering a frame. Other examples are envisioned.

[0057] The system management unit determines the characteristics of each frame in a set of frames (block 504). In one specific implementation, the characteristics at least include the length of time for rendering each frame. In an exemplary specific implementation, based on the determined length of each frame, the system management unit determines whether to trigger the recording of the operation frequency associated with the rendering of a given frame (conditional block 506). Whether to trigger such recording is determined by the system management unit at least in part based on the detected change in the frame length of the given frame compared to the previous frame. For example, when the length of a frame differs from the length of the immediately preceding frame by a threshold amount, the system management unit determines to trigger the recording of the operation frequency for that frame. For example, if the frame length has changed by 10% or more, it is assumed that a scene change or other significant change has occurred. In another example, the recording may also be considered triggered when a predetermined period of time (e.g., 10 seconds) has elapsed during the rendering of a set of frames. In this case, the recording is triggered periodically (e.g., at a programmable time period).

[0058] If it is determined not to trigger the recording (conditional block 506, "no" branch), then method 500 continues to block 504, where the system management unit continues to check whether the characteristics of the frame have changed until it is determined that such a change has occurred and / or until a predetermined period of time has elapsed. Otherwise, if it is determined to trigger the recording of the operation frequency associated with the rendering of a given frame (conditional block 506, "yes" branch), then the system management unit disables the power management unit so that frequency throttling is not performed (e.g., not performed by the power management unit 220) in order to reduce power consumption and possibly build or increase the power budget (block 508). Thus, as will be described in conjunction with Figure 7 any existing power budget will be consumed.

[0059] Then, the system management unit determines whether the recording conditions are met (conditional block 510). As described above, the recording conditions include one or more scenarios, including but not limited to: two or more consecutive frames take the same (or similar) amount of time to render, two or more consecutive frames are determined to use the same or similar average frequency during rendering, rendering two or more consecutive frames with the same or similar starting frequencies, etc. This indicates that the operation frequency has reached a relatively stable state.

[0060] If it is determined that the recording conditions are not met (conditional block 510, "no" branch), then the system management unit checks the power consumption of the computing unit, where such consumption may indicate whether the recording can be triggered. In one specific implementation, the system management unit continues to monitor the power consumption of the computing unit to determine when to trigger the recording.

[0061] Once the recording condition is met (conditional box 510, "yes" branch), the recording unit records the operating frequency of a given frame (or, in an alternative embodiment, the operating frequency of a given number of frames and / or a given time period). In various embodiments, the operating frequency used during the rendering of various portions of the frame is recorded. In one embodiment, the recorded operating frequency is stored (e.g., stored in a data array, a location in memory, etc.), and the recorded operating frequency is used by the power management unit to determine the operating frequency to be used during the rendering of other frames rendered after the given frame. Once the recording is complete, the power management unit may also resume operation (box 516). Then, method 500 ends.

[0062] Although the embodiments presented Figure 5 describe the power management unit identifying when to trigger recording and starting to record when the recording condition is met, in other embodiments, the power management unit is configured to continuously record parameters of frames (e.g., operating frequency). In such scenarios, when the recording condition is met, the power management unit obtains the parameters that have been recorded to optimize the operating frequency, as Figure 6 described.

[0063] Now turning to Figure 6 , an exemplary method 600 for performing a task using one or more recorded parameters is illustrated. As mentioned in connection with Figure 5 , the power management unit determines the value of the operating frequency to be used by the computing unit to render one or more frames. In one example, the power management unit determines the operating frequency for rendering a frame based on the power budget allocated to the computing unit scheduled to render the frame.

[0064] In one embodiment, the power management unit monitors one or more tasks queued for execution (box 602). As described previously, the tasks may include frames to be rendered by a given computing unit. Based on the tasks queued for execution at a given one or more computing units, the power management unit determines the power budget allocated to the computing unit to execute the given task (box 604). For example, when a frame is being rendered, the power management unit may determine the power budget allocated for the rendering. In one example, the power allocation unit allocates a power budget to the graphics processing unit, and the power allocation unit is configured to manage the operating frequency of the circuitry within the graphics processing unit within the power budget.

[0065] Then, the power management unit determines whether there is excess power available for boosting the operating frequency (conditional block 606) at least in part based on the power budget. In one particular implementation, for example, when the power management unit adjusts the operating parameters of the processing system to save power, the available power is consumed or accumulated as a power quota. For example, for the execution of a task that is less sensitive to changes in the operating frequency, the power management unit may lower the operating frequency during execution to save power. This saved power indicates the available power quota. In contrast, when executing a task that is more sensitive to the operating frequency, the power management unit may increase the operating frequency to boost performance, and this may indicate the consumption of the power quota.

[0066] If such excess power is not available (conditional block 606, "no" branch), the power management unit may set the operating frequency without boosting (block 608). In an exemplary particular implementation, the power management unit is configured to set the operating frequency based on the performance sensitivity of the task currently being executed. However, if there is excess power available for boosting (conditional block 606, "yes" branch), the power management unit determines the operating mode. In one particular implementation, the power management unit is configured to operate in two operating modes, where, in the first operating mode, the power management unit determines the operating parameters (e.g., the power management mode) for executing the task based on the available power. In the second operating mode, the power management unit adjusts the operating parameters of the given task at least in part based on data recorded for other tasks that are relatively similar to the given task. For example, when the given task includes rendering a frame, if the lengths of two frames are the same, i.e., the execution times of the two frames are the same, then the two frames are relatively similar.

[0067] As shown, when the first operating mode is in effect, the power management unit changes the operating frequency while the given task is being executed based on the available power (block 612). For example, in response to determining that excess power is available, in the first mode, the power management unit boosts the operating frequency to a relatively higher level than the current operating frequency to achieve a potential performance improvement. That is, when the computing unit executes a task that is not sensitive to performance, the power management unit operates to boost performance, thereby utilizing the power quota.

[0068] On the other hand, if the second mode is in effect, i.e., the power management mode is in effect, the power management unit first determines whether the recorded operating frequency is available (conditional block 614). In one particular implementation, the recorded operating frequency can be used as a reference operating point to determine the operating frequency for executing the given task. For example, as described previously, the operating frequency can be identified and recorded during the rendering of a frame and subsequently used to set the operating frequency for rendering subsequent frames.

[0069] If the recorded frequencies are available (conditional block 614, "yes" branch), the power management unit sets the current operating frequency based on these recorded frequencies. That is, by using the recorded frequencies, the power management unit determines how to modify the current operating frequency in order to save power or improve the performance of the task being executed. For example, even when there is a power budget, the power management unit refers to the recorded frequencies to determine the modification to the operating frequency, rather than increasing the operating frequency to the maximum allowable frequency (as operated in the first mode). This can advantageously assist in generating an additional power budget that can be used for performance-sensitive tasks, i.e., for executing tasks where an increase in power would achieve the desired performance improvement.

[0070] If the recorded operating frequencies are not available (conditional block 614, "no" branch), the power management unit stops throttling the existing operating frequency level until a stable operating frequency is reached (block 616). As described previously, recording can be triggered in response to a change in the length of time to render a frame. When a relatively significant change in the rendering time between frames is detected, this typically indicates a scene change. In addition to similar rendering times, if the first frame is rendered at a default starting frequency and the next frame is also rendered at the same starting frequency, this can also indicate such a condition. Once such a condition is detected, in one particular implementation, these exemplary conditions for triggering recording can indicate that the operating frequency has reached a relatively stable state after the power management mode has been disabled. Other possible scenarios indicating that the operating frequency has reached a relatively stable state are envisioned.

[0071] Once a stable frequency is reached, the power management unit records the operating frequency (block 618). These recorded frequencies are then used as reference operating points to modify the operating frequency for subsequent tasks (block 620), as described above.

[0072] In one particular implementation, when the conditions for triggering recording occur, e.g., when the length of a frame changes compared to a previously executed frame, the power management unit continuously records the operating frequency used to render the frame. In addition, once the recorded data is available, the power management unit uses the recorded data to execute other frames until the execution point where recording needs to be performed again. Further, whenever the power management unit determines that the operating frequency used to render a given frame does not match the recorded operating frequency, the power management unit adjusts the operating frequency to match the recorded operating frequency (or uses the recorded operating frequency as a threshold to modify the operating frequency).

[0073] Now turning to Figure 7, an exemplary timeline graph 700 depicting frequency (in megahertz, MHz) modifications during the rendering of a set of frames over a period of time (in microseconds, ms) is illustrated. The graph depicts the change in the operating frequency 706 relative to the maximum allowable frequency 704 during the rendering of multiple frames 702.

[0074] As shown, arrow 708 shows one such execution point for initiating recording. In a particular implementation, at point 708, recording is initiated based on the detection of a condition. In a particular implementation, the condition is that the length of time to render a frame (also referred to as the frame length) has changed. For example, at point 708, the frame length has changed by a given amount (e.g., 10%), which can initiate recording. In various particular implementations, the given amount or condition is programmable. In response to initiating recording, the power management unit disables the power management unit, i.e., the computing unit for executing a set of frames 702 no longer operates in the power management mode.

[0075] Once the power management mode is disabled, the operating frequency 706 is no longer throttled and defaults to the maximum allowable frequency 704, as shown. As the operating frequency 706 increases, the computing unit consumes the additional power (i.e., any power budget) that was previously saved due to throttling, and the operating frequency 706 gradually reaches a steady state. In one example, the steady state is indicated by: two or more consecutive frames taking the same (or similar) amount of time to render, two or more consecutive frames being determined to use the same or similar average frequency during rendering, and / or rendering two or more consecutive frames with the same or similar starting frequencies. Once the steady state is achieved, it is assumed that any previously accumulated power budget has been consumed. As depicted, when additional power (or "power budget") is consumed during execution, the frequency increase due to the additional available power disappears and the operating frequency 706 decreases.

[0076] Once a stable operating frequency is detected, the power management unit begins recording the operating frequency used to render the frames. Additionally, during the period when the operating frequency is relatively stable and recording is being performed, the power management mode remains disabled to ensure no additional modification to the operating frequency 706. As shown, the power management mode is disabled during the period indicated by arrow 710.

[0077] Then, the recorded operation frequency is stored in a location accessible by the power management unit. Additionally, once the recording is complete, the power management unit can also be enabled (i.e., the power management mode). Then, the recorded operation frequency is used as a reference operation point for rendering subsequent frames 702. As seen from FIG. 700, after the recording is complete, the rendering of frame 702 continues in a steady state, and the operation frequency 706 does not rise to the maximum allowable frequency 704. This, in turn, enables the power management unit to generate a power budget, whereas any additional power would otherwise be consumed if the recorded operation frequency were not used as a reference operation point. For example, the power management unit uses the recorded operation frequency to perform tasks where the change in operation frequency is relatively independent of performance (i.e., tasks where performance has a low sensitivity to changes in frequency). During such tasks, the power management unit continues to generate a power budget. The recorded operation frequency is used to render the frames, rather than boosting the operation frequency during the rendering of the frames to utilize the accumulated power budget, and the power budget can be used elsewhere where the change in operation frequency has a greater impact on performance (i.e., for tasks where performance is more sensitive to changes in frequency).

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

Claims

1. A system, the system comprising: A system management unit, the system management unit being configured to: Record one or more first operation frequencies of a computing unit when performing a first task; And Perform a second task at one or more second operation frequencies, wherein the one or more second operation frequencies for performing the second task are selected at least in part based on the one or more first operation frequencies.

2. The system according to claim 1, wherein The first task includes rendering a frame, and the second task includes rendering a frame.

3. The system according to claim 2, wherein, In response to a condition including detecting a scene change, record the one or more first operation frequencies.

4. The system according to claim 3, wherein, In response to the condition, the system management unit is further configured to disable the power management mode of the computing unit until a stable operation frequency is achieved.

5. The system according to claim 1, wherein, The system management unit is further configured to accumulate a power quota when operating in the power management mode.

6. The system according to claim 1, wherein The system management unit is further configured to record the power state associated with the computing unit.

7. The system according to claim 1, wherein Record the one or more first operation frequencies at predetermined periodic intervals.

8. A method, the method comprising: Recording, by a system management unit, one or more first operation frequencies of a computing unit when performing a first task in a set of tasks; And Performing, by the system management unit, a second task in the set of tasks at one or more second operation frequencies, wherein the one or more second operation frequencies for performing the second task are selected at least in part based on the one or more first operation frequencies.

9. The method according to claim 8, wherein, The first task includes rendering a frame, and the second task includes rendering a frame.

10. The method according to claim 8, wherein, In response to identifying a change in at least one characteristic associated with the set of tasks, the system management unit records the one or more first operation frequencies, the at least one characteristic including at least a frame length.

11. The method according to claim 10, the method further comprising, in response to identifying the change in the at least one characteristic associated with the set of tasks, the system management unit disabling the power management mode of the computing unit.

12. The method according to claim 8, the method further comprising the system management unit generating a power quota when performing the set of tasks.

13. The method according to claim 8, wherein, The one or more second operation frequencies are operation frequencies recorded during the execution of the first task.

14. The method according to claim 13, wherein, Record the one or more first operation frequencies during the period when the power management mode is enabled.

15. A computing system, the computing system comprising: A central processing unit; A memory controller; And A system management unit, the system management unit being configured to: Record one or more first operation frequencies of a computing unit when performing a first task in a set of tasks; And Perform a second task in the set of tasks at one or more second operation frequencies, wherein the one or more second operation frequencies for performing the second task are selected at least in part based on the one or more first operation frequencies.

16. The computing system according to claim 15, wherein, The first task includes rendering a frame.

17. The computing system according to claim 15, wherein, In response to recognizing a change in at least one characteristic associated with the set of tasks, record the one or more first operating frequencies, where the at least one characteristic includes at least the frame length.

18. The computing system according to claim 17, wherein, In response to recognizing the change in the at least one characteristic associated with the set of tasks, the system management unit is further configured to: Disable the power management mode of the computing unit; and Check the consumption of the power quota, where the power quota is an indication that at least one operating frequency among the one or more first operating frequencies has reached a threshold.

19. The computing system according to claim 15, wherein, The system management unit is further configured to record the power state associated with the computing unit.

20. The computing system according to claim 15, wherein, Record the one or more first operating frequencies at predetermined periodic intervals.

Images