Ariaki
/
Back to blog

2026.09.29

0.08 W more, 34 fps to 61: which knob actually saves battery on a handheld?

Same Snapdragon 8 Gen 2 handheld, same game, same scene, ten configurations measured on battery. The Performance power profile was the worst of the lot: highest power draw, lower frame rate. What worked was finding the bottleneck first and then comparing energy per frame. Along the way two sensors lied to me, and one of them almost had me report a 101 fps that never existed.

硬件实测掌机功耗方法论

Same handheld, same game, same scene.

5.85 W, 34 fps. After changing three settings: 5.93 W, 61 fps.

Eight hundredths of a watt more, and the frame rate nearly doubles. Meanwhile the knob most people reach for first, flipping the power profile to "Performance", was the worst of the ten configurations I measured: 9.98 W, 44 fps. About 70% more power than stock, and fewer frames than the middle profile.

The embarrassing part: halfway through, I almost reported "101 fps on Balanced." That number was fake. I was reading the wrong sensor. Section 1 covers that first, because it decides which numbers you should trust for the rest of the post.

If you just want the procedure, jump to the checklist in section 7. If you want to know why one machine needed three different prescriptions for three games, read section 4.

1. The 101 fps I almost shipped

The device is an Android handheld with a Snapdragon 8 Gen 2 (Adreno 740 GPU), running a community-maintained Linux gaming distro. Running x86 Windows games on it means two translation layers: DXVK turns DirectX into Vulkan, and FEX turns x86 instructions into ARM. The game is Dave the Diver, a 2D pixel-art game that really shouldn't be hard work.

The goal was simple: hold 60 fps (120 if possible) and use as little power as possible doing it.

