AMD Ryzen Threadripper & Epyc: Multi-Die-Strategie spart viel Geld

[BigYundol]

AW: AMD Ryzen Threadripper & Epyc: Multi-Die-Strategie spart viel Geld

Ich bin ja immer noch gespannt, ob das ganze "Skalierbarkeit" bei Navii nicht völlig falsch verstanden wurde und es doch nur wieder eine Architektur mit 2000 bis 6000 Shader pro Chip sein wird

Ich spekuliere ebenfalls darauf, dass es eher darum geht, die Architektur generell so umzugestalten, dass sie bei grossen Chips in gewissen Anwendungsfällen (wie Gaming) nicht mehr so derbe aus dem Gleichgewicht gerät wie noch bei Fiji und Vega beobachtet. Sondern von klein bis gross ein ausgeglicheneres Bild abgeben soll.

Wer weiss, womöglich kann sich Navi dank den programmierbaren Primitiv Shadern u.ä. die verschiedenen Ressourcen dynamisch an die anliegenden Anforderungen anpassen
Also bei FHD bsw. würde evtl. der Pixeldurchsatz verkleinert und mehr Ressourcen den Dreiecksschubsern zugeteilt, bei UHD umgekehrt. [/Spekulatius]

 

[chiquita]

AW: AMD Ryzen Threadripper & Epyc: Multi-Die-Strategie spart viel Geld

Achso... genau wie Threadripper sich als ein Die darstellt? Dann ist die ganze Anpassung in den Betriebssystemen die ryzenoptimiert sind damit multitask Dinge auf möglichst dem gleichen CCX laufen wohl alles Quatsch.
Woher willst du wissen was sich wie darstellt bei einem Produkt das es gar nicht gibt?
.

Liegt wohl eher daran, dass die letzte AMD Architektur vor 5 Jahren rausgekommen ist und diese Architektur komplett neu nun komplett neu ist und noch keinerlei Implementierungen seitens Windows zu dem Zeitpunkt vorlagen ?

Somit musste man von Seiten AMD nur anpassen, dass die Kerne die grad zusammenarbeiten auch auf demselben CCX liegen um die Kommunikations Latenz im Falle von zwei Kernen auf zwei CCX einzusparen.

Seitdem läuft doch alles Paletti oder nicht ? und in MT Szenarien mit maximaler Last auf allen Kernen ist doch die Performance ziemlich gut für eine geklebte Lösung.


Warum sollte das nun mit Grafikkarten bzw. MCM Lösungen nicht funktionieren ?

Wenn die IF schnell genug Kommunizieren kann oder sich mehrere Dies auch an mehrere HBM Module angebunden befinden und dazu viele oder alle Shader gleichmäßig ausgelastet werden, dann sollte die Leistung doch ziemlich linear mit skalieren.

Alternativ, könnte man auch jeden MCM Cluster an einem Quadranten des Frames arbeiten lassen und somit eine SFR Lösung zu forcieren, welche unabhängig von der API ist, das Spiel würde immer noch denken, dass es über AFR befeuert wird. Obwohl in Wirklichkeit der Quadrant die Leistung angibt, bei dem der nächste Frame zuletzt fertiggestellt wurde.

Also genug Ansätze um MCM vernünftig zu realisieren sollte es sicher geben, TR hat es schließlich gezeigt.

 

[Locuza]

AW: AMD Ryzen Threadripper & Epyc: Multi-Die-Strategie spart viel Geld

Hoffentlich kriegen die das bei GPUs auch vernünftig hin

Vega 64 in 7nm sollte so um die 160mm² groß sein ... davon 4 "zusammenlöten" und man hätte n 16000 Shader Monster

GloFo nennt einen Faktor von 2 bezüglich der SRAM- und Logik-Skalierung, jedenfalls auf dem Papier, in der Praxis war die Integrationsdichte im Vergleich zu den angekündigten Marketingwerten meist ein Stück darunter.
Also selbst mit Faktor 2 wäre Vega 10 noch ~242mm² groß.

