Locuza
Lötkolbengott/-göttin
Dein hypothetischer Vorschlag mit dem gespiegelten L3$ im I/O-Die geht vermutlich davon aus, dass wenn andere Chiplets Remote-Memory-Access ausführen, dass etwas schneller geschehen würde, wenn der I/O-Die in einigen Fällen die nötigen Daten schon vorliegen hat?Was meinst du damit? Dynamisches Takten des IFs?
Bezogen auf so einen Fall meine ich das man lieber noch ein Stück weiter bis zum Chiplet geht und mehr in Bezug auf die Latenz und die elektrische Energie beim Transfer bezahlt, als konstant Energie zu investieren, um den L3$ von jedem Chiplet im I/O-die zu spiegeln.
Ja, da hast du Recht, ein größerer L3$ könnte einem die Kommunikation nicht ersparen.Wie soll das funktionieren, wenn Thread A auf CCX 0 die Daten erzeugt und an Thread B auf CCX 1 synchronisiert?
Zen1 war 213 mm² davon belegen die CCX selber nur 88mm² (2x 44mm²)Und dann noch eine Frage an dich. Wenn im I/O-Chip keinerlei Cache verbaut sein sollte, wie erklärst du dir die enorme Größe des Chips?
https://en.wikichip.org/w/images/th...px-amd_zen_octa-core_die_shot_(annotated).png
Zen - Microarchitectures - AMD - WikiChip
Ungefähr 16,9mm² für x32 PCIe/IFIS bzw. 67,6mm² für x128 Lanes.
Das Dual-Channel DDR4-Interface benötigt 16,2mm², als Octo-Channel 64,78mm².
Rein für diesen I/O Abschnitt benötigt man insgesamt 132,4mm².
Der Flächenverbrauch wird natürlich wegen PCIe4.0 schon ansteigen müssen, dass DDR4-Interface könnte ein wenig wachsen, ebenso kommen die IFOPs hinzu, neben weiteren I/O wie USB und der ganzen Kontrolllogik, wo man sich leicht eine Größe über 250mm² vorstellen kann, aber der I/O-Chip liegt bei über 400mm², da kann man sich schon Gedanken machen, ob AMD da zusätzlich große Puffer verbaut.
Aber die Cache-Größe und Politik müsste natürlich sinnvoll sein, dass Konzept von ständigen und gleichgroßen L3$-Kopien im I/O-Chip ergibt für mich wenig Sinn und nicht allgemein zusätzlicher Cache.