AMD kauft Xilinx

[Leonidas]

WSJ:
https://www.wsj.com/articles/amd-is-in-advanced-talks-to-buy-xilinx-11602205553

[prinz_valium_2]

Deswegen ging der Kurs in den Keller.
Aber wenn, dann ist jetzt ein guter Zeitpunkt zum kaufen. Gerade mit den guten Produkten könnte man gut wachsen und mit scale dann ordentliche Margen in den nächsten 3 bis 5 Jahren einfahren.

Welche Synergien gibt es bier bezüglich Chiplet Designs und IO dies?

[Pirx]

Sieht nach einem Deal aus, der AMD weitreichende Möglichkeiten in vielen Märkten eröffnet - wenn auch zu einem hohen Preis. Die Unsicherheit, wie das abgewickelt werden soll, ist allerdings erstmal Gift für AMD-Aktionäre, die sich auf Kursgewinne wegen Zen3 & Co. gefreut hatten (*fauch*).

[Tobalt]

AMD bräuchte das Knowhow definitiv. Aber mein Bauchgefühl sagt dass man sich da etwas überhebt

Welche Synergien gibt es bier bezüglich Chiplet Designs und IO dies?

Nicht so sehr viele denke ich. Dafür sind die FPGA doch zu sehr auf andere Aspekte optimiert als CPU/GPU.

Aber FPGA sind selbst ein hochgefragter Markt. Und wenn in den nächsten Jahrzehnten die von-Neumann-Architektur mehr und mehr abgestreift wird, wird Schaltungsumordnung während der Laufzeit evtl auch wichtig

[stinki]

Intel hatte ja schon vor Jahren Altera gekauft und für gewisse Server Anwendungen könnte eine hoch integrierte Kombination aus CPU + GPU + FPGA durchaus sinn ergeben. Das war auch einer der Beweggründe von Intel für den Kauf damals.

[bnoob]

Intel hat aber Alter ganz gut abgewickelt, wenn ich das richtig im Kopf habe?

[Felixxz2]

Die Synergien sind sicher auch vor allem Skaleneffekte und es ist natürlich ein deutlicher Imagegewinn. Ein Move für die großen Jungs, alleine das ist nicht zu unterschätzen.
Auch kann man auch einfach nur Bundles machen bzw. Kunden von Xilinx zu Epyc überreden etc.

Selbst wenn man die FPGAs nicht integriert, die "politischen" Vorteile dürften doch per se schon sehr interessant sein.

[Sunrise]

Also zumindest geht Xilinx genau in die Richtung, die AMD für die Zukunft benötigt und das ja beim letzten Analyst Day auch angekündigt hat. Sie haben enormes Know-how was Design und Fertigung auf den Cutting-Edge Nodes und Packaging-Technologien (bei TSMC) betrifft. War es nicht Xilinx, die immer den Next-Best Shit implementiert hatten? Das beginnt irgendwo bei High-Bandwidth, geht über 3D-Stacking und endet bei insgesamt extrem hoher Leistungsdichte.

Nur...der Kaufpreis ist natürlich wieder ein Brett, da zuckt man erstmal kurz zusammen. Eventuell brauchen sie das aber, damit man aufgrund der immer teurer werdenen Fertigung und langen Zyklen auf den jeweiligen Nodes mit den neuen Technologien/Implementation in Zukunft mitspielen kann. FPGAs sind natürlich weiterhin stark gefragt, im Datacenter könnte das helfen, um zu Intel aufzuschließen.

[davidzo]

Xilinx ist auf jeden Fall der bessere Kauf als Altera. Also wenn ich die Kombinierte IP und Expertise von AMD und Xilinx im Chipdesign sehe ist die aktuell stärker als die von Altera und Intel.

Altera hat unter Intel ja nur an Marktanteil und Bedeutung verloren, die große Konsolidierung und Synergieeffekte zwischen Xeon und FPGA ist ausgeblieben. Insofern kann ich AMD nicht ganz nachvollziehen wieso man sich jetzt genau so ein Klotz ans Bein lachen möchte wie Intel. Dadurch dass Altera weitgehend an die Intel Fertigung gebunden war hatten die dieselben Verzögerungen die Intel gegenüber AMD ins hintertreffen gebracht hatten. Nur halt gegenüber Xilinx und die sind bei TSMC und HBM noch schneller dabei als AMD selbst. Es kann nur sein, das AMD denkt dass sich die Altera Integration bei Intel langfristig dann doch positiv auswirkt und man auch so etwas braucht um im Rennen zu bleiben.

Schon vor der Aquisition war Altera immer nur die zweite Geige hinter Marktführer Xilinx. Insofern kann ich schon verstehen dass AMD sich da mit Xilinx für die Zukunft besser gerüstet sähe als Intel, zumal man mit Zen3 aktuell auch um knapp 2 Generationen vor Xeon liegt.

[Tobalt]

Mein Eindruck ist auch dass Xilinx Dominanz seit der Intel Übernahme von Altera zugenommen hat.

Aber ist Altera echt an Intel-Prozesse gebunden ?? Haben die denn Kapazitäten dafür und machen die Prozesse bei FPGA sinn?

[davidzo]

Nicht mehr, die machen jetzt auch wohl wieder mit TSMC, weil Intel hat ja noch keinen EUV node in Aussicht.

Aber die ganze Stratix10 Generation hat sich um Jahre verspätet weil man in die 14nm Lieferprobleme gestolpert ist. Wäre der rechtzeitig gekommen wäre das im highend ne Bombe gewesen. So hat man Milliarden Entwicklungsgelder verschleudert die 14nm Designregeln für den Altera FPGA zu erweitern, die technologisch eine Sachgasse waren, weil 10nm auch schlecht verfügbar ist. Die 10nm Agilex FPGAs gingen besser, aber haben auch fast ein Jahr nach dem Launch gebraucht um einigermaßen verfügbar zu sein.
So weit im Entwicklungsprozess ist es viel zu spät noch mal die Fertigung zu ändern, das kommt dann erst bei der nächsten Gen.

Die Prozessentscheidung muss gar nicht mal mit der Aquisition zusammehängen, Altera hatte ja schon kurz davor auf Intel Fertigung gesetzt. Aber in beiden Fällen liegt es an Intel die sich überschätzt haben wodurch Altera nicht wie geplant skalieren konnte, ob nun durch die oder nach der Aquisition ist egal.

[Zossel]

Switche, Ethernet und so ein Zeug wäre auch nicht uninteressant gewesen, was gibt da noch außer Broadcom und Marvell?

[=Floi=]

wo sind denn xilinx chips denn in consumer produkten vertreten? gibt es das wirklich?

[unl34shed]

Das einzig mir bekannte Produkt mit FPGA für den Consumer Markt wäre G-Sync, aber da ist es ein Altera. Oszilloskope würde ich jetzt nicht darunter zählen.

[Benutzername]

Das einzig mir bekannte Produkt mit FPGA für den Consumer Markt wäre G-Sync, aber da ist es ein Altera. Oszilloskope würde ich jetzt nicht darunter zählen.

Für Bastelprojekte werden ein paar FPGA abgesetzt. Als Beschleunigerchip zB in einem BluRay Player oder auch in Settop Boxen. Zum etnschlüsseln in eben jenen Kisten. Bing benutzt FPGAs als Teil der Internetsuchmaschine. Das benutzt man als Konsument indirekt. Manche Netzwerkkarten enthalten FPGA. Könnte auch als Ersatzteil für die Heizungssteuerung zu Hause kommen, wenn es die original Chips nicht mehr gibt. Im Auto natürlich. Gibt bestimmt noch mehr wo FPGA verbaut sind ohne daß man es bemerkt.

[Berniyh]

Ist die Frage, ob es wirklich um Produktsynergien für Consumer geht, glaube ich ehrlich gesagt weniger.

Aber es ist eine Firma die zum Einen ordentlich Umsatz macht und zum Anderen ordentlich Gewinn. Mehr als AMD selbst jedenfalls.
Abgesehen davon geht es vermutlich ein Stück weit auch um IP und evtl. will man ja Teile davon tatsächlich auch für eigene Datacenter Anwendungen ins Portfolio aufnehmen.

[amdfanuwe]

Hab mal mit einem Messsystem von National Instruments gearbeitet. War ein FPGA mit ARM Core drin.
Diese Systeme werden für Maschinensteuerungen, Prototypenbau, Messsysteme etc. eingesetzt.

FPGA eignet sich gut für Prototyping und Kleinserie. Für Großserie würde mann einen eigenen ASIC bauen, nachdem das Prototyping mit FPGA funktioniert :-)

Da die Kosten für die Design- und Testtools auf Grund der zunehmend mehr zu verbauenden Transistoren in kleineren Nodes explodieren, würden sich allein dadurch schon ordentliche Synergieeffekte ergeben. Lassen ja beide bei TSMC produzieren und sind an den neuesten Nodes interessiert.

Zudem arbeiten AMD und Xilinx in ML zusammen: https://www.amd.com/system/files/documents/xilinx-deep-learning-solution-on-amd-epyc-processors.pdf
Würde AMD in Sachen ML ordentlich vorwärts bringen.

Zudem könnten Xilinx zukünftig auch X86 ZEN Kerne integriert haben statt schwacher ARM Kerne.

Desweiteren könnte AMDs Semicustom Abteilung davon profitieren:
Wenn eine Firma eine neues Produkt auf PC mit FPGA Einsteckkarten entwickelt, könnten sie das ganze als Semicustom IC bei AMD fertigen lassen.

Neben den Synergieen könnte AMD zusätzliches Geschäft im Semicustom Bereich generieren.
Summa summarum sehe ich das schon positiv.

[Nakai]

Naja kommt drauf an welche FPGAs man meint.

Die FPGA-SOCs werden bei uns für höhere Stückzahlen benutzt (1~2 Mio) aber auch nur bei speziellen Usecases (ADAS, AI/ML, Low-Latency DSP [LIDAR/RADAR]). Die Gründe sind vielfältig und gehen von Stromverbrauch, Stabilität, Kosten (ja, das auch) bis hin zu Performance (Latency, Throughput). So moderen FPGA-SOCs (Zynq Ultrascale MP oder die Xilinx ACAPs) sind verdammt mächtig und spezielle GPGPU oder andere Embedded Systeme erfüllen nicht alle Anforderungen.

Aus meiner Sicht können wir hier in Zukunft sehr interessante Produkte sehen, wie ein FPGA-Chiplet kombiniert mit GPU-, sowie CPU-Chiplet. Der FPGA kann dann für LowLatency Signalverarbeitung, Preprocessing, AI/ML (Realtime) etc. verwendet werden. Die GPU eben für Grafik und unkritisches Computing und die CPU für die Kontrolllogik. Außerdem sollte man diese Dinger für spezielle Workloads nicht mehr unterschätzen. Die Integration in ein SW-Ecosystem ist auch weniger kompliziert, wie vor Jahren.

[BoMbY]

AMD hatte bereits mal wenigstens 21% Anteile an Xilinx:


In December 1991, a net gain of $46.1 million on the sale or other
disposition of assets was realized, primarily attributable to the sale of 3.5
million shares of Xilinx, Inc. stock. Prior to the sale, the company owned 21
percent of Xilinx and this investment was accounted for on the equity method.
After the sale, the remaining investment represented 5.6 percent of outstanding
Xilinx shares and was accounted for on the cost method.


https://ir.amd.com/sec-filings/filter/annual-filings/content/0000891618-94-000068/EX-13.txt?TB_iframe=true&height=auto&width=auto&preload=false

[amdfanuwe]

Die FPGA-SOCs werden bei uns für höhere Stückzahlen benutzt (1~2 Mio)
Bei den Mengen dürfte sich ein eigener ASIC noch nicht lohnen.

[mboeller]

Bei den Mengen dürfte sich ein eigener ASIC noch nicht lohnen.

Das "lohnen" sollte sich doch gerade stark hin zu größeren Stückzahlen verschieben? Zumindest dann, wenn man den neuesten Prozess benutzen will. Vielleicht wird in 5 Jahren sehr viel mehr über FPGA laufen als jetzt, da sich neue ASIC in 5nm oder 3nm erst bei Stückzahlen >>10Mio oder gar 100Mio lohnen?

[Brillus]

Das "lohnen" sollte sich doch gerade stark hin zu größeren Stückzahlen verschieben? Zumindest dann, wenn man den neuesten Prozess benutzen will. Vielleicht wird in 5 Jahren sehr viel mehr über FPGA laufen als jetzt, da sich neue ASIC in 5nm oder 3nm erst bei Stückzahlen >>10Mio oder gar 100Mio lohnen?
Kommt wohl stark drauf an wieviel Hard-Cores man drin hat und ob man sie für seine Aufgabe braucht. Neben FPGA und neuestem Prozess gibt es ja auch noch die Option abgehangenen Prozess.

[Tobalt]

Wo hier gerade die Zynq SoCs angesprochen wurden.

Hoffentlich bezahlt Intel nicht Schmiergeld an nV um AMD die ARM Lizenz zu entziehen. Damit wären die dann zu einer Neuentwicklung des CPU parts gezwungen.

ODER: was es noch gar nicht gibt: Ein neues Zynq mit Zen Cores statt ARM <3

[amdfanuwe]

Ich reim mir das so zusammen:
Früher konnte sich eine Firma noch die Designtools von Mentor Graphics einkaufen und ein paar fähige Ingeneure konnten einen Chip designen.
Mit zunehmender Komplexität klappt das heutzutage nicht mehr. Dazu braucht es schon spezialisierte Abteilungen, die sich nicht mehr viele Firmen leisten können.
Geht man halt zu einem Semicustom Anbieter.

Ab welcher Menge sich das lohnt hängt von den Kosten und dem Anwendungsfall ab.
Gegenüber einem Eigendesign dürfte ein AMD Semicustom mit fertigen CPU Kernen, FPGA, GPU und eigenem Logik Anteil relativ günstig werden.
Irgendwo gibt es halt ein Punkt, ab dem ein eigener (semicustom) Chip günstiger ist als andere Lösungen.
Sieht man ja auch an den Konsolen. Hätten ja auch einfach einen Mini PC zusammenstellen können.

[Zossel]

Hoffentlich bezahlt Intel nicht Schmiergeld an nV um AMD die ARM Lizenz zu entziehen. Damit wären die dann zu einer Neuentwicklung des CPU parts gezwungen.

Mit so einer Nummer wäre der ARM-Deal mit einem Schlag wertlos, wer würde dann noch ARM bei NV kaufen wollen?

[Tobalt]

Mit so einer Nummer wäre der ARM-Deal mit einem Schlag wertlos, wer würde dann noch ARM bei NV kaufen wollen?

Du hast Recht. Intel als auch nV sind schon mit vielen krummen Dingern durchgekommen, aber dabei ging es stets gegen den Consumer und wenig gegen Firmenkunden

Andererseits kann ich nV auch zutrauen dass sie das Arm Lizenzgeschäft bewusst killen werden um keine CPU Konkurrenz aufzubauen. Stattdessen nutzen sie das Knowhow und bauen selbst nV CPUs. Lukrativ ist das Lizenzgeschäft mWn eh nicht.

[Brillus]

Du hast Recht. Intel als auch nV sind schon mit vielen krummen Dingern durchgekommen, aber dabei ging es stets gegen den Consumer und wenig gegen Firmenkunden

Andererseits kann ich nV auch zutrauen dass sie das Arm Lizenzgeschäft bewusst killen werden um keine CPU Konkurrenz aufzubauen. Stattdessen nutzen sie das Knowhow und bauen selbst nV CPUs. Lukrativ ist das Lizenzgeschäft mWn eh nicht.
Da gibt es mit RISC-V auch schon Alternativen. Und zuerst müssten die mal richtig in CPU rein kommen vor die solche Sachen machen können.

[Zossel]

Andererseits kann ich nV auch zutrauen dass sie das Arm Lizenzgeschäft bewusst killen werden um keine CPU Konkurrenz aufzubauen. Stattdessen nutzen sie das Knowhow und bauen selbst nV CPUs. Lukrativ ist das Lizenzgeschäft mWn eh nicht.

Um damit den Weg von PA-RISC, SPARC und POWER etc. zu gehen?

[Zossel]

Naja kommt drauf an welche FPGAs man meint.

Die FPGA-SOCs werden bei uns für höhere Stückzahlen benutzt (1~2 Mio) aber auch nur bei speziellen Usecases (ADAS, AI/ML, Low-Latency DSP [LIDAR/RADAR]). Die Gründe sind vielfältig und gehen von Stromverbrauch, Stabilität, Kosten (ja, das auch) bis hin zu Performance (Latency, Throughput).

In welchem Bereich liegt eigentlich der Sromverbrauch Custom-Asic vs. FPGA?
Was sind da die Randbedinungen?

[Fusion_Power]

"Xilinx" sagt mir gar nix, muß man die kennen? :confused:

[mboeller]

"Xilinx" sagt mir gar nix, muß man die kennen? :confused:

kannst ja selbst nachlesen: https://en.wikipedia.org/wiki/Xilinx

[amdfanuwe]

In welchem Bereich liegt eigentlich der Sromverbrauch Custom-Asic vs. FPGA?
Was sind da die Randbedinungen?

In einem FPGA gibt es einen Haufen Logikblöcke die man programmieren kann, ob sie sich wie ein AND, OR, XOR, Register, kleine Tabelle etc verhalten sollen ( Ähnlich einer GPU, die jedoch komplexere Kerne für GPU Aufgaben enthält).

Bei einem ASIC werden für ein OR nur ein paar Transistoren benötigt.
Spart eine Menge Fläche und Energie. Zudem kann der ASIC durch optimierte Verbindungswege schneller arbeiten. Sind halt erstmal hohe Investitionskosten.

"Xilinx" sagt mir gar nix, muß man die kennen? :confused:
Als Gamer nicht, als Hardwareentwickler schon.
Ähnlich dem CPU Bereich, wo man es mit Intel und AMD sowie ein paar anderen CPU Herstellern zu tun hat, gibt es Xilinx, Altera ( mitlerweile von Intel aufgekauft) und ein paar kleinerer Hersteller.

[Fusion_Power]

kannst ja selbst nachlesen: https://en.wikipedia.org/wiki/Xilinx
Ich meinte die Frage ehr im Bezug auf unseren Alltag hier. Wiki sagt mir, dass die Firma ehr wenig für "Normalkunden" herstellt, ehr für Firmen wie Automobilindustrie, Telekommunikation usw..

Als Gamer nicht, als Hardwareentwickler schon.
Ähnlich dem CPU Bereich, wo man es mit Intel und AMD sowie ein paar anderen CPU Herstellern zu tun hat, gibt es Xilinx, Altera ( mitlerweile von Intel aufgekauft) und ein paar kleinerer Hersteller.
Yupp, ist wohl ehr nicht für "uns" interessant.
Wobei ich nun schon neugierig bin was AMD ausgerechnet mit so einer Firma vor hat und ob das dann in irgend einer Form auch für uns Endkonsumenten und Gamer von Bedeutung ist.

[gedi]

Hm, für mich nen Panikkauf. Die Firma steht ja nicht umsonst zum Verkauf. Ob AMD damit seine Aktienwerte steigern kann? Ich würde sagen Nö. Und wenn BN failed haben wir quasi ein Monopol

[Brillus]

Hm, für mich nen Panikkauf. Die Firma steht ja nicht umsonst zum Verkauf. Ob AMD damit seine Aktienwerte steigern kann? Ich würde sagen Nö. Und wenn BN failed haben wir quasi ein Monopol
Ne eine ziemlich gute Erweiterung für die Semi Custom-Sparte. Dazu sogar sehr gute Firmen-Bilanz.

Und oben drauf auch viele gute Ingenieure.

Eher eine der besten Übernahmekanidaten für AMD die es aktuell gibt.

[amdfanuwe]

Yupp, ist wohl ehr nicht für "uns" interessant.
Wobei ich nun schon neugierig bin was AMD ausgerechnet mit so einer Firma vor hat und ob das dann in irgend einer Form auch für uns Endkonsumenten und Gamer von Bedeutung ist.
Naja, wenn du Handy Vermittlungsstationen, 5G, Satellitentechnik, Video echtzeitcodierung, Server switches etc uninteressant findest, OK, ist auch nicht mein Ding. Ohne den Kram oder zumindest den Einsatz von FPGAs bei der Entwicklung moderner Technik sähe unsere Welt allerdings noch so aus wie vor 30 Jahren. Spielkonsolen mit Steckmodulen. :smile:
Und nicht vergessen, Geld wird in der Industrie gemacht, Konsumer ist eher Nebenprodukt.
Edit:
AMD will raus aus der Konsumerschiene mit geringen Margen. Server, ML, HPC stehen da auf dem Programm. Die möchten auch gerne bei den Big Boys mitspielen.

[Fusion_Power]

Naja, wenn du Handy Vermittlungsstationen, 5G, Satellitentechnik, Video echtzeitcodierung, Server switches etc uninteressant findest, OK, ist auch nicht mein Ding. Ohne den Kram oder zumindest den Einsatz von FPGAs bei der Entwicklung moderner Technik sähe unsere Welt allerdings noch so aus wie vor 30 Jahren. Spielkonsolen mit Steckmodulen. :smile:
Und nicht vergessen, Geld wird in der Industrie gemacht, Konsumer ist eher Nebenprodukt.
Edit:
AMD will raus aus der Konsumerschiene mit geringen Margen. Server, ML, HPC stehen da auf dem Programm. Die möchten auch gerne bei den Big Boys mitspielen.
Ist mir schon klar, dass wir indirekt von all der "unsichtbaren" Technik profitieren und das es Ohne halt nicht geht. Nur bezweifle ich, dass ich in absehbarer Zeit z.B. nen FPGA-Chip in meinem PC einbauen werde. So meinte ich das. ;) Dachte zudem, AMD ist auch aufm Server-Sektor schon groß.
Wobei ich von netten Retro-Gaming-Emulator Geräten weiß, die FPGAs benutzen, da wird das schon wieder interessant. ^^

[amdfanuwe]

dass ich in absehbarer Zeit z.B. nen FPGA-Chip in meinem PC einbauen werde. So meinte ich das. ;)
Sorry, hatte ich dich falsch verstanden.
Wüßte auch nicht, welchen Mehrwert ein FPGA im PC bringen könnte.

[Nakai]

Bei den Mengen dürfte sich ein eigener ASIC noch nicht lohnen.

Das sind auch keine typischen FPGAs Systeme mehr. Die Zynq Ultrascales und die neuen ACAPs sind heterogene Systeme mit mehreren ARM Kernen einen GPU-Teil und einen fetten DSP-Array. Den eigentliche FPGA-Teil braucht man dann hauptsächlich zusätzliche dedizierte Logik und die ganzen Rechenblöcke effektiv miteinander zu verdrahten. Und ja wir haben wir auch Systeme die erst einen FPGA haben und dann einen ASIC, aber das sind dann wirklich nur einzelne Funktionsblöcke für bestimmte Notwendigkeiten (zb Safety).

[amdfanuwe]

Was heißt schon "typische FPGA Systeme"?
Als Ingenieur habe ich die Aufgabe ein Problem zu lösen.
Wenn es nichts von der Stange gibt, eine CPU nicht schnell genug ist, nimmt man halt einen FPGA für die Datenerfassung, Encodierung, Decodierungs und sonstigen Algorithmen sowie die Ausgabe für die Steuerung von Devices. Die CPU braucht man für Datenübertragung, Speichern, Benutzerinterface eventuell noch GPU für Visualisierung.
Wenn es von der Geschwindigkeit her nicht langt oder Teile davon in genügender Menge benötigt werden, wird es halt einen ASIC.
Also im Prinzip:
Simulation: langsam, billig
CPU: für manches nicht schnell genug, günstig
FPGA: schneller für bestimmte Anwendungen, hat seinen Preis
ASIC: besser gehts nicht, teuer in anfänglichen Investitionskosten, billig in der Masse.

[Skysnake]

Xilinx ist halt auch noch interessant, weil man sich damit die ganzen PHY Kosten teilen kann.

FPGAs sind ja IO Monster. Da gibt es schon viel Platt für Synergien.

[Zossel]

In einem FPGA gibt es einen Haufen Logikblöcke die man programmieren kann, ob sie sich wie ein AND, OR, XOR, Register, kleine Tabelle etc verhalten sollen ( Ähnlich einer GPU, die jedoch komplexere Kerne für GPU Aufgaben enthält).

Bei einem ASIC werden für ein OR nur ein paar Transistoren benötigt.
Spart eine Menge Fläche und Energie. Zudem kann der ASIC durch optimierte Verbindungswege schneller arbeiten. Sind halt erstmal hohe Investitionskosten.

Mich würden Werte aus der Praxis interessieren.

[Tobalt]

Wenn man in FPGA Cpu Kerne nachbaut, landet man bei gleicher Leistung enorm langsamer.. Ich würde mal vorsichtig mit Faktor 100 ansetzen.

Allerdings kann man natürlich Einheiten bauen die es in GPU oder CPU nicht gibt und die für spezielle Aufgaben wie ML prädestiniert sind. Somit lässt sich dass eine GPU oder CPU auch in Punkto Perf/W übertreffen.

[basix]

Einer der Hauptvorteile ist, dass man FPGAs per "Software-Update" upgraden kann. Nicht umsonst werden in vielen Computer-Vision Applikationen FPGAs verwendet. Die Technik / Algorithmen entwickeln sich so schnell, dass sich ASIC Entwicklungen oft gar nicht lohnen. Und schneller / energieffizienter sind FPGAs bei parallelisierbaren Aufgaben gegenüber CPUs auch noch - oder gar erst genug schnell damit man die Tasks in Echtzeit ausführen kann.

ASICs lohnen sich nur bei hohen Stückzahlen, wenn die Technologie dahinter relativ stabil ist und/oder wo Low Power sehr wichtig sind.

AMD will raus aus der Konsumerschiene mit geringen Margen. Server, ML, HPC stehen da auf dem Programm. Die möchten auch gerne bei den Big Boys mitspielen.

AMD hat mit allen erschienenen Produkten seit Zen 2 / RDNA1 eine Bruttomarge von >50%. Man verdient also auch an Consumer Produkten sehr gut Geld und ausserdem bringt das Stückzahlen (NRE Kosten, Economy of Scale). Einzige Ausnahme werden die Konsolen SoCs sein. Dort hat man dann aber 5-7 Jahre eine Cash Cow ohne grossen Arbeitsaufwand, deswegen ist hier eine geringere Bruttomarge akzeptierbar. Weil Gewinn ist Gewinn, vor allem wenn man keinen Aufwand mehr damit hat.

Beim Xilinx Deal würde ich technologisch einige Vorteile und Synergieeffekte sehen. Aber 30 Mia. Dollar sind sehr viel Geld, welches AMD mMn einfach noch nicht hat. Deswegen sehe ich die Übernahmegerüchte mit Skepsis an. Wenn AMD so viel Geld wie Nvidia oder Intel hätte, hätte ich gesagt ja das passt.

[|MatMan|]

Na hoffentlich verhebt sich AMD da nicht so wie damals mit ATI. Und hoffentlich hat AMD eine Vision für die Zukunft, in der die Übernahme eine wichtige Rolle spielt. Hier im Forum hatte die bisher noch niemand. Nur für das Know-How mit neuen Herstellungsprozessen klingt für mich viel zu kurz gedacht und zu teuer.
NVIDIA'S ARM Deal macht da im Vergleich deutlich mehr Sinn bei gar nicht so stark unterschiedlichen Kosten.

Ist schon was zur Finanzierung bekannt? In dem Artikel, den ich gelesen habe, stand leider nichts dazu.

[amdfanuwe]

Mich würden Werte aus der Praxis interessieren.
Für welche Aufgabe?
Das ist wie der Vergleich zwischen Sportwagen(DSP), Familienkombi(CPU), Handwerker Kastenwagen(FPGA) und LKW(GPU).
Alles Fahrzeuge(ASIC) und glücklich wirst du nur, wenn du für deine Anwendung das Richtige zur Verfügung hast.
Wenn das nicht reicht, kann man halt seine eigene Ideen in einem ASIC umsetzen und dabei kommen dann spezialisierte Varianten heraus, Formel1 Renner, Go Cards, Kleinbusse, Reisebusse, Pritchenwagen, Schwerlaster, SUV ...
Muss sich halt rechnen ein eigenes Design aufzulegen.

Wenn man Standardlogik im FPGA nachstellt, denk ich auch dass Faktor 10 - 1000 der FPGA langsamer, Ernergieaufwändiger und größer ausfällt.
Für neue Aufgabenstellungen, für die es noch keine Standardlösungen gibt, ist das FPGA dann erst mal die einzige Möglichkeit die Aufgabe zu realisieren.
Daher FPGA vornehmlich für Entwicklung und Kleinserie.
Entweder mit integrierten ARM Kernen, als Coprozessor oder Stand alone, wenn keine wesentlichen CPU Funktionen benötigt werden.
Ein FPGA umzuprogrammieren dauert übrigens auch ein paar Millisekunden.

Ist wie beim Vergleich CPU - GPU. Eine CPU kann auch die Pixel berechnen, aber nur 4 - 16 Stück auf einmal während die GPU eben ein paar tausend Pixel pro Takt durchsausen lässt. Die CPU ist ist im Vergleich zur GPU verdammt langsam.
Man könnte auch CPU Aufgaben auf der GPU laufen lassen. Wäre nur einiges langsamer und hätte einen höheren Energieverbrauch.

[unl34shed]

Na hoffentlich verhebt sich AMD da nicht so wie damals mit ATI. Und hoffentlich hat AMD eine Vision für die Zukunft, in der die Übernahme eine wichtige Rolle spielt.

Die Synergieeffekte sind im Servermarkt zu finden, da können FPGAs als Spezial Beschleuniger dienen, die speziell für die einzelnen Aufgaben angepasst werden. Für den Consumer Markt eher uninteressant.

[|MatMan|]

Die Synergieeffekte sind im Servermarkt zu finden, da können FPGAs als Spezial Beschleuniger dienen, die speziell für die einzelnen Aufgaben angepasst werden. Für den Consumer Markt eher uninteressant.
Naja das ist doch ziemliches Wunschdenken. Ich wüsste nicht, dass FPGAs heute in nennenswerten Stückzahlen in Servern verbaut werden, lasse mich aber gern korrigieren. Den Markt müsste AMD also erstmal selbst aufbauen, was extrem viel Auswand bedeutet.
Was wären überhaupt Anwendungen für FPGAs in Servern? AI sicher nicht und HPC kann ich mir auch nicht vorstellen, abgesehen von einer kleinen Nische - und dafür 30 Mia.?

[amdfanuwe]

Naja das ist doch ziemliches Wunschdenken. Ich wüsste nicht, dass FPGAs heute in nennenswerten Stückzahlen in Servern verbaut werden, lasse mich aber gern korrigieren.

In Switches und Routern versteckt.


Was wären überhaupt Anwendungen für FPGAs in Servern? AI sicher nicht
AMD, Xilinx Claim World Record for Machine Learning Inference
https://www.tomshardware.com/news/amd-xilinx-machine-learning-inference-record,37885.html

[Skysnake]

Kommt immer drauf an wie viel io du drin hast. Oft ist die Frequenz aber halt Faktoren niedriger.

Man kann bei FPGAs kaum 100MHz+ erreichen wenn es etwas komplexer ist.

Im Asic sind dann auch 2-3 GHz drin.

So Effizienzmäßig würde ich ca nen Faktor 10 in den Ring werfen.

Wobei man da halt auch davon ausgeht, dass das Design noch in einen einzelnen FPGA passt. Das ist ein haupt Problem mit denen. Irgendwann geht der Platz aus und dann kannst dein Design halt vergessen

[Brillus]

Also ich sehe die Snyergien vor allem im IO-Design und anderm Low-Level Zeugs(Transitoroptimierungen). Und natürlich auch das man sich im dem Bereich so sehr gute Leute reinholt, denke die sind eher selten.

Auserdem sehe ich es als gute Erweiterung der Semi-Custom Sparte, da kann man noch was zwischen Chip von der Stange und ganz Semi-Custom anbieten.

[Nakai]

Also wenn AMD Xilinx kauft, dann hat das einen Grund.

Xilinx ist halt auch noch interessant, weil man sich damit die ganzen PHY Kosten teilen kann.

FPGAs sind ja IO Monster. Da gibt es schon viel Platt für Synergien.

Jup.

Wie wärs mit einem ACAP-Chiplet?;)

Wenn AMD Xilinx aufkauft, sehen wir erstmal Synergien in dem Bereich, dass die SW-Ecosysteme angeglichen werden. Im Bereich der AI sind FPGAs im Datacenter für Inference extrem stark. Die DL-Netzwerke müssen aber auch noch trainiert werden. Da kommt dann CDNA ins Spiel. Ein DL-Netzwerk auf einen FPGA zu bringen ist schon ein bisschen anstrengender, wegen der reduzierten Numerik auf diesen Dingern. Kein FP16 oder BFloat16, sondern nur INT-Arithmetik. Da muss das Training und Topologie der Netzwerke schon angepasst werden.

Als nächsten oder parallelen Schritt könnten wir Packages mit einen Zen-Chiplet+IO-Die+FPGA+HBM2/3 sehen. Das wär auch AMDs Einstieg in den Automotive-Sektor. Die FPGAs sind schon ASIL-Zertifiziert und Xilinx ist auf jeder Einkaufsliste eines jeden OEMs oder Zulieferers.

Wichtig ist auch, dass das Kern-Segment von Xilinx fortbesteht. Das generiert bereits Umsatz und Gewinn. Die Xilinx-Aktie liefert auch eine Dvidende.

[Kriegsgeier]

Sehr gute Deutsche Analyse bezüglich

https://www.elektroniknet.de/elektronik/halbleiter/der-grund-fuer-eine-uebernahme-von-xilinx-durch-amd-180176.html

[y33H@]

Klar zielt das auf Datacenter ab.

[pipin]

Sehr gute Deutsche Analyse bezüglich

https://www.elektroniknet.de/elektronik/halbleiter/der-grund-fuer-eine-uebernahme-von-xilinx-durch-amd-180176.html

Der Artikel ist aber optimistisch beim Marktanteil von AMD bei den Servern vor Epyc. Aus der 5 kann man getrost 1 % machen.

[unl34shed]

Also hiernach sind es 5.8% für Server.

https://www.heise.de/news/Ryzen-Epyc-und-Athlon-AMD-erzielt-hoechsten-CPU-Marktanteil-seit-2013-4863767.html

[pipin]

Also hiernach sind es 5.8% für Server.

https://www.heise.de/news/Ryzen-Epyc-und-Athlon-AMD-erzielt-hoechsten-CPU-Marktanteil-seit-2013-4863767.html

Ja jetzt inklusive IoTs. AMD sagt ja selbst nach eigener Zählweise sind sie bei 10%.

Ich sprach aber von vor Epyc. also 2016 und das meinte ja auch der Artikel.

[JVC]

Passt :up:

Schade das ich nicht schnell 20K in AMD für 2Dollar versenkt habe ....
(jetzt steige ich nicht mehr ein)

M.f.G. JVC

[prinz_valium_2]

Passt :up:

Schade das ich nicht schnell 20K in AMD für 2Dollar versenkt habe .... 100+...
(jetzt steige ich nicht mehr ein)

M.f.G. JVC

Wir ärgern und alle, dass wir nur 2k und nicht 20k reingesteckt haben und auch schon ein paar Anteile wieder verkauft.
So ist das leben

[JVC]

Wir ärgern und alle...
Jo man ^^, 20K bei 2Dollar ....
Das wäre für so Manchen schon die Pensionsvorsorge...

Ich ärger mich "nicht"... hab auch so nicht zu wenig... ;)

M.f.G. JVC

[Zossel]

Sehr gute Deutsche Analyse bezüglich

https://www.elektroniknet.de/elektronik/halbleiter/der-grund-fuer-eine-uebernahme-von-xilinx-durch-amd-180176.html

Ah, die haben auch was mit Ethernet im Angebot:

Das aktuelle SmartNIC-Angebot von Xilinx ist Teil der Alveo-Kartenpalette, die Alveo U25


Lustig ist das für https://www.xilinx.com/publications/product-briefs/alveo-u25-product-brief.pdf nur Linux-Treiber (keine Windows-Treiber) angeboten werden :-)

[Zossel]

Was hat sich AMD da eigentlich gegönnt?