Das sollte ja der Vorteil sein. ICh denke ja auch dass sich MRs stark verringern werden aber ob es sich wirklich wie eine GPU verhält bzw. "anfühlt"... da muss schon noch weitaus mehr passieren.
NV hatte es ja mit der High-Bandwith-Bridge versucht und auch etwas verbessert, dies auf einem Interposer können da sicher nochwas drauflegen aber gleich vier GPUs halte ich für harten Stoff. Ich wäre schon begeistert wenn sies mit zwei GPUs ordentlich hinbiegen könnten.

Bei CPUs ists glücklicherweise weniger problematisch.

Die GPUs sind ähnlich wie die CPUs mit ihren Kernen bzw. Einheitenmodulen in unterschiedliche Logikblöcke aufgetrennt und werden durch starke Verbindungen synchronisiert.
Eine neumodische MCM-GPU würde natürlich versuchen die Logikblöcke nicht auf einem die zu haben, sondern auf einem Package mit einem entsprechend schnellen Fabric zu verbinden.

NVIDIA Future GPUs To Feature Multiple Chips on the Same Package

Das wäre natürlich nicht so eine stupide Minimallösung, wie die HBB von Nvidia, wo es nur darum geht zwei GPUs genug Bandbreite zur Verfügung zu stellen, damit immerhin genug Bandbreite für einen 5K Framebuffer zur Verfügung steht.

Ich bin ja immer noch gespannt, ob das ganze "Skalierbarkeit" bei Navii nicht völlig falsch verstanden wurde und es doch nur wieder eine Architektur mit 2000 bis 6000 Shader pro Chip sein wird

Es ist eben nur ein Stichwort und bisher spuckt auch die Gerüchteküche nichts genaues aus, entsprechend ist es nur geraten, ob Navi schon so ein Konzept umsetzen wird.

 

[Poor_Volta]

AW: AMD Ryzen Threadripper & Epyc: Multi-Die-Strategie spart viel Geld

aber gleich vier GPUs halte ich für harten Stoff.

Ich gehe für die ersten MCM-GPUs auch nur von 2 Dice aus.
Bei GPUs ist die maximal wirtschaftliche Chipgröße höher als bei CPUs, weil es da viel mehr Redundanzen gibt.

Eine 400-500mm² GPU in 7nm kommt sicher teurer, als ein MCM aus 2 GPUs.
Es sidn ja nicht nur die Fertigungskosten, schon die Entwicklung der einzelnen Chips frisst einige Millionen Dollar.

Intels nächstes Prozessor-Design wird ähnlich dem Design von AMD sein

Was genau meinst du damit?

 

[Incredible Alk]

AW: AMD Ryzen Threadripper & Epyc: Multi-Die-Strategie spart viel Geld

Warum sollte das nun mit Grafikkarten bzw. MCM Lösungen nicht funktionieren ?

Im Wesentlichen deswegen, weil die Datenmengen und Latenzen die zum Eliminieren von Mikrorucklern nötig wären selbst für Verbindungen auf einem MCM wie dem InfinityFabric viel zu groß sind.

Bei CPUs funktioniert das, weil die allerallermeisten Dinge innerhalb eines arbeitenden Kerns und dessen Cache ablaufen können und nur hin und wieder mal Daten zwischen Dies einer TR/EPYC-CPU getauscht werden müssen - und es hier oft nicht auf ein paar Mikrosekunden ankommt da andere Aufgaben unabhängig davon parallel weiterlaufen können. Und selbst das erzeugt bereits zig GB/s Traffic auf dem MCM.

