News AMD Radeon: R9 390X mit Hawaii und 8 GB GDDR5, Fiji mit neuem Namen

[Nai]

Wenn die HBM-Stacks die Verteilung der Channels selber übernehmen, warum soll dann die GPU das zusätzlich machen?

Tun sie nicht, siehe vorletzter Post.

Die GPU verteilt lediglich die Renderojekte und weisst Speicherbereiche zu, diee ihr vomm HBM-Logic Die zur verfügung gestellt werden. Selbt Wenn aus GPU-Sicht das Scheduling so aussieht als ob das wie bei GDDR 5 war, so passiert dies nciht auch tatsächlich in Hardware

Sinn ?

Wenn das was Nai und du sagen stimmen würde, wäre es völlig unmöglich an einer GPU z.B. 2 GB ECC und 2 GB normalen Speicher anzusprechen. Wie wir alle sicherlich übereinstimmen, würde ein solches "Interleaving" nicht funktionieren wegen dem zusätzlichen Bit bei ECC. Mit HBM sind solche Konfigurationen möglich. Dies wäre aber die Stackebene von der du sprichst.

Ich weiß nicht aus welcher zuverlässigen Quelle die Idee des Mischens von ECC und nicht ECC kommt. Die einzige (unzuverlässige) Quelle die ich finde ist diese:
http://www.hardwareluxx.de/index.ph...ine-erhoehung-der-speicherbandbreite-ist.html
Aus Anwendungssicht wäre der Nutzen aus Kombination von ECC und nicht ECC ersteinmal stark eingeschränkt und würde zudem Anpassungen an den APIs erfordern, wo man für Speicherbereiche ECC einstellen kann. Andere Quellen reden nur davon, dass ECC und nicht ECC HBM das selbe physikalische Interface verwenden. Selbst wenn man bei HBM ECC und nicht ECC kombinieren würde: Hier müsste dann das Interleaving nur zwischen den Stacks nach ihrem ECC-Support unterscheiden.

Beides ist falsch - beides aus anderen Gründen die ich versuche hier darzulegen.

Das Problem ist, dass deine Begründungen von anderen Menschen nicht nachvollzogen werden können und ich sie sogar für falsch betrachte.

Auch wenn es einige neue Eigenschaften für den GPU-Controller gibt, die dadurch möglich werden, dass HBM im Gegensatz zu GDDR5 einen Logic-Die besitzt der das Management völlig verändert auf die Weise wie ich es beschrieben habe.

Wie bereits von mir beschrieben: Die Grundlegende Ansteuerung und damit die Problematik des Interleavings ändert sich nicht.

 

[Daedal]

Du beharrst mittlerweile auf die dritte Definition von Interleaving die du dir im Zuge dieser Diskussion zugelegt hast. Die anderen hatte ich ja schon zitiert.

Das ist der einzige Grund warum du hier ständig das selbe wiederholst als ob das in irgendeiner Form widerlegt was ich schrieb.

Das ist auch der Grund warum einige hier mitlesenden das verwirrend finden.

Die Situation mit ECC ist nur ein weiterer Beleg, dass der Speicher in unterschiedliche Pools mit unabhängiger Ansteuerung aufgeteilt werden kann. Ohne "Interleaving" auf einer Ebene deiner Wahl zwischen den ECC und normalen Stacks.

Die Bestätigung dafür findest du vermutlich in jedem Link den ich die letzten 4 Seiten hier gepostet habe - gelesen hast du offensichtlich keinen davon.

 

[r4yn3]

Er muss nichts widerlegen. Du begreifst es nur schlichtweg nicht. Alle anderen die hier mitlesen verstehen, worauf er aus war, nur du nicht.

Ab dem Punkt, wo du behauptet hast ein 1024bit Interface wäre nicht möglich, und andeutest, eine GPU hätte mit HBM keinen Speichercontroller mehr, da diesere ja auf dem Stack ist....sorry, da kann man dich einfach nicht mehr ernst nehmen.
Da hilfts auch nicht wenn du noch 1000 Quellen verlinkst, die du scheinbar selber nicht verstehst.

 

[Daedal]

Ab dem Punkt, wo du behauptet hast ein 1024bit Interface wäre nicht möglich, und andeutest, eine GPU hätte mit HBM keinen Speichercontroller mehr, da diesere ja auf dem Stack ist....sorry, da kann man dich einfach nicht mehr ernst nehmen.

Zitiere bitte wo ich das mit den 1024bit SI geschreiben habe und wo das mit dem fehlenden GPU Speichercontroller.

Ich kann wirklich nur hoffen, dass du dich nicht auf diese Passage beziehst und dies dein Textverständnis ist.

Die I/O die der HBM Speicher bereit stellt fuhren in den Logic-Die und enden dort. Auf der GPU gibt es kein 1024-bit-Speicherinterface. Das wäre gar nicht machbar. Das Speicherinterface sitzt auf dem HBM-Die und dort ist die Row-Column Verwaltung die seitens der GPU wie bisher angesprochen wird und dann anstatt Interleaving auf der Ebene weiterführend in Dual-Command und Pseudo-Channels auf dem Speicher die Auslastung maximiert auf den Banks.

Deshalb werden mit jedem 1GB Stack HBM 8-Channels zugefügt und es kommen 1024-Bandbreite dazu. Dafür ist keinerlei Änderung an der GPU von Nöten wie das bisher war wo das Speicherinterface einen großen Teil des Dies (10% ca.) belegt hat. Diese Logik ist nicht mehr vorhanden und Teil des HBM-Speichers. Das vereinfacht auch das Cache-Subsystem weil es eben erst hinter dem Cache zu diesen Optimierungen kommt.

Würde das anders sein, müsste Fiji ein 4096-bit Speicherinterface auf der GPU verbauen für 4GB HBM. Dies ist ja wohl aus offensichtlichen Gründen nicht der Fall.

 

[r4yn3]

Und nun muss man noch als zusätzliche Information zufügen, dass der Speichercontroller für HBM auf dem Speicher selber sitzt und nicht in der CPU oder GPU wie man das bisher gewohnt war. Auf diese Weise ist die drastische Reduzierung des Speicherinterfaces möglich.

Was sitzt dann nun auf der GPU, dass mit HBM kommuniziert? Der HBM Logic Die Controller?

Und ich hab dich vorhin schon gefragt, wenn die GPU kein 1024bit SI hat, wo führen dann die Leitungen hin?
Wo hast du deine Quelle her, dass Fiji kein 4096bit Interface besitzt?

 

[Nai]

Du beharrst mittlerweile auf die dritte Definition von Interleaving die du dir im Zuge dieser Diskussion zugelegt hast. Die anderen hatte ich ja schon zitiert.

Ich habe bislang nur eine Defiintion verwendet: Das zyklische Aufteilen des Speichers auf die Resourcen (Bänke/Kanäle). Auf was habe ich je nach Kontext immer spezifiziert näher.

Die Situation mit ECC ist nur ein weiterer Beleg, dass der Speicher in unterschiedliche Pools mit unabhängiger Ansteuerung aufgeteilt werden kann. Ohne "Interleaving" auf einer Ebene deiner Wahl zwischen den ECC und normalen Stacks.

Die Aufteilung der einzelnen Speicherzellen in Kanäle und Bänke ist fest. Das mit den Pools stand nirgendwo.

Die Bestätigung dafür findest du vermutlich in jedem Link den ich die letzten 4 Seiten hier gepostet habe - gelesen hast du offensichtlich keinen davon.

Bestätigung zu deinen Thesen findet man dort keine.

wo das mit dem fehlenden GPU Speichercontroller.

Bitte:

Und nun muss man noch als zusätzliche Information zufügen, dass der Speichercontroller für HBM auf dem Speicher selber sitzt und nicht in der CPU oder GPU wie man das bisher gewohnt war.

Würde das anders sein, müsste Fiji ein 4096-bit Speicherinterface auf der GPU verbauen für 4GB HBM. Dies ist ja wohl aus offensichtlichen Gründen nicht der Fall.

Das ist doch gerade der Witz von HBM. Die GPU hat ein sehr breites vergleichsweise niedrig getaktetes Speicherinterface mit 1024 Datenleitungen ein paar Address- und sonstige Kontrollleitungen pro HBM-Stack. Deshalb haben die HBM-Stacks gemäß des Standards auch so viele Anschlüsse. Deshalb auch die Gerüchteküche zu einem 4096 Bit SI. Näheres dazu habe ich bereits erläutert.

Dein Zitat ergibt immer noch in weiten Teilen keinen Sinn. Was heißt zum Beispiel:

Das Speicherinterface sitzt auf dem HBM-Die und dort ist die Row-Column Verwaltung die seitens der GPU wie bisher angesprochen wird und dann anstatt Interleaving auf der Ebene weiterführend in Dual-Command und Pseudo-Channels auf dem Speicher die Auslastung maximiert auf den Banks.

Für mich klingt das nach einer sinnlosen Aneinanderreihung von Begriffen.

Die offensichtlichen Fehler an deinem Zitat habe ich bereits zuvor erläutert und will ich nicht mehr vortragen.

 

[Daedal]

Was sitzt dann nun auf der GPU, dass mit HBM kommuniziert? Der HBM Logic Die Controller?

Und ich hab dich vorhin schon gefragt, wenn die GPU kein 1024bit SI hat, wo führen dann die Leitungen hin?
Wo hast du deine Quelle her, dass Fiji kein 4096bit Interface besitzt?

Du solltest nun anfangen den Unterschied zwischen Interface und Controller zu erkennen. Und beide Begriffe entsprechend in meinen Aussagen sortieren in deinem Kopf. Dann ergeben deine Fragen vielleicht Sinn.

Ich habe bislang nur eine Defiintion verwendet: Das zyklische Aufteilen des Speichers auf die Resourcen (Bänke/Kanäle). Auf was habe ich je nach Kontext immer spezifiziert näher.

Nein du hast den selben Begriff für unterschiedliche Definitionen verwendet. Wozu hast du dich dann die ganze Zeit über Banks unterhalten?
Anstatt Interleaving haben wir nun Module-Threading, Bank-Interleaving (beides sitzt nun auf dem HBM Logic Die) und Memory Scheduling (sitzt auf der GPU und ist über das PHY mit dem PHY des HBM Speichers verbunden, welches dort an das 1024-bit Interface jedes HBM-Stacks angebunden ist=4096-bit Interface)

Ergänzung (31. Mai 2015)

Bestätigung zu deinen Thesen findet man dort keine.

Du willst ernsthaft behaupten du findest keine Bestätigung für konfigurierbares ECC in den technischen Quellen?

 

[r4yn3]

Ändert aber nichts daran, dass du scheinbar gar nicht weißt wie groß das Speicherinterface von Fiji ist. Prost Mahlzeit, wie soll man da noch weiter diskutieren.

Aber klar, Fiji hat nur noch ein Interface, Controller befindet sich alles auf dem HBM Stack, welcher sich die Daten selbstständig aus der GPU zieht...

 

[Nai]

Du solltest nun anfangen den Unterschied zwischen Interface und Controller zu erkennen. Und beide Begriffe entsprechend in meinen Aussagen sortieren in deinem Kopf. Dann ergeben deine Fragen vielleicht Sinn.

Seine Fragen ergeben schon sinn. Nur deine Antworten mal wieder nicht. Deine sonstigen Aussagen, wie dass die GPU mal einen Memory-Controller mal keinen Memory-Controller bei HBM benötigt, ebenfalls.

Nein du hast den selben Begriff für unterschiedliche Definitionen verwendet.

Wie gesagt habe ich nie. Siehe letzter Post.

Wozu hast du dich dann die ganze Zeit über Banks unterhalten?

