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.
NewsSpielen unter Linux: Mesa 22.3.0 bringt Support für RDNA 3 in den Vulkan-Treiber
Und ein Mesa Update ist anscheinend nicht so simpel wie die Installation des Windows Treibers, muss ich nun darauf warten das Pop OS ein Update anbietet?
Es kommt immer darauf an welche Distribution man verwendet. Das heißt welche Treiber in der Distribution verwendet werden. Und wie der Update-Mechanismus funktioniert.
Bei einer Rolling-Release-Distribution werden die aktuellen Treiber wie alles andere auch ausgerollt. Wenn sie fertig sind kommen sie halt ins Paket und gut ist.
FSR kannst du in Linux tatsächlich sehr einfach in jedem Spiel aktivieren, egal ob es von den Entwicklern implementiert wurde. In Steam z.b. mit der Launch Option "WINE_FULLSCREEN_FSR=1" und in Lutris mit der Environment Variable "WINE_FULLSCREEN_FSR 1".
Danke, wie gesagt ich bin Linux-Neuling und war einfach sehr verwundert, darüber dass es im Grunde kein Treibermenü auf Linux gibt. Habe die Tools hier jetzt alle mal durchgesehen und das Meiste ist wohl möglich. Für AMD-Chill habe ich aber leider noch nichts gefunden, gibt es da etwas? Ich fand die Funktion auf Windows immer spitze, weil man so erstens verhindert, dass die GPU in irgendwelchen Ladescreens 3000FPS produziert, die GPU kühler bleibt und wohl auch weniger Strom verbraucht. Wäre toll wenn man das auch auf Linux irgendwie nutzen könnte.
Du könntest die FPS direkt per DXVK (bei DX11-Spielen) oder per MangoHUD begrenzen.
Chill als solches ist mir für Linux nicht bekannt. Kann aber sein, dass irgend jemand ein Tool dafür entwickelt hat. Also bitte auch selbst recherchieren, wenn es Dir wichtig ist.
Ansonsten könntest Du natürlich auch den proprietären AMD-Treiber installieren & nutzen.
Was dieser in der Linux-Version implementiert hat, weiß ich nicht. Früher gab's da auch Probleme bei einem Kernel-Update. Dann ging der Xorg/X11 nicht mehr und man schaute in die schwarze Röhre. 😜
Dies kann sich über die Jahre/Jahrzehnte aber auch verbessert haben.
Edit:
Mit CoreCtrl kannst Du auch noch einiges an der GPU einstellen.
Es gibt dort ein Globales Profil und natürlich können auch eigene Profile angelegt werden.
Mir ist kein Programm bekannt das eine dynamische Anpassung „in Game“ ermöglicht.
AMD selbst stellt kein Frontend zur Verfügung, alternative Tools ermöglichen eine statische Begrenzung, corectrl (Undervolting, Powertarget, Lüfterkurve etc.) ist hier einen Blick wert und eben mangoHUD (fps).
Ich hatte vorher einige Gaming Notebooks mit 9800m gts, 660m GTX von Nvidia. Bei Grafikkarten brauchen manuelle Anpassungen bei jedem Linux Kernel compilieren. Ansonsten geht es. Ansonsten hat man keine Bildausgabe und immer keine Beschleunigung. Hat mit dem GrafikkartenBios zu tun und der mangelhaften Qualität der Binär Nvidia-Treiber für gnu linux. Die Windows Treiber sind auch mangelhafter als die AMD Treiber für eine 6600 XT in meinem Fall.
Ich habe immer fast nur in Gnu linux gespielt. die fps sind um einiges besser mit steam und windows für die Nvidia gpus in den spielen die free to play waren. die nvidia binärtreiber für gnu linux liefern nur um die ~35 fps für star conflict zu dem Zeitpunkt. In Windows war ich weit über 60 fps mit besserer Bildqualität.
amd seite: mit der ati x700 kann ich leider nichts mehr dazu sagen. Die 6600 XT läuft um einiges problemloser und besser in gnu linux. Windows 10 pro hat es geschafft mit ~ 6x neustarten mir den AMD gpu treiber zu zerschiessen mit den automatischen windows updates. obwohl der neueste amd gpu treiber zu diesem zeitpunkt in windows 10 pro installiert war. Ich hatte zwar eine Bildausgabe aber die Gaming Performance war nicht mehr vorhanden. Die 6600 XT hat ausreichend Reserven. Ich habe derzeit nichts wie ich es unter GNU Linux die Gaming Performance testen kann. Urban Terror läuft flüssig - läuft aber auf einer low performance 660M auch performant. Also kein Benchmark.
Ergänzung ()
SVΞN schrieb:
Neben Mesa, Vulkan, DXVK, Wine und Proton sind insbesondere die Grafiktreiber der Schlüssel zum Spielen unter Linux.
Hier macht einem der offene AMD-Grafiktreiber das Leben natürlich bedeutend einfacher.
Es gibt ein meherere GB großes Packet für diverse Hardware wie Netzwerkkarten usw wo auch die Radeon GPUS wie 6600 XT dabei sind. Ohne diese läuft es nicht!
Quelloffen ist bei mir etwas anderes. AMD 6600 XT ist positiver als NVIDIA oder INTEL GPUs in GNU Linux. Zu dem Zeitpunkt des Erwerbs 6600 XT, siehe meine ersten Posts diesbezüglich, war es eine Raterei wie eine AMD 6600 XT GPU "anzusteuern" ist in gnu linux. Es gab seitens AMD keine Dokumentation für die 6600 XT. Es gab auch keine Dokumentation seitens gentoo gnu linux oder seitens arch gnu linux. (Die restlichen Distros sind nicht wirklich wert zu schauen da sie für mich kein wirkliches hintergrundwissen bisher hatten bei anderen fragen, z.b. ubuntu, linux mint, usw.) Für mich ist der AMD Treiber für die 6600XT für gnu linux nicht quelloffen, wenn ich mir alle Einstellungen zusammensuchen muss. Der "quell-offene" Teil und der Teil im Linux Kernel + vermutlich "gnu" mesa Teil ist ein Flickwerk von diversen älteren Grafikkarten Produkten. Dieser Teil hat Abhängigkeiten zu älteren AMD bzw. ATI Grafikprodukten. Sauber programmiert ist es nicht, weil es gab keine Hinweise und diese Abhängigkeiten kann man besser dokumentieren. In der Zwischenzeit hat die Gentoo Wiki dies etwas nachgeholt.
--
Quelloffen ist wirklich jeglicher Source Code inklusive jeglicher Hardware internals und inklusive aller Datenblätter. Ich sehe es so, in meiner persönlichen Meinung und Verständnis, dass der Begriff Quellofffen falsch verwendet wird.
--
Ich bin auch der Meinung welches nur Personen welches Gnu Linux zumindest zu 75 Prozent privat verwenden am Rechner nur diese Fach-Themen beantworten sollten. Nur irgendein Binär Linux wie ubuntu, mint intalliert zu haben vermittelt recht wenig vom hintergrundwissen welches wichtig ist.
Ergänzung ()
Replay86 schrieb:
Bei 2,8% Linux User weltweit davon spielen sagen wir mal die Hälfte ist das ein Verlust für Nvidia, mit denen die, denke ich, gut leben können.
Ich meide Intel wie die Pest. Ich verwende über 90 % Prozent privat Gnu linux seit 1998. Da ich bis auf ein AMD Notebook und diesen AMD Desktop-Rechner fast nur INTEL Produkte hatte, kann ich dies sehr gut beurteilen!
Ich hatte nur intel notebooks mit gnu linux. Dass war der Grund warum ich mir kein Intel mehr privat gekauft habe. Leider gab es hier eine Fehlberatung bezüglich des Mainboards B550 Gaming Edge Wifi von MSI. Das WLAN Modul ist scheinbar mit USB angebunden. Das Wlan ist fehlerhaft implementiert bei meinem Mainboard. Das Wlan schmiert regelmässig ab und muss öfters regelmässig neu initialisiert werden bei Boot Vorgängen. Ob es so gut und professionell ist den Rechner öfters neu zu starten bei einer Brot und Butter WLAN Chip von Intel? Ist kein Exot - sehr häufig und sehr hohe verkaufte Stückzahlen dieser WLAN Chips von Intel.
bugs.kernel.org ist nicht wirklich hilfreich wenn man wlan probleme einmeldet. Dort sitzen auch Leute von Intel. Helfen im Grunde gar nicht und Fehler wurden nicht behoben. Diese sind nach über 1 Jahr immer noch vorhanden. Da das Mainboard uralt ist, behaupte ich mal, diese Probleme exisiteren seit mindestens 3 Jahre.
Intel gpu probleme. bugs.kernel.org ist nicht wirklich hilfreich. Diesel Intel GPU Probleme wo teilweise O365 apps nicht aktualisiert werden bzw. das Bild einfrieren sehe ich mit Windows 10 pro auch in einer domäne mit verschiedenen Intel Generationen. Ist also nicht nur Gnu linux spezifisch welches intel gpus tunlichst zu vermeiden sind. Probleme mit 2d Rendering mit low performance desktops.
intel - notebook bios bugs + intel chipset bugs + intel cpu bugs. Im Grunde ist für mich ASUS und Intel Schuld. Intel gibt vor wie das Bios zu sein hat mit den Microcodes. Dass es fehlerhaft ist, ist das Ergebnis auf meiner Seite. Leider nicht nach Spezfikation und Standard implementiert. Alles voller Fehler - kann man etwas ausbessern - bringt aber leider nichts - da es Fehlerhafte Intel basierte Intel CPUs und Intel Gpus Notebooks sind.
Es gibt ein meherere GB großes Packet für diverse Hardware wie Netzwerkkarten usw wo auch die Radeon GPUS wie 6600 XT dabei sind. Ohne diese läuft es nicht!
./amdgpu/
Die notwendigen Binärblobs für Navi sind in Summe unter 500kB groß und Bestandteil vom offiziellen Kernelrelease. Wenn du da "blind" irgendwelche Pakete mit Blobs in Größenordnungen von Gigabyte ziehst, liegt das nicht in der Verantwortung von AMD.
Das klingt eher danach, dass du durch wildes Installieren irgendwann die ganzen Abhängigkeiten des Mesa-Stacks unbewusst mitinstalliert hast und es dadurch lief. Da braucht es dann aber auch keinen Seitenhieb auf Nutzerinnen von Ubuntu
Und "wirklich quelloffen", den Anspruch haben glaube nur Wenige. Solang alle notwendigen Komponenten für den stabilen und performanten Betrieb im Kernel/Mesa sind, sind die Meisten sehr glücklich. Bei AMD ist das derzeit gegeben, solang man den Teil Compute ignoriert.
Als jemand der gerne AMD unter Linux für genau die genannten Data Science Use-Cases beruflich nutzen würde:
Es ist zum Kotzen. Selbst wenn man sich den Stress gibt (was ich privat gemacht habe) den ganzen rocm-Stack zu kompilieren, funktionieren PyTorch und Tensorflow nicht hundertprozentig (Vega56). Ebenso lässt die Geschwindigkeit ggü. vergleichbaren NV-Karten bei aktuelleren Karten stark zu wünschen übrig, wenn es denn überhaupt läuft. Die Profikarten kriegt man nicht von der Firma bezahlt weil die (völlig zu recht) sagt, dass es für weniger Geld ja die Option NVidia-Consumerkarten gibt, bei der auch nichts kompiliert werden muss, sondern schon fertig paketiert im Repo liegt.
Am Ende gibt es leider aktuell zero Gründe auf AMD zu setzen wenn man nicht gerade sehr gut skalierende Anwendungen auf die Profikarten auf CDNA-Basis maßschneidert, was aber nur HPC-Anwendungen sind.
AMD haben da einfach sehr sehr lange gepennt und NVidia beherrscht aktuell den Markt abseits von HPC sehr deutlich. Sehr schade.
Und ein Mesa Update ist anscheinend nicht so simpel wie die Installation des Windows Treibers, muss ich nun darauf warten das Pop OS ein Update anbietet?
Mesa ist Teil des Betriebssystems und du hast dich für eines entschieden, dass bei der Aktualität ständig hinterher hinkt, aber Anthony von Linus Tech Tips emphiehlt das halt immer. Valve selbst empfiehlt seit einiger Zeit Manjaro für PCs, die nicht Steam Deck sind, aufgrund der technologischen Nähe zu SteamOS 3.x. Persönlich bin ich außerhalb des Decks eher mit Fedora und openSUSE Tumbleweed unterwegs, aber auch wenn Fedora im Schnitt schneller aktualisiert als Ubuntu und Derivate wie pop_OS, muss man bei manchen Komponenten trotzdem bis zum nächsten Fedora-Release warten, ist also für diesen konkreten Fall schneller Mesa-Updates auch nicht uneingeschränkt zu empfehlen.
Nichts tut bei NVidia out of the box, alleine schon weil der Treiber derzeit rechtlich gar nicht in der Box sein kann und nachträglich installiert werden muss. Man macht das bloß notgedrungen direkt nach der Linux-Installation, weil man sonst nur lahmes Software Rendering hat.
Wie gut oder schlecht GPGPU out of the box mit Radeon-GPUs geht, hängt halt vom OS-Anbieter ab. Vor 'nem halben Jahr wurde bei Fedora noch dran gearbeitet: https://www.phoronix.com/news/Fedora-ROCm-April-2022. Den aktuellen Stand kenne ich nicht. Da ist's natürlich an der Nutzerschaft zu signalisieren, dass Bedarf da ist, GPGPU-Kram in die Standard-Repos mit aufzunehmen und halt von selbst als Abhängigkeit mit installiert wird, wenn man entsprechende Software installiert.
Support nachträglich über die Pakete von AMD selbst zu installieren geht natürlich auch, aber nachträglich installieren ist auch das, was man bei NVidia-Treibern machen muss.
Die Verantwortung benötigst Du, wenn der Paketmanager "apt" Fehler bei Updates anzeigt.
Meist sind diese ganz einfach zu beheben ... oder ein geduldiges Warten, bis alle zu MESA gehörenden Pakete+Abhängigkeiten in den nächsten Stunden/Tagen in den PPA-Repos verfügbar sind.
In Spielen hatte ich (vermutlich!) keine Probleme mit dem neuesten Mesa-Stack.
Jedenfalls hatte ich bisher keine offensichtlichen Fehler wahrgenommen bzw. erkannt.
Da Pop!_OS auch (anders als Ubuntu) oft neuere Kernel zur Verfügung stellt, ist das zusätzlich entspannter.
Man kann hiermit also ein ziemlich aktuelles System haben, ohne direkt ein Rolling Release nutzen zu müssen.
AMD hat nicht gepennt. Sie hatten schlicht und einfach kein Budget in der Phase als Nvidia Cuda zur dominierenden GPGPU-API gemacht hat.
Ich finde es viel frustrierender, dass sich die APUs nur für Games nutzen lassen. AMD hat HSA implementiert, aber keinen Softwaresupport bereitgestellt. Somit liegt die GPU der APU bei der Anwendungssoftware brach.
ROCm war die Wette wenigstens in HPC Fuß zu fassen. Das ist aufgegangen. Ich hätte allerdings erwartet, dass sich 2022 mehr tut in Richtung ROCm einfacher auszurollen und HIP breiter verfügbar zu machen.
Aber grundsätzlich sollte man beachten, dass die AMD Gaming GPUs bei GPGPU bisher nicht mit Nvidia mithalten können. Vega ist in die Jahre gekommen. RDNA 1 und RDNA 2 sind auf Rendering Workloads optimiert worden. Sie können mit relativ wenig Rechenleistung viele Frames herausholen. Aber wenn man die Rechenleistung nutzen will, fällt der große Unterschied zwischen RDNA2 und Ampere auf.
Für mich ist die entscheidende Frage was stellt AMD für die AIE in Phoenix Point und Zen 5 bereit. Ohne Softwareunterstützung wird die AIE bei allem Potential nur totes Silizium bleiben. So wie die GPU bei Anwendungssoftware.
Wölkchen schrieb:
Nichts tut bei NVidia out of the box, alleine schon weil der Treiber derzeit rechtlich gar nicht in der Box sein kann und nachträglich installiert werden muss.
Okay, guter Punkt. Es macht es aber leider kein Bisschen weniger frustrierend :/
Und es wundert mich auch, denn für ziemlich viele Sachen war Geld da … und dass HPC auf GPU ein Ding ist bei dem sie über lange Zeit gut hätten mitspielen können zeigte ja auch schon die Vega-Architektur. Bzw. sie haben es damit auch versucht … aber der Softwarestack war echt um Längen hinter dem von NV hinterher 8(
ETI1120 schrieb:
Ich finde es viel frustrierender, dass sich die APUs nur für Games nutzen lassen. AMD hat HSA implementiert, aber keinen Softwaresupport bereitgestellt. Somit liegt die GPU der APU bei der Anwendungssoftware brach.
100% Zustimmung. Es wäre so schön einfach ein paar Sachen auch auf APUs auf prinzipielle Lauffähigkeit testen zu können. Damit könnte man auf Laptops sehr viel besser arbeiten und müsste nicht direkt für jeden Mist auf AWS/EC2 … oder einen Laptop mit CUDA-fähiger Graka kaufen. @Tanzmusikus Ich denke es ist v.a. der DataScience-DeepLearning-Kram gemeint? Zumindest verstehe ich es so. Solange da grundlegende Libraries nicht auf die APU/GPU zugreifen, sind die Dinger nur halb so wertvoll wie sie sein könnten.
ETI1120 schrieb:
ROCm war die Wette wenigstens in HPC Fuß zu fassen. Das ist aufgegangen. Ich hätte allerdings erwartet, dass sich 2022 mehr tut in Richtung ROCm einfacher auszurollen und HIP breiter verfügbar zu machen.
ROCm/HIP: Jo. Es wäre ja schon extrem viel damit gewonnen gewesen wenn man konstant fertige Pakete für Ubuntu, Redhat, SUSE und kompilierbaren Code für die anderen Distris gehabt hätte. Und zwar einfach nur für Tensorflow und PyTorch. Fast alles baut irgendwie auf Tensorflow und PyTorch auf. Okay, das ist auch etwas übertrieben, aber es wäre halt schon echt viel damit gewonnen gewesen. Zusätzliche Beschleunigung für andere Libraries wäre da echt nur noch Bonus.
ETI1120 schrieb:
Aber grundsätzlich sollte man beachten, dass die AMD Gaming GPUs bei GPGPU bisher nicht mit Nvidia mithalten können. Vega ist in die Jahre gekommen. RDNA 1 und RDNA 2 sind auf Rendering Workloads optimiert worden. Sie können mit relativ wenig Rechenleistung viele Frames herausholen. Aber wenn man die Rechenleistung nutzen will, fällt der große Unterschied zwischen RDNA2 und Ampere auf.
Das meinte ich ja oben. Es gibt einfach keine Brücke für engagierte Amateure wie bei NV wo man mit den Consumergeräten schon was richtig brauchbares in der Hand hat. Und wenn es das dann gäbe, würde auffallen wie ineffizient RDNA für solche Workloads ist. Der "dual use" der NV-Architekturen ist schon ein Riesenvorteil.
Ich würde es sehr begrüßen mit AMD eine Alternative zu haben. Allein schon weil sie seit 2007/8 so viel für das OpenSourcing von Treibern unter Linux getan haben … aber es bleibt noch sehr viel aufzuholen für sie.
ETI1120 schrieb:
Für mich ist die entscheidende Frage was stellt AMD für die AIE in Phoenix Point und Zen 5 bereit. Ohne Softwareunterstützung wird die AIE bei allem Potential nur totes Silizium bleiben. So wie die GPU bei Anwendungssoftware.
Ja, da warte ich auch gespannt drauf für meinen nächsten Laptop. Am Ende müssen sie, um mich glücklich zu machen, "nur" Matrizenmultiplikation sehr effizient in Hardware gießen. Und idealerweise alle anderen LA-Grundfunktionen. Was AI halt letztlich auch nur ist.
AMD hatte über Jahre auf HSA gesetzt, musste aber erkennen, dass es ohne Softwarestack nicht geht. Deshalb kam 2015 die Umorientierung auf ROCm und HPC. Kern von ROCm ist HIP. Der zweite Teil der Erkenntnis war, dass es mit OpenCL nicht funktionieren wird.
Vega war der erste Schritt in Richtung HPC, aber mit Nvidia konnte Vega nicht wirklich mithalten. Während das R&D-Budget von Nvidia immer weiter ausgeweitet wurde, ist es bei AMD geschrumpft.
usbstick schrieb:
Und wenn es das dann gäbe, würde auffallen wie ineffizient RDNA für solche Workloads ist.
Je nach dem wie man es nutzt.
Wenn man es nicht nutzt ist es verschwendetes Silizium.
Mit RDNA 3 wird sich die Situation eventuell bessern, je nach dem wie viel von der theoretischen Performance im GPGPU tatsächlich auf die Piste kommt
AMD wird in Jahr 2023 für GPU und AI 3 Architekturen haben:
RDNA fürs Rendering
CDNA für GPGPU und auch für AI
Hier wird man sehen in wie weit CDNA 3 für AI erweitert wird. CDNA 2 wurde für FP 64 ausgelegt.
XDNA für AI
Die AIE wird außerdem in einige AMD-Prozessoren einfließen
usbstick schrieb:
Ich würde es sehr begrüßen mit AMD eine Alternative zu haben. Allein schon weil sie seit 2007/8 so viel für das OpenSourcing von Treibern unter Linux getan haben … aber es bleibt noch sehr viel aufzuholen für sie.
Darüber braucht man nicht zu diskutieren. Ich hätte mir für 2022 mehr versprochen.
Aber wie es aussieht steht GPGPU außerhalb HPC nicht oben auf der Prioliste. Ich würde mich interessieren wie der AI-Softwarestack vorankommt, der auf dem Financial Analyst Day angekündigt wurde.
usbstick schrieb:
Ja, da warte ich auch gespannt drauf für meinen nächsten Laptop. Am Ende müssen sie, um mich glücklich zu machen, "nur" Matrizenmultiplikation sehr effizient in Hardware gießen. Und idealerweise alle anderen LA-Grundfunktionen. Was AI halt letztlich auch nur ist.
Die AIE wurde von Xilinx speziell für AI ausgelegt. Ich gehe davon aus, dass die AIE der Grund war warum AMD Xilinx gekauft hat, und warum Xilinx sich kaufen lies.
Xilinx hatte schlicht nicht die Resourcen und Mittel um mit Nvidia zu konkurrieren. AMD hat die IP gefehlt.
Die Frage ist was AMD 2023 für die AIE in Phoenix Point bereitstellen kann. Nicht nur ob es ein Softwarestack gibt, sondern ob es bereits auch Anwendungen gibt.
Ajo, Vega konnte schon mithalten, nur halt nicht im Grafikbereich.
Das was ich mit der RNDA-Ineffizienz meinte war, dass es halt einigermaßen ausschließt, selbst wenn es einen schönen Softwarestack gäbe, dass man sich die Kunden analog zu NV über die billigen Consumerprodukte angelt. Es gibt sehr wenige Menschen die sich direkt eine Profikarte kaufen. Das sehe ich als einen der Hauptvorteile von NV.
Die Unterscheidung zwischen CDNA und XDNA kannte ich noch nicht … weißt Du da mehr? Denn auf der mathematischen Ebene ist das ja eigentlich alles sehr ähnlich. Da wundert es mich, dass es dafür unterschiedliche Architekturen geben wird. Es dürfte dann ja noch mehr Gründe dafür geben?
Drei Dinge, die für mich noch ziemliche Blocker sind: DSC (Nvidia), HDR und Anticheat Probleme. Ansonsten kann ich es kaum erwarten Linux als mein Haupt-OS zu benutzen und goodbye Windows sagen zu können.
"Anticheat" ist auf einem quelloffenen System mit quelloffenen Treibern konzeptionell unmöglich. Das wird also nie funktionieren können.
Anticheat ist vom Konzept her darauf ausgelegt, daß du an deinem System nichts verändern kannst, um dir beim Online-Spielen keinen Vorteil zu verschaffen.
FOSS verfolgt genau gegenteilige Ziele, die beliebige Anpassung der gesamten Software-Umgebung, in der dein Spiel dann läuft, ist explizit erwünscht und möglich.
Das steht schlicht im Widerspruch.
Ergänzung ()
Hirschschnaps schrieb:
Danke, wie gesagt ich bin Linux-Neuling und war einfach sehr verwundert, darüber dass es im Grunde kein Treibermenü auf Linux gibt.
Widerspruch oder nicht, Lutris z.B. unterstützt AntiCheat seit geraumer Zeit (rudimentär).
Hier liegt es nicht an FOSS oder OSS, sondern an den AC-Herstellern diese Software für Linux bereitzustellen.
AntiCheat wird von Linux nicht in den Kernel aufgenommen - das ist ziemlich sicher.
Es liegt also an den AC-Herstellern z.B. eine User-Space-Variante von AntiCheat bereitzustellen, welche auch aktuelle Spiele nutzen können. Andere DRM-Techniken sind ja auch im User-Space von Linux "erlaubt"/möglich.
Proprietäre Software in binärer Form auf einem Quelloffenen System mit quelloffenen Treibern schließt sich nicht aus. Firmware ist auch nicht quelloffen und wird für jede Menge Geräte unter Linux genutzt, auch von freien Treibern.
Für den OSS AMD Mesa-Treiber gibt es bisher keine graphische Oberfläche - das stimmt.
Beim proprietären AMDGPU- inkl. PRO-Treiber sollte es aber eine GUI geben, wenn mich nicht alles täuscht.
Könnte allgerdings die Crimson- oder Catalyst-Oberfläche sein, falls es nicht schon die Adrenalin-GUI ist.
Vor ca. 8 Jahren war es die Catalyst-GUI, siehe hier:
YouTube
An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.
