News Spielen unter Linux: Mesa 22.3.0 bringt Support für RDNA 3 in den Vulkan-Treiber

[Piktogramm]

@Diablokiller999
Mesa beinhaltet den AMDGPU Treiber, der AMDGPU PRO Treiber ist proprietär.
Es ist aber noch etwas komplizierter. Die Implementierung von OpenGL, Vulkan etc. ist jeweils modular. Bei AMD gibt es zum Beispiel für Vulkan den RADV-Treiber, der großteils von Valve gesponsort wurde und den AMDVLK Treiber von AMD (der wohl Verwandtschaft zum AMD Windowstreiber hat).

Zum Daddeln ist aktuell zu empfehlen auf Mesa AMDGPU zu setzen und RADV zu nutzen.

Ein ähnliches Spiel gibt es dann auch für OpenCL, OpenGL. Wobei das OpenGL Modul von Mesa gerade die beste Kompatibilität und Leistung bietet. Bei OpenCL hingegen braucht es AMDGPU PRO und den RoC-Stack.

 

[Tanzmusikus]

€: Jemand parat wie man unter Arch die Version auslesen kann bzw wo man die aktuelle findet?

pacman -Ss mesa* oder yay -Ss mesa*
Ggf. auch pacman/yay -Ss mesa-utils

Auch pacman -Ss mesa | grep Installiert sollte bei eingestellter deutscher Sprache möglich sein.

---

Ich hoffe, ich hab da keine Fehler drin (* weg zur Not).

 

[tmfo]

Ich sehe nicht so richtig den direkten Bezug zum Steam Deck. Dessen iGPU ist doch RDNA2. Was bringen hier RDNA3-spezifische Features?

 

[Tanzmusikus]

Hier im Thema geht's allgemein um Linux' Mesa 22.3.0 für RDNA3, nicht im Speziellen um das SteamDeck.
SteamDeck 2.0 könnte es ja evtl. betreffen, falls dieses irgendwann erscheint.

 

[Replay86]

Und Nvidia mit sturer quellgeschlossene Softwarepolitik den Anschluss verloren. Wenn Linuxanwender die Wahl haben, kaufen sie seit vielen Jahren nur Intel oder AMD.

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.

 

[Piktogramm]

@tmfo
Naja Svens Meldung scheitert etwas daran die Versionsunterschiede eines extrem großen Softwareprojektes darzustellen und dann auch noch etwas Einordnung für "normale" Nutzer hinzubekommen. Das soll kein Vorwurf sein, das ist schlicht ein aussichtsloses Unterfangen..

Das aktuelle Release unterstützt RDNA3 GPUs und das Release liefert eben auch OpenGL + Vulkanfeatures für andere Architekturen, insofern diese die Features unterstützen bzw. die GPUs von Mesa überhaupt unterstützt werden. Im Zweifelsfall profitiert also jede AMD-Karte unter Linux und da ist das SteamDeck gerade die prominenteste Plattform.

 

[0x8100]

Ich sehe nicht so richtig den direkten Bezug zum Steam Deck.

steam deck = valve. valve ist mitglied von khronos, der gruppe zur standardisierung von vulkan und entwickelt dort neue extensions damit proton besser läuft. jetzt ist wieder eine reihe dieser extensions in mesa (auch) für amd gpus implementiert worden. mit dem neuen mesa werden dann auch auf dem steam deck spiele besser laufen.

 

[Piktogramm]

@Replay86
Naja Rechenzentren laufen fleißig Nvidia und je nach Kultur dort mosern schon einige über Nvidias Treiberpolitik.

 

[JustAnotherTux]

RADV (genauso wie radeonsi) gibt es aber auch nur, weil AMD zum einen nicht Blockt und zum anderen amdgpu als Kernel-Komponente pflegt.
Und es ist ja auch völlig ok bzw sogar wünschenswert, dass die Userspacetreiber möglichst viel von Mesa/DRI (wieder)verwenden, anstatt das Rad jedes Mal neu zu erfinden, wie es bei proprietären Treibern der Fall ist ^^

Ja da kann ich dir nur zustimmen

 

[Piktogramm]

@SVΞN
Bug im Artikel
Schau dir mal den letzten Link in deiner Tabelle an, der zeigt auf:
https://lists.freedesktop.org/archives/mesa-dev/2022-November/225898.html/#

Das /# ist wahscheinlich zu viel und der aktuelle Link bringt ein 404 hervor

 

[Tanzmusikus]

... stimmt, für das Announce funktioniert das:
https://lists.freedesktop.org/archives/mesa-dev/2022-November/225898.html

 

[ghecko]

Wo liegt denn eigentlich der Unterschied zum von AMD angebotenen AMDGPU Treiber und Mesa, hat man da irgendwelche Vorteile?

Mesa musst du dir als modulare Infrastruktur vorstellen, die die eigentlichen Treiber mit den APIs und den Programmen verknüpft:

Das sieht jetzt erst mal wild und clunky aus, sorgt aber tatsächlich für Ordnung und nimmt bei der Treiberentwicklung viel Arbeit ab. So kann es sein, dass wenige Leute mal schnell einen neuen GPU-Treiber für den M1 schreiben. Und selbst Intel ARC ist unter Linux anscheinend recht problemlos nutzbar, während unter Windows nach wie vor nur die Hälfte funktioniert.

Mesa und amdgpu stehen also nicht in Konkurrenz, amdgpu ist einfach nur der Stecker, mit dem sich Mesa an die AMD-Hardware andockt.

Die OpenGL- und Vulkan-Treber für AMD-Grafikkarten sind gut. Aber bei GPGPU gibt es immer noch massiv Probleme. Hier ist die Klage bei Phoronix, bei Nvidia tut es out of the box und bei AMD ist es immer ein herumprobiere.

Ja, leider. Aber rusticl macht mir Hoffnung, dass sich das in Zukunft bessert. OpenCL ootb bei AMD ist längst überfällig.

 

[nille02]

Langsam möchte Nvidia ja Teile des Codes offen legen.

Naja bisher haben sie ihren Blob nur weiter auf die GPU verlagert. Das was sie nun Open Source Modul nennen macht nichts anderes als Befehle an den Blob auf der GPU durchzuleiten.

 

[ETI1120]

Ja, leider. Aber rusticl macht mir Hoffnung, dass sich das in Zukunft bessert. OpenCL ootb bei AMD ist längst überfällig.

Ich weiß nicht ob dies für OpenCL nicht zu spät kommt.

Nvidia hat OpenCL immer nur halbherzig unterstützt. Cuda lieferte immer bessere Ergebnisse, so dass praktisch alle, die für Nvidia-GPUs entwickeln, auf Cuda setzen. Da Nvidia das Feld bisher praktisch unangefochten beherrscht, hat sich Cuda als Quasistandard etabliert.

AMD hat sich inzwischen nach einigen Versuchen auf HIP festgelegt. Es ist einfach Cuda-Code in HIP-Code umzuwandeln. HIP kann für AMD- und Nvidia-GPUs kompiliert werden. Auf diese Art und Weise wurde die Software für Frontier portiert. Es wird sich zeigen, ob AMD auch Anbieter von kommerzieller Software für diesen Weg gewinnen kann.

Natürlich gibt es auch noch Unterstützung für OpenCL, aber AFAIK nur sehr begrenzt.

Und Intel propagiert auch eine eigene API.

 

[ghecko]

AMD hat sich inzwischen nach einigen Versuchen auf HIP festgelegt.

Das Problem mit HIP ist halt, das es unter Linux an ROCm hängt. Und der Support von Hardware und OS ist eine absolute Vollkatastrophe.
Dieser Post im Phoronix-Forum fasst das gut zusammen:
https://www.phoronix.com/forums/for...port-sycl-in-the-future?p=1350916#post1350916
HIP bringt also unter Linux nichts, wenn es abseits von HPC kaum einer nutzt, weil ROCm nicht nutzbar ist.

tldr: AMD hat den Consumermarkt was GPU-Compute betrifft komplett aufgegeben, und es ist kein Licht am Horizont. Dafür muss irgend eine Lösung her. rusticl kann OpenCL wieder für Developer interessant machen, weil es tatsächlich Verbreitung verspricht, als Teil vom Mesa. Damit wäre zumindest das Henne-Ei Problem weg.

 

[flaphoschi]

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.

Als Linuxanwender interessiert es mich, wie Linux als Plattform interessant für Hersteller gemacht wird. Der aktuelle Marktanteil ist dafür kein Punkt, der Ausblick und die sichere Lücken dagegen schon.

Und Nvidia zeigt sich bei Tegra etwas freundlicher. Grund? Embedded Bereich kann sich schlechte Treiber und fehlenden Support nicht mehr leisten. Android hat die schlechte Situation allen gezeigt. Nvidias Grafik im Auto muss halt mit Linux laufen, dreissig Jahren lang - und schon hat keiner Lust auf den quellgeschlossenen Code.

 

[ghecko]

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.

Ja, die gehen Nvidia gelinde gesagt am Arsch vorbei.
Was Nvidia nicht am Arsch vorbei geht, sind die ganzen HPC, IoT und Datascience-Kunden die zu AMD überlaufen, weil deren offenes Treibermodell für deren Entwicklung Vorteile bringt. Das ist der eigentliche Grund warum die Hardliner bei NV jetzt von ihrer Linie abweichen. Weil es im Portmonee dünner wird.
Open Source lohnt sich.

 

[ETI1120]

Das Problem mit HIP ist halt, das es unter Linux an ROCm hängt. Und der Support von Hardware und OS ist eine absolute Vollkatastrophe.

ROCm wurde mit dem Ziel HPC hochgezogen, momentan reift die Toolkette auf dem Frontier.
HIP ist momentan eng mit ROCm verbunden. Aber HIP hängt nicht an ROCm. Eher anders herum, viele Komponenten von ROCm basieren auf HIP.

Das witzige ist, es Cycles verwendet für AMD-Grafikkarten HIP sowohl unter Windows als auch unter Linux. Also müssen zumindest einige Teile der HIP-Toolkette in den Treibern vorhanden sein. Die AMD-Grafikkarten können nicht mit der Performance von Optix mithalten, da Cycles mit HIP noch nicht die Raytracing-Einheiten verwendet und da RDNA 2 generell bei der Rechenleistung weit hinter Ampere zurückliegt.

Generell ist der ausbleibende Fortschritt im Jahr 2022, was GPGPU auf AMD-Gaming-CPUs betrifft, ernüchternd. Ich hatte eigentlich Anfang des Jahres das Gefühl da kommt Bewegung in die Sache, aber es war wohl nur eine Sonderaktion für Blender. Und das war letztendlich äußerst zäh.

Ob rusticl das tote Pferd OpenCL wiederbeleben kann, bleibt abzuwarten. Eine gute Crossplattform-OpenCL-implementierung hätte es schon vor Jahren geben müssen. Ein kritischer Punkt ist, rusticl muss auf Nvidia-Karten mit Cuda mithalten können. Der andere kritische Punkt ist, rusticl muss von den Programmierern angenommen werden.

 

[Dark Thoughts]

Und ob FSR usw. möglich ist habe ich gar nicht erst geschaut.

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".

 

[flaphoschi]

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.

Zweite Antwort

Der Marktanteil ist für die BWLer wichtig und tatsächlich für die aktuelle Marktlage. Für die Zukunft gilt immer anderes und für Marktlücken wird es umgedreht genutzt.

Marktanteile werden speziell in der IT zu Beginn vergeben. Microsoft hat bei PC alles gewonnen, bei Smartphones alles verloren. Da waren Apple und Google da. Umgekehrt, wer wirklich gut ist und auf schwache Konkurrenz trifft kann einen bestehend Markt vollständig übernehmen. Linux hat das bei Servern getan. Und im Embedded Bereich. Tesla hat das bei Autos. Es geht.

Bleibe wir bei Autos. Nvidia zeigt sich bei Tegra etwas freundlicher. Die Autohersteller haben quellgeschlossenen Treiber bei Android gesehen und deren Folgen. Kann man sich nicht leisten, wenn Autos 30 Jahre alt werden.

Den PC-Markt kann man eigentlich nur über die Hardware ändern. Da beherrscht Microsoft die Hersteller. IBM hätte die Macht 2005 noch gehabt und vergeben. Valve macht es richtig, Hardware mit Linux ausliefern.

Beispiele:
NXP ist bei ARM eine Hersteller in einer Marktlücke, langsamer als Qualcomm, aber quelloffene Treiber als Plattformsicherheit.

Apple. War mal wichtig bei Computern, als der Markt noch am entstehen war. Ist dann in das Hochpreissegment*, hat deswegen absolut Marktanteile verloren - in einem noch wachsenden Markt. Beinahe Pleite gegangen. Hat dafür mit iPod und iPhone einfache neue Märkt aufgemacht.

Die initiale Verteilung ist entscheiden. Mit viel Engagement und einem Schlüssel kann man es aber drehen. Wenn alles nicht hilft, mach einfach was komplett Neues, also zurück zur initialen Verteilung.

BWL-Denken ist leider nie langfristig und fokussiert auf Marktanteile. Und scheitert dann. Es langfristig nicht gut.

* Apple mag bei den Preisen mittlerweile wieder überziehen. Der Markt ist aber erstmal aufgeteilt und Vendor Lock-in greift.