Bei GPUs wäre das ein zigfaches davon, da hier zig Shader an der gleichen Aufgabe arbeiten können. Eine Latenz von 500ns mehr ist hier vernichtend da alle anderen so lange nichts tun können und alle Shadereinheiten müssen (übertrieben gesagt) gleichzeitig Zugriff auf alle Daten haben. Ein Infinity Fabric müsste hier viele TB/s schaffen und Latenzen im Nanosekundenbereich haben damit das sinnvoll funktioniert - und da sind wir weit davon entfernt.

Damit sowas funktionieren kann müsste man GPU-Teile sehr geschickt anordnen/verbinden (wie Locuza schon sagt) und da steckt extrem viel R&D-Aufwand dahiner. So "einfach" wie bei CPUs ist das hier bei weitem nicht.

 

[PCGH_Torsten]

AW: AMD Ryzen Threadripper & Epyc: Multi-Die-Strategie spart viel Geld

Hoffentlich kriegen die das bei GPUs auch vernünftig hin

Vega 64 in 7nm sollte so um die 160mm² groß sein ... davon 4 "zusammenlöten" und man hätte n 16000 Shader Monster

Threadripper und Epyc brillieren vor allem, wenn den Kernen voneinander unabhängige Aufgabenstellungen zugewiesen werden. Das ist bei einer GPU, die einen zusammenhängenden Frame liefern soll, naturgemäß schwierig. Alle jüngeren Versuche, die Rechenarbeit parallel auf mehreren Chips abzuwickeln, scheiterten an den hohen Datentransferraten, die zwischen diesen erforderlich wären. Möglich, dass AMD mit einem deutlich nach oben skalierten Infinity Fabric eine ausreichend performante Lösung konstruieren könnte, hier müssen Nutzen und Aufwand dann aber neu abgewogen werden: Wenn man eine Grafikkarte der Radeon-690-Klasse beispielsweise auf vier Radeon-660-Chips zusammenfügen kann, diese aber durch die nötigen Schaltungen um 30 Prozent größer werden und zu dem in allen Preisklassen dann der gleiche (teure HBM-)Speicher genutzt werden muss, dann kann das technisch mögliche unrentabel werden. Definitiv der Fall wäre das bei einem weiter skalierbaren High-End-Chip. Schon Vega 64 ist weit oberhalb der umsatzstarken Marktmitte platziert. Die GPU aufwendig zu erweitern, um ein weiteres Angebot im 2.000-Euro-Segment platzieren zu können, dass dann quasi niemand kauft, dürfte sich kaum lohnen.

Intels nächstes Prozessor-Design wird ähnlich dem Design von AMD sein. Einfach aufgrund der Kostenersparnis bei R&D und der Fertigung. So und nicht anders.

Die Kostenersparnis ist von den Stückzahlen abhängig. Intel fertigt weitaus mehr CPUs als AMD und betreibt eine Vielzahl an Fertigungsstraßen. Hier werden ohnehin zusätzliche Belichtungsmasken benötigt und der Entwicklungsaufwand für verschiedene Kernzahlen hält sich bei den modularen Designs in Grenzen.

 

[chiquita]

AW: AMD Ryzen Threadripper & Epyc: Multi-Die-Strategie spart viel Geld

Im Wesentlichen deswegen, weil die Datenmengen und Latenzen die zum Eliminieren von Mikrorucklern nötig wären selbst für Verbindungen auf einem MCM wie dem InfinityFabric viel zu groß sind.

Aber Mikroruckler gibt es doch nur, weil die GPUs im Crossfire oder SLI unterschiedlich lange für einen Frame benötigen.

Schließlich funktioniert das ja bei mGPU Konfigurationen mehr oder weniger. Dort liegt ja auch alles auf dem Speicher jeder GPU doppelt vor.
Warum sollte das also nicht mit einem 4er GPU Cluster funktionieren, der sich mal 4 Hypothetische HBM Stacks teilt.

