In this write-up here:
It states to use PPD for AMD. While the write-up goes into details for TLP (for Intel users), it didn’t really go into enabling or configuring PPD.
Is it automatically enabled by default for Fedora and Ubuntu? Do we need to mess with anything? I believe this is a systemd service.
Curious about this too, as I plan on running Solus on FW16. I wonder if extra steps will be needed.
The key point in the KB article is that it assumes you are using Fedora. PPD is installed and configured to work by default on Fedora Workstation. For other distributions, there may be more work. Framework support Fedora 39 and Ubuntu 22.04 for the FW13 models, I kind of expect they will support the same on FW16.
Thanks. The document didn’t say it PPD was enabled by default. And if there’s nothing else to configure, I it sounds like both Fedora and Ubuntu PPD just works right out of the gate with AMD 7040 series, and is as battery optimized as it gets.
For now that seems true. For the F13 laptops there has been a large discussion on this. I expect once the F16 drops into more hands the same discussion could happen again.
Here’s the thread I’ve been following:
Except we have the addition of the dGPU to account for as well.
The dGPU goes into D3cold (BOCO) through the kernel runtime PM framework when it’s not in use for 5 seconds.
The only thing you really need to watch out for is any sensor monitoring software that might inadvertently keep it awake. For example nvtop and mission center both cause this problem.
Do you know of any sensor monitoring software which avoids this problem?
I don’t know. It’s entirely possible to detect from sysfs that the GPU is off (power/runtime_status) but I guess most software doesn’t check it.
Interesting.
So I can run:
cat /sys/class/drm/card1/device/power/runtime_status
and get suspended
then
cat /sys/class/drm/card2/device/power/runtime_status
and get active.
This gels as I look at:
cat /sys/class/drm/card2/device/uevent
and
cat /sys/class/drm/card1/device/uevent
Comparing the PCI slot name against the output of lspci VGA output.
This tells me the dGPU is suspended, as I would expect as it’s not being utilized or needing to wake.
Now to the question of an application that does this. I did not have one, so I tossed together a quick and dirty script that “appears” to be working correctly.
1- I ran my script. Idles at empty. Upon launching Steam (flatpak), Fedora 39.
2- Script immediately indicated the card is “awake.”
3- With steam idle, it stopped at two 5 second entries.
4- With it still paused, I launched a game in steam I have set with the command parameters set with DRI_PRIME=1 %command% and sure enough, the card woke up again and the script shows activity.
5- Stopping the game, the script stops its 5 second refresh indicating the card is no longer active.
Still testing this more, but, based on some rough testing, I suspect this should do what the op wants. They could in theory, apply this wherever (at startup, as a service, etc).
Thoughts @Mario_Limonciello ? Seems like it does what op is looking for. You can see where it stops its activity as you described after steam is idle and after I close the game.
#!/bin/bash
# Path for card1
STATUS_FILE="/sys/class/drm/card1/device/power/runtime_status"
# Initial status check
PREV_STATUS=$(cat "$STATUS_FILE")
# Alert if already active
if [ "$PREV_STATUS" = "active" ]; then
echo "ALERT: card1 is already active at script start - $(date)"
fi
while true; do
# Current status check
CURRENT_STATUS=$(cat "$STATUS_FILE")
# Alert if status is active, regardless of previous state
if [ "$CURRENT_STATUS" = "active" ]; then
echo "ALERT: card1 is active - $(date)"
fi
# Update previous status
PREV_STATUS="$CURRENT_STATUS"
# Check interval
sleep 5
done
We want you on current releases for PPD. Please follow our guides for the PPA or COPR for Ubuntu LTS and Fedora.
Thoughts @Mario_Limonciello ?
Sounds like what I expect. If the dGPU isn’t in use for 5 seconds it goes back into runtime PM.
I did not have one, so I tossed together a quick and dirty script that “appears” to be working correctly.
If you want something cleaner take a look at pyudev. I personally think you can more easily get all the attribute you want (they’re attributes of the device).
Ah, yes, this is great. Will take a gander.
Edit: Yes, this is the way! I am liking this. Adding to my list. Good idea!
I just want to mention here that the ability for the dGPU to reliably transition from hot to cold when it’s not needed directly impacts my purchasing decisions of whether or not I’ll get a gpu module in the future (my Batch 1 did not have one). I’ve had issues in the past with other laptops and this is the main reason I didn’t buy the dGPU.
Understood. So as Mario explained, by default, the dGPU D3cold (BOCO) through the kernel runtime. This means, when not in use, it will be a state of deep sleep.
This happens out of the box on our officially supported Linux distros.
Now, there are applications that are an exception to the rule. Using NVTOP for example, will by nature, “wake” the dGPU and the script above will reflect this. We would call this expected behavior as we are looking at our GPUs here.
TLTR: The dGPU is in deep power saving state until called up. The script I provided merely is used to verify this.
From what I’ve seen so far on various forum threads, it sounds like the functionality works pretty well on the FW 16 
I’m just afraid of that changing at some point, as I’ve been burned (and am currently being burned) by driver updates. cough nvidia cough. I understand that’s mostly out of Framework’s hands.
Totally get it. So we have full time Linux staff, plus we have AMD (active here as a matter of fact) working hard to ensure compatibility with our engineers. Linux support is VERY important to me, to Framework and AMD has been amazing to work with.
Are regressions impossible? Of course not. Welcome to Linux. But we work with our amazing hardware and software partners to resolve those issues.
Do Fedora variants enjoy the same support as offered under the blessed blanket of “Fedora”? For instance will Kinoite also be supported like Kubuntu might be on the Ubuntu side of things?
Amazing question - longer term goal, yes. Short term, we have a team of two - so laser focused on Fedora Workstation (GNOME).
Not really sure if this is the right place to leave this comment; or if it’s just really excessively keen but I was following the knowledgebase article (Optimizing Fedora Battery Life) and discovered this section of the docs is now pointing to a bit of the readme that’s just been removed (Update Fedora39-amd-fw13.md · FrameworkComputer/linux-docs@2d89575 · GitHub).
I wasn’t really sure where or how I should propose updating the knowledge base/removing the link and this is the closest thread I could see to it.
Is it the case that now nothing needs to be done for PPD on AMD?