Power-Aware History-Based Graphics Power Optimization

Abstract

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

Description

[Background technology]

[0001] Description of Related Art Many design factors must be considered during the design of a computer or other processor-based system. A successful design requires various trade-offs between power consumption, performance, thermal output, etc. For example, a computer system design that emphasizes high performance may allow for greater power consumption. Conversely, a portable computer system, sometimes powered by a battery, may emphasize reduced power consumption, even at the expense of some performance. Regardless of the specific design goals, a computing system typically has a certain amount of power available during operation. This power must be allocated among the various components within the system, such as allocating a portion to the central processing unit, another portion to the memory subsystem, and a portion to the graphics processing unit. How power is allocated among the system components may change during operation.

[0002] It is understood that power must be allocated within a system, but how power is allocated can significantly affect system performance. For example, if too much of the system power budget is allocated to tasks that offer the smallest performance gain, the power allocation will be inefficient. Similarly, for devices where power conservation is paramount, if power allocation is based solely on performance improvement, this can also produce undesirable results. Traditionally, a power allocation unit in a computing system may allocate power by simply using parameters available at the time a task is executed, without necessarily considering the allocation efficiency and / or sensitivity of the processing unit to power state changes.

[0003] In view of the above, there is a need for improved systems and methods for efficient allocation of power to a processing system.

[0004] Advantages of the methods and mechanisms described herein may be better understood by referring to the following description taken in conjunction with the accompanying drawings. [Brief explanation of the drawings]

[0005] [Figure 1] FIG. 1 is a block diagram of one embodiment of a computing system. [Figure 2] FIG. 2 is a block diagram of another embodiment of a computing system. [Figure 3] FIG. 2 is a block diagram of one embodiment of a task scheduler. [Figure 4] FIG. 2 is a block diagram of one embodiment of a system management unit. [Figure 5] FIG. 1 illustrates a method for recording one or more parameters of a task scheduled to be executed. [Figure 6] FIG. 1 illustrates a method for performing one or more tasks based on recorded parameters. [Figure 7] FIG. 10 is a timeline graph showing changes in operating frequency during the rendering of a frame. DETAILED DESCRIPTION OF THE INVENTION

[0006] In the following description, numerous specific details are set forth to provide a thorough understanding of the methods and mechanisms presented herein. However, those skilled in the art should recognize that various embodiments 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 techniques described herein. It should be understood that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some elements may be exaggerated relative to other elements.

[0007] A system, apparatus, and method for performing efficient power optimization in a computing system are disclosed. A system management unit records an operating frequency at which a computing component, such as a central processing unit (CPU) or a graphics processing unit (GPU), operates to perform a first task. The operating frequency, in one example, indicates the clock speed of the CPU or GPU. The system management unit saves the recorded operating frequency in a data array or any other predetermined memory location in the computing system. The system management unit then uses the recorded operating frequency to determine an operating frequency for the execution of one or more other tasks. In doing so, the computing component optimizes the power consumed to perform the 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, and the threshold operating frequency is determined using the recorded operating frequency. Furthermore, the computing component consumes additional power for a task if increasing power consumption provides a greater performance improvement. As an example, the system management unit may be a system management circuit or system management circuitry.

[0008] Referring now to FIG. 1 , a block diagram of one embodiment of a computing system 100 is shown. In this embodiment, the illustrated computing system 100 includes a system-on-chip (SoC) 105 coupled to a memory 160. However, embodiments in which one or more of the illustrated components of the SoC 105 are not integrated on a single chip are possible and contemplated. In some embodiments, the SoC 105 includes multiple processor cores 110A-110N and a GPU 140. In the illustrated embodiment, the SoC 105, memory 160, and other components (not shown) are part of a system board 102, while one or more of the peripherals 150A-150N and the GPU 140 are separate entities (e.g., daughterboards, etc.) coupled to the system board 102. In other embodiments, the GPU 140 and / or one or more of the peripherals 150 may be permanently mounted on the board 102 or otherwise integrated into the SoC 105. Note that processor cores 110A-110N may be referred to as processing units or processors. Processor cores 110A-110N and 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 requests targeting memory 160, or memory access instructions that can be translated and / or decoded into memory access operations.

[0009] In another embodiment, SoC 105 includes a single processor core 110. In a multi-core embodiment, processor cores 110 may be identical to one another (i.e., symmetric multi-core), or one or more cores may be different from the others (i.e., asymmetric multi-core). Each processor core 110 includes one or more execution units, cache memory, a scheduler, branch prediction circuitry, etc. Additionally, each of processor cores 110 is configured to assert access requests to memory 160, which serves as the main memory of computing system 100. Such requests, including read and / or write requests, are initially received from the respective processor core 110 by bridge 120. Each processor core 110 may also include a queue or buffer that holds 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 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 on an available ALU may be referred to as pending ready instructions. In one embodiment, each processor core 110 is configured to track the number of pending ready instructions.

