RTX Spark: NVIDIA greift Intel und AMD bei den Notebook-CPUs an

Das ist richtig, aber das machen die Spark Dinger doch. Welche Bandbreite das nun hat, kein Plan, aber in Zukunft wird da wahrscheinlich noch mehr gehen.

Je nach Anwendung ist die Bandbreite noch gar nicht mal soooo kritisch.
Wird schon einen Platz finden, NV würde es sonst nicht machen, denke ich.

PS: Gut, der Titel der News ist vielleicht reisserisch gewählt, dass dieser "Angriff" so stattfindet oder gar glückt, halte ich für unwahrscheinlich.
Es wird ein paar Leute geben, die sowas wollen, die können es nun auch kaufen, für eine Hand voll Goldmünzen.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Alles andere hatten wir bisher ja auch schon, das die IGPU den Hauptspeicher genutzt hatte.
Das ist aber nicht das gleiche wie Unified Memory, denn die iGPUs haben einen eigenen Adressbereich, weshalb man ja auch im BIOS festlegen kann/muss wie viel RAM die iGPU bekommt. Die Daten werden dann zwar nicht über PCIe übertragen, müssen aber im RAM kopiert werden, damit die iGPU darauf zugreifen kann. Unified Memory hat AMD bei den letzten seiner APUs realisiert, dies war der ganze Sinn warum AMD damals auf die APUs gesetzt und diese auch APUs genannt hat, statt CPUs mit IGPU. Der Gedanke war eben, dass die GPU Kerne auch kleinere Aufgaben übernehmen können, die sich bei einer diskreten GPU wegen der Übertragung von Daten und Programmcode per PCIe nicht sinnvoll auf der GPU ausführen ließen. Aber mit Zen hat AMD das ganze Konzept dann wieder über Board geworfen und die paar Entwickler die sich darauf eingelassen haben, im Regen stehen lassen.

Keine Ahnung ob diese NVidia Chips wirklich echtes Unified Memory haben oder nicht, es ist mir auch egal, da ich so etwas niemals kaufen würde.
 
Unified Memory, NUMA etc. hat AMD mit Llano anno 2011 versprochen und die Konsolen sind seit einer Ewigkeit APUs. Unterm Strich ist quasi kaum was dabei raus gekommen und selbst die Physik macht wieder die CPU alleine.
 
Konnte schon jemand in Erfahrung bringen ob mit diesem Gerät auch eGPU Unterstützung in die Win11ARM Welt einziehen wird? Liegt ja irgendwie Nahe wenn Nvidia jetzt als neuer Inkubator fleißig mitmischt. Andererseits fallen mir auch zig Gründe ein warum Nvidia genau das unterbinden möchte 8-)
 
Das ist aber nicht das gleiche wie Unified Memory, denn die iGPUs haben einen eigenen Adressbereich, weshalb man ja auch im BIOS festlegen kann/muss wie viel RAM die iGPU bekommt. Die Daten werden dann zwar nicht über PCIe übertragen, müssen aber im RAM kopiert werden, damit die iGPU darauf zugreifen kann. Unified Memory hat AMD bei den letzten seiner APUs realisiert, dies war der ganze Sinn warum AMD damals auf die APUs gesetzt und diese auch APUs genannt hat, statt CPUs mit IGPU. Der Gedanke war eben, dass die GPU Kerne auch kleinere Aufgaben übernehmen können, die sich bei einer diskreten GPU wegen der Übertragung von Daten und Programmcode per PCIe nicht sinnvoll auf der GPU ausführen ließen. Aber mit Zen hat AMD das ganze Konzept dann wieder über Board geworfen und die paar Entwickler die sich darauf eingelassen haben, im Regen stehen lassen.

Keine Ahnung ob diese NVidia Chips wirklich echtes Unified Memory haben oder nicht, es ist mir auch egal, da ich so etwas niemals kaufen würde.
Die Idee der APU leuchtet mir grundsätzlich ein, je nach Rechenaufwand wird die Berechnung entweder auf die CPU geschoben oder auf die GPU und so könnte man diese entsprechend auslagern.
Das ist aber am ende wie bei einem Lieferdienst bei dem sich 2 Fahrer einen Transporter teilen. Wenn die Auftragsbücher explodieren reicht halt ein 1 Transporter nicht mehr für 2 Fahrer und jeder brauch einen eigenen. Wir haben das doch jetzt schon das Anwendungen Speicher vor-belegen. Das heißt grenzen für die Ressourcen Nutzung muss man im Endeffekt am ende trotzdem setzen.
Wäre ein Dual-Socket nicht sinnvoller mit jeweils einer GPU und CPU die sich einen Speicherbereich teilen?
 
