News Neue Strategie: AMD will auch ein Software-Unternehmen werden

[Aslo]

Konzerne wollen viel, wenn der Tag lang ist...

 

[Northstar2710]

Erstmal ist heute FSR 3.1 auf GPUopen erschienen https://gpuopen.com/learn/amd-fidelityfx-sdk-1-1/

 

[Topflappen]

Darauf warte ich als ehemaliger Besitzer einer ATI 8500 jetzt schon 23 Jahre.
Wenn ich die bisherigen Versuche betrachte ne vernünftige Software auf die Beine zu stellen, mutet das wie ein Kniefall vor Nvidia an, oder als ein Aprilscherz.

 

[blackiwid]

Habe ich was verpasst? Wo waren jenseits von der damals aktuellen Version von Battlefield die aber- und aberdutzenden PC-Spiele, die Mantle unterstützten?

Es war ein Marketingerfolg der die kompletten APIs revolutioniert hat, ja eine geschlossene Technik mit DX und Vulkan standards in der Pipeline hatte nicht so viel konkrete Implimentationen, ohne Mantle hätte es nicht dieses DX gegeben oder sehr viel später erst und das selbe für Vulkan, Vulkan ist mehr oder weniger eine Adaption von Mantle nur eben frei.

AMD ware Technologieführer in entscheidender weise Nvidia konnte noch so gut DX11 unterstützen und optimieren ohne DX12 oder Vulkan wären sie komplett gegen die Wand gefahren worden, gerade bei vielen ähnlichen Modellen.

Man kann sagen da Nvidia eine AMD Technologie mit Vulkan unterstützt und selbst DX12 wurde stark inspieriert und es gibt auch kein Nvidia-Vulkan. Hätte Nvidia Mantle entwickelt gäb es bis heute kein von Nivdia unterstütztes Vulkan das daraus hervor gegangen wäre und AMD würde versuchen ihr Mantle zu emulieren oder halt mit nem freien Standard gegen zu halten, höchstens weil sie damit Microsoft vielleicht an der Backe hätten würden sie damit nicht erfolg haben, wobei ich denen schon zu trau das sie auch MS platt machen mitlerweile das ist ja ein Monster das so viel Geld hat das sie wahrscheinlich selbst MS kaufen könnten.

Nein, MS hat nicht auf Mantle reagiert, sondern auf Vulkan, dass große Teile von Mantle assimiliert hat.

Ja und wie wäre das ohne Mantle passiert? Entweder gar nicht oder viel Später...

Wozu auch? Nvidia Karten fuhren mit DX ja gut, nur AMD hatte Probleme mit dem massiven Overhead.

Ja bei AMD wars schlimmer aber auch heute schlägt in jedem Benchmark wo beides da ist selbst DX12 wird noch geschlagen von Vulkan aber du glaubst DX11 hätte Nvidia immer gleich schnell und gut gehalten wie Vulkan... lol...

Oder habe ich wieder die aber- und aberdutzenden PC-Spiele verpasst, die Vulkan unterstützen?

Nix ist gelutscht 100% aller Windows spiele werden von DX12 Calls in Vulkan übersetzt und dann in Linux per Vulkan abgespielt... und ja es gibt auch ein paar Native von Android und co wo ja auch finanzielle ein riesen Markt ist ganz abgesehen oder auch andere Konsolen. Du glaubst doch nicht das Playstation per DX Befehle angesteuert wird das deren Treiber DX versteht.

Selbst die Switch ne NVIDIA Konsole unterstützt offiziell Vulkan ich würde auch vermuten sogar ausschliesslich, seh nicht das die DX benutzen nur ne kleine Minderheit benutzt irgendwie noch DX die Minderheit der PC spieler, und wie gesagt auch da nur noch als Emulation in Linux.

AMD konnte sich damals schon proprietäre Lösungen mit ihrem popligen Marktanteil bei Grafiklösungen gar nicht erlauben und heute erst recht nicht.

Und wo widerspricht das irgendwas was ich gesagt habe? Ich habe gesagt das das ein gutes Modell war, sie hatten da keine Zeit das erst bei Krohnos über Jahre standardisieren lassen, damit war es Gut eine Quasi Vulkan Beta erst zu emulieren und in ein paar Spielen früh anbieten zu können nicht das wieder Nvidia ohne jegliceh Standards schneller ist und den Mart mit ihrem Monopol dicht macht, Frankreich wacht langsam aus die sagen nicht einfach ohh der ganze Markt ein Monopol ist doch egal.

Selsbst wenn sie ohne Standardisierung von Khronos nur selbst das Opensource gemacht hätten hätte das viel Gekostet und Jahre gedauert bis deren Juristen das alles durchsucht hätten ob es gegen irgend ein Patent oder irgendwas verstöst daher war es legitim und klug kurzfristig Proprietär zu gehen solange das Ziel klar ist und man das nicht nur vorschiebt und dann ein release auf den Sanktnimmerleinstag verschiebt.

 

[SSD960]

Vielleicht werden die Treiber dann auch besser. Ein richtiger Schritt.

 

[stefan92x]

Außerhalb der Nerd bubble und öffentlichen Projekten achtet keiner auf open source.

Da kann ich klar widersprechen. Open Source vereinfacht vieles, auch im Business-Umfeld. Und sei es nur, dass es Support vereinfacht, wenn man bei Problemen selber bis in den Quellcode debuggen kann und qualifizierte Bugreports erstellen kann. Auf sowas wird durchaus geachtet.

 

[icetom]

Irgendwie drehen sich unsere Gedanken hier im Kreis. Du schreibst open source hat bestimmte Vorteile, darum ging es in meinem Post gar nicht. Leute in der IT Abteilung (Nerd bubble nicht abwertend gemeint) sind genau die Blase die auf sowas achtet. Du bestätigtst es also.

 

[Vortox]

Ich frage mich ob das jetzt nur AMD oder auch die zugekauften Xilinx Produkte betrifft. Da sind die softwaremäßig einigermaßen gut aufgestellt.

 

[Nooblander]

PC-Spiele, die Mantle unterstützten? Es war kein Erfolg,

Aus Mantel ging Vulkan hervor am Ende.
Das ist dann der Erfolg.

 

[DevPandi]

Man kann für AMD nur hoffen das Sie es nicht zu spät gemerkt haben.

Es hat in dem Fall eigentlich fast nur knapp 25 Jahre gebraucht, damit sie das verstehen. Aber sie haben es kapiert und ich hoffe, dass sie es auch machen.

Ich kann aber sagen, auf der GDC gab es von AMD auch einige interessante Beiträge, die auch da auf positive Entwicklung, auch im Bereich RT hoffen lassen.

Natürlich war das wichtig für AMD. Wenn der große Konkurrenz NVIDIA hier aber mit eigenen Entwickler Frameworks "anbietet" und Partnerschaften bei der Entwicklung von Spielen mitwirkt, sodass diese auf NVIDIA optimiert sind während AMD offene Standards und Low-Level Optimierungen benötigt, dann ist klar, dass NVIDIA die Leistung "besser auf die Straße" bringt (Rasterleistung).

Bei der GPU ist es etwas komplizierter und hat auch nur bedingt etwas mit den Partnerschaften von Nvidia mit den Entwicklern zu tun, hat aber auch viel mit der damals gewählten Architektur von AMD zu tun und wie der Treiber primär gearbeitet hat.

Das primäre Problem für GCN war die generelle Auslegung auf Wave64, während Nvidia mit Warp32 gearbeitet hat. Im Übrigen liegt in der damaligen Stärke von Nvidia und der Schwäche von AMD heute die Stärke von AMD bei der Auslastung und die Schwäche von Nvidia.

AMD hat mit RDNA die Architektur auf Wave32 "umgebaut" und auch im Treiber etliche Workloads auf Wave32 umgestellt.

Und wenn ich es jetzt richig im Kopf habe - mir raucht langsam der Schädel von den ganzen Whitepapern und Vorträgen:

RDNA und RDNA2: 1 Wave32-Befehl pro Takt, 1 Wave64-Befehl alle 2 Takte.
RDNA3: 1 bis 2 Wave32-Befehle pro Takt, bis zu 1 Wave64-Befehl pro Takt.

Pascal: 2 Warp32-Befehle alle 2 Takte (2 FP oder 2 INT)
Turing: 2 Warp32-Befehle alle 2 Takte (1 FP und 1 INT)
Ampere/Ada: 2 Warp32-Befehle alle 2 Takte (1 FP und 1 INT, 2 FP, 2 INT)

Ist allerdings ein komplexes Thema und nur stark vereinfacht.

Solange es nicht so wird, wie als Microsoft auf einmal eine Hardwarebutze werden wollte...

Es gibt an der Stelle einen entscheidenden Unterschied: AMD muss eine Softwarefirma werden, damit ihre Hardware auch unterstützt wird.

Die beste Hardware nutzt nichts, wenn die Software nicht passt. Es hat durchaus einen Grund, warum AMD aktuell oft nur im absoluten "HPC"-Markt (Supercomputer) eine Alternative zu Intel und Nvidia ist, aber abseits davon eben nicht.

Bei Supercomputern wird oft der ganze Softwarestack von Grund auf angepasst und alle wissen das, dadurch werden auch Algorithmen und Co "individuell" programmiert und dafür auch Geld in die Hand genommen.

Firmen und Co vermeiden aber genau das, weil es sehr teuer ist und greifen daher zur Stangenware und hier bietet Nvidia mit CUDA aktuell das bessere Ökosystem. Genauso beteiligt sich Nvidia an vielen Frameworks und Co und liefert selbst entsprechende Treiber, während AMD das bisher leider oft vermieden hat.

Bis jetzt ja, aber wenn ich mich an die schrecklichen Treiber von 2019/20 für meine RX5700 erinnere wird mir echt schlecht.

Die Treiber damals waren ein großer Umbau, RDNA ist auch eher als Zwischenschritt zu verstehen, damit die Probleme bei RDNA 2 nicht mehr da sind.

Absolut richtig was CB schreibt, sie müssen nicht nur aufholen, sie müssen deutlich besser als der Konkurrent werden, damit die User auch wechseln.

Ja und Nein. AMD muss nicht unbedingt die deutlich bessere Hardware und auch nicht die deutlich bessere Software als die Konkurrenz haben. Zen 1 hat damals bereits gut an den Marktanteilen von "Intel" geknabbert, ohne dass die Hardware deutlich besser war, sondern sie war ein attraktives Angebot, gleiches gilt auch für Zen 2.

Vor Zen gab es praktisch kein AMD im Serverbereich.

Nicht so ganz richtig. AMD konnte ab 2003 mit der K8-Architektur und dem Opertron damals relativ gut von Intel aber auch anderen Anbietern "Marktanteile" sich sichern, weil man x86 "kompatibel" war, aber eben 64 Bit mitbrachte. AMD konnte so bis 2006 sogar sehr deutlich von Intel die Anteile abknabbern und erreichte um die 25 % bei den Servern. Bei den normalen Prozessoren, egal ob Notebook, OEM und Co konnte man sich sogar an die 40 % nähern.

Intel konnte das erst mit dem Core 2 Duo wieder so drehen, dass AMD nicht mehr auf deren Kosten wuchs. Dazu beigetragen hat dann der TLB-Bug sowie später Bulldozer.

Es ist ja nicht nur die Software auch die Hardware von Nvidia ist einfach besser sie arbeitet schneller u. effizienter gerade in diesen Bereichen.

Jaein, kommt darauf an, was man definiert.

 

[4BitDitherBayer]

Jaein, kommt darauf an, was man definiert.

Hab ich doch.

Es ist ja nicht nur die Software auch die Hardware von Nvidia ist einfach besser sie arbeitet schneller u. effizienter gerade in diesen Bereichen.
GPUs von AMD sind eigentlich nur noch fürs Gaming so richtig brauchbar u. das auch nur wenn kein Raytracing mit im Spiel ist. Selbst bei der Video Verarbeitung hat man sich mittlerweile sogar von Intel ARC die Butter vom Brot stehlen lassen. Die Rendern mittlerweile schneller u effizienter als vergleichbare AMD Karten.

 

[StephenFalken]

sollen ne Linux Distribution rausbringen und die auf ihre CPUs und GPUs optimieren. das würde Sinn machen.
denn so richtig Interesse daran, Bugs zu fixen, hat Microsoft nicht.
die zwei Systemsteuerungen bspw.
wann will Microsoft das fixen?
die Versager beim in-stand-by-gehen...
Werbung im Start Menü - absurd!
und und und...
wollen sie ewig abhängig von Microsoft bleiben?

 

[Balikon]

Das ist dann der Erfolg.

Wenn keine Sau Vulkan unterstützt, ist das kein Erfolg. Weder für AMD noch für die Verbraucher.

 

[Northstar2710]

sollen ne Linux Distribution rausbringen und die auf ihre CPUs und GPUs optimieren. das würde Sinn machen.

nein, das macht keinen sin. AMD ist bei Linux sehr aktiv. wichtig ist das alles in den mainkernel wandert, damit möglichst viele distributionen die vorteile genießen können. Ich warte schon auf Kernel 6.11 wo man einzelne kernen verschiedene Pbo frequenzen verpassen kann.
für Heimanwender gibt es genug möglichkeiten um linux für ihre AMD Hardware anzupassen.

 

[tree-snake]

In Zukunft werde AMD zuerst mit den Software-Unternehmen sprechen um deren Bedürfnisse zu verstehen und darauf basierend die passende Software zur optimalen Nutzung der dazu passenden Hardware zu entwickeln.

Wow, sowas hat AMD vorher nicht gemacht? Dachte das wäre absoluter Standard bevor man HW für den Profibereich entwickeln will.

 

[Boimler]

Hoffentlich profitieren davon auch die Treiber. Es sind zwar oft "nur" Kinderkrankheiten. Aber dass man es auch nach dem fünften Update nicht hinkriegt, ein UV-Profil zu speichern, ist schon lästig. AMD geht es wahrscheinlich um mehr, aber da könnte man anfangen .

 

[Nooblander]

Wenn keine Sau Vulkan unterstützt, ist das kein Erfolg.

Es liest sich, das du schlecht informiert bist bei dem Thema.

ID Softwares neuere Doom Games (auch das neu angekündigte), die neuen Woifenstein Teile nutzen ausschließlich Vulkan API ebenso wie Serious Sam Neuauflagen oder auch No Man Sky.

Baldurs Gate 3 und Valheim oder Enshrouded als neuere, bekannte Games bieten Support für die Vulkan Api.
Rainbow Six Siege oder auch Dota supported Vulkan im kompetitiven Bereich.

Hunt Showdown mit der Cry Engine bekommt neben DX12 auch Vulkan Support mit seinem Engine Update im August.

Zudem gibt es Vulkan auch im professionellen Bereich, 3D CAD zum Bsp. Hier mit Autodesk Fusion 360.

Steam/Valve nutzt Vulkan in Verbindung mit Proton damit unter Linux alle Windows Games lauffähig sind, auf dem Steamdeck als Beispiel. Ebenso Wine nutzt Vulkan unter Linux zum ausführen Windows Games usw,

 

[ETI1120]

Also ich finde den Artikel auf Computer Base ziemlich platt. Der Artikel von TPU ist um Längen informativer.

Der Grundtenor des Artikels "AMD kann keine Software" ist nicht richtig, vollkommen unsachlich und beschreibt das Problem nicht.

Ich verstehe auch nicht so recht was die Entscheidung von AMD sich nicht bei ML Commons zu engagieren mit dem Stand der Software zu tun haben soll.

Phil Guido und Jack Huyhn haben gar nicht die Befugnis eine neue Strategie anzukündigen und wenn man das liest was TPU schreibt, haben sie es auch gar nicht gemacht. Sie haben nur dargestellt was AMD in den letzten beiden Jahren für CDNA und ROCm umgesetzt hat.

Aber AMD ist eben nicht nur AMD und ATI, inzwischen gehört auch Xilinx dazu.

Um überhaupt FPGAs verkaufen zu können, musste Xilinx Software zur Programmierung der FPGAs bereitstellen. Xilinx konnte nur mit einer guten Software zum Programmieren der FPGAs zum Marktführer werden.

Mit der Übernahme von Xilinx kam sehr viel Software Know How zu AMD. Es war folgerichtig die Verantwortung für die Software bei Victor Peng zu bündeln. Dies wurde eigentlich schon zum FAD 2022 verkündet. Da hat Victor Peng eine umfassnde Softwarestrategie für AI vorgestellt. Allerdings hat AMD bisher vor allem die Unterstützung für CDNA gepusht.

Mit der Übernahme von Pesando kam nochmals sehr viel Software Know How zu AMD. Auch bei den Zukäufen von den beiden AI Spezialisten im letzten Jahr. Mit all diesen Zukäufen und weiteren Neueinstellungen hat sich die Anzahl der Softwareentwickler verdreifacht.

Wenn man ein bisschen bei LinkedIn gräbt, sieht man, dass AMD in den letzten 2, 3 Jahren sehr viele Leute für die Treiberentwicklung eingestellt hat. Ganz davon abgesehen sieht man auf GPU Open, dass AMD momentan einiges an Software auf die Beine stellt.

Vor 2022 gab es bestenfalls eine Erwähnung von ROCm in den Whitepapers zu CDNA. Seit dem FAD 2022 gibt eigentlich keine Veranstaltung oder Interview bei dem die Führungsriege AMD von AMD bei Thema HPC oder AI nicht über ROCm redet. Auch Lisa Su weist immer wieder gerne auf ROCm hin.

Was allerdings klar ist, ist dass Nvidia mit ihrem Softwarestack weiter ist und vor allem mehr Akzeptanz bei den Entwicklern hat. D. h., alles was AMD bisher mit ROCm gemacht hat, ist nur ein Anfang und es ist noch ein weiter Weg. In vielen Aspekten, unterstützter Hardware, Reife der Software, Akzeptanz bei den Entwicklern, ...

Zum Thema Open Source:
Lisa Su und andere aus der Führungsriege haben mehrfach gesagt, dass AMD keine andere Wahl hat, als auf Open Source zu setzen. Der Grund ist, dass AMD als viel kleinerer Gegenspieler zu Nvidia keine Chance hat, eine weitere Closed Source Lösung neben CUDA am Markt zu etablieren.
Dass diese Einschätzung richtig ist sehen wir daran, wie mühsam es für AMD ist eine Open Source Lösung zu etablieren.

AMD/ATI und Software
Das Problem bei der Software von AMD/ATI, war nicht, sich AMD über die Bedeutung der Software nicht bewusst gewesen wäre. AMD war sich bewusst, dass z. B. die Fusion Strategie ohne Software nicht erfolgreich sein kann. Wenn man ein bisschen gräbt findet man vieles was das bestätigt. Wie zum Beispiel bei der Pressemitteilung zur Beförderung von Phil Rogers zum Corporate Fellow.

Aber letztendlich waren es Lippenbekenntnisse weil AMD nicht dem entsprechend gehandelt hat. AMD hat der Software weder die notwendige Priorität noch die erforderlichen Ressourcen gegeben. Als dann ab 2009 die finanzielle Lage immer schlechter wurde, hat AMD eben zuerst bei der Software gespart. Aus diesem Grund ist die groß angekündigte Fusion Strategie gescheitert. Die Hardware war fertig aber es gab keine Software mit der man GPU und CPU programmieren konnte. An Phil Rogers hat dies nicht gelegen. Phil Rogers ist 2015, als Fusion begraben und ROCm geboren wurde, zu Nvidia gewechselt. Er war war dort bis zu seiner Pensionierung im Oktober 2023 VP System Software, Compute Server Architect.

Als Unternehmen zu wissen was man machen muss, und es konsequent durchzuziehen ist good execution.
Als Unternehmen zu wissen was man eigentlich machen muss, und es eben nicht zu machen ist bad execution.

Bei AMD kam neben langer bad execution in Sachen Software ab 2009 hinzu, dass auch das Geld knapp wurde. Und ROCm hat mit dem Start in 2015 lange darunter gelitten, dass nur wenige Leuten daran gearbeitet haben. Deshalb war der Fokus von ROCm ausschließlich GCN und CDNA.

Fokus auf CDNA und ROCm
Und vieles was nicht ROCm oder nicht CDNA ist, fällt immer noch unter den Tisch. Dass die NPU von Phoenix beim Start keine Softwareunterstützung hatte, fällt auch in den Zuständigkeitsbereich von Jack Huyhn. Dass sie bei vielen Notebooks im BIOS gar nicht aktiviert war ist ein weiteres Meisterstück. Die Krönung war aber, dass die einzigen Leute von AMD die sich darum gekümmert haben, Entwickler der AIE waren. Von der Compute und Graphics Group hat sich niemand blicken lassen, ...

 

[DevPandi]

Hab ich doch.

Ich bin an der Stelle nicht weiter darauf eingegangen, weil das Thema sehr komplex ist und von zu vielen Faktoren abhängt.

Navi 1 und Navi 2 sind - abseits von RT - in vielen Punkten ähnlich bishin zu effizienter als es Turing und Ampere waren. Bei Ampere spielt mit, dass RDNA 2 die bessere Fertigung hatte. Gleichzeitig zeigt RDNA und RDNA2 aber auch, dass AMD prinzipiell effiziente Architekturen können.

Die Umstellung auf Vec32 und auch weitgehend auf Wave32 hat bei AMD sehr viel gebracht, sogar soviel, dass sie mit einer Architektur, die nur halbsoviele Shader hatte, die gleiche Leistung wie Ampere umsetzen konnte. Warum wieso weshalb hab ich vereinfacht im Beitrag schon dargestellt.

RDNA 3 ist in der Form auch kein wirklicher Griff ins Klo, hier gibt es Probleme, die vermutlich aus mehreren Faktoren resultieren. Sei es dass die ROPs ungewöhnlich viel Leistung brauchen, dass der eigentliche Chip zu Eng gepackt wurde und dass hier auch der "Multi-Chip"-Ansatz auch noch so seine Kinderkrankheiten hat.

Zum Thema "Decoder" und "Encoder", die Video betreffen: In dem Fall hängt Intel nicht nur AMD ab, sondern von den Messwerten und möglichen Modi sogar Nvidia. Das ändert an der Stelle aber nicht viel daran, dass für die meisten Menschen es relativ irrelevant ist, ob Nvidia, AMD oder Intel den besten "Encoder" haben. Das sind Diskussionen, die oft eher unter "Techniknerds" geführt werden und die ich nicht mal im Ansatz in der Form in der Videoproduktion kenne, weil da teilweise mit ganz anderen Voraussetzungen gearbeitet wird und man ohnehin bereits das Quellmaterial mehrfach in Echtzeit decodieren sowie dann encodieren muss.

Also ich finde den Artikel auf Computer Base ziemlich platt. Der Artikel von TPU ist um Längen informativer.

Ich hab jetzt mal dein Beitrag geliked, weil ich durchaus verstehe was du meinst. Hier ist oft aber auch das Problem, wir welches Publikum bereitest du das alles auf. Ich stolper darüber ja auch immer noch, ob ich jetzt stark vereinfache, weniger stark, dafür aber langweile und soweiter. Es ist eine Kunst.

Der Grundtenor des Artikels "AMD kann keine Software" ist nicht richtig, vollkommen unsachlich und beschreibt das Problem nicht.

Da gebe ich dir prinzipiell Recht, aber auch hier ist die Frage, ob es die Leser interessiert und wie auch da das Level der Leser ist. Der allgemeine Grundtenor - auch in der Community - ist, dass AMD Software nicht kann und dass Treiber und Co schlecht sind. Dass das nicht so ist, hab ich ja auch bereits oft versucht zu erläutern, klappt nur nicht immer.

Im Endeffekt ist das Problem eher: AMD "kann Software", sie haben es nur bisher abseits des HPC-Marktes schon fast sträflich schleifen lassen.

Ich verstehe auch nicht so recht was die Entscheidung von AMD sich nicht bei ML Commons zu engagieren mit dem Stand der Software zu tun haben soll.

Das Problem ist, dass bei solchen "Treffen", durchaus nicht nur die Nerds anwesend sind, sondern auch oft mal Entscheidungsträger, weil der Nerd der Firma den Chef mitnimmt oder auch umgekehrt. Genauso gehen die Zahlen durch die Presse und es ist damit auch PR, die helfen kann.

AMD nutzt diese Möglichkeit leider nicht, auch weil ihnen zum teil die Ressoucen "fehlten" oder andere Sachen wichtiger sind, gleichzeitig bleibt aber das negative Bild hängen.

Aber AMD ist eben nicht nur AMD und ATI, inzwischen gehört auch Xilinx dazu.

Die Xilinx-Fusion (eine Übernahme würde ich das nicht nennen) ist mit die beste Entscheidung, die AMD treffen konnte. Sie haben jetzt auch im KI-Bereich Know-How eingekauft, das helfen wird und so langsam sieht man da auch die Früchte reifen, aber auch hier, ist es viel zu langsam.

Bei AMD kam neben langer bad execution in Sachen Software ab 2009 hinzu, dass auch das Geld knapp wurde.

Das ist ein Faktor, der mitspielt. Die Probleme sind bei AMD aber Älter gewesen.

Und vieles was nicht ROCm oder nicht CDNA ist, fällt immer noch unter den Tisch.

Und genau das ist mit das Hauptproblem. Im HPC-Markt macht AMD sehr viel und kann da ja auch mit Frontier und Co Erfolge vorweisen.

Das Dumme ist nur, dass auf dem Markt, der am Ende wirklich wichtig ist, davon nichts ankommt. Der "Nachwuchs" fängt in der Schule, dem Studium und in der Ausbildung immer noch mit Nvidia-Hardware und CUDA an, lernt die Tools von Nvidia und Intel kennen.

ROCm ist selbst unter Linux im Endeffekt nur etwas für die "Nerds", die sich mit "Grundlagen" befassen können und möchten. Alle anderen greifen zu Nvidia.

Da ist es auch egal, wie gut RDNA 3 teilweise mit Ada mithalten kann, wenn man ROCm und die ganzen APIs zur Zusammenarbeit überreden kann. Viel zu viel Aufwand und Arbeit.

 

[Novasun]

An dem Artikel stört mich eines am meisten:

Auch Radeon RX, wo AMD seit Jahren bei den Software-Features maximal zu Nvidia aufschließen, aber nie vorangehen konnte, und Epyc, die gegenüber Xeon viel potentere Plattform, die sich nichtsdestoweniger nicht durchsetzen kann, zeugen von der Software-Schwäche des Konzerns.

Was hat Intel euch für den Satz überwiesen?
Das ist eine Behauptung der ich gerne ein paar Fakten gegenstellen will. Wieso spielt Intel bei Großrechner fast keine Rolle mehr. Weil Epyc sich nicht durchgesetzt hat? Weil die Software fehlt? Wieso hat Epyc inzwischen 20% Marktanteil... Wir kamen von faktisch nicht existent im Servermarkt.

Das es "so" langsam geht - da gibt es viele Gründe dafür. Software da ist es aber nicht... Ja das mancher Softwarekonzern nicht Abgenommen hat etc. pe. pe..

Die anfängliche Problematik im Chiplet Design bezogen auf Datenbanken und theoretisch jede andere Software [ungleich schnell je nachdem ob der Cache auf dem eigenen Chiplet reichte oder man beim Nachbarn die Daten holen musste]...

Das sind und waren aber keine reine Softwareprobleme...