[0010] An input / output memory management unit (IOMMU) 135 is coupled to bridge 120 in the illustrated embodiment. In one embodiment, in computing system 100, bridge 120 functions as a northbridge device and IOMMU 135 functions as a southbridge device. In other embodiments, bridge 120 may be a fabric, a switch, a bridge, any combination of these components, or another component. Several different types of peripheral buses (e.g., peripheral component interconnect (PCI) bus, PCI-Extended (PCI-X), PCI Express (PCI Express) bus, gigabit Ethernet (GBE) bus, universal serial bus (USB)) may be coupled to IOMMU 135. Various types of peripheral devices 150A-150N may be coupled to some or all of the peripheral buses. Such peripherals 150A-150N include (but are not limited to) keyboards, mice, printers, scanners, joysticks, other types of game controllers, media recording devices, external storage devices, network interface cards, etc. At least some of the peripherals 150A-150N coupled to IOMMU 135 via corresponding peripheral buses can assert memory access requests using direct memory access (DMA). These requests, which may include read and write requests, are conveyed to bridge 120 via IOMMU 135.

[0011] In some embodiments, SoC 105 includes a graphics processing unit (GPU) 140 configured to couple to a display 145 (not shown) of computing system 100. In some embodiments, GPU 140 is a separate integrated circuit separate from SoC 105. GPU 140 performs various video processing functions and provides processed information to display 145 for visual output. GPU 140 may also be configured to perform other types of tasks scheduled for GPU 140 by an application scheduler. GPU 140 includes “N” computational units for executing tasks for various applications or processes, where “N” is a positive integer. The “N” computational units of GPU 140 are also referred to as “processing units.” Each computational unit of GPU 140 is configured to assert requests for access to memory 160.

[0012] In one embodiment, memory controller 130 is integrated into bridge 120. In another embodiment, memory controller 130 is separate from bridge 120. Memory controller 130 receives memory requests conveyed from bridge 120. Data accessed from memory 160 in response to a read request is conveyed by memory controller 130 to the requesting agent via bridge 120. In response to a write request, memory controller 130 receives both the request and the data to be written from the requesting agent via bridge 120. If multiple memory access requests are pending at a given time, memory controller 130 arbitrates between the requests. For example, if the power budget allocated to memory controller 130 limits the total number of requests that can be made to memory 160, memory controller 130 can give priority to critical requests while delaying non-critical requests.

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

[0014] Although not explicitly shown in FIG. 1 , SoC 105 may also include one or more cache memories internal to processor cores 110. For example, each of processor cores 110 may include an L1 data cache and an L1 instruction cache. In some embodiments, SoC 105 includes a shared cache 115 shared by processor cores 110. In some embodiments, shared cache 115 is a level two (L2) cache. In some embodiments, an L2 cache is implemented within each of processor cores 110, and thus shared cache 115 is a level three (L3) cache. Cache 115 may be part of a cache subsystem that includes a cache controller.

[0015] In one embodiment, system management unit 125 is integrated into bridge 120. In other embodiments, system management unit 125 may be separate from bridge 120 and / or system management unit 125 may be implemented as multiple separate components in multiple locations on SoC 105. System management unit 125 is configured to manage the power states of various processing units on SoC 105. In one embodiment, system management unit 125 uses dynamic voltage and frequency scaling (DVFS) to vary the frequency and / or voltage of the processing units to limit their power consumption to a selected power budget.

[0016] The SoC 105 includes multiple temperature sensors 170A-170N, which may represent any number of temperature sensors. While the sensors 170A-170N are shown on the left side of the block diagram of the SoC 105, it should be understood that the sensors 170A-170N may be distributed throughout the SoC 105 and / or located next to major components of the SoC 105 in an actual implementation of the SoC 105. In one embodiment, there is a sensor 170A-170N for each core 110A-110N, a compute unit of the GPU 140, and other major components. In this embodiment, each sensor 170A-170N tracks the temperature of the corresponding component. In another embodiment, there are sensors 170A-170N for different geographic regions of the SoC 105. In this embodiment, the sensors 170A-170N are distributed throughout the SoC 105 to track temperatures in various areas of the SoC 105 and monitor for hot spots within the SoC 105. In other embodiments, other schemes for disposing sensors 170A-170N within SoC 105 are possible and contemplated.

[0017] SoC 105 also includes multiple performance counters 175A-175N, which may represent any number and type of performance counters. While performance counters 175A-175N are shown on the left side of the block diagram of SoC 105, it should be understood that performance counters 175A-175N may be distributed throughout SoC 105 and / or located within major components of SoC 105 in an actual implementation of SoC 105. For example, in one embodiment, each core 110A-110N includes one or more performance counters 175A-175N, memory controller 130 includes one or more performance counters 175A-175N, GPU 140 includes one or more performance counters 175A-175N, and other performance counters 175A-175N are utilized to monitor the performance of other components. Performance counters 175A-175N may track a variety of different performance metrics, including instruction execution rates of cores 110A-110N and GPU 140, memory bandwidth consumed, row buffer hit rates, cache hit rates for various caches (e.g., instruction cache, data cache), and / or other metrics.

[0018] In one embodiment, the SoC 105 includes a phase-locked loop (PLL) unit 155 coupled to receive a system clock signal. The PLL unit 155 includes several PLLs configured to generate and distribute corresponding clock signals to each of the processor cores 110 and other components of the SoC 105. In one embodiment, the clock signals received by each of the processor cores 110 are independent of one another. Furthermore, the PLL unit 155 in this embodiment is configured to individually control and change the frequency of each of the clock signals provided independently to each of the processor cores 110. The frequency of the clock signal received by any given one of the processor cores 110 may be increased or decreased according to the power state assigned by the system management unit 125. The various frequencies at which the clock signals are output from the PLL unit 155 correspond to different operating points of each of the processor cores 110. Thus, changing the operating point of a particular one of the processor cores 110 is implemented by changing the frequency of its respective received clock signal.

[0019] An operating point, for purposes of this disclosure, 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 that unit and may also include increasing its operating voltage. Similarly, lowering the operating point of a given functional unit may be defined as lowering the clock frequency and may also include lowering the operating voltage. Limiting the operating point may be defined as limiting the clock frequency and / or operating voltage to a specified maximum value for a particular set of conditions (but not necessarily a maximum limit for all conditions). Thus, if the operating point is limited for a particular processing unit, that processing unit can operate at clock frequencies and operating voltages up to the values ​​specified for the current set of conditions, but can also operate at clock frequencies and operating voltage values ​​less than the specified values.

[0020] If changing the respective operating points of one or more processor cores 110 includes changing one or more respective clock frequencies, system management unit 125 changes the state of digital signals provided to PLL unit 155. In response to these signal changes, PLL unit 155 changes the clock frequencies of the affected processor core(s) 110. Additionally, system management unit 125 can cause PLL unit 155 to prevent individual clock signals from being provided to corresponding ones of processor cores 110.

[0021] In the illustrated embodiment, SoC 105 also includes voltage regulator 165. In other embodiments, voltage regulator 165 may be implemented separately from SoC 105. Voltage regulator 165 provides a supply voltage to each of processor cores 110 and other components of SoC 105. In some embodiments, voltage regulator 165 provides a variable supply voltage according to a particular operating point. In some embodiments, each of processor cores 110 shares a voltage plane. Thus, each processor core 110 in such embodiments operates at the same voltage as the other processor cores 110. In another embodiment, voltage planes are not shared, and therefore the supply voltage received by each processor core 110 is set and adjusted independently from the respective supply voltages received by the other processor cores 110. Thus, operating point adjustments, including adjustments to the supply voltage, may be selectively applied to each processor core 110 independently of the other cores in embodiments with unshared voltage planes. If changing the operating point includes changing the operating voltage of one or more processor cores 110, system management unit 125 may change the state of a digital signal provided to voltage regulator 165. In response to the change in the signal, voltage regulator 165 adjusts the supply voltage provided to the affected ones of processor cores 110. If power is removed from any of processor cores 110 (i.e., a gated processor core), system management unit 125 sets the state of a corresponding one of the signals to cause voltage regulator 165 to no longer provide power to the affected processor core(s) 110.

[0022] In various embodiments, computing system 100 may be a computer, a laptop, a mobile device, a server, a web server, a cloud computing server, a storage system, or any of a variety of other types of computing systems or devices. Note that the number of components of computing system 100 and / or SoC 105 may vary from embodiment to embodiment. There may be more or fewer components / subcomponents than those shown in FIG. 1 . Also, note that computing system 100 and / or SoC 105 may include other components not shown in FIG. 1 . Additionally, in other embodiments, computing system 100 and SoC 105 may be structured in other ways than those shown in FIG. 1 .

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

[0024] System management unit 210 includes control unit 240, power allocation unit 215, and power management unit 220. In the illustrated example, power management unit 220 is shown to include recording unit 202. In some embodiments, control unit 240 is configured to determine how power is allocated in the computing system. In one scenario, in response to detecting a particular condition, control unit 240 determines power budget allocations for various circuits in the computing system. In some embodiments, system management unit 210 provides information to one or both of power allocation unit 215 and power management unit 220 for use in making power allocation decisions. Various such embodiments and combinations are possible and contemplated. In one scenario, the condition is one that requires a reduction in power consumption of the computing system (or some component(s) of the computing system). This condition may occur as a result of the system reaching its maximum allowed or allocated power. Alternatively, this condition may occur as a result of a thermal condition (e.g., reaching a maximum operating temperature). In response to detecting the condition, control unit 240 evaluates various parameters, including one or more of the currently executing task(s), the type of task, the phase of a given task, etc. In another scenario, the condition may be intentionally imposed by some policy / mechanism implemented by the combined hardware and system software / firmware in an attempt to reach a desired software-dependent optimal operating point of power-performance settings. In various such embodiments, some attributes of the running software application are tracked on the hardware as the software application executes (at runtime) and used in making decisions at each point in time. Note that while power management unit 220 is shown as being included in system management unit 210, in other embodiments, power management unit 220 and / or recording unit 202 are located elsewhere.For example, in one embodiment, power management unit 220 and recording unit 202 are collocated with graphics processing unit 140 or some other unit. In such a case, graphics processing unit 140 is allocated a power budget by control unit 240 and power allocation unit 215 and operates to manage the operating frequency of circuitry within graphics processing unit 140 within the predetermined power budget. These and other embodiments are possible and contemplated.

[0025] The power allocation unit 215 is configured to allocate a power budget to each of the compute units 205A-205N, the memory subsystem including the memory controller 225, and / or one or more other components. The total amount of power available to the power allocation unit 215 to be distributed among the components may be capped by the host system. The power allocation unit 215 receives various inputs from the compute units 205A-205N, including the status of the miss status holding register (MSHR) of the compute units 205A-205N, the instruction execution rate of the compute units 205A-205N, the number of pending ready-to-execute instructions in the compute units 205A-205N, the instruction and data cache hit ratios of the compute units 205A-205N, the memory bandwidth consumed, and / or one or more other input signals. The power allocation unit 215 can utilize these inputs to determine whether the computing units 205A-205N have tasks to perform, and the power allocation unit 215 can then adjust the power budget allocated to the computing units 205A-205N according to those determinations (e.g., by the control unit 240). The power allocation unit 215 can also receive inputs from the memory controller 225, including 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 allocation unit 215 can utilize the status of these inputs to determine the power budget allocated to the memory subsystem.

[0026] The PLL unit 230 includes any number of PLLs configured to receive a system clock signal(s), generate a corresponding clock signal, and distribute the system clock signal to each of the computing units 205A-205N and other components. The power management unit 220 is configured to convey control signals to the PLL unit 230 to control the clock frequency supplied to the computing units 205A-205N and other components. The voltage regulator 235 provides a supply voltage to each of the computing units 205A-205N and other components. The power management unit 220 is configured to convey control signals to the voltage regulator 235 to control the voltage supplied to the computing units 205A-205N and 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.

[0027] In an exemplary embodiment, power management unit 220 manages the operating frequency and power consumption of the system in a power management mode. For example, in a power management mode, power management unit 220 reduces the operating frequency of a computing unit that is less sensitive to clock frequency (or has a relatively lower sensitivity relative to other computing units) to save power. For example, if a computing unit performs a task that is compute-bound, power management unit 220 increases the clock frequency to improve performance. On the other hand, for a memory-bound task, power management unit 220 does not increase the frequency, considering that such an increase would not result in an increase (or desired increase) in performance.

[0028] The recording unit 202 is configured to record one or more parameters associated with the execution of a predetermined task, so that these recorded parameters may be used by the power management unit 220 to manage the power consumption of the computing unit for the execution of a subsequent task based on the power budget determined by the power allocation unit 215. The recording unit 202, in one embodiment, determines when the one or more parameters associated with a predetermined task should be recorded based at least in part on an indication of a change in a characteristic of a set of tasks that includes the predetermined task.

[0029] In one example, if the set of tasks includes rendering multiple frames, the recording unit 202 determines that parameters for a frame need to be recorded if the length of the frame (e.g., the time it takes to render the frame or the number of clock cycles to render the frame) exceeds the length of a previously rendered frame. Additionally, the recording unit 202 triggers the recording of one or more parameters in response to detecting a recording condition, including, but not limited to, two or more consecutive frames taking the same (or similar) time to render, two or more consecutive frames determined to have the same or similar average frequency used during rendering, rendering two or more consecutive frames with the same or similar starting frequency, etc.

[0030] In one embodiment, the one or more parameters recorded by the recording unit 202 include at least operating frequencies. In one example, these operating frequencies indicate clock frequencies supplied to the computing units 205A-205N and other components to perform a predetermined task. The recording unit 202 is configured to record the operating frequencies used by the computing unit(s) while performing the predetermined task, and the power management unit 220 then utilizes the recorded operating frequencies to control clock frequencies supplied to one or more computing components for other subsequent tasks that are “relatively similar” to the predetermined task. In a non-limiting example, if the predetermined task includes rendering frames, two frames are relatively similar if both frames are of the same length, are consecutive, or are within the same scene.

[0031] With reference to the frame rendering embodiment described above, the operating frequencies used during the rendering of a given portion of the frame are recorded and stored in a data array (or other data structure). The frequencies used during the rendering of the corresponding portion of the frame are identifiable. For example, each such element of the data structure can be identified as corresponding to a portion of the frame, and the corresponding frequency can be stored. Then, in a later frame, these recorded frequencies are used during the rendering of the later frame. Other embodiments are contemplated.

[0032] In another embodiment, the one or more parameters further include a power state of the computing components while performing a given task and a sensitivity of the computing unit to changes in the power state. In one example, the sensitivity of the computing unit to power changes may indicate the sensitivity of the unit's performance to changes in power state based on the type of task being performed, the type of unit performing the task, the current operating frequency, the current power consumption, etc. Based on the recorded power state of the computing unit for the given task and its sensitivity to changes in power state, the power management unit 220 manages the power consumption of the computing unit for subsequent tasks that are relatively similar to the given task.