Was willst du mit einem Dual Sockel? Das Zeug muss zwangsläufig auf einen Träger. Selbst die heutigen Klebechips sind nur ein Anfang. Das Zauberwort bei einer CPU ist Latenz, Latenz, Latenz und dann Cachegrößen Bandbreite etc. Bei GPUs kannst du die Latenz gut verstecken. Die Anforderungen sind einfach verschieden.

Ein wunderschönes Beispiel wie selbst planar limitiert erarbeitet gerade Intel mit dem bLLC gegenüber dem 3D Ansatz von AMD. Rechenwerke die warten arbeiten nicht.
Irgendwo stellt sich aber auch die Frage was du eigentlich beschleunigen willst. Software ist nicht Software.
 
 
Das sah ich gestern schon bei Gamers Nexus. Ich hoffe, dass der seine Ziele nicht erreicht und dass das Zeug wie Blei in den Regalen stehen oder liegen bleibt.
 
Unified Memory, NUMA etc. hat AMD mit Llano anno 2011 versprochen
NUMA ist was anderes, aber gebracht hat AMD das Unified Memory erst bei der letzten oder den beiden letzten APU Generationen vor Zen, wo also die GPU einfach auf das RAM der CPU zugreifen und eine Operation auf den Daten dort ausführen und die CPU dann weitermachen konnte, ohne irgendwas kopieren zu müssen. Damit war die GPU dann praktisch wie eine Befehlserweiterung für die CPU und genau dies war eben das Konzept hinter der ganzen APU Geschichte. Nur brauchte es eben auch entsprechend angepasst Software und bei der Unterstützung für die SW Entwickler war AMD auch nie stark, schon gar nicht wenn man es mit NVidias CUDA vergleicht.

Selbst die heutigen Klebechips sind nur ein Anfang. Das Zauberwort bei einer CPU ist Latenz, Latenz, Latenz und dann Cachegrößen Bandbreite etc.
Wenn du mit den Klebechips generell die Design auf Basis von Tiles meinst, so werden diese bleiben, schon weil die aktuellen Fertigungen nur noch recht kleine Diessizes erlauben, bei EUV sind es nur noch 26 mm * 33 mm und bei High-NA halbiert sich dies auf 26 mm * 16,5 mm, dann erhält man mit kleineren Dies eine größere Yield mit mehr Flexibilität. Entscheidend, auch für die Latenz, ist wie die Dies verbunden werden, also SERDES zu Sea Of Wires. SERDES bedeutet, dass man die Übertragungen seriell ausführt, ähnlich wie PCIe, was aber eben bedeutet, dass die Daten in Paketen übertragen werden und damit erhöht sich die Latenz gewaltig und ebenso die Leistungsaufnahme. AMDs IF ist ein Beispiel, aber deren Chiplets werden wie BGA Chips auf die Trägerplatine gelötet, was günstig ist, aber halt nicht so viele Verbindungen ermöglicht. Arrow Lake scheint auch SERDES zu verwenden, zumindest zwischen dem CPU Tile und dem SoC Tile, da man dort ja auch die Geschwindigkeit der Verbindung einstellen kann.

Sea Of Wires bedeutet, dass man die Signalleitungen über die Dies hinweg verbindet, was natürlich Halbleiterinterposer oder eben direktes Durchkontaktieren übereinander liegender Dies erfordert, wie es AMD bei dem 3D Cache machen dürfte. Die Latenz ist entsprechend gering, da es wie ein einzelnes Die Signallaufzeite müssen natürlich auch gleich sein, was bei parallelen Verbindungen mit steigenden Taktraten immer ein Problem war, weshalb man ja auch überall (z.B. PCI, PATA, SCSI) auf serielle Verbindungen umgestiegen ist. Keine Ahnung was Intel bei Clearwater Forest mit "Monolithic mesh coherent fabric" meint, aber vielleicht ist dies ja der Ansatz das Mesh mit Sea Of Wires von CPU Chiplet zum nächsten zu verbinden.

Intel Clearwater Forest Tiles.png

Da wird man sehen müssen, wer Sea Of Wires zuerst in den Desktop bringt, denn dies wird die Latenzen senken.
Ein wunderschönes Beispiel wie selbst planar limitiert erarbeitet gerade Intel mit dem bLLC gegenüber dem 3D Ansatz von AMD.
Wie willst du schon wissen ob diese sich unterschiedlich verhalten? Es sollte keinen Unterschied machen, ob der ganze Cache neben den Kernen liegt, oder wie bei AMDs X3D ein Drittel von ihm neben den Kernen und Zweidrittel dann über dem einen Drittel Cache sitzt. Bei Clearwater Forest sitzt übrigens der ganze L3 Cache (LLC) in den Base Chiplets. Neben der reinen Fertigung der Tiles, spielt eben auch das Packaging eine wichtige Rolle.
 
Unified RAM mit Beschleuniger ist doch geil für lokale KI-workloads. Bandbreite und rammenge sind geil. Die Apple Architektur hat es vorgemacht wie gut das laufen kann.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh