Erste direkte Aussage finde ich bei Toms Hardware's entsprechendem Artikel. Da sagt AMD, dass auch der non L3 Cache Chiplet mit dem Cache sprechen kann, aber das ist natürlich nicht optimal und sollte vermieden werden.
Da bin ich ja mal gespannt, AMD hat ja immer wieder gerne Ärger mit Windows (gehabt) und das hier klingt nach so nem weiteren Punkt für Probleme. Natürlich arbeiten sie mit MS daran, dass der scheduler zusammen dem Chipsatz Treiber anhand des Spiels erkennen soll, ob mehr Cache oder mehr Takt bevorzugt wird und das entsprechende CCD dann belegt wird. Bleibt abzuwarten, wie salonfähig das bereits zu Release sein wird...
Selbstredend ist der Cache shared, jedoch interessiert das latenzkritische Anwendungen nicht. Die werden den 12- und 16-Kerner als CPUs mit 32 MB L3$ ansteuern, weil Zugriffe auf den anderen CCD mit um ein Vielfaches erhöhten Latenzen einhergehen. Das bringt Anwendungen schnell ins Stocken. AMD bemüht sich ja nicht umsonst explizit um Scheduler-Anpassungen in Windows, damit das OS zwischen den Kernen unterscheidet. In manchen Anwendungen wird die Unterscheidung irrelevant sein (so beim Rendering, hier dürfte eher der niedrigere Takt zu einem Malus führen), bei latenzkritischen Anwndungen, wozu i. d. R. auch das Gaming gehört, wird man es dagegen vermeiden über einen CCD hinweg Cache zu adressieren.
Entsprechend hat AMD jetzt auch schon ohne explizite E-Cores ein ähnliches Setup wie Intel, d. h. der OS-Scheduler muss explizit zwischen den Kernen unterscheiden können und die Threads bestmöglich zuordnen. Die kritischen kommen auf den CCD mit dem V-Cache drauf, alles andere kann auf den zweiten CCD mit den 32-MB-onDie-L3$. *) Die Unterscheidung ist schlicht notwendig, weil in Abhängigkeit des konkreten Workloads die Kerne einen signifikant voneinander abweichenden Durchsatz aufweisen können.
*) Wobei die Betrachtung auch noch arg vereinfachend ist, denn kritisch kann bedeuten, dass sehr viele Speicherressourcen benötigt werden, kritisch kann aber auch bedeuten, dass ein Thread vorwiegend eine hohe Rechenlast hat, jedoch auf vergleichsweise wenigen Ressourcen arbeitet, d. h. ein höherer Takt könnte hier vorteilhafter sein, sodass ggf. eher der CCD ohne V-Cache zu bevorzugen wäre.
Im Endeffekt haben Intel und Microsoft hier schon viel Vorarbeit geleitet, da man an den Hybrid-Designs schon länger dransitzt und bspw. sieht man für die SW auch vor, dass neuere SW seine Threads mit speziellen Flags versieht, die ausweisen, in welcher Art der Entwickler diese zu nutzen gedenkt, sodass der Scheduler eine bessere Verteilung vornehmen kann.
Intel hat mit dem ThreadDirector und dem Hardware Guided Scheduling zudem hier gar Hardware-Einheiten implementiert, die dem OS Echtzeitinformationen der Prozesse zur Verfügung stellen und unterstützen (natürlich auch, um den migrationstechnischen Übergang von Alt- auf Neu-SW zu optimieren). Was AMD sich hier überlegt hat, wird man abwarten müssen, sprich wie weit Microsoft das ganze rein softwarebasiert bestmöglich verteilen kann, da bisher nichts von unterstützenden HW-Maßnahmen im Ryzen bekannt ist.