News Proton 8.0: Valve bringt großes Update für Spieler, die Linux nutzen

[flaphoschi]

Das wage ich zu bezweifeln, klar es gibt eine duennere Uebersetzerschicht, aber in der Realitaet schau dir den grottig schlechten Port von Ark: Survival Evolved an…

Pfuschen kann leider jeder. Deswegen steht da auch “ordentliche” und nicht “hingepfuschte”.

Verhunzte Konsolenports sind unter Windows auch keine Seltenheit

 

[schM0ggi]

Über Umwege, ja. Aber warum Umwege gehen? SteamOS und seine Updatepolitik ist so konstruiert, das man sein System eigentlich nicht verbasteln kann. Weil es bei jedem Systemupdate nahezu komplett ausgetauscht wird, bis auf Kontodaten, flatpaks und ein paar Ordner mit installierten Spielen. Das ist für eine Konsole super, aber für alle die ihren PC wie einen normalen Desktop nutzen wollen nicht. Das meine ich mit SteamOS macht nichts besser. Deshalb macht es auch keinen Sinn darauf zu warten, das es mal SteamOS für alle PCs gibt um ein Problem zu lösen, was nicht existiert.
Vor allem sollte man das nicht als Grund voran schieben, mit dem Ausprobieren zu warten.

Wieso Umwege? Im Terminal passwd eingeben ist doch kein Umweg!? Ansonsten lässt sich die Steam Deck schon als daily nutzen, wenn man Anwendungen rein als Flatpak nutzt. Man muss letztendlich wissen, worauf man sich einlässt. Bei der CT gab es dazu mal einen coolen Bericht bzgl. Langzeitnutzung:

https://www.heise.de/news/c-t-3003-Steam-Deck-als-Arbeits-PC-Langzeit-Test-7078288.html
Das Video dazu ist echt unterhaltsam.

Ja, für die Hardware des Steamdecks. Solche Anpassungen machen aber auf Desktops keinen Sinn, weil die andere Hardwarekonstellationen haben. Da machen genau die genannten Gaming-Distributionen einen besseren Job, weil die sich nicht auf statische Hardware konzentrieren.

Ich dachte bei den Anpassungen auch an "allgemeine" patches wie z.B. die Zen patches. Kann mir gut vorstellen, dass Valve in der Richtung auch Optimierungen hat. Aber ja, grundsätzlich gibt es das auch bei Distros mit Gaming Fokus. Aber auch auf "normalen" Distros ist Gaming kein Problem und performant. Nutze ja Fedora und da läuft alles rund.

 

[ghecko]

Wieso Umwege? Im Terminal passwd eingeben ist doch kein Umweg!? Ansonsten lässt sich die Steam Deck schon als daily nutzen, wenn man Anwendungen rein als Flatpak nutzt. Man muss letztendlich wissen, worauf man sich einlässt. Bei der CT gab es dazu mal einen coolen Bericht bzgl. Langzeitnutzung:

Hab ich probiert, es hat an allen Ecken und Enden mit meinem Workflow und meiner Programmumgebung gehakt. Und auszugehen von der allgemeinen Frustrationstoleranz von Umsteigern ist genau das nicht zielführend.

Ich dachte bei den Anpassungen auch an "allgemeine" patches wie z.B. die Zen patches. Kann mir gut vorstellen, dass Valve in der Richtung auch Optimierungen hat.

Sie haben Anpassungen spezifisch für die Hardware des Steamdecks. Die können auf einem Desktop Vorteile bringen, müssen aber nicht. Und viele sind je nach Hardware auch kontraproduktiv.

SteamOS auf dem Desktop ist irgendwie etwas nachdem jeder schreit, aber keiner braucht.

 

[flaphoschi]

Es gibt auch backports. Da ist aktuell 6.1 drin. Weis ja nicht welche hoch-exotische Hardware du fährst, aber kann mir kaum vorstellen, dass ein Gamer da irgendwelche Probleme mit haben sollte. Mich würde die uralte Software eher nerven die sonst so mit kommt.
Rolling Release hab ich nur miese Erfahrungen mit gemacht, ganz übel OpenSuse Tumbleweed. Nie wieder. Dann lieber was stabileres wie Fedora, sehr aktuelle Pakete und recht hohe Stabilität. Die Community ist da auch super (irc als auch foren). Und mit XFCE/Cinnamon/Mate taugliche Oberflächen.

Japp.

Nur will man das als Neuling mit einem AMD Zen4 Mobile mit RDNA3 bei Erstkontakt mit Debian lieber nicht lernen. Und selbst 6.1 ist für Anwender mit Arch veraltet. Dafür hält einem Debian größere Änderungen auf Jahre hinweg von Hals.

 

[blackiwid]

Freesync macht das ebenfalls, nur steuert es zusätzlich...

Dann macht es doch kein Sinn VSync an zu machen wenn man Freesync an hat oder?

 

[ghecko]

Eigentlich nicht.

 

[blackiwid]

Pfuschen kann leider jeder. Deswegen steht da auch “ordentliche” und nicht “hingepfuschte”.

Der Nutzen ist einfach so gering aber der Aufwand steht in keinem Verhältnis, von daher in ner Perfekten Welt ohne andere Softwareprobleme, momentan gehts darum ob man genug Gamer zu Linux bringen kann, wenn sich da die % zahlen erhöhen kann man irgendwann auch über Native Ports vielleicht reden.
Oder in anderen Worten ich glaub nicht das das der groesster Flaschenhals ist, Wahrscheinlich ist der Unterschied Nativ Windows -> Linux groesser wie Linux nativ -> Linux Proton, daher würde ich lieber erstmal die Treiber in allen lagen gleich schnell wie in Windows bekommen.

Die Uebersetzerschicht hat btw auch vorteile, so kann ein Studio keine Linuxspezifische nativen Schadcode einfuehren, dadurch das die Uebersetzerschicht das quasi anbieten muss, kriegt man bisschen mehr Transparenz rein, fast wie unter Android mit der "Sandbox".

 

[Nine-tailed Fox]

Dann macht es doch kein Sinn VSync an zu machen wenn man Freesync an hat oder?

Gehört V-Sync nicht zu freesync dazu?
Dachte immer man müsste V-Sync aktivieren um freesync zu nutzen.
V-Sync begrenzt die Bildrate auf die Hz des Monitors und freesync sorgt dafür das es nicht stockt wenn die Bildrate unterhalb der möglichen Hz fällt.
So hatte ich das zumindest verstanden.

 

[ghecko]

V-Sync begrenzt auf die Bildrate auf auf die Hz des Monitors

Nein, Vsync sperrt nur den Framebuffer, wenn der Monitor das Bild gerade neu aufbaut. Anwendungen können nach wie vor Bildraten komplett unabhängig von der Bildwiederholrate des Monitors haben.
Vsync verhindert nur Tearing, erhöht aber Latenz und Geruckel, wenn die Bildwiederholrate zum Bildmaterial ungünstig abweicht.
Deshalb wurde Freesync und Gsync ins Leben gerufen, die passen die Bildwiederholrate des Monitors variabel auf die der Anwendung an. Dabei wird die Funktion die Vsync hat ebenfalls übernommen.

 

[Nine-tailed Fox]

Ok, Danke. @ghecko
Aber brauch ich das jetzt um freesync zu nutzen oder läuft freesync auch ohne v-sync?

 

[blackiwid]

Gehört V-Sync nicht zu freesync dazu?
Dachte immer man müsste V-Sync aktivieren um freesync zu nutzen.
V-Sync begrenzt auf die Bildrate auf auf die Hz des Monitors und freesync sorgt dafür das es nicht stockt wenn die Bildrate unterhalb der möglichen Hz fällt.
So hatte ich das zumindest verstanden.