Cloud Onload is a high performance network stack from Solarflare (https://www.solarflare.com/) that dramatically reduces latency, improves CPU utilization, eliminates jitter, and increases both message rates and bandwidth. Cloud Onload runs on Linux and supports the TCP network protocol with a POSIX compliant sockets API and requires no application modifications to use. Cloud Onload achieves performance improvements in part by performing network processing at user-level, bypassing the OS kernel entirely on the data path.Cloud Onload is a shared library implementation of TCP, which is dynamically linked into the address space of the application. Using Solarflare network adapters, Cloud Onload is granted direct (but safe) access to the network. The result is that the application can transmit and receive data directly to and from the network, without any involvement of the operating system. This technique is known as “kernel bypass”

https://www.xilinx.com/publications/onload/sf-onload-couchbase-cookbook.pdf

Und da kommt dann sowas bei raus:

Key Observations from Performance Testing• Solarflare’s Onload delivers an average performance gain of 300% for Memcached when measuring 128byte GET requests per second (RPS) across the entire range of one to 28 instances using multiple ports over 25GbE with two physical clients each spawning up to five million parallel connections.• Using 100GbE and all the same settings as above the average benefit was an impressive 280%.

https://www.xilinx.com/publications/resutls/onload-memcached-performance-results.pdf

[Benutzername]

Ah, die haben auch was mit Ethernet im Angebot:




Lustig ist das für https://www.xilinx.com/publications/product-briefs/alveo-u25-product-brief.pdf nur Linux-Treiber (keine Windows-Treiber) angeboten werden :-)


Warum sollte man Windowstreiber schreiben für Cloudserver? Die laufen doch praktisch alle auf Linux. Manchmal vermutlich auch *BSD.


Der Xilinx Kauf passt dann ja zu intels Kauf von diversen Netzwerkspezis und nvidias Kauf von Mellanox und ARM um alles aus einer Hand für Datacenter, Supercomputer usw. anzubieten.

[prinz_valium_2]

Ist unter Dach und Fach

https://ir.amd.com/news-events/press-releases/detail/977/amd-to-acquire-xilinx-creating-the-industrys-high?sf239269550=1

[Troyan]

Verstehe ich immer noch nicht. Xilinx und AMDs GPU stehen im direkten Konkurrenzkampf für (DL-)Datacenter. Imo ist das der Tot der GPUs. $35 billionen sind eine Menge für eine Firma, die im Datacenter-Bereich nicht relevant ist.

Ist der andere Kram so bedeutend?

[SKYNET]

Verstehe ich immer noch nicht. Xilinx und AMDs GPU stehen im direkten Konkurrenzkampf für (DL-)Datacenter. Imo ist das der Tot der GPUs. $35 billionen sind eine Menge für eine Firma, die im Datacenter-Bereich nicht relevant ist.

Ist der andere Kram so bedeutend?

es geht um die jetzt gewonnene infrastruktur... xilinx hat die füsse überall schon drinne wo AMD gerne reinwollte... haben sie nun, fertig.

der deal wird AMD in dem sektor massiv vorranbringen.

[Pirx]

unter Dach und Fach noch nicht, die Vorstände haben zugestimmt, die Aktionäre müssen noch mitmachen, soll bis Ende 2021 dauern The acquisition is subject to approval by AMD and Xilinx shareholders, certain regulatory approvals and other customary closing conditions. The transaction is currently expected to close by the end of calendar year 2021. Until close, the parties remain separate, independent companies.

[prinz_valium_2]

unter Dach und Fach noch nicht, die Vorstände haben zugestimmt, die Aktionäre müssen noch mitmachen, soll bis Ende 2021 dauern

Wohl wahr.

[BoMbY]

Verstehe ich immer noch nicht. Xilinx und AMDs GPU stehen im direkten Konkurrenzkampf für (DL-)Datacenter.

Standen. Ich sehe z.B. schon Potential für kombinierte Beschleunigerkarten mit FPGA und GPU, vor allem wenn die Unified Memory haben.

[Brillus]

Standen. Ich sehe z.B. schon Potential für kombinierte Beschleunigerkarten mit FPGA und GPU, vor allem wenn die Unified Memory haben.

Schon mal geschrieben, ich sehe da eine weitere Option zwischen Semi-Custom und Stock Ware.

Sonst halt viel Synergie bei entwicklung im Bereich Analoge/IO und low level Transitoroptimierung.

[Troyan]

Standen. Ich sehe z.B. schon Potential für kombinierte Beschleunigerkarten mit FPGA und GPU, vor allem wenn die Unified Memory haben.

Kosten sind ein riesiger Faktor für Datenzentren. FPGA und GPUs sind Konkurrenzprodukte. Wenn ein Produkt mehr Funktionen abbilden kann, umso kosteneffizienter für die DZ. AMD und Xilinx sind Konkurrenten. Die Kombination von GPU und (dedizierten) FPGA macht hierbei kein Sinn.

[basix]

Kosten sind ein riesiger Faktor für Datenzentren. FPGA und GPUs sind Konkurrenzprodukte. Wenn ein Produkt mehr Funktionen abbilden kann, umso kosteneffizienter für die DZ. AMD und Xilinx sind Konkurrenten. Die Kombination von GPU und (dedizierten) FPGA macht hierbei kein Sinn.

GPU und FPGA ergänzen sich. Für jedes Problem das richtige Werkzeug ;) Es gibt Überschneidungsbereiche und hier können somit Synergien entstehen.

[Flinx]

Stolze 35 Milliarden Dollar lässt sich AMD die Übernahme des Chipproduzenten Xilinx kosten. Je Aktie ergibt sich daraus ein Kaufpreis von 143 Dollar. Diesen will AMD dabei komplett mit eigenen Aktien bezahlen. Fortan würden die bisherigen AMD-Aktionäre 74 Prozent halten, der Anteil der Anteilseigner von Xilinx würde bei 26 Prozent liegen.

[BoMbY]

Abgesehen davon kann AMD nun bald FPGA-Logik direkt z.B. in den GPU einbauen. Den könnte man z.B. als Command Processor (und mehr) nutzten, und dann könnte der Compiler direkt für beide Teile optimierten Code für einen Compute Kernel erzeugen.

[davidzo]

Verstehe ich immer noch nicht. Xilinx und AMDs GPU stehen im direkten Konkurrenzkampf für (DL-)Datacenter. Imo ist das der Tot der GPUs. $35 billionen sind eine Menge für eine Firma, die im Datacenter-Bereich nicht relevant ist.

Ist der andere Kram so bedeutend?

Nicht ganz. Xilinx ist for allem da stark wo AMD aktuell schwächelt (low precision, Int). Dass DP-Leistung und 32bit floating Point in Zeiten von Deep Learning nicht mehr der heilige Grahl des GPU computing ist hat AMD schmerzhaft lernen müssen. Der Markt ging komplett an nvidia und selbst Intel ist hier mit bfloat16 und kommenden GPUs besser aufgestellt. Ich denke das Portfolio von Xilinx ist eher eine ideale Ergänzung zur schwächelnden CDNA Architektur. CDNA ist wiederrum perfekt für HPC, wo Xilinx bisher wenig anbietet.
Xilinx hat ein großes Portfolio an PCIe4 Beschleunigern und Netzwerklösungen gebaut, die perfekt zu AMDs Epyc passen und in Zukunft eine bessere Ingtegration a la nvidia Mellanox ermöglichen.

[BoMbY]

Apropos Mellanox. NVidia's Mellanox scheint eine Menge Gedöns von Xilinx einzukaufen:

Mellanox Innova-2 Flex Open Programmable SmartNIC is a network adapter card that
combines ConnectX-5 with a fully-open programmable Xilinx® FPGA

[...]

Users can easily develop and deploy FPGA applications, utilizing the Xilinx Vivado Design Suite
development environment and Mellanox tools suite. The Vivado license is to be obtained from Xilinx

https://www.mellanox.com/related-docs/prod_adapter_cards/PB_Innova-2_Flex.pdf

[Relic]

Stolze 35 Milliarden Dollar lässt sich AMD die Übernahme des Chipproduzenten Xilinx kosten. Je Aktie ergibt sich daraus ein Kaufpreis von 143 Dollar. Diesen will AMD dabei komplett mit eigenen Aktien bezahlen. Fortan würden die bisherigen AMD-Aktionäre 74 Prozent halten, der Anteil der Anteilseigner von Xilinx würde bei 26 Prozent liegen.

Ist doch ein super Deal für beide Seiten. Xilinx Aktionäre bekommen einen relativ hohen Kurs und AMD muss keine Geldreserven locker machen und kann vom hohen Aktienkurs profitieren.

[YfOrU]

Patrick@STH hats ganz gut zusammen gefasst: https://www.servethehome.com/amd-to-acquire-xilinx-continuing-consolidation/

[stinki]

AMD kann dann auch FPGAs mit Zen-Cores bauen.
Früher waren dort PowerPC-Cores und heute sind dort ARM-Cores drin.
Ich denke gerade die Kombination aus FPGA und CPU plus die DSPs die in den FPGAs drin sind ermöglichen ganz neue Lösungen und Produkte. Die Logic der FPGAs kann ja auch ganz oder teilweise zur Laufzeit umkonfiguriert werden.
Mich wundert es halt sehr, dass Intel + Altera noch kein solches Produkt für den Serverbereich, von dem ich wüsste, herausgebracht haben. Das war einer der Hauptgründe für den Kauf von Altera.
Und damit wird AMD ein noch größerer Kunde bei TSMC, Xilinx ist ein langjähriger Kunde und Partner von TSMC, die immer die ersten waren die wirklich große Chips dort in einem neuen Prozess hergestellt haben.
Für mich ist das die beste Fusion/Übernahme der letzten Jahre im IT Sektor. Ich hoffe AMD macht da mehr draus als Intel. Xilinx ist auf jeden Fall die letzten Jahre auch immer vor Altera gewesen. (ich habe früher sehr, sehr viel mit Xilinx FPGAs gearbeitet und das hat echt Spaß gemacht mit der Firma zusammenzuarbeiten, die wussten immer was sie tun)

[Wörns]

Wenn der Kauf von Xilinx keine gute Ergänzung für AMD ist, mit welchem Ziel hat dann Intel Altera gekauft?
MfG

[Loeschzwerg]

+1 für den Link von YfOrU

Mich wundert es halt sehr, dass Intel + Altera noch kein solches Produkt für den Serverbereich, von dem ich wüsste, herausgebracht haben.

Also solche hybriden Prozessoren (CPU + FPGA auf einem Träger) gibt es schon:
https://ark.intel.com/content/www/de/de/ark/products/139940/intel-xeon-gold-6138p-processor-27-5m-cache-2-00-ghz.html

[davidzo]

Ziemlich beeindruckend was AMD da für einen Technologiekonzern baut.

Der gemeinsame market Cap von AMD Xilinx sind 135Mrd Dollar.

Intel kommt nach den jüngsten Kursschwankungen gerade mal auf 205Mrd. Und das beinhaltet natürlich Altera, die jüngst zum verkauf angebotene Flashspeichersparte, Netzwerk, 5G etc.

Es ist nicht lange her da war Intel 10mal soviel wert wie AMD, aber mittlerweile kämpfen die beiden ganz klar in einer Liga und auch was die breite der Produktpalette angeht liegen da zwar andere Schwerpunkte, aber ich kann nicht sagen welche Palette nun größer ist. AMD+ATI+Xilinx oder Intel+Altera+Networking.

Krasse Zeiten in denen wir leben...

[Screemer]

Wenn der Kauf von Xilinx keine gute Ergänzung für AMD ist, mit welchem Ziel hat dann Intel Altera gekauft?
MfG
und nvidia mellanox?

[Troyan]

Mellanox verkauft Netzwerktechnik. Das passt perfekt ins Portfolio von nVidia, um Supercomputer zu bauen. Xilinx produziert Konkurrenzprodukte zu AMD. Das passt null ins Portfolio.

Was Xilinx jedoch hat, ist Umsatz. Die machen 1/4 vom dem, was AMD macht. Das sieht toll in Quartalsberichten aus, da AMD sich nicht verschulden muss. Immerhin kommt es für Aktionäre zu einem Wertverlust von 1/3 der eigenen Aktien...

[amdfanuwe]

Xilinx produziert Konkurrenzprodukte zu AMD. Das passt null ins Portfolio.
Mumpits. Xilinx hat weder CPU noch GPU Produkte und AMD hat kein FPGA.
Da gibt es keine Konkurrenzprodukte.
Die ergänzen sich wunderbar.

[Tobalt]

Sehe GPU und FPGA auch nur bedingt als Konkurrenten..

Selbst wenn ist das nicht immer schlecht. Erst dieses Jahr hat Analog Instruments den Konkurrent Maxim gekauft. Die entstehende Konsolidierung kann helfen einem noch größeren Konkurrenten (Texas in dem Fall; hier Intel oder nVidia) besser das Wasser zu reichen

@Loeschzwerg: Diese Xeon Linie ist schon ein ganz schöner Brocken und kostet ein paar Riesen. Ich glaube stinki spielt eher auf sowas wie die Cyclone SoC oder die Zynq Linie an. Bisher verwenden die zB Cortex A9.

Man ist also was ALU/FPU Power angeht, in den Dingern doch stark limitiert, selbst im Vergleich zB. zu einer kleinen x86 CPU wie dem Athlon 3000GE

[Loeschzwerg]

Ich glaube stinki spielt eher auf sowas wie die Cyclone SoC oder die Zynq Linie an. Bisher verwenden die zB Cortex A9.


Stimmt, in diesen Dimensionen ist bisher nichts bekannt. Da kommt vielleicht auch erst eine Reaktion sollte AMD dort etwas planen.

Aber allgemein schon brutal was sich hier am Markt gerade tut. Ich weiß nicht ob ich das gut finden soll wenn immer mehr IP bei den ganzen großen Firmen sitzt. Unabhängig davon dass die Entscheidung von AMD natürlich richtig war/ist.

[Digidi]

Nvidia Simuliert ja mit Cadcenc Systemen Ihre GPUs. Cadence hat glaube ich die Xilinx Chips drinnen die man braucht um die GPUs zu simulieren. Der Kauf von Xilinx hat wirklich ein geschmäckle.

https://www.youtube.com/watch?v=650yVg9smfI
https://www.cadence.com/ko_KR/home/company/newsroom/press-releases/pr/2019/cadence-launches-protium-x1--the-first-scalable--data-center-opt.html
https://www.youtube.com/watch?v=6jHW_MjeDbc

[Zossel]

Nvidia Simuliert ja mit Cadcenc Systemen Ihre GPUs. Cadence hat glaube ich die Xilinx Chips drinnen die man braucht um die GPUs zu simulieren. Der Kauf von Xilinx hat wirklich ein geschmäckle.

Zeigt eigentlich nur das FPGAs weiter verbreitet sind als manche hier glauben.

[unl34shed]

Nvidia Simuliert ja mit Cadcenc Systemen Ihre GPUs. Cadence hat glaube ich die Xilinx Chips drinnen die man braucht um die GPUs zu simulieren. Der Kauf von Xilinx hat wirklich ein geschmäckle.

Und welches? In den PCs bei Nvidia werkeln sicher auch Intel/AMD CPUs, das ist ungefähr genau so eine "Schlagzeile" :eek:

[Digidi]

@unl34shed

wir reden hier vom Kern eines sehr sehr sehr speziellen Produktes und nicht von einer 0815 CPU GPU. Das ist ein Chip der nur für soche Zweche gefertigt wurde. Das nutzen vielleicht 5 Große Unternehmen weltweit.
Ich vermute mal das Xilinx und Intel bei so goßen FPGAs sogar quasi Monopolisten sind weil es sich für keine andere Firma lohnen würde hier einzusteigen. Das Risiko wäre einfach zu groß. Du bräuchtest eine große Investitionssumme mit hohem Risiko und dann hast du nur ein kleinen Kundenkreis.

Genau hier liegt dann auch das Problem entweder Nvidia fertigt irgendwann selbst FPGAs oder sie nehmen das was Xilinx ihnen anbietet. AMD wird da bestimmt exklusivrechte nun haben bei solchen Chips was AMD einen Vorsprung bei der Simulation von GPUs und CPUs sichert.

[basix]

Genau hier liegt dann auch das Problem entweder Nvidia fertigt irgendwann selbst FPGAs oder sie nehmen das was Xilinx ihnen anbietet. AMD wird da bestimmt exklusivrechte nun haben bei solchen Chips was AMD einen Vorsprung bei der Simulation von GPUs und CPUs sichert.

Ich halte es für unwahrscheinlich, dass AMD hier ein solches Exklusivrecht einführt. Eher hat AMD Mitspracherecht und kann Custom etwas ins Design giessen, was ihnen nützt.

[SKYNET]

Ich halte es für unwahrscheinlich, dass AMD hier ein solches Exklusivrecht einführt. Eher hat AMD Mitspracherecht und kann Custom etwas ins Design giessen, was ihnen nützt.

naja, ich denke sie werden in zukunft dann NV den zugriff verweigern... wenn das NV somit dann jedes jahr sagen wir mal 6 monate entwicklungszeit extra aufhalst, rechnet sich das schon für AMD ;)

[Nakai]

Xilinx öffnet AMDs Möglichkeit in den Automotive-Markt einzusteigen.

Xilinx-SOCs und FPGAs werden schon lange Zeit im Automotive-Segment verwendet.

Ansonsten ist Xilinx ein Sammelhort an IP. 35 Milliarden $ finde ich zwar keine kleine Summe für AMD aber keine kleine Summe für diese Firma. Außerdem besitzt Xilinx bereits eine sehr gute Stellung im Markt und benötigt keine große Hilfe und kann auf sich alleine stehen. Jeglicher Vergleich mit der ATI Übernahme damals sind an den Haaren herbeigezogen. Es gibt genug Synergiepunkte, man muss nur diese Ausbauen. FPGAs und GPUs sind auch keine direkten Konkurrenzprodukte, auch nicht im Bereich AI. Der Fokus bei FPGAs ist eine höchstperformante und niedrig-latente Ausführung bei Inference-Workloads. Trainings macht man auf GPU- oder andere HPC-Cluster.

[Skysnake]

AMD kann dann auch FPGAs mit Zen-Cores bauen.
Früher waren dort PowerPC-Cores und heute sind dort ARM-Cores drin.
Ich denke gerade die Kombination aus FPGA und CPU plus die DSPs die in den FPGAs drin sind ermöglichen ganz neue Lösungen und Produkte. Die Logic der FPGAs kann ja auch ganz oder teilweise zur Laufzeit umkonfiguriert werden.
Mich wundert es halt sehr, dass Intel + Altera noch kein solches Produkt für den Serverbereich, von dem ich wüsste, herausgebracht haben. Das war einer der Hauptgründe für den Kauf von Altera.
Und damit wird AMD ein noch größerer Kunde bei TSMC, Xilinx ist ein langjähriger Kunde und Partner von TSMC, die immer die ersten waren die wirklich große Chips dort in einem neuen Prozess hergestellt haben.
Für mich ist das die beste Fusion/Übernahme der letzten Jahre im IT Sektor. Ich hoffe AMD macht da mehr draus als Intel. Xilinx ist auf jeden Fall die letzten Jahre auch immer vor Altera gewesen. (ich habe früher sehr, sehr viel mit Xilinx FPGAs gearbeitet und das hat echt Spaß gemacht mit der Firma zusammenzuarbeiten, die wussten immer was sie tun)

Naja, wenn es um leading edge geht hatte Xilinx die letzten Jahre wohl schon sehr zu kämpfen. Das was Sie released haben gab es praktisch nicht als Vollausbau, sondern immer mit mehr oder weniger großen Einschränkungen.

Wenn man dann mal wirklich große Designs hat die die Features auch wirklich voll ausnutzen dann stand man teilweise schon echt blöde da...

[Skysnake]

Nvidia Simuliert ja mit Cadcenc Systemen Ihre GPUs. Cadence hat glaube ich die Xilinx Chips drinnen die man braucht um die GPUs zu simulieren. Der Kauf von Xilinx hat wirklich ein geschmäckle.

https://www.youtube.com/watch?v=650yVg9smfI
https://www.cadence.com/ko_KR/home/company/newsroom/press-releases/pr/2019/cadence-launches-protium-x1--the-first-scalable--data-center-opt.html
https://www.youtube.com/watch?v=6jHW_MjeDbc
Ja das gibt es und ja das ist Schweine teuer so das sich das kaum jemand leisten kann.

ABER da ist der FPGA nur eine Komponente für ein Produkt von Cadence bei dem der Software stack auch entscheidend ist.

Und die großen FPGAs werden auch bei Militärprodukten, Luft und Raumfahrt oder in der Forschung für Detektoren etc eingesetzt. Auch ansonsten sind in manchen Industrieprodukten die großen FPGAs drin.

Klar das sind dann immer alles ziemlich kleine Stückzahlen von Dutzend bis tausende Geräte im Jahr. Unterm Strich verkauft man dann aber doch auch wieder Zehntausende oder Hunderttausende große Chips im Jahr.

Der Markt ist halt ziemlich breit aufgestellt und hat mit Militär, Luft und Raumfahrt sowie Automotiv oft auch sehr exotische Anforderungen. Xilinx kennt und kann das alles. Allein das Wissen über die Anforderungen und die Existenz von funktionierenden Entwicklungsprozessen ist da Gold wert. Also gerade auch für so Dinge wie autonomes Fahren etc.

Für Envidia ändert sich da aber wie gesagt nichts. Die sind mit Ausnahme von gsync kein Xilinx Kunde, sondern ein Kunde von Cadence.

[amdfanuwe]

Xilinx-Samsung SmartSSD Computational Storage Drive Launched (https://www.servethehome.com/xilinx-samsung-smartssd-computational-storage-drive-launched/)
Part of the other driver here is that Xilinx sees computational storage as becoming mainstream, projected to be 5% of the market in only a few years.
Von Datenverarbeitung im Speicher war bei AMD auch schon mal die Rede. Da ging es aber um die Verarbeitung im Basis Die eines HBM Stacks, wenn ich mich korrekt erinnere.
Zumindest scheint das ein Zukunftsthemea zu sein und der AMD Xilinx Merger erscheint immer sinnvoller.

[basix]

Hmm, FPGA hat den Vorteil dass man den "Accelerator" auf den Anwendungszweck oder die Art der gespeicherten Daten abstimmen kann. Das ist sicher eine gute Idee.

Mir kam nur gerade in den Sinn, ob hier auch eine Zen APU je nach Anwendung Sinn machen könnte: Van Gogh hätte 4 CPU Kerne, RDNA2 sowie CVML DSPs von Tensilica direkt integriert. Low Power optimiert und einigermassen günstig zu fertigen. Und via GPU und DSPs lässt sich einiges Number Crunching sehr effizient ausführen.

[BoMbY]

AMD and Xilinx Demonstrate Converged ROCm Runtime Technology Preview at SC20 (https://forums.xilinx.com/t5/Xilinx-Xclusive-Blog/AMD-and-Xilinx-Demonstrate-Converged-ROCm-Runtime-Technology/ba-p/1175091)

[basix]

AMD and Xilinx Demonstrate Converged ROCm Runtime Technology Preview at SC20 (https://forums.xilinx.com/t5/Xilinx-Xclusive-Blog/AMD-and-Xilinx-Demonstrate-Converged-ROCm-Runtime-Technology/ba-p/1175091)

Das geht aber fix :O

[][immy]

Das geht aber fix :O
naja, nur weil wir von der Übernahme erst seit kurzem wissen, können die ja im Hintergrund schon seit einer Ewigkeit zusammen gearbeitet haben. Solche Übernahmen kommen ja nicht selten über lange Partnerschaften zustande.

[basix]

Das ist mir schon klar ;) Dennoch erstaunlich, da es hier inkl. unified memory address space und all den Dingen funktioniert und man sogar die gleichen Libraries wie BLAS etc. obendrauf verwenden kann. Bei CPU + GPU + FPGA mit selbem Software-Stack zu betreiben ist man also auf selbem Weg wie Intels oneAPI - und das eben füher als ich es erwartet hätte.

[BoMbY]

METHOD AND APPARATUS FOR EFFICIENT PROGRAMMABLE INSTRUCTIONS IN COMPUTER SYSTEMS (https://www.freepatentsonline.com/20200409707.pdf)


Systems, apparatuses, and methods for implementing as part of a processor pipeline a reprogrammable execution unit capable of executing specialized instructions are disclosed. A processor includes one or more reprogrammable execution units which can be programmed to execute different types of customized instructions. When the processor loads a program for execution, the processor loads a bitfile associated with the program. The processor programs a reprogrammable execution unit with the bitfile so that the reprogrammable execution unit is capable of executing specialized instructions associated with the program. During execution, a dispatch unit dispatches the specialized instructions to the reprogrammable execution unit for execution. The results of other instructions, such as integer and floating point instructions, are available immediately to instructions executing on the reprogrammable execution unit since the reprogrammable execution unit shares the processor registers with the integer and floating point execution units.



via Reddit (https://www.reddit.com/r/Amd/comments/koqgrv/amds_newlypatented_programmable_execution_unit/)

[basix]

METHOD AND APPARATUS FOR EFFICIENT PROGRAMMABLE INSTRUCTIONS IN COMPUTER SYSTEMS (https://www.freepatentsonline.com/20200409707.pdf)

Das hört sich sehr interessant an. Das könnte ein Durchbruch auf mehreren Ebenen bedeuten, wenn das performant und effizient funktioniert.

Was man damit machen könnte:

Accelerators, welche spezifisch auf die SW angepasst sind und dennoch den Vorteil von Fixed Function Units von normalen ASICs (CPUs und GPUs) nutzen können
Allgemeine IPC Erhöhung von CPUs (z.B. Log, Sqrt, Exp Beschleunigung) und GPUs
Effiziente ARM Emulation
Machine Learning SFUs
Latenzreduktion von kritischen Befehlen (z.B. Single Cycle anstatt X Cycles)
Entschlacken des Frontends und der gesamten Pipeline. Wenig gebrauchte Befehle werden "emuliert". Damit könnte man sich von x86 Altlasten lösen und dennoch SW kompatibel bleiben, ohne die Performance zu killen. Das reduziert die Komplexität der CPU und spart Chipfläche und Energie.
Neue Instruktionen, adaptive Anpassung an neue SW
Mehrfacheinsatz von Execution Units durch adaptiven Einsatz der Ressourcen. FP und INT Einheiten sind "universal" aber die Pipeline wird umprogrammiert. Mit weniger Execution Units kann man mehr Anwendungsfälle abdecken.


Grundsätzlich ist das für alle Arten von Prozessoren interessant (CPUs, GPUs). Tendenziell geht es aber vor allem in Richtung Server und Datencenter, da die SW mit einem Bitfile für die HW-Konfiguration daherkommen sollte. Das bedingt ein entsprechendes Neukompilieren der SW oder AMD erstellt entsprechende Bitfiles für die jeweilige SW (als Fall Back Lösung). Ein dynamisches Anpassen der Pipeline abhängig vom Execution Flow (im Zusammenspiel mit den Prediction Units) wäre wohl der heilige Gral, ist aber wohl extrem schwer. Geil wäre es aber.

Durch die architektonische Nähe von GPU und FPGA ist CDNA2 wohl ein Kandidat für eine erste Umsetzung ;) Hier sehe ich auch den grössten unmittelbaren Vorteil durch die sich schnell wandelnde HPC und Machine Learning Landschaft und die Anzahl Instructions ist verglichen mit x86 relativ gering (somit einfacher umzusetzen). Ausserdem ist hier direkte SW Optimierung auf die HW am naheliegendsten.
Bei Gaming GPUs könnte AMD pro Spiel "Befehlssatzprofile" im Treiber anlegen um Spiele zu beschleunigen (oder die Spielehersteller optimieren das bereits selbst). Angepasste Befehle und Pipelines je nach verwendeter API wären auch denkbar (DX11, DX12, Vulkan, etc.). Bei CPUs und normalen Programmen, welche auch noch zum Teil Uralt sind und oftmals den Intel Compiler benutzen, wird das einfach viel komplizierter.

[Badesalz]

Das ist nicht einfach nur um ggf. CPUs/GPUs pimpen zu können :rolleyes: Das wird für AMD bald überlebenswichtig sein sowas zu haben.

Und man hat damit jetzt auch noch Solarflare. Da kann man sich nun auch mehr basteln als nur Ethernet auf Consumerboards mit der Quali der Intel 2.5Gb Chips.

Der Einkauf geht in Ordnung. Bald überlebenswichtig, wie gesagt.

[basix]

Mir ging es um das Patent und nicht um die Xilinx Aquisition ;) Der AMD / Xilinx Deal macht für AMD sehr viel Sinn (wie du auch sagst). Das obige Patent kann man aber auch ohne eigene FPGAs umsetzen, entsprechende IP kann man auch lizenzieren. Wenn man die IP besitzt ist es aber sicher einfacher.

[Pirx]

Der Zusammenschluß ist anscheinend durch, China gibt das ok, https://www.reuters.com/technology/china-conditionally-approves-amds-35-bln-deal-xilinx-2022-01-27/

[basix]

Nice :)

[Zossel]

Welchen Anteil am Umsatz von TSMC hat Xilinx?

Und wie gut ist Xilinx in Software?

[Tobalt]

Also für mein Empfinden sind die FPGA Tools wie Vivado sehr komplexe Dinger, da steckt sicher viel spezifisches KnowHow über Compiler, Algorithmen, uä.

[Zossel]

Also für mein Empfinden sind die FPGA Tools wie Vivado sehr komplexe Dinger, da steckt sicher viel spezifisches KnowHow über Compiler, Algorithmen, uä.

Diese Art von Software ist bestimmt nicht ganz ohne, mir geht es mehr um Erfahrungen wie buggy die Tools von Xilinx sind, wie ist der Support von Xilinx, etc.

Könnte also AMD im Software Bereich (insbesondere HPC) von möglichen Qualitäten bei Xilinx profitieren?

[fondness]

Mit 14. Februar gehört Xilinx zu AMD, auch die Aktionäre haben mittlerweile zugestimmt:
https://twitter.com/amd/status/1491769334854733826
https://twitter.com/LisaSu/status/1491774565021667336?ref_src=twsrc%5Etfw

[Zossel]

Mit 14. Februar gehört Xilinx zu AMD, auch die Aktionäre haben mittlerweile zugestimmt:
https://twitter.com/amd/status/1491769334854733826
https://twitter.com/LisaSu/status/1491774565021667336?ref_src=twsrc%5Etfw

Und was schnappt sich AMD als nächstes?

[amdfanuwe]

Was brauchen sie denn?

[Zossel]

Was brauchen sie denn?

Interconnects für HPC, Ethernet und Infiniband Beschleuniger.
Software.
Irgendwas mit AI/KI/ML.
Wireless?

[Tobalt]

Also die größte Baustelle gerade im Vergleich zu nV sehe ich aktuell auch bei Software/Algorithmen. Ich vermute mal dass sie sich da ein zwei kleine Fische aus Bereich Computergrafik holen. Mit XeSS und DLSS schwimmt denen sonst der komplette Consumergrafikmarkt mittelfristig davon.

[Skysnake]

Interconnect gibt es nichts am Markt was wirklich relevant ist für HPC würde ich sagen.

Software müssen sie eigentlich nur was pushen was sie haben.

AI/KI/ML ist auch nur das bekannte in neuen Schläuchen.

Wenn Sie was reißen wollen setzen Sie noch andere Datenformate ein wie Posits von Gustafson vorgeschlagen.

Wireless willst du nicht anfangen. Da hat sich schon Intel böse verhoben

[basix]

Diese Art von Software ist bestimmt nicht ganz ohne, mir geht es mehr um Erfahrungen wie buggy die Tools von Xilinx sind, wie ist der Support von Xilinx, etc.

Könnte also AMD im Software Bereich (insbesondere HPC) von möglichen Qualitäten bei Xilinx profitieren?

Xilinx ist Marktführer bei FPGAs. So schlecht kann es also nicht sein. Bruttomarge liegt schon seit 10 Jahren bei ~70%. Ich hatte schon lange nichts mehr direkt mit FPGAs am Hut, aber Xilinx galt eigentlich immer als qualitativ gut aber jedoch eher teuer. Also was ich so in Erinnerung habe: Gute Qualität. Wie das auf Software Seite aussieht, kann ich weniger beurteilen. Die paar Sachen, die wir im Studium gemacht haben, gingen aber gut von der Hand (Taschenrechner :freak:, Bildverarbeitung)

Soweit ich das beurteilen kann, hat Xilinx einiges an Know How bezüglich Interconnects und PHYs. Multichip-Packages, HBM, Interposer etc. haben sie auch. Bei HW-Design und IP wird es also definitiv Synergien geben. Und auch bezüglich ML/DL haben sie interessante Sachen im Petto (Sparsity Zeugs (https://www.xilinx.com/about/blogs/adaptable-advantage-blog/2022/Sparse-vs-Dense-TOPS.html), Network Pruning und so). Bezüglich ML/AI wird Xilinx definitiv ein Win für AMD sein, bei HW wie auch SW. "Programmable Network on Chip" haben sie auch, evtl. ähnlich zu Infinity Fabric.

Prinzipiell kann ich mir gut vorstellen, dass eines der nächsten Xilinx FPGAs ebenfalls mit Infinity Fabric daherkommt und direkt an EPYC und CDNA gekoppelt werden kann. Via CXL und Speicherkohärenz sollte das eine zusätzliche Accelerator Stufe geben. Den Software-Stack hat man ja schon kompatibel gemacht und vereinheitlicht (CPU, GPU, FPGA), siehe News einige Posts hier im Thread vorher. Der Link dort ist mittlerweile aber ein Dead-End, hier einer der passen sollte: https://www.hpcwire.com/off-the-wire/amd-and-xilinx-demonstrate-converged-rocm-runtime-technology-preview-at-sc20/

Also die größte Baustelle gerade im Vergleich zu nV sehe ich aktuell auch bei Software/Algorithmen. Ich vermute mal dass sie sich da ein zwei kleine Fische aus Bereich Computergrafik holen. Mit XeSS und DLSS schwimmt denen sonst der komplette Consumergrafikmarkt mittelfristig davon.
Jepp. Hier hat AMD Nachholbedarf. AMD hat verglichen mit Intel und Nvidia später angefangen und auch weniger Ressourcen. Da muss AMD also noch etwas Gas geben. Und allgemein bei Support / Guidance für Kunden. Da fehlt AMD etwas an Manpower.

XeSS und DLSS sind sicher gute Punkte. Aber AMD hat zwei Vorteile: Konsolen und das XeSS ist Open Source sowie auf AMD Karten lauffähig ist. Letzteres nimmt evtl. schon ein wenig Druck weg. Und wenn AMD mit FSR 2.0 eine Technik liefert, welche an DLSS 2.0 heranreicht und auf den Konsolen eingesetzt werden kann, werden sehr viele Spiele FSR einfach mitbringen. DLSS oder XeSS wären dann Zusatzaufwand für die Entwickler. Und andere Techniken wei Unreal Engines TSR gibt es auch noch.

Edit:
Wenn ich die Alveo U250 von Xilinx anschaue, wir das ein guter Match für AMD. Da kommt ziemlich was an Radeon Feeling auf. Man schaue sich doch mal diese PCIe Karte an, irgendwas zwischen X1950XTX bis und mit HD4870X2 :D
https://de.farnell.com/xilinx/a-u250-a64g-pq-g/data-center-accelerator-card-54mb/dp/2919992

Edit 2:
Interessant, dass es hier eine gemeinsame Präsentation von Xilinx und Numenta gibt. Numenta ist Spezialist, was Sparsity auf FPGAs angeht. Bin mir aber nicht sicher, ob das in irgendeiner Form produktiv eingesetzt wird oder darauf gehofft wird, dass einer der Grossen die Firma aufkauft.
https://www.slideshare.net/numenta/fpga-conference-2021-breaking-the-tops-ceiling-with-sparse-neural-networks-xilinx-numenta

[Zossel]

Prinzipiell kann ich mir gut vorstellen, dass eines der nächsten Xilinx FPGAs ebenfalls mit Infinity Fabric daherkommt und direkt an EPYC und CDNA gekoppelt werden kann.

Sowas gab es schon mal früher für Opteron-Sockel.

[Skysnake]

Für Intel gab es das von Altera auch mal als es noch den FSB gab. Danach hat Intel wohl so viel umgestellt und rumgekackt das keiner mehr was machen konnte. Am Ende hat Intel Altera dann ja gekauft.

[Zossel]

Für Intel gab es das von Altera auch mal als es noch den FSB gab. Danach hat Intel wohl so viel umgestellt und rumgekackt das keiner mehr was machen konnte. Am Ende hat Intel Altera dann ja gekauft.

Die Schnittstellen aus der CPU raus waren/sind bei Intel mit Patenten zugenagelt um in den 90'ern alternative Chipsatzherstellern (X, Y, Z) und CPU-Herstellern (Cyrix, AMD, etc.) loszuwerden.

IMHO war Hypertransport seinerzeit offen, wie ist der aktuelle Stand bzgl. IF?

BTW: Tut sich Intel eigentlich immer noch einen Gefallen weil Intel was eigenes Richtung IO benutzt?

[Skysnake]

Keine Ahnung wie es um IF aussieht. Mit CXL hat man aber sicherlich eine brauchbare Alternative, die am Ende sehr viel interessanter ist für HWHersteller, da eben auch von Intel supported.

[=Floi=]

Ich könnte mir auch den zukauf von automotive chiphersteller vorstellen. Auch sparten, welche andere loswerden wollen.
Der OEM markt für kleine chips wie bei broadcom würde ebenfalls passen.

[amdfanuwe]

Ich könnte mir auch den zukauf von automotive chiphersteller vorstellen. Auch sparten, welche andere loswerden wollen.
Der OEM markt für kleine chips wie bei broadcom würde ebenfalls passen.
Seh ich nicht so.

Ich denke, AMD strebt eher die Richtung Hgh-End Chipdesign an.
Wenn ich ein Produkt entwickel, hab ich die Möglichkeit
- alles selbst machen (Apple)
- etwas von der Stange zu nehmen (Intel, AMD, Broadcom, Atmel, TI,....)
- mich an ein Designhaus für ein Semicustom Design zu wenden.

Für einen Chip mit leistungsfähiger CPU, GPU und künftig FPGA gibt es aktuell nur AMD. Damit deckt AMD High End digital Logik komplett ab. ML, Tensor Cores stehen sicherlich schon am Start.
Intel will mit IDM 2.0 ab 2024 ähnliches anbieten und bieten dann, bisher undenkbar, Intel Cores für Custom Designs an.
Nvidia ist aus dem Rennen da es mit ARM nicht geklappt hat.

[basix]

Bei Nvidia frage ich mich, ob man nun bei der ARM Strategie bleibt oder in Richtung RISC-V gehen will. Für Grace und dessen Nachfolger ist ARM sicher noch gesetzt. Wie es dann danach aussieht? Schwer zu sagen.

Ganz aus dem Rennen sind sie mMn aber nicht. Grace wird genauso Speicherkohärenz zu Nvidia-GPUs bieten. AMD und Intel werden aber sicher deutlich skalierbarere CPU-Lösungen haben. Und bei FPGAs ist immer die Frage, wie gross der Markt effektiv ist. Verglichen mit CPUs und GPUs deutlich kleiner. Man müsste mit FPGAs schon sehr grosse Vorteile gegenüber GPUs haben, damit man hier relevante Marktanteile abgraben kann.

Wenn man natürlich ein System haben will, wo alles aus einer Hand kommt (inkl. SW-Stack): Ja, da ist Intel und AMD im Vorteil. Xilinx ist als strategische Akquisition for AMD sicher sehr wertvoll. Und für Xilinx ist die Datacenter-Synergie mit AMD wertvoll. Deswegen wird das für beide ein Win-Win.

[amdfanuwe]

Bei Intel und AMD sieht man an den einzelnen Chips (CPU, GPU, FPGA) welche Leistung für ein Semicustom Design abrufbar ist.
Nvidia muß da erst was aufbauen, bisher sieht man nur GPU Leistung.
Zudem denke ich nicht, dass Nvidia mehr in Richtung Open Source geht, da bleibt immer das Geschmäckle des proprietären.
Nvidia kämpft darum weiterhin mitspielen zu können.
Nachdem ihnen damals die Chipsätze mit IGP wegfielen, ihnen klar ist, dass kleine GPUs in Notebooks bald überflüssig sind, bei Gaming GPU zunehmend Konkurrenz durch AMD und Intel aufkommt, muss Nvidia seine Nische finden. Mit KI und Cuda sind sie momentan noch sehr Gut aufgestellt. Will Nvidia zukünftig nicht nur einen Nischenmarkt bedienen, müssen sie wachsen.

GPU und FPGA haben unterschiedliche Konzepte und Anwendungsbereiche. Bei ML überschneidet sich das etwas. Liegt aber auch daran, dass sich für ML noch keine eigene spezielle Hardware durchgesetzt hat.

Bleibt noch eine Weile spannend, wer der Technologietreiber der Zukunft wird.
Wenn sie nicht aufpassen, beliefert China in ein paar Jahren die Welt mit Spitzentechnologie.

[basix]

RISC-V bedeutet nicht, dass Nvidia in Richtung Open Source geht. Das würde eher bedeuten, dass sie wieder anfangen, eigene CPU-Cores zu designen (oder zusammen mit einem Technologiepartner).

[amdfanuwe]

RISC-V bedeutet nicht, dass Nvidia in Richtung Open Source geht.
Hab ich auch nicht geschrieben.
ARM hat jedoch schon ein ordentliches Software Ökosystem.
Das müßte für Risc-V erstmal aufgebaut werden. Eignet sich von daher nur für proprietäre Systeme.
Als Softwareentwickler ist mir die Hardware ziemlich egal, solange die entsprechenden Bibliotheken und OS Unterstützung vorhanden ist.
Das ist ja der Vorteil bei X86, dass es da alles gibt.
Bei Linux gibt es dann schon Probleme zwischen den Distributionen zu portieren, dann nochmal auf eine andere Architektur...

[Brillus]

Wenn man natürlich ein System haben will, wo alles aus einer Hand kommt (inkl. SW-Stack): Ja, da ist Intel und AMD im Vorteil. Xilinx ist als strategische Akquisition for AMD sicher sehr wertvoll. Und für Xilinx ist die Datacenter-Synergie mit AMD wertvoll. Deswegen wird das für beide ein Win-Win.

Ich frag mich auch inwieweit evtl Zyqn mässige Dinger da interesant werden können wo dann garnicht Konkurrenz zu CPU/GPU Bereich sondern für eigenes IO sozusagen den IO die als FPGA machen.

[amdfanuwe]

Wie kommst du auf Zyqn? Das ist ein SOC mit ARM Cores, einem FPGA Block und ein paar weiteren fixed Function Einheiten.
Nettes Teil für Echtzeit Signalverabeitung. Haben wir für einen Sensor-Prüfplatz verwendet.
Für die Entwicklung ganz nett. Hätten wir das in Masse gebraucht, wäre anschließemd ein ASIC aus der Lösung gemacht worden.

Also einen FPGA statt des I/O Dies zu verwenden macht keinen Sinn, nicht so schnell, nicht so effizient.
Im I/O Die einen FPGA Block vorzusehen für Encoding/Decoding von Datenströmen könnte ich mir aber schon vorstellen.
Kommt halt auf den Anwendungsfall an, ob sowas Sinn macht.
Mal sehen, mit was uns AMD überrascht.

[Zossel]

Wenn man natürlich ein System haben will, wo alles aus einer Hand kommt (inkl. SW-Stack): Ja, da ist Intel und AMD im Vorteil. Xilinx ist als strategische Akquisition for AMD sicher sehr wertvoll. Und für Xilinx ist die Datacenter-Synergie mit AMD wertvoll. Deswegen wird das für beide ein Win-Win.

AMD könnte "relativ einfach" ein Produkt anbieten wo statt einen CPU-Die ein FPGA-Die am IO-Chip hängt, welche Die-Fläche haben den typische FPGAs die auch was wegschaffen? Die Entwicklungskosten und damit auch die Risiken wären wohl überschaubar und man hätte ein Produkt am Markt wo sich dann auch ein Ökosystem drumherum bilden könnte.

Aber sicherlich wird man erste Synergien in den nächsten Produkten sehen, mein Favorit wäre ja schlaues und schnelles Ethernet auf dem IO-Die was NVMe-oF mit kurzen Latenzen kann und auch dieses Protokoll aus den Atombomben-Simulatoren.

[Tobalt]

FPGA erreichen nichtmal im Ansatz die Taktraten und Effizienz von ASICs...

Bei den Stückzahlen macht es einfach keinen Sinn. Sinn macht es in neuen Feldern wie KI wo es noch keine Konsens für fixed function units gibt.

[basix]

Klar, die Effizienz von ASICs werden FPGAs nie erreichen. Eine GPU oder eine CPU sind in dem Sinne allerdings nicht zwingend ASICs, sondern fast schon General Purpose. FPGAs können deutlich besser auf einen Spezialfall getrimmt werden, wo man dann den Effizienznachteil wieder ausgleichen kann. Und man ist flexibel, kann also mit einem FPGA mehrere Spezialfälle abdecken, was mit einem ASIC nicht geht. Mit einem FPGA sind einfach deutlich mehr Spezialfälle zu geringeren Kosten abdeckbar (siehe Grafik im Anhang). Und ob das nun Stückkosten, Man-Hours oder Berechnungzeiten sind, spielt in der Betrachtung keine Rolle. Gerade für ML/AI sind FPGAs eigentlich sehr interessant, da sich dieses Technologiefeld sehr schnell entwickelt.

Die Idee von Zossel finde ich deswegen schon sehr attraktiv. Stell dir mal ein EPYC Package vor, wo man bis zu 12 Zen 4 Chiplets unterbringen kann. Jetzt kann man im selben Formfaktor ein Mega-FPGA liefern, welches 12 FPGA Chiplets unterbringt. Oder je nach Applikation sogar gemischt, z.B. 8x CPU und 4x FPGA.

Der riesige Vorteil wäre hier, dass man die Infrastruktur rund um EPYC mitnutzen kann. SP5-Sockel, 128x PCIe Lanes, 12-Channel DDR5 und Networking-Interfaces. Und da AMD und Xilinx eh ihre SW-Library rund um HIP vereinheitlichen, würde das dann mehr oder minder out-of-the-box laufen.

Und wie Zossel angedeutet hat, mit relativ wenig Zusatzaufwand: Man muss das FPGA-Chiplet und das Package designen. Im besten Fall wären das CPU CCD sowie das FPGA CCD sogar pinkompatibel. Dann kann man das selbe Package verwenden und beliebige Mischverhältnisse zwischen CPU/FPGA bereitstellen. Im Falle von FPGAs könnte ich mir eine solche Pinkompatibilität eigentlich gut vorstellen, das als "SRAM-Array" und dessen LUTs relativ einfach auf bestimmte grössen anpassbar. Oder wie Zossel sagt, wären das Beschleuniger-Funktionen für gewisse Tasks. Ob nun Networking-Acceleration oder was auch immer.

Gerade für Supercomputer und HPC konnte so eine gemischte CPU einigen Sinn machen, wenn man auf einige Spezialanwendungen spezifisch die Algorithmen optimieren kann.

Lisa Su hat ja getwittert: Das beste kommt erst noch. Evtl. genau sowas? :)

Edit:
Beim Gedanken zu FPGAs und SRAM kam mir noch ein Zusatzgedanke. FPGA 3D-Stacked auf dem CCD? Quasi änlich wie dem 3DV-Cache? Holy cow :D
Dadurch würde man automatisch potente Vektor- und Matrizenrechner auf den EPYC-Sockel bekommen. Bei gleichzeitiger Verfügbarkeit einer x86 CPU mit 96-128 Cores. Cache-Anbindung an den L3$ des CCDs wäre direkt gegeben. Dazu noch die Möglichkeit, spezielle Algorithmen und Accelerators direkt ins FPGA zu laden, anstatt es in den CPU-Core zu designen (was man bei späteren CPU-Generationen dann allenfalls kann, wenn sinnvoll und verbreitete Nutzung).

Edit 2:
Und FGPAs sind ja hauptsächlich SRAM mit extremer Bandbreite. Die Density ist verglichen mit 3DV-Cache deutlich kleiner, aber evtl. kann AMD & Xilinx das irgendwie kombinieren? 3DV-Cache & FPGA merged on-a-chip?

[Nakai]

FPGA != FPGA.

Immer diese Rechnungen, dass ASICs besser sind. FPGAs gehen bereits eher in Richtung ASIC/SOCs mit soviel dedizierter Logik wo da drin ist. DSPs, CPU-Kerne, extra RAM, die ganze Peripherie. Da ist der FPGA-Teil mittlerweile eher nur noch um das alles konkret zu verdrahten bzw. hierarchischen Speicher hinzuzufügen.

[Tobalt]

Ich schrub ja oben, dass FPGA super sind für Felder wo es noch keinen Konsens über "ideale" fixed function units gibt.

Paradebeispiel ist natürlich KI, wo FPGA aktuell richtig Sinn machen. Aber die Tensor Cores von nV bspw. können ja auch schon mit diversen Formaten umgehen oder nicht ? Dass es bei Inference grundlegend auf Dot Products bzw. Matrix Products hinausläuft ist quasi Konsens. Das Zahlenformat ist es noch nicht. Das jetzt alles bis ins letzte Bit als frei verdrahtbare LUTs und Flipflops anzubieten, ist für den Endkundeprodukt nicht zweckmäßig IMO. So eine Gewisse Konfigurierbarkeit gibt es ja aktuell auch schon.

Ich finde es prinzipiell interessant was konfigurierbares mit einzubauen, aber ich glaube nicht dass es zweckmäßig ist, es bis auf so eine Ebene konfigurierbar zu lassen wie es in FPGAs typischerweise ist. Also die Granularität der Blöcke wird wohl nicht so fein.

Ein Bsp sind ja die schon angesprochenen DSP Blöcke. Im Prinzip fixed function, aber können ja auch noch miteinander verbunden werden falls andere Formate gewünscht sind. Dabei werden sie aber wiederum ziemlich langsam! Also die Konfigurierbarkeit hat einen beträchtlichen Preis im Hinblick auf Taktbarkeit (möglicherweise nicht fundamental, aber eben in aktuellen FPGA). Das heißt fast zwangsläufig, dass man in ein End User Produkt nur eben soviel Konfigurierbarkeit packen wird, wie sich sehr gut begründen lässt durch konkrete Anwendungsfälle.

[Orko]

Ich könnte mir kleine in CPU / GPU integrierten FPGA Blöcke als Art Wild-Card vorstellen:

1) Etabliert sich ein neuer Video Codec, gibt es eine neue DirectX / OpenXX / Vulkan Version, kommt HDMI oder Displayport mit neuen Features, gibt es ISA Erweiterungen, usw dann kann Support für bereits im Markt / im Einsatz befindliche Produkte nachgereicht werden. Vielleicht nicht top-perfomant, aber besser als gar nicht.

2) Ergeben sich im Betrieb Bugs, Sicherheitslücken, Instabilitäten, Inkompatibilitäten (z.B. bei Integration vieler Komponenten in Supercomputer), sollen bestehende Installationen mit neuen Komponenten erweitert werden, usw dann kann dies ggf mithilfe der FPGAs gefixt werden.

3) Vielleicht kann auch der RAM Support verbessert werden: bessere Kompatibilität zu den unterschiedlichsten sich im Markt befindlichen und neu dazukommenden RAM-Modulen, höhere Taktraten.

