News GPU-Computing: AMDs HIP-SDK bringt Nvidia CUDA auf eigene GPUs

[sikarr]

Wie gut läuft es denn nach der Portierung auf AMD Karten? Wäre ja der Hammer wenn es am Ende unter AMD performanter wäre als unter Nvidia selbst.

 

[duklum]

Wann sinD Bennchmarks für Blender zu erwarten? Mich würde die Leistung der AMD Radeon RX 7900 XTX interessieren. Also ob diese dadurch besser wird. Den aktuell würde ich zum Rendern die RTX 4090 kaufen, aber wenn das jetzt die Rangordnung nochmal neu auswürfelt und AMD für knapp den halben Preis an eien ähnliche Leistung ran kommt, dann würde ich umdenken.
Ist das damit möglich? Oder hat das keinen einfluss darauf?

Benchmarks für Blender gibt es hier:
https://opendata.blender.org/benchmarks/query/?group_by=device_name&blender_version=3.6.0

Beim Thema KI/ML habe ich keine Ahnung. Ich arbeite mit CAD und ab und zu muss ich auch einiges rendern. Zu dem Thema kann ich sagen, dass in dem Bereich kaum jemand auf die Idee kommen würde zu AMD zu greifen. Im Forum von meiner CAD software (Rhino3D) schimpfen die Entwickler schon seit ich mich erinnern kann über AMDs Treiber, nur Intel ist schlimmer (viel schlimmer). Dabei geht es sowie ich es verstanden habe hauptsächlich um OpenCL. Wenn jemand Probleme hat und sich rausstellt, dass er ne AMD Karte im System hat schreiben die Enwickler meist direkt dazu "nächstes mal Nvidia kaufen".

Rein von der Leistung im CAD viewport ist AMDs mit Nvidia ungefähr gleich auf. Wenn man aber auch rendern muss (z.B. Cycles/Blender, Vray oder Keyshot) dann kommt nur Nvidia in Frage. Mit CUDA war man beim rendern mit Nvidia schon um einiges schneller und oft wurde AMD mit OpenCL erst gar nicht unterstützt (Ausnahme Cycles/Blender). Schön zu hören, dass AMD mit HIP nur irgendwie an CUDA herankommt. Nur intererssiert das beim Rendern keinen, denn das rechnen die erwähnten Programme seit einiger Zeit über Optix - das ist der schicke Marketingname von Nvidia wenn ein Programm auf den RT Kernen läuft (nicht wie CUDA auf den GPU Kernen). Das hat noch mal einen riesen Schub an Leistung gebracht. Ich hatte lange Zeit versucht AMD die Stange zu halten (hatte sogar mal ne Vega64) aber spätestens als Optix das Rendern beschleunigt hatte war auch bei mir kein Vorbeikommen an Nvidia mehr.

Im Bereich CAD und speziell beim Rendern ist AMD leider kein Thema. Wenn AMD es nicht schafft eine Schnittstelle bereitzustellen, welche (analog zu Nvidias RT-Kernen) die "Ray Accelerators" ab RDNA2 nutzen kann, wird sich daran auch nichts ändern.

Hier der Unterschied zwischen AMDs 7900XTX (HIP) und Nvidias 4090 (Optix) beim Rendern mit Cycles.
Spoiler: die 4090 ist rund 237% schneller.

Würde mich sehr freuen, wenn AMD es schafft in meinem Anwendungsbereich wieder aufzuholen. Meiner Meinung nach müssten sie dafür aber viel mehr Kohle in die Entwicklung ihrer Schnittstellen stecken. Gerade geben sie sich zwar mehr Mühe, scheint mir aber bei Weitem nicht genug um an Nvidia ran zu kommen - was ich sehr schade finde. Einfach nur die Rohleistung auf dem Silizium zu haben genügt nicht. Da muss schon eine Schnittstelle her, über die man die Leistung auch abrufen kann. Bei den Programmen die ich nutze spüre ich von HIP oder ROC noch nichts - nur Blender ist da mal wieder eine Ausnahme.

Wie zu Beginn schon erwähnt, das bezieht sich alles nur auf CAD und Rendern im speziellen und dabei auch nur auf bestimmte Programme. Wenn es bei der KI-und ML-Sachen bei AMD momentan besser läuft finde ich das super. Dieser Markt ist natürlich wichtiger/größer als CAD und Rendern, darum verständlich.

 

[Novasun]

Das dämpft die Erwartungen natürlich direkt wieder.
Mal schauen wie sich das entwickelt.
Grundsätzlich ist das Potenzial ja enorm, die Rohleistung ihrer Compute und Server Karten ist da und Marktanteile zum erobern gibts auch ohne Ende.

Langsam. Da man jetzt erst mal einfach den CUDA Code überführen kann ist schon mal super. Damit kann man ja schnell mal testen und ausprobieren... Wichtig ist das auch die ganzen Softwarehersteller wo einzelne PlugIns CUDA nutzen. Die können die dann eben auch für andere GPUs anbieten.

 

[SimsP]

Du arbeitest mit HIP einem Bestandteil von ROCm aber nicht der vollumfänglichen API. HIP funktioniert unter Linux tatsächlich schon länger mit Consumer GPUs. "FULL ROCm" war bisher nur den Instinct GPUs unter Linux vorbehalten. Unter Linux kann man nun auch "FULL ROCm" seit Version 5.6 mit Radeon Pro und RDNA 3 und 2 nutzen. Kurzgefasst die DL,ML Parts der API. Das ging vorher unter Windows überhaupt nicht. Hier ist man nun mit dem HIP SDK für Windows nachgezogen als ersten Veröffentlichungsschritt. Alle Funktionen/Bestandteile von ROCM werden nach letztem Stand im Herbst für Windows nachgereicht.

Ich nutze derzeit mehr oder weniger privat HIP mit meiner Radeon VII nun unter Windows was voher nicht ging und man dadurch eine deutlich schlechtere Performance hatte oder bestimmte CUDA Programme garnicht erst lauffähig waren.

Ob es möglich war weiß ich tatsächlich nicht. AMD setzt es halt jetzt erst Stufenweise um.

Aha, welcher Betsandteil von ROCm ging denn bisher nicht mit Vega? Also ich nutze das ganze hauptsächlich für Tensorflow/Pytorch und solche Sachen. Dafür braucht man ja HIP/HCC/OpenCLR + ROCr + ROCt und die ganzen Libs (Blas, MIOpen ...). Außerhalb dessen kann ich nicht viel sagen, aber das funktioniert schon seit mindestens Ubutu 18.04 (ich glaub das war ROCm >=1.8??). Nicht gut und sehr frickelig aber prinzipiell gehts. Wobei ich nicht weiß ob frickelig nicht ein permanentes Alleinstellungsmerkmal von AMD Software ist

Kp also meiner Erinnerung nach waren im Code immer wieder mal Windows Compile-Direktiven gesetzt. Bin mir aber nicht mehr ganz sicher und weiß auch nicht, ob das wirklich durchgängig war. Hab nie versucht ROCm für Windows zu bauen. Das macht ja schon unter Linux genug Probleme, wenn Versions-Nummer XY wieder wegen Abhängigkeit Z nicht baut, die natürllch wieder genau bei dem Kernel, den man gerade selber verwendet wieder nicht die passenden libs dabei hat.
Also wie gesagt alles fern ab von setup.exe ausführen und läuft.

 

[Zornica]

Ob das hilft das kompatibilitätsproblem zwischen amd notebook gpus und davinci resolve zu resolven?
rocm scheint da ja irgendwie nicht so richtig zu funktionieren leider...

 

[usbstick]

@alle die auch gerne konkurrenz für cuda sehen würden:

ich bin froh, dass es bei AMD anscheinend voran geht, wenn auch in kleinen schritten.
pytorch mit rocm fertig beziehen zu können war schon ein großer schritt, rdna-support mit mehr sicherheit als "eventuell wird es mal offiziell supported" ist ebenfalls super, und wenn die irgendwann mal ein ganzes ökosystem anbieten bei dem man nicht tagelang den ganzen stack mit miopen und hcc usw. kompilieren mnuss, dann ist diese welt ein besserer ort.

 