Deswegen habe ich ja auch SFR vorgeschlagen, AFR würde hier schließlich einen immensen Lag bringen und wäre wahrscheinlich überhaupt nicht umsetzbar in dem Szenario.
Aber mit SFR ist ja selbst bei SLI oder CF der anderen GPU egal was die andere GPU treibt macht, jede GPU berechnet ihren Teil des Bildes und wird dargestellt, sobald die GPU mit dem aufwendigeren Teil des Bildes auch fertig ist.

Das zB. auf 4K übetragen und in 4 Cluster á 1080p unterteilt bei 4 Chips auf dem MCM mit jeweils einem HBM Chip pro Grafikcluster und man sollte das einigermaßen gut skalieren lassen können.

Wenn der Gedanke hinter dem SFR vernünftig implementiert wird wäre das machbar.

Vorausgesetzt dass ein Grafikcluster+ HBM sich in Full HD gut auslasten lässt um die Performance vernünftig hochskalieren lassen zu können.

BTW: Das Konzept der IF und das verbinden der Chips scheint doch erst jetzt interessant zu sein, ebenso ist das Nvidia Pendant NVlink auch erst seit ~ einem Jahr bekannt.
Warum sich also solche MCM Designs schon früher hätten ergeben können ist mir also ein Rätsel

 

[amdahl]

AW: AMD Ryzen Threadripper & Epyc: Multi-Die-Strategie spart viel Geld

Möglich, dass AMD mit einem deutlich nach oben skalierten Infinity Fabric eine ausreichend performante Lösung konstruieren könnte,

Dabei sollte man aber nicht den Stromverbrauch außer Acht lassen. Ich weiß es nicht mehr genau auswendig, aber bei einem Epyc verbrauchen die Transfers über IF deutlich im zweistelligen Wattbereich.
Wenn man das jetzt mal um eine oder zwei Größenordnungen nach oben skaliert um für GPUs ausreichende Transferraten zu erreichen steht man vor einem ernsten Problem mit erhöhter Leistungsaufnahme.

 

[Atent123]

AW: AMD Ryzen Threadripper & Epyc: Multi-Die-Strategie spart viel Geld

Wenn das so einfach wäre mit den mehreren GPUs hätte sich das viel früher durchgesetzt aber trotz vieler Bemühungen auf beiden Seiten ist SLI/Crossfire nie wirklich über eine bessere Machbarkeitsstudie rausgekommen. Ich würde mich ja freuen wenn AMD ein mGPU-Design gut hinbekommen würde aber ich glaube an sowas erst wenn ichs sehe (egal jetzt wers versucht...).

Bisher gab es allerdings auch keine Verbindung mit derart niedrigen Latenzen.
Crossfire wird wohl nicht an um die 75 ns (135 ns zwischen den DIEs) rankommen.
Ob das allerdings schon für Mikrorucklerfreie Verbindung von GPUs reicht ist wohl die andere Frage.

@amdahl

"Dabei sollte man aber nicht den Stromverbrauch außer Acht lassen. Ich weiß es nicht mehr genau auswendig, aber bei einem Epyc verbrauchen die Transfers über IF deutlich im zweistelligen Wattbereich."
Hast du dazu eine Quelle ?

 

[Incredible Alk]

AW: AMD Ryzen Threadripper & Epyc: Multi-Die-Strategie spart viel Geld

Deswegen habe ich ja auch SFR vorgeschlagen, AFR würde hier schließlich einen immensen Lag bringen und wäre wahrscheinlich überhaupt nicht umsetzbar in dem Szenario.
Aber mit SFR ist ja selbst bei SLI oder CF der anderen GPU egal was die andere GPU treibt macht, jede GPU berechnet ihren Teil des Bildes und wird dargestellt, sobald die GPU mit dem aufwendigeren Teil des Bildes auch fertig ist.

Stimmt alles. SFR und auch TBR (TileBased) haben die Mikroruckelproblematik nicht und es gibt glaube ich auch ganz vereinzelt Spiele die das unter DX12 zulassen, die Karten können das ja.

