AMDs Fusion war die Grundlage für die heutige Zen Struktur.
Nein, wer dies glaubt, zeige mir mal was von Fusion noch in Zen steckt und wird nichts finden, denn er hat überhaupt nicht verstanden, was Fusion überhaupt ist. Es ging um die Integration von CPU und GPU und Zen hat entweder gar keine GPU mehr oder eine die wieder genauso von der CPU getrennt ist wie vor der Fusion Integration.
Das effiziente Multichiplet Design hat massiv davon profitiert.
Fusion hat mit Chiplets gar nichts zu tun, dies Fusion APUs waren alle monolithische Designs.
Bei Intel ist es halt mit drauf wegen der Bildausgabe.
Genau wie bei allen APUs auf Zen Basis, AMD hat Fusion komplett begraben!
wenn man von einem G AMD Prozessor die GPU für floatings nutzen würde (Vega) würde das jeden Intel CPU nieder machen,
Belege? Das ist totaler Quatsch, die Zen basierten APUs haben kein Fusion mehr, die haben eine CPU und eine iGPU die genauso getrennt sind wie bei den Intel CPUs mit iGPU.
Bei Intel werden halt diese Floatings der GPU von der CPU geshared., wie mit dem Shared Memory Müll.
Was für ein Quatsch²! Es gibt Intel CPUs ohne iGPU deren FP und sonstige CPU Performance nicht schlechter als die der Modelle mit iGPU ist, teils sogar ein wenig besser, weil die CPU sich die RAM Zugriffe nicht mit der iGPU teilen muss. Die RAM Bereich sind aber eben strikt getrennt und dies ist bei den aktuellen, Zen basierten AMD APUs eben nicht anderes.
Oder was meinst du/ihr warum Intel auf biegen und brechen auch endlich dedizierte Grafikkarten auf den Markt bringt?
Erstmal bin ich nur einer, keine Gruppe und dann ist es eben der Weg den Intel geht, nachdem die Xeon Phi eben nicht erfolgreich waren. Ebenso wie AMD mit Fusion in eine Sackgasse gerannt ist, ist es Intel auch mit den Xeon Phi und dann orientiert sich ein Unternehmen eben um. Dedizierte Grafikkarten machen im HPC ja durchaus Sinn, aber dies bedeutet eben nicht, dass Befehlserweiterungen wie AVX-512 und demnächst dann AMX (Advanced Matrix Extension) keine Sinn machen, denn beides konkurriert weniger als es sich ergänzt.
Man kann auf Dauer auch technisch nicht mehr in allen Bereichen auf selben Fläche in allen Disziplinen die Rechenleistung oben halten.
Was soll dieser Satz uns sagen? Es sollte klar sein, dass man mehr Transistoren braucht um die IPC zu steigern, egal ob mit Befehlssatzerweiterungen oder sonstwie. Diese zusätzlichen Transistoren brauchen eben auch mehr Platz, sofern man dies nicht über die Fertigung kompensieren kann, weshalb die Rocket Lake CPUs mit den Cypress Cove Kernen, die eben die auf 14mm backported Sunny Cove Kerne sind, maximal 8 statt wie ihre Vorgänger 10 Kerne haben, denn die Architektur war eben für 10nm entwickelt worden und die Kerne sind in 14nm eben viel größer als die ihrer Vorgänger.
Ich mein wer Vektoren mit der CPU berechnen möchte/muss kauft dann halt Intel wenn das so toll ist.
Es bringt eben eine um Längen bessere Performance und obwohl eine GPU dies noch viel schneller könnte, ist die Latenz zu hoch um kleinere Aufgaben dort berechnen zu lassen. Da ist der Pferdefuß wenn es darum geht GPGPU zu betreiben und genau deshalb machen solche Befehlserweiterungen auch Sinn, mal ganz davon abgesehen, dass ein guter Compiler von sich auch die Programme auf AVX-512 optimieren kann (klar, bei weitem noch nicht so gut wie von Hand optimierter Code ist), aber um Berechnungen auf der GPU auszuführen, braucht man eben einen ganz anderen Befehlssatz und der Aufwand dies zu programmieren, ist ungleich höher. Programmieren, vor allem gute, sind aber chronisch knapp und gute Entwickler kosten richtig Geld, obendrein hat man dann sehr spezifische Hardwareanforderungen was für kommerzielle Software auch kein Vorteil ist, da man damit den potentiellen Markt verkleinert.
dank ResizeBar kann die CPU eh ohne Probleme direkt in den GPU RAM schreiben.
Dies kann man auch ohne ResizeBar, aber es dauert und man muss alle Daten übertragen, die Inputdaten zur GPU und die Ergebnisse zurück von der GPU, weshalb es sich eben nur lohnt, wenn man auch genug Berechnungen auf diesen Daten ausführt um diesen Zeitverlust zu kompensieren, wobei die Grenze natürlich von der jeweiligen Performance der CPU und GPU sowie der Anbindung der GPU abhängt. Was also trotz der Datenübertragungen auf einem System schneller auf der dGPU auszuführen wäre, ist es auf einem anderen System nicht, wie soll ein SW Entwickler da alle Fälle abdecken können?