[0033] In one embodiment, the system management unit 210 complements a power throttling unit (not shown) in managing the power consumption of the computing components of the SoC 105. In one example, the power throttling unit 210 dictates the amount of power (or operating frequency) to be supplied to the computing components when the SoC 105 is not operating in a power management mode (e.g., when the power management unit 220 is disabled, malfunctioning, or otherwise unavailable). For example, when it is determined that recording of one or more parameters associated with a given task should begin, the power management unit 220 enters an operating mode that does not change the operating frequency to manage power consumption (i.e., the unit's power management mode is disabled). In embodiments described herein, disabling the power management unit 220 and / or a power management mode refers to disabling changes to the operating frequency of the computing unit(s). For example, as described above, changes to the operating frequency of circuitry associated with rendering a frame are temporarily disabled. However, other power management features, such as dynamic power management of one or more GPU cores, GPU deep sleep functionality, clock gating, etc., may be active even when power management unit 220 and / or power management modes are disabled. That is, while power management unit 220 is inactive, control unit 240 and / or power throttling unit may continue to determine how to allocate power in the computing system.

[0034] In one embodiment, power management unit 220 is configured to conserve power in a power management mode so that a computing unit executing a set of tasks can consume less power than allocated by power allocation unit 215. For example, if a computing unit is allocated a predetermined power budget, the computing unit may end up consuming less power than allocated. For example, by throttling or otherwise limiting the operating frequency while rendering a frame, the computing unit consumes less than the entire allocated power budget than it would otherwise. In such a case, a power "credit" (i.e., unused power budget) is said to exist.

[0035] Furthermore, in various embodiments, when the power management mode is disabled, the computing unit consumes available power to maximize performance. In other words, if it is determined that a power credit exists, the credit is reported to the given unit. In response to detecting that a power credit is available, the operating frequency of the given unit may be increased to utilize the available excess power. In such embodiments, the given unit selects various operating frequencies based on the reported available power. Such reported available power may represent accumulated, currently unused power or previously accumulated power that was unused. For example, after the power management mode is disabled and a power credit exists (e.g., allocated power remains available, allowing the computing unit to operate at a higher frequency), the computing unit operates at an operating frequency closer to the maximum allowed frequency rather than operating at a throttled value of the operating frequency.

[0036] One or more techniques are used to identify operating frequencies corresponding to non-power credit periods. As will be described in more detail, the rendering of a frame (or the execution of a task of the type being observed) is monitored. If a predetermined condition is detected, any power credits present (or that may have existed) are assumed to be consumed (or "drained"). For example, when rendering a frame and power credits are present, the operating frequency of the rendering unit may increase to a relatively high rate, as described above. Then, if power throttling is disabled, the operating frequency begins to decrease as power credits are consumed. At some point, the operating frequency no longer reflects the power credits. In such a case, rendering similar frames will take similar times due to the use of the same frequency (or the same average frequency). Generally speaking, consecutive frames often have great similarity. If a relatively large change in rendering time between frames is detected, this often indicates a scene change. In addition to having similar rendering times, such a condition may also be indicated when the rendering of a first frame has a default starting frequency and the next frame is also rendered at the same starting frequency. When such a condition is detected, these exemplary conditions for triggering recording may, in one embodiment, indicate that the operating frequency has reached a relatively stable state after disabling the power management mode. Other possible scenarios that indicate that the operating frequency has reached a relatively stable state are contemplated.

[0037] The operating frequency can then be recorded and serve as a reference operating point(s) for the system management unit 210 to determine the operating frequency for the execution of other subsequent tasks. Again, taking the frame rendering example mentioned above, a steady state is considered to be reached when the operating frequency at the start of rendering two consecutive frames is the same. The operating frequency of the second frame is then saved as the reference operating point.

[0038] Using these recorded parameters may advantageously facilitate efficient power conservation, as power credits accumulated by the system management unit 210 are not consumed as soon as they become available. Furthermore, the system management unit 210 continues to manage power consumption based on the recorded frequencies, and saved power may be used only for tasks where increasing power consumption provides a greater performance boost.

[0039] Referring now to FIG. 3, one embodiment of a task scheduler 300 is shown. In one embodiment, task scheduler 302 assigns tasks from a task queue to multiple compute units of an SoC (e.g., SoC 105 of FIG. 1). Task scheduler 302 receives multiple inputs for use in determining how to schedule tasks to the various compute units of the SoC. Task scheduler 302 also coordinates with a system management unit (e.g., system management unit 210 of FIG. 2) to determine an optimal task schedule for pending tasks to the compute units of the SoC. The multiple inputs utilized by task scheduler 302 include quality of service (QoS) 306 requirements of queued tasks, task arrival timestamp 310, and respective device preferences 308 (e.g., CPU, GPU). In other embodiments, task scheduler 302 utilizes other inputs to determine the optimal task schedule 314 for pending tasks 312. In various embodiments, information regarding the proposed task schedule 314 and task type 316 is conveyed to or otherwise made available to system management unit 210.

[0040] In one embodiment, task scheduler 302 attempts to minimize task execution time and task wait time on the assigned compute unit, thereby ensuring that the temperature rise of the compute unit executing the assigned task remains below the currently available thermal margin. Task scheduler 302 also attempts to schedule tasks in a way that keeps the sum of a given task's execution time and its wait time at or below the time indicated by the given task's QoS setting. In other embodiments, other example algorithms for the task scheduler are possible and contemplated.

[0041] In another embodiment, the system management unit 210 uses the device preferences 308 to determine whether a given task is compute-bound or memory-bound. Further, the system management unit 210 ascertains the power state of the computing unit for executing the given task 312 from the proposed power state 318. Based on information about whether the task 312 is compute-bound or memory-bound and the power state of the computing unit, the power allocation unit 215 allocates power from the power budget for consumption by the computing unit to execute the task 312. Based on the power allocated by the power allocation unit 215 and the device preferences 308, the power management unit 220 is configured to manage the power supply for the computing unit, i.e., by either increasing the power supply, decreasing the power supply, or keeping the power supply constant.

[0042] In one example, when the power management unit 220 increases the power supply of a computing unit to perform a given task 312, a portion of the previously accumulated power credits is consumed, whereas when the power supply is reduced, more power credits are accumulated. Furthermore, stabilization of a power- or frequency-related parameter during the execution of a task 312 indicates the consumption of power credits.

[0043] 4 illustrates 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 comprises 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) based at least in part on tasks 406 received from a task scheduler. Furthermore, the power management unit 418 manages the operating frequency and power consumption of the system in a power management mode.

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

[0045] In various embodiments, the one or more parameters are reported from other units or portions of the system (e.g., based on sensors, performance counters, other event / activity detection, etc.). In some embodiments, the 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 in the system, the duration(s) of the power-performance state, previously recorded parameters, etc. Additionally, the system management unit 410 is configured to receive task-related information 406 from a task scheduler (e.g., task scheduler 302 of FIG. 3). For example, such information may include a proposed task schedule, a task type, and a proposed power state.

