- Laut Tests von Ars Technica zeigte SteamOS bei vier der fünf getesteten Spiele eine spürbare Verbesserung der Bildrate
- Returnal, Borderlands3, Cyberpunk 2077, Homeworld 3, Doom: The Dark Ages
- Nur Borderlands 3 zeigte unter Windows und SteamOS ein ähnliches Leistungsniveau
- Die standardmäßigen Treiber von SteamOS lieferten insgesamt meist bessere Ergebnisse als die Standard-Treiber unter Windows
- SteamOS zeigte Vorteile bei geringerem Betriebssystem-Overhead und Proton-Optimierungen
- Auch Microsoft reagiert und hat Funktionen zur Optimierung von Windows für Spiele angekündigt
Wichtige Leistungsverbesserungen
- Bei insgesamt 4 von 5 Spielen wurde unter SteamOS eine spürbare Steigerung der Bildrate festgestellt
- Returnal, Borderlands3, Cyberpunk 2077, Homeworld 3, Doom: The Dark Ages
- Nur Borderlands 3 zeigte auf beiden Betriebssystemen nahezu identische Ergebnisse, wobei Windows in diesem Spiel tendenziell leicht höhere Werte erreichte
- In einigen Spielen führte allein der Wechsel des Betriebssystems zu Bildratenverlusten von 8 % bis 36 %
- Bei Homeworld 3 erreichte Windows mit dem von Asus bereitgestellten Grafiktreiber bei niedrigen Grafikeinstellungen eine ähnliche Leistung wie SteamOS
- Bei den anderen vier Spielen lagen die standardmäßigen Windows-Treiber von Lenovo leistungsmäßig deutlich hinter den Treibern von SteamOS zurück
Treiber-Updates und Leistungsänderungen
- Unter Windows zeigte sich insgesamt eine Leistungssteigerung, wenn der Asus-Treiber manuell installiert wurde
- Bei der Grafikeinstellung "Low" in Homeworld 3 war die Leistung der beiden Betriebssysteme nahezu gleichauf
- In den übrigen Tests zeigte selbst Windows mit aktualisierten Treibern im Vergleich zu SteamOS 8–36 % Verlust bei der Bildrate
Optimierungen bei SteamOS und Proton
- Obwohl SteamOS Windows-Spiele über die Proton-Kompatibilitätsschicht ausführt, zeigte es in der Praxis eine bessere Leistung als Windows
- Dies wird darauf zurückgeführt, dass Valve Proton und die Mesa-Grafiktreiber kontinuierlich auf Effizienz optimiert hat
Betriebssystem-Overhead und die Reaktion von Windows
- Unter SteamOS sorgen weniger unnötige Hintergrundaufgaben für einen Leistungsvorteil
- Auch Microsoft hat das Problem erkannt und mit der jüngsten Ankündigung von "Xbox Experience for Handheld" seine Strategie zur Optimierung der Spieleleistung vorgestellt, darunter die Minimierung von Hintergrundaufgaben und das Aufschieben nicht essenzieller Prozesse
- Dadurch besteht die Aussicht, dass künftige Windows-basierte Handheld-Gaming-Geräte höhere Bildraten liefern werden
1 Kommentare
Hacker-News-Kommentare
Jemand teilt die Einschätzung, dass sich die Gaming-Performance nach den persönlichen Erfahrungen der letzten Jahre so einordnen lässt: Platz 1 ist Steam unter Linux mit Proton und Wayland (Niri), Platz 2 die Kombination aus Proton und X11 (Xfce), Platz 3 Steam unter Windows und Platz 4 Spiele, die unter Linux auf andere Weise laufen. Der größte spürbare Unterschied beim Wechsel zu Linux sei die verbesserte Frametimes-Konsistenz gewesen, wodurch kurze Hänger deutlich seltener auftreten und sich Spiele viel stabiler und vorhersehbarer anfühlen. Nach dem Wechsel von X11/Xfce zu Wayland/Niri sei auch insgesamt ein Framerate-Anstieg spürbar gewesen. Beeindruckend sei außerdem, dass der dauerhafte Umstieg nach mehreren Anläufen Anfang 2023 schließlich gelungen sei. Allerdings lasse sich nicht vermeiden, dass Spiele über Proton oder Wine meist länger zum Starten brauchen
Interessant sei, dass es sogar Fälle gab, in denen Spiele mit nativen Linux-Ports besser liefen, wenn stattdessen die Windows-Version über Proton ausgeführt wurde. Als Beispiele werden Civ5, Civ6 und Cities Skylines (1) genannt. Da die Person keine dedizierte Gaming-Hardware nutzt, sondern ein Notebook mit einer Nvidia-3050-Laptop-GPU, falle der Unterschied noch deutlicher auf. Bei Cities Skylines liege Linux bei etwa 20 fps, während unter Windows konstant 45–60 fps erreicht würden. Diablo 4 sei unter Linux zudem so reaktionsträge, dass es praktisch unspielbar sei. Wer starke Gaming-Hardware habe, komme mit Linux gut zurecht, aber auf schwächerer Hardware sei Windows weiterhin im Vorteil
Niri wird als wirklich großartiger Window Manager (WM) gelobt. Nachdem auf HN über einen Phoronix-Artikel die Nachricht aufkam, dass ein Overview-Modus hinzugefügt wurde, sei nun endlich der Wechsel von Sway zu Niri erfolgt. Bei Vollbildspielen oder schwebenden Fenstern gebe es in Niri deutlich weniger Lag und Ruckler als in einer X11-Umgebung, möglicherweise auch dank
xwayland-satellite. Einen passenden Bar mit Unterstützung füri3status-rszu finden, sei schwierig gewesen; letztlich sei man beii3bar-rivergelandetJemand spielt seit vielen Jahren unter Linux und stimmt den Aussagen zur Framerate größtenteils zu. Mit ZFS (single NVMe) seien Ladezeiten möglich, die deutlich unter denen von Windows liegen. Im direkten Vergleich mit dem Ehemann, der auf derselben Hardware Windows nutzt, habe es oft Fälle gegeben, in denen Spiele etwa 10 Sekunden schneller geladen wurden
Es wird gefragt, ob es bei Nvidia-GPUs überhaupt einen praktikablen Weg gibt, Wayland wirklich brauchbar zum Laufen zu bringen. Bei jedem Versuch sei alles langsamer gewesen und das gesamte System habe sich schwerfälliger angefühlt als unter X11
Ergänzend zur Aussage, dass Steam-Spiele unter Linux im Schnitt langsamer starten wegen Proton/Wine, merkt jemand an, dass sich Steam-Spiele unter Linux nach persönlichem Eindruck so verhalten, als würden Shader auf der CPU kompiliert und generell schlechter optimiert sein. Unter Windows scheine es dagegen vorkompilierte Shader zu geben oder die GPU werde dafür genutzt. Trotzdem sei die Erfahrung mit Wayland+Linux deutlich stabiler und mit viel weniger Stottern verbunden als unter Windows. Ob dieser Unterschied wirklich am OS liegt oder daran, dass Windows-Systeme durch allerlei Installationen schnell unnötig schwerfällig werden, sei allerdings unklar. Die Person nutzt beide Betriebssysteme auch für sehr unterschiedliche Zwecke
Es wird argumentiert, dass der letzte fehlende Baustein für vollendetes Linux-Gaming das Anti-Cheat-Thema sei. Große Anbieter würden Support wegen unzureichender Kernel-Sicherheit meiden, und selbst wenn Anti-Cheat vorhanden sei, erlaubten manche Spieleentwickler dessen Einsatz nicht, wie etwa bei Destiny. Wenn AAA-Spiele nur noch problemlos liefen, würde Windows vollständig aufgegeben werden. SteamOS wird als die größte Innovation der Gaming-Geschichte gelobt
Moderne Anti-Cheat-Systeme seien in Wahrheit nur eine Übergangslösung. Verbesserte OS-Sicherheit, die Unhaltbarkeit von Kernel-Level-Anti-Cheat in wenig vertrauenswürdigen Umgebungen und die ständige Katz-und-Maus-Dynamik machten klar, dass der bisherige Ansatz auf Basis von Kernel-Hooks klare Grenzen habe. Als wirksamere Alternative wird vorgeschlagen, künftig alle Prüfungen serverseitig durchzuführen und dem Client nur die nötigen Informationen zu geben. Wenn ein repräsentatives Spiel wie UT auf so eine Architektur setze, könnten veraltete Methoden ganz natürlich verschwinden
Die Meinung wird vertreten, dass Multiplayer-Spiele ohne dedizierte Server letztlich an Grenzen stoßen. Ein Anti-Cheat-Daemon, der in den Kernel eindringt und Dateien oder Speicher überwacht, sei unerwünscht. Communities mit dedizierten Servern könnten Spieler nach Erfahrung deutlich besser verwalten als zentralisierte Matchmaking-Systeme
Insbesondere Epic schiebe die Verweigerung von Linux-Support auf die Komplexität, tatsächlich spiele aber wohl auch hinein, dass Steam faktisch der Standard-Store ist und man das ungern akzeptiere
Es wird daran erinnert, dass Easy Anti Cheat und Battle Eye Linux bereits seit einigen Jahren nativ unterstützen; ob dies tatsächlich aktiviert wird, liege aber bei den Spieleentwicklern. Rund 40 % der Spiele mit Anti-Cheat würden unter Linux laufen, nachprüfbar auf areweanticheatyet.com
In poetischer Wehmut wird auf Technologien wie Valve Anti-Cheat (VAC) verwiesen, die einst mit Counter-Strike zur Popularität von Steam beitrugen. Es wird gefragt, warum VAC nicht mit der Zeit weiterentwickelt wurde. Wünschenswert wäre, in einer Linux-Ära wieder stärker in VAC zu investieren und es als Gegengewicht zu Easy Anti Cheat auszubauen
Wenn Windows-Spiele über Proton auf SteamOS schneller laufen, dann sollten Entwickler laut einer Meinung eher SteamOS-APIs als Windows priorisieren. So könne man Kompatibilität zu Windows wahren und zugleich maximale Performance erreichen. Vorgeschlagen wird, dass große Game-Engines wie Unity und Unreal SteamOS als Hauptziel in CI und Tests stärker berücksichtigen sollten. Außerdem wird spekuliert, ob Valve eine SteamOS-CI/CD-Farm betreibt, und die Hoffnung geäußert, dass sich plattformübergreifende Builds und Tests auch mit Rust-basierten Templates und Bibliotheken umsetzen ließen
Dagegen wird eingewandt, dass die Windows-API die maßgebliche Grundlage (True Source) für das Verhalten von Spielen sei. Wenn etwas unter Windows funktioniert, aber nicht unter Proton, behebt Valve das Problem auf der Proton-Seite. Wenn etwas dagegen nur unter Proton funktioniert, aber nicht unter Windows, bestehe das Risiko, dass das Spiel letztlich kaputtgeht. Unter Proton sollte man daher Funktionen vermeiden, die schlecht zu Windows passen, und bei Tests auch Umgebungen wie das Steam Deck berücksichtigen; grundsätzlich sei eine Windows-zentrierte Entwicklung aber weiter sinnvoll
Es wird darauf hingewiesen, dass die einzige stabile ABI in der SteamOS-Umgebung Win32 sei; nur für SteamOS zu entwickeln könne daher langfristig Kompatibilitätsprobleme verursachen
Da Epic die Unreal Engine besitzt, wird bezweifelt, dass das Unternehmen eine Optimierung für SteamOS und dessen APIs gern sehen würde. Erwähnt wird dabei auch die Wettbewerbssituation zwischen Epic Store und Steam
Der realistische Hinweis lautet, dass sich der Großteil des Marktes (99 %) weiterhin an Windows orientiert. Proton sei letztlich ebenfalls eine Implementierung von Win32, also im Kern ebenfalls auf Windows ausgerichtet
Jemand berichtet von einer merkwürdigen Erfahrung aus der Windows-XP-Zeit: Windows lief als VMWare-VM auf Linux und war auf derselben Hardware trotzdem schneller als eine reine Windows-Installation
Kürzlich sei ein Wechsel zu Arch erfolgt, nicht SteamOS-basiert, und die Erfahrung sei ziemlich robust gewesen. Allerdings funktioniere nicht alles sofort out of the box, und pro Spiel seien kleinere Anpassungen nötig. Meist gehe es nur darum, den Startbefehlen Parameter hinzuzufügen, also nichts besonders Schwieriges. Die nötigen Tipps finde man fast immer in Proton DB und in Community-Kommentaren. Die Zufriedenheit sei so groß, dass eine Rückkehr zu Windows kaum noch infrage komme
Vor etwa 10 bis 15 Jahren habe jemand dasselbe Spiel abwechselnd unter Windows und Linux (Wine) genutzt und dabei 100 bis 200 Savegames gespeichert. Überraschenderweise sei das Laden der Savegame-Liste unter Linux (Wine) doppelt so schnell gewesen wie unter Windows. Es wird Verwunderung darüber geäußert, dass so etwas passieren konnte, obwohl NTFS nicht einmal ein natives Linux-Dateisystem ist
Wenn SteamOS und Ganoo/L00nockz, vermutlich eine scherzhafte Schreibweise für GNU/Linux, sich endgültig als Gaming-Plattform etablieren, wolle jemand zum ersten Mal seit 2012 wieder einen Gaming-PC zusammenbauen. Als Mac-Nutzer sei man mit der Unix-Basis für Entwicklung zufrieden, aber beim Gaming liege macOS noch hinter Linux zurück. Sobald AAA-Releases und stabile GPU-Treiber vollständig da seien, werde in den nächsten fünf Jahren ein großer Wandel erwartet
AAA-Spiele liefen in Wahrheit schon seit Jahren gut, und mit dem Steam-Client sowie AMD-GPUs sei Linux bereits jetzt eine hervorragende Gaming-Plattform
Seit dem Erscheinen des Steam Deck liefen faktisch fast alle Spiele gut unter Linux. Ausnahmen seien vor allem Spiele, die absichtlich kaputt gemacht wurden, etwa durch Anti-Cheat-Integrationen. Auf protondb.com lasse sich die Kompatibilität prüfen; unter den 300 meistgespielten Steam-Titeln funktionierten tatsächlich nur 17 nicht, davon seien 5 lediglich Utilities
Wenn Windows einmal Unix-basiert würde, könnte man beim Entwickeln und Spielen die Vorteile beider Welten nutzen; das sei schon lange ein Wunsch. Das Gefühl sei, dass die Realität diesem Zustand inzwischen deutlich näher gekommen ist
Mit einigen Links zu Diskussionen darüber, dass auch der Windows-Kernel im Vergleich zu anderen OS langsamer sei, wird die Lage ironisch kommentiert: Blogbeitrag zugehörige HN-Diskussion
Es wird argumentiert, dass es nicht ganz treffend sei, Proton als „translation layer“ zu bezeichnen. Die Win32-API bestehe nicht aus Systemcalls auf Kernel-Ebene, sondern aus in DLLs registrierten Funktionssätzen, und Proton auf Linux liefere DLLs, die diese Win32-API über Linux-Systemcalls implementieren, während Windows dafür seine eigenen DLLs mit eigenen Systemcalls nutze
Dagegen wird eingewandt, dass selbst die offizielle Wine-Website von einer „Kompatibilitätsschicht“ spricht, die Aufrufe zur Laufzeit übersetzt; daher sei die Bezeichnung translation layer nicht wirklich falsch
Der hartnäckigen Entwicklungsgeschichte von Wine, einschließlich Proton, wird Respekt gezollt. Früher sei es noch verspottet worden, weil es angeblich als Lösung nur neue Probleme schaffe, heute werde es als mächtiges Werkzeug zur Ablösung von Windows gesehen
In scherzhaftem Ton wird gefragt, ob selbst Funktionen wie
sscanf()aus Kompatibilitätsgründen unnötig komplex implementiert wurdenEs wird darauf hingewiesen, dass Proton/Wine sogar verschiedene NT-Systemcalls direkt implementiert, obwohl in der Praxis auch viele Windows-Programme solche Systemcalls unmittelbar nutzen
Zur Einordnung wird erklärt, dass das eigentliche Wesen von Wine die Übersetzung der Windows-ABI in Linux-OS und Userland sei. Gerade diese Übersetzung sei der Kern der Portabilität
Jemand habe mit einem Leistungsunterschied von 20 bis 30 % gerechnet, tatsächlich seien es aber eher 200 bis 300 % gewesen, was schockierend sei. Gewünscht wird, dass Microsoft ein von unnötigen Funktionen befreites „Windows für Gaming“ veröffentlicht; die Person selbst nutze Windows inzwischen ohnehin nur noch zum Starten von Steam