Weil du aufgebracht hast dass Interleaving bezüglich Channels fälschlicherweise ein sogenanntes "Modulthreading" bzw. "Bank-Interleaving" sei. Siehe folgender Post: https://www.computerbase.de/forum/t...mit-neuem-namen.1479141/page-25#post-17444756 Danach hast du das Channel-Interleaving ständig mit den falschen HBM-Features in Kombination gebracht (Single-Bank-Refresh usw).

Anstatt Interleaving haben wir nun Module-Threading, Bank-Interleaving (beides sitzt nun auf dem HBM Logic Die) und Memory Scheduling (sitzt auf der GPU und ist über das PHY mit dem PHY des HBM Speichers verbunden, welches dort an das 1024-bit Interface jedes HBM-Stacks angebunden ist=4096-bit Interface)

An dem Satz ist mal wieder fast alles falsch.

Du willst ernsthaft behaupten du findest keine Bestätigung für konfigurierbares ECC in den technischen Quellen?

Es steht nirgendwo, dass es das Ziel ist HBM-Stacks mit ECC und nicht mit ECC zu mischen. Dass man ECC abschalten kann steht dort; aber das ging ja bereits bei GDDR5. Auch das mit dem "Pools" steht da nirgendwo. . .

Langsam habe ich das Gefühl, dass Daedal mal wieder absichtlich versucht uns in Kleinigkeiten oder ablenkende Off-Topic-Diskussionen zu verzetteln. . .

 

[r4yn3]

Ich möcht von ihm nur noch wissen was er denn denkt welches SI Fiji hat. Scheinbar ja nicht mal ein 1024bit breites. Da wären ja 4096 regelrecht lächerlich hoch

Das für alles andere habe ich ehrlich gesagt keinen Nerv mehr. Es ist witzlos zuzusehen, wie er von einem Detail zum nächsten ausweicht, because of Pseudochannel...

Für mich mal wieder eine nette Lehrstunde, man wird sich dann ohnehin wieder beim Fiji/HBM Test sehen ^^

 

[Nai]

because of Pseudochannel...

Was Pseudochannel? Du irrst dich. Es ist der Single Bank Refresh und Dual-Command-Interface! In der Hinsicht von Daedals vollkommener Ahnungslosigkeit, auch zu sehen an seinen inneren Widersprüchen wo jetzt genau mal wieder ein Speichercontroller bei HBM ist, finde ich folgende Aussage von ihm auch mal wieder relativ amüsant:

Ich schrieb schon einmal, dass es recht eindeutig zu sehen ist wenn ein Softwarefokusierter Entwickler nicht über seinen Abstraktionslayer hinaus schauen kann.

Ich mache auch langsam Schluss hier, weil es keinen Sinn ergibt und es gleich mit den "falschen" nächsten Off-Topic-Argumenten weiter geht. Ich habe denke ich alles gesagt was es zum Thema sagen gab, so dass jeder außer Daedal wahrscheinlich die Problematik hinter dem Interleaving verstanden hat. Da kann jetzt von mir aus auch Daedal weiter Phantasieaufsätzen dazu schreiben; seine Meinung ändere ich sowieso nicht und von einer Diskussion mit ihm habe ich wegen seinen sinnlosen Argumenten keinen Erkenntnissgewinn.

 

[Dark_Knight]

Hat einer von euch ein genauen Schaltplan von Fiji? Egal wer jetzt. Weil wenn nicht, redet ihr seit zig Seiten einfach nur viel Technikblabla wo keiner weiß was der andere eigentlich meint. Kann eigentlich nicht so schwer sein jetzt eine genaue Schaltzeichnung vorzulegen wie genau jetzt die GPU mit dem HBM Speicher kommuniziert, welche Bahnen von wo nach wo gehen und wer jetzt genau wem was zum verarbeiten gibt.

Wenn keiner dies jetzt hat. Dann hört doch endlich auf zig Seiten Sinnlos zu posten und wartet ab wenn Fiji gezeigt wird. Man könnte fast meinen ihr habt nichts besseres zu tun mit eurer Freizeit. Geht doch einfach mal ein paar Spiele zocken. Echt ey.

 

[Daedal]

Ändert aber nichts daran, dass du scheinbar gar nicht weißt wie groß das Speicherinterface von Fiji ist. Prost Mahlzeit, wie soll man da noch weiter diskutieren...

Ich möcht von ihm nur noch wissen was er denn denkt welches SI Fiji hat. Scheinbar ja nicht mal ein 1024bit breites. Da wären ja 4096 regelrecht lächerlich hoch
^^

Du redest einen Stuss daher.
Fiji hat 4096 SI.
Es sitzt aber nicht auf der GPU. Es sitzen jeweils 1024 SI auf jedem GB HBM Stack.
Diese TSV basierenden SIs haben sehr kurze Signalwege. Die Anbindung der GPU erfolgt nicht mehr wie bisher direkt über das SI.
Auf der GPU sitzt der GPU Speichercontroller und auf den HBM Logic Dies sitzt der Speichercontroller für den Stack.

Der GPU Controller verwaltet die Speicherstacks und der HBM Controller kümmert sich um Bank-Interleaving und Module-Threading auf dem Stack. Das scheint wohl zu kompliziert zu sein?

Zu dem Interconnect zwischen GPU und HBM Stack der auf allen Abbildungen als PHY bezeichnet ist gibt es noch keine Informationen.

Ergänzung (31. Mai 2015)

An dem Satz ist mal wieder fast alles falsch

An dem Satz ist gar nicht falsch.

Ergänzung (31. Mai 2015)

Hat einer von euch ein genauen Schaltplan von Fiji? Egal wer jetzt. Weil wenn nicht, redet ihr seit zig Seiten einfach nur viel Technikblabla wo keiner weiß was der andere eigentlich meint. Kann eigentlich nicht so schwer sein jetzt eine genaue Schaltzeichnung vorzulegen wie genau jetzt die GPU mit dem HBM Speicher kommuniziert, welche Bahnen von wo nach wo gehen und wer jetzt genau wem was zum verarbeiten gibt.

Nicht von Fiji, doch den wie der HBM auf dem Interposer verbunden ist. Ich habe das hier verlinkt und es wurde ebenso erfolgreich ignoriert wie der Rest auch:

http://www.cs.utah.edu/thememoryforum/mike.pdf
[•••].
http://www.hotchips.org/wp-content/...Bandwidth-Kim-Hynix-Hot Chips HBM 2014 v7.pdf
Dort findest du allerdings auch die Erklärung wie die I/O angebunden sind.
Das Wirebonding von GDDR5 ist auf Seite 4 erklärt.
Der Untrerschied zur TSV Anbindung auf HBM auf der folgenden Seite 5.
Eine Schematische Darstellung auf Seite 9 des gesamten Stacks inkl. der Tabelle wie die Chanell-verteilung auf eien Stack (4Hi-1GB) ist.
Auf Seite 10 dann die schematische Darstellung er Innterconnects im INterpsoer zum SoC (CPU oder GPU ist identisch angebunden)
Es gibt keinen Sockel der die IO verbindet. Auf dem Base Die (Logic-Die) sind laut Grafik enthalten: DFT Area, TSV Area und PHY - wie man erkennen kann werden die TSV nicht raus geleitet aus dem Stack, sondern es gibt eine Übergabe an den "PHY" - wie der gestaltet ist, ist noch nicht beschrieben worden in einer Quelle die mir bekannt wäre.
Noch etwas Detailierter ist es auf der Seite 12 dargestellt.

Was das Speicherinterface auf der GPU angeht: es wird kleiner trotz massivem Sprung auf 4096-bit bei 4 GB HBM.
Siehe dazu aus diesem Artikel bei pcper:
http://www.pcper.com/reviews/Genera...Memory-HBM-Architecture-AMD-Plans-Future-GPUs
.

Hier eine Schematische Dartstellung des auf dem HBM Logic Die sitzenden DRAM-Controllers. Und bevor mir jetzt wieder einer kommt mit das wäre ja HBM und kein DRAM. 1 GB HBM besteht aus 4x256 GB SDRAM mit TSV verbunden im Stacking.

HBM DRAM Controller Core

The core accepts commands using a simple local interface and translates them to the command sequences required by HBM DRAM devices. The core also performs all initialization and refresh functions.The core uses bank management modules to monitor the status of each SDRAM bank. Banks are only opened or closed when necessary, minimizing access delays.

The core queues up multiple commands in the command queue. This enables optimal bandwidth utilization for both short transfers to highly random address locations as well as longer transfers to contiguous address space. The command queue is also used to opportunistically perform look-ahead activates, precharges and auto-precharges further improving overall throughput.

 

[Tappy]

Ich hatte noch einen Bericht im Kopf, in dem das so erwähnt wurde. Hab' ihn grad nochmal rausgesucht:


http://www.3dcenter.org/news/welche-grafikkarten-beherrschen-directx-120-und-121-hardware

edit:
Wie genau das jetzt mit Dx12-Features aussehen wird, weiß halt keiner genau. Aber mein Tipp bleibt: Tahiti und Pitcairn fliegen aus dem Portfolio raus, weil GCN 1.1 (evtl sogar 1.2) der neue Mindeststandard wird - der Rest wie gesagt Refresh (kein Rebrand!).

@Faust2011

Dr. Toxic hat alles relevante schon geschrieben.
Nur meine R9 285 hat GCN 1.2 und die wird wohl DX12.1 supporten und natürlich Features wie VSR, was halt so neu kommt oder schon kam.
Ich erwarte auch, dass die 285 die 280x zukünftig überholt mit DX12

Bin noch gespannt inwieweit nv dx12 hardwaremäßig supported...

 

[r4yn3]

Fiji hat 4096 SI.
Es sitzt aber nicht auf der GPU. Es sitzen jeweils 1024 SI auf jedem GB HBM Stack.
Diese TSV basierenden SIs haben sehr kurze Signalwege. Die Anbindung der GPU erfolgt nicht mehr wie bisher direkt über das SI.

Dein ernst? TSV basierende SIs? Nicht mehr direkt über das SI? Ich weiß nicht ob ich lachen oder weinen soll...du verstehst von dem ganzen noch weniger als bisher vermutet.
Deiner Ansicht nach, ersetzt der Logic Die scheinbar jeglichen MC der GPU. Es gibt nicht einen Slide der sowas andeutet.

Bisherige GPUs hatten z.B. 8-64bit Dual Channel Controller, womit von 16 Speicherchips jeder mit 32bit angesteuert wurde...ergibt 512bit.

Bei HBM wird die GPU wohl 4-1024bit Controller haben, die wesentlich simpler sind da ja die meiste Logik ausgelagert wurde. Siehste ja schön auf deinen Bildchen.

Das Speicherinterface ist lediglich die Breite zwischen GPU und Speicher, in diesem Fall eben HBM, der pro Stack 1024bit hat. Ergibt 4096bit. Also 4096 kleine feine Leiterbahnen die durch den Interposer zur GPU laufen.

Wenn du dich schon schwer tust das zu verstehen, wie willst du dann den Logic Die verstehen?

 

[Daedal]

Bisherige GPUs hatten z.B. 8-64bit Dual Channel Controller, womit von 16 Speicherchips jeder mit 32bit angesteuert wurde...ergibt 512bit.

Bei HBM wird die GPU wohl 4-1024bit Controller haben, die wesentlich simpler sind da ja die meiste Logik ausgelagert wurde. Siehste ja schön auf deinen Bildchen.

Das Speicherinterface ist lediglich die Breite zwischen GPU und Speicher, in diesem Fall eben HBM, der pro Stack 1024bit hat. Ergibt 4096bit. Also 4096 kleine feine Leiterbahnen die durch den Interposer zur GPU laufen.

