Bazzite und konsistente FPS

[SonyXP]

Hallo ihr Lieben,

ich habe mir vor ein paar Monaten einen Framework Desktop mit AMD Ryzen AI Max+ 395/64GB zugelegt, den ich als kleinen Desktop-PC mit Möglichkeit zum "Couch-Gaming" benutze. Als Betriebssystem kommt Bazzite in aktuellster Version zum Einsatz, wegen des Gaming-Modes die "Deck"-Variante.

Da ich zuvor jahrelang Windows-User war, sind meine Linux-/Bazzite Kenntnisse noch recht jungfräulich. Das System läuft an sich sehr stabil (in Bezug auf "Crashes" (bisher keine). Was mir aufgefallen ist - in vielen Spielen - die FPS sind doch ab und an sehr sprunghaft. Ebenso sprunghaft dabei sind auch der GPU und CPU-Takt, der hier doch weitaus unruhiger auf und ab regelt, als ich das von Windows gewohnt bin. Via Mangohud kann ich zusehen, wie sich GPU und CPU-Kerne das TDP-Package (in der Regel TDP-Profil "Balanced" = 100W Sustained) teilen. Der Eine braucht ein paar Watt weniger, der andere nimmt sie sich. So geht das, samt Taktraten, sekündlich hin und her.

Ich habe testweise mal die GPU fix auf 2600MHz getaktet (2900MHz ist der werks. Maximaltakt) und siehe da - die GPU-Auslastung war nahezu dauerhaft bei 99-100% (keine Sprünge mehr zwischen 80-90%), die FPS schossen (bspw. in Valheim) um ca. 12-13 FPS konstant hoch und die Frametimes waren viel flacher, ruhiger (Microsttutter im Spiel (bspw. bei Kameraschwenks) so gut wie nicht mehr vorhanden).

Das sagt mir, dass die CPU sich vom Teller ggf. oft zu wenig nimmt. Fühle ich da richtig und habt ihr ähnliche Erfahrungen unter Bazzite/Cachy/SteamOS mit gleicher/ähnlicher Hardware gemacht? Und, welche Auswirkungen darauf können die EPP (Energy Preference Profiles und der Governor haben? Oder die ruhig werkseitig belassen (Governor aktuell: powersave, EPP: balance_performance). Ich bin für jeden Optimierungstipp dankbar!

Lieben Dank fürs Lesen und Austauschen!

Gruß,
Sony

P.S: Natürlich habe ich auch schon mit VRR (an/aus) und Gamingmode-/Desktopmode quergetestet, das bringt aber für mich keine Unterschiede.

 

[Alexander2]

Also beim Steamdeck läuft alles gut, das Teilt sich das Energiebudget ja auch. mir ist da nichts ungewöhnliches aufgefallen.
Und klar schwankt kram -je nach bedarf. Gerade beim steam Deck schaue aber auch nciht die ganze Zeit rum auf die Graphen.

Edit:
Mal dran gedacht steamos zu testen ob das da evtl wegen dem powerbudget kram ja anpassungen hat?

Edit:
Aber tendenziell gibts ja so einige laptops und auch von AMD die so nen Powerbudgetshare haben.

 

[SonyXP]

Ich habe die Graphen auch nur eingeblendet, weil doch so einige Spiele ordentlich "ruckeln", obwohl genug FPS anliegen und wollte dem Ganzen mal auf den Grund gehen. Ansonsten blende ich HUDs aus, weil sie mir schon auf den Keks gehen

:edit: Um Deine Fragen zu beantworten: Ich habe mich bewusst für Bazzite entschieden, weil (laut Netz) hier eine bisher gute Unterstützung für den Framework Desktop angeboten wird. Ujust hat speziell für dieses Modell einige Zusatzsschalter mit an Bord.

 

[bart1983]

Nach meiner Erfahrung hat der eingesetzte Proton Version einen massiven Einfluss auf stuttering/stabile FPS

Ich habe mit CachyOS-Proton-latest stets die beste Erfahrung gemacht, teilweise besser als die vorgegeben Proton-Version von Steam. Auch unter Fedora (worauf Bazzite ja basiert).
Ich würde die ProtonPlus App installieren & dann verschiedene ProtonVersionen probieren.

 

[SonyXP]

Die ProtonPlus App ist schon installiert, das werde ich mal im Auge behalten. Im oben genannten Beispiel betrifft es allerdings auch besonders die Vulkan API (dann ohne Proton).

Spielt ihr mit den werkseitigen Standard-Governor und Schedulern? Über die beiden Themen bin ich bei meiner Recherche nun auch schon öfter gestolpert und welchen Einfluss sie mitunter haben "können".

 

[bart1983]

Ein Windowsspiel das unter Linux läuft, nutzt immer Proton (Proton ist im Grunde "ein Wine optimiert für Games"), egal ob DirectX oder Vulkan als Grafikschnittstelle genutzt wird.
dh auch wenn du Vulkan eingestellt hast, ist die eingesetzte Protonversion wichtig, wenn das Spiel kein natives Linux-Games ist.

Ich nutze Nobara, dort ist der Sheduler schon für Games optimiert. Ist aber bei deinem Bazzite auch schon der Fall.

 

[Tsu]

1. CPU frequency scaling ‘powersave’ kennt nur zwei Zustände, natürlich springt dann der Kerntakt – was durch den aggregierten CPU Takt, d. h. über alle Kerne, stetig aussehen könnte. Versuche mal conservative, das steigert ihn in Schritten bis die Auslastung abfällt.
   
   Alternativ eben gedeckeltes performance oder schedutil. Im stationären Betrieb würde ich auch mit denen anfangen – powersave fiele mir auch nicht zuerst ein.
   
   Die kannst du übrigens noch weiter deinen Vorlieben nach tunen, also wie träge die regeln sollen.
2. Der Scheduler wiederum regelt nur die Zuteilung und Belegung der Kerne mit tasks. An dem scheinst du noch nicht gedreht zu haben, und das ist auch erstmal okay so.
   
   In Fahrzeugen und Konsolen läuft es mit dem so, dass die Hauptanwendung „alle - 1 CPU Thread“ bekommen. HPC, VM Cluster, large-scale Simulationen: Auch hier sehe ich „alle - 2 CPU Kerne [pro Sockel]“; diese Server starten sogar nur mit einem Mindest-Set.
   
   Das erwähne ich aber nur der Vollständigkeit halber.
3. Dann gäbe es noch den I/O Scheduler, den ich aber, um Missverständnisse nicht entstehen zu lassen, ‘elevator’ nenne. Bei einer PCIe SSD kannst du den auf elevator=noop setzen (per udev) um die CPU geringfügig zu entlasten. Das dürfte bei dir keinen messbaren Einfluss gehabt haben.
   
   Auch nur der Vollständigkeit halber ewähnt, nicht dass du da zuviel Zeit reinsteckst.
4. Unabhängig davon gibt es noch die Regelung des Notebook-Maximums über alles (das „Supremum“) sowie das der Grafikkarte, die auf irgendwas zwischen 80–120W gedeckelt sein dürfte. Musst mal schauen, wie das in deinem BIOS geregelt ist und wie du die Profile umschalten kannst. Hier bin ich nicht fit drin.

 

[SonyXP]

Vielen Dank erst einmal für Eure Tipps und Erklärungen.

@bart1983 Das ist gut zu wissen! Mein Gedankengang bzgl. der Vulkan-API basierte in diesem Fall auf Microrucklern in Valheim, welches ich als native Linux-Version spiele.

Zwei Dinge haben hier besonders viel Einfluss auf stabile (und in der Tat auch höhere) FPS, und deutlich niedrigere bzw. glattere Frametimes gehabt:

• Herabsetzen der GPU-Clock von 2900MHz (Automatik/default) auf 2600MHz, was zu einem FPS-Gewinn von 20% geführt hat (von 60 FPS auf 72 FPS (Hohe Settings@WQHD)) und
• Ändern des Schedulers auf SCX_BPFLAND, was nochmal 2-3 FPS und glattere Frametimes ergab
  (Dank an den Input von @Tsu, der mich dazu ermutigt hat, das mal auszuprobieren)

Zuvor konnte die GPU nur bis 80% (im Schnitt) ausgelastet werden. Durch die Änderung liegt sie zwischen 95 und 100%. Ich denke, dass das Herabsetzen der GPU-Clock der CPU selbst nun ein paar Watt mehr vom TDP-Package überlässt (was die GPU jetzt einspart) und sich beides so begünstigt.

Nicht so massiv, aber doch messbar, stelle ich das Verhalten auch in anderen Spielen fest - die dann aber in der Tat über Proton laufen - z.B. Dragons Dogma 2. Hier sind es nur etwa 4-5 FPS Unterschied, weshalb ich mich mal generell dazu austauschen wolte. Das ist mein erstes System mit reiner APU (Strix Halo) und ich musste mir zuvor noch nie Gedanken über ein "TDP-Package", Scheduler und Sonstiges machen. Irgendwie aber auch spannend und interessant. Man lernt viel dabei.

 

[Alexander2]

Sinnvoll könnte sein deine erfahrungen betreffend ruckler und das zurückgehen dieser mit den treiberentwicklern zu teilen. An sich ist das ja etwas das ganz automatisch auch laufen sollte denke ich.

 

[Sensei21]

Bitte einmal scx_cake oder scx_lavd (das ist hit-or-miss, manchmal ist es super, manchmal nicht - von Version zu Version unterschiedlich) testen - hab mit scx_cake soweit die besten Erfahrungen neben scx_bpfland gemacht

falls es den cachy kernel oder einen kernel mit amd-pstate mit EPP boost gibt, diesen ebenfalls nutzen - damit sollte das ganzen nochmals um einiges besser laufen:

epp_boost enabled
=================
With epp_boost enabled (interleaved A/B tests with 6 iterations, usingWelch's t-test to arrive at the deltas), the busy core running the Civ VImain thread runs at a 3.5 GHz median and the benchmark gains 31.8% in1%-low fps (p=0.014) and 4.1% in frame-time p99 (p=0.015), with p999 andaverage fps unchanged.

EPP boost wird über die letzten 4 commits in z.B. https://github.com/CachyOS/linux/commits/7.2/amd-pstate/ implementiert