4) Ergeben sich im Entwicklungsprozess Probleme, kann ggf time-to-market verbessert werden. So nach dem Motto: Hauen wir das Produkt erstmal mit Fix-per-FPGA raus, während wir parallel den nötigen Metal-Respin angehen.

5) Kommt ein Semicustom Kunde (z.B. Konsolen Hersteller) mit speziellen Anforderungen: Kann ein bereits verifiziertes Standard-Design aus dem Design-Werkzeug-Kasten genommen und die gewünschten Funktionen / Features per FPGA realisiert werden, oder muss auf Architekturebene eingegriffen werden?

Sachen halt die bisher über Microcode-Updates oder BIOS-Updates nicht / schlecht lösbar sind.

Ganz flexibel geht das sicherlich nicht, da ein solcher FPGA Block mit entsprechender Bandbreitenanbindung wohl entsprechend im Chipdesign plaziert werden muss: z.B. einer am GPU Display Ausgang, einer am CPU Decoder, einer beim chipinternen Interconnect mit Cache Anbindung, einer bei den chipexternen Schnittstellen (Arbeitsspeicher, Chipsatzanbindung).

Wäre auch noch die Frage inwieweit sich das finanziell lohnt. Bei Server oder HPC Anwendungen könnte ich mir vorstellen, dass sich Kunden für solche Features interessieren. Bei Consumer ist das wohl schwieriger, dass Kunden die zusätzliche Chipfläche bezahlen in der Hoffnung dass sich dass vielleicht irgendwann in der Zukunft positiv auszahlt.

Auch gehen mit solchen Wild-Card FPGA Blöcken wohl gravierende Sicherheitsrisiken einher. Jeder der es schafft auf einen solchen Block zuzugreifen, kann damit beliebigen Unfug anstellen. Etwa analog dazu wer es aktuell schafft sich in die Secure-Enklaven einzuhaken oder schadcodebehaftete Microcodes / BIOS Updates zu verteilen.

Allerdings habe ich von dem Thema kein tieferes Fachwissen. Kann also gut sein, dass meine Vorstellung hier spekulativer Blödsinn ist.

[Skysnake]

Also...

1. Nein, das ist nicht sinnvoll. Du willst ja eigentlich neue Produkte verkaufen. Zudem brauchst du schon einiges an Platz, damit es schneller als auf der CPU/GPU ist. FPGAs bringen ja vor alle. Erst mal nen Perf/Watt Vorteil gegenüber CPU/GPU Lösungen. Das ist Privaten aber ziemlich egal und für Firmen rechnet es sich neue Produkte zu kaufen.

2. Vergiss das mal ganz schnell. Bugs sind im Allgemeinen glitsches bei der Ausführung oder harte Logikfehler an bestimmten Stellen. Die können aber überall passieren. Da hilft nur ausschalten der Funktion oder Metalspin um die Verdrahtung zu ändern. Und selbst WENN es gehen würde wäre der Performance Hit viel zu groß. CPU und auch GPUs sind GHz. FPGAs noch immer <200MHz

3. Das hat was mit dem Signalweg zu tun. Da hilft dir kein FPGA

4. Auch das ist eher nicht realistisch.


Und weil auch schon vorher HPC angeschleppt wurde... nein FPGAs sind nicht super nützlich für HPC. Also ja an sich theoretisch schon, weil es schon Probleme gibt die sich einfach dafür eignen würden. Jetzt kommt aber das große ABER. Die meisten sites führen Unmengen an verschiedenen Codes aus. Daher sind noch immer so viele reine CPU Systeme vorhanden. Und NEIN wenn in nem 1k Knoten Cluster 64 GPUs stecken, dann sehe ich das nicht als hybrides System an. Das ist dann einfach ne GPU Partition für hauptsächlich Visualisierung der Daten und vielleicht noch ne Hand voll von Leuten um Codes zu portieren und eventuell rechnet auch wirklich einer drauf. Das war es dann aber auch.

Ihr müsst euch einfach klar machen, das CPU Programmierung != GPU Programmierung ist. Am Ende vom Tag werden die Codes von Wissenschaftlern geschrieben. Da ist man an sich schon froh wenn die guten oder gar sehr guten CPU Code schreiben können. Dann kommt noch hinzu , das selbst WENN sie sehr guten Code schreiben können dafür auch die Zeit/das Geld brauchen.

So und guten GPU Code schreiben ist jetzt schwerer, weil man paralleler denken muss. Quasi Datenflow mäßig. Man muss die Parallelität in seinem Code sehen/fühlen. Von 100 bleiben dir vielleicht 10 übrig, die das schaffen/wollen. So und die brauchen jetzt die Zeit/das Geld das auch zu realisieren. Das scheitert schon öfters daran, das es nicht genug davon gibt, oder eben zu Aufwändig wird und große Codes das nicht aufnehmen weil es nicht wartbar für die ist.

So und jetzt kommen die FPGAs, die von CPU noch viel viel weiter weg sind als GPUs von CPUs...


Sorry,aber die Anzahl an Leuten die das können ist verschwindend gering und selbst wenn du 5 solcher Leute hast, dann ist der Aufwand immens! Das lohnt einfach nicht. Selbst Firmen die quasi nur genau ein Problem auf ihren 30Mio Rechner rechnen tun sich mit GPUs schwer. Wenn musst du zu solchen Schwergewichten wie AWS, Microsoft und Google schauen. Die gehen dann aber auch schnell in die vollen und bauen ASICs. Der FPGA ist also nur nen Zwischenschritt.

Im HPC seje ich das aber eher nicht, denn die Ressourcen sind zu groß die man dafür braucht. Das steckt man keiner einzelnen Gruppe in den Hals. Das passiert quasi nie. Warum quasi nie? Na ganz einfach. Beim BlueBrain Project ist das eigentlich passiert und den Aufschrei hat selbst die 0815 Presse mitbekommen den es dadurch gab weil so viele Ressourcen gebündelt wurden. Und hier war es ja sogar wirklich etwas wo man ein Ziel sehen konnte für das es sich wirklich lohnen würde.....


So lange FPGAs also nicht in Massen vor free rein geklatscht werden in die Chips und es wie bei nVidia und ihren Tensorcores etc einfach keinen Weg dran vorbei gibt, wird es nicht genutzt. Oder was glaubt ihr warum im HPC Bereich so viele von denen die GPUs nutzen jetzt so low precision Kram machen? Richtig, weil du mit low precision Leistung zugeschissen wirst sich bei FP64 aber quasi nichts tut seit Jahren... da wird der Leidensdruck dann halt groß es zu nutzen und die Zeit hat man auch eher, weil mit FP64 kommt man ja nicht wirklich weiter.

Ach so und bevor ich es vergesse. Vor der Übernahme von Altera durch Intel hatte ich die Hoffnungen auch noch. Intel hat das aber voll in den Sand gesetzt. ALLE die ich kenne und FPGAs versucht haben zu nutzen sind grandios gescheitert. Die high level Tools sind zwar fähig ein hallo worden zu realisieren, sobald es aber komplexer wird kannst du die Vorteile des FPGAs nicht mehr nutzen, weil du es nicht formuliert bekommst. Sprich das Ergebnis ist halt immer langsam, selbst wenn es als Problem passen würde. Und da hast du schon wieder das Problem, dass die Leute nicht verstehen wie FPGAs ticken im Vergleich zu CPUs und GPUs. Es wird also auch noch oft falsch gearbeitet.

Und wenn die Leute es können und sehen, dass die high level Sprachen es einfach nicht können, streichen Sie die Segel wenn du mit Verilog/VHDL ankommst. Das ist einfach totaler Overkill...

[Orko]

Weitere gemischte Gedanken:

Vielleicht könnte ein FPGA in GPUs integriert werden, welches einige Teile der Arbeit übernimmt welche bisher per Graphikkarten-Treiber auf der CPU laufen. Insbesondere solche Teile die von hohen Bandbreiten und/oder niedrigen Latenzen zur GPU profitieren. Oder solche Teile bei denen eine deutliche Entlastung der CPU erreicht werden kann. Mit jedem Treiberupdate gibt es dann halt, soweit nötig, ein entsprechendes Update für den FPGA.

Üblicherweise enthalten die Graphikkarten-Treiber spezifische Optimierungen für verbreitete Spiele. Vielleicht kann hier ein GPU seitiger FPGA neue Möglichkeiten eröffnen. Bei jeden Spielstart würde der Treiber dann den FPGA mit spielespezifisch-optimierten Code beladen. Voraussetzung wäre ein FPGA der eine entsprechend hohe Anzahl an Reprogrammierungen unterstützt.

Ich sehe grad, basix hat das schon im Post #104 geschrieben:
"Bei Gaming GPUs könnte AMD pro Spiel "Befehlssatzprofile" im Treiber anlegen um Spiele zu beschleunigen..."

Und: von dem was ein GPU Treiber so im Detail macht habe ich noch viel weniger Ahnung als davon wo / wie FPGAs vorteilhaft integriert werden könnten.


basix in Post #133:

"Im Falle von FPGAs könnte ich mir eine solche Pinkompatibilität eigentlich gut vorstellen, das als "SRAM-Array" und dessen LUTs relativ einfach auf bestimmte grössen anpassbar."

Ich hätte gedanklich FPGAs eher als Array von Transistoren verknüpft, deren Gates von programmierbaren Flash Zellen gesteuert werden, und weniger in Verbindung mit SRAM gebracht. Die Programmierung von gängigen FPGAs bleibt meines Wissens üblicherweise erhalten wenn die Versorgungsspannung weggenommen wird.

Aber warum nicht ein FPGA des per SRAM programmiert wird (wobei das Programm dann nicht von ROM kommt sondern aus einer Datei oder gar vom Arbeitsspeicher gezogen wird)? Vorteil: Beliebig oft und schnell reprogrammierbar. Interessanter Gedanke.

Der Aussage tut dies natürlich keinen Abbruch. Als Array-Anordnung so oder so gut flächig skalierbar.

[Orko]

Also...


Ihr müsst euch einfach klar machen, das CPU Programmierung != GPU Programmierung ist. Am Ende vom Tag werden die Codes von Wissenschaftlern geschrieben. Da ist man an sich schon froh wenn die guten oder gar sehr guten CPU Code schreiben können. Dann kommt noch hinzu , das selbst WENN sie sehr guten Code schreiben können dafür auch die Zeit/das Geld brauchen.

So und guten GPU Code schreiben ist jetzt schwerer, weil man paralleler denken muss. Quasi Datenflow mäßig. Man muss die Parallelität in seinem Code sehen/fühlen. Von 100 bleiben dir vielleicht 10 übrig, die das schaffen/wollen. So und die brauchen jetzt die Zeit/das Geld das auch zu realisieren. Das scheitert schon öfters daran, das es nicht genug davon gibt, oder eben zu Aufwändig wird und große Codes das nicht aufnehmen weil es nicht wartbar für die ist.

So und jetzt kommen die FPGAs, die von CPU noch viel viel weiter weg sind als GPUs von CPUs...


Sorry,aber die Anzahl an Leuten die das können ist verschwindend gering und selbst wenn du 5 solcher Leute hast, dann ist der Aufwand immens!


Ich habe im Studium FPGAs per VHDL programmiert, und das war nicht allzuschwer zu lernen. Hat 2 Tage à 10 Stunden gedauert und schon war der Code für einen Fahrradcomputer funktional und fertig (bei vorhandener Test-Bench und vorab ausgearbeitetem Algorithmus und vorab null Berührung mit irgend einer parallelen Programmiersprache).

Für jemanden der allgemein sequenziell programmieren kann und die generelle Syntax von Programmiersprachen kennt, für den ist der Umstieg auf paralleles Programmieren meiner persönlichen Erfahrung nach relativ einfach. Die Güte von Code ist in beiden Fällen immer sehr von der Erfahrung und der Intuition des jeweiligen Programmierers abhängig.

Und nein, üblicherweise werden Codes nicht von Wissenschaftlern geschrieben. Wissenschaftler (z.B. Geologen, Physiker, Informationtheoretiker, Mathematiker, Chemiker, Meteorolgen) erstellen Algorithmen ohne Ahnung vom Programmieren / Programmiersprachen zu haben. Programmierer setzen diesen dann in funktionalen und perfomanten Code um. In schwierigen Fällen helfen ausgebildete Algorithmiker als Bindeglied. Gute Programmierer für gängige Programmiersprachen sind relativ einfach zu bekommen, gute Wissenschaftler im jeweiligen Fachgebiet schon schwerer, und in diesem Punkt stimme ich dir zu: gute Algorithmiker sind rar. Algorithmik war mal Teil eines meiner früheren Berufe. Habe dann auch gleich das Programmieren mit übernommen. Meine Erfahrung ist: Wenn sich ein Wissenschaftler der weiss was berechnet werden soll (die Formeln) und ein Coder der seine Programmiersprache kennt zusammensetzen, dann dauert das meist zwar etwas bis diese verstehen was der jeweils andere in seiner Fachsprache eigentlich genau meint, aber dann kommt meist ein zumindest 3/4 perfomanter Code bei rum.

Spezialfälle wie Monte-Carlo-Algorithmen, Algorithmen für Qantencomputer, Chaostheorie, nondeterministische Algorithmen, und Ähnliches mal ausgenommen.

Problematisch wird es wenn weder Coder noch Aufgabensteller Ahnung von Algorithmik haben und dies nicht berücksichtigt wird (bedingt z.B. allgemein fehlendes Fachwissen, Projektleiter, Chef, Firmenphilisophie, Zeitdruck, Spardruck, persönlicher, Ehrgeiz, Selbstdarstellung, Carrierechancen). Dann kommt gerne Müll-Code bei rum. Typischies Beispiel ist wenn eine fachfremde Firma einen Programmierjob extern vergibt, aber nicht mal das Problem / die Aufgabenstellung definieren kann. Programmierer, Informatiker und Algorithmiker werden halt gerne zusammen in einen Topf geschmissen. "Hat doch alles was mit Computern zu tun, muss doch irgendwie gehen."

Im wissenschaftlichen Bereich kommt dies eher selten vor. Die meisten Firmen lernen nachdem sie ein / zweimal finanziell (oder zeittechnisch oder qualitativ) gegen die Wand gefahren sind. Am "schlimmsten" sind Behörden (meine Erfahrung erstreckt sich dabei ausschleißlich auf deutsche Behörden). Die kaufem immer und immer wieder Müll-Software ein, und lernen rein gar nichts daraus.

</OT>

[Tobalt]

Ne FPGA geht flöten bei Power cycle..Das wird jedesmal durch einen zusätzlichen Controller neu beschrieben.

Und wie Skysnake schon andeuten: Ein softwareseitiges konfigurierbarkeitsproblem wird eher schlecht mit FPGA gelöst werden.

Ein Punkt der mir noch einfällt und der evtl gut mit sehr kleinen nodes harmoniert: Man kann kleinere Packages realisieren. Dies werden eh immer kleiner und man braucht nicht so viele Pins wenn man die vorhandenen konfigurierbar macht.. Die CPU kann dann zwar nicht alles gleichzeitig, aber kann dann zB auf dem einen Board Dual Channel RAM und auf dem anderen nur Single Channel, dafür dann mehr Peripherie..Das wäre evtl. für mobile Interessant

[Orko]

Ne FPGA geht flöten bei Power cycle..Das wird jedesmal durch einen zusätzlichen Controller neu beschrieben.



OK, I stand corrected, und adaptiere mein FPGA Weltbild entsprechend.
Edit: Und vielen Dank für die Richtigstellung

[amdfanuwe]

Die Programmierung von gängigen FPGAs bleibt meines Wissens üblicherweise erhalten wenn die Versorgungsspannung weggenommen wird.
Das waren nur die ersten.
Mittlerweile wird von einem externen seriellem EEPROM bei Power-On geladen bzw. vom Host PC programmiert.

---

Ich seh das eher so: Software besteht aus Funktionen. Diese werden mit den CPU Befehlen sequentiell ausgeführt. Bestimmte Funktionen haben sich als nützlich erwiesen weshalb sie in folgenden CPUs als Fixed Function ausgeführt werden. Mit SSE/AVX , Multicore kam die parallelisierung hinzu, wodurch einiges beschleunigt werden kann.
Gaming GPUs mit ihren massiv parallelen Einheiten stellten sich für einige Anwendungen auch als gute Beschleuniger dar.

Letztendlich geht es darum Funktionen schneller und effizienter auszuführen.

Da kann eine FPGA Einheit in der CPU, als AIB etc. durchaus nützlich sein.
Flexibler als Fixed Funktion und schneller als CPU Code.
Etablieren sich in den Bibliotheken, die ich als Programmierer verwende, bestimmte FPGA Algorithmen, wird man sich sicherlich überlegen diese zukünftig als Fixed Function zu implementieren.

So kann ein FPGA-Block zusätzliche Beschleunigung und Effizienz erzielen, ohne das ich mich als Programmierer damit rumschlagen muß.

-------

Ich fand folgende Beiträge zu Xilinx FPGAs ganz interessant:

https://www.hpcwire.com/2021/06/10/xilinx-expands-versal-chip-family-with-7-new-versal-ai-edge-chips/
https://www.hpcwire.com/2021/11/15/xilinx-targets-hpc-and-datacenter-with-new-alveo-u55c-fpga-card/

[Brillus]

Ich könnte mir kleine in CPU / GPU integrierten FPGA Blöcke als Art Wild-Card vorstellen:

1) Etabliert sich ein neuer Video Codec, gibt es eine neue DirectX / OpenXX / Vulkan Version, kommt HDMI oder Displayport mit neuen Features, gibt es ISA Erweiterungen, usw dann kann Support für bereits im Markt / im Einsatz befindliche Produkte nachgereicht werden. Vielleicht nicht top-perfomant, aber besser als gar nicht.

2) Ergeben sich im Betrieb Bugs, Sicherheitslücken, Instabilitäten, Inkompatibilitäten (z.B. bei Integration vieler Komponenten in Supercomputer), sollen bestehende Installationen mit neuen Komponenten erweitert werden, usw dann kann dies ggf mithilfe der FPGAs gefixt werden.

3) Vielleicht kann auch der RAM Support verbessert werden: bessere Kompatibilität zu den unterschiedlichsten sich im Markt befindlichen und neu dazukommenden RAM-Modulen, höhere Taktraten.

4) Ergeben sich im Entwicklungsprozess Probleme, kann ggf time-to-market verbessert werden. So nach dem Motto: Hauen wir das Produkt erstmal mit Fix-per-FPGA raus, während wir parallel den nötigen Metal-Respin angehen.

5) Kommt ein Semicustom Kunde (z.B. Konsolen Hersteller) mit speziellen Anforderungen: Kann ein bereits verifiziertes Standard-Design aus dem Design-Werkzeug-Kasten genommen und die gewünschten Funktionen / Features per FPGA realisiert werden, oder muss auf Architekturebene eingegriffen werden?

Sachen halt die bisher über Microcode-Updates oder BIOS-Updates nicht / schlecht lösbar sind.

Ganz flexibel geht das sicherlich nicht, da ein solcher FPGA Block mit entsprechender Bandbreitenanbindung wohl entsprechend im Chipdesign plaziert werden muss: z.B. einer am GPU Display Ausgang, einer am CPU Decoder, einer beim chipinternen Interconnect mit Cache Anbindung, einer bei den chipexternen Schnittstellen (Arbeitsspeicher, Chipsatzanbindung).

Wäre auch noch die Frage inwieweit sich das finanziell lohnt. Bei Server oder HPC Anwendungen könnte ich mir vorstellen, dass sich Kunden für solche Features interessieren. Bei Consumer ist das wohl schwieriger, dass Kunden die zusätzliche Chipfläche bezahlen in der Hoffnung dass sich dass vielleicht irgendwann in der Zukunft positiv auszahlt.

Auch gehen mit solchen Wild-Card FPGA Blöcken wohl gravierende Sicherheitsrisiken einher. Jeder der es schafft auf einen solchen Block zuzugreifen, kann damit beliebigen Unfug anstellen. Etwa analog dazu wer es aktuell schafft sich in die Secure-Enklaven einzuhaken oder schadcodebehaftete Microcodes / BIOS Updates zu verteilen.

Allerdings habe ich von dem Thema kein tieferes Fachwissen. Kann also gut sein, dass meine Vorstellung hier spekulativer Blödsinn ist.

Ich sehe vorallem deinen Punkt 5) als interesantesten. Insbesondere in hinsicht auf Chiplet. Kunde kommt ich will 10k Stück eines Chips mit n Big-CPU chiplets mit m little-CPU chiplets und k GPU Chiplets und auserdem soll Anschlüsse X und spezial DSP Y unterstützt werden. Mit einem IO-Die mit integrierten FPGA könnte man das hinbekommen als Semi-Custom aber sicher bei der Stückzahl zu teuer.

[Brillus]

Ne FPGA geht flöten bei Power cycle..Das wird jedesmal durch einen zusätzlichen Controller neu beschrieben.


Stimmt so im allgemeinen auch nicht kommt auf die Art des FPGAs an. Das geht von SRam der neu beschrieben werden muss nach reboot über NAND der es behält bis hin zu Antifuse FPGAs die nur einmal beschrieben werden können.

[Skysnake]

Ich habe im Studium FPGAs per VHDL programmiert, und das war nicht allzuschwer zu lernen. Hat 2 Tage à 10 Stunden gedauert und schon war der Code für einen Fahrradcomputer funktional und fertig (bei vorhandener Test-Bench und vorab ausgearbeitetem Algorithmus und vorab null Berührung mit irgend einer parallelen Programmiersprache).

Also ein erweitertes hallo world würde ich sagen. Wahrscheinlich auch ohne Synthese oder wenn dann ohne Anforderungen daran. Also weder bezüglich Ressourcenverbrauch noch an erreichte Taktrate.

Wir haben in net Vorlesung mal den sweet16 Prozessor implementiert in Verilog, da hat sogar einer eine Pipeline gebaut. Das zu synthetisieren war aber auch nicht mal eben gemacht und hatte der Tutor vom Prof übernommen.

Das ist halt einer der Punkte die man gerne unterschätzt, wenn man einfache Sachen macht.

Aber selbst ohne das. Die Algorithmen waren vorgegeben, also wie das zu implementieren ist. Genau das steht ja aber meist aus. Welche Sachen lohnen sich überhaupt von der CPU auf den FPGA zu schieben und wenn, wie Teile ich den Algorithmus auf usw. Da braucht man viel Erfahrung und ein Gespür für um zu riechen was sich überhaupt lohnen könnte geprüft zu werden.



Für jemanden der allgemein sequenziell programmieren kann und die generelle Syntax von Programmiersprachen kennt, für den ist der Umstieg auf paralleles Programmieren meiner persönlichen Erfahrung nach relativ einfach.
Also das deckt sich weder mit meiner Erfahrung aus der Uni, wo 50-70% Ärger Probleme mit dem Umstieg auf paralleles Programmieren hatten und dann von den 50-30% bei GPUs nochmals >50% es nicht begri haben was es heißt GPUs zu programmieren.

Gut vielleicht lege ich da höhere Anforderungen für "Umstieg" an, weil für mich das nur der Fall ist, wenn jemand performanten Code schreibt, der schneller ist als der serielle und dabei auch ne gewisse Effizienz hat. Bzw auch sieht, wann es UNMÖGLICH ist effizient zu parallellisieren.

Aber gut, bei mir fliegen deswegen auch schon viele bei seriellen Programmieren raus, weil so Sachen wie Cache Blocking etc nicht in deren Schädel geht...

Aber wenn ich an meine Arbeit in nem EU Forschungsprojekt denke, dann hat quasi keiner ne wirkliche Ahnung davon, warum sein Code nicht schneller ist. Und das sind Leute mit echter Erfahrung in paralleler Programmierung und trotzdem hat man absolute Brainfarts gesehen....

Die Güte von Code ist in beiden Fällen immer sehr von der Erfahrung und der Intuition des jeweiligen Programmierers abhängig.

Erfahrung in serielle Programmierung hilft aber nur bedingt beim parallelisieren und CPU Erfahrung nur bedingt bei GPU Programmierung.