Nein gehoert es nicht, Freesync passt die HZ den fps an soweit ich das verstehe, in einem bestimmten bereich, also liefert der PC dir 40fps zeigt er dir vielleicht 2 bilder mit 80 hz 2x an und wenn dann auf 80fps hoch kommst nimmt er nur noch 1 bild.

Vsync wurde ja die Hz Zahl auf irgend einen Wert fix stellen und die max fps eben auf diesen Wert auch stellen, eigentlich Fix den Wert aber wenn die Hardware den nicht packt, dann faellt es runter und es gibt screen tearing. Freesync verhindert aber Screen tearing, in dem es dann einfach die Hz zahl reduziert oder die FPS verdoppelt, so versteh ich das.

 

[ghecko]

Aber brauch ich das jetzt um freesync zu nutzen oder läuft freesync auch ohne v-sync?

Freesync ersetzt Vsync vollständig, anders herum nicht.

 

[schM0ggi]

Freesync/VRR hat nach der Installation der KDE Version von Nobara gar nicht funktioniert, scheinbar gibt es da auch keine Einstellung dazu weil es von Haus aus aktiv sein sollte bei KDE.
Bei Gnome gibt es das VRR Setting in den Einstellungen, da war dann aber glaube ich das Problem das mit aktivem vsync vrr nicht funktionierte und ohne vsync kam ich mangels framebegrenzer oft aus der freesync range und wurde mit tearing belohnt

Bei KDE gibt es in den display settings die Option "Adaptive Sync". Das ist VRR.

Dann macht es doch kein Sinn VSync an zu machen wenn man Freesync an hat oder?

VSync macht auch bei VRR Sinn und sollte in Kombination mit VRR genutzt werden.
VRR passt die HZ des Displays auf die aktuelle FPS an. Dadurch gibt es kein Tearing.
Überschreiten aber die FPS die max HZ des Displays, hast du ohne VSync Tearing.
Daher sollte man VSync aktiviert lassen, damit es in so einem Fall greift, und auch nur dann.
Der Input Lag ist bei diesen hohen FPS vernachlässigbar.

Bei Wayland war es bislang nicht nötig und eine Besonderheit, da Wayland bereits von sich aus VSync erzwingt, weil dort die Philosophie "perfekte frames" herrscht. Aber mittlerweile, zumindest auf der Steam Deck, gibt es die Möglichkiet "Allow Tearing" zu aktivieren, sprich man hat das bekannte Tearing Verhalten ohne VSync und weniger Input Lag.

Freesync ersetzt Vsync vollständig, anders herum nicht.

Nein, das ist nicht richtig. Siehe oben. Beide ergänzen sich.

 

[ghecko]

Überschreiten die FPS die max HZ des Displays, hast du ohne VSync Tearing.

Ach so, dann mach das Sinn. Hätte nicht gedacht das Freesync außerhalb des Arbeitsbereiches die Arbeit komplett einstellt.

 

[blackiwid]

VRR passt die HZ des Displays auf die aktuelle FPS an. Dadurch gibt es kein Tearing.
Überschreiten die FPS die max HZ des Displays, hast du ohne VSync Tearing.

Ahh also als Frame limiter, also bei 144hz dann vsync auf 144 stellen?
Gibts maximale FPS nicht auch als extra setting in manchen games?

So langsam finde ich Gaming auch komplizierter als Linux einrichten

 

[Nine-tailed Fox]

@schM0ggi
Danke für die Aufklärung!

 

[schM0ggi]

Ach so, dann mach das Sinn. Hätte nicht gedacht das Freesync außerhalb des Arbeitsbereiches die Arbeit komplett einstellt.

Überhalb ja, unterhalb des VRR Bereichs können dann Technologien wie LFC zum Einsatz kommen, wo dann gegebenenfalls der Frame mehrfach dargestellt wird.

Ahh also als Frame limiter, also bei 144hz dann vsync auf 144 stellen?
Gibts maximale FPS nicht auch als extra setting in manchen games?

So langsam finde ich Gaming auch komplizierter als Linux einrichten