Wenn du dich schon schwer tust das zu verstehen, wie willst du dann den Logic Die verstehen?

Und wieder denkst du der Speichercontroller sitzt zusammen mit dem 1024-bit Interface auf dem selben Die. Das habe ich dir jetzt mehrfach erklärt das dies nicht der Fall ist. Das PHY verbindet den GPU-Controller mit dem SI auf dem HBM Die. Über das PHY werden die 4*8*128-bit Kanäle angesprochen durch die GPU, wenn 4*1GB Stacks verbaut sind. Das steht genau so auf jedem Bild das du hier nicht verstehst offensichtlich.

Wie sonst sollte das SI(Es heisst auf allen HBM Folien PHY) auf der GPU weniger Platz einnehmen obwohl es 8 mal mehr Bandbreite ermöglicht? Die Stacks haben diesen Teil des GPU Controllers jetzt mit im Logic Die integriert. Kapiers endlich. Lies die Quellen.

 

[Nai]

Hier eine Schematische Dartstellung des auf dem HBM Logic Die sitzenden DRAM-Controllers. Und bevor mir jetzt wieder einer kommt mit das wäre ja HBM und kein DRAM. 1 GB HBM besteht aus 4x256 GB SDRAM mit TSV verbunden im Stacking.

Mensch Daedal. Lese und verstehe doch nur einmal, aber einmal die Quellen die du postest. Das ist kein HBM Logic DIE. Sondern ein HBM Speichercontroller-Chip. Intended Use:

Northwest Logic’s high-performance, high quality, easy-to-use IP cores are optimized for use in both ASICs and FPGAs. Each core is available in source code and netlist formats and is provided with a testbench and expert technical support.

 

[Daedal]

Seite 10 zeigt diese Architektur doch exakt
http://www.hotchips.org/wp-content/...Bandwidth-Kim-Hynix-Hot Chips HBM 2014 v7.pdf
Und das ist der Logic Die in der Quelle. Der Controller sitz auf dem HBM. Lies die Erklärung unter dem Bild und neben dem Bild. Du kannst doch das nicht einfach bestreiten wenn das dort exakt so steht:
http://nwlogic.com/products/docs/HBM_DRAM_Controller_Core.pdf
Das ist doch nicht der GPU-Controller auf AMDs Chips.

 

[r4yn3]

Hör auf zu behaupten die TSVs sind das SI. PHY ist das SI. PHY ist lediglich eine allgemeine Bezeichnung für ein Interface. Fiji wird trotz Logic Dies der Stacks weiterhin einen MC haben...und das Interface ist nach wie vor 4096bit breit.

Wie vollkommen dämliche wäre dein Lösungsweg, wenn ich von Slice bis zum Logic Die 128GB/s hätte, diese aber nicht zur GPU bringe? Lest du überhaupt den Schwachsinn den du von dir gibst?

 

[Nai]

Seite 10 zeigt diese Architektur doch exakt
http://www.hotchips.org/wp-content/u...02014 v7.pdf

Argh nein. Schau dir an, wie die Memory-Solutions von NW-Logic verwendet werden sollten:
http://nwlogic.com/products/docs/Memory_Interface_Solution_Overview.pdf
Das PHY was du bei NW-Logic liest, ist das PHY, was da in der HBM-Präsi auf Seite 11 im SoC-Kasten ist.

Und nocheinmal: Da ist kein Memory Controller auf dem HBM-Stack. Du steuerst einen HBM-Stack analog wie jeden gewöhnlichen DRAM über Column-Select, Row-Select, Bank-Select an. Siehe den Gottverdammten standard. Deshalb hat HBM ja auch die Features des Dual-Command-Interfaces (Seperate pins für Rows und Columns) und des Single-Bank-Refresh-Befehls. Deshalb steht auch in keiner Quelle, dass im Logic Die der Memory Controller liegt. Da hilft es auch nichts, wenn du verzweifelt versuchst das durch falsche "Querverbindungen" zu beweisen. . . . .