Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
TestDiablo IV unter Linux im Test: Benchmarks auf dem Arch-Gaming-PC und Valves Steam Deck
"Als Kompatibilitäts-Layer wurde Proton in der GloriousEggroll-Ausführung Wine-GE-Proton8-8 genutzt. Der DX12-zu-Vulkan-Übersetzter vkd3d-proton war in Version 2.9 im Einsatz."
"und über Lutris ausgeführt. Zur Dokumentation der FPS diente MangoHud in Version 0.6.9.1-6, das neuerdings auch in den offiziellen Arch-Linux-Paketquellen enthalten ist."
Bei denen musste ich erst mal Google fragen und ob ich mir das merken werde, bin ich mir nicht sicher.
Schön für jeden, der dort involviert ist. Ich bin es nicht.
Das ist halt einfach gelogen.
Auf Linux laufen einfach mehr Spiele. Versuch mal ein Jade Empire nativ auf einem aktuellen Windows zu spielen und dann nimm mal Proton v.8...
Die Kompatibilitätsschichten erlauben es, dass viel mehr Spiele möglich sind als auf einem Windows, welches mit weiterem voranschreiten, nach hinten hin immer mehr aussortiert. Und das es auch mit aktuellen Spielen geht... Nun du hast den Titel gelesen?
Gaming gegen Linux anzuführen untergräbt deine eigene Argumentation. Das du hingegen nicht fähig bist ein Arch-Linux aufzusetzen, würde ich dir hingegen abkaufen, also knüpfe eher daran an mit deiner Argumentation.
[wege]mini schrieb:
"Als Kompatibilitäts-Layer wurde Proton in der GloriousEggroll-Ausführung Wine-GE-Proton8-8 genutzt. Der DX12-zu-Vulkan-Übersetzter vkd3d-proton war in Version 2.9 im Einsatz."
"und über Lutris ausgeführt. Zur Dokumentation der FPS diente MangoHud in Version 0.6.9.1-6, das neuerdings auch in den offiziellen Arch-Linux-Paketquellen enthalten ist."
Bei denen musste ich erst mal Google fragen und ob ich mir das merken werde, bin ich mir nicht sicher.
Schön für jeden, der dort involviert ist. Ich bin es nicht.
Bildung ist eine Holschuld. Was daran jetzt so schwer zu merken sein soll ist mir schleierhaft. Mal vereinfacht gesagt:
MangoHUD = MSI Afterburner
GloriousEggroll = Proton-Fork
vkd3d-proton = für DirectX12 (DXVK für DirectX 9-11 (bzw. vll bald für DirectX 8-11))
Lutris = unabhängiger Spielelauncher und Wine-Frontend
Viel komplizierter ist es, zu erklären, warum es auf Linux (und eigentlich auch auf Windows) nicht den EINEN Grafiktreiber gibt. Aber das muss man verstehen wollen, sonst hat eine Erklärung keinen Zweck.
@[wege]mini das sind aber nur technische Details, die wichtig sind wenn man die CB-Benchmarks selbst nachstellen möchte. Oder falls es einen bekannten Bug in einer bestimmten Version gibt, die Leserschaft herausfinden kann ob die Benchmarks betroffen sind.
Dinge, die mir nicht wichtig sind, merke ich mir nur kurzzeitig. Da sind wir Menschen alle gleich. Für Umsteiger ist aber das ganze "Tamtam" erst einmal abschreckend.
Wenn man dann noch die Konsole benutzen muss, muss man es wirklich mögen, da es auch Alternativen gibt.
Bleiben wir dabei, dass bei der Performance Linux mittlerweile auf Augenhöhe ist. Die Usability könnte besser sein, hier landen wir dann aber wieder bei Distributionen.
Nimmst du die "richtige" ist alles gut.
Und natürlich ist Bildung nur dann eine Holschuld, wenn man sie braucht.
Aktuell sehe ich aber keinen Grund, warum ich Linux brauchen sollte.
Ich hab heute mit ein paar meiner Kinder eine kleine CS Lan-Party gemacht.
Fazit: wir haben CS:S gespielt, weil ein PC zu lahm für CS:GO war xD bzw hats schon im Menü enorm geruckelt. Bei mir hat die native Version von CS:S aber nicht mehr gestartet (im Jänner gings noch).
Hab jetzt eine Proton-Version genommen, ging dann auch gleich. Bei dem Lahmen PC gibts auf dessen Ubuntu(das ich immer noch nicht neu aufgesetzt hab seit 9 Jahren...) im Vollbild von CS(egal S oder GO) keinen sichtbaren Mauszeiger, KA worans liegt.
Hier durchweg gute Ehrfahrung mit CSGO und CS1. Lediglich die neuen Menüs bei CSGO waren kurz verbuggt. Problemquelle könnte ein altes System sein oder schlimmer - Nvidia?
Ich habe zwischen 2002 und 2010 immer wieder CS mit WINE gespielt. Die Zeit hat mich traumatisiert und gelehrt*. Ich habe es dann sein lassen, Quake3 und GCC waren die neuen Spiele. Sonst gab es Fehler im Spiel, mal Programmabsturz bei ALT+Tab, mal Ruckler und dann hat man WINE als Plagge auf der Platte (ob der Fehler jetzt vom neuen WINE kommt? Fonts installiert? Laufwerksbuchstabe…).
Valve hat es mit dem Derivat Proton wohl gut hinbekommen! Ich verzichte dankend auf den zusätzlichen Layer mit höherem Speicherverbrauch und Komplexität. Auch wenn die Ergebnisse teilweise beeindrucken sind, siehe hier.
Apple nutzt den ganzen Unterbau nun auch als Portierungshilfe. Wohlwissend über den Qualitätsanspruch habe sie klargestellt, dass die Publisher nicht mal daran denken sollen ein Spiel für MacOS mit WINE/Proton auszuliefern. Apple hat recht native Ports zu verlangen, also beste Leistung und Integration. Wobei man sagen muss, Apple hat sich mit Mantel (API) selbst überschätzt und Problem eingehandelt. Die hätten einmal einem Standard folgen müssen, Vulkan.
Valve muss aufpassen. Proton bzw. WINE sind als Layer nur eine Krücke oder Schmerztablette. Wer zu lange dran bleibt wird süchtig. Das heißt die Spieleentwickler lassen Valve die Arbeit machen mit Proton und Valve erstickt irgendwann daran. Das war und ist immer die Warnung bei WINE und mit steigendem Erfolg (mehr Tabletten…) wird es gefährlicher.
Meine Idee wäre ja ein “Native Linux Port Award” mit zwei Kategorien. Bester Launch-Port und bester Subsequent-Port (also wenn Linux anfänglich nicht unterstützt) wurde. Anreiz für Entwickler ist Anerkennung und Mehreinnahmen?
* Seitdem achte ich auf native Portierung oder bewusst kompatible Lösungen. Umgekehrt meide ich alles Inkompatiblen. Wenn die Gegenseite nicht kooperieren möchte, macht man nur schlechte Kompromisse! Nicht portiert? API nicht offen spezifiziert? Antwortet mit “Linux unterstützen wird nicht”? Dann fällt es sofort durch eine andere gute Lösung. Die Anwort auf Laptop ist nicht “vielleicht mit einem Startparameter ACPI…” sondern der Kauf eines für Linux zertifizierten ThinkPads. Das Leben ist so viel angenehmer
So hat Nvidia sich auch das Hausverbot hier eingehandelt. Selber schuld. Sie hatten mehr als genug Zeit quelloffene Kernelmodule und Dokumentation bereitzustellen. AMD und Intel habe das getan. Vor mehr als einer Dekade.
Jede Hardwareempfehlung sollte mit dem Torvalds-GIF anfangen. “Wenn sie wissen was Linux ist und es auch nur erwägen…”. Was bringen einem theoretisch 10%, 40% oder 70% mehr Grafikleistung wenn es nicht zuverlässig ist?
Am Steam Deck läuft D4 wirklich super. Bis man ca 14 GB RAM belegt hat, dann schmiert alles, inklusive OS ab. Das ist Schade, denn so ist man gezwungen in niedrigeren Einstellungen zu spielen, als eigentlich möglich wäre. Hat das sonst noch jemand beobachtet? Und mit welchen Kompatibilitätseinstellungen spielt ihr?
Kann ja noch werden. ^^
Als Ergänzung vielleicht noch, ganz grob. Proton ist ein Wine-Derivat von Valve (Steam), Glorious Eggroll ist ein Pseudonym eines Entwicklers der Proton (und Wine) dann nochmal forkt und anpasst. Seine Versionen haben ein GE-Suffix, nach dem Schema Proton-GE-Versionsnummer.
Oft ist GE bei sehr neuen Spielen besser, einfach weil der Typ unglaublich schnell Dinge fixt und einen hohen Output hat. Eine eigene Distribution – Nobara – hat er nebenbei auch noch.
Zur Installation nutze ich ProtonUp-Qt. Wirklich oft brauchte ich Proton-GE bisher nicht.
[wege]mini schrieb:
Dinge, die mir nicht wichtig sind, merke ich mir nur kurzzeitig.
Die IT-Welt wird halt immer komplexer und deshalb gibt es nicht mehr so simple Dinge wie "der eine Grafiktreiber". Es gibt bei Linux einen Grafikkartentreiber im Kernel, "amdgpu" ist das auf AMD-Seite beispielhaft) der sorgt dafür dass das OS bzw. die Applikationen/Spiele überhaupt mit der Hardware der GPU reden können (Schnittstelle Hardware <-> Software). Dann gibt es aber auch noch Userspace-Treiber wie Mesa und deren Vulkan-Treiber RADV (wieder beispielhaft auf AMD-Seite), welche bestimmte Grafik-APIs umsetzen. Die Implementationen von OpenGL, Vulkan usw. sind also nicht im Kerneltreiber sondern separat in einem Userspace-Treiber. Und das sind auch sehr große Projekte, da diese APIs halt auch sehr umfangreich sind.
Das ist bei Windows und NVidia bspw. rein technisch gesehen genauso, nur kriegt man das als Windows-Blackbox-User halt typischerweise nicht so genau und in dem Detailgrad mit wie unter Linux. Als User lädt man unter Windows ein riesiges Bloatware-Paket von amd.com oder nvidia.com runter was mind. 500MB groß ist, installiert das und dann setzt sich halt im Kopf fest "Ich hab DEN AMD/NVidia-Treiber installiert, mehr brauch ich nicht". Dass das in Wirklichkeit ein ganzes Paket an Treibern und zusätzlicher Software plus X ist, wird dann halt wegabstrahiert.
Ist ja OK, irgendwie muss man immer Komplexität wegabstrahieren wenn man über Software redet, sonst müssten wir alle auf Low-Level-Code-Ebene reden und dann wird's kompliziert (und bei Closed Source Software geht das auch nicht mal so gut dann). Aber manchmal ist etwas Differenzierung doch nötig, vor allem unter Linux, weil es da nicht nur EIN Paket gibt sondern eben pro Treiber und Software ein eigenes, und man kann auch anders mixen und matchen: z.B. könnte man bei AMD amdgpu+Mesa+RADV nutzen, man könnte aber auch amdgpu+Mesa+AMDVLK nutzen. Als Beispiel. Die Aufsplittung von jeder sinnvoll unterscheidbaren Komponente auf Einzelpakete hat also auch Vorteile. Und das wird bei Linux-Paketen halt typischerweise gemacht. Alles was irgendwie sinnvoll anhand von Funktion aufgesplittet werden kann, wird aufgesplittet. Durch das Dependency-Feature von allen gängigen Paketmanagern weiß der Paketmanager ja, dass das eine Paket dann nicht reicht sondern noch mind. diese anderen Pakete ebenfalls mit dazu gehören (entweder als "required" oder "optional"). Bei Windows-Setups wird typischerweise viel mehr auf einmal mitinstalliert, also da ist eher weniger aufgesplittet, was vor allem erst mal in mehr Bloat resultiert. Wenn ich bei mir schaue, Mesa ist ca. 17MB groß, LLVM als Dependency 35MB, RADV 2,3MB und amdgpu ca. 12MB. Macht ca. 66MB. Selbst wenn wir die Userspace-Treiber x2 nehmen um noch die 32bit-Libs für den 32bit-Support dazu zu nehmen, sind es nur 120MB. Damit kann man fast alle Spiele spielen. Vergleicht das mal mit der Größe der Windows-Treiberpakete.
eher alle paar Monate mal nen Problemchen, aber da man sich ja an sein Wunschsystem gewöhnt kennt man mit gewisser Zeit auch die kniffe mal etwas zu fixen oder zu ändern, das es wieder läuft.
Na ja da sage ich nur zu, Kauf dir mal neue Hardware(7900xtx), dann wirst du sehen das nicht nur Tage lang sondern auch Monate lange nichts so läuft wie man sich das vorstellt. Kannst du dran runfummeln wie du willst kommt nichts gutes bei rum. Es gibt Meiner Meinung noch immer nichts, was das zusammen erlaubt:
Dual Monitor beide mit 144Hz
Beide einzeln Saklieren weil FHD und UHD
Freesync
Beide Monitore aktiv
Problemlos auf einem spielen und auf den anderen YT schauen
Was für Windows an sich basic ist, läuft unter Linux über haupt gar nicht. Mit X kannst du das vergessen da geht der zweite Monitor dunkel und mit wayland kannst du die Performance z.B in POE vergessen weil dir absolut Müll ist. Außerdem kann man damit nicht im Hauptfestern ordentlich spielen weil er die Taskleiste nicht ausblenden kann usw. Teil erkennt er nicht mal dir Auflösung und zeig nur Mist an.
Es läuft einfach nicht und das sind nur paar Bsp.
Leute ich möchte weg von Windows, aber nicht zurück zum gefühlt Win95 wo man jede Woche neu formatieren musste. Okay etwas über spitzt aber so fühlt es sich an.
Warum will ich weg von Windows? Weil mir die Datenpolitik gar nicht gefällt.
Das liegt wahrscheinlich an SCHED_AUTOGROUP was bei manchen Distributionen standardmäßig eingeschaltet ist (Details hier und hier).
Entweder abstellen oder stattdessen mit cgroups regeln.
Aber auch nachdem ich das per Boot-Parameter deaktiviert hatte (/proc/sys/kernel/sched_autogroup_enabled war wirklich 0) bekamen zwei parallel encodende AVIdemux selbst bei sehr hoch/sehr niedrig die gleiche CPU-Zeit.
Egal ob mit Zen- oder normalen Kernel (6.3).
Also habe Autogroup wieder aktiviert und das versucht:
Start using the autogroup nice level at proc/<pid>/autogroup instead of the regular nice level.
Aber auch das ging in die Hose: Wenn ich beim pid des einen AVIdemux einen höheren Nice-Wert gesetzt habe, wurde der automatisch auch beim anderen geändert.
Aber jetzt habe ich endlich einen Ansatzpunkt, in welcher Richtung ich suchen muss:
Herausforderung angenommen!
Alexander2 schrieb:
Das nun Umsteiger erstmal wieder eine Lernphgase haben - meist sogar eine schlimmere als komplette neueinsteiger
XP kannte ich noch in- und auswändig, aber schon seit Win7 blicke ich da nicht mehr durch.
Win10+11 sind für mich der reinste Horror in Punkto Übersichtlichkeit und Benutzerführung: Wie kann man sich sowas nur freiwillig antun?
Bengart schrieb:
Ja, hab ich auch eine Zeitlang gesagt im Zusammenhang mit Linux. Nach wochenlangem gebastel kam dann i Foren der klassische, hast du auch falsch aufgesetzt, da muss man natürlich hier noch einen Parameter setzen, da einen bestimmten Treiber über die Konsole einbinden und generell macht man ja eh alles falsch.
Dazu kann ich nichts sagen: Alle anfänglichen Probleme konnte ich per Google und den guten Wikis (insbesondere dem von Ubuntuusers) selbst lösen, was mir sogar Spaß gemacht hat, da ich dadurch viel lernen konnte und ein Erfolgserlebnis nach den anderen hatte.
Ganz anders als ich es von Windows her gewohnt war: Dort habe ich zwar viele mit den gleichen Problemen finden, aber letztendlich lief es immer auf eine Neuinstallation hinaus: Reparaturversuche waren fast immer verschwendete Zeit und haben es höchstens schlimmer gemacht.
Bengart schrieb:
Auf den Hinweis, das ich da nicht bewandert bin, kam der Hinweis, das dann Linux nicht das richtige ist. 🤷♂️
Die Probleme mit X11 gehören schon sehr bald der Vergangenheit an da immer mehr auf Wayland-Support hin umgebaut wird. Ja, X11 ist alt und kann manche Dinge nicht mehr, die heutzutage vielleicht als "basic" gesehen werden. Aber Wayland kann es. Dementsprechend kann ich nur anraten, nutzt Distributionen/Desktops/Compositors die auf Wayland setzen. X11-Apps laufen darunter transparent via XWayland. Aber auch diese Krücke wird irgendwann weg sein, wenn Wine usw. auch nicht mehr X11 nutzen. Die Arbeiten daran laufen.
Das ist halt eine Riesenumstellung im Linux-Desktop-Bereich, von der alten Technik die noch geradeso am Leben gehalten wird auf moderne Technik. Die immer noch nicht für alle relevanten Desktop-Programme abgeschlossen ist.
Bei brandneuer Hardware ist es halt typischerweise so, dass man ein paar Monate warten sollte bis alles rund genug ist. Ich war selbst Early Adopter einer 7900XTX unter Linux, anfangs war's noch relativ problematisch, inzwischen läuft alles ohne Probleme. Aber auch hier gilt: die Entwicklungsgeschwindigkeit steigt. Früher musste man noch länger warten. Heutzutage geht das schon schneller. Auch dieses Problem verringert sich also im Laufe der Zeit. Je mehr User dazu kommen, je mehr Relevanz die Linux-Desktop-Technologien für die Hersteller haben und je mehr Entwickler dran arbeiten, desto schneller geht das ganze auch. Windows ist halt noch der Platzhirsch und jeder muss direkt alles stehen und liegen lassen wenn da irgendwas noch nicht rund läuft. Einfach weil da die meisten User sind. Das ändert sich aber. OSX und Linux graben Windows immer mehr Anteile weg. Windows war mal bei > 95% Dominanz auf dem Desktop-Bereich, aktuell sind es "nur" noch > 70% oder so.
Das ist halt einfach gelogen.
Auf Linux laufen einfach mehr Spiele. Versuch mal ein Jade Empire nativ auf einem aktuellen Windows zu spielen und dann nimm mal Proton v.8...
Die Kompatibilitätsschichten erlauben es, dass viel mehr Spiele möglich sind als auf einem Windows, welches mit weiterem voranschreiten, nach hinten hin immer mehr aussortiert. Und das es auch mit aktuellen Spielen geht... Nun du hast den Titel gelesen?
Gaming gegen Linux anzuführen untergräbt deine eigene Argumentation. Das du hingegen nicht fähig bist ein Arch-Linux aufzusetzen, würde ich dir hingegen abkaufen, also knüpfe eher daran an mit deiner Argumentation.
Sehr geile Argumentation. Es laufen (angeblich) MEHR Spiele auf Linux als auf Windows und deshalb können gar nicht tausende Spiele auf Linux nicht laufen? Unabhängig davon ob dein Argument wahr ist (oder nicht) hat das eine mit dem anderen NICHTS zu tun.
Tatsache ist jedoch, ProtonDB bietet den Gegenbeweis. 50% der Spiele dort gelten als Unsupported/Borked. Da 40% als Verfied/Playable gelten und das ~9700 sind entspricht das >10000 Spiele alleine die auf ProtonDB als nicht funktional gelten. Mir hier eine Lüge zu unterstellen ist nicht nur dreist sondern gleicht einer unwahren Tatsachenbehauptung. Wenn man dann noch bedenkt dass 2021 ca. 50 000 Spiele alleine auf Steam sind und damit die meisten Titel noch nicht einmal einen Eintrag in ProtonDB haben setzt dem ganzen das i-Tüpfelchen auf.
Tatsache ist jedoch, ProtonDB bietet den Gegenbeweis. Stellt man auf Steam Catalog dann gelten 414 Spiele als Borked. Auf den ganzen Steam Catalog hinweg kann man dann extrapolieren dass tausende Spiele nicht funktionieren. Man könnte natürlich annehmen dass evtl. sogar mehr Spiele funktionieren die ungetestet sind. Man könnte aber natürlich auch argumentieren dass Spiele die getestet wurden auch ein höheres Interesse daran hatten dann letztlich auch zu funktionieren. Statistical Bias ist hier schwer rauszudenken. Aber von 414/11000 auf extrapoliert 2000+ zu schließen ist damit nicht weit hergeholt. Von den Bronze Titel die man auch als unspielbar deklarieren könnte mal von abgesehen.
Natürlich decke ich damit nicht WINE oder DXVK ab (Gibt es noch andere?). Vulkan hat aber im Vergleich recht wenig Spiele. Höchstens ein paar Tausend und das war schon sehr nett geschätzt. Ich habe leider keine Liste gefunden die aufzeigt wie viele Spiele die mit Proton nicht funktionieren dann mit WINE funktionieren. Aber die bisherigen Datenlage ist ziemlich erdrückend. Die meisten Spiele laufen nicht auf Linux.
Es wird aber noch besser wenn du dann versuchst mit NATIV auf Windows zu argumentieren um dann Proton zu nennen was nichts weiteres als ein sehr ausgefuchster und komplexer Emulator ist der nicht auf Hardwareemulation sondern auf Kompatibilitätsprinzipien basiert. NATIV auf Linux (DXVK) laufen insgesamt nur sehr sehr wenig Spiele. Äpfel und Birnen und so?
Und man bekommt Jade Empire mit einem Xbox Emulator ziemlich sicher auf Windows zum laufen. Ich bin mir auch sehr sicher ich brauche weniger Zeit dafür den Xbox-Emu aufzusetzen als dass ich jetzt ein (Nobara-)Linux aufsetze auf dem es ja quasi "out of the box" läuft. Nicht wahr?
Ich finde auch gut dass du mir mit dem Ad-hominem Argument direkt die Möglichkeit gibst zurückzuschießen ohne am Schluss behaupten zu können ich hätte damit angefangen.
Dass du nicht in der Lage bist logische Schlussfolgerungen zu machen würde ich dir direkt abkaufen. Also knüpfe lieber mal daran an mit deiner Argumentation.
Ganz anders als ich es von Windows her gewohnt war: Dort habe ich zwar viele mit den gleichen Problemen finden, aber letztendlich lief es immer auf eine Neuinstallation hinaus: Reparaturversuche waren fast immer verschwendete Zeit und haben es höchstens schlimmer gemacht.
Habe seit Jahrzehnten Windows nicht neuinstalliert. Lebe noch mit einer Version, die von Windows 7 über 8 und 10 zu 11 upgegradet wurde. Finde es aber gut, das CB mehr über LINUX berichtet. Generell würde ich hier gerne mehr über Möglichkeiten lesen, Spiele unter Linux zum Laufen zu bringen.
Caramon2 schrieb:
en Schwachköppe ignoriert man am besten. Mit denen zu diskutieren ist genauso fruchtbar wie Reparaturversuche unter Windows.
Das war auch vor über 10 Jahren. Linux hat seitdem nicht wirklich an Verbreitung gewonnen. Ich kann es aber seitdem verstehen. Windows läuft einfach. Gut wenn es dann um Patitionstabellenstandards geht und die Migration, wird es sehr schwierig für den normalen User.
Momentan sehe ich aber keinen Grund zu Linux zu wechseln. Windows 11 gefällt mir sehr gut.
Ich glaube, du unterschätzt, wie lange es dauern kann, bis sich etwas Neues und Besseres auch in der breiten Masse durchsetzt. Vulkan ist eine relativ neue API. Fast die gesamte Spielebranche setzt seit Jahrzehnten auf DirectX, auf Engines die DirectX verwenden, auf Tools die mit Engines mit DirectX funktionieren, und auf Entwickler-Erfahrung die auf DirectX fußt. Nur weil da jetzt eine tolle neue API namens Vulkan existiert die auch noch offen ist und überall läuft anstatt nur unter Windows, bedeutet das nicht, dass die jetzt alle aufspringen und alles verändern. Das kostet ja auch etwas, und die meisten User sind IMMER NOCH bei Windows. Bei vielen Spieleschmieden wird sich also gar nix ändern, solange das was aktuell noch funktioniert, weiterhin funktioniert und solange sie die meisten User erreichen können. Das ist doch nur zu erwarten. Verdammt schade zwar, aber zu erwarten.
Und deshalb ist es wichtig, dass es mit Wine/Proton/DXVK/VKD3D usw. jetzt auch zusätzlich zur wichtigen offenen Vulkan-API auch Kompatibilitätstechniken gibt, die DirectX in Vulkan übersetzen und somit die gigantische Anzahl an vorhandenen und auch in Zukunft noch entwickelten DirectX-basierten Spielen auch auf Nicht-Windows-OSsen zugänglich/spielbar macht.
Übrigens: bei den unsupporteten Spielen her liegt es teilweise an den Entwicklern selbst. Beispielsweise Fortnite (eins der populärsten Spiele überhaupt) wirst du unter Linux nie spielen dürfen. Nicht, weil es technisch nicht funktionieren würde. Sondern weil via Anti-Cheat alles andere außer "physikalische Windows-Installation" verboten wird seitens des Herstellers. Es ist also einfach nur eine Entscheidung des Herstellers.
Ein derart dreistes Verhalten kann sich auch erst dann ändern, wenn weniger User Windows verwenden, denn erst wenn solche Firmen Kundschaft verlieren, werden sie erkennen, dass ihr Verhalten schlecht war. Deshalb: hört auf, diese sich selbst verstärkenden Monopole weiter zu unterstützen und bewegt euch in Richtung offener, neutraler Systeme, und unterstützt keine Software, die Nutzer von neutralen, offenen Systemen bewusst aussperrt.
Also wegen dem Thema Kompatibilität bei Linux..
Bei mir laufen aktuell mehr Spiele auf dem Deck als auf meinem Windows 10 Desktop!
Liegt daran, dass ALLES* auf dem Deck läuft, sogar Supreme Commander FA, wenn auch nur im Fenstermodus. Unter Windows kommt seit drei Jahren (irgendein Update/Treiber?) nur noch eine Fehlermeldung wenn ich das Game zocken will.
Ganz ehrlich, bin ziemlich begeistert von Linux bzw. Valves Steam OS.
*Von ca.100 Titeln in der Bibliothek gut 30 auf Deck probiert
Die ganzen Distributionen sorgen bei mir nur für Verwirrung, der Einstieg für Gamer mit Steam OS geht klar.
Ja, das ist auch noch ein Faktor. Bei protondb stehen User Reports. Die müssen nicht stimmen, und schon gar nicht aktuell sein. Es erlaubt also eine Einschätzung, aber es ist nicht DIE WAHRHEIT was läuft und was nicht läuft.
Bei brandneuer Hardware ist es halt typischerweise so, dass man ein paar Monate warten sollte bis alles rund genug ist. Ich war selbst Early Adopter einer 7900XTX unter Linux, anfangs war's noch relativ problematisch, inzwischen läuft alles ohne Probleme.
Wie gesagt es läuft nicht so wie ich es möchte, alles ohne Probleme halte ich für ein Gerücht.
Und eine 'Ausrede' Hardware ist zu neu, naja blöder Vergleich, im Windows stopfe ich egal was rein installieren dir Treiber läuft. Und das an Tag 1.
Auf meiner Arch Umgebung habe ich die 7900xtx gebootet schwarze Bild fertig. Mensch das macht Spaß, dann Monatelang warten bist es OOTB geht oder ewig dran run fummeln und Stundenlang bei Leuten abkupfern was die so herausgefunden haben mit welchen Paketen es geht oder nicht geht usw. kommt schon das will das niemand freiwillig.
Wie gesagt bin Pro Linux, aber es ist noch so Benutzer unfreundlich, das es mir den Spaß nimmt, möchte abends auch mal nur Spaß haben am PC und keine Probleme lösen. Das mache ich schon genug auf Arbeit.
Einfach nicht verwirren lassen. Tatsächlich kann man die meisten Empfehlungen von Distris für Neueinsteiger und fürs Gaming an einer Hand abzählen, das ist also übersichtlich. Ja, in der Theorie gibt es Hunderte an Distributionen, aber nur ein paar sind qualitativ, gut unterstützt, bekannt/populär, aktuell, sicher und stabil.
Als Distro wird Einsteigern typischerweise empfohlen: Mint, Ubuntu oder Fedora. SteamOS setzt auf Arch auf, Arch ist zwar eine sehr gute Distri, aber als "Do It Yourself"-Distri trotzdem nicht empfehlenswert für Einsteiger, es sei denn man hat das passende Mindset für eine solche Distri.
Fast noch wichtiger als die Distro ist die Wahl der Desktop-Umgebung, aber auch hier ist es übersichtlich: als Windows-Umsteiger will man sehr wahrscheinlich zuerst mal mit KDE Plasma oder Cinnamon starten, weil die halt einem Windows-Desktop am Ähnlichsten sind. SteamOS verwendet auch KDE Plasma.
Mit der Einstellung hattest du dann aber auch die falsche Distri. Arch ist nicht gedacht für Menschen, die nicht ab und zu etwas "fummeln" wollen am System. Arch ist und bleibt ein bisschen "Do It Yourself". Deshalb empfehle ich es auch nie für Neueinsteiger, es sei denn ich weiß schon, dass sie das richtige "Mindset" für die Distri haben. Da gibt es andere Distris, die für die meisten User "komfortabler" sind. Fedora ist empfehlenswert für User, die Arch genutzt hatten aber dann doch etwas mit etwas mehr "Komfort" haben wollen.
Wenn du es damals unter Arch richtig gemacht hättest (richtige Paket- + Kernelversionen), hätte deine 7900XTX keinen Blackscreen gebracht sondern wäre zumindest Day 1 nutzbar gewesen. Ja, die Standard-Archpakete waren damals zu alt für die 7900XTX in Day 1 (Kernel, Mesa und LLVM-Libs war zu alt), aber es gab trotzdem schon aktualisierte Pakete. Hättest du halt nutzen müssen damals. Inzwischen ja kein Problem mehr. Ich persönlich hatte dann noch mit dem berühmt-berüchtigten "amdgpu ring gfx timeout" zu kämpfen bei einigen Spielen (vieles lief aber auch schon Day 1), wobei dieser Bug auch sehr inkonsistent ist und auch teilweise nur bei bestimmten GPU-Modellen auftritt und bei anderen nicht, aber durch weitere Updates von den ganzen Treibern und Paketen wurden die Probleme im Laufe der Wochen/Monate immer geringer und heute läuft jedes Spiel was ich auf die 7900XTX werfe, problemlos unter Arch.