1. Adaptive Video Coding to Reduce Energy on General Purpose Processors Daniel Grobe Sachs, Sarita Adve, Douglas L. Jones University of Illinois at Urbana-Champaign http://www.cs.uiuc.edu/grace grace@cs.uiuc.edu

2. Introduction  Wireless multimedia increasingly common  Recent advances reduce constraints:  2GHz+ processors  High-speed wireless networks  Systems now Energy limited  Energy management essential

3. Adaptation  Adaptation key to energy management  Hardware adaptation already common  Software adaptation also possible  Challenges  How do we control adaptations?  How do we coordinate different adaptations?

4. GRACE Project  Target mobile multimedia devices.  Coordinated adaptation of all system layers  Hardware, application, network, OS  Complete cross-layer adaptation framework  Preserves separation between layers

5. Goals of this work  Target wireless video transmission  Adapt application: Adaptive video encoder  Adapt hardware: Adaptive CPU  Implement part of GRACE framework  Trade off between CPU and network energy

6. Contributions  Apply existing adaptive-CPU research  Energy-adaptive video encoder  Trades off between network, CPU  Allows adaptation with fixed QoS  Cross-layer adaptation framework  Coordinate app and CPU adaptation  Preserves logical separation between layers  20% Energy savings over existing systems

7. Presentation Overview  System model  System architecture and design  Cross-layer adaptation process  Results

8. System Model  Total Energy = CPU Energy + Network Energy Adaptive CPU Adaptive Video Encoder Control Wireless Network Video Capture

9. CPU Hardware Adaptation [Micro]  Reduce performance to save energy  Voltage and frequency scaling  Lower freq  lower voltage  lower energy  Architecture adaptation  Issue width  Active functional units (ALUs, etc.)  Instruction window size

10. Adaptive Encoder  Based on TMN H.263 encoder  Changed to logarithmic motion search  Encoder adapts for energy  Trade off between network and CPU energy  More computation  fewer bits  Adapt Motion Search and DCT  Computationally expensive  Elimination affects primarily rate

11. Adaptive Encoder Details  Motion Search and DCT thresholds  Terminate MS early when SAD under threshold  Skip DCT if SAD of block under threshold  Transmit “DCT flag” bit for each 8x8 block  Extends H.263 standard  Adaptation effect:  Setting thresholds at infinity  Reduces CPU load by ~50%  Increases data rate by 2x or more

12. Adaptation Control  When do we adapt?  What configurations do we choose?

13. Adaptation Control  When do we adapt?  Adapt before every frame  What configurations do we choose?

14. Adaptation Control  When do we adapt?  Adapt before every frame  What configurations do we choose?  Must minimize total CPU+network energy  Must complete frame within its allocated time

15. Adaptation Control  When do we adapt?  Adapt before every frame  What configurations do we choose?  Must minimize total CPU+network energy  Must complete frame within its allocated time  How do we find the optimal configurations?

16. Optimization  Application, CPU reconfiguration linked  Application reconfiguration changes workload  CPU reconfiguration changes performance  App config affects optimal CPU configuration … and vice versa  Two stage approach 1. For each app config, find CPU config, energy 2. Pick lowest-energy application configuration

17. Optimization Algorithm 1. For each app config, find  Best CPU config  CPU energy  Network energy  Total energy = CPU energy + network energy 2. Pick app config with lowest total energy

18. Optimization Algorithm 1. For each app config, find  Best CPU config – completes in time, with least energy [MICRO’01]  CPU energy  Network energy  Total energy = CPU energy + network energy 2. Pick app config with lowest total energy

19. Optimization Algorithm 1. For each app config, find  Best CPU config – completes in time, with least energy [MICRO’01]  CPU energy  Network energy  Total energy = CPU energy + network energy 2. Pick app config with lowest total energy Requires instruction count

20. Optimization Algorithm 1. For each app config, find  Best CPU config – completes in time, with least energy [MICRO’01]  CPU energy = Instruction count x Energy per instruction [MICRO’01]  Network energy  Total energy = CPU energy + network energy 2. Pick app config with lowest total energy Requires instruction count

21. Optimization Algorithm 1. For each app config, find  Best CPU config – completes in time, with least energy [MICRO’01]  CPU energy = Instruction count x Energy per instruction [MICRO’01]  Network energy = Byte count x Energy per byte [WaveLAN measured]  Total energy = CPU energy + network energy 2. Pick app config with lowest total energy Requires instruction count

22. Optimization Algorithm 1. For each app config, find  Best CPU config – completes in time, with least energy [MICRO’01]  CPU energy = Instruction count x Energy per instruction [MICRO’01]  Network energy = Byte count x Energy per byte [WaveLAN measured]  Total energy = CPU energy + network energy 2. Pick app config with lowest total energy Requires byte count Requires instruction count