[HierGibtsNichts]

Enwickler meist direkt dazu "nächstes mal Nvidia kaufen".

Das sind dann meistens aber auch Programme, Devs etc. die finanziell von Nvidia unterstützt werden. (Gruß geht raus an die Devs von Adobe)

Wenn AMD es nicht schafft eine Schnittstelle bereitzustellen, welche (analog zu Nvidias RT-Kernen) die "Ray Accelerators" ab RDNA2 nutzen kann, wird sich daran auch nichts ändern.

Tatsächlich ist es so das ein ROCm ab Version 5.6 die Ray Accelerators beim Rendern ansprechen/nutzen kann. Das läuft zwar Stand jetzt noch über die GPU als Zwischenschritt, die Accelerator werden nicht direkt angesprochen.

Meiner Meinung nach müssten sie dafür aber viel mehr Kohle in die Entwicklung ihrer Schnittstellen stecken. Gerade geben sie sich zwar mehr Mühe, scheint mir aber bei Weitem nicht genug um an Nvidia ran zu kommen - was ich sehr schade finde.

Problem ist halt das AMD kein reiner GPU Hersteller wie Nvidia ist und man viel geringerer Gesamtkapazitäten hat für alle Bereiche.

Hier der Unterschied zwischen AMDs 7900XTX (HIP) und Nvidias 4090 (Optix) beim Rendern mit Cycles.
Spoiler: die 4090 ist rund 237% schneller.

Ich gehe davon aus das diese Angaben unter Linux sind korrekt?

Danke aber für den Kommentar. Nochmal eim sehr interessanter Einblick von anderer Stelle.

Ergänzung (4. August 2023)

welcher Betsandteil von ROCm ging denn bisher nicht mit Vega?

Alles was mit DL, ML etc. zutun hat. Hierfür waren bisher die Instinc GPUs auch unter Linux nötig.

Ergänzung (4. August 2023)

@alle die auch gerne konkurrenz für cuda sehen würden:

ich bin froh, dass es bei AMD anscheinend voran geht, wenn auch in kleinen schritten.
pytorch mit rocm fertig beziehen zu können war schon ein großer schritt, rdna-support mit mehr sicherheit als "eventuell wird es mal offiziell supported" ist ebenfalls super, und wenn die irgendwann mal ein ganzes ökosystem anbieten bei dem man nicht tagelang den ganzen stack mit miopen und hcc usw. kompilieren mnuss, dann ist diese welt ein besserer ort.

Das ist das mittelfristig das Zeil des ganzen Unterfangens tatsächlich.
Das wird noch Zeit beanspruchen und Cuda wird man nie ablösen aber eben eine valide Alternative bieten können.

 

[duklum]

Das sind dann meistens aber auch Programme, Devs etc. die finanziell von Nvidia unterstützt werden. (Gruß geht raus an die Devs von Adobe)

Rhino3D - das Programm das ich meine, wird meines Wissens nicht von Nvidia finanziell unterstützt. Die finanzieren sich rein von Käufern ihrer Lizenz - ich bin so einer.

Tatsächlich ist es so das ein ROCm ab Version 5.6 die Ray Accelerators beim Rendern ansprechen/nutzen kann. Das läuft zwar Stand jetzt noch über die GPU als Zwischenschritt, die Accelerator werden nicht direkt angesprochen.

Ah, na langsam scheint sich in der Hinsicht etwas zu tun, danke interessanter Hinweis. Hat das mit dem "nicht direkt ansprechen" eventuell etwas damit zu tun, dass die Rays Accelerators bei AMD im Gegensatz zu Nvidias' RT-Cores nicht als separate Einheit auf der GPU sitzen, sondern immer ein Teil jeder compute unit sind?

Problem ist halt das AMD kein reiner GPU Hersteller wie Nvidia ist und man viel geringerer Gesamtkapazitäten hat für alle Bereiche.

Ja, das ist leider wahr.