Aber es implementiert fast niemand und keiner wills nutzen, aus einem einfachen Grund: Bei AFR sind zwei Karten wenns gut läuft 50-80% schneller als eine einzelne. Bei SFR/TBR sinds wenns gut läuft noch 30-40%.

Anders gesagt: Wenn du 4 GPUs per SFR zusammenarbeiten lässt sind die nur vielleicht doppelt so schnell wie eine einzelne GPU weil die Skalierung dieser Rendertechniken einfach für den Allerwertesten ist. Und aktuell (und leider wohl auch in Zukunft) brüsten sich GPU-Hersteller, Spieleentwickler und so weiter eben lieber mit einem längeren fps-Balken im Benchmark als mit einem kurzen balken mit "mikroruckelfrei"-Aufschrift mit der 99% der Kunden nix anfangen kann.

 

[hanfi104]

AW: AMD Ryzen Threadripper & Epyc: Multi-Die-Strategie spart viel Geld

Ich bin mir sicher, dass wir in wenigen Jahren nach dem Ende der Shrinks plötzlich eine Explosion an neuen techniken in der MCM Technologie haben und davon werden sich dann 1 - 2 durchsetzen, Not macht bekanntlich erfinderisch.

 

[yummycandy]

AW: AMD Ryzen Threadripper & Epyc: Multi-Die-Strategie spart viel Geld

Derzeit skaliert die IF bis zu 512GB/s und VEGA ist schon innerhalb des Chips an mehreren Stellen per IF verbunden. Ich hab das immer als Vorarbeit für alles kommende verstanden. Abgesehen davon, arbeitet die IF innerhalb von VEGA auf Mesh-Basis, was sicherlich die benötigten Transferraten auf einigen Lanes verringern würde. Die Problematik der Latenzen bleibt sicherlich. Eine Aufteilung nach Pipelines, mitsamt ROPs und TMUs fände ich ziemlich interessant, auch wenn es dann einen gemeinsamen L2 Cache geben müsste, wie eben auch schon bei VEGA intern. Aber gut, bin auch kein Chipdesigner.


https://i.imgur.com/jsRXHIG.png
http://radeon.com/_downloads/vega-whitepaper-11.6.17.pdf

 

[Pu244]

AW: AMD Ryzen Threadripper & Epyc: Multi-Die-Strategie spart viel Geld

Im Prinzip sind TR und Epyc 2 und 4 Sockelsysteme, die man in ein Package gequetscht hat, mit allen Vor- und Nachteilen, die das so mit sich bringt. Die Frage ist, ob Intel genauso kontert, die könnten dann, aus dem Stand, 36 und 72 Kern CPUs bringen. Das ganze wollte Intel schonmal zu Zeiten des Core2Duo, unter dem Namen Skulltrail (allerdings mit zwei Packages, was Vorteile hat), einführen, leider ist es nie dazu gekommen.

Warum sollte das nun mit Grafikkarten bzw. MCM Lösungen nicht funktionieren ?

Weil sie nun seit gut 15 Jahren an dem Problem herumdoktern und bisher keine vernünftige Lösung gefunden haben. Als das Problem vor 13 Jahren dann von der Öffentlichkeit erkannt wurde, hat man baldige Abhilfe versprochen, getan hat sich seither eher wenig. Wenn sie SFR mal endlich in den Griff bekommen, dann wäre es der Heilige Gral, damit würde ein Multi GPU System endlich das halten, was damals versprochen würde. Nach gut 13 Jahren warten bin ich eher wenig optimistisch, dass sie es bald hinbekommen, ich lasse mich aber gerne vom Gegenteil überzeugen.

Wenn Navi wirklich so erscheint, wie einige hier spekulieren, dann haben sie die ultimative Möglichkeit auch den 3. High End Chip zu verpfuschen (gut, vorher hat HBM einen gewissen Teil beigetragen). Poor Volta, er wird auch dann keinen Spielkameraden bekommen.

 

[RawMangoJuli]

