Die "Core"-Definition von CPUs (die ohnehin nicht ganz klar ist) lässt sich nur schwer auf GPUs übertragen. Am nahesten kommt die Sichtweise, dass jeder unabhängige shader-Prozessor ein eigenständiger Kern ist, demnach besitzen aktuelle GPUs bereits viele 100 Kerne. Da die Zahl der Sockel bei Multi-DIE-Systemen keinen großen Unterschied macht und die Zahl der Sockel bei Grafikkarten per Definition=0 ist, gibt es keine engere Integration mehrerer Chips auf einer Karte, als derzeit praktiziert wird.
Es wird zwar immer wieder von Plänen gesprochen, idealerweise nur noch einen Chip zu haben und die einzelnen Modelle alleine durch die Zahl der Chips zu trennen, aber in der Praxis scheitert das an der hohen Anzahl von sich gegeneinander beeinflussenden Elementen im Rendering-Prozess, die ein extrem hohes Datenaufkommen zwischen den einzelnen Recheneinheiten bedingen. Innerhalb eines Chips kein Problem, aber bekanntermaßen bereits zwischen zwei GPUs mit großen Nachteilen behaftet und bei vier GPUs eine mittelschwere Katastrophe, was die Skalierung angeht.
In nächster Zeit wird wohl keiner der Hersteller die Zahl der GPUs pro Karte steigern, sondern weiterhin an der Zahl der Einheiten pro Chip arbeiten.
Bezüglich Parallelisierung:
Ich denke, Havenger wollte andeuten, dass genau diese bis auf weiteres nur sehr eingeschränkt möglich ist und somit die Zahl der in Spielen nutzbaren Kerne stark einschränkt. Da interagiert das Problem der bereits oben genannten Kommunikation (sicher: Man könnte z.B. die Physik jedes Objektes von einem Kern berechnen lassen. Aber wie werden dann Kollisionen berücksichtigt?) als auch die Verwaltung eine Rolle. Denn im Gegensatz zu z.B. dem Rendering eines Bildes, das aus einzelnen Elementen besteht, die hinterher leicht zusammengefügt werden können, ist ein Spiel zwingend darauf angewiesen, dass alle Elemente der Spielwelt zu jeder Zeit zueinander passen.
Lasse ich die aber alle getrennt voneinander berechnen, muss ich sehr viel Rechenleistung aufbringen, um alle Berechnungen zu vereinigen und zu koordinieren.
Und diese Aufgabe kann ich wiederum nur schwer auf mehrere Kerne verteilen -> ich habe automatisch eine sehr hohe Last auf einem Kern, der dann eh alles limitiert.