Bericht Linux-Gaming: Mit welcher Distribution laufen Windows-Games am besten?

Krümel-Hamster schrieb:
Die verwendete Lexar NM790 verwendet anscheinend einen Controller, der erst ab Linux Kernel 6.5.7 unterstützt wird.
Danke für die Info, ich habe mir für meine Linux Versuche auch eine NM790 angeschafft. Seit Samstag aber
keine Zeit gehabt.

Räumt schon mal den ersten Stolperstein aus dem Weg.
 
cruscz schrieb:
Vielen Dank für den Test, wobei durchaus auch ein Vergleich zu verbreiteten Distributionen wie Mint, Fedora, vielleicht auch noch OpenSuSE und altbackenem Debian interessant wären.

Insgesamt sieht es aber bei den getesteten OS schon ziemlich solide aus, auch wenn die Unterschiede gering ausfallen ist lustigerweise Linux oft schneller.
Sobald das Windows 11 ordentlich zugemüllt ist, geht es da vermutlich noch einmal ordentlich nach oben für die Linuxe.

Vielen Dank für die Arbeit!
Nobara ist ja eine Fedora Distribution und mit PopOs hat man Mint als Ubuntu Distribution abgedeckt, Debian würde mich aber schon interessieren, da SteamOS vorher auf Debian basiert hat bevor es zu Arch gewechselt ist.
 
doko1975 schrieb:
Nobara ist ja eine Fedora Distribution und mit PopOs hat man Mint als Ubuntu Distribution abgedeckt
Aber zumindest Nobara ist eine spezielle Gaming-Distribution, bei PopOS mag die Einschätzung richtig sein, Mint ist aber noch einmal eine Spur verbreiteter.
Ging mir bei der Aussage (wären alle Distributionen auf einer spezifischen Basis identisch, gäbe es eben keine paar Hundert verschiedenen Distributionen), auch eher darum den Vergleich zu „Brot und Butter“-Installationen zu machen. So wäre es ( um den Vergleich zur Windows Welt zu machen), als hätte man in Windows Vista Zeiten mit der Ultimate getestet, diese war im Vergleich zu Pro und Home nun einmal nur im einstelligen Prozentbereich der Installationen.
 
Kurzer Rückblick, da Neuigkeiten:
Grimba schrieb:
Mein Razer Blade 15 friert manchmal einfach ein, beim Spielen oder sogar einfach in X
Grimba schrieb:
Der Rechner reagiert aber auf keine Eingaben mehr
Grimba schrieb:
Zuerst dachte ich, es ist vielleicht der Openrazer Treiber.
Also ich habe jetzt vieles ausprobiert, F/E-Sync an/aus, Gamemode an/aus, diverse Ingame Einstellungen (in WoW, weil das am meisten abschmierte) verändert, verschiedene Wine Versionen, alles keine Wirkung. Die Freezes kamen in anderen Spielen inzwischen ähnlich verlässlich irgendwann.

Aber, in der Tat, die Deinstallation von Openrazer und damit des Kernel-Moduls brachte Besserung. Bisher seit Stunden absolut stabil. Mir kam von Anfang an her merkwürdig vor, dass diese Freezes das Notebook gleich komplett aus dem Tritt brachten, unrettbar. Zu sowas ist eigentlich nur etwas auf Kernelebene fähig. Andererseits ließen sich zwar die Symptome und diverse Lösungsansätze googlen, jedoch nichts in Verbindung mit dem Openrazer Moduls.

Dass ich einen Freeze vor der Installation hatte, muss wohl in meiner Erinnerung falsch gewesen sein. Es würde auf jeden Fall vom Verdacht her passen, denn sowohl Arch als auch OpenSUSE verhielten sich hier nach der Installation ziemlich ähnlich.

Vielleicht ist das ein neues Problem mit einem neueren 6er Kernel. Kann mich nicht erinnern, das Problem in der Vergangenheit gehabt zu haben. Das Modul baut jedenfalls problemlos auch mit den aktuellen Kernelversionen, auch mit 6.7. Was das aus dem Tritt bringt, keine Ahnung.

Jedenfalls wollte ich nur kurz Rükmeldung geben und kann an dieser Stelle jedem Razer-Besitzer nur von OpenRazer abraten, zumindest meine Reihe (late 2020) ist betroffen. Ich überlege ein issue auf Github dort zu erstellen, oder vielleicht gibt's ja schon eins, dann hätte ich das bis jetzt übersehen.
Ergänzung ()

