Die Diskussion über einen eventuellen MultiChip-Ansatz bei AMDs Navi-Architektur (oder später) gehen in unserem Forum weiter, wobei sich hier inzwischen zwei gewichtige Argumente herauskristallisiert haben: Erstens einmal kommt erneut das Problem der hierfür benötigten Interface-Bandbreiten zwischen den einzelnen Chips eines solchen MultiChip-Ansatzes zur Sprache. Dabei kann man sich nicht von den üblichen Werten zur Speicherbandbreite zum Grafikkartenspeicher leiten lassen, denn Chip-intern liegen vollkommen andere Bandbreiten zwischen Ausführungseinheiten und den verschiedenen Caches vor. All dies quer über ein Trägermaterial zum nächsten Chip zu verschicken, dürfte nicht ganz trivial werden. Die Erfahrungen aus dem CPU-Bereich hierzu sind auch nicht gänzlich zielführend, da in diesem Fall ja keine CPU-Kerne aufgetrennt werden, vielmehr jeder Kern Software-seitig abgetrennte Aufgaben zugewiesen bekommt und nicht direkt mit anderen CPU-Kernen an einer Aufgabe zusammenarbeiten muß. Man streitet sich im CPU-Bereich eher nur um geteilte Ressourcen wie Caches und Speicherbandbreite, arbeitet aber am Ende trotzdem immer an seiner eigenen, unteilbaren Aufgabe.

Im GPU-Bereich ist dies völlig anders organisiert, jede einzelne Aufgabe könnte potentiell Teile des kompletten Chipdesigns für sich in Anspruch nehmen – womit die Aufteilung des Chips in Einzelchips ergo enormen Datenströme zwischen diesen Einzelchips verursacht. Hierbei spielt nicht nur die technische Machbarkeit eine Rolle, sondern auch die Energieeffizienz: Interfaces zu außen liegenden Chips kosten nicht schlecht an Strom – und will man dies mehrfach und zu extrem hohen Bandbreiten machen, könnte ein solches Projekt allein am Stromverbrauch scheitern. Geht man hingegen davon aus, das diese Aufgabe gelöst werden kann, dann springt einem zum anderen unmittelbar die Eleganz eines solchen MultiChip-Ansatzes entgegen: Anstatt sich bei HighEnd-Lösungen wie bisher mit schlechter Fertigungsausbeute, Zwang zu hohen Taktraten und dementsprechendem Stromverbrauch herumzuschlagen, nimmt man in einem MultiChip-Ansatz einfach 3-4 der billig zu fertigenden Midrange/Mainstream-Lösungen daher – und erreicht dieselbe Performance zu vielleicht nicht einmal einer kleineren Chipfläche, aber mit wesentlich weniger Ärger. Weil Chipfläche dann letztlich kein Mangel mehr ist, kann man auch auf das maßlose Hochtakten verzichten, die Grafikchips notfalls auch auf einer eher stromeffizienten Taktrate laufen lassen.

Wie gesagt kann dabei auch ein höherer Silizium-Aufwand entstehen – welcher sich aber dadurch armortisert, das die Erstellung eines expliziten HighEnd-Designs samt der kostenspieligen Produktionsvorbereitung wegfällt und man nicht mehr das Problem der automatisch (durch die höhere Chipfläche) geringeren Fertigungsausbeute hat. Das einzelne Midrange- oder Mainstream-Design, welches man in einem MultiChip-Ansatz als Ausgangspunkt benutzt, erreicht hingegen durch die viel höheren Stückzahlen auch eine nochmals bessere Fertigungsausbeute, wird also günstiger als ein normaler Midrange- oder Mainstream-Grafikchip. Im Endeffekt hat AMD selbiges bereits mit den aktuellen Ryzen-, Threadripper- und Epyc-Prozessoren vorexerziert: Ausgangspunkt hierfür ist immer dasselbe Zeppelin-Die, nur eben in mehrfacher Ausfertigung je nach Bedarf. Damit kann man sich vollkommen auf die bestmögliche Fertigung eben dieses einzelnen Dies konzentrieren – und macht es auch eher Sinn, das ganze nach nur einem Jahr nochmals in der nur minimal besseren 12nm-Fertigung ("Pinnacle Ridge") neu aufzulegen. Ob und wann ein Grafikchip-Entwickler diesen MultiChip-Ansatz ins Grafikchip-Business übernimmt, bleibt allerdings weiterhin abzwarten.

Bei Gaming on Linux berichtet man über das Linux-Tweaktool "GameMode", welches seitens des für einige Spiele-Portierungen auf Linux bekannten Software-Entwicklers "Feral Interactive" zur Verfügung gestellt wird. Hierbei werden schlicht die Stromspar-Einstellungen des verwendeten Prozessors für die Spieldauer maximiert, was in geringem Maß der durchschnittlichen Framerate und in sehr bemerkbarem Maßstab den minimalen Frameraten zu Gute kommt. Speziell unter Linux erscheint dies als nützlich, da Linux ansonsten eher für den professionellen Einsatz optimiert ist, wo die Energieeffizienz durchaus eine gewichtige Rolle spielt und vor allem eine dauerhaft anliegende höchstmögliche Taktrate eher selten vorkommt. Das genannte Tweaktool wird in der Meldung primär mit den Spiele-Portierungen von Feral Interactive selber getestet, sollte jedoch eigentlich unter jedem Linux-Spiel funktionieren können und steht auf GitHub dem geneigten Linux-Gamer zum Download bereit.