Frame slice based power management

Abstract

Systems, apparatuses, and methods for implementing efficient power optimization in a computing system are disclosed. A system management unit is configured to track computing activity of a computing device while processing each of a plurality of frames. Computational activity is tracked at least for a given period of time comprising a plurality of time slices. The system management unit also correlates a time slice associated with the given frame with a time slice associated with at least one previously processed frame from the plurality of frames based at least in part on the tracked computational activity. The system management unit predicts a clock frequency for rendering the given frame based at least in part on the mutual relevance, and renders the given frame using the predicted clock frequency.

Description

Background Technology

[0001] Related technical descriptions When designing a computer or other processor-based system, many design factors must be considered. Successful designs require various trade-offs between power consumption, performance, and thermal output. For example, the design of a high-performance computer system may allow for greater power consumption. Conversely, the design of a battery-powered portable computer system may sometimes emphasize reducing power consumption at the expense of some performance. Regardless of specific design goals, computing systems typically have a given amount of available power during operation. This power must be allocated among the various components within the system—some to the central processing unit, some to the memory subsystem, some to the graphics processing unit, and so on. The allocation of power among system components may also change during operation.

[0002] Processing systems routinely employ various management techniques to manage operating system parameters, such as clock frequency and system power, to ensure efficient operation of the entire system. For example, mechanisms such as dynamic voltage and frequency scaling can help mitigate power management issues by adjusting power consumption in response to workload demands. Additionally, cooling systems can help dissipate excess heat, thereby achieving sustained performance while maintaining system stability. Therefore, careful consideration of power management strategies is crucial for ensuring optimal performance and lifespan in GPU processing environments.

[0003] However, current management schemes for operating parameters are typically based on average behavior. For example, when a frame is rendered, the processing system calculates an appropriate power management scheme based on the average power dissipation over the last few rendered frames or graphics engine activity. This results in conservative frequency selection that unnecessarily consumes power, or alternatively, average frequency selection that will impair the performance of some phases of the frame.

[0004] In light of the above, there is a need for improved systems and methods for efficient system management of frame rendering. Attached Figure Description

[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: Figure 1 It is a block diagram of a specific implementation of a computing system.

[0006] Figure 2 It is a block diagram of another specific implementation of the computing system.

[0007] Figure 3 It is a block diagram of a specific implementation of the system management circuit.

[0008] Figure 4 This is a block diagram illustrating the tracking of computational activities during frame processing in one or more activity periods.

[0009] Figure 5 An example is given of a method for tracking computational activity to predict one or more parameters that will be scheduled for execution. Detailed Implementation

[0010] 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 will recognize that various specific implementations can be practiced without these specific details. In some cases, 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, the elements shown in the accompanying drawings are not necessarily drawn to scale. For example, the dimensions of some of these elements may be enlarged relative to others.

[0011] Systems, apparatus, and methods for efficient power management in processing systems are disclosed. System management circuitry tracks computational activity of a computing device while processing each of a plurality of frames. In various embodiments, the number of frames is fixed, programmable, and / or dynamically identified. Computational activity is tracked over at least a given time period comprising the plurality of frames, wherein each frame is divided into a plurality of time slices. The system management circuitry, based at least in part on the tracked computational activity, correlates time slices during the processing of subsequent frames with time slices during the processing of at least one previously processed frame among the plurality of frames, and predicts a clock frequency for rendering the frame. Subsequent frames are rendered using the predicted clock frequency of each time slice during the frame period.

[0012] Now for reference Figure 1A block diagram of one embodiment of a computing system 100 is shown. In this embodiment, the illustrated computing system 100 includes a system-on-a-chip (SoC) 105 coupled to memory 160. However, it is possible and conceivable to implement an SoC 105 in which one or more of the illustrated components are not integrated onto a single chip. In some embodiments, the SoC 105 includes multiple processor cores (circuits) 110A to 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, and one or more peripheral devices 150A to 150N and the GPU 140 are discrete entities (e.g., daughterboards, etc.) coupled to the system board 102. In other embodiments, the GPU 140 and / or one or more peripheral devices 150 may be permanently mounted on the board 102 or otherwise integrated into the SoC 105. It should be noted that processor cores 110A to 110N may also be referred to as processing units or processors. As described below, certain types of circuits are referred to as "units" (e.g., decoding units, computation units, arithmetic logic units, functional units, memory management units, etc.). Therefore, unless otherwise stated, the term "unit" also refers to a circuit.

[0013] Processor cores 110A through 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 instructions, which can be translated and / or decoded into memory access requests or memory access operations for memory 160.

[0014] In another embodiment, SoC 105 includes a single processor core 110. In a multi-core embodiment, processor cores 110 may be identical to each other (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. Furthermore, each processor core 110 is configured to issue access requests to memory 160, which serves as the main memory of computing system 100. Such requests include read requests and / or write requests, and are initially received by bridge 120 from the corresponding processor core 110. Each processor core 110 may also include a queue or buffer that holds flight instructions that have not yet completed execution. This queue may be referred to herein as an "instruction queue." Some instructions in processor core 110 may still wait for their operands to become available, while others may wait for an available arithmetic logic unit (ALU). Instructions waiting for an available ALU may be referred to as ready instructions. In one embodiment, each processor core 110 is configured to keep track of the number of ready instructions.

[0015] In the illustrated embodiment, the Input / Output Memory Management Unit (IOMMU) 135 is coupled to the bridge 120. In one embodiment, in the computing system 100, the bridge 120 serves as the northbridge device, and the IOMMU 135 serves as the southbridge device. In other embodiments, the bridge 120 may be a texture, a switch, a bridge, any combination of these components, or another component. Various different types of peripheral buses (e.g., Peripheral Component Interconnect (PCI) bus, PCI Expansion (PCI-X), PCIe (PCI Express) bus, Gigabit Ethernet (GBE) bus, Universal Serial Bus (USB)) may be coupled to the IOMMU 135. Various types of peripheral devices 150A to 150N may 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, which are coupled to the IOMMU 135 via their respective peripheral buses, can issue memory access requests using Direct Memory Access (DMA). These requests (which may include read and write requests) are transmitted to bridge 120 via IOMMU 135.

[0016] In some implementations, SoC 105 includes a graphics processing unit (GPU) 140 configured to be coupled to a display 145 (not shown) of computing system 100. In some implementations, GPU 140 is a separate and independent integrated circuit from SoC 105. GPU 140 performs various video processing functions and provides the processed information to display 145 as visual information output. GPU 140 can also be configured to perform other types of tasks scheduled to GPU 140 by an application scheduler. 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 GPU 140 are also referred to as “processing units”. Each computing unit of GPU 140 is configured to issue an access request to memory 160.

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

[0018] 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 embodiments are also possible and conceivable. In one embodiment, memory 160 is used to implement random access memory (RAM) for use with SoC 105 during operation. The implemented RAM can be static RAM (SRAM) or dynamic RAM (DRAM). DRAM types used to implement memory 160 include (but are not limited to) double data rate (DDR) DRAM, DDR2 DRAM, DDR3 DRAM, etc.

[0019] although Figure 1 While not explicitly shown, SoC 105 may also include one or more cache memories within processor core 110. For example, each processor core 110 may include an L1 data cache and an L1 instruction cache. In some implementations, SoC 105 includes a shared cache 115 shared by processor cores 110. In some implementations, the shared cache 115 is a Level 2 (L2) cache. In some implementations, each processor core in processor core 110 has an L2 cache implemented therein, and therefore the shared cache 115 is a Level 3 (L3) cache. Cache 115 may be part of a cache subsystem that includes a cache controller.

[0020] In one implementation, system management circuitry 125 is integrated into bridge 120. In other implementations, system management circuitry 125 may be separate from bridge 120, and / or system management circuitry 125 may be implemented as multiple separate components in multiple locations within SoC 105. System management circuitry 125 is configured to manage the power states of various processing units of SoC 105. In one implementation, system management circuitry 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.

[0021] SoC 105 includes multiple temperature sensors 170A to 170N, representing any number of temperature sensors. It should be understood that although sensors 170A to 170N are shown on the left side of the block diagram of SoC 105, sensors 170A to 170N can be distributed throughout SoC 105, and / or located near the main components of SoC 105 in an actual implementation of SoC 105. In one implementation, sensors 170A to 170N are present for each core 110A to 110N, the compute units of GPU 140, and other main components. In this implementation, each sensor 170A to 170N tracks the temperature of the corresponding component. In another implementation, sensors 170A to 170N are present for different geographic areas of SoC 105. In this implementation, sensors 170A to 170N are distributed throughout SoC 105 and are positioned to track the temperature of different areas of SoC 105 to monitor for the presence of any hot spots within SoC 105. In other specific implementations, other approaches for positioning sensors 170A to 170N within the SoC 105 are possible and conceivable.

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

[0023] In one embodiment, SoC 105 includes a phase-locked loop (PLL) unit 155 coupled to receive a system clock signal. The PLL unit 155 includes multiple PLLs configured to generate corresponding clock signals and distribute them to each processor core in processor core 110 and to other components of SoC 105. In one embodiment, the clock signals received by each processor core in processor core 110 are independent of each other. Furthermore, in this embodiment, the PLL unit 155 is configured to independently control and change the frequency of each clock signal provided to a corresponding processor core in processor core 110. The frequency of the clock signal received by any given processor core in processor core 110 can be increased or decreased based on the power state assigned by system management circuitry 125. Various frequencies of the clock signals output from the PLL unit 155 correspond to different operating parameters of each processor core in processor core 110. Therefore, by changing the frequency, operating voltage, or combinations thereof of its corresponding received clock signal, changes in the operating parameters of a particular processor core in processor core 110 are achieved.

[0024] For the purposes of this disclosure, operating parameters can be defined as operating frequency (or clock frequency) and may also include operating voltage or power (e.g., the supply voltage or power to a functional unit). Increasing the operating parameters of a given functional unit can be defined as increasing the frequency of the clock signal supplied to that unit and may also include increasing its operating voltage. Similarly, decreasing the operating parameters of a given functional unit can be defined as decreasing the clock frequency and may also include decreasing the operating voltage. Limiting operating parameters can be defined as limiting the clock frequency and / or operating voltage to a specified maximum value under a specific set of conditions (but not necessarily the maximum limit for all conditions). Therefore, when limiting the operating parameters of a particular processing unit, it can operate at a clock frequency and operating voltage up to the specified value under a set of current conditions, but may also operate at a clock frequency and operating voltage value less than the specified value.

[0025] When changing the corresponding operating parameters of one or more processor cores 110, including changing one or more corresponding clock frequencies, the system management circuit 125 alters the state of the digital signals provided to the PLL unit 155. In response to these signal changes, the PLL unit 155 changes the clock frequency of the affected processor core 110. Additionally, the system management circuit 125 can also cause the PLL unit 155 to disable the supply of corresponding clock signals to the corresponding processor core within the processor core 110.

[0026] In the illustrated embodiment, SoC 105 also includes a voltage regulator 165. In other embodiments, the voltage regulator 165 may be implemented separately from SoC 105. The voltage regulator 165 provides a supply voltage to each processor core in processor core 110 and to other components of SoC 105. In some embodiments, the voltage regulator 165 provides a supply voltage that varies according to a specific operating point. In some embodiments, each processor core in processor core 110 shares a voltage plane. Therefore, in this embodiment, each processor core in processor core 110 operates at the same voltage as the other processor cores in processor core 110. In another embodiment, the voltage plane is not shared, and therefore the supply voltage received by each processor core 110 is set and adjusted independently of the corresponding supply voltage received by the other processor cores 110. Therefore, in embodiments with a non-shared voltage plane, operating parameter adjustments, including adjustments to the supply voltage, may be selectively applied to each processor core 110 independently of other operating parameter adjustments. When changing operating parameters, including altering the operating voltage of one or more processor cores 110, the system management circuitry 125 changes the state of the digital signal supplied to the voltage regulator 165. In response to the signal change, the voltage regulator 165 adjusts the supply voltage supplied to the affected processor core 110. When power needs to be removed from one of the processor cores 110 (i.e., gating), the system management circuitry 125 sets the state of the corresponding signal so that the voltage regulator 165 does not supply power to the affected processor core 110.

[0027] In the various embodiments described herein, system management circuitry 125 is configured to determine one or more operating parameters of a computing device (such as GPU 140) based on computing activity tracked during a given time period (hereinafter referred to as an active period) when performing one or more tasks (e.g., tasks performed when rendering frames). In one embodiment, system management circuitry 125 tracks computing activity of the computing device during each of multiple time slices within an active period. For example, when rendering frames, system management circuitry 125 may track computing activity of the computing device while processing each of multiple time slices into which each frame is divided. Furthermore, based on data generated by such tracking, system management circuitry 125 may predict operating parameters for time slices in future frames based on computing activity during similar slices in previous frames, as described below.

[0028] In one implementation, system management circuitry 125 may store data generated due to tracking computational activities at a specific memory location, such as a data array (or other memory location). Furthermore, system management circuitry 125 uses such data to specify operational parameters for subsequent similar frames encountered for rendering. This data is referred to hereinafter as "active data." In one implementation, system management circuitry 125 uses active data to manage the power and frequency consumption of one or more computing units during the execution of various tasks. For example, clock generation circuitry (not shown) may generate a clock signal with a clock frequency predicted using active data.

[0029] In various specific implementations, computing system 100 can be any of a computer, laptop computer, mobile device, server, web server, cloud computing server, storage system, or various other types of computing system or device. It should be noted that the number of components in computing system 100 and / or SoC 105 can vary depending on the specific implementation. The number of each component / subcomponent can be... Figure 1 The number shown may be more or less. It should also be noted that computing system 100 and / or SoC 105 may include... Figure 1 Other components not shown. Additionally, in other specific embodiments, computing system 100 and SoC 105 differ from... Figure 1 The construction is performed as shown.

[0030] Turn now Figure 2 A block diagram of a specific implementation of system management circuit 210 is shown. System management circuit 210 is coupled to computing units 205A to 205N, memory controller 225, phase-locked loop (PLL) unit 230, and voltage regulator 235. System management circuit 210 may also be coupled to... Figure 2 One or more other components not shown. Computing units 205A to 205N represent any number and type of computing units (e.g., CPU, GPU, FPGA, etc.), and computing units 205A to 205N may also be referred to as processors or processing units. In some embodiments, computing units include either or both of general-purpose computing circuitry 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).

[0031] System management circuit 210 includes control circuit 240, power distribution circuit 215, and power management circuit 220. In the example shown, power management circuit 220 is shown as including activity tracker 202. In some embodiments, control unit 240 is configured to determine how power is distributed in the computing system. In one scenario, in response to the detection of a specific condition, control unit 240 determines a power budget to be allocated to various circuits within the computing system. In some embodiments, system management circuit 210 provides information to one or both of power distribution circuit 215 and power management circuit 220 for making power distribution decisions. Various such embodiments and combinations are possible and conceivable. In one scenario, the aforementioned condition is one that requires reducing the power consumption of the computing system (or some components of the computing system). This condition may occur because the system has reached its maximum permissible power or the allocated power. Alternatively, this condition may occur due to thermal conditions (e.g., the maximum operating temperature has been reached). In response to the detection of this condition, control unit 240 evaluates one or more of various parameters, including the currently running task, task type, stage of a given task, etc. In another scenario, this condition may be intentionally enforced through a strategy / mechanism implemented by the combined hardware and system software / firmware to attempt to achieve a software-dependent optimal operating point for desired power performance settings. In various such implementations, certain attributes of the software application running on the hardware are tracked while the software application is executing (at runtime), and these attributes are used when making decisions at each point in time. It should be noted that while power management circuitry 220 is shown as included within system management circuitry 210, in other implementations, the power management unit circuitry and / or activity tracker 202 are located elsewhere. For example, in one implementation, power management circuitry 220 and activity tracker 202 are located alongside graphics processing unit 140 or some other unit.

[0032] Power allocation circuit 215 is configured to allocate a power budget to each of the computing units 205A through 205N, the memory subsystem including memory controller 225, and / or one or more other components. For the host system, the total amount of power available for distribution by power allocation circuit 215 to components can be limited. Power allocation circuit 215 receives various inputs from computing units 205A through 205N, including the state of the miss status holding register (MSHR) of computing units 205A through 205N, the instruction execution rate of computing units 205A through 205N, the number of pending instructions ready for execution in computing units 205A through 205N, the instruction and data cache hit rates of computing units 205A through 205N, the consumed memory bandwidth, and / or one or more other input signals. The power allocation circuit 215 can use these inputs to determine whether computing units 205A to 205N have tasks to perform, and then the power allocation circuit 215 can adjust the power budget allocated to computing units 205A to 205N based on these determinations (e.g., via control unit 240). The power allocation circuit 215 can also receive inputs from the memory controller 225, including consumed memory bandwidth, 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 circuit 215 can use the state of these inputs to determine the power budget allocated to the memory subsystem.

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

[0034] In one exemplary implementation, power management circuitry 220 manages the system's operating frequency and power consumption. For example, power management circuitry 220 modifies the operating frequency of a computing unit to save power. In another example, for a computing unit performing a computationally intensive task, power management circuitry 220 increases the clock frequency to improve performance. On the other hand, for memory-intensive tasks, power management circuitry 220 does not increase the frequency because such an increase would not improve performance (or the desired improvement).

[0035] Activity tracker 202 is configured to track computational activity of computing devices (such as one or more computing units 205A to 205N) and predict operating parameters (such as clock frequency) for subsequent tasks queued for execution. In one embodiment, during frame rendering, activity tracker 202 is configured to track computational activity for multiple frames within an active period. For each frame, computational activity is tracked during certain time slices identified within the active period. For example, the active period while processing each frame can be divided into "n" time slices, where n can be a fixed, programmable, or dynamically determined positive integer. In one embodiment, the number of slices can be based on the time taken to execute changes in operating frequency or voltage, the sampling interval of system management circuitry 210, etc.

[0036] For example, when rendering the first frame, the active period is divided into four time slices, so that if the application runs at 60Hz, computational activity is tracked for approximately 4.167ms each time, which is equivalent to a quarter of a 60Hz frame. Another approach involves dividing the time slices based on tasks within the frame, with at least one task executed in each of these time slices, once every 16.67ms or every 60Hz time interval. In this case, computational activity for at least one task is tracked for each time slice. This pattern repeats for each frame.

[0037] In one implementation, the activity tracker 202 initiates tracking of computational activity when the execution of the application is initiated by one or more computing units 205A to 205N. In one example, this tracking is for workloads involving the repetitive execution of similar tasks at a periodic rate (e.g., game rendering, video processing, etc.). In another implementation, the activity data generated by tracking computational activity can be updated based on one or more factors. For example, when rendering multiple frames, the activity tracker 202 can re-initiate tracking to update the data if the length of the frame (i.e., the amount of time spent rendering the frame) exceeds the length of the previously rendered frame.

[0038] In one implementation, the computational activity tracked by activity tracker 202 includes at least tracking operating parameters, such as voltage and frequency, while performing a given task. In one example, the operating parameters may indicate the clock frequency supplied to computing units 205A through 205N and other components to perform the given task. Activity tracker 202 is configured to track the operating frequency supplied to the computing units while performing a given task (such as rendering a frame), and then power management circuitry 220 uses the tracked operating frequency to predict and control the clock frequency supplied to one or more computing components to perform other subsequent tasks (e.g., consecutive frames) that are “relatively similar” to the given task. In one implementation, predictions are made for time slices of tasks to be performed based on activity data tracked for time slices of tasks that have previously been performed relatively similar tasks.

[0039] For example, in one implementation, consecutive frames in a scene can be substantially similar due to relatively minor variations between frames. Therefore, when the scene remains unchanged, the execution of a given frame is expected to be similar to the execution of the immediately preceding frame (e.g., consuming similar amounts of processing and data resources, taking similar amounts of time, etc.). Temporal locality between frames allows system management circuitry 210 to correlate time slices associated with a frame (i.e., the frame to be processed) with time slices associated with at least one previously processed frame.

[0040] Referring to the specific implementation of the frame rendering described above, when processing each frame, the activity tracker 202 is configured to track the computational activity of the computing circuitry or processing device within an active period. In various implementations, the active period may include the entire length of the frame or a specific time period during the processing of the frame. As described above, time slices are identified within the active period such that computational activity during each time slice can be tracked and stored as activity data. In one implementation, computational activity is tracked for each frame during each time slice of the active period, and this is performed for multiple frames. In one implementation, the tracked computational activity indicates at least one task performed during a given time slice, such that the activity data is used to correlate time slices of different frames with each similar task performed while processing different frames. In one example, the correlation between the activity data and time slices of different frames can be stored as a lookup table or other suitable data structure (e.g., Figure 4(Details are provided). Furthermore, each such element of the data structure can be identified as corresponding to a portion of a frame and stores the corresponding operating frequency. This data is then used on a later frame to predict the operating frequency for rendering that later frame. In one example, the operating frequency is predicted using corresponding active data from one or more time slices in the original frame (and other similarly rendered frames from previous times) and one or more time slices in the later frame. In another example, a clock generation circuit (not shown) can generate a clock signal with a clock frequency predicted using the active data. Other specific implementations are envisioned.

[0041] In another implementation, one or more parameters may also include the power state of the computing component while performing a given task, and the sensitivity of the computing unit to changes in said power state. In one example, the sensitivity of the computing unit to power changes may indicate how responsive the unit's performance is 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 activity data, power state, and the computing device's sensitivity to changes in the power state of a given task, power management circuitry 220 manages the computing device's power consumption for subsequent tasks relatively similar to the given task.

[0042] Predicting operating parameters based on activity data can advantageously facilitate efficient power savings by allowing the power management circuitry 220 to track intra-frame workload variations and more optimally determine the target frequency for each phase, rather than simply tracking average behavior over one or more frames. The systems and methods described herein can also lead to improvements in the performance-per-watt efficiency of the processing device.

[0043] Figure 3 An example is illustrated by a system management circuit 310, which includes control circuitry 322, power distribution circuitry 314, and power management circuitry 318. Power management circuitry 318 also includes an activity tracker 302 and a workload / domain unit 304. Control circuitry 322 is configured to determine how power is allocated within the computing system. Power distribution circuitry 314 is configured to allocate a power budget to one or more computing units (not shown) based at least in part on task-related information 306 received from a task scheduler. Furthermore, power management circuitry 318 manages the operating frequency and power consumption of the computing system.

[0044] System management circuitry 310 is also shown configured to receive any number of various system parameters, denoted as 320A-320N, corresponding to system conditions, operations, or states. In the example shown, parameters include the operating temperature 320A of a given cell, the current drawn by the given cell 320B, the operating frequency of the given cell 320C, and frame markers 320D (e.g., indicating the start and end of a frame). Other parameters are also possible and conceivable. In one embodiment, frame marker 320D includes information related to the individual frames being rendered, such as frame length, frame performance markers, frame start frequency, etc. In one embodiment, frame marker 320D includes at least frame boundary information, enabling activity tracker 302 to identify when a frame ends and when a new frame begins. Furthermore, one or more performance counter metrics 308 are received, providing information about the GPU's performance during a specific task or workload. These metrics can be used to identify performance bottlenecks, optimize performance, and debug problems.

[0045] In various implementations, one or more parameters are reported from other units or parts of the system (e.g., based on sensors, performance counters, other event / validity detections, or other means). In some implementations, one or more parameters are tracked within system management circuitry 310. For example, when multiple tasks are performed, system management circuitry 310 tracks computational activity during an active period. In one implementation, when a task involves rendering a frame, the system management circuitry is configured to track computational activity of a computing device (e.g., a computing unit) over a given amount of time, where the amount of time consists of one or more time slices. For example, during frame processing, system management circuitry 310 invokes activity tracker 302 to track computational activity in each time slice of each frame within an active period. That is, for each frame, during a given time slice, activity tracker 302 tracks the system's operating parameters as the frame is processed. This tracking is repeated for multiple frames. In one implementation, time slices are identified based on the frame length of each frame under consideration. For example, “N” time slices can be identified such that, assuming each frame is “N*M” MS long, each slice is “M” MS long. For each of the N time slices, the activity tracker 302 tracks the computational activity of the corresponding frame. In various implementations, the tracked computational activity includes at least information about the operational parameters of the computational units when performing one or more tasks and subtasks associated with the processing of the frame. Tasks may include scene setting, geometry processing, shading, rendering, post-processing, etc. Other implementations are envisioned.

[0046] In some implementations, workload / domain circuitry 304 is configured to determine how the characteristics of a given task within a set of given tasks differ from previously executed tasks. Any change in a given characteristic can instruct activity tracker 302 to initiate tracking of computational activity. Furthermore, while activity tracker 302 is currently tracking computational activity, a change in the given characteristics of one or more tasks can further instruct activity tracker 302 to recalibrate the activity period and the resulting time slices. In various implementations, recalibration of the activity period and time slices involves at least modifying the duration of the activity period and / or one or more time slices within the activity period. For example, a recalibrated activity period can be generated by changing the duration and number of time slices of a previously generated activity period. For example, an activity period of T milliseconds and comprising N time slices can be recalibrated to have a duration greater than or less than T milliseconds. Thus, the time slices are recalibrated to be greater than or less than N time slices. It should be noted that this implementation is described to provide a simplified illustration of recalibrating activity periods and resulting time slices. However, in operation, more complex calculations may be involved in such recalibration. Such implementations are envisioned.

[0047] As mentioned above, when a set of tasks includes rendering frames, the characteristics include frame length, and one or more parameters include at least the operating frequency of the computing unit when processing a given frame. Furthermore, the activity tracker 302 can provide the tracked computational activity, stored as activity data, to one or both of the power allocation circuitry 314 and the power management circuitry 318 for making power allocation decisions. These decisions are provided to various processing units as parameter state changes 312. It should be noted that although the methods and systems described herein focus on tracking computational activity to predict the operating parameters of computing units when performing tasks, in several other embodiments, these systems and methods can also be used to predict the operating parameters of other subsystems, such as the memory subsystem. Various such embodiments and combinations are possible and conceivable.

[0048] Now go to Figure 4 This illustrates an exemplary implementation of computational resources for performing tasks for frame processing during one or more activity periods. In one implementation, an activity tracker (e.g., Figure 3 The activity tracker 302 described herein is configured to track the computational activity of one or more computational units within a given time period (hereinafter referred to as an "activity period") that is divided into one or more time slices while processing a frame. In one specific implementation, in order to process each frame, such as Figure 4 The frames depicted (0, 1, M, P, etc.) require a certain amount of power and frequency from the processing unit to perform tasks associated with frame processing. Figure 4The examples depicted illustrate various tasks 402-1 through 402-P. In a specific implementation, these tasks may include geometry processing, coordinate spacing, geometry culling, tessellation, etc., when rendering a frame.

[0049] In one implementation, consecutive frames in a scene can be substantially similar due to relatively minor variations between frames. Therefore, when the scene remains unchanged, the execution of a given frame is expected to be similar to the execution of the immediately preceding frame (e.g., consuming similar amounts of processing and data resources, taking similar amounts of time, etc.). Temporal locality between frames allows the activity tracker to correlate time slices associated with a frame (i.e., the frame to be processed) with time slices associated with one or more previously processed frames. Furthermore, based on this correlation, the system management circuitry predicts the operating parameters of subsequent frames within a given scene.

[0050] In the specific implementation depicted in the figure, frames 0, 1, and 2 are shown as similar, i.e., exhibiting temporal locality between frames. For example, the activities for frames 0, 1, and 2 during time slices 0-0, 1-0, and 2-0 are identical (as indicated by similar shaded bars). Similarly, the activities for frames 0, 1, and 2 during time slices 0-1, 1-1, and 2-1, and time slices 0-2, 1-2, and 2-2 are also identical. It should be noted that for simplicity, only three frames are shown as exhibiting temporal locality; however, in various specific implementations, any number of frames can be similar.

[0051] In one implementation, if a change in the scene is detected, the activity tracker can recalibrate the time slices and track activity data for subsequent frames during the modified time slices. When the activity tracker initiates tracking of computational activity, it first identifies time slices within the activity period of each frame, allowing computational activity to be tracked during each time slice. Figure 4As shown, when processing frame 0, time slices 0-0, 0-1, 0-2, and 0-3 are identified. Similarly, for frame 1, time slices 1-0, 1-1, and 1-2 are identified; for frame 2, time slices 2-0, 2-1, and 2-2 are identified; and for frame M, time slices M-0, M-1, and M-2 are identified. For frame P, time slice P-0 can be identified. In the example described in the figure, time slices are identified based on a scenario where computational resources are evenly divided among multiple tasks. That is, for each task 402-1 to 402-9, a corresponding time slice is identified, such that the activity period is “divided” into three equal time slices. In another case, time slices can also be identified based on the length of the frame. For example, computational activity is tracked during an activity period that includes time slices evenly divided among tasks. Alternatively, the activity period is not evenly divided among tasks, with some tasks performing in time slices longer than others. For example, for frame M, each of time slices M-0, M-1, and M-2 has unequal durations, that is, tasks 402-M1, 402-M2, and 402-M3 can have unequal processing times.

[0052] In one implementation, the computational activity of a processing unit can be tracked as one or more tasks are executed during these time slices. For example, for frame 0, task 402-1 is executed during time slice 0-0, task 402-2 during slice 0-1, and task 402-3 during slice 0-3. It should be noted that although for ease of illustration, only a single task is depicted as being executed during a given time slice, multiple tasks can be executed during each identified time slice. In one implementation, during each time slice, an activity tracker tracks computational activity as one or more tasks are executed, and the activity data resulting from this tracking is stored in a data structure.

[0053] In one implementation, a given time slice of a frame is associated with one or more time slices of one or more previously processed frames. In another implementation, this association is performed based on memory or engine utilization during similar time slices. Similar time slices can be identified based on the temporal locality of the frames. Figure 4In the example shown, if a computing unit consumes the same amount of power during time slice 1-0 of frame 1 (the active period of frame 1) and time slice 0-0 of frame 0 (the active period of frame 0) within a given time percentage, these time slices are correlated with each other. Furthermore, based on this correlation, the operating parameters of each computing unit can be predicted for subsequent frame rendering. For example, during time slice P-0, within the active period of frame P, the computing activity data stored during time slices 0-0, 1-0, 2-0, etc., is used to predict the operating parameters for performing task 402-P, and these time slices are further correlated with time slice P-0 (using the same shading pattern to depict similar correlated time slices).

[0054] In one implementation, the operational parameters of task 402-P executed by the computing unit during time slice P-0 can be calculated using stored activity data, for example, as the average operating clock frequency during time slices 0-0, 1-0, and 2-0. Other implementations are envisioned. In one example, the activity data can be stored in any data structure, such as a lookup table. The activity data includes data generated due to tracking computational activity, including frame information, the corresponding time slice, the executed task, and the operational parameters calculated for each task. Other operational parameters such as power supply, voltage, number of cores, and amount of RAM utilized can also be included in the activity data.

[0055] Based on predicted operating parameters, the system management circuitry can manage the system's operating frequency and voltage. In an exemplary embodiment, if a computing unit is consistently underutilized during a given time slice of a predetermined number of processing frames, the system management circuitry can reduce the frequency and voltage of the computing unit during the corresponding time slice of a subsequent frame, for example, to achieve higher power efficiency. In another embodiment, if the memory subsystem utilizes more power than a threshold during a given time slice of a predetermined number of processing frames, the power supply can be increased for the same time slice of a subsequent frame. Various such embodiments for managing the system's operating parameters using computational activity tracked during time slices are possible and conceivable.

[0056] Now go to Figure 5 An exemplary method 500 is illustrated for tracking computational activity to predict one or more parameters scheduled for execution. It should be noted that although method 500 is described in relation to frame rendering, other specific implementations related to various computational tasks are also conceivable.

[0057] In one implementation, the system management circuitry identifies multiple time slices within a given time period when processing multiple frames (box 502). In one implementation, time slices are identified such that computational resources are evenly distributed among multiple tasks. That is, for each task, a corresponding time slice is identified such that a given time period is “divided” into equal time slices. In another implementation, time slices are based on the frame length of the frames under consideration. Other implementations are envisioned for determining which time slices to consider within a given time period to track computational activity. Furthermore, for each of the multiple frames, a time period and a corresponding time slice are identified for tracking computational activity.

[0058] For each time slice within a given time period, the activity tracker tracks computational activity as the frame is processed (box 504). In one implementation, for each currently processed frame, a task and associated subtasks are executed within each identified time slice. The activity tracker is configured to track computational activity during each time slice and store the data resulting from the tracking as activity data. Tracking continues for each frame during each time slice within a given time period.

[0059] Based on activity data, a time slice corresponding to a given frame is associated with a time slice associated with at least one previously processed frame from multiple frames (box 506). In one embodiment, the time slice associated with a given frame is associated with a time slice corresponding to at least one previously processed frame based on a comparison of computational activity for the given frame with computational activity tracked during the time slice corresponding to the at least one previously processed frame. For example, for similar tasks performed on both the given frame and at least one previously processed frame, the time slices of the two frames can be associated based on activity data stored for the previously processed frames.

[0060] The system management circuitry is configured to predict operating parameters for a given frame based on the interrelationships between time slices (box 508). For example, based on activity data identified within a time slice during the rendering of a previously processed frame, the system management circuitry is configured to evaluate the operating parameters of the computational unit for each frame in the previously processed frames during a specific time slice, and predict the operating parameters for the corresponding time slice associated with the given frame. In one embodiment, the operating parameters include at least a clock frequency.

[0061] In one implementation, the processing unit is configured to render a given frame (box 510) based on predicted operation parameters. In another implementation, multiple operation parameters, such as multiple operation frequencies and clock signals, are predicted for a time slice in the given frame based on activity data recorded during a corresponding time slice in a previously rendered frame. The processing unit can then predict specific operation parameters to render the given frame and perform a task during a specific time slice based on those specific operation parameters.

[0062] In one embodiment, during the processing of each frame, the system management circuitry also determines that recalibration conditions (condition box 512) are met. According to this embodiment, recalibration conditions include changes in the frame length of a given frame. Such changes can be due to changes in the scene or other aspects. In other embodiments, recalibration conditions may also include unplanned changes in frequency or supply power, system failures, temperature changes, etc. In other embodiments, recalibration conditions may also include operating parameters stored in the active data not meeting certain criteria. For example, recalibration can be initiated if the computing unit or memory subsystem in a different time slice of a frame exhibits behavior that appears significantly different from the corresponding behavior in the same time slice of a previous frame.

[0063] If the recalibration conditions are met (condition box 512, "Yes" box), the system management circuitry modifies the time slice, that is, modifies the tracking frequency or tracking period of computational activities within a given time period. However, if the recalibration conditions are not met (condition box 512, "No" branch), the method proceeds to box 504, where the tracking of computational activities continues.

[0064] Unless otherwise stated, the specific embodiments described are non-limiting. That is, the disclosed specific embodiments are not intended to limit the scope of the claims drafted based on this disclosure, even where only a single example is described with respect to a particular feature. The disclosed specific embodiments are intended to be illustrative and not restrictive unless otherwise stated in this disclosure. Therefore, this application is intended to allow for claims covering the disclosed specific embodiments, as well as such alternatives, modifications, and equivalents that will be apparent to those skilled in the art who benefit from this disclosure.

[0065] For example, features in this application can be combined in any suitable manner. Therefore, during the examination of this application (or an application claiming priority thereto), new claims can be formulated for any such combination of features. Specifically, referring to the appended claims, features from dependent claims can be combined, where appropriate, with features from other dependent claims (including claims dependent on other independent claims). Similarly, features from corresponding independent claims can be combined, where appropriate. Thus, while the appended dependent claims can be drafted such that each dependent claim depends on a single other claim, additional dependent relationships are also contemplated. In this application or another application, any combination of features in dependent claims consistent with this disclosure is contemplated and can be claimed. In short, combinations are not limited to those specifically listed in the appended claims.

[0066] Where appropriate, it is also conceivable that claims drafted in one format or statutory type (e.g., apparatus) are intended to support corresponding claims in another format or statutory type (e.g., method).

[0067] Unless the context clearly specifies otherwise, references to the singular form of an item (i.e., a noun or noun phrase preceded by "an," "a," or "the") are intended to mean "one or more." Therefore, without accompanying context, a reference to "item" in a claim does not exclude additional instances of that item. "A plurality of" items refers to a collection of two or more items within an item.

[0068] The terms “including” and “comprising” and their forms are open-ended and mean “including but not limited to”.

[0069] The phrase "based on" or "used for" describes one or more factors that influence the determination. This term does not exclude the possibility that additional factors might influence the determination. That is, the determination may be based solely on the specified factor or on the specified factor along with other unspecified factors. Consider the phrase "A is determined based on B." This phrase indicates that B is a factor used to determine A or that affects the determination of A. This phrase does not exclude the possibility that the determination of A may also be based on some other factor, such as C. This phrase is also intended to cover implementations in which A is determined solely based on B. As used herein, the phrase "based on" is synonymous with the phrase "at least partially based on."

[0070] The phrases “responding to” and “in response to” describe one or more factors that trigger an effect. This phrase does not exclude the possibility that additional factors may influence or otherwise trigger the effect, whether in conjunction with or independently of the specified factors. That is, the effect may respond only to those factors, or it may respond to the specified factors as well as other unspecified factors. Consider the phrase “responding to B to execute A.” This phrase indicates that B is a factor that triggers the execution of A or will trigger a specific result of A. This phrase does not exclude that the execution of A may also respond to another factor such as C. This phrase also does not exclude that the execution of A may jointly respond to B and C. This phrase is also intended to cover implementations that execute A in response only to B. As used herein, the phrase “responding to” is synonymous with the phrase “at least partially responding to.” Similarly, the phrase “responding to” is synonymous with the phrase “at least partially responding to.”

[0071] Within this disclosure, different entities (which may be referred to differently as “cells,” “circuits,” other components, etc.) may be described or claimed to be “configured” to perform one or more tasks or operations. This expression (an entity configured to [perform one or more tasks]) is used herein to refer to a structure (i.e., a physical structure, such as a circuit). More specifically, this expression is used to indicate that the structure is arranged to perform the one or more tasks during operation. A structure may be referred to as being “configured” to perform a task even when the structure is not currently operating. Therefore, an entity described or stated as being “configured” to perform a task refers to a physical entity, such as a device, circuit, system with processor units, and memory storing program instructions that can be executed to perform the task. This phrase is not used herein to refer to an intangible entity.

[0072] In some cases, various units / circuits / components may be described herein as performing a set of tasks or operations. It should be understood that even if not specifically stated, those entities are "configured" to perform those tasks / operations.

[0073] For the purposes of this U.S. patent application, the statement in the claims that a structure is “configured” to perform one or more tasks should be expressly interpreted as... Unintentionally 35 USC § 112(f) is invoked for this claim element. If the applicant wishes to invoke Section 112(f) during the examination of a U.S. patent application based on this disclosure, it will use the term "means" for "construction for" [performing a function] to describe the claim element.

[0074] Different “circuits” may be described in this disclosure. These circuits constitute hardware comprising various types of circuit elements, such as combinational logic, clock storage devices (e.g., flip-flops, registers, latches, etc.), finite state machines, memories (e.g., random access memory, embedded dynamic random access memory), programmable logic arrays, etc. Circuits may be custom-designed or obtained from standard libraries. In various specific implementations, circuits may suitably include digital components, analog components, or a combination of both. Certain types of circuits may generally be collectively referred to as “units” (e.g., decoding units, arithmetic logic units (ALUs), functional units, memory management units (MMUs), etc.). Such units also refer to circuits.

[0075] Therefore, the disclosed circuits / units / components, as well as other elements illustrated in the accompanying drawings and described herein, include hardware elements such as those described in the preceding paragraphs. In many cases, the internal arrangement of hardware elements within a particular circuit can be specified by describing the function of that circuit. For example, a particular “decoding unit” can be described as having the function of executing “the opcode of a processing instruction and routing that instruction to one or more of a plurality of functional units,” meaning that the decoding unit is “configured” to perform that function. To those skilled in the art of computers, such a functional specification is sufficient to suggest a set of possible structures for the circuit.

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

Claims

1. A system comprising: System management circuit, the system management circuit being configured to: The computational activity of the computing device is tracked when processing two or more frames out of a total of multiple frames, where each frame includes multiple time slices; as well as The clock generation circuit generates a clock signal with a predicted clock frequency, wherein the predicted clock frequency is based at least in part on the correlation between computational activities during a time slice of the first frame and computational activities during a time slice of the second frame.

2. The system of claim 1, wherein the system management circuitry is further configured to store data corresponding to computational activities tracked for each of the plurality of time slices of the plurality of frames.

3. The system of claim 1, wherein the clock signal is used to render frame data.

4. The system of claim 1, wherein the system management circuitry is further configured to recalibrate the active period of a given frame in response to a recalibration condition.

5. The system of claim 4, wherein the recalibration conditions include one or more of the following: a change in the frame length of the given frame, one or more unplanned changes in the clock frequency or supply power of the system, and computational activity data of tracking that does not meet the given criteria.

6. The system of claim 1, wherein the computational activity is stored as activity data, and wherein the activity data is updated in response to a change in at least one characteristic associated with at least one of the plurality of frames.

7. The system of claim 1, wherein the plurality of time slices are defined at least in part based on the processing time of each frame.

8. A method, the method comprising: The computational activity of the computing device is tracked when processing two or more frames out of a total of multiple frames, where each frame includes multiple time slices; as well as The clock generation circuit generates a clock signal with a predicted clock frequency, wherein the predicted clock frequency is based at least in part on the correlation between computational activities during a time slice of the first frame and computational activities during a time slice of the second frame.

9. The method of claim 8, further comprising storing data corresponding to computational activities tracked for each of the plurality of time slices of the plurality of frames.

10. The method of claim 8, further comprising using the predicted clock frequency to render frame data.

11. The method of claim 8, further comprising recalibrating the active period of a given frame in response to a recalibration condition.

12. The method of claim 11, wherein the recalibration conditions include one or more of the following: a change in the frame length of the given frame, one or more unplanned changes in clock frequency or power, and computational activity data of tracking that does not meet a given criterion.

13. The method of claim 8, wherein the computational activity is tracked in response to a change in at least one characteristic associated with at least one of the plurality of frames.

14. The method of claim 8, wherein the plurality of time slices are defined at least in part based on the processing time of each frame.

15. A computing system, the computing system comprising: A computing device configured to process frames; and System management circuit, the system management circuit being configured to: The computing activity of the computing device is tracked while processing each of the multiple frames, wherein the computing activity is tracked at least within a given time period comprising multiple time slices; Based at least in part on the tracked computational activity, the time slice associated with a given frame is correlated with the time slice associated with at least one previously processed frame from the plurality of frames; The clock frequency associated with the rendering of the given frame is predicted, at least in part, based on the said interrelationship; as well as The given frame is rendered using the predicted clock frequency.

16. The computing system of claim 15, wherein the system management circuitry is further configured to store data generated due to computing activities tracked for each of the plurality of time slices of the plurality of frames.

17. The computing system of claim 15, wherein the time slice associated with the given frame is correlated with the time slice associated with at least one previously processed frame based on a comparison of computing activity of the given frame with computing activity tracked during a time slice associated with at least one previously processed frame.

18. The computing system of claim 15, wherein the system management circuitry is further configured to: In response to a recalibration condition, one or more time slices of the given frame are recalibrated; and The one or more time slices of the given frame are modified based on the recalibration.

19. The computing system of claim 15, wherein the system management circuit is further configured to: In response to identifying a recalibration condition, recalibrate one or more time slices of the given frame; and The one or more time slices of the given frame are modified based on the recalibration.

20. The computing system of claim 19, wherein the recalibration conditions include one or more of the following: a change in the frame length of the given frame, one or more unplanned changes in the clock frequency or supply power of the system, and computational activity data of tracking that does not meet a given criterion.

Images