Test Diablo IV unter Linux im Test: Benchmarks auf dem Arch-Gaming-PC und Valves Steam Deck

[Brrr]

Das geht ja eben nicht. Viele der Dinge, die da aufgeführt sind, kann man bei Wayland nicht fixen, weil es dem Konzept entgegensteht. Du kannst da z.B. nicht so einfach auf beliebige Fenster mit anderen Programmen zugreifen. Das ist bei Wayland bewusst nicht vorgesehen. Einfache Anwendungen könnte man natürlich ersetzen, das stimmt. Aber es hätte jetzt für mich überhaupt keine Vorteile.

Ich benutze selber auch noch X11 weil es für mich einfach noch besser funktioniert. Aber ich glaube solche Dinge könnten in den Compositor integriert werden.

 

[Tanzmusikus]

Gibt es eine Möglichkeit es dauerhaft so einzustellen, dass Linux die Prioritäten so wie Windows behandelt?

Vermutlich mit FIFO-Scheduler (First-In-First-Out) ...
https://www.man7.org/linux/man-pages/man7/sched.7.html

... oder mit NOOP-Scheduler:
https://www.thomas-krenn.com/de/wiki/Linux_I/O_Scheduler

 

[MaverickM]

Mir fehlt hier leider der direkte Vergleich von ROG Ally zum SteamDeck, also das Ally mit 720p und 15W, soweit ich sehe gibt es nur zwei 720p Benches und die sind beide mit 30W, wobei 15W viel interessanter wären, wenn man auch mal was vom Akku haben möchte^^

War das nicht so, dass das ROG Ally bei 15W dem Stamdeck unterlegen war?

 

[Brrr]

Linux ist für das Gaming mit vollem Umfang leider noch immer keine Option. (HDR, VRR usw.)

VRR funktioniert. HDR leider immernoch nicht wirklich, aber da werden endlich Schritte gemacht.

 

[Taxxor]

@MaverickM siehe hier

 

[Brrr]

@FX-Multimedia
Klar ist es eine "Option".


HDR gibt's per Gamescope, Free-G-Sync ist verfügbar und auch VRR läuft.

Gamescope ist eine erste Option, aber wirklich brauchbar ist das für mich z.B. noch nicht. Da ich da keinen Desktop zur Verfügung habe. Also HDR gibts, ja... aber ist noch ziemlich viel Arbeit, da muss noch mehr passieren bis das die breite Masse nutzen kann.

 

[MaverickM]

@MaverickM siehe hier

Ahh, schön, dass sich da mit Updates was getan hat.

 

[Nine-tailed Fox]

Vielen Dank für den Test und die Benchmarks ❤️

 

[Brrr]

Vermutlich mit FIFO-Scheduler (First-In-First-Out) ...
https://www.man7.org/linux/man-pages/man7/sched.7.html

... oder mit NOOP-Scheduler:
https://www.thomas-krenn.com/de/wiki/Linux_I/O_Scheduler

Gibt auch noch ionice (Für I/O) und nice (CPU).

 

[Northstar2710]

@SavageSkull dieses tool vereinfacht die launcher Installation ein wenig. https://www.gamingonlinux.com/2023/...ic-games-and-more-on-steam-deck-the-easy-way/

Aber im Endeffekt wie immer install Datei runterladen und mit Proton unter Steam installieren. Dann den launcher mit Proton starten und dann das Spiel über den launcher installieren/starten.

 

[Bierliebhaber]

Das Ally holt also aus 30W gegenüber 15W, also der doppelten Leistung, gerade mal 27% mehr fps bei einer geringeren Auflösung raus? Das ist schon sehr schwach. Bei nativer Auflösung ist es fast gleich schnell.

Man zahlt also wesentlich mehr, muss dazu auf die Ergonomie, die Touchpads und die Software des Deck verzichten UND hat im Endeffekt nicht wirklich mehr Leistung. Habe mit wenig gerechnet, aber mit SO wenig dann doch nicht.

 

[Caramon2]

@Caramon2 Vielleicht hilft dir der Link, etwas Klarheit zu bekommen: https://www.embedded-software-engin...von-linux-a-4e1e0d9b15040b02ad3dd95d7699678f/

Das scheint der richtige Ansatzpunkt zu sein. Danke!

... oder mit NOOP-Scheduler:
https://www.thomas-krenn.com/de/wiki/Linux_I/O_Scheduler

