News Spielen unter Linux: Raytracing dank Vulkan-Erweiterung noch effizienter

[PCGH_Sven]

Die Khronos Group hat Vulkan 1.4.351 mit sechs neuen Erweiterungen veröffentlicht. Das Highlight für Spieler ist ganz sicher die sogenannte "Opacity Micromap", eine Erweiterung für effizienteres Raytracing, doch das ist längst nicht alles.

Was sagt die PCGH-X-Community zu Spielen unter Linux: Raytracing dank Vulkan-Erweiterung noch effizienter

Bitte beachten: Thema dieses Kommentar-Threads ist der Inhalt der Meldung. Kritik und allgemeine Fragen zu Online-Artikeln von PC Games Hardware werden hier gemäß der Forenregeln ohne Nachfrage entfernt, sie sind im Feedback-Thread besser aufgehoben.

 

[joecnstr]

Sehr schön! Bin gespannt, wann man es im Einsatz sehen wird und ob es spürbare Verbesserungen gibt. Auch von Nvidia gibt es in letzter Zeit einige positive Signale für Linux

Es sind spannende Zeiten. Gefühlt bringt jedes größere Update ein paar Prozent mehr Leistung für Linux Gaming. Was hier in den nächsten Jahren noch erreicht werden kann?

 

[ameisenmann]

Ich frage mich echt, was Valves Masterplan ist. Wollen sie PC-Gaming komplett übernehmen? Es soll sehr eng an ihre Hardware, SteamOS und Steam verknüpft sein, dass niemand mehr unter Windows spielen will?
Unrealistisch ist es nicht, wenn man unter Linux stetig mehr fps bekommt als unter Windows, werden irgendwann zumindest die Leute umsteigen, die ein Build nur fürs Gaming nutzen.

 

[Homerclon]

Unter den beteiligten Ingenieuren aus verschiedenen Organisationen findet sich auch Valves Hans-Kristian Arntzen

Hans-Kristian Arntzen ist doch kein MA von Valve, er ist Eigenständig - Gründer und CEO von Arntzen Software AS in Norwegen. Wie man eurem eigenen Link auch entnehmen kann.

 

[joecnstr]

Ich frage mich echt, was Valves Masterplan ist. Wollen sie PC-Gaming komplett übernehmen? Es soll sehr eng an ihre Hardware, SteamOS und Steam verknüpft sein, dass niemand mehr unter Windows spielen will?
Unrealistisch ist es nicht, wenn man unter Linux stetig mehr fps bekommt als unter Windows, werden irgendwann zumindest die Leute umsteigen, die ein Build nur fürs Gaming nutzen.

Nein das macht so keinen Sinn - wenn sie sich abschotten wollen würden, wäre ja Windows die naheliegende Wahl, am besten mit Secure Boot und Steam tief im Kernel vergraben. Die Linux Strategie ist ja viel offener.

Der Grund ist (so meine Interpretation) einfach: Sie müssen unabhängig von Microsoft werden. Denn wenn Microsoft eines Tages auf die Idee kommt Gebühren zu verlangen (sei es von Valve direkt, oder im Abo von den Nutzern) dann sehen sie alt aus... Selbst wenn Linux nicht die Weltherrschaft erlangt (wie es von einigen Leuten offenbar erhofft wird ) haben sie damit immer noch ein Ass im Ärmel.

Ah und natürlich müssen sie keine Windows Lizenzen für Steam Deck, Steam Machine, etc. erwerben. Weiss nicht wie viel das pro Gerät wäre (es wird ja kaum der reguläre Vollpreis sein), aber es könnte die Entwicklungskosten für SteamOS / Proton decken, denke ich.

 

[Zik7]

Langsam wird es eng!

 

[The_Invisible84]

Nein das macht so keinen Sinn - wenn sie sich abschotten wollen würden, wäre ja Windows die naheliegende Wahl, am besten mit Secure Boot und Steam tief im Kernel vergraben. Die Linux Strategie ist ja viel offener.