Ich hatte z.b. mal nen Code Reviewed der so 10Mio Zeilen Code hatte und vom Core Entwickler und Gründer des Codes um GPU Code erweitert wurde. Ich habe nur 1-2h gebraucht um zu sehen, dass das NIEMALS schneller auf einer aktuellen GPU sein kann als auf einer aktuellen CPU. Hat mich dann aber knapp einen Monat und nen mehrtägigen vor Ort Termin gebraucht um das zu zeigen. Dabei ist noch nen Faktor 30 oder so beim CPU Code ausgefallen und nen Faktor 2-5 beim GPU Code. Am Ende war dann auch der CPU Code deutlich schneller. So wie es zu erwarten war....


Und nein, üblicherweise werden Codes nicht von Wissenschaftlern geschrieben. Wissenschaftler (z.B. Geologen, Physiker, Informationtheoretiker, Mathematiker, Chemiker, Meteorolgen) erstellen Algorithmen ohne Ahnung vom Programmieren / Programmiersprachen zu haben. Programmierer setzen diesen dann in funktionalen und perfomanten Code um. In schwierigen Fällen helfen ausgebildete Algorithmiker als Bindeglied. Gute Programmierer für gängige Programmiersprachen sind relativ einfach zu bekommen, gute Wissenschaftler im jeweiligen Fachgebiet schon schwerer, und in diesem Punkt stimme ich dir zu: gute Algorithmiker sind rar. Algorithmik war mal Teil eines meiner früheren Berufe. Habe dann auch gleich das Programmieren mit übernommen. Meine Erfahrung ist: Wenn sich ein Wissenschaftler der weiss was berechnet werden soll (die Formeln) und ein Coder der seine Programmiersprache kennt zusammensetzen, dann dauert das meist zwar etwas bis diese verstehen was der jeweils andere in seiner Fachsprache eigentlich genau meint, aber dann kommt meist ein zumindest 3/4 perfomanter Code bei rum.

Du bist nicht beruflich im HPC Umfeld tätig oder? Das ist so weit weg von der Realität...


Spezialfälle wie Monte-Carlo-Algorithmen, Algorithmen für Qantencomputer, Chaostheorie, nondeterministische Algorithmen, und Ähnliches mal ausgenommen.

Problematisch wird es wenn weder Coder noch Aufgabensteller Ahnung von Algorithmik haben und dies nicht berücksichtigt wird (bedingt z.B. allgemein fehlendes Fachwissen, Projektleiter, Chef, Firmenphilisophie, Zeitdruck, Spardruck, persönlicher, Ehrgeiz, Selbstdarstellung, Carrierechancen). Dann kommt gerne Müll-Code bei rum. Typischies Beispiel ist wenn eine fachfremde Firma einen Programmierjob extern vergibt, aber nicht mal das Problem / die Aufgabenstellung definieren kann. Programmierer, Informatiker und Algorithmiker werden halt gerne zusammen in einen Topf geschmissen. "Hat doch alles was mit Computern zu tun, muss doch irgendwie gehen."

Im wissenschaftlichen Bereich kommt dies eher selten vor. Die meisten Firmen lernen nachdem sie ein / zweimal finanziell (oder zeittechnisch oder qualitativ) gegen die Wand gefahren sind. Am "schlimmsten" sind Behörden (meine Erfahrung erstreckt sich dabei ausschleißlich auf deutsche Behörden). Die kaufem immer und immer wieder Müll-Software ein, und lernen rein gar nichts daraus.

</OT>

AHA Erfahrung aus deutschen Behörden. Was soll denn das sein? Und beziehst du dich da eventuell auf buisness Logik? Dir ist schon klar, dass das total ungeeignet für GPUs und erst recht FPGAs im Allgemeinen ist?

Was du meinst ist sicherlich CoProgrammiung und das findest du fast nirgends.

[Orko]

<OT> @Skysnake

"Wahrscheinlich auch ohne Synthese oder wenn dann ohne Anforderungen daran. Also weder bezüglich Ressourcenverbrauch noch an erreichte Taktrate."

Hab grad mal nachgeschaut, den Kurs gibts nach all den Jahr(zehn)ten immer noch:
https://www.uni-ulm.de/in/mikro/lehre/projekte-ss/project-design-of-integrated-systems/
War damals halt VHDL statt Verilog. Bewertungskriterien waren Anzahl benötigter Gates und "Stromverbrauch" als Maßstab der Effizienz des entwickelten Systems. Maximale Taktrate war kein Kriterium - verständlich bei einem Fahrradcomputer. Kontrolle der Taktraten, bzw welche Schaltungsbereiche mit welcher Frequenz getaktet / aktualisiert werden hingegen schon. Routing war automatisiert. Zum Schluß konnte man mit dem Fahrrad rumfahren, das Display betrachten und die Knöpfe drücken.

"Die Algorithmen waren vorgegeben, also wie das zu implementieren ist. Genau das steht ja aber meist aus."

Äh nein. Und der Systementwurf hat deutlich mehr Zeit gekostet als die Programmierung an sich. Algorithmen waren nicht nötig, dazu war die Aufgabenstellung zu simpel. Mit Algorithmen habe ich mich erst viel später beschäftigt, z.B. Algorithmen zur Kompression von bestimmten Daten bzw Signalen.

"Also das deckt sich weder mit meiner Erfahrung aus der Uni, wo 50-70% Ärger Probleme mit dem Umstieg auf paralleles Programmieren hatten und dann von den 50-30% bei GPUs nochmals >50% es nicht begri haben was es heißt GPUs zu programmieren."

Ich kann hier nur meine angestaubten Studi-Erfahrungen zur FPGA Programmierung beitragen. Mit GPU Programmierung hatte ich bislang keine engeren Kontaktpunkte. Die Reihenfolge in der wir damals Programmiersprachen gelernt haben war Pascal-Derivate -> C -> VHDL, und soweit ich mich erinnere sind alle bis auf einen Komilitonen mit dem Umstieg auf das parallele Programmieren gut zurechtgekommen.

"Du bist nicht beruflich im HPC Umfeld tätig oder? Das ist so weit weg von der Realität..."

Hofzauberer am Hofe seiner Majestät König Randor in Eternia.
Darüber hinaus, sorry, kein Kommentar möglich.

Die Schilderung entspricht meiner Erfahrung zu Kontakten im akademischen Bereich. Fiktives Beispiel: Die Fakultät für Informatik stellt die Hardware (Rechenzeit), die Kompetenz in den Bereichen Informatik und Algorithmik, und einige in der gewünschten Programmiersprache talentierte Studenten / HiWis / Diplomanten. Die Fakultät für z.B. Biochemie stellt die mathematischen Modelle für Moleküle und Reaktionen, die Aufgabenstellung, und z.B. einen Doktoranten der diese versteht und erklären kann. Je höher die wissenschaftliche Kompetenz bzw der akademische Status in einem Fachbereich, desto unwahrscheinlicher ist es dass der Wissenschaftler selber coded. Er / sie delegiert.

Vielleicht haben wir beide auch einfach nur eine etwas unterschiedliche Auffassung von den Begriffen "Wissenschaftler" und "Coder / Programmierer". Ist zumindest mein Eindruck.

</OT> over and out

[Skysnake]

Welche Uni war denn das? Schlecht ist das nämlich keineswegs! Spiegelt nur nicht meine Realität wieder. Und diese bezieht sich auf die Uni Heidelberg, Uni Stuttgart und die Höchstleistungsrechenzentren Stuttgart (HLRS) und München (LRZ), sowie die Rechenzentren Dresden und Ulm. Ich habe aber auch mit Leuten von Archer, DWD, Mainz, Medien Stuttgart sowie diversen Firmen zu tun. Und da kann ich das wirklich nicht bestätigen. Die Regel ist eher, das ein Doktorand z.b. in Strömungsmechanik promoviert und dann eben ein neues Feature implementiert. Ich kenne jetzt nicht wirklich eine Arbeitsgruppe bei der es reine Informatiker gab die sich um den Code gekümmert haben und daneben Algorithmiker. Ich kenne eher, das es z.b. ne Arbeitsgruppe Algorithmik gibt, diese aber Codes analysieren und schauen wie man das erweitern kann. Da wird auch gerne mal die neue Hardware mit angeschaut.

Wie gesagt ich war in dem Bereich einige Jahre direkt tätig und bin inzwischen auf der anderen Seite bei den Herstellern. Reine Informatiker sind da die echten Exoten.

Der Kurs hört sich btw stimmig an. Waren am Ende wahrscheinlich ein paar Schieberegister, Coubter und FSMs. Das kann am Ende schon auch einiges an Komplexität ergeben. Das nach Anzahl Gattern und Stromverbrauch bewertet wurde ist auch sehr gut, denn das lässt einen Nachdenken!

Mit "Algorithmen" meine ich z.b. schon wie man denn nen Multiplizierer baut vzw wie man die Schleife im Algorithmus in HW umsetzt, also wo nehme ich mehrere ALUs und rechne ne Schleife in einem Schritt, oder wo schiebe ich einzelne Werte durch ne Pipeline, damit ich nicht mehrfach lesen muss usw usf. Das wird halt am Ende quasi beliebig komplex und daran krankt halt der FPGA. Du musst schon echt viel implementieren, damit du einen Vorteil hast. Und dann wird es komplex wenn es nich arsch langsam werden soll musst du mit constraints arbeiten usw usf.

Wie gesagt, ich hatte damit direkt zu tun, wobei dort für nen ASIC entwickelt wurde, was es nochmals schwerer macht. Aber auch sonst aus angrenzenden Bereichen kenne ich eigentlich fast nur Paper bezüglich nicht erreichter Ziele. Und mir kann man da wirklich keinen Pessimismus vorwerfen. Ich habe immer versucht Leute für FPGAs zu begeistern, aber das ist verdammt schwer. Hatte mit meinem Chef da auch mal eine längere Diskussion drüber ob man ne Gruppe in die Richtung pushen soll oder nicht. Ich war dafür Chef nicht, weil die Leute weder das Geld noch das KnowHow dafür gehabt hätten und dazu dann auch noch selbst wenn erst mal für X Jahre ohne Publikation dagestanden wären. Die Durststrecke musst du erst mal überleben. War nen Code aus der Festkörperphyisik mit Fernfeld. Also viel all to all ohne die Möglichkeit zur Näherung durch Aggregation. Die werden nie signifikant schneller werden ohne auf FPGAs oder ASIC zu gehen. Die interessieren nämlich nur recht wenige Systeme aber SEHR lange Zeitskalen. Also serielles Problem. Die hatten nur bis 4 Knoten skaliert, wobei "skalieren" für die hieß es wird nicht langsamer.... ich meine mit 4 Knoten hatten Sie nen Speedup von 2,x oder so im Vergleich zu einem Knoten. War denen aber egal, weil die schon so Monate/Jahre an einem Ding gerechnet haben... gibt btw wohl weltweit nur eine Gruppe die in dem Bereich mit FPGA/ASIC arbeitet. Die sind halt Faktor 100-1000 schneller bei der Simulation... keine Ahnung wie die mit denen ich zu tun hatte vernünftig Paper realisiert bekommt.

Das ist halt meine First Hand experience aus dem HPC Bereich. Ich kenne noch nicht mal viele sites die überhaupt FPGAs haben in ihren Systemen. Also Center. Spontan fällt mir da nur Ulm ein. Die meisten haben dafür halt auch einfach nicht die Expertise. Heidelberg hat/hatte Sie zum Beispiel, das war aber nicht beim Rechenzentrum verfügbar sondern in Arbeitsgruppen. Man braucht da halt auch echt nen langen Atem wenn man an Simulationen, also HPC geht.

Heidelberg hat ja z.b. auch für BlueBrain was gemacht bzw für die LHC Detektoren.

Maschinenbauer etc haben es da sicherlich einfacher es z realisieren weil es einfacher/abgegrenzter ist.

Insgesamt aber alles nicht trivial.

Oder anders gesagt, kennt überhaupt jemand jemanden der die Intel-CPU+FPGA Lösung im Einsatz hat? Ich kenne nicht einen. Geschweige denn das es produktiv genutzt wird.

Und ich bin da echt für alles offen!

Aber deswegen würde ich mir davon für "normale" Nutzer nicht wirklich was erhoffen. Vielleicht kann AMD das für ihre Chips irgendwo nutzen die Idee mit dem GPU Treiber finde ich z.b. gar nicht so abwegig. Aber wirklich vorstellen kann ich mir nur wenig. Die Erfolgsmeldungen bleiben leider einfach sehr sehr sehr überschaubar, selbst wenn man jeden Stohhalm feiert.

[amdfanuwe]

Seht es mal so: Mit GPU als Beschleuniger arbeitet man auch erst ein paar Jahre.
FPGA rückt so langsam ins Bewustsein, dass einige Sachen damit besser Beschleunigt werden können als mit GPU.
Wie die auf Hardwareebene programmiert werden interessiert die wenigsten.

https://6lli539m39y3hpkelqsm3c2fg-wpengine.netdna-ssl.com/wp-content/uploads/2021/11/Xilinx_Vitis_Platform.png

Ich habe an einem Prüfstand Mit National Instruments Hardware in Labview "programmiert".
Im prinzip Graphische C-Programmierung. Wenn man das System des Datenflusses verstanden hatte und die parallelen Möglichkeiten des FPGA-Teils entsprechend nutzt ist das eine hübsche Geschichte ohne eine Zeile Code zu schreiben.
Mein Vorgesetzter, Physiker, knallte zur Auswertung dann noch ein paar FFT und andere Funktionsblöcke zur grafischen Auswertung der eingesammelten Daten rein.
Ein paar Klicks, funktioniert und gut.
Die parametrisierung der FFT etc. war dann schon das größte Problem. Dazu fehlte mir das Wissen, war für den Physiker nur eine Fingerübung.
Ich nehme mal an, die FFT wurde durch den Compiler auf das FPGA optimiert.
Wozu hat man schließlich Bibliotheken und APIs?

[Skysnake]

Ja, nur ist das kein "Programmieren" wie du schon richtig sagst. Das war die Auswertung von irgendwelchen Sensordaten oder?

Bei Simulation kommen die Leute daher und machen irgendwelchen fancy shit. Klar kann man z.b. auch OpenCL benutzen, am Ende fehltden Leuten aber oft die Semantik in der Sprache um die Fähigkeiten der FPGAs sinnvoll auf die FPGAs zu kappen.

Und ja FFTs sind z.b. so was, das sich eignet für FPGAs.

[basix]

Entsprechende SW-Bibliotheken sind natürlich der Schlüssel für eine weite Verbreitung. Heute programmiert man CPUs auch nicht mehr in Assembler und mit z.B. einer MKL kommen hochoptimierte Code-Teile daher. Sowas benötigt man auch für FPGAs. Allerdings halt etwas flexibler (z.B. wäre eine Vektorbreite oder die Breite eines Datenpfades einstellbar).

Bei Xilinx geht man zudem mit Versal in Richtung ACAP: Adaptive Compute Acceleration Platform
https://www.xilinx.com/content/dam/xilinx/support/documentation/white_papers/wp505-versal-acap.pdf

Schlussendlich kann man damit fixe Funktionsblöcke frei verdrahten und miteinander verknüpfen. Dies geschieht via FPGA-Teil. Und gewisse Fixed Function Logic sind daneben ganz normal verfügbar (wie CPU Cores). Was, wenn AMD dieses Konzept auf einige ihrer CPUs und GPUs anwendet?
While programmable logic (FPGA) and vector-based (DSP, GPU) implementations have recently demonstrated great performance gains over CPUs, the true benefit of the ACAP architecture only comes into focus when developers leverage more than one type of the Versal ACAP's compute element to enable a tightly coupled compute model. In this case, 1+1+1 can be much more than 3.
In der Tabelle 2 des verlinkten Papers sind sehr ordentliche Speed-Ups zu sehen, auch gegen GPUs und FPGAs.

[Skysnake]

Naja, sehr viel Code hat aber eben nichts mit MKL etc zu tun. Klar gibt es den auch mal irgendwo zwischendurch, aber eben nicht.

Der Einwurf mit den SOC FPGAs ist aber berechtigt. Ich würde es aber umdrehen. Die AMD CPUs bekommen nicht FPGAs, sondern die FPGAs bekommen x86 CPU Cores.

Da könnte für manche Appliances schon attraktiv sein wegen der höheren per Core Leistung.

Ich denke da z.b. an L3 Switche usw.

[Zossel]

Da könnte für manche Appliances schon attraktiv sein wegen der höheren per Core Leistung.

Ich denke da z.b. an L3 Switche usw.

Wofür brauchen L3 Switche viel CPU?

[amdfanuwe]

Ja, nur ist das kein "Programmieren" wie du schon richtig sagst.
Programmieren besteht eben nicht nur aus kryptischen Codezeilen schreiben.
Ist schon eine andere Ebene den Code graphisch dargestellt zu haben.
Ebenso habe ich gerne mit VisualState zur Darstellung von State Machines gearbeitet.
Nützt halt alles nichts, wenn man nicht versteht, was auf Hardwareebene passiert.

-----

Ja, war ein Sensor Prüfplatz. Sensoren ansteuern und programmieren, Motoren ansteuern, drehzahl erfassen, Sensordaten empfangen, CRC berechnen, Daten vorverarbeiten, sammeln, das ganze mit mehreren Bussystemen (SPI, Eindraht...) und Protokollen.
Geht nur mit FPGA in Echtzeit.
Die ARM Cores auf dem Chip braucht man für die Kommunikation über Ethernet mit dem PC, wo die Daten gespeichert werden und die Ausgabe an Bildschirm erfolgt.

----

Ich fände einen FPGA Teil in der CPU schon interessant. Da ließen sich sicherlich mehr Programme mit Beschleunigen als mit AVX 512.
Hängt halt von den Bibliotheken und Compilern ab, wie das genutzt wird.

[Skysnake]

Ja, ich habe auch FSMs programmiert und da ist die grafische Aufbereitung Gold wert. Ansonsten verliert man da ziemlich schnell den Überblick...

---

Mit so was hatte ich gerechnet. Das sind die Fälle in denen FPGAs richtig glänzen können. LHC wäre ohne FPGAs/ASICs in den triggern auch nicht machbar.

Aber da kommen wir halt zu dem Punkt, wo man das zum Consunermark differenzieren muss. Dort gibt es nicht die drölf Millionen Spezialfälle auf die man sich anpassen muss.

Und bei HPC könnte man z.b. FFTs ja auch beschleunigen, nur hat man da den Datentransfer
Und FPGAs sind auch nicht billig und am Ende vom Tag bedeutet jeder Euro in so was ein Euro weniger in RAM, Netzwerk, CPUs oder schlich Anzahl Knoten.

Und da sind wir wieder bei gleichen Problem wie bei GPUs. Zu wenige Codes nutzen es überhaupt und selbst von denen die es tun an zu wenigen Stellen.

---

Für dich sicherlich. Aber für die Allgemeinheit??? Da habe ich meine Zweifel

[amdfanuwe]

Für dich sicherlich.
Neh, für mich nicht mehr. Hab mich dank AMD Aktien zur Ruhe gesetzt und bin froh mir das Elend in der Industrie nicht mehr antun zu müssen.
Da kommt man mit guten Vorsätzen und der Vorstellung wie man gute Software entwickelt von der Schule und darf 20 Jahre nur Basteln.
Frustrierend.

Übrigens würde ich jedem Programmierer mal SPS Programmierung empfehlen. Da lernt man Parallel programmieren.

---

Lustig wird es übrigens wenn man vom Arbeitsamt einen HTML Programmierkurs zur Weiterbildung angeboten bekommt.
Web-Programmierer sind ja so gefragt.

[Skysnake]

Haha der war gut :D

Ich bin etwas verbittert nicht 10k in 2016-2018 für um die 8$/€ gekauft zu haben. Da hätte ich nen Faktor 10 Gewinn gemacht. Und je nachdem nochmals nachgekauft bis so 20$/€. Aber hätte auch nicht gedacht, dass das auf über 100 steigt...

Blöd halt wenn man kein flüssiges Spielgeld hat. Aber mit nem Neugeborenen fällt das schwer. Vor allem wenn das zweite dann auch noch anrückt...

[amdfanuwe]

Ja, kenn ich.
Meine sind jetzt Ü20 und denken nicht ans ausziehen.
Hat ja auch 20 Jahre gedauert bis ich nach und nach genügend Aktien angesammelt hatte. Da ich nicht auf das Geld angewiesen war und das weitere Potential von AMD sah, konnte ich die liegen lassen. Ein Jahresgehalt mit 2000% Gewinn, da kann man schon daran denken die Lebensarbeitszeit zu verkürzen.
War aber auch Glückssache bei AMD so dabei zu sein.
Apple, Nvidia, Tesla, Bitcoin, Hanf etc. hab ich verpennt.

[mksn7]

Welche Uni war denn das? Schlecht ist das nämlich keineswegs! Spiegelt nur nicht meine Realität wieder. Und diese bezieht sich auf die Uni Heidelberg, Uni Stuttgart und die Höchstleistungsrechenzentren Stuttgart (HLRS) und München (LRZ), sowie die Rechenzentren Dresden und Ulm. Ich habe aber auch mit Leuten von Archer, DWD, Mainz, Medien Stuttgart sowie diversen Firmen zu tun. Und da kann ich das wirklich nicht bestätigen. Die Regel ist eher, das ein Doktorand z.b. in Strömungsmechanik promoviert und dann eben ein neues Feature implementiert. Ich kenne jetzt nicht wirklich eine Arbeitsgruppe bei der es reine Informatiker gab die sich um den Code gekümmert haben und daneben Algorithmiker. Ich kenne eher, das es z.b. ne Arbeitsgruppe Algorithmik gibt, diese aber Codes analysieren und schauen wie man das erweitern kann. Da wird auch gerne mal die neue Hardware mit angeschaut.


Komme auch aus dem universitären Rechenzentrumsumfeld, und kann das bestätigen. Im HPC gibts keine Informatiker (übertrieben). Die Leute die HPC bei uns machen sind alles domain scientists, also Leute für die die Computer nur ein Mittel zum Zweck ihrer eigentlichen Forschung sind.

Wir sehen aber auch dass die Leute immer weniger tatsächlich eigene Codes schreiben, sondern große community codes verwenden. Bei denen ist nicht unbedingt gegeben dass die gut optimiert sind, vor allem weil die recht flexibel sind. Aber bei den meisten hat zumindest schonmal jemand versucht eine GPU Portierung zu machen, wenn es der vendor nicht sogar selbst macht.

Aber für FPGA macht sicher keiner was.

[basix]

Naja, sehr viel Code hat aber eben nichts mit MKL etc zu tun. Klar gibt es den auch mal irgendwo zwischendurch, aber eben nicht.

Der Einwurf mit den SOC FPGAs ist aber berechtigt. Ich würde es aber umdrehen. Die AMD CPUs bekommen nicht FPGAs, sondern die FPGAs bekommen x86 CPU Cores.

Da könnte für manche Appliances schon attraktiv sein wegen der höheren per Core Leistung.

Ob nun x86 CPU + FPGA oder FPGA + x86 CPU ist doch egal ;) Hier stellt sich für mich eher die Frage, ob man als Formfaktor PCIe Erweiterungskarten wählt oder als Alternative halt auf den EPYC Sockel.

Und MKL war nur ein Beispiel. Bei FPGA wäre das eher sowas wie eine Vektor-FPU als Designtemplate. Vektorbreite dann wählbar. Hintereinanderreihen von mehreren Vektor/Matrizen FPUs mit individueller Breite. Für ML sicher sehr interessant.

Zu grafischen "Programmiersprachen":
LabView ist zwar einfach beim Einstieg. Umso komplexer es wird, desto weniger ist LabView geeignet und performant ist LabView noch nie gewesen. Beim Tool würde ich eher sowas Matlab Simulink wählen. Daraus lässt sich bereits heute C-Code oder was für SPS und DSP synthetisieren. Und für FPGA gibt es diese Synthetisierung ebenfalls bereits: https://de.mathworks.com/discovery/fpga-programming.html

AMD und Xilinx müssten allenfalls einen Custom-VHDL/Verilog-Coder bereitstellen, welcher ihre Plattform optimal ausnutzen kann. Hinter den FFT, Filter und was auch immer Grafik-Icons im Simulink Modell hängt ein Template für das VHDL-Design. Für das Verknüpfen der einzelnen Funktionsblöcke gäbe es dann noch einen übergeordneten "Compiler", welcher die Datenpfade optimiert. So weit weg von einem praktikablen Einsatz ist das aus meiner Sicht nicht. Gerade weil Wissenschaftler schon viel mit Matlab machen (ist verglichen mit Python aber kostenpflichtig). Als Alternative könnten AMD und Xilinx ja ein eigenes "Simulink" zur Verfügung stellen, welches kostenfrei ist.

Aber für FPGA macht sicher keiner was.
Wenn man mit ACAP CPU + FPGA + GPU/NPU verbindet, ergibt sich eine kleinere Einstiegshürde. Alles nur auf FPGAs umsetzen macht wohl wirklich keiner. Wenn man ein FPGA aber "by-the-way" auch mitnutzen kann, ist es wohl weniger weit weg.

Mit einem FPGA könnte man allenfalls einzelne kritische Algorithmen-Teile massiv beschleunigen (Bottlenecks). Den Rest lässt man auf CPU/GPU.

[Skysnake]

Ob nun x86 CPU + FPGA oder FPGA + x86 CPU ist doch egal ;) Hier stellt sich für mich eher die Frage, ob man als Formfaktor PCIe Erweiterungskarten wählt oder als Alternative halt auf den EPYC Sockel.

Na das ist schon nen großer Unterschied. Es soll ja bestimmen wo 80-90% des Preises her kommen.


Und MKL war nur ein Beispiel. Bei FPGA wäre das eher sowas wie eine Vektor-FPU als Designtemplate. Vektorbreite dann wählbar. Hintereinanderreihen von mehreren Vektor/Matrizen FPUs mit individueller Breite. Für ML sicher sehr interessant.

Zu grafischen "Programmiersprachen":
LabView ist zwar einfach beim Einstieg. Umso komplexer es wird, desto weniger ist LabView geeignet und performant ist LabView noch nie gewesen. Beim Tool würde ich eher sowas Matlab Simulink wählen. Daraus lässt sich bereits heute C-Code oder was für SPS und DSP synthetisieren. Und für FPGA gibt es diese Synthetisierung ebenfalls bereits: https://de.mathworks.com/discovery/fpga-programming.html

AMD und Xilinx müssten allenfalls einen Custom-VHDL/Verilog-Coder bereitstellen, welcher ihre Plattform optimal ausnutzen kann. Hinter den FFT, Filter und was auch immer Grafik-Icons im Simulink Modell hängt ein Template für das VHDL-Design. Für das Verknüpfen der einzelnen Funktionsblöcke gäbe es dann noch einen übergeordneten "Compiler", welcher die Datenpfade optimiert. So weit weg von einem praktikablen Einsatz ist das aus meiner Sicht nicht. Gerade weil Wissenschaftler schon viel mit Matlab machen (ist verglichen mit Python aber kostenpflichtig). Als Alternative könnten AMD und Xilinx ja ein eigenes "Simulink" zur Verfügung stellen, welches kostenfrei ist.

Ist ja nicht so als ob das nicht schon seit Jahrzehnten versucht wird. Das ist das Gleiche wie halt die Compiler die galt mal "nur" vernünftig optimierten Maschinencode generieren müssen.... dabei übersieht man aber halt, das der Compiler sich halt haargenau an die Semantik der Sprache halten muss. Wobei wenn man mit Compilern zu tun hat man recht schnell merkt, das selbst GCC und ICC sich oft genug nicht an die Standards halten und eigentlich ungültige Optimierungen machen bzw Code fressen der so gar nicht valide ist....


[/quote]
Wenn man mit ACAP CPU + FPGA + GPU/NPU verbindet, ergibt sich eine kleinere Einstiegshürde. Alles nur auf FPGAs umsetzen macht wohl wirklich keiner. Wenn man ein FPGA aber "by-the-way" auch mitnutzen kann, ist es wohl weniger weit weg.

Mit einem FPGA könnte man allenfalls einzelne kritische Algorithmen-Teile massiv beschleunigen (Bottlenecks). Den Rest lässt man auf CPU/GPU.[/QUOTE]
Das ist doch aber das Problem! Der FPGA Teil ist nicht dort free. Und wenn er zu oft ungenutzt Rum steht, dann lieber weglassen und paar Knoten mehr haben. Wie zuvor schon gesagt genau das gleiche Problem wie bei GPUs. Nur das GPUs sehr viel weiter verbreitet sind.

[basix]

Ist ja nicht so als ob das nicht schon seit Jahrzehnten versucht wird. Das ist das Gleiche wie halt die Compiler die galt mal "nur" vernünftig optimierten Maschinencode generieren müssen.... dabei übersieht man aber halt, das der Compiler sich halt haargenau an die Semantik der Sprache halten muss. Wobei wenn man mit Compilern zu tun hat man recht schnell merkt, das selbst GCC und ICC sich oft genug nicht an die Standards halten und eigentlich ungültige Optimierungen machen bzw Code fressen der so gar nicht valide ist....

Ja, zu hohe Optimierungen sind nie gut. Bei uns werden eher konservative Level gewählt, obwohl Speicherplatz in MCUs knapp ist.

Bei diesen "FPGA-Libraries" erwarte ich aber auch nicht zu hohen Optimierungsgrad. Zumindest weit entfernt von ASIC-Level.


Das ist doch aber das Problem! Der FPGA Teil ist nicht dort free. Und wenn er zu oft ungenutzt Rum steht, dann lieber weglassen und paar Knoten mehr haben. Wie zuvor schon gesagt genau das gleiche Problem wie bei GPUs. Nur das GPUs sehr viel weiter verbreitet sind.

Klar. Für die Masse ist ein FPGA-Zusatz nicht gedacht. Das ist 3DV-Cache aber auch nicht. Gibt viele Anwendungen, wo überhaupt nicht davon profitieren. Gaming ist hier ein Spezialfall. Es gibt für viele Codes zudem sicher Performance-Tracing, wo ersichtlich wird, wo viel Zeit verwendet wird. Gibt es auch für Python als Plugin, wo man sehr schnell diese Teile evaluieren und optimieren kann (meistens kein grosser Aufwand für die ersten 80% des Optimierungspotentials).

Jetzt ist die Frage, ob und wie oft solche kritische Code-Teile mittels FPGA beschleunigt werden können. Für Consumer HW ist dies aber eher nicht gedacht. Deswegen mMn nach die Auslegung auf EPYC / HPC und bestenfalls 3D-Stacked auf die CPU-Chiplets. Verbindung mit CDNA wäre eine andere Möglichkeit.

Für Consumer-Produkte und Standardware wäre der Waste = 0. Bei entsprechenden Anwendungen mit Optimierungspotential der Benefit = Faktor X.

[fondness]

Durch den gestiegenen Aktienkurs von AMD kostet die Xilinx-Übernahme den AMD-Aktionären fast 50 Milliarden:
https://www.computerbase.de/2022-02/uebernahme-fuer-49.8-mrd.-usd-erste-amd-xilinx-produkte-bereits-fuer-2023-angepeilt/

Und ist damit die größte Übernahme in der Geschichte der Halbleiterindustrie.

[Tobalt]

Ich habe das programmieren in Labview gelernt. für viele dinge würde ich es nicht im Traum einsetzen da zu umständlich, aber einer hat es schon immer super gemacht und zwar Parallelisierung.

Auch heute nutze ich noch Labview FPGA und da hat man auch kontrolle über jeden einzelnen cycle und bit wenn man es braucht. Ich benutze das nur so. Am ende nutzt das auch den Vivado Implementer und ist nicht mehr oder weniger performant als direkt in VHDL geschriebenes Zeug. Wenn man einen sehr hohen Grad an gate usage hat, wird man aber wohl mit Labview die Ressourcen nicht zu gut ausreizen können.

Aber ansonsten bin ich voll bei Skysnake, selbst die wenigsten Labview User könnten die FPGAs zu irgendwas sinnvollem nutzen. Der ganze Nutzen ist zu situational für Endnutzer

[basix]

Durch den gestiegenen Aktienkurs von AMD kostet die Xilinx-Übernahme den AMD-Aktionären fast 50 Milliarden:
https://www.computerbase.de/2022-02/uebernahme-fuer-49.8-mrd.-usd-erste-amd-xilinx-produkte-bereits-fuer-2023-angepeilt/

Und ist damit die größte Übernahme in der Geschichte der Halbleiterindustrie.

Erste Produkte 2023. Bergamo? Zen 5? CDNA3? NextGen Versal?

Edit:
https://www.forbes.com/sites/patrickmoorhead/2022/02/14/its-day-one-for-the-combined-amd-and-xilinx-and-ceo-lisa-su-is-energized/
Lisa Su told me we should see the first AMD processor with Xilinx AI IP in 2023.

[zst]

Ist zwar nicht AI, aber sind die UVD/VCE/VCN Blöcke eigentlich ein Hausgewächs oder evtl. externe IP? Vielleicht gibt es dann bessere Encoder in kommenden Radeon GPUs.

[Tobalt]

Was bitte ist Xilinx AI IP außer einem Buzzwort. Xilinx verkauft ja so viele KI Beschleuniger.. Und AMD ist nicht fähig selbst eine Low Precision Matrix MUL Einheit zu designen ??

[amdfanuwe]

Xilinx verkauft ja so viele KI Beschleuniger..
Du hast Zahlen dazu? Immer her damit.

[basix]

@Tobalt:
Wenn ich raten müsste: Sparsity.

[Tobalt]

uwe: nein keine Zahlen und Xilinx verkauft sicher viel an KI Apps, aber was ich meinte ist dass sie eben keine AI Hardware verkaufen, sondern FPGAs. Falls die User damit KI machen, dann ist das doch letzlich Software, wie also soll diese Software in eine CPU integriert werden ?! Deswegen sag ich Buzzwort.

basix: Danke,werde ich mir genauer ansehen. Wie schon oft gesagt fällt das aber für mich in die Kategorie "Neue Anwendungen, bei denen noch kein Fixed-Function-Konsens besteht und deshalb FPGA Sinn machne". Also FPGA, nicht irgendwelche CPU/GPU/FPGA Hybride mit 12 unnützen Cores.

Es könnte natürlich sein, dass Su's Aussage sich nicht auf einen konventionellen AMD Prozessor bezieht, der dann ein FPGA angeflanscht bekommt, sondern tatsächlich einen neuen ASIC meint, der zB. auf Xilinx' Knowhow mit gut ASIC-baren AI Algorithmen aufsetzt.

[amdfanuwe]

sondern FPGAs.
So gesehen verkauft Nvidia auch nur GPUs.

[unl34shed]

uwe: nein keine Zahlen und Xilinx verkauft sicher viel an KI Apps, aber was ich meinte ist dass sie eben keine AI Hardware verkaufen, sondern FPGAs. Falls die User damit KI machen, dann ist das doch letzlich Software, wie also soll diese Software in eine CPU integriert werden ?! Deswegen sag ich Buzzwort.

Ist jetzt die Frage zu was man die Versal Plattform zählt. Du hast ein ARM SoC, FPGA, aber auch Xilinxs AI Engine in einem Package. Kann man natürlich als FPGA mit co-Prozessoren sehen, aber wenn man ehrlich ist, ist es dedizierte AI Hardware. Und 200TOPs ist jetzt nicht gerade wenig für keine AI Hardware.

[MSABK]

Ich hab überhaupt keine Kenntnis über die Industrie. Warum ist Xilinx so teuer? Haben die auch eine Foundry oder „designen“ die nur Chips?

[w0mbat]

Die haben FPGAs erfunden und sind der größte FPGA Entwickler. Keine eigene FAB.

Und "teuer" ist auch nicht so richtig, AMD hat 10x Umsatz gezahlt.

[Denniss]

AMD muß in sache AI/KI zu nvidia aufschließen und solche Entwickler/Ingenieure wachsen nicht auf Bäumen. Da schaut man sich halt um ob man sich nicht ne gute Firma zukaufen kann.

[Zossel]

Oder wie Zossel sagt, wären das Beschleuniger-Funktionen für gewisse Tasks. Ob nun Networking-Acceleration oder was auch immer.

Gerade für Supercomputer und HPC konnte so eine gemischte CPU einigen Sinn machen, wenn man auf einige Spezialanwendungen spezifisch die Algorithmen optimieren kann.

In der Cloud gibt es überall Ethernet und IP, AMD könnte im ersten Schritt derartige Netzfunktionen via FPGA in den Markt bringen und dann in einem zweiten Schritt, auch mit verbesserter Software wo schon erste Betriebserfahrung drin steckt, die Funktionen "asic-like" auf dem Die unterbringen. Von besseren Latenzen profitiert eigentlich fast alles.

[Brillus]

AMD muß in sache AI/KI zu nvidia aufschließen und solche Entwickler/Ingenieure wachsen nicht auf Bäumen. Da schaut man sich halt um ob man sich nicht ne gute Firma zukaufen kann.
Bin noch nichtmal so sicher ob das, das wichtigste ist. Xilinx ist auch extrem stark im IO und Low-Level Design. Auserdem haben die auch sehr viel Erfahrung mit Chiplets, Stacking etc.

[Zossel]

https://community.intel.com/t5/Blogs/Products-and-Solutions/Software/Intel-Acquires-Linutronix/post/1362692

Wäre vielleicht die ein oder andere Linux-Butze was für AMD?