Ja genau, man kann sich das dann praktisch als Limiter vorstellen.
Alternativ lässt sich das auch mit in game fps limiter usw. regeln, wenn vorhanden. Und vor allem, wenn die gescheit funktionieren. Bei Windows schwört man da auf RTSS und 2-3 unter der max HZ des Displays.

Ich persönlich setze die max fps in game immer auf ~90, abhängig was geht. 144 brauche ich in game dann nicht wirklich und schafft meine RX 5700 eh nicht. Aber auf dem Desktop ist 144 natürlich butterweich.

 

[Tanzmusikus]

Gibt es auch alternativen für Programme wie reshade unter Linux?

Ja, einige Tools wurden für natives Linux-Gaming bereits genannt.

Alternativ kann man auch das originale ReShade in das Wine-Prefix des jeweiligen Windows-Spiels kopieren.
Es verhält sich dann genauso wie unter Windows. Mit Trainern & Tools für Windows das gleiche.

Einzige Grenze wäre die Kompatibilität von WINE/Proton zu nennen, da nicht alles 1:1 aus Windows implementiert wurde. Man kann vieles installieren, aber manche bestimmte tief verwurzelte Funktionen kann man nicht ersetzen.

Immer dran denken, 32bit geht nicht. Warum auch immer das so gewollt ist.

Was meinst Du damit (generelle Linux-Distro-Unterstützung von CPUs oder speziell Pakete/Tools/Spiele)?

Die meisten Linux-Distros setzen mittlerweile einen 64-bit Prozessor voraus.
Gibt aber auch noch diverse Distros mit nativer 32-bit Unterstützung (z.B. Bodi-Linux).
Arch z.B. bieten auch Multi-Libs (64-bit & 32-bit Bibliotheken/Pakete) an.

32-bit Spiele oder auch 32-bit'ige Spiele-Launcher kann man mit bestimmten Einstellungen in den Spiele-Tools wie HGL, Lutris, Steam usw. zum Laufen bringen. dgVoodoo2 ist in Lutris als Glide-Wrapper für ältere Spiele wie z.B. Doom verfügbar.

Gibt also viele Möglichkeiten.
Am Anfang kennt man natürlich selten diese Vielfältigkeit, geschweige denn kann man sie mangels Wissen sofort und fehlerfrei anwenden. Dies ist jedenfalls meine Erfahrung. Mir macht's meist Freude das mit Geduld heraus zu finden.

Ich nutze u.a. für Spiele seit einigen Monaten erfolgreich Pop!_OS (Ubuntu-Basis) und EndeavourOS (Arch-Basis).

 

[Fred_VIE]

Wurde nicht von Steam direkt Manjaro empfohlen?

Ob es empfohlen wurde weiß ich nicht, ich hatte jedoch bisher weder unter Manjaro noch unter Kubuntu Probleme mit Spielen vom Steam Client.

Unter Manj kann ich auch Spiele ohne Steam direkt über proton-ge-custom-bin starten.

 

[schM0ggi]

32-bit Spiele oder auch 32-bit'ige Spiele-Launcher kann man mit bestimmten Einstellungen in den Spiele-Tools wie HGL, Lutris, Steam usw. zum Laufen bringen. dgVoodoo2 ist in Lutris als Glide-Wrapper für ältere Spiele wie z.B. Doom verfügbar.

Btw... Wrapper wie nglide oder dgvoodoo lassen sich auch normal, wie unter Windows, einbinden. Man muss dann lediglich die WINEDLLOVERRIDES korrekt setzen. Cool finde ich auch, dass mit Wine legacy Komponenten unterstützt werden und somit 16-Bit Installer (bei alten Spielen) problemlos funktionieren. Das ist bei Windows 10 z.B. nicht der Fall, da dort schlicht die Komponenten fehlen und man auf community made alternative Launcher zurückgreifen muss. Hab schon ältere Spiele gehabt, die unter Linux mit Wine im Vergleich zu Windows 10 wesentlich einfacher laufen.