Edited by Chunsang Jeong. Send review comments to chunsang.jeong@linaro.org.


The intent of this document is investigating what are needed to save GPU power and what kinds of measurement and control are considered to the purpose.

As current embedded system (and x86) requires higher resolutions for the display and complex 3D rendering, it requires high GPU performance, which makes GPU as one of the huge power consumer of the system with multi-core based architecture. By comparing CPU power management, there isn't sufficient commonly controllable GPU power management in the kernel.

Our kick-off event was a mini-summit at the 2011.Q4 Linaro Connect. The minutes from that session are available here.


Graphics Processing Unit
Power Management Unit
Dynamic Voltage and Frequency Scaling

Overall GPU power management

Inside of GPU

Built-in PMU inside of GPU measures loads of cores in GPU and provides per core turn on/off as the load of data to handle. Meanwhile the load balancing of the cores inside of GPU can be happened by the GPU drivers or built-in h/w mechanism, which depends on the GPU power management architecture. Usuallly GPU doesn't support per-core control out of GPU.

Outside of GPU

GPU driver gets utilization of the GPU by checking the h/w register or getting utilization ratio from GPU driver, and scaling the input of the clock and power as the utilization ratio. If there isn't any activity in the GPU ( if utilization is 0), turn on/off the GPU power domain by gating the clock and power to GPU. These are known as DVFS or external PMU.

Power saving during GPU works

  • DVFS.
  • Auto power control(if GPU has internal PMU)

Power saving when GPU is idle

  • Runtime Power Management
  • Gating clock and power


Governors for GPU

Feasibility of gpufreq and GPU governor which can be migrated form cpufreq.

  • Performance: Sets highest CPU frequency and power for CPU to have max performance within CPU operation range.
  • Powersave: Sets lowest CPU frequency and power for CPU to have max power saving within CPU operation range.
  • Ondemand: Sets CPU frequency and power depending on CPU utilization.
  • Userspace: Provides user setting interface for CPU frequency and power.
  • Limitation to GPU Governors: GPU doesn't support per GPU core control because of it's pipelined architecture.
  • Question: For powersaving, does GPU need to provide all kinds of governors which CPU has or just need dynamic power control governor will be enough, based on CPU ondemand governor?

Runtime power management

Runtime power management is a system-wide power management which makes idle devices can be suspended. In a view of GPU driver, it's an event from system to suspend/resume for GPU driver. When the GPU gets suspend from the system, it saves context and turn off clock and power for GPU. If GPU gets resume event from system, it turn on GPU(wake up) and restores context. If GPU works with DVFS, it will decide start frequency clock and power. Usually GPU driver supports runtime power management framework in GPU driver.

GPU Suspend/Resume

GPU suspend/resume need to be integrated into runtime power management and DVFS if GPU uses. It supports for GPU to work without losing data.

System Monitoring

For GPU power management, it needs to monitor system information such as;

  • Current CPU clock
  • GPU input clock
  • Operation range of GPU clock.
  • System power supply(regulator) operation range
  • Current GPU input power.
  • GPU utilization from GPU driver.

Most of the case, reducing the power input to GPU is much more effective then reducing clock input to GPU for power saving (DVS is more effective than DFS), so the GPU power management needs to get the system power(regulator) information.

Remained topics

Out of GPU bottleneck

Bottleneck can be happened out of GPU and GPU driver, even though GPU doesn't work with full performance,

  • Bus bandwidth.
  • Memory bandwidth.
  • User space GPU driver as a big CPU consumer.
  • Question: Does GPU need to get CPU utilization information?

Multi-process environment

  • Android uses GPU all the time as default rendering and has more complex use cases to handle.
  • Anything to consider more for multi-process GPU consumer environment such as Android?

X86 extension

Compatibility with X86 architecture?


WorkingGroups/Middleware/Graphics/Projects/GpuPowerManagement (last modified 2012-01-23 17:25:29)