I/O hat wenig mit der CPU-Auslastung zu tun.

Außer vielleicht dass z. B. bfq eine über 10x höheren Overhead als mq-deadline hat:

mq-deadline is ~800 LOC, against ~10500 LOC for BFQ

https://www.kernel.org/doc/html/latest/block/bfq-iosched.html
(hatte ich mir zufällig heute morgen herausgesucht, da ich mich momentan mit den Zen-Kernel beschäftige und der bfq standardmäßig nutzt)

 

[Taxxor]

Das Ally holt also aus 30W gegenüber 15W, also der doppelten Leistung, gerade mal 27% mehr fps bei einer geringeren Auflösung raus?

52% ohne bzw 55% mit FSR.
Finde ich schon eine recht gute skalierung, dafür dass es auch eine höhere Grundlast zu stemmen hat, einerseits durch die doppelte Kernzahl, andererseits durch Windows.

 

[Kaito Kariheddo]

So läuft Diablo VI unter Linux

Korrigiert, danke

oh, noch mit X11? hast du noch ein Problem mit Wayland?

Hab ich tatsächlich, im Multi-Monitor-Setup wird die Maus beim spielen nicht im Fenster gehalten. Daher bastel ich mir mit labwc einen eigenen Wayland-Desktop, der ist mir aber noch nicht stabil genug.

 

[Redundanz]

schade, dass die linux 1% fps regelmäßigen drops geschuldet sind und nicht etwa einem initialen shader/state caching seitens dxvk. wobei letzteres mit dxvk version 2.x sowieso scheinbar vollständig weggefallen ist...also das initiale ruckeln beim cacheaufbauen...

 

[cele]

Höhö das Titelbild^^
Danke für die Linux und Steamdeckerei, nice.

Diablo selbst find ich megaöde (seit Teil 1), stumpf mit der Maus rumklicken, gähn, fast wie ein interaktiver Bildschirmschoner kam mir das in den 90ern vor. Wo man doch Doom und C&C spielen konnte auf Lanparty, weshalb sowas langweiliges?! Konnte ich nie nachvollziehen Aber cool dass es vielen Leuten gefällt und das Spiel als fertig entwickelt bezeichnet werden kann, so wie es auf den Markt kam.

 

[Kuristina]

wobei letzteres mit dxvk version 2.x sowieso scheinbar vollständig weggefallen ist...also das initiale ruckeln beim cacheaufbauen

Das ist mir auch sofort aufgefallen. Wobei ich noch einen extra Flag setze RADV_PERFTEST=gpl* und damit gibts überhaupt kein Stottern mehr am Anfang, wo sonst die Shader erst erstellt wurden. Butterweich. Kann natürlich sein, dass das auch schon integriert ist.

(*nur AMD)

 

[Kaito Kariheddo]

Also im Test mit gamemode hab ich genau 1 FPS mehr in AVG und 1%. Im Test mit Wayland zu X11 ebenfalls 1 FPS mehr. Und zusammengenommen komme ich auf AVG 110,4 und 1%-Lows bei 50,1. Das "stottern" ist weiterhin vorhanden und Performance-Vorteile ergeben sich nicht wirklich.

 

[Kaito Kariheddo]

Die Fixierung des Prozesses auf einen CCD hat ebenso wie die Task-Priorisierung nichts geändert am stottern. Eine deutliche Verbesserung der Frametimes und 1%-Lows konnte ich dennoch herbeiführen -> FPS-Limit. Durch ein Limit auf 90 stiegen die 1% Lows auf 69,4 und auch der Frametime-Graph sah mehr nach Linie als Puls aus.

 

[flaphoschi]

Danke für den Test an die Redaktion

Hoffentlich könnt Ihr das auch bald mit Counter-Strike 2 machen. Mit nativen Port! Und somit hoffentlich auch ohne Framedrops oder andere lästige Probleme.

PS: Erinnert Ihr euch noch a den ersten native Port von CSGO auf Linux? Direkt mal die Windows mit Nvidia stehen gelassen.
Valve hatte eine etwas “ineffiziente” Implementierung. Hat halt keiner gemerkt, bis man den OpenGL-Layer hatte und mal mit Linux nativ gegen testen konnte. Blogbeitrag dazu von Valve bei archive.org zu finden. Was man nicht alles tut, damit es unter Windows nicht so ruckelt.

Ich hätte es ja so gelassen