Stromsparen unter Linux mit Intel P-State

Stromsparen unter Linux ist ja meist eine Wissenschaft für sich. Viele Stromsparmechanismen und Tipps, sowie Tricks werden immer wieder gegeben, andere passen sich mit den Generationen der Geräte auch an. In diesem Fall will ich über eine relativ neue Stromspartechnik namens Intel P-State berichten, dass bei meinem neuen HP Spectre X360 und dem Kernel 4.20.7 standardmäßig zum Einsatz kommt.



Das Notebook ist für Entwickler und Technikaffine ein wichtiger begleiter. Auch Youtuber, Podcaster und Blogger nutzen das Notebook für ihre tägliche mobile Arbeit.
Die Freiheit immer und überall ohne Kabel leistungstarke Hardware für den Videoschnitt zu haben, oder mal schnell einen neuen Text zu schreiben mit einer ordentlichter Tastatur sind wichtige Kriterien dafür.
Aber natürlich muss auch die Akkulaufzeit stimmen. In der Vergangenheit hat sich Linux damit immer etwas schwer getan, da nicht immer alle neuen Stromsparmechanismen dort immer sofort verfügbar waren und weil die Hersteller meist auch mist in ihre Firmware/BIOS/EFI schrieben, die dazu führten dass ihre Stromspartechniken kaputt waren und nicht dem Standard entsprachen. Gefixt haben die Hersteller dies dann nur per Windows Treiber. Leider ist das heutzutage zum Großteil immer noch so.
Linux ist also hier darauf angewiesen diese Quirks zu erkennen und nachzuimplementieren.

Mittlerweile hat auch Intel erkannt, dass es für ihre neuen Ultrastromsparprozessoren Sinn macht evtl. die Steuerung raus aus der reinen Software rein in eine bessere Kooperation von Hardware und Software zu packen.
Aus diesem Grund gibt es auch den Intel P-State Skalierungstreiber für Linux. Dieser bietet im Gegensatz zum alten ACPI Skalierer, nur noch 2 Skalierungsstrategien, Performance & Powersave.

KSysguard zeigt den Takt der Prozessoren mit Performance Skalierungsmethode


Standardmäßig wird zumindest bei mir auf dem Neptune System (Neptune 6 Beta basierend auf Debian Buster) der Performance Skalierer verwendet. Der hat den Vorteil, dass er sehr viel Leistung aus dem Notebook herausholen kann, was man ja auch beim Videoschnitt benötigt.
Der Nachteil ist, dass er zumindest hier aber nicht ordentlich runtertaktet, sondern immer einen hohen Takt an der oberen Grenze. auch wenn nicht viel am Notebook gemacht wird. hält.

Der Trick ist es nun also den Powersave Modus zu benutzen, der auf vernünftigere Werte gesetzt wird und auch deutlich nach unten taktet, wenn nicht viel am Notebook gemacht wird.
Dies kann man mit modernen Tools wie cpupower auch manuell relativ schnell und einfach einstellen.
Dazu reicht der Befehl

sudo cpupower frequency-set -g powersave

Natürlich will man so etwas nicht immer manuell einstellen und hätte gerne diesen stromsparenden Modus standardmäßig im Akkubetrieb aktiv.
Steckt man dann das Stromkabel an, möchte man dann natürlich auch die volle Leistung des Rechners nutzen können und dann wäre es super, wenn der Rechner den Skalierungsmodus in performance ändert.

Gott sei dank sind wir hier bei Linux und so kann man das alles einfach und schnell mittels einiger Konfigurationsdateien auch schnell so einstellen.

Ich habe mich hier von diesem Arch Linux Foren Thread inspiren lassen, der dies für den acpi Skalierer durchführt.

Dazu habe ich mir zuerst dieses power.sh Scrtipt gebastelt, dass mittels upower überprüft ob der Akku gerade aufgeladen wird oder nicht. Je nachdem setzt er dann den entsprechenden Governor (die entsprechende Skalierungsmethode):

#!/usr/bin/bash
STATE=""
BAT="BAT0"
if [[ "$1" == "BAT" || "$1" == "AC" ]]; then
  STATE="$1"
fi
if [[ $STATE == "" ]]; then
  if [[ $(upower -i /org/freedesktop/UPower/devices/battery_$BAT | grep state | grep discharging) == "" ]]; then
    STATE="AC"
  else STATE="BAT"
  fi
fi
echo $STATE
if [[ $STATE == "BAT" ]]; then
  echo "Discharging, set governor to powersave"
  cpupower frequency-set -g powersave
elif [[ $STATE == "AC"  ]]; then
  echo "AC plugged in, set governor to performance"
  cpupower frequency-set -g performance
fi

Angepasst werden muss hier evtl. nur der Name von BAT, der bei meinem Akku BAT0 heißt.
Mittels dieses power.sh scriptes, dass zusätzlich noch mit dem Parametern AC und BAT manuell in einen Skalierungsmodus gezwungen werden kann, habe ich nun Udev und Systemd Service Dateien erstellt, dir mir beim Hochfahren oder dem Abstecken bzw. Anstecken des Stromkabels den entsprechenden Skalierungsmodus setzen.

Das Udev Script, was ich unter /etc/udev/rules.d/powersave.rules angelegt habe, sieht dann so aus:

SUBSYSTEM=="power_supply", ATTR{online}=="1", RUN+="/home/leszek/Downloads/power.sh AC"
SUBSYSTEM=="power_supply", ATTR{online}=="0", RUN+="/home/leszek/Downloads/power.sh BAT"

Der Pfad zum power.sh Script muss man natürlich ggf. anpassen.

Nun sorgt dieses Service File beim Hochfahren des Rechners dazu, dass der richtige Skalierungsmodus verwendet wird:

[Unit]
Description=Sets the CPU governor on boot according to AC mode
Requires=multi-user.target
After=multi-user.target
[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/home/leszek/Downloads/power.sh
[Install]
WantedBy=multi-user.target
Die Servicedatei habe ich unter /etc/systemd/system/power_management.service angelegt.

Nun kann es aber noch dazu kommen, dass ich das Gerät ja auch manchmal in den Standby bringe und kurz davor den Stromkabel angeschlossen habe, ich dann aber Stunden später den Kabel abstecke und dann das Gerät erst aufwecke. Damit dann die richtige Skalierungsmethode für die CPU Taktung gewählt wird braucht es einen weiteren Systemd Dienst. Dieser root-resume.service getaufte Dienst wird wiederum unter /etc/systemd/system/ angelegt.
[Unit]
Description=Local system resume actions
After=suspend.target
[Service]
Type=simple
ExecStart=/home/leszek/Downloads/power.sh
[Install]
WantedBy=suspend.target
Mit diesen Anpassungen läuft das Notebook nun doppelt so lange und somit genauso wie ich es erhofft habe und ich kann bis etwa 10 Stunden Akkulaufzeit herausholen.

Videos unter Linux schneller rendern mit GPU Beschleunigung

Videoschnitt ist ja eines meiner Hobbies, gerade als Podcaster, kommt man ja nicht immer drum herum. Nun betreibe ich ja nur ziemlich einfachen Videoschnitt via Kdenlive unter Linux und meist sind es auch nur im Falle des Techview VLogs nur Konvertierungen mit Ein- und Ausblendeffekten.

Im Falle der Techview Podcast Show wird das ganze etwas aufwendiger mit Überganagseffekten und eben etwas mehr B-Roll Schnitt der hineingemischt wird, oder auch Titel Einblendungen usw.
Etwas gestört hat mich dort bisher immer der etwas lange Atem den man haben musste, nachdem ein Video fertig geschnitten war, dieses auch herausrendern zu können. Hier ist es manchmal etwas lässtig, wenn man für ein 15 Minuten Video 30 Minuten braucht um es zu rendern.

Kdenlive


Diese Zeiten sind bedingt durch die standardmäßig in vielen Videoschnittprogrammen unter Linux verwendeten Renderprofile, die nur CPU Rendering beinhalten.
Nun gibt es aber mit VAAPI eine Schnittstelle und einen Enkodierer, sowie Dekodierer für ffmpeg, der so etwas auch auf die durchaus besser dafür geeignete GPU auslagern kann, bzw. diese mitbenutzen kann für das Rendern.

Das erfreuliche, dank sehr guter Arbeiten der Grafiktreiberentwickler für Linux ist diese Schnittstelle quasi zum Standard geworden und alle gängigen aktuellen Karten von AMD, Intel und sogar Nvidia (mittels Nouveau) unterstützen es.
Da auch aktuelle Distributionen in ihre ffmpeg Versionen die Unterstützung dafür hineinkompilieren, steht also dem Rendern eines Videoclips mittels dieser Technik nicht viel im Wege.

Auf meinen Neptune und Netrunner Systemen, basierend auf Debian Stable bzw. Testing, ist es dank der ebenfalls aktivierten vaapi Enkodierfähigkeit in der Bibliothek Melt auch in meinem Lieblingsvideoschnittprogramm Kdenlive möglich auf diese Fähigkeit zu setzen.

Renderprofile von Kdenlive


Leider liefert Kdenlive momentan noch (es ändert sich in der Zukunft, so hoffe ich) kein Standardprofil dafür aus. Deshalb habe ich etwas Hand angelegt und möchte euch hier zeigen, wie man sich sein eigenes Renderprofil unter Kdenlive erstellen kann, dass auf den VAAPI Codec für die H.264 Videokodierung setzt.
Dazu muss man einfach ein neues Renderprofil erzeugen. Ich habe eines auf Basis des vorhandenen MP4 Profils erstellt, da meine GPU nur in der Lage ist H264 ordentlich zu dekodieren und zu enkodieren. Infos darüber was eure GPU kann verrät der Befehl

vainfo

den man in ein Terminal eingeben kann. (Vorrausgesetzt das gleichnamige Paket ist installiert)

Mein "LLs Podcast Option" Profil mit VAAPI


Nun habe ich folgende Werte für mein neues LLs Podcast Option Profil eingetragen (siehe auch Foto oben):

vaapi_device=/dev/dri/renderD128 vf='format=nv12,hwupload' properties=x264-medium f=mp4 vcodec=h264_vaapi threads=4 real_time=-1 preset=faster acodec=aac g=120 crf=%quality ab=%audiobitrate+'k'

Mit diesen Einstellungen erziele ich einen deutlichen Performancegewinn, wenn es um das Rendern von Videos geht. Hier mal ein Vergleich zu einem Techview VLog den ich geschnitten habe einmal die Renderzeit mit dem MP4 Profil von Kdenlive:

Renderzeit mit Standard MP4 Profil von Kdenlive

 Und hier zum Vergleich das gleiche Renderprojekt mit meinem Profil und VAAPI Enkodierung:

Renderzeit mit VAAPI Enkodierer Profil

Wie man sehen kann ist der Unterschied schon gewaltig. Ich kann bei dem Video was etwas über 24 Minuten geht meine Renderzeit halbieren und komme so auf einen Renderwert der unter Echtzeit liegt, also mit etwa 20 Minuten kürzer ist als das Video selbst.

Das ganze jetzt auf einem noch nicht mehr so taufrischen Thinkpad E555 mit AMD A8-7100 und einer R5 Radeon Grafikeinheit in dieser APU.
Neben der schnelleren Renderzeit werden auch die CPU Kernel nicht die ganze Zeit sehr hoch belastet, so dass auch die Hitzeentwicklung nicht mehr so deutlich ansteigt bei diesem Notebook. Zumal auch bei einer kürzeren Renderzeit die Prozessoren evtl. auch gar nicht so weit wegen Hitze heruntertakten müssen.

Natürlich schneide ich nun meine Videos nicht nur auf diesem Laptop, sondern auch einem potenteren AMD Sechskern Desktop System (AMD FX-6100) das mit einer Nvidia Geforce 650 TI ausgestattet ist. Nun könnte ich hier auch auf VAAPI setzen. Aber auf diesem System ist tatsächlich der proprietäre Nvidia Treiber installiert, da ich darauf auch ab und zu Spiele spiele, die der Nouveau Treiber nicht schafft.

Der Nvidia Treiber bietet eine weitere clevere GPU Optimierung fürs Dekodieren, aber auch Enkodieren von Videos. NVENC nennt sich das ganze und ist ebenfalls in aktuellen Distros in ffmpeg und melt enthalten.
Wer also den proprietären Nvidia Treiber sein eigen nennt kann anstatt VAAPI auch NVENC zum enkodieren von Videos benutzen.

NVEnc Renderprofil


Mein Profil auf diesem Desktop Rechner sieht dann so aus:

properties=x264-medium f=mp4 vcodec=nvenc_h264 acodec=aac g=120 crf=%quality ab=%audiobitrate+'k' preset=fast

Mit diesem Profil erreiche ich auch gute Werte für das Videorendering.

Jedem sollte aber klar sein, je nachdem was man für Videos schneidet sind die Einsparoptionen  mittels der Nutzung von VAAPI oder NVEnc beim Rendern von Videos nicht immer so hoch wie in meinem Beispiel. Lohnen tut es sich aber allemal, gerade auch wenn man wie ich einen etwas älteren Rechner einsetzt und über eine potente Grafikeinheit verfügt.