Der Grund ist (so meine Interpretation) einfach: Sie müssen unabhängig von Microsoft werden. Denn wenn Microsoft eines Tages auf die Idee kommt Gebühren zu verlangen (sei es von Valve direkt, oder im Abo von den Nutzern) dann sehen sie alt aus... Selbst wenn Linux nicht die Weltherrschaft erlangt (wie es von einigen Leuten offenbar erhofft wird ) haben sie damit immer noch ein Ass im Ärmel.

Ah und natürlich müssen sie keine Windows Lizenzen für Steam Deck, Steam Machine, etc. erwerben. Weiss nicht wie viel das pro Gerät wäre (es wird ja kaum der reguläre Vollpreis sein), aber es könnte die Entwicklungskosten für SteamOS / Proton decken, denke ich.

Naja man darf halt nicht vergessen das man trotzdem nur die DirectX API nachbaut. Schöner wäre wenn Spiele wirklich nativ gegen Linux kompilieren. Anscheinend ist es aber wegen dem ganzen Distro Wirrwarr einfacher die DX API nachzubauen was schon einiges über die Hauptprobleme von Linux aussagt. Ich hoffe zb solche Zusammenschlüsse wie Open Gaming Collective bringen hier endlich einen distroübergreifenden Standard rein wo sich Entwickler anhalten können.

 

[joecnstr]

Naja man darf halt nicht vergessen das man trotzdem nur die DirectX API nachbaut. Schöner wäre wenn Spiele wirklich nativ gegen Linux kompilieren. Anscheinend ist es aber wegen dem ganzen Distro Wirrwarr einfacher die DX API nachzubauen was schon einiges über die Hauptprobleme von Linux aussagt. Ich hoffe zb solche Zusammenschlüsse wie Open Gaming Collective bringen hier endlich einen distroübergreifenden Standard rein wo sich Entwickler anhalten können.

Hier ist halt der Punkt, dass die Verwendung der APIs nicht in der Hand von Valve liegt - die Spielehersteller verwenden was sie möchten und das ist aktuell natürlich mehrheitlich DirectX.

Linux APIs haben leider einen "Nachteil": Sie entwickeln sich schnell weiter und werden schnell legacy. Software, welche diese Frameworks nutzt muss nachziehen. Bei der üblichen Open Source Software kein Problem - aber closed Source wird einfach sehr schnell nicht mehr gewartet wenn es nicht mehr verkauft wird. Deswegen muss man, sehr langfristig gesehen, eigentlich immer API Wrapper bzw Kompatibilitätsschichten vorsehen.

Beispiel: SDL ist mittlerweile ein Sorgenkind bei nativen Linux builds. Ich hatte schon häufig das Problem, dass native Spiele nicht starten oder nicht korrekt unter Linux funktionieren. Es klappt dann tatsächlich besser, die Windows Version mit Proton zu wählen

Und was mir noch wichtig zu erwähnen ist, weil es ständig als Argument vorgebracht wird: Das hat alles NICHTS mit der Distribution zu tun, außer deine spezifische Distribution verweigert aus religiösen Gründen die Verwendung gewisser Libs und APIs

 

[Capucius]

Naja man darf halt nicht vergessen das man trotzdem nur die DirectX API nachbaut. Schöner wäre wenn Spiele wirklich nativ gegen Linux kompilieren. Anscheinend ist es aber wegen dem ganzen Distro Wirrwarr einfacher die DX API nachzubauen was schon einiges über die Hauptprobleme von Linux aussagt. Ich hoffe zb solche Zusammenschlüsse wie Open Gaming Collective bringen hier endlich einen distroübergreifenden Standard rein wo sich Entwickler anhalten können.