AW: AMD Ryzen Threadripper & Epyc: Multi-Die-Strategie spart viel Geld

GloFo nennt einen Faktor von 2 bezüglich der SRAM- und Logik-Skalierung, jedenfalls auf dem Papier, in der Praxis war die Integrationsdichte im Vergleich zu den angekündigten Marketingwerten meist ein Stück darunter.
Also selbst mit Faktor 2 wäre Vega 10 noch ~242mm² groß.

von 14nm auf 7nm?

hast du dazu mal n Link ... das kommt mir so wenig vor ^^

TSMC nennt von 16nm auf 10nm 2x Packdicht und von 10nm auf 7nm 1,6x Packdichte

das wären dann 3,2x Packdichte von 16nm auf 7nm


Samsung 7nm soll ja wohl sogar noch besser sein als der von TSMC


Edit: wie akkurat is eig semiwiki?

das steht 123,7 Milliarden Transen/mm² (7nm) vs 32,5 Milliarden Transen/mm² (14nm)

also 3,8x Packdichte xD

https://www.semiwiki.com/forum/content/6713-14nm-16nm-10nm-7nm-what-we-know-now.html

 

[Gast1705317003]

AW: AMD Ryzen Threadripper & Epyc: Multi-Die-Strategie spart viel Geld

Wie auch immer AMD das am Ende zusammen schustern wird auf die kommenden CPU Generationen.
Hauptsache es werden alle davon profitieren was die Kosten der Herstellung angeht aber auch dem erwerb,hoffe ich.

grüße Brex

 

[Kaby-Lame]

AW: AMD Ryzen Threadripper & Epyc: Multi-Die-Strategie spart viel Geld

Ich bin mir sicher, dass wir in wenigen Jahren nach dem Ende der Shrinks plötzlich eine Explosion an neuen techniken in der MCM Technologie haben und davon werden sich dann 1 - 2 durchsetzen, Not macht bekanntlich erfinderisch.

Nach dem Ende des klassischen Siliziums werden neue Materialien Einzug halten. Kohlenstoffnanoröhren sind ein heißer Kandidat: TREND Transistoren: Kohlenstoff schlagt erstmals Silizium - electronica Blog
Eine spannende Zeit liegt vor uns

 

[chiquita]

AW: AMD Ryzen Threadripper & Epyc: Multi-Die-Strategie spart viel Geld

Weil sie nun seit gut 15 Jahren an dem Problem herumdoktern und bisher keine vernünftige Lösung gefunden haben. Als das Problem vor 13 Jahren dann von der Öffentlichkeit erkannt wurde, hat man baldige Abhilfe versprochen, getan hat sich seither eher wenig. Wenn sie SFR mal endlich in den Griff bekommen, dann wäre es der Heilige Gral, damit würde ein Multi GPU System endlich das halten, was damals versprochen würde. Nach gut 13 Jahren warten bin ich eher wenig optimistisch, dass sie es bald hinbekommen, ich lasse mich aber gerne vom Gegenteil überzeugen.

In den letzten 15 Jahren wollte sich aber auch keiner mit einer MCM Lösung auseinandersetzen, das einzige was man ausprobiert hat waren eben jene Lösungen von AMD und Nvidia, dann halt noch 3DFX, aber was aus letzteren wurde wissen wir ja

Das waren alles Multi Package Lösungen auf einer Platine (3DFX/ GX2 7950 etc. ) oder mehrere Platinen ( SLI/CF) und keine Multi Die Lösungen auf einem Package.
Rein von der Latenz kann man sich auch bessere Resultate vorstellen, wenn 4 Chips auf einem Package verlötet sind und über die Infinty Fabric via Mesh von jedem Chip ein halbes TB/s an Bandbreite zur Verfügung gestellt wird zudem werden sich alle Chips mit Sicherheit den Speicher teilen, der mit ziemlicher Sicherheit mit seiner Bandbreite auch zur Kommunikation zwischen den Chips beitragen kann um Latenz einzusparen.