[0046] In the example of FIG. 4 , workload / domain unit 404 includes data indicative of the sensitivity of various portions of the computing system to power state changes. In other embodiments, workload / domain unit 404 is configured to calculate such data. For example, in one embodiment, workload / domain unit 404 includes characterization data generated by executing various workloads and evaluating performance in relation to power state changes. In some embodiments, this data includes characterization data generated offline. In other embodiments, the data includes characterization generated at runtime. In yet another embodiment, the characterization data maintained by workload / domain unit 404 is programmable and may be updated during runtime based on a comparison of predicted power / performance changes compared to actual power / performance changes. In one embodiment, workload / domain unit 404 includes circuitry configured to perform calculations that represent relationships between task types, power state changes, and predicted performance changes.

[0047] In some embodiments, the workload / domain unit 404 is further configured to determine how characteristics of a given task differ from previously executed tasks in the given set of tasks. Any change in the predetermined characteristics can indicate to the recording unit 402 that recording of one or more parameters for the given task should begin. As described above, if the set of tasks includes rendering a frame, the characteristics include at least the frame length, and the one or more parameters include at least the operating frequency of the computing unit while performing the given task. The recording unit 402 can provide the recorded operating frequency to one or both of the power allocation unit 414 and the power management unit 418 for use in making power allocation decisions. Various such embodiments and combinations are possible and contemplated.

[0048] Turning now to FIG. 5 , an exemplary method 500 for recording one or more parameters associated with a given task is shown. As described above, a system management unit (e.g., system management unit 410 of FIG. 4 ) is configured to record one or more parameters associated with the execution of a given task. In an exemplary embodiment, the recorded one or more parameters may be used by the system management unit 410 to manage power and performance parameters of one or more subsequent tasks. The system management unit 410 determines a change in a characteristic of a set of tasks of which the given task is a part and, based on the change, determines whether recording should be triggered. If it is determined that recording should be triggered, the recording unit (e.g., recording unit 402 of FIG. 4 ) records one or more parameters associated with the given task and saves 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 include the operating frequency of at least one computing unit(s) executing the set of tasks.

[0049] For simplicity, method 500 will be described using an example in which the set of tasks includes multiple frames rendered by a computing unit, with a given task representing the rendering of a separate frame. Generally speaking, the method of FIG. 5 first determines when task parameter recording should occur in the absence of power credits. As described above, if the length of time to render a frame changes by some threshold amount, which may be fixed or programmable, this may indicate that a scene change has occurred. Thus, any frequency previously determined for rendering a frame may no longer be suitable for the new scene(s). Thus, a new frequency for rendering a subsequent frame is determined. Furthermore, the characteristics of the set of tasks examined for changes include the length of time it takes to render each frame, and the one or more parameters include at least the operating frequency of the given computing unit(s) rendering the frame. Other examples are contemplated.

[0050] The system management unit determines characteristics of each frame in the set of frames (block 504). In one embodiment, the characteristics include at least the length of time to render each frame. In an exemplary embodiment, based on the determined length of each frame, the system management unit determines whether recording of an operating frequency associated with the rendering of a given frame should be triggered (conditional block 506). The determination of whether such recording is triggered is made by the system management unit based at least in part on a detected change in the frame length of the given frame compared to the previous frame(s). For example, the system management unit may determine that recording of an operating frequency is triggered for a frame if the frame length differs from the length of the immediately preceding frame by a threshold amount. For example, if the frame length changes by 10% or more, a scene change or other significant change is assumed to have occurred. In another example, recording may be considered triggered if a predetermined period (e.g., 10 seconds) has elapsed during the rendering of the set of frames. In such cases, recording may be triggered periodically (e.g., at a programmable period).

[0051] If it is determined that recording has not been triggered (conditional block 506: "NO"), method 500 proceeds to block 504, where the system management unit continues to check for changes in frame characteristics until such a change is determined and / or until a predetermined period of time has elapsed. Otherwise, if it is determined that recording of the operating frequency associated with rendering of a given frame has been triggered (conditional block 506: "YES"), the system management unit disables the power management unit (e.g., by the power management unit 220) to prevent frequency throttling (block 508) in order to reduce power consumption and potentially build or increase power credits. As a result, any existing power credits are consumed, as described in connection with FIG. 7.

[0052] The system management unit then determines whether a recording condition is met (conditional block 510). As discussed above, the recording condition may include one or more scenarios, including, but not limited to, two or more consecutive frames taking the same (or similar) amount of time to render, two or more consecutive frames determined to have the same or similar average frequency used during rendering, rendering two or more consecutive frames with the same or similar starting frequency, etc. This suggests that the operating frequency has reached a relatively stable state.

[0053] If it is determined that the recording condition is not met (conditional block 510: "No"), the system management unit examines the power consumption of the computing unit, which may indicate whether recording may be triggered. In one embodiment, the system management unit continues to monitor the power consumption of the computing unit to determine when to trigger recording.

[0054] If the recording condition is met (conditional block 510: "YES"), the recording unit records the operating frequency for the given frame (or in alternative embodiments, for a given number of frames and / or a given period of time). 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 saved (e.g., in a data array, memory location, etc.) and used by the power management unit to determine the operating frequency to be used during the rendering of other frames rendered subsequent to the given frame. The power management unit may also restore itself once recording is complete (block 516). Method 500 then ends.