Was für ein "Distro-Wirrwarr"? Der Kernel ist der Gleiche. Man kann auch innerhalb einer Distri einen anderen Kernel oder einen anderen Window-Manager verwenden. Wenn etwas eine Standardisierung schwierig machen würde, dann wäre es eher die Modularität, aber ähnlich wie bei Windows, wo man dann als Gamer auch schon bestimmte Versionen nicht zum Zocken nutzen konnte (angefangen bei Win NT vs. Win 98) muss man sich dann eben auf etwas festlegen. Es wird keine DX API nachgebaut, wie kommst du auf die Idee. Es wird gewrappt bzw. gemappt, und der Grund dafür ist wirtschaftlich, nämlich dass die Mehrheit der Spiele so vorliegt und man sie verfügbar machen will, um sie verkaufen zu können. Damit steigt die absolute Spielerzahl (der relative Marktanteil, der immer verglichen wird ist für Verkäufe nicht so wichtig, wie tatsächliche Absatzzahlen) und irgendwann ist ein nativer Port dann wirtschaftlich interessant.

Warum äußerst du dich eigentlich öffentlich, wenn du dich mit Linux nicht auskennst?

 

[The_Invisible84]

Hier ist halt der Punkt, dass die Verwendung der APIs nicht in der Hand von Valve liegt - die Spielehersteller verwenden was sie möchten und das ist aktuell natürlich mehrheitlich DirectX.

Linux APIs haben leider einen "Nachteil": Sie entwickeln sich schnell weiter und werden schnell legacy. Software, welche diese Frameworks nutzt muss nachziehen. Bei der üblichen Open Source Software kein Problem - aber closed Source wird einfach sehr schnell nicht mehr gewartet wenn es nicht mehr verkauft wird. Deswegen muss man, sehr langfristig gesehen, eigentlich immer API Wrapper bzw Kompatibilitätsschichten vorsehen.

Beispiel: SDL ist mittlerweile ein Sorgenkind bei nativen Linux builds. Ich hatte schon häufig das Problem, dass native Spiele nicht starten oder nicht korrekt unter Linux funktionieren. Es klappt dann tatsächlich besser, die Windows Version mit Proton zu wählen

Und was mir noch wichtig zu erwähnen ist, weil es ständig als Argument vorgebracht wird: Das hat alles NICHTS mit der Distribution zu tun, außer deine spezifische Distribution verweigert aus religiösen Gründen die Verwendung gewisser Libs und APIs

Generell stimme ich dir zu, aber man hat sich halt auch selbst ein Ei gelegt weil Proton so gut funktioniert. Im Prinzip haben Entwickler dadurch noch weniger Gründe einen nativen Linux Port zu machen.

Zwecks der Distro Sache: Doch hat es schon. Ob ich als Entwickler offiziell ein Rolling Release, Standard Release (Ubuntu, Debian) und Enterprise OS (RHEL, Rocky LInux) supporten muss macht schon einen großen Unterschied. Man kann nicht mal die ganzen dlls dazu mitausliefern weil es oft schon an der untersten glibc ABI scheitert.

Warum äußerst du dich eigentlich öffentlich, wenn du dich mit Linux nicht auskennst?

Klar arbeite ja auch nur 25 Jahre mit Linux Desktops nur ist da der Hype längst verflogen und man sieht es eben realistisch. Du kannst dich ja selbst fragen warum setzt sich Linux einfach nicht durch? Jeder wettert immer sofort "ist doch ein Unsinn" aber keiner konnte mir dazu noch eine gute Antwort geben

 

[Capucius]

Klar arbeite ja auch nur 25 Jahre mit Linux Desktops nur ist da der Hype längst verflogen und man sieht es eben realistisch. Du kannst dich ja selbst fragen warum setzt sich Linux einfach nicht durch? Jeder wettert immer sofort "ist doch ein Unsinn" aber keiner konnte mir dazu noch eine gute Antwort geben

Da zitiere ich mal Kurt Tucholsky: „Erfahrung heißt gar nichts. Man kann seine Sache auch 35 Jahre schlecht machen“.

Es gibt eine Menge plausibler Antworten, und letzten Endes ist die Frage falsch gestellt, denn im Serverbereich hat sich Linux ja nicht umsonst weitestgehend durchgesetzt. Im Endgerätebereich sind die Gründe doch seit Jahren klar: der Lock-In Effekt ist enorm, dadurch dass die erwerbstätige Bevölkerung in der Breite "Windows- und Office-Skills" hat und das in Ausschreibungen wie Bewerbungen angegeben wird. Dazu kommt ein Ökosystem, das von MS gut aufgesetzt wurde und dafür sorgt, dass im Businesskontext vielen Menschen vom Status Quo profitieren. Nicht zu vergessen der bekannte Faktor "Niemand ist je dafür gefeuert worden ein System von Microsoft oder SAP einzuführen". Und halt noch die grundsätzliche Trägheit der Masse, es ist immer schwieriger vom Status Quo wegzukommen, als darauf zu beharren.

 