The first round was measured with the charger plugged in. I read frame rate from the stats pipe of gamescope (the compositor, the layer that puts the game's frames on screen), and power from the battery driver's power_now. The numbers looked like this:

  • Eco profile: 68 fps, 7.9 W
  • Balanced profile: 101 fps, 10.3 W

Looked great. Then both numbers fell apart.

The frame rate was compositor frames. The compositor reports how many times it refreshed the screen, and it keeps refreshing even when the game hasn't delivered a new frame. Once I switched to MangoHud's log of frames the game actually submitted, the compositor was saying 68 while the game was producing 33. That's off by more than 2x.

The power number was wrong too. With the charger in, power_now read 43.8 W. I multiplied current and voltage from the same moment myself: 4.36 A × 4.16 V = 18.1 W. The driver's figure was 2.4x too high, and while charging, the battery current includes charge current anyway, so you can't isolate what the game is drawing.

So that entire round went in the bin. The re-test had two rules:

power = |battery current × battery voltage|, charger unplugged, status must read Discharging
fps   = frames the game submitted (MangoHud log), never the compositor's count

Charging has a third trap: playing while charging pushed the GPU to 84°C, right against the 85°C passive throttling threshold, and its clock dropped from 680 MHz to 401–475 MHz. A plugged-in measurement is a measurement of a machine running a fever. It's a different machine from the one you play on battery.

That's also my first set of questions whenever I see someone's handheld power screenshot: game frames or compositor frames? Power computed from current and voltage, or whatever the driver reports? Charger in or out? If they can't answer all three, I skip the chart.

2. Compare energy per frame

On battery, each configuration ran 50–60 seconds, same scene (hovering on the boat), bottom screen off, brightness untouched. The "5th-pct fps" column is the frame rate at the slowest 5% of moments in the run; it's the number that tells you whether the game feels choppy even when the median looks fine. Ten results:

Configuration W fps (median) 5th-pct fps mJ/frame
Eco + 1080p (stock) 5.85 33.6 29.1 174
Balanced + 1080p 8.54 51.2 35.6 167
Performance + 1080p 9.98 44.1 35.6 226
Eco + 720p 5.53 56.8 33.3 97
Balanced + 720p 6.63 58.8 49.5 113
Performance + 720p 8.39 59.3 53.3 141
Eco + 720p + GPU locked 550 MHz 5.93 61.3 50.3 97
Eco + 720p + GPU locked 475 MHz 5.81 60.0 50.4 97
Eco + 720p + lock 475 + cap 60 5.98 47.7 31.3 125
Eco + 720p + lock 401 + cap 60 5.55 49.8 32.2 111

The last column is the one I'd look at first:

energy per frame (mJ) = system watts ÷ fps × 1000

It's one division, but it puts "battery life" and "smoothness" in the same unit. Looking only at watts, stock at 5.85 W already seems frugal. Divide it out and stock costs 174 mJ per frame, while the final setting costs 97 mJ. The same battery draws close to 80% more frames.

Battery life is a division too:

runtime (hours) ≈ battery energy (Wh) ÷ system watts

The battery driver reports a full capacity of 5938 mAh. I didn't get a nominal voltage, so assuming the usual 3.7–3.9 V for lithium cells that's 22–23 Wh; divided by 5.93 W, about 3.7–3.9 hours. That's arithmetic. I never ran a full battery down.

3. Why Performance is the worst profile

Look at Performance + 1080p: 9.98 W, 44 fps. Fewer frames than Balanced's 51.

The reason is how the profile is implemented. It pins the GPU's minimum clock at the top step, 680 MHz, so the GPU never gets to breathe. It runs straight into the thermal limit and gets pushed back down. At the end of that run the GPU was at 85.2°C and its median clock was only 550 MHz. You pay the top-tier power bill and get a mid-tier clock, plus extra heat.

Near a passive throttling threshold, "max out the clock" roughly means "let the thermal governor pick the clock for you," and the governor usually picks worse than you would.

4. Find the bottleneck, then pick the knob

For Dave the Diver, the biggest knob is resolution. Going from 1080p to 720p cuts pixel count by 2.25x; on Eco the frame rate goes from 33.6 to 56.8 while power actually drops by 0.3 W.

That trick doesn't generalize. The same day, on the same machine, I tuned two other games and got the opposite answer, so I wrote down a way to tell: run the same scene on all three power profiles and watch two things.

The first is GPU utilization. The second is this ratio:

clock elasticity = fps gain ÷ clock gain

Elasticity close to 1 means frame rate tracks that component's clock, so that component is your bottleneck. Low elasticity means you're adding clock to a part that isn't holding you back.

Readings for the three games:

  • Dave the Diver: GPU at 93% at 1080p. GPU-bound. Lowering resolution works.
  • GTA V (legacy edition): 1080p low settings, 26 fps on Eco, 28 on Balanced, 32.6 on Performance, GPU utilization stuck at 51–55% throughout. From Balanced to Performance the big CPU core went 2092 → 2956 MHz, up 41%; frame rate went 28 → 32.6, up 16%. Elasticity 0.40. The GPU is half idle, all eight CPU cores sit around 80%, so the bottleneck is on the CPU side, most likely the x86-to-ARM translation overhead, with Steam and the game launcher's embedded browser eating roughly 2.7 cores in the background. Lowering resolution does nothing here, raising CPU clock buys back only 40% of what you pay, and the big core hits 93°C. In actual play, the open-world streaming couldn't keep up and textures never loaded. I gave up on it.
  • Watch Dogs 2: 15–17 fps at 1080p high, GPU at 99%. GPU-bound, the exact opposite of GTA. Dropping to 720p low gave 29–33 fps, double.

One machine, three games, two kinds of bottleneck. Carrying one game's conclusion over to the next is a coin flip.

As an aside, the Enhanced edition of GTA V won't even start on this GPU, and no tuning can fix it: the game's compute shaders hard-require a wave size of 32 (WaveSize 32), Adreno 740 hardware only supports 64 and 128, pipeline creation fails, and the game then calls a null pointer. Seven crashes in a row, the same error line 11 times in the log. When you hit something like that, the graphics menu won't save you.

There's also a third case. At 720p on Performance, Dave still only reaches 59.3 fps with the GPU at 51%. When neither GPU nor CPU is saturated and frame rate sits flat around 60, that's the game's own cap. That's where the 120 fps goal ends; the game has no frame-rate option either.

5. A clock lock is really a floor

One thing in the table confused me at first. Eco + 720p without a lock already has a median GPU clock of 475 MHz, giving 56.8 fps with a 5th percentile of just 33.3. Manually lock the GPU at 475 MHz, same clock, and you get 60.0 fps with a 5th percentile of 50.4, for only 0.28 W more.

The difference is that the governor clocks down. In auto mode the GPU drops its clock whenever load looks light, then ramps up when the next heavy frame arrives, and the frames before it gets there are the ones you lose. A manual lock also pins the minimum clock; the maximum never changed. The stutter came from the clock floor. The ceiling was fine all along.

Locking at 550 vs 475 MHz both come out at 97 mJ per frame in this scene, basically indistinguishable. I kept 550 because the heavier underwater sections are untested and one step up is some headroom.

The other counterintuitive result is the frame cap. Capping at 60 through the compositor was supposed to shave off wasted frames. Instead fps dropped to 47.7, the 5th percentile dropped to 31.3, and energy per frame rose from 97 to 125 mJ. My guess is the cap's pacing fell out of step with the game's own pacing; I didn't dig further. On this machine, don't use the compositor frame cap.

6. Where these numbers are weak

  • Each configuration ran once, 50–60 seconds each. Power standard deviation ranged from 0.23 to 0.65 W, so I don't take a gap like 5.81 vs 5.93 seriously.
  • Only one scene was measured: hovering on the boat. Underwater and combat scenes, which are heavier, were not.
  • Each of the three games was measured in a different scene (GTA walking on a beach, Watch Dogs 2 driving), so their frame rates can't be compared with each other, only within each game.
  • Runtime is computed, with an assumed voltage. No full discharge test.
  • The "translation bottleneck" for GTA is inferred from a half-idle GPU, busy CPU and 0.40 elasticity. I never ran a control with translation optimizations off (I tried one aggressive FEX profile but uninstalled GTA before testing it properly; on Watch Dogs 2 it slowed loading and didn't raise fps).
  • Screen brightness was held fixed and never treated as a variable. It's probably the biggest power saving left.

7. Next time you tune a handheld, in this order

  1. Unplug. Power and temperature measured while charging don't count.
  2. Compute power yourself from battery current times voltage. Don't trust the driver's power_now.
  3. Read the frames the game submits, not the compositor's stats.
  4. Pick one fixed scene and run it on all three power profiles, noting GPU utilization and clock.
  5. GPU saturated: lower resolution. GPU half idle and fps not keeping up with CPU clock: lowering resolution won't help, accept 30 fps or stream. Neither saturated and fps flat at 60: that's the game's cap, stop.
  6. Sort every configuration by watts ÷ fps and pick the lowest energy per frame whose 5th-percentile fps is acceptable.
  7. If median fps is fine but it drops frames now and then, try a manual clock lock to raise the floor before stepping up a profile.
  8. Don't use the compositor frame cap unless you've measured that it doesn't make that game worse.
  9. Clock locks are usually global. Set them back to auto before switching games.