dh. in den letzen 15 Jahren haben wir nur halbgare Lösungen á SLI und CF gehabt die im best Case die Durchschnittsbilder angehoben haben um den Balken zu verlängern aber im Real Szenario viel mehr FPS Aufgrund der MR für dasselbe Erlebnis wie bei sGPU nötig waren.
Zumal man bisher auch immer wieder mal Shrinks auf den Markt geworfen hat und eine neue Architektur vorgestellt hat, war bisher das Konzept der MCM umgänglich. Da man ja die Leistung bisher auch auf Konventionellem Weg steigern konnte. SLI und CF waren nur dazu da um die Balken noch mehr zu verlängern
Abgesehen davon dass die Entwickler auch keinen Bock haben, auf Crossfire oder SLI zu optimieren.
Nvidia bietet schließlich nur noch 2 Way SLI an und bei DX 12 liegt der mGPU Shit komplett beim Entwickler...
dh. tradtionelle mGPUs sind tot, da Entwickler sicher keine Optimierungen für einen Nischenmarkt einpflegen.
Somit bleibt als einzige Option die jemals fruchten könnte ein MCM Chipdesign, welches von den Spiele-Engines, als eine GPU erkannt und auch so befeuert wird.



Das einzige mal dass es bisher MCM Lösungen auf dem Konsumer Markt gab, war der Pentium D und die Core 2 Quad Reihe von Intel.

Seitdem ist diese Idee gestorben und wurde nun nach ~10 Jahren das erste mal wieder mit Epyc und TR implementiert.
dh. auch wiederum dass die letzten 10 Jahre kein MCM Produkt seinen Weg auf den Markt gefunden hat, geschweige den die Option für den Grafikmarkt wurde wahrscheinlich bisher noch nie abgewogen.

 

[sterreich]

AW: AMD Ryzen Threadripper & Epyc: Multi-Die-Strategie spart viel Geld

...und Mikroruckler aus der Hölle.

Wenn das so einfach wäre mit den mehreren GPUs hätte sich das viel früher durchgesetzt aber trotz vieler Bemühungen auf beiden Seiten ist SLI/Crossfire nie wirklich über eine bessere Machbarkeitsstudie rausgekommen. Ich würde mich ja freuen wenn AMD ein mGPU-Design gut hinbekommen würde aber ich glaube an sowas erst wenn ichs sehe (egal jetzt wers versucht...).

Nach aktuellem Stand wäre eine Grafikkarte mit 4 GPUs auf einem Interposer nur eines: Eine Miningmaschine.

Einfach ist es sicher nicht, aber das Hauptproblem ist ja, dass bei SLI und Crossfire die Karten als zwei Instanzen für die CPU auftreten. Zumindest beim Alternate Flame Rendering das für SLI/CF genutzt wird. Die CPU taktet schneller und liefert die Daten für das zu Berechnende an GPU 2 während GPU1 noch beschäftigt ist. Nun wird GPU1 wie eine normale Karte fertig und GPU2 nur einen CPU-Cycle später. Der einzige wirkliche Vorteil hier ist, dass es softwaremäßig keine Herausforderung ist.

Das könnte man theoretisch mit der Anzahl der GPUs oder Module verbessern. Bei 2 Modulen wäre wieder die selbe Situation wie bei normalen SLI/CF und wird exponentiell besser. Ab einer gewissen Zahl ist das erste Modul fertig, wenn die CPU gerade erst einen Auftrag an das letzte Modul sendet. Hier müsste man den Mittelweg zwischen Rechenkraft der einzelnen Module und Anzahl finden.