Ich gehe davon aus das diese Angaben unter Linux sind korrekt?

Bei der Suche war das OS nicht angegeben, Mittelwert für alle OS. Kann man aber auf Linux oder Windows beschränken - ändert am Ergebnis kaum etwas.

 

[HierGibtsNichts]

eventuell etwas damit zu tun, dass die Rays Accelerators bei AMD im Gegensatz zu Nvidias' RT-Cores nicht als separate Einheit auf der GPU sitzen, sondern immer ein Teil jeder compute unit sind

Exakt das ist der Hintergrund, ja.

 

[Hate01]

Alles was mit DL, ML etc. zutun hat. Hierfür waren bisher die Instinc GPUs auch unter Linux nötig.

Das stimmt nicht. Das läuft alles bei mir seit gefühlt Ewigkeiten auf meiner Radeon VII (ist im Grunde auch eigentlich eine MI50).

 

[HierGibtsNichts]

@Hate01 Unter Linux gibt/gab es "inoffizielle" Optionen/Möglichkeiten ROCm im vollen Funktionsumfang vor Version 5.6 auf der Radeon VII zu nutzen. (aufgrund ihrer technischen nähe zu den Instinct GPUs damals) Habe ich selbst gemacht aber das waren keine offiziellen durch AMD Supported Lösungen. Der HIP Part von ROCm lief tatsächlich schon immer auf der Radeon VII und das ganz offiziell.

 

[FrankN84]

Bisher dachte ich, CUDA wäre ein exklusives Feature für Nvidia Karten.
Wenn mittels HIP SDK nun aber auch Windows Software mit CUDA Support auf AMD GPUs zur Beschleunigung genutzt werden kann, klingt das super.

Heißt das, man könnte bspw. bei der Video Konvertierung auch CUDA Beschleunigung mit AMD Karten aktivieren und nutzen?? Ob es da leistungsmäßig (Dauer der Konvertierung) große Unterschiede gibt...?

Einstellungen in AVC (Any Video Converter)

 

[ETI1120]

„Wie unterscheidet sich HIP von ROCm?

Wie so üblich muss man hier ganz genau auf das Wording achten. Und hier ist dieser Blockbeitrag IMO sehr unpräzise. Auch in diesem Abschnitt hätte es HIP SDK heißen müssen.

HIP ist das eine und HIP SDK for Windows ist etwas anders.

AMD zeigt auf ihrer Website den Aufbau des ROCm Softwarestacks

Anzumerken ist, dass diese Übersicht, die AI-Frameworks die ROCm unterstützt, nicht umfasst.
Eine gute Übersicht bietet auch: https://rocm.docs.amd.com/en/latest/reference/all.html

HIP ist erst Mal eine API um GPUs zu programmieren, wie gesagt sie ist entsprechend dem Kern von CUDA angelegt. Damit man mit HIP überhaupt Programmieren kann benötigt man Compiler und ein Runtime. Profiler und Debugger sind essentielle Tools.

HIP ist die von AMD favorisierte API zum Programmieren von GPUs. ROCm umfasst neben HIP mit OpenCL und OpenMP noch andere APIs zum Programmieren von GPUs.

Ein ganz wichtiger Bestandteil von ROCm sind Bibliotheken. Aber viele davon sind vor allen Dingen für HPC notwendig. AMD wird erstmal nur den Kern für Windoiws verfügbar machen.

Wo das ganze unübersichtlich wird ist einerseits die Unterstützung von GPUs und andererseits von Funktionen für Windows und Linux.

So wie ich es verstehe bezieht sich die Angabe des GPU-Supports bei Linux auf den gesamten ROCm Stack, während AMD bei Windows sich auf das HIP SDK vor Windows bezieht. Da bei Windows der Funktionsumfang des HIP SDK kleiner ist, fällt es leichter mehr GPUs zu unterstützen.

Prinzipiell halte ich das Unterscheiden zwischen ROCm und HIP SDK für eine gute Idee wenn man es bei Windows und Linux so durchzieht. Für Desktopapplikationen benötigt man nicht das komplette ROCm.
Dass man die AI-Frameworks nicht in die HIP SDK einbezieht kann ich nicht so recht nachvollziehen und ist hoffentlich nur vorläufig.

Doch die neue Version des SDK ermöglicht es erstmals, Software für Nvidias CUDA-Schnittstelle direkt auf AMD-Hardware auszuführen.

Das witzige ist, dass ich diese Aussage in keiner Verlautbarung von AMD zu ROCm 5.6 gefunden habe.

Und wenn man sich diesen Satz genauer überlegt, wie soll das gehen?
Direkt die erzeugten Binaries ausführen geht nicht, da die GPUs nicht binärkompatibel sind und die CUDA API 1:1 nachbauen kann AMD auch nicht. Also läuft das ganze AFAIK auf das Portieren von CUDA auf HIP raus. Klar kann AMD HIPIFY immer weiter optimieren, aber es wird immer Grenzen geben, die das Eingreifen von Programmierern erfordern.

Ich nehme an dass HIPIFY unter Windows noch nicht verfügbar ist, weil unter Windows weniger Bibliotheken als unter Linux verfügbar sind. Falls der CUDA Code das Äquivalent einer nicht für Windows verfügbaren HIP-Bibliothek verwendet, kann HIPIFY für Windows nicht einfach Aufrufe für diese nicht vorhandene Bibliothek generieren.


Im übrigen beantwortet der Blogbeitrag den Du zitiert hast, auch die folgende Frage:

Wie schwierig ist es, eine CUDA Anwendung mit dem HIP SDK zu portieren?​

​

Nicht so schwer, wie Sie vielleicht denken. Sowohl CUDA als auch HIP sind Dialekte von C++. Wenn Sie also CUDA kennen, sollte Ihnen die Syntax vertraut sein, und das SDK enthält Tools, die den Prozess beschleunigen: Das HIPIFY-Toolset übersetzt CUDA-Code automatisch in portables HIP C++. Mit der Orochi-Bibliothek von AMD können Sie sogar eine einzige Binärdatei kompilieren, die sowohl auf AMD- als auch auf NVIDIA-Hardware läuft.​

Zu Orochi:

Orochi ist eine Bibliothek, die HIP- und CUDA-APIs dynamisch lädt, so dass der Benutzer die APIs zur Laufzeit wechseln kann. Daher müssen Sie nicht zwei separate Implementierungen für jede API kompilieren. So können Sie eine einzige Binärdatei kompilieren und pflegen, die sowohl auf AMD- als auch auf NVIDIA-GPUs ausgeführt werden kann. Im Gegensatz zu HIP, das zur Kompilierungszeit hipamd oder CUDA verwendet, lädt Orochi dynamisch die entsprechenden HIP/CUDA-Bibliotheken, je nach Plattform. Mit anderen Worten, es kombiniert die von HIPEW und CUEW angebotenen Funktionen in einer einzigen Bibliothek.​

​

Wie gut läuft es denn nach der Portierung auf AMD Karten? Wäre ja der Hammer wenn es am Ende unter AMD performanter wäre als unter Nvidia selbst.

Das wird nicht passieren.

RDNA 1 und RDNA 2 setzen ihre begrenzte Rechenleistung sehr effizient in Gamingleistung um. Wenn es aber um die Rechenleistung geht, liegen sie hinter den vergleichbaren Nvidia-Karten zurück.

AFAIK sieht es bei RDNA 3 besser aus, da RDNA 3 bei FP32 Arithmetik stark von Dual Issue profitiert. Im Gegensatz zu den Games wo Dual Issue Mal hilft und Mal praktisch nicht hilft.

...
Wenn jemand Probleme hat und sich rausstellt, dass er ne AMD Karte im System hat schreiben die Enwickler meist direkt dazu "nächstes mal Nvidia kaufen".

...
Gerade geben sie sich zwar mehr Mühe, scheint mir aber bei Weitem nicht genug um an Nvidia ran zu kommen - was ich sehr schade finde.

Aber wenn die Grundhaltung ist, ja keine AMD GPU zu verwenden, dann kann AMD machen was sie wollen und sie bekommen keinen Fuß in die Tür.

Problem ist halt das AMD kein reiner GPU Hersteller wie Nvidia ist und man viel geringerer Gesamtkapazitäten hat für alle Bereiche.

Mal im ernst: Wenn AMD die einige Produkte nicht im erforderlichen Umfang supporten kann, müssen sie halt diese Produkte einstellen.

Ich kann diese Entschuldigen des armen kleinen AMD nicht mehr "hören". Es schadet nur und hilft niemanden. AMD ist ein Unternehmen mit 25 000 Mitarbeitern mit mehr als 20 Mrd USD Umsatz.

Ich weiß nicht ob Du den Hintergrund dieser Entwicklung mitbekommen hast.

George Hotz der CEO von COMMA hat im März angekündigt AI auf Basis von RDNA implementieren zu wollen. Nach ein paar Wochen gab es einige wütende Verlautbarungen und das Fazit dass er es einstellt.

Ein paar Tage später kam ein Tweet von Lisa Su, dass AMD den Support von RDNA verbessern wird. Sie bezog sich ausdrücklich auf George Hotz und hat sich AFAIR für die konstruktiven Gespräche bedankt. (beide Tweets kann ich bei Twitter nicht mehr sehen, es gab Mal Zeiten wo man auf 2 Jahre alle Tweets gesehen hat)

Am 1. August kam übrigens folgender Tweet von George Hotz:

Ich finde im übrigen, dass AMD viel zu wenig aus dem Umstand macht, dass der gesamte ROCm Software-Stack Open Source ist. AMD muss dafür sorgen dass sich genügend externe Programmierer den Stack genauer anschauen.

Bei den Linux Grafiktreibern hat dies hervorragend funktioniert. Hier natürlich vor allem wegen Valve.

 

[HierGibtsNichts]

Bisher dachte ich, CUDA wäre ein exklusives Feature für Nvidia Karten.
Wenn mittels HIP SDK nun aber auch Windows Software mit CUDA Support auf AMD GPUs zur Beschleunigung genutzt werden kann, klingt das super.

Heißt das, man könnte bspw. bei der Video Konvertierung auch CUDA Beschleunigung mit AMD Karten aktivieren und nutzen?? Ob es da leistungsmäßig (Dauer der Konvertierung) große Unterschiede gibt...?

Anhang anzeigen 1383145
Einstellungen in AVC (Any Video Converter)

Für die automatische Konvertierung brauchst du zum HIP SDK auch noch das Tool HIPIFY TOOL, das kommt nächste Woche in die AMD Software Pro Edition für Windows. Also den Professionellen Treiber von AMD.
Das sollte dann funktionieren tatsächlich.
Du wirst nicht die 1 zu 1 Performance wie mit einer Nvidia GPU haben aber deutlich besser mit Open CL.

 

[PrefoX]

@Kaito Kariheddo
man könnte hier ja fast anmerken, dass ATi damals mit der X1900 und der FireStream bei GPGPU auch eine gewisse "Vorreiterrolle" hatten. Auch mit der CTM-API.

NVIDIA hat damals mit CUDA "nachgezeogen", wobei CUDA dann auch durchdachter war und das deutlich bessere Marketing. ATi kam damals vermutlich die "Übernahme" durch AMD dazwischen und den dann verdonneten Sparkursen.

naja die ersten unified/programmierbaren shader sind von nvidia, nur dadurch gibt es GPGPU... also mal nicht die Wahrheit verdrehen. Nvidia hat das erfunden und AMD hat darauf aufgebaut. so wie RTX, DLSS, Gsync, GDeflate etc etc.

 

[usbstick]

Das ist das mittelfristig das Zeil des ganzen Unterfangens tatsächlich.
Das wird noch Zeit beanspruchen und Cuda wird man nie ablösen aber eben eine valide Alternative bieten können.

ich weiß … ich verfolge das schon seit 2008, also seit AMD mit der Entwicklung eines FLOSS-Treibers für Linux angefangen hat, und sich da insgesamt sehr gut, aber leider auch langsam entwickelt hat. Mit einem funktionierenden GPU-Stack, kann ich dann weiterhin in meinen privaten Systemen auf AMD bauen.

 

[ReactivateMe347]

Mir fehlt hier AMDs ursprünglicher eigener Ansatz, genannt Stream. Ich weiß nicht genau, warum die das verbockt haben, aber OpenCL hat AMD wohl nicht deswegen unterstützt, weil es eben der schönere weil plattformübergreifende Ansatz war, sondern weil sich Stream nicht durchgesetzt hat und man nicht völlig irrelevant werden wollte.

https://www.computerbase.de/2009-03/neue-stream-version-von-ati-nun-mit-multi-gpu/

Ich vermute anhand des Artikels, dass das hier nur funktioniert, wenn man den Quellcode hat und nicht auf Basis von CUDA-Binärdateien, explizit ausgeschlossen wird das jedoch nicht. Das wäre vielleicht gut, das explizit zu erwähnen.

 

[Convert]

naja die ersten unified/programmierbaren shader sind von nvidia, nur dadurch gibt es GPGPU...

GPGPU gab es schon vor den unified Shadern.. Unified Shader sind flexibler, aber auch die nicht unified Shader waren/sind programmierbar/für GPGPU nutzbar, nur eben komplizierter und eingeschränkter.

 

[DevPandi]

naja die ersten unified/programmierbaren shader sind von nvidia, nur dadurch gibt es GPGPU... also mal nicht die Wahrheit verdrehen.

Nein, man benötigt keine Unified-Shader für GPGPU, ATi hat GPGPU mit der X1900XTX eingeführt. Flooding@Home hatte für die X1000er auch entsprechend die Optionen. Die "bessere" Programmierbarkeit der Shader kam mit DirectX 9.0c und dem ShaderModel 3.0, dass viele Limitierungen löste. Das ist vollkommen unabhängig von der Entwicklung der Unified--Shader. Diese hat NVIDIA als auch ATi damals eingeführt, weil mit DirectX 9.0c und erst recht DirectX 10 die klassische Grafikpipeline quasi vollständig abgeschafft wurde und sich die Vertex- als auch die Pixel-Shader mit DirectX10 fast vollständig deckten.

Ebenso habe ich dazu die entsprechenden Links - FireStream - bereits geliefert, ich muss hier nicht die Wahrheit verdrehen.

Nvidia hat das erfunden und AMD hat darauf aufgebaut. so wie RTX, DLSS, Gsync, GDeflate etc etc.

... Ach, NVIDIA hat also GPGPU erfunden? Die Fakten sprechen da eine andere Sprache. Wie gesagt, ATi war mit FireStream davor auf dem Markt und NVIDIA hat nachgezogen. Entsprechende Links habe ich gesetzt, die sogar den zeitlichen Ablauf beschreiben.

"RTX" erfunden? Na, an deinem Beitrag merkt man eher, dass du vermutlich ein Fanboy bist, der hier mal sein Nichtwissen zum Besten gibt und sich damit lächerlich macht. Eine der ersten "APIs" für Echtzeit-RT war OpenRT und jemand, der sich mit Echtzeit-RT sehr intensiv beschäftigt hat, hat sogar auf CB zu diesem Thema eine Artikel-Reihe veröffentlicht.

NVIDIAI hat GDeflate erfunden? GDeflate basiert auf Deflate und da hat NVIDIA überhaupt nichts erfunden. RTX IO wurde zudem 2020 "angekündigt". Zu dem Zeitpunkt war bereits bekannt, was AMD zusammen mit Sony als auch Microsoft "ermöglichen" wird, was diese Sachen angeht. Erfunden? Von wegen.

Und bei DLSS und Co kann man dann auch streiten, ob NVIDIA "Upscaleing" erfunden hat. ... Die PlayStation 4 Pro brachte Checkerboard-Rendering. Dazu gab es entsprechende Upscaleing-Techniken bei Foto und Film bereits vorher, zwar nicht mit KI "verbessert", aber auch bereits sehr gute Algorithmen.

Man kann das hier an der Stelle drehen und wenden wie man will, ATi war bei GPGPU einige Monate früher auf den Markt und waren damit die ersten - 2006. NVIDIA zog 2007 mit CUDA nach. CUDA war dann das bessre Produkt und hat sich entsprechend auch schneller weiter entwickelt, während AMD nachder Übernahme von ATi quasi viele Ressourcen streichen musste.

 

[ETI1120]

CUDA war dann das bessre Produkt und hat sich entsprechend auch schneller weiter entwickelt, während AMD nachder Übernahme von ATi quasi viele Ressourcen streichen musste.

Klare langfristige Ziele zu setzen und auf diese konsequent schrittweise zuarbeiten war schon immer das was Nvidia ausgezeichnet hat. Und dafür muss man Jensen Huang respektieren.

ATI ist ein ganz anderes Kapitel. Als ATI von AMD übernommen wurde waren die eben erst dabei die ganzen Übernahmen zu verdauen, die sie selbst in den letzten Jahren getätigt hatten.

Die Übernahme selbst würde ich eigentlich als Paradebeispiel einer gescheiterten Übernahme sehen. Man muss nur schauen wer alles vom Führungspersonal von ATI in den ersten 2 Jahren nach der Übernahme das Unternehmen verlassen hat. Das dürfte in den technischen Abteilungen nicht anders gewesen sei.

Erst 2011 kam das erste Produkt mit CPU und GPU raus, erheblich verspätet. Ich habe nur Schlechtes und nichts Gutes über das Zusammenarbeiten zwischen Ex-AMD und Ex-ATI gehört. Das Klima hat sicher einiges erschwert. Das große Streichen hat erst 2009 begonnen, aber das dürfte die internen Probleme noch verschäft haben.

Das eigentliche Desaster ist aber, dass AMD die APUs nie angemessen mit Software unterstützen konnte. AMD wusste frühzeitig*) dass sie Software brauchen, aber sie sind nie auf einen grünen Zweig gekommen. So ist sind Games der einzige Anwendungsfall für APUs. In Anwendungen liegt die im Vergleich zur CPU enorme Rechenleistung der iGPU brach.

*) Am 26 November 2007 hat AMD Phil Roger zum Corporate Fellow ernannt.

Rogers wird eine Schlüsselrolle bei der Softwareentwicklung für AMDs "Fusion"-Technologieinitiative spielen, bei der CPUs und GPUs kombiniert und integriert werden, um die Energieeffizienz und die Leistungsfähigkeit zu verbessern. Rogers wird sich auf die Softwareanforderungen konzentrieren, die notwendig sind, um die GPU und die CPU so zusammenzubringen, dass die Systemleistung optimiert wird und gleichzeitig die Software- und Anwendungsflexibilität erhalten bleibt.​

​

"Die Softwareentwicklung ist ein entscheidendes Werkzeug, das AMD nutzt, um Lösungen auf Plattformebene zu schaffen, die das Erlebnis für den Endbenutzer verbessern", sagte Ben Bar-Haim, Corporate Vice President, Software, Graphics Products Group bei AMD. "Phils einzigartige Talente sind entscheidend für die Beschleunigung der Anwendungsleistung durch die Optimierung der Interaktion von Hardware und Software."​

​

AMD beschäftigt weltweit mehr als 1.200 Softwareexperten, die sich darauf konzentrieren, das Erlebnis für den Endbenutzer zu verbessern und die Plattform- und Anwendungsinnovationen der Kunden besser zu unterstützen. Die Software-Teams konzentrieren sich auf die Bereitstellung von Hardware-Erweiterungen, neuen Anweisungen, Gerätetreibern, Entwicklungstools und mehr.​

Phil Rogers hat auch HSA unermüdlich promotet. Im Jahr 2015 hat AMD die Strategie bei der GPGPU Software auf ROCm umgestellt. Im Oktober 2015 hat Phil Rogers AMD verlassen und im selben Monat bei Nvidia angefangen. Er ist heute Server Software Architect und Vice President of System Software bei Nvidia.