23. Adaptation Process: Stage 1 App. Conf. 1 CPUNet Predict Next Instr. Count Predict Next Byte. Count Conf 1 Energy Conf 2 Energy Conf 3 Energy... Conf n Energy App configuration energy table

24. Adaptation Process: Stage 1 App. Conf. 1 CPUNet Predict Next Instr. Count Predict Next Byte. Count Conf 1 Energy Conf 2 Energy Conf 3 Energy... Conf n Energy App configuration energy table Find CPU Configuration CPU Optimizer

25. Adaptation Process: Stage 1 App. Conf. 1 CPUNet Predict Next Instr. Count Predict Next Byte. Count Conf 1 Energy Conf 2 Energy Conf 3 Energy... Conf n Energy App configuration energy table CPU Energy Estimator Predict CPU Energy Predict Net Energy Find CPU Configuration Network Energy Estimator CPU Optimizer

26. Adaptation Process: Stage 1 App. Conf. 1 CPUNet Predict Next Instr. Count Predict Next Byte. Count + Conf 1 Energy Conf 2 Energy Conf 3 Energy... Conf n Energy App configuration energy table CPU Energy Estimator Predict CPU Energy Predict Net Energy Find CPU Configuration Network Energy Estimator CPU Optimizer

27. Adaptation Process: Stage 1 App. Conf. 1 CPUNet Predict Next Instr. Count Predict Next Byte. Count + Conf 1 Energy Conf 2 Energy Conf 3 Energy... Conf n Energy CPU Energy Estimator Predict CPU Energy Predict Net Energy Find CPU Configuration Network Energy Estimator CPU Optimizer

28. Adaptation Process: Stage 1 App. Conf. 1 CPUNet Predict Next Instr. Count Predict Next Byte. Count + Conf 1 Energy Conf 2 Energy Conf 3 Energy... Conf n Energy CPU Energy Estimator Predict CPU Energy Predict Net Energy Find CPU Configuration Network Energy Estimator CPU Optimizer

29. Adaptation Process: Stage 2 Conf 1 Energy Conf 2 Energy Conf 3 Energy... Conf n Energy

30. Adaptation Process: Stage 2 Conf 1 Energy Conf 2 Energy Conf 3 Energy... Conf n Energy Pick Lowest Energy

31. Adaptation Process: Stage 2 Conf 1 Energy Conf 2 Energy Conf 3 Energy... Conf n Energy Pick Lowest Energy CPU Adaptor Chosen Configuration Application Adaptor

32. Adaptation Process: Stage 2 Conf 1 Energy Conf 2 Energy Conf 3 Energy... Conf n Energy Pick Lowest Energy CPU Adaptor Chosen Configuration Application Adaptor Capture, Encode, and Transmit Frame

33. Predictors  How do we predict instructions and bytes?  Fixed software  use previous frame data  Adaptive software  no longer works!  Solution: Offline profiling  Encode reference sequences offline  Transition randomly between app. configs  Fit predictors to transitions between configs  Map last instruction, bytes to new app. config  Linear, 1 st -order predictors

34. Experiments  RSIM CPU simulator  State-of-the-art CPU, memory  Princeton Wattch energy model  Reported energy typical of modern CPUs  Simulation Conditions:  Fixed and adaptive CPU  Fixed and adaptive software  Foreman sequence

35. Fixed vs Adaptive Systems  Adaptive hardware saves 70% over fixed system  Adaptive application saves  30% on fixed hardware  20% on adaptive hardware (total savings of 80%) 0 5 10 15 20 25 30 35 30.49 21.23 7.36 6.25 Net CPU Adaptive H/W Adaptive S/W Adaptive Sys Fixed System Energy (J)

36. Algorithm Comparison  Baseline: Fixed software, adaptive hardware  Adaptive software:  Adaptive DCT/motion thresholds  Instruction, byte count for next frame predicted  Oracle  Instruction and byte count for next frame exact  Adapt-Once  Adapt once at start of encoding  Minimize total energy across entire sequence

37. 0 2 4 6 8 7.36 6.55 6.09 6.25 Algorithm Comparison Energy (J) Net CPU Adapt Once Fixed Adaptive Oracle  Energy consumption of Adaptive within 3% of Oracle  Simple predictors sufficient for energy savings  Adaptive saves 5% over Adapt-Once  Frame-by-frame adaptation can save energy

38. Other test cases  Low Power CPU  Network energy dominated  Software adaptation did not save energy  Carphone  Little inter-frame variation  One-shot adaptation was sufficient  Adapt-Once, Adaptive, Oracle same energy  Adaptive software saved ~15%

39. Conclusions  A new framework for coordinated CPU/application adaptation  Combined benefits of both adaptations  Preserves separation between layers  Adaptive applications save energy:  Up to 20% on adaptive hardware  Up to 30% on fixed hardware