[joecnstr]

Generell stimme ich dir zu, aber man hat sich halt auch selbst ein Ei gelegt weil Proton so gut funktioniert. Im Prinzip haben Entwickler dadurch noch weniger Gründe einen nativen Linux Port zu machen.

Zwecks der Distro Sache: Doch hat es schon. Ob ich als Entwickler offiziell ein Rolling Release, Standard Release (Ubuntu, Debian) und Enterprise OS (RHEL, Rocky LInux) supporten muss macht schon einen großen Unterschied. Man kann nicht mal die ganzen dlls dazu mitausliefern weil es oft schon an der untersten glibc ABI scheitert.

Klar arbeite ja auch nur 25 Jahre mit Linux Desktops nur ist da der Hype längst verflogen und man sieht es eben realistisch. Du kannst dich ja selbst fragen warum setzt sich Linux einfach nicht durch? Jeder wettert immer sofort "ist doch ein Unsinn" aber keiner konnte mir dazu noch eine gute Antwort geben

Hmmm aber dafür gibt's ja APIs und Bibliotheken, damit man unabhängiger von System/Distro Spezifika ist? Wichtig ist halt dass diese APIs relativ lange/gut abwärtskompatibel sind. Also dass z.b. die Entwickler auf sagen wir mal Version 5.0 von etwas aufbauen und kein Problem entsteht wenn sie Rolling Release Distro dann Version 5.3.1-alpha verwendet...

GlibC ist natürlich der heilige Gral, der Kern der Kompatibilität. Wenn das nicht passt, läuft glaube ich nicht mal mehr ein Container/VM. Aber ich hab noch nie gehört dass es daran scheitert. Ausnahme: Wenn dein System puristisch nur noch rein 64bit Libs verwendet. Dann ist alles, was für 32bit compiled wurde, inkompatibel

 

[RoomReich]

Ich muss jetzt mal blöd fragen. Bringt das auch was für bestehende Spiele, oder muss da erst was gepatcht werden seitens Entwickler?

 

[The_Invisible84]

Hmmm aber dafür gibt's ja APIs und Bibliotheken, damit man unabhängiger von System/Distro Spezifika ist? Wichtig ist halt dass diese APIs relativ lange/gut abwärtskompatibel sind. Also dass z.b. die Entwickler auf sagen wir mal Version 5.0 von etwas aufbauen und kein Problem entsteht wenn sie Rolling Release Distro dann Version 5.3.1-alpha verwendet...

GlibC ist natürlich der heilige Gral, der Kern der Kompatibilität. Wenn das nicht passt, läuft glaube ich nicht mal mehr ein Container/VM. Aber ich hab noch nie gehört dass es daran scheitert. Ausnahme: Wenn dein System puristisch nur noch rein 64bit Libs verwendet. Dann ist alles, was für 32bit compiled wurde, inkompatibel

Daran scheiterts aber und das ist sogar die Hauptkritik von Linus Torvalds seitens Linux Desktop. GlibC Kompatibilität wird vor allem bei RollingRelease Distros gerne geschrottet und meistens bricht gar nicht die API sondern die ABI. Und das ist nur ein Paket davon.

Wenn du das wirklich mal selbst erleben willst kann ich nur eine Source Distro wie Gentoo empfehlen und als Desktop versuchen ein paar Monate zu verwenden. Und dann viel Glück wenn ein GCC/Glibc Update kommt ; )

Aber darum gings eigentlich gar nicht so, es geht eigentlich darum das ein Entwickler dafür Support geben müsste. Er könnte zwar sagen "nur Ubuntu LTS" aber da würde man viele wieder nur verägern.