Da man bei einem MCM allerdings nur eine Pipeline hat könnte man auch besser parallelisieren und Split Frame Rendering (gibt's ja seit DX12) betreiben. Der Nachteil von SFR ist ja der Kommunikationsoverhead. Alleine mit dem IF dürfte die Kommunikation deutlich schneller ausfallen als mit PCIE (+SLI-Bridge). Zusätzlich kann man bei MCM-Designs hardwaretechnisch nachhelfen. Eventuell mit einem eigenen Chip nur für die Arbeitsverteilung an die Module. Selbst ohne so einen "Scheduler" kann man die Verteilung eher im Treiber als in der Anwendung stattfinden lassen, wodurch ein generell besserer Optimierungsgrad zustande kommen dürfte.

Zusammen mit Freesync/G-Sync gehört MCM-GPUs mMn auf jeden Fall die Zukunft.

Als Besitzer zweier solcher CPUs kann ich euch sagen: es ist nicht ganz so friedefreudeeierkuchen wie es hier dargestellt wird. Von wegen bei CPUs unproblematisch.
Ein Nachteil ist zum Beispiel dass die Performance gnadenlos einbricht wenn ein Thread mehr RAM benötigt als ein die direkt angebunden hat. Daran können auch Optimierungen am Betriebssystem nichts ändern, es ist eine generelle Einschränkung so einer Architektur.

Auf das wär ich jetzt gar nicht gekommen, klingt aber logisch.
Wobei man hier wohl noch begrenzt mit der Größe der RAM-Module gegensteuern könnte. Ist natürlich eine Preissache. Ich maße mir mal an und sage, dass das eher eine Ausnahmeerscheinung ist und sich das bei dir nicht rechnen würde. Wie oft kommt es vor, das der RAM eines Moduls nicht ausreicht?

 

[amdahl]

AW: AMD Ryzen Threadripper & Epyc: Multi-Die-Strategie spart viel Geld

Schwierig das pauschal zu sagen, der Regelfall ist es natürlich nicht dass ich nur einen Kern nutze. Aber es kommt schon regelmäßig vor, während der Entwicklung noch häufiger als dann später im Einsatz.
Man kann natürlich gegensteuern mit größeren DIMMs, aber bei insgesamt 8 dies würde das bedeuten deutlich mehr Speicher zu kaufen als jemals benötigt wird. Und ab 64GB aufwärts pro die müsste man sogar auf LRDIMM ausweichen was die Performance wieder ein wenig drückt. Für eine gangbare Lösung des Problems halte ich es jedenfalls nicht. Wenn ich mehr Geld auf das Problem werfen will kann ich ja gleich Intel kaufen

 

[Cross-Flow]

AW: AMD Ryzen Threadripper & Epyc: Multi-Die-Strategie spart viel Geld

Skulltrail war nichts anderes als ein 2P LGA771 Mainboard ( zusammen mit Workstations Chipsatz ) zu nehmen und da drauf 2 LGA 771 Xeons zu setzen welche halt einen Desktop tauglichen Namen bekommen haben. Skulltrail hat ansich nichts mit MCM zu tun.

Die ganze Situation mit dem Core 2 Duo / Core 2 Quad zu vergleichen ist aber auch nicht richtig. Das "Problem" dieser war die Kommunikation untereinander sowie der nicht vorhandene IMC ( MC war ja noch in der Northbridge bei LGA775 / 771 LGA whatever ).

AMDs HT ( welches wir ja heute noch in veränderter Form haben ) hatte diese Probleme in diesem Ausmaß nicht da genug Bandbreite zur Verfügung stand. Auf AM3+ hätte selbst ein PCI-E 3.X Controller im Chipsatz für MultiGPU ( 2 x x16 ) mit HT version 3.X mehr als genug Bandbreite gehabt.

Ryzen hat mal gar nicht mit diesem "alten" MCM Ansatz zu tun - einfach aus dem Grund das Bandbreite in hülle und fülle vorhanden ist. Aktuelle MCM Modelle leiten unter der schlechten Latenz ( Skylake 45ns vs. Ryzen 70+ ns siehe AIDA Chache Benchmark ).

Die Latenz hat aber per se nichts mit MCM zu tun.