Graphics power management

Minutes from mini-summit at Linaro Connect 2011Q4

  • Available measurements and controls for the current generation GPUs: tweaking clock gating and dvfs is possible with the graphics drivers. Kernel driver sets the frequency and pm figures out the voltage. Kernel graphics driver knows when the GPU is used to do something. The trick is how smooth the UI interaction is supposed to be, pipelines are very deep and doing anything that involves either stalling it or flushing the queue for power savings can be expensive and can cause issues with quality. If you want to use dvfs you want to protect the future - in terms of protecting how long it will take to render the frame and make sure the GPU will be available in order to avoid stutters. In the 3d space you tend to render the entire scene at each frame.
    • Other issue: MALI 400 is quad core in samsung implementation, single core in STE. So there are differenced in the amount of processors used depending on the implementation, for SGX you can control the PM parts via micro controller on HW, but for Mali it can be done so that there is no HW control of the power management. Does the driver manage what it needs - or are all cores used full blast: the driver is trying to maintain an avg usage of the cores (this handling is done internally in the driver). Need a link for the MALI400 kernel driver (chunsang's git tree), also for the PVR driver.

  • What measurements and controls the sw would ideally have access to, what counters do you use to throttle the power: the dvfs on-demand governor uses the cpu usage counts, as well as the idle counter which is used to reach an off state.
    • Available in the GPU driver
      • Clock gates - going to clock gating from no clock gating is the basic PM. But moving to higher frequencies requires finer controls.
      • DVFS (Mali400 Android example)

      • Driver enables clock (kernel takes care of dependencies)
      • GPU cores can idle (plug into the idle framework?)
    • Does the linux scheduler have a notion of the usage of GPUs?
    • Access to specifications for the HW: it is not a given unless you work for the GPU itself. Perhaps it is possible to get clear answers to specific questions.
    • Can the GPU cores idle? This needs to be checked from PM pov
    • Coordinating access to shared memory between the GPU and CPU: synchronizing, minimizing the overlaps (getting to sleep more often). It's generally the case that the GPU goes on to do its stuff and does not need to wake up the CPU.
      • Graphics clock domain for typical SoC: keeps the L3 alive (core power domain - CPU). So a lot of things are kept awake on the SOC.
      • In most cases (especially for Android) GPU and CPU work at the same time - especially for Android the GPU is on most of the time
  • What capabilities the next generation gpus might have
  • Recommendations for the design teams at a GPU vendor - we are asking for some sort of instrumentation to tell us the utilization of the GPU (exists for performance tuning for SGX)
    • Having some controls to play around with dvfs or idling would be good
    • SGX has a tool called pvrtune
    • MALI400 has a tool called PAT(Performance Analysis Tool)
  • General questions
    • How much video lag is allowed:
      • Watching a movie: a 15 msec frame loss would be noticeable
    • Apps that use the GPU do their own calibration at the startup - may tune assuming full blast and keep throwing frames at the GPU. Will only slow down if not fed enough frames.
      • Closest thing that some kernel drivers might do is audit the memory references from the GPU, in a command buffer. But in SGX the kernel does not even see the command stream.
      • Could the buffer fullness be checked? It varies depending on the case - would need to probably do a lot of sampling to try and guess what the GPU needs. How about checking at a later stage buffer beyond the GPU processing - however the worst you will get (1-2 frames of lag) will be noticeable. The bottom line of 60 fps means something like 30msec window time.
      • Key thing is interactivity - so input is needed, can that be leveraged? Could that mean putting some control in the touchscreen drivers to control the GPU?
    • Connecting the graphics multimedia and power management through the UMM: if we can compact the memory at kernel level maybe we can switch off a ddr bank - is this something feasible (memory power management)? You'd probably want the GPU to participate in whatever scheme to arrange for memory. Or when going to sleep mode - trash the buffers. You will know when checking what memory migration can happen in the graphics driver. So memory power management is not going to happen in any short term timespace. How about memory region support - would it be possible to use that work to create special memory regions to start at least playing with this idea?

WorkingGroups/Middleware/Graphics/Docs/GPUPowerManagement (last modified 2012-02-10 19:40:16)