Best option when aiming for battery life?

Hello! I’m currently using an Apple M2 air which has been absolutely incredible in terms of battery life and overall performance - undoubtedly one of the best laptops I have ever used because I can always depend on its battery life.

I however absolutely love the ethos of the frame.work and was wondering if any of the intel/amd options offer decent/comparable battery life/performance?

My previous mac was an 16” intel i9 and I could barely use it for more than 2 hours without the battery dying and the miserable fans on full blast at all times. (Vs a fanless and easily achieved 12-16 hours on the m2)

I was hoping someone could suggest a particular frame.work option (I actually preordered the 13” ultra 125h) - I would be doing mostly we development and would be using Linux.

(I also understand it’s not possible to match/surpass the m2 battery life I’m just wondering which frame.work config might offer the best available)

1 Like

Decent probably, comparable unlikely.

If you don’t do video playback the amd has quite good battery life on linux, however there is something not quite right with the hw decoder/how it’s used in linux that causes it to use excessive amounts of power for doing the simplest stuff. On windows it’s apparently fine.

I am curious how the new intel platform shakes out, in theory, it is basically built for low power video playback but how well that’ll work on linux, especially initially, remains to be seen.

1 Like

@Adrian_Joachim can you please try this series?

[PATCH 1/2] drm/amdgpu/vcn: identify unified queue in sw init (kernel.org)

i’m running windows but i feel like some of this stuff still applies Ryzen 5 7640u 2x8gb 1tb SSD: I get 7-9 hours.

To improve battery life i’ve:

turn off bluetooth unless needed

dim the power LED to lowest setting in bios

set screen behavior to start hibernate as opposed to sleep when closed

set screen to turn off after two minutes

have the usb-a &hdmi expansion cards in the slots closest to you

run windows in best power efficency & keep battery saver on at all times.

This looks like it might be a step in a very right direction but I may be too smooth-brained to apply it.

I have used patch files for kernels before but I have not managed to either turn this mbox thing into a patch for 6.9.8 or apply it with git am to either linux or linux-stable.

Edit:
I am going to take new baseline numbers, maybe someone can tell me how to turn this into a working patch later so I can compare. I would really love to test it.

Here’s a branch:

https://git.kernel.org/pub/scm/linux/kernel/git/superm1/linux.git/log/?h=superm1/vcn-dpg-6.9

1 Like

That did help but I still think I did it wrong since I get the exact same results, does this need enabling or something?

I basically followed these instructions. I ended up generating my own patch files by comparing the amdgpu_vcn files with the ones the pkgbuild pulls which got me a compiling and booting kernel (at least uname says so).

One of two things is happening:

  1. You applied the patch series wrong. If you’re not sure it’s applying them properly add a third patch with a debug message.
  2. You’re using scaling or some method that doesn’t do direct output. There’s a few people that have shown success with this series so far. For example: [Guide] FW13 Ryzen Power Management - #69 by TheStachelfisch

Having done it wrong is my current theory XD

Shouldn’t better power gating have an impact even without direct scanout?

I have seen that which only increases my theory that I did it wrong

Yes it should still improve things if it’s using VCN for decode. The part I worry about is that mpv has some “auto options” that try to use GFX instead of VCN and you have to signal your intent pretty hard. Use nvtop in another tab to confirm that VCN IP is active (warning; ENC and DEC are the same queue on Framework 13 / PHX).

mpv isn’t even part of my testing, the video playback testing I do is kodi, ffmpeg and firefox.

I gave it another shot and instead of messing around with patchingI just pulled your whole repo and built that which seems to have worked better.

Seems to be the case, the ffmpeg tests without display had the largest power reduction.

Shaves off about 1W for 720p 30 youtube playback in firefox (both fill-screen and windowed and across codecs), for 4k 60 youtube playback the difference is a lot smaller (~0.3W), I did notice av1 uses about 2W more than vp9 in that test which threw me for a loop for a bit (the test video I was using seems to default to av1 for 4k60 which didn’t seem to be the case the last time)

720p30 kodi playback allmost matches my t480s now and finally beat the sw decoded numbers with a reduction of a bit under 1.5W. 4k playback got a bit less of a reduction at around 0.8W.

The biggest reduction were in the ffmpeg no display tests where the patch shaves off slightly over 2W for bot 480p24 and 1080p30 which pretty much match the sw decode numbers.

It’s still not quite where I’d like it to be but it’s a big step in the right direction and the bigger share of the excess power may be on the presentation side now.

I’ll try playing with the mpv rendering thing and see if that produces further gains.

2 Likes

Glad to hear it’s working for you.

1 Like

Happy to report similar improvements in my testing: ~1W reduction with mpv and ~2-3W in Firefox (1080p h264). I’m hoping a bit more will be shaved off when the new 2.8k screens ship and fractional scaling can be disabled.

@Adrian_Joachim mpv --hwdec=auto-safe --vo=dmabuf-wayland should help.

1 Like

Just make sure you are comparing the same video, my test video suddenly having a 4k av1 version threw me for a loop for a bit today. Apparently 4k60 av1 draws like 2W more than the vp9 version.

All my numbers are without fractional scaling.

Found something quite similar. The mpv numbers aren’t as different to my kodi numbers as they used to, maybe kodi implemented the dmabuf thing too at one point.

I just hope they keep going and don’t just call it done now, my t480s (with a processor that came out 7 years ago) still uses less power to play back the same videos with pretty similar baseline power draw.

Yeah, I used Big Buck Bunny locally.

I didn’t conduct an exhaustive test by any means, but happy to see some improvement.

Agreed :slight_smile:

Why didn’t I think of this, doing local video playback in firefox would reduce the variability of whatever youtube is doing in the background massively. Then again it also makes the scenario more artificial.

What was the delta between mpv and firefox in your case?

Local video playback also removes the variability of WLAN conditions.

I did quite a bit of testing on that early on and found it to make very little difference (at least with the ax210, didn’t do much testing with the mediatek as I needed that for something else), the laptop does have line of sight to the ap though so that may make it’s life a lot easier there.