AMD ROCm 5.6 für RDNA3 und Radeon Pro GPUS

  • Ersteller Ersteller HierGibtsNichts
  • Erstellt am Erstellt am
H

HierGibtsNichts

Gast
AMD ROCm 5.6 für RDNA3 und Radeon Pro GPUS

Für alle professionellen Anwender bei uns in der Guppe oder die welche in der professionellen Materie sind bzwe. sich dafür interessieren.

Im Herbst 2023 veröffntlicht AMD ROCm in Version 5.6 für alle RDNA3 und Radeon Pro GPUs.

Für die welche nicht so in der Materie sind, die Veröffentlichung von ROCm auf/für Radeon GPU ist deshalb so bedeutend weil es sich hierbei um die Konkurrenz zu Nvidias CUDA Programmierschnittstelle handelt welche bisher nur auf den Servermarkt begrenzt war und nicht auf für den normalen Anwender verfügbare GPU.

Bisher hatte Nvidia im professionellen Bereich ein Alleinstellungsmerkmal/Markmacht mit CUDA und besonders in "CUDA Anwendungen" eine deutlich bessere Performance.

Dies ändert sich nun, weil es mit ROCm 5.6 nun eine weitere für alle Nutzer, Entwickler und Firmen verfügbare API gibt auch abseits vom Servermarkt und den teueren MIInstinct GPUs. ROCm ist kostenlos, OpenSource.

Für Interessierte ausserhalb der Pro Bubble habe ich ein YT Video angehängt was das Ganze nochmal grob und einfach erklärt.

https://www.youtube.com/watch?v=-u41fsG6foc&t=303s

Es ist wie immer Konkurrenz ist immer gut und belebt das Geschäft.

Was ist CUDA : CUDA (früher auch Compute Unified Device Architecture genannt) ist eine von Nvidia entwickelte Programmierschnittstelle (API), mit der Programmteile durch den Grafikprozessor (GPU) abgearbeitet werden können

https://www.amd.com/de/graphics/servers-solutions-rocm
 
  • Gefällt mir
Reaktionen: duklum, Eller, Demon_666 und 5 andere
Zu spät, zu wenig.

"We plan to expand ROCm support from the currently supported AMD RDNA 2 workstation GPUs: the Radeon Pro v620 and w6800 to select AMD RDNA 3 workstation and consumer GPUs. Formal support for RDNA 3-based GPUs on Linux is planned to begin rolling out this fall, starting with the 48GB Radeon PRO W7900 and the 24GB Radeon RX 7900 XTX, with additional cards and expanded capabilities to be released over time."

Das ist eigentlich kein Grund zu feiern sondern ein Armutszeugnis, das ab Herbst irgendwann erst die 7900 XTX und wer weiß wann auch die anderen RDNA3 GPUs supportet werden. Bei Nvidia hat man Day1 support und selbst Intel bekommt das als Neueinsteiger besser hin. Wenn AMD bei Compute fernab von HPC noch mal Fuß fassen will, müssen sie sich ranhalten. Die anderen bekommen es ja auch irgendwie hin.
 
  • Gefällt mir
Reaktionen: duklum und Marco01_809
ghecko schrieb:
Zu spät, zu wenig.

Das ist eigentlich kein Grund zu feiern sondern ein Armutszeugnis.
Zu spät wohl nicht, wenn die Branche es anfragt und Interesse daran hat.

Ich habe nicht geschrieben das man es feiern soll aber es ist eine positive Entwicklung.

Armutszeugnis ist schon massiv überzogene Beurteilung.

ghecko schrieb:
selbst Intel bekommt das als Neueinsteiger besser hin
wo? intel arc und computing, ist nicht existent.
 
  • Gefällt mir
Reaktionen: duklum und kuddlmuddl
Taurus104 schrieb:
wo? intel arc und computing, ist nicht existent.
OneAPI. Zb. in Blender mit der aktuellen Version volle Integration in den Renderer, mit RT unter Windows und Linux. AMD? Ja, nein... vielleicht bei der nächsten Version.
Blender 3.6 adds support for Intel hardware ray-tracing for Arc Graphics and Data Center GPus via use of the Embree 4 library. Blender developers have found nice speed-ups with Intel's ray-tracing path with Embree and oneAPI. This support works on both Windows and Linux.
Over on the AMD side, there is experimental AMD Radeon hardware ray-tracing at long last! This HIP RT support though is sadly limited to Windows. The release notes mention explicitly: "No Linux support, as HIP RT is Windows only still.
https://www.phoronix.com/news/Blender-3.6
https://gitlab.freedesktop.org/drm/amd/-/issues/2145
https://projects.blender.org/blender/blender/issues/100353
Taurus104 schrieb:
Zu spät wohl nicht, wenn die Branche es anfragt und Interesse daran hat.
CUDA hat den Konsumermarkt übernommen, dank AMDs Untätigkeit. Und bei AMDs Marktanteil, der auch wegen Compute so gering ist, machen Softwareschmieden kaum einen Finger krumm um AMD zu supporten. Bis die Konsumerkarten nicht zuverlässig laufen erst recht nicht.
Das hätte schon vor Jahren laufen müssen. So spätestens ab 2009.
 
Zuletzt bearbeitet:
ghecko schrieb:
OneAPI. Zb. in Blender mit der aktuellen Version volle Integration in den Renderer, mit RT unter Windows und Linux. AMD? Ja, nein... vielleicht bei der nächsten Version.


https://www.phoronix.com/news/Blender-3.6
https://gitlab.freedesktop.org/drm/amd/-/issues/2145
https://projects.blender.org/blender/blender/issues/100353

CUDA hat den Konsumermarkt übernommen, dank AMDs Untätigkeit. Und bei AMDs Marktanteil, der auch wegen Compute so gering ist, machen Softwareschmieden kaum einen Finger krumm um AMD zu supporten. Bis die Konsumerkarten nicht zuverlässig laufen erst recht nicht.
Das hätte schon vor Jahren laufen müssen. So spätestens ab 2009.
Es schwingt in den Aussagen eine etwas Negative Grundeinstellung gegenüber AMD mit. Sorry. Das liest man heraus. Auch das "ja, nein vielleicht" Gerede ist unsachlich, mehr nicht.
Die Anführung von OpenAPI ist auch eher so naja aber das weiß man sicher.

Natürlich ist es immer besser alles schneller, mehr und sofort. ABER Ich bin privat und beruflich froh das AMD jetzt den Schritt macht und es eine Alternative gibt. Das ist der Grundtenor den man bisher aus dem Markt/Branchenbereich auch hört zu der Ankündigung und das ist eben auch meine Ansicht.

AMDs Marktanteil, der auch wegen Compute so gering ist,
Das halte ich für eine Subjektive Einschätzung mehr nicht.

Aber hier bringt Diskurs nichts. ich habe meine Meinung dazu gesagt und die Info an Interessierte da gelassen. Wenn man den Sachverhalt negativ statt positiv sehen möchte, kann man das tun. Dann soll man weiter CUDA nutzen aber sich nicht über Nvidias Markmacht beschweren als Kunde.
 
Taurus104 schrieb:
Ich denke hier schwingt in den Aussage eine etwas Negative Grundeinstellung gegenüber AMD mit. Sorry. Das liest man heraus. Auch die ja, nein vielleicht Gerede ist unsachlich mehr nicht.
Ich sitze vor einer AMD-APU in einem Laptop, davor im PC auch nur AMD, also an der Einstellung kann es nicht liegen. Nenne es Frustration über Dinge, die ich mit meinem PC unter meinem OS gerne tun würde, die AMD aber nicht so richtig auf die Reihe bekommt.
Taurus104 schrieb:
Die Anführung von OpenAPI ist auch eher so naja aber das weiß man sicher.
oneAPI. Und das was Intel in relativ kurzer Zeit an Funktion bereitgestellt ist schon beachtlich, so waren meine Erwartungen auch bezüglich ROCm, als AMD das erste mal drüber diskutiert hat. Meine Erwartungen wurden halt enttäuscht.
Taurus104 schrieb:
Dann soll man weiter CUDA nutzen
Will ich nicht, gerade deshalb ärgere ich mich ja über AMDs "Enthusiasmus" in diesem Umfeld.
 
Unter Arch Linux kann man mit dem Package rocm-hip-sdk auf einer 6700XT Rocm benutzen.
Einfach das Package installieren und mit dem Befehl:
export PATH=/opt/rocm/bin:$PATH
im Path eintragen.

Was man noch tun muss um es auf der 6700XT zu nutzen, ist, mit diesem Befehl dem System vorgaukeln, es sei eine 6900XT:
export HSA_OVERRIDE_GFX_VERSION=10.3.0 HCC_AMDGPU_TARGET=gfx1030

Funktioniert zumindest für PyTorch ganz OK, allerdings stürzt es immer wieder mal ab. :D
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: HierGibtsNichts
Ich setze da mehr Hoffnung auf Rusticl als auf ROCm. Offiziell nur für drei Distributionen, dass ist doch ein Witz. Vor meinem festen Umstieg auf Tumbleweed konnte man ROCm wohl mal zum laufen bringen, was ich dazu so gefunden habe, daher ist z.B. Blender aktuell nicht zu gebrauchen.

Die neue Umsetzung von OpenCL 3.0 in Rust läuft den Berichten und Rückmeldungen nach schon recht gut. Ist wohl auch schon ohne große Optimierungen schneller als ROCm. Ist nun schon in Mesa 23.1 enthalten, aber noch nicht als Default im Build enthalten, wenn man über die Repos der Distributionen das System aktualisiert.
 
  • Gefällt mir
Reaktionen: HierGibtsNichts
Microarchitekt schrieb:
Ich setze da mehr Hoffnung auf Rusticl als auf ROCm. [....] daher ist z.B. Blender aktuell nicht zu gebrauchen.
Leider hat Blender den Support von OpenCL aus Cycles genommen, weil die AMD Implementierung so buggy war. Ich glaube nicht das Blender das in naher Zukunft wieder integriert, somit ist Rusticl für Blender keine Option :/
Die setzen auf HIP für AMD, und dazu ist ROCm notwendig.
 
Es wurde ja schon aus der Ecke im Umfeld von Blender angerissen, dass die Entfernung von OpenCL etwas voreilig war. Nur leider war da nur die Umsetzung mittels 'Clover' vorhanden und von Rusticl noch nichts zu sehen. Das da jetzt aktuell nicht mit Begeisterung zurück gerudert wird kann man verstehen. Dafür waren die Probleme mit Clover zu groß und zu nervig.

Ein Schwenk zurück zu OpenCL dürfte bei den Projekten, wenn sie es machen sollten, erst mit einiger zeitlicher Verzögerung kommen. Da wird sich Rusticl erst mal in kleineren Sachen beweisen müssen, dass es wirklich so stabil läuft wie es sich wohl andeutet. Aktuell wird die Umsetzung von OpenCL 3.0 auch noch nicht fertig und es werden immer noch weitere Features des Standards in den Entwicklungszweig eingefügt.

ich bin durchaus guter Dinge, dass die Umsetzung mittels Rust viele Probleme von Clover von vornherein vermeidet. Problem ist halt, man muss wieder Vertrauen bei den nutzenden Projekten aufbauen, welches durch Clover doch massiv gelitten hat.
 
  • Gefällt mir
Reaktionen: HierGibtsNichts
Zurück
Oben