Qualcomm Power Optimization SDK
With its multicore CPU, Qualcomm® Adreno™ GPU and Qualcomm® Hexagon™ DSP, the Qualcomm® Snapdragon™ mobile platform is designed for heterogeneous computing. All three cores (devices) put heterogeneous computing within the reach of mobile app developers and the users of their applications.
To get the most out of heterogeneous computing on Snapdragon mobile platforms, developers can use APIs in the Qualcomm® Snapdragon™ Heterogeneous Compute SDK and the Qualcomm® Snapdragon™ Power Optimization SDK to balance performance and power consumption. The SDKs complement each other in allowing for placement of workloads on the cores best suited to execute them power-efficiently.
This tutorial walks through the components of the Power Optimization SDK, including sample code that demonstrates the main features developers can use on the CPU and GPU. It builds on the performance-improving components and code explored in the Heterogeneous Compute SDK.
The main intent of the Power Optimization SDK is to provide APIs to developers that they can integrate to their applications to optimize and lower power consumption.
Approaches to power management
First, as depicted in the image below, there are two approaches to power management: reactive and proactive.
The reactive model represents standard power management, where the application runs a workload, and the system, based on how the workload is running, adjusts power within thermal constraints. The reactive model is acceptable in most use cases, but since it’s generic, it leaves room for certain optimizations.
The proactive model picks up where the reactive model leaves off. Developers with a strong understanding of the algorithms built into their apps can make recommendations directly to the system to optimize power consumption while the algorithms are running.
The Power Optimization SDK follows the proactive model. It provides APIs so that, from their algorithms, developers can directly control the clock frequencies at which the CPU and GPU run.
Power requests are subject to system constraints; they don’t override the system. As shown in the diagram below, the SDK makes the requests to an underlying component called Perflock, which determines whether the request can be honored or not.
If another application requires that the CPU and GPU run at a specific frequency, then Perflock will deny the request.
Two variants of power management APIs are available in the Power Optimization SDK: static and dynamic.