[0055] While the embodiment presented with respect to Figure 5 describes a power management unit that identifies when recording is triggered and starts recording when a 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 a scenario, when a recording condition is met, the power management unit fetches already recorded parameters for optimizing the operating frequency, as illustrated in Figure 6.

[0056]

[0041] Turning now to Figure 6, an example method 600 for performing a task using one or more recorded parameters is shown. As described with respect to Figure 5, the power management unit determines values ​​of operating frequencies to be used by computing units to render one or more frames. In one example, the power management unit determines the operating frequencies for rendering the frames based on a power budget allocated to the computing units scheduled to render the frames.

[0057] In one embodiment, the power management unit monitors one or more tasks queued for execution (block 602). As described above, a task may include a frame to be rendered by a given computing unit. Based on the tasks queued for execution on a given computing unit or multiple computing units, the power management unit determines a power budget to be allocated to the computing unit(s) for executing the given task (block 604). For example, if a frame is being rendered, the power management unit may determine a power budget allocated for rendering. In one example, a graphics processing unit is allocated a power budget by a power allocation unit, and the power allocation unit is configured to operate to manage the operating frequency of circuitry within the graphics processing unit within the power budget.

[0058] The power management unit then determines, based at least in part on the power budget, whether excess power is available to boost the operating frequency (conditional block 606). In one embodiment, the available power is either accumulated or consumed as power credits, for example, when the power management unit adjusts operating parameters of the processing system to conserve power. For example, for execution of a task that has low sensitivity to changes in operating frequency, the power management unit may reduce the operating frequency during execution to conserve power. This saved power is an indication of the available power credits. In contrast, when a task that has higher sensitivity to operating frequency is executed, the power management unit may increase the operating frequency to boost performance, which may be an indication of the consumption of power credits.

[0059] If such excess power is not available (conditional block 606: “No”), the power management unit may set the operating frequency without boosting (block 608). In an exemplary embodiment, the power management unit is configured to set the operating frequency based on the performance sensitivity of the currently executing task. However, if there is excess power available for boosting (conditional block 606: “Yes”), the power management unit determines an operating mode. In one embodiment, the power management unit is configured to operate in two operating modes: in a first operating mode, the power management unit determines operating parameters for execution of the task based on available power (e.g., power management mode); in a second operating mode, the power management unit adjusts operating parameters for a given task based at least in part on recording available data for other tasks that are relatively similar to the given task. For example, if the given task includes rendering frames, two frames are relatively similar if both frames are the same length, i.e., the execution time of both frames is the same.

[0060] As shown in the figure, when the first operating mode is active, the power management unit varies the operating frequency while a predetermined 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 for potential performance increases. That is, the power management unit operates to boost performance to take advantage of power credits when the computing unit executes tasks that are not performance-sensitive.

[0061] On the other hand, if the second mode is active, i.e., if the power management mode is active, the power management unit first determines whether the recorded operating frequency is available (conditional block 614). In one embodiment, the recorded operating frequency can serve as a reference operating point for determining the operating frequency for the execution of a given task. For example, as described above, the operating frequency can be identified and recorded during the rendering of a frame and then used to set the operating frequency for the rendering of a subsequent frame.

[0062] If the recorded frequencies are available (conditional block 614: "YES"), the power management unit sets the current operating frequency based on these recorded frequencies. That is, using the recorded frequencies, the power management unit determines how the current operating frequency should be modified to save power or boost performance for the task being executed. For example, even if power credits are present, instead of boosting the operating frequency to the maximum allowed frequency (as is done in the first mode), the power management unit references the recorded frequencies to determine the modification to the operating frequency. This can advantageously help generate additional power credits that can be utilized for the execution of performance-sensitive tasks, i.e., tasks that provide performance improvements for which increasing power is desirable.

[0063] If the recorded operating frequency is not available (conditional block 614: "NO"), the power management unit stops throttling the existing operating frequency level until a stable operating frequency is reached (block 616). As described above, recording can be triggered in response to a change in the length of time to render a frame. When a relatively large change in rendering time between frames is detected, this often indicates a scene change. In addition to having similar rendering times, such a condition can also be indicated when the rendering of a first frame has a default starting frequency and the next frame is also rendered at the same starting frequency. When such a condition is detected, these exemplary conditions for triggering recording, in one embodiment, can indicate that the operating frequency has reached a relatively stable state after disabling the power management mode. Other possible scenarios indicating that the operating frequency has reached a relatively stable state are contemplated.

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

[0065] In one embodiment, the power management unit continuously records the operating frequency for rendering a frame when a condition for triggering recording occurs, such as a change in the length of the frame compared to a previously executed frame. Furthermore, as the recorded data becomes available, the power management unit uses the recorded data for the execution of other frames until a point in the execution when recording needs to occur again. Furthermore, each time the power management unit determines that the operating frequency for rendering 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 modifies the operating frequency using the recorded operating frequency as a threshold).

[0066] 7, an exemplary timeline graph 700 is shown illustrating frequency (given in megahertz, MHz) modifications during the rendering of a set of frames over a period of time (given in microseconds, ms). The diagram illustrates the change in operating frequency 706 during the rendering of multiple frames 702 relative to a maximum allowed frequency 704.

[0067] As shown, one such point in time during which recording is initiated is indicated by arrow 708. In one embodiment, at point 708, recording is initiated based on detecting a condition. In one embodiment, the condition is a change in the length of time to render a frame(s) (also referred to as frame length). For example, at point 708, the frame length changes by a predetermined amount (e.g., 10%), which can initiate recording. In various embodiments, the predetermined amount or condition is programmable. In response to recording being initiated, the power management unit disables the power management unit, i.e., the computing unit(s) executing the set of frames 702 no longer operate in power management mode.

[0068] When the power management mode is disabled, the operating frequency 706 is no longer throttled and defaults to the maximum allowed frequency 704, as shown. As the operating frequency 706 increases, the computing unit consumes additional power (i.e., any power credits) 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 determined to have the same or similar average frequency used during rendering, and / or the rendering of two or more consecutive frames with the same or similar starting frequency. Once the steady state is achieved, any power credits previously accrued are assumed to have been consumed. As shown in the figure, if additional power (i.e., “power credits”) is consumed during execution, the frequency increase dissipates due to the additional available power, and the operating frequency 706 decreases.

[0069] Once a stable operating frequency is detected, the power management unit begins recording the operating frequency used to render the frame. Furthermore, during the period in which the operating frequency is relatively stable and recording occurs, the power management mode remains disabled to ensure that no further modifications to the operating frequency 706 are made. As shown in the figure, the power management mode is disabled for the period indicated by arrow 710.

[0070] The recorded operating frequency is then saved in a location accessible by the power management unit. Furthermore, the power management unit (i.e., the power management mode) may be enabled once the recording is complete. The recorded operating frequency is then used as a reference operating point for the rendering of the subsequent frame 702. As can be seen from the graph 700, after the recording is complete, the rendering of the frame 702 continues in a steady state without the operating frequency 706 increasing to the maximum allowed frequency 704. This may allow the power management unit to generate power credits, but any additional power would be consumed if the recorded operating frequency were not used as the reference operating point. For example, the power management unit may use the recorded operating frequency to perform tasks for which changes in operating frequency are relatively unrelated to performance (i.e., tasks for which performance is less sensitive to changes in frequency). During such tasks, the power management unit continues to generate power credits. Rather than boosting the operating frequency during rendering of a frame to utilize the accumulated power credit, the recorded operating frequency is used to render the frame, and the power credit can be used elsewhere where a change in operating frequency has a greater impact on performance changes (i.e., for tasks whose performance is more sensitive to frequency changes).

[0071] It should be emphasized that the above-described embodiments are merely non-limiting examples of embodiments. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to encompass all such variations and modifications.

Claims

1. 1. A system comprising: Equipped with a system management unit, The system management unit recording one or more first operating frequencies of the computing units while performing a first task; performing a second task using one or more second operating frequencies; and and the one or more second operating frequencies are selected for performing the second task based at least in part on the one or more first operating frequencies. system.

2. the first task includes rendering a frame; the second task includes rendering a frame; The system of claim 1.

3. the one or more first operating frequencies are recorded in response to a condition including detecting a scene change; The system of claim 2.

4. the system management unit is configured to disable a power management mode of the computing unit in response to the condition until a stable operating frequency is achieved. The system of claim 3.

5. the system management unit is configured to accumulate power credits while operating in a power management mode; The system of claim 1.

6. the system management unit is configured to record a power state associated with the computing unit; The system of claim 1.

7. the one or more first operating frequencies are recorded at predetermined periodic intervals; The system of claim 1.

8. 1. A method comprising: recording a first operating frequency of one or more of the computing units while the system management unit is executing a first task of the set of tasks; the system management unit executing a second task of the set of tasks using one or more second operating frequencies; the one or more second operating frequencies are selected for performing the second task based at least in part on the one or more first operating frequencies. method.

9. the first task includes rendering a frame; the second task includes rendering a frame; 9. The method of claim 8.

10. the one or more first operating frequencies are recorded in response to the system management unit identifying a change in at least one characteristic associated with the set of tasks; the at least one characteristic includes at least a frame length; 9. The method of claim 8.

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

12. generating power credits while the system management unit is performing the set of tasks; 9. The method of claim 8.

13. the one or more second operating frequencies are operating frequencies recorded during execution of the first task; 9. The method of claim 8.

14. the one or more first operating frequencies are recorded while a power management mode is enabled; 14. The method of claim 13.

15. 1. A computing system comprising: a central processing unit; A memory controller; a system management unit; The system management unit recording a first operating frequency of one or more of the computing units while performing a first task of the set of tasks; executing a second task of the set of tasks using one or more second operating frequencies; and the one or more second operating frequencies are selected for performing the second task based at least in part on the one or more first operating frequencies. Computing system.

16. the first task includes rendering a frame; 16. The computing system of claim 15.

17. the one or more first operating frequencies are recorded in response to identifying a change in at least one characteristic associated with the set of tasks; the at least one characteristic includes at least a frame length; 16. The computing system of claim 15.

18. wherein the system management unit, in response to identifying a change in at least one characteristic associated with the set of tasks, Disabling a power management mode of the computing unit; examining consumption of power credits as an indication that at least one operating frequency of the one or more first operating frequencies has reached a threshold; configured to:

20. The computing system of claim 17.

19. the system management unit is configured to record a power state associated with the computing unit; 16. The computing system of claim 15.

20. the one or more first operating frequencies are recorded at predetermined periodic intervals; 16. The computing system of claim 15.

Images