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.
BerichtLinux-Gaming: Mit welcher Distribution laufen Windows-Games am besten?
Eine Frage am Rande. Bin gerade über einen Performance-Vergleich zwischen Mesa und AMDs eigener OpenGL Implementation gestolpert, wobei beide auf den amdgpu kernel-driver arbeiten:
Immernoch so, Mesa mit amdgpu ist der offiziell sinnvolle Weg, wenn man mit AMD Graka spielen will.
RadeonSI hab ich nie gehört, gibt es also wohl nicht mehr?
Es ist halt etwas verwirrend weil umgangssprachlich immer viele Dinge in einen Topf geworfen werden.
RadeonSI = der OpenGL- (und OpenCL aber naja wir vereinfachen auch lieber noch etwas) Treiber in Mesa (Mesa ist ja letztendlich ein Treiber-Paket für Vulkan, OpenGL, VA-API und noch mehr APIs) für moderne AMD-GPUs (aber nicht nujr für AMD-GPUs). Also alles andere als "gibt's nicht mehr" - allerdings ist OpenGL heutzutage nicht mehr relevant für Spiele, deshalb hört man davon auch eher weniger. Die meisten setzen ja auf Vulkan oder Direct3D schon seit geraumer Zeit (und Direct3D wirtd unter Linux nach Vulkan übersetzt) und dafür ist dann der RADV-Treiber in Mesa zuständig. Aber gerade ältere Spiele könnten noch OpenGL benutzen.
Also ja, wenn man eine AMD-Grafikkarte hat dann sollte man AMDGPU als Kerneltreiber benutzen und Mesa im Userspace, wobei das dann RADV enthält für Vulkan und RadeonSI für OpenGL.
Es gibt auch noch andere Userspace-Treiber, z.B. AMDVLK, was eine Alternative zu RADV wäre. RADV ist eigentlich ein inoffizieller Vulkan-Treiber für AMD GPUs, aber da hier Valve, Red Hat, Google und noch andere namhafte Entitäten dran arbeiten, ist RADV inzwischen besser geworden als der "offizielle" Open Source Vulkan-Treiber von AMD selbst (AMDVLK). (Auch irgendwie ein schönes Beispiel, wie sinnvoll Open Source ist, denn durch die "natürliche Konkurrenz" die dadurch entsteht (weil jeder dran arbeiten kann) können Projekte noch besser werden als der Hersteller es selbst hinbekommt.)
Als User muss man eigentlich gar nix beachten, denn AMDGPU + Mesa/RADV/RadeonSI sollte alles standardmäßig aktiv sein wenn man eine nicht uralte AMD-GPU hat. Man könnte aktiv werden und bspw. anstatt RADV den AMDVLK benutzen (als Vulkan-Treiber), aber dann hätte man es wahrscheinlich schlechter (für Spiele) dadurch.
Das was ich jetzt geschrieben habe ist auch vereinfacht, aber vielleicht hilft es ja wem bei den ganzen ewig vielen Begrifflichkeiten.
Ergänzung ()
netzgestaltung schrieb:
Keine der Pakete die ich installiere werden von den Software Erstellern maintained. Dafür ist der Distributor der Distro oder des Repos verantwortlich. Das ist für mich die standard Situation. Deswegen sehe ich nicht, welcher Art die Verbesserung in AUR sein soll und was "offiziell" in dem Zusammenhang bringen soll(außer Marketing bei weniger Arbeit für die ARCH Maintainer).
Ja, es ist meistens sogar positiv, würde ich sagen, wenn nicht der Entwickler selbst der Paket-Maintainer ist. Denn normalerweise ist es wegen der vielen Linux-Distris so, dass ein Entwickler gar nicht alles perfekt anpassen kann auf alle Distris, d.h. bei manchen (insb. bei denen, die der Entwickler nicht selbst nutzt oder testet) wird das Paket vom Entwickler dann weniger qualitativ sein, als wenn der Distributor sich den Quellcode des Entwicklers schnappt und daraus ein perfekt angepasstes Paket für die jeweilige Distri baut.
Allerdings gibt es natürlich auch Fälle, wo genau das ein Problem ist, denn auch die Paket-Maintainer in den Distributionen sind nur Menschen und Menschen machen Fehler, und manchmal kommt es vor dass der Entwickler bei der Paketerstellung einen besseren Job macht als die Distris. Aber ich würde sagen das ist eher selten der Fall. Oder zumindest wird es selten zu einem Problem, wenn Distris es tun. Es gibt aber ein paar bekannte, reichweitenstarke Projekte wie Bottles oder OBS, wo die Entwickler davon abraten, Distro-spezifische Pakete zu benutzen, und lieber bspw. das Flatpak zu benutzen. Es könnte aber auch nur deshalb sein, weil sie keine Lust haben, mehrere Pakete/Distris zu supporten und lieber nur Support für eine Version/Variante geben wollen. Dann ist die Umgebung kontrollierter.
Hatte echt versucht, mir das selbst zusammenzulesen - aber ohne so einen groben Gesamtüberblick verliert man sich sehr schnell zwischen den ganzen Codenamen und Abkürzungen ...
Dann gabs da noch dri und drm ... kannst du das bitte noch kurz einordnen?
DRM = Direct Rendering Manager (in diesem Kontext), das ist sozusagen der hardware*un*abhängige Grafik-Kern im Linux-Kernel. DRM ist also immer da und funktioniert immer gleich. Und dazu braucht es dann noch einen hardwareabhängigen Kernel-Treiber wie amdgpu, das ist sozusagen dann das Puzzleteil damit der DRM mit der verbauten Grafikhardware sprechen kann - der Teil ist logischerweise immer anders je nach Grafikkarte. KMS und FB gibt es dann auch noch, das sind auch Teile im DRM die halt bestimmte Aufgaben haben.
DRI ist alles zusammen sozusagen (Direct Rendering Infrastructure). Das ist alles Kernel-Level! Also normalerweise nicht allzu relevant für User. Die müssen eigentlich nur dafür sorgen dass der richtige hardwareabhängige Kernel-Grafiktreiber geladen ist, der Rest ist alles Low-Level-Grafikinfrastruktur im Kernel.
Eine Applikation oder ein Spiel redet aber nie direkt mit dem Kernel-Zeug sondern das geht immer über verschiedene Libraries, und die Libraries reden dann am Ende der Kette mit dem DRM im Kernel.
Für Vulkan, OpenGL oder so, was User dann eher interessiert, braucht man dazu noch die Userspace-Treibersammlungen wie Mesa oder "den proprietären Nvidia-Treiber" was quasi ein Äquivalent zu Mesa ist, nur halt proprietär von Nvidia, also da sind deren closed source OpenGL/Vulkan/...-Treiber drin. Plus dass "der Nvidia-Treiber" dann neben diesen Treibern auch noch den Kerneltreiber mitbringt, der ebenfalls proprietär ist, oder zumindest größtenteils. Mesa hat neuerdings aber auch den NVK mit an Board, ein Open Source Vulkan-Treiber für Nvidia-GPUs der konkurrenzfähig werden könnte zum proprietären von NVidia, und NVidia arbeitet momentan auch an dem mit. Es könnte also doch noch die Hölle zufrieren und zumindest der könnte Open Source und Teil von Mesa werden. Vielleicht switcht NVidia auch alles auf Open Source Treiber um. Heutzutage kann ja alles passieren irgendwie. Sehr wahrscheinlich hängt das aber nicht mit Nächstenliebe zusammen, insb. nicht bei NVidia, sondern eher mit Kosteneinsparungen -- wenn Firmen auch nur einen Teil der Arbeit an die Open Source Community auslagern können, sparen sie In-House-Entwicklungskosten.
https://piped.video/watch?v=K9khdYpMI5s ist noch empfehlenswert zu schauen (man braucht nur die ersten 10-15min zu sehen, der Rest ist unwichtig) wenn man die APIs und Libraries die beim Spielen unter Linux benutzt werden, besser verstehen will. Das ist dann aber alles Userspace und somit näher am User bzw. an den Applikationen/Spielen dran. Am Ende der langen Kette reden diese Komponenten natürlich alle mit dem DRM im Kernel um dann die Pixel auch auf der Hardware anzuzeigen aber da sind halt viele Softwareschichten dazwischen die alle einen Teil vom Gesamt-Job machen.
Kann denn mal jemand seine Erfahrungen mit Nobara teilen?
Was macht den die Distribution aus? Kommt hier viel von Fedora mit und was ist deren Philosophie?
ich hab jetzt ne weile Nobara im einsatz zocke aber nicht so häufig.
Gut ist das sehr vieles mitkommt was man zum spielen braucht und man nichts nachinstallieren muss. Nachteil es ist viel installiert, ach was!? ^^
Ansonsten bin ich nicht so zufrieden, weil es einfach ne Kleinstdistro ist ohne richtigen Support... der ist eben nicht möglich. Mit meiner letzten installation hatte ich das Problem das nach jeden Update Grub irgendwie verkonfiguriert wurde, sodass die config file beim booten nicht mehr gefunden werden konnte, gab ne Erklärung und ne Anleitung zum fix. Der fix hat dann aber nur bis zum nächsten Update gehalten. Hab dann ne Neuinstallation gemacht und seit dem läuft das auch wieder.
Nobara 40 aufbauend auf Fedora 40 (release April) kam jetzt auch erst vor 5 Tagen.
Für mich persönlich und jeden der lieber "Konsolenfeeling" haben möchte, also an und los, würde ichs jetzt nicht mehr empfehlen, aber deswegen hab ich auch ausprobiert. Wenn ich jetzt neu installieren müsste würde ich es mit https://bazzite.gg/ probieren mit der Hoffnung nie wieder Probleme zu haben ^^
Aber mal schauen evtl. wird das mit Nobara noch größer und besser
Ich habe dann auch mal wieder einen Versuch gewagt, nachdem ich mir mein Win11 zerschossen habe, weil mir das Tracking auf den Kecks ging. Habe so einige Distros getestet (Voyager, Nobara, LMDE6, Pop_OS 24.04. Alpha, Linux Mint). Im Endeffekt bin ich wieder bei Pop_OS hängen geblieben, läuft einfach rund. Voyager fand ich optisch erfrischend, aber sogar in der Minimal-Installation wurden zig Spiele installiert, die ich nicht haben wollte.
So, ich konnte dann doch nicht an mich halten und habe mir Black Myth: Wukong zugelegt. Sehr geiles Spiel. Läuft auch sauber auf meiner HW und Linux. Für das Spiel wird ein Controller empfohlen. Kein Problem dachte ich, habe ja noch einen XBox Elite Controller hier liegen. Aber denkste Puppe. Der BT-Dongle funktiert glaub ich schon lange nicht mehr, zumindest kann ich den Controller nicht damit koppeln. Per USB-Kabel konnte ich den XBox Controller auch nicht mit dem System verheiraten. Im Netz stehen viele How-To's aber nicht wirklich für den Elitecontroller.
Ok, dann direkt per BT mit dem System verbinden. Aber denkste. BT ließ sich nicht einschalten. Zig How-To's durchgekaut, nichts half. Dann dachte ich: ggfls. liegst am Pop-OS. Andere Live-Distro angeschmissen. Wieder kein BT.
Handbuch vom Mobo geschnappt: Intel-Kombi-Kontroller WLAN/BT. Sollte also passen, da WLAN funktionierte. Wieder ins Bios. WLAN-Controller steht auf Auto. Unter WIndows funktionierte BT und WLAN problemlos.
Folgende Auswahl war gegeben:
Auto
BT only
WLAN only
BT off
Also, LAN-Kabel rauskramen, BT only einstellen und läuft......
Parallel habe ich mir dann ein PS5-Controller bestellt, der sollte dann (hoffentlich) besser mit LINUX funktionieren.
Eigentlich funktionieren die XBox-Gamepads OotB mit Linux, zumindset im Kabelbetrieb. Hab hier ein paar Knock-Offs rumliegen, alles kein Problem, von daher geh ich davon aus, dass die Originale sich genauso verhalten sollten.
Es gab zwar eine Rückmeldung beim Anstecken vom Motor, aber die Tasten hatten keine Funktion. Und im Netz wird immer nur vom XBox und XBox ONE Controller gesprochen. Da Sony den Linux-Treiber für seinen PS5 Controller unterstützt hat, gehe ich von einer besseren Kompatibilität aus.
Mein Google-Stadia Controller wird per USB-Anschluss unter Linux auch ootb erkannt & funktioniert.
Xbox-Controller sowieso. Der Elite hat halt Sonderfunktionen & ggf. anderen Chip verbaut. Da kann es sein, dass sich keiner von den Linux-Programmiern gefunden hat, einen Treiber dafür zu schreiben bzw. dass dieser es nicht in den Kernel geschafft hat. Es könnte also ein Xbox-Elite Treiber auf Github/Gitlab o.s.ä. geben.
P.S.2
Ich kann ansonsten den "Google Stadia Controller" empfehlen. Gibt's sehr preisgünstig (& preiswert!) gebraucht. Dieser hat die gleiche Anordnung der Sticks wie bei PS (dafür allerdings Xbox-Buttons).
Das Witzige ist ja, nachdem ich WLAN deaktivert hatte lief BT. Dann konnte ich auch alle BT-Geräte in der Nähe sehen. Dabei fiel mir ein: meine Bose Kopfhörer waren doch die ganze Zeit schon gekoppelt. Jetzt habe ich wieder auf WLAN+BT (also Auto-Einstellungen im Bios) umgestellt und alles läuft trotzdem weiter.
Der PS5 Controller wird sowohl per USB als auch per BT erkannt und funktioniert ohne Probleme unter Steam.
Nur die Tastenbelegung im Spiel wird mir wie beim MS Controller angezeigt (X, Y, ...) das irritiert etwas.
Der MS Elite Controller funktionierte unter MS bei mir nur mittels USB. Per BT nur mit dem Extra Dongle, der aber schon eine Weile nicht mehr funktionierte.