Lol...ey... und weißte, kaum taske ich in das Spiel zurück, nachdem ich den Beitrag geschrieben habe, laufe ein paar Schritte... Freeze.... :(

Die Kiste trollt mich gerade hart, Stunden nix, zack. Offenbar war es das doch nicht. Glaubstes, sowas Blödes.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: rarp, knoxxi, Espero und eine weitere Person
Besten Dank. War mir aber bekannt, und der darin geschilderte Freeze ist hier nicht das Problem. Aber nichts desto trotz, die Deinstallation von OpenRazer hat die Häufigkeit der Freezes definitiv positiv beeinträchtigt. Ich bin nur gerade ratlos, an welcher Stelle hier vielleicht ein Log was aufgeschnappt hat. Ist ja nicht so, als würde eine Kernelpanic geschmissen. Das Ding steht einfach, der letzte Sound läuft in einer 3-5 Sekundenschleife und die Maus bewegt sich noch oder zumindest noch eine Weile. Gnarf.
 
Wird dir nicht helfen, aber ich hab openrazer schon lange installiert und keinerlei Probleme damit. Ich hatte in den letzten Tagen mit Guild Wars 2 Probleme, ähnliche Symptome auch, aber das lag an einer neuen Versionsnummer von pixman (dient der 2D Darstellung). Downgrade da und alles war gut.
 
Zuletzt bearbeitet:
Interessant. Hast du das was nachlesbares für mich? Bin ja für jeden Strohhalm dankbar :)
 
Das klingt ja wirklich sehr ähnlich. Wobei das jetzt nicht ein Launcher Problem ist. Allerdings hat der Blizzard Launcher z.B. Renderprobleme, und auch um Lutris herum ist irgendwie ein dicker schwarzer rand. Vielleicht liegt ja wirklich damit was im Argen. Das schlussendliche Symptom ist ja nun wirklich sehr sehr ähnlich. Besten Dank!

edit: Hm, dagegen spräche allerdings, dass bei Tumbleweed, wo ich das Problem ja auch, und sogar etwas massiver und ohne Auslöser hatte, nach wie vor pixman 0.42-2 zum Einsatz kommt. Also sollte es damit zusammenhängen, hängt es nicht alleine an der Versionsnummer. Dann wurde da ggf. beim Packetieren anders gearbeitet. Aber ich werde es auf Arch dennoch mal probieren. Wird nur schwierig zu verifizieren, wenn die sich jetzt Stunden am Stück benimmt, die blöde Kiste.
 
Zuletzt bearbeitet:
Bei Guild Wars 2 wird pixman für die Fensterdarstellung beim Launcher genutzt. Weil das kein normales Fenster ist, sondern ein Shape. Unförmig und mit transparenten Stellen drin. Weiß nicht, wie das bei dir ist.
 
Der ist sogar Linux Native, der Launcher, ne?
Ja, dann ist es vielleicht doch nicht vergleichbar.
 
Hm, der NVIDIA 545 scheint ja allenthalben auch als Buggy angesehen zu werden. Vielleicht gehe ich hier auch vorerst auf 535 zurück probeweise.
Ergänzung ()

Oha, mit 535 beinahe sofort den Freeze nach wenigen Schritten ingame, aber rettbar. Raustaskbar und beendbar. Das wird ja immer lustiger.
 
Zuletzt bearbeitet:
So, pixman downgrade gemacht. 535 und 545 verhalten sich bis jetzt stabil. Aber die Testphase ist natürlich kurz. Allerdings, dafür dass der 535 so fix im krepieren war... nunja, man darf gespannt sein.

Hm, also ich bin geneigt, den Schwarzen Peter ebenfalls pixman zuzuschieben. Einfach wegen der Gleichheit der Symptome. Der Auslöser kann ja ein anderer gewesen sein. Bleibt nur noch fraglich, warum dann vor Wochen das Tumbleweed,was ich drauf hatte, bereits unter X11 einfach so weggestorben ist, da war doch pixman 43 noch gar nicht raus? Oder war OpenSUSE hier schneller und ist später zurückgeschwenkt? Oder doch ganz was anderes? Tja... vermutlich, wenn ich gleich zurücktaske, haut's die Mühle wieder aus den Latschen und ich stehe wieder am Anfang :D
 
Zuletzt bearbeitet:
Wäre ja nice. Allerdings finde ich hier schon eine Unterscheidung zu dem vorliegenden Fall bei mir: Bei dem Bug geht's ja auch oder vorallem um die lib32 Variante, verstehe ich das richtig? Diese habe ich z.B. überhaupt nicht installiert.

edit: Nope. Das war's nicht. Beim letzten Ladebildschirm war Schluss, wieder nach langem problemlosen Betrieb. Gleiches Problem, wieder scheinbar kein Auslöser. Wieder am Anfang. :(

edit2: Ich habe mittlerweile auch mal testweise den ZEN-Kernel laufen lassen. Auch hier keine Besserung. Mir gehen so langsam die Ideen aus. Eigentlich schade, die ganze Sache. Das System läuft sonst nämlich wie geschmiert. Hardwarefehler scheidet aus, da es das Problem unter Windows nicht gibt. Das Ganze wurmt mich wirklich sehr.
 
Zuletzt bearbeitet:
Also in Ermangelung eines Anhaltspunkts oder eines aussagekräftigen Logfiles, habe ich weiter fleißig die Duckduckgo Ente durchs Netz gescheucht, und bin auf ein paar interessante Sachen gestoßen.

https://discuss.kde.org/t/kde-plasma-completely-freezes-in-fullscreen-except-cursor/368/9
https://discuss.kde.org/t/kde-still-freezing/7662/11

Das Problem scheint also unter anderem auch KDE Plasma zu sein, den ich hier auch verwende. Ich hatte allerdings in letzter Zeit viele DEs ausprobiert, auch Gnome und Cosmic, daher war ich sicher, das Problem dort eigentlich auch gehabt zu haben. Aber offenbar gibt es gemeldete Probleme bei KDE. Die Gemeinsamkeit bei diesem Problem scheint also immer KDE in Verbindung mit NVIDIA Optimus und dem Rendering Offload Betrieb zu sein.

Vorgeschlagene Lösungen reichen von ältere 5er Kernel zu verwenden, als auch zu Nouveau zu wechseln, oder krude Varianten, wie hier https://github.com/doitsujin/dxvk/issues/2365#issuecomment-1147539160 ,
welche jedoch im Falle der intel PageFlip = false Variante ordentlich Leistung kosten.

Nun, zu Gnome zu wechseln steht mir natürlich auch noch offen. Auch habe ich zwischendurch einmal Wayland probiert, allerdings gab es da Fehldarstellungen, also bin ich erstmal wieder zurück zu X11. Nach diesem Problem suchend fand ich dann allerdings bei https://wiki.archlinux.org/title/NVIDIA/Troubleshooting
das hier:
If fullscreen applications are freezing or crashing, try enabling Display Compositing and Direct fullscreen rendering options in your desktop environment's settings.
In der Tat ist in Arch bei KDE per Default der Compositor, also KWin, so eingestellt, dass er erlaubt, dass Spiele ihn ausschalten aus Performancegründen. Das sorgt dann auch für die schwarzen Ränder um GTK Fenster, wenn das passiert, denn da hat sich etwas beim Darstellen der Fensterdekorationen geändert, so dass ohne Compositor die Rahmengrößen nicht mehr stimmen. Ich hatte also gleich bemerkt, dass das bei Spielen fast immer passierte.

Jetzt bin ich schon eine ganze Weile im Spiel mit weiterhin aktiven Compositor. Macht letztendlich auch im Spiel die Navigation zu anderen Apps viel bequemer, es gibt keine Darstellungsprobleme mehr und eine Auswirkung auf die Performance bemerke ich bisher auch nicht. Vielleicht ist ja der kurze Satz aus dem Archwiki wirklich der Knackpunkt gewesen. Andererseits habe ich mich hier schon häufiger zu früh gefreut...

Bisher scheint es zumindest so, als wäre das Problem erstmal nicht mehr da. Ich werde mich natürlich melden. Was mich jetzt noch vielleicht interessiert, ist, was passiert, wenn ich das so auch unter Wayland betreibe, ob dann auch die Fehldarstellungen weg sind, weil der Compositor weiterhin aktiv ist.

Egal, jedenfalls, immerhin, ein weiterer Strohhalm!
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Tevur
Was du Compositor nennst, ist unter X11 eigentlich der Window Manager, also KWin in diesem Fall. Bei Wayland ist der Compositor der Server, der auch die Aufgaben des Window Manager übernimmt. KWin ist dann der Wayland Compositor. Ohne den Compositor geht bei Wayland nichts. Insofern erübrigt sich die Frage. Wayland wird erst von KDE Plasma 6 stabil unterstützt.
 
Das nenne nicht ich so, die Benennung wird sowohl im Wiki als auch in den KDE Einstellungen verwendet :)
Aber ergibt Sinn. Ich habe schon gesehen, dass sich die Einstellungsmöglichkeiten in beiden Varianten unterscheiden. Dann wird es da auch diese Einstellung nicht geben. Ich bin mit Wayland noch nicht so gut zu Fuß, ich hab noch auf XFree86 laufen gelernt. Das war schon Hexerei für mich, als ich plötzlich keine config mehr schreiben musste. Und das ist ja auch schon etliche Jahre her. Da Wayland ja so ewig in der Entwicklung war, habe ich mich damit nicht sonderlich beschäftigt.

Nichts desto trotz: Dieses Häkchen in den Einstellungen scheint bisher das Zünglein an der Waage gewesen zu sein. Bisher nicht ein Freeze.

spätes Edit (quassle hier eh schon zuviel):
Also ich hab jetzt gestern 5Std. SWtoR, 1Std. WoW und heute gerade nach Feierabend eine komplette Partie Civ6 ohne Freeze spielen können. Das war vorher zu 100% nicht möglich. Also ich wage es mal mich festzulegen und sage, dass der Satz aus dem Archwiki die Lösung brachte. Es ist etwas schade, dass er nicht wirklich prominent sichtbar ist, denn es ist ja kein eigener Troubleshoot-Punkt sondern er steht da mehr nebenbei in einem anderen Unterkapitel am Schluss. So wird er leicht übersehen oder gar nicht erst gefunden.

Man kann also schlussendlich sagen: Wer KDE Plasma nutzt in Verbindung mit den aktuellen Kerneln (6.x) und Nvidia Treibern (535/545) und X11 (nicht Wayland), und zudem den Hybrid Modus mit Render Offloading nutzt, der lasse tunlichst Compositing eingeschaltet :) Das löst eh noch andere Probleme, ist eigentlich ein no-brainer.
 
Zuletzt bearbeitet:
Zurück
Oben