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

[Armandex0]

Ich denke fast nicht, dass es Nai ums "brauchen" geht sondern vielmehr dass man es dennoch verwenden wird. Das ist doch gerade der Punkt.
Es ist prinzipiell immer günstiger Datenpaket x auf mehrere Bänke,Slices,Module,whatever zu verteilen und parallel zu lesen/schreiben.
Das ist doch gerade der Grund warum das angewandt wird. (oder....?)
Verbesserung der Zugriffszeiten, ausnutzen der vorhandenen speicherbandreite(n) etc.pp.
Es gibt für mein Verständnis keinen logischen Grund diese Technik der Speicherverwaltung wegzulassen.

Edit:
Auch wenn ich sowas toll und interessant finde -man lernt ja gern hinzu- kann's genauso gut sein dass ich alles komplett falsch verstanden habe. 😳

 

[Nai]

Ich denke fast nicht, dass es Nai ums "brauchen" geht sondern vielmehr dass man es dennoch verwenden wird. Das ist doch gerade der Punkt.
Es ist prinzipiell immer günstiger Datenpaket x auf mehrere Bänke,Slices,Module,whatever zu verteilen und parallel zu lesen/schreiben.
Das ist doch gerade der Grund warum das angewandt wird. (oder....?)
Verbesserung der Zugriffszeiten, ausnutzen der vorhandenen speicherbandreite(n) etc.pp.
Es gibt für mein Verständnis keinen logischen Grund diese Technik der Speicherverwaltung wegzulassen.

Genau so war das gemeint

Und nun haben wir HBM mit Dual Command, welches im selben Channel schreiben und lesen kann. Das beschrieben meine Links und Folien exakt. Wohin soll man nun die Schreib- und Lesevorgänge noch Inteleaven wie Nai das beschreibt? Das eine ist GDDR5 und das andere HBM - es muss doch mal jetzt deutlich sein, dass das eine nicht für das andere gilt.

Mein letzter Versuch das Interleaving zu erklären. Diesmal an einen schönen Bild wo aus einer Textur mit dem Namen Tex gelesen wird:

Ohne dieses Interleaving wirst du genau das Problem bei HBM haben . . . . Der Rest des Posts geht wieder komplett offtopic am Problem vorbei, weshalb ich nicht schon wieder drauf eingehen und es korrigieren möchte.

Das kann kaum ernst gemeint sein bei der Verwendung deiner Begrifflichkeiten. Ich hatte wenigstens eine Quelle einer Hardware Redaktion die das so in der Überschrift verwendet hat und daher von dort zitiert und verwendet. Also woran hängst du dich jetzt auf?

Semantik, wie ich bereits beschrieben habe. Ich habe zwar nicht den Fachbegriff verwendet aber es semantisch korrekt beschrieben mit "Interleaved Memory Layout" und die "die Addressen werden interleaved auf die Kanäle abgebildet". Das ist semantisch korrekt und bereits relativ nahe an dem Begriff Channel-Interleaving dran. Und falls du meinst ich hätte Modul-Threading verwenden sollen: Nein das ist komplett etwas anderes wie von mir im letzten Post erklärt.

 

[Daedal]

Ohne dieses Interleaving wirst du genau das Problem bei HBM haben . . . . Der Rest des Posts geht wieder komplett offtopic am Problem vorbei, weshalb ich nicht schon wieder drauf eingehen und es korrigieren möchte.

Nein das wird es nicht. Ich habe dargelegt, dass Dual Command die Banks besser auslastet als jedes derzeit verwendetes Interleaving. Du beharrst auf etwas das nicht existiert bei HBM und begründest es damit, dass es doch so ist. Nur es gibt keine Quelle dazu - das einzige das du nun zum wiederholten mal erklärst: Was ist Interleaving.

Danke dafür, doch nachdem du es nun erneut erklärst bitte ich dich endlich eine einzige Qhelle zu nennen die beweist, dass HBM Interleaving nutzt. Ich habe dir die technischen Dokus gezeigt wo der Hersteller SKHynix erlärt, dass es kein Interleaving gibt so wie du es beschreibst.

Damit wäre das wohl abgeschlossen. Wohl auch weil mein post "am Offtoipc vorbei geht", im Gegensatz zu deinem der nach wie vor reines Offtopic ist und den Namen völlig zurecht trägt.

Semantik, wie ich bereits beschrieben habe. Ich habe zwar nicht den Fachbegriff verwendet aber es semantisch korrekt beschrieben mit "Interleaved Memory Layout" und die "die Addressen werden interleaved auf die Kanäle abgebildet". Das ist semantisch korrekt und bereits relativ nahe an dem Begriff Channel-Interleaving dran. Und falls du meinst ich hätte Modul-Threading verwenden sollen: Nein das ist komplett etwas anderes wie von mir im letzten Post erklärt.

"Interleaved Memory Layout" ist aber kein Chanel Interleaving, sondern bedeutet lediglich, dass die Subbanks gesplittet sind in der Ansprache durch den Controller - diese Folien haben wir schon mal diskutiert. Vielleicht blätterst du nun einige Seiten zurück und versucht das ganze mit den neu dazu gekommenen Infos und er richtigen Terminologie zu erfassen. Das könnte hilfreich sein und ich muss das ganze nicht von vorne anfangen mit den neuen Begriffen die du JETZT endlich anfängst in Quellen zu bestätigen. Irgendwann schaffst du auch mal einen Link zu etwas zu posten der dann auch beschreibt was du behauptest. Ich wünsch dir Glück dabei.

Um es mal auf den Punkt zu bringen:
Interleaving ist tot auf HBM. Der Grund dafür ist die getrennte Ansprache der Rows und Columns auf eigenständigen I/Os und der eingeständigen Speichercontroller für je 4x128-bit Dualchanel der "Dual Command" unterstützt. Dadurch werden Reads und Writes für die beiden Subbanks, die durch ein "Interleaved Memory Layout" getrennt angesprochen werden, gleichzeitig übermittelt auf dem Speicherkanal - es gibt keine Lücke mehr auf dem Transportweg die optimiert werden kann und dafür abwechselnd Reads und Writes übermittelt werden müssen.

 

[DrToxic]

Um es mal auf den Punkt zu bringen:
Interleaving ist tot auf HBM. Der Grund dafür ist die getrennte Ansprache der Rows und Columns auf eigenständigen I/Os und der eingeständigen Speichercontroller für je 4x128-bit Dualchanel der "Dual Command" unterstützt.

Ok, aber warum will man auf den "Boost" vom Interleaving verzichten? Damit verliert man ja im Vergleich bis zu 75% Durchsatz, wordurch wird das dann aufgewogen? Über den "Turbo" der einzelnen Channel?

 

[Nai]

Ok, aber warum will man auf den "Boost" vom Interleaving verzichten? Damit verliert man ja im Vergleich bis zu 75% Durchsatz, wordurch wird das dann aufgewogen? Über den "Turbo" der einzelnen Channel?

Das Bild war nur ein Beispiel, da ich nicht so viel zeichnen wollte. HBM hat bei 4096 Bit insgesamt 64 Channels, also wäre der Verlust dementsprechend schlimmer. Ich verstehe nicht, ob meine Posts wirklich ssoo schlecht zu verstehen sind, dass Daedal deshalb immer an mir vorbeiredet oder ob er es absichtlich oder mangels Verständnis tut. . . . . Sein aktuelles Schlusswort ist mal wieder eine Off-Topic-Auflistung von HBM-Features, teils mit falschen teils mit sinnlosen Begründungen.

 

[Daedal]

Damit verliert man ja im Vergleich bis zu 75% Durchsatz, wordurch wird das dann aufgewogen? Über den "Turbo" der einzelnen Channel?

Man kann nichts boosten wo keine Lücken mehr zu füllen sind. Die maximale Auslastung ist mit Dual Command erreicht. Die Pseudo-Channel ersetzten alles was hier über Interleaving geschrieben wurde. Das hat auch einen guten Grund. Die ganze Industrie bewegt sich auf segmentierte asynchrone Rechenleistung zu. Dies wird bei Liquid VR deutlich, bei der nächsten Version von eDP mit dem segmentierten PSR, bei den Asynchronen Compute Units und auch bei HBM.

 

[r4yn3]

Um das hier mal als Dau zu entwirrten zu versuchen. Ein 4 Hi Stack HBM, hat n Durchsatz von 128GB/s. Der Stack hat 4 Slices, wovon jeder Slice 2 Channel hat, und jeder Channel 2 Peusdochannel bietet (ab HBM2, steht 2 mal in dem memcom Link, Seite 23 Unten und Seite 30). Nichts desto trotz hat der Stack 128GB/s.

Will ich nun eine Textur mit den vollen 512GB/s (4 Stacks je 128GB/s) laden, muss ich zwangsläufig die Textur auf alle 4 Stacks verteilen/zerstückeln.

Was mir nun eigentlich der Psuedochannel bringt, der ja eigentlich nur die Auslastung eines Slices verbessert, aber nicht dessen Bandbreite....das Versuch ich eigentlich noch zu verstehen.

Edit: Armandex0 hat es eigentlich eh auch gut "erklärt". Das ganze Interleaving lässt sich auch bei HBM noch auf den Stack und Slice runterbrechen um die Bandbreite besser auszunutzen. Auch hier sehe ich nicht, was sich da mit dem Pseudochannel ändern, da dieser nur einen Channel effizienter verwaltet.

Wie Nai schon mehrmals sagte, sehe auch ich als Dau nicht, was das eine mit dem anderen zu tun hat. Zumal in keiner Quelle ersichtlich oder beschrieben wird, dass mit HBM kein Interleaving von Stacks und Slices mehr stattfindet.


OT: Nai hat hier im Forum schon oft bewiesen, dass er wirklich fundiertes Wissen über diese Materie besitzt. Da find ich es eigentlich schon maßlos dreist, ihn ständig hinzustellen, als hätte er keine Ahnung wovon er redet. UND dann im gleichen Atemzug anderen eine schlechte Forenetiquette vorzuwerfen.

 

[Daedal]

Anhang anzeigen 495752
Ohne dieses Interleaving wirst du genau das Problem bei HBM haben.

Dieses Bild hat Nai selber gezeichnet und zeigt unten nicht wie HBM agiert. Es sind nicht 3 Channel unausgelastet wenn kein interleaving genutzt wird. Deses Bild zeigt GDDR5 ohne Interleaving. Bei HBM sieht jeder Channel einzeln für sich aus wie Channel 1. Daher hat Interleaving keinen Nutzen. Vor allem da gar kein Chanel Interleaving existiert. Es ist Module -Threading.

Vor allem da Module-Threading lediglich max 4 Banks nutzen kann.

Das wäre wie wenn man Hyperthreading nutzen wollte wenn jeder Thread 100% Auslastung auf den jeweiligen Ressourcen der CPU hat. Es hat keinen Nutzen.

->Das was auf Seite 24 als Legacy Mode beschrieben ist, ist genau das was Nai die ganze Zeit erklärt (auch wenn er Interleaving falsch definiert, was aber keine Rolle spielt bei dieser Argumentation.)
Das was unter Pseudo-Channel Mode steht ist der Ersatz für Interleaving im Legacy Mode. Dies stellt einen Channel dar.

Hier eine Darstellung des selben Sachverhalts über alle Channels verteilt ("Bank n" bedeutet eine beliebige Anzahl von Bänken die sich alle ebenso unabhängig verhalten) - die Folie sollte auch schon bekannt sein aus dieser Diskussion hier im Thread:

Ergänzung (30. Mai 2015)

OT: Nai hat hier im Forum schon oft bewiesen, dass er wirklich fundiertes Wissen über diese Materie besitzt. Da find ich es eigentlich schon maßlos dreist, ihn ständig hinzustellen, als hätte er keine Ahnung wovon er redet. UND dann im gleichen Atemzug anderen eine schlechte Forenetiquette vorzuwerfen.

Das
magst du so sehen. Doch ich kenne ihn lediglich aus dieser Diskussion hier und dem Bild das er bei dem Thema über seinen Wissensstand offenbart und vor allem seinen Umgang mit belegten Quellen.

Ich schrieb schon einmal, dass es recht eindeutig zu sehen ist wenn ein Softwarefokusierter Entwickler nicht über seinen Abstraktionslayer hinaus schauen kann.
Der Memorycontroller bei HBM sitzt auf dem Stack im Logic-Die. Er kann nicht über Stackgrenzen hinaus Interleaving betreiben.

Interleaving verbessert ja nicht die Bandbreite, sondern die Auslastung der Banbreite die vorhanden ist durch gleichzeitige Reads und Writes. Dies geht bei konventionellen Channels nicht zeitgleich beim Zugriff auf Channels. Siehe Bild 1.

 

[Armandex0]

Dieses Bild hat Nai selber gezeichnet und zeigt unten nicht wie HBM agiert. Es sind nicht 3 Channel unausgelastet wenn kein interleaving genutzt wird. Deses Bild zeigt GDDR5 ohne Interleaving. Bei HBM sieht jeder Channel einzeln für sich aus wie Channel 1. Daher hat Interleaving keinen Nutzen.

Also ich glaube, da hast Du einen gravierenden Denkfehler drin. Deine Aussage würde bedeuten dass bei HBM regelmäßig nur ein kleiner Bruchteil der verbauten Kapazität effektiv nutzbar wäre.

Vor allem da gar kein Chanel Interleaving existiert. Es ist Module -Threading.
Vor allem da Module-Threading lediglich max 4 Banks nutzen kann.
Das wäre wie wenn man Hyperthreading nutzen wollte wenn jeder Thread 100% Auslastung auf den jeweiligen Ressourcen der CPU hat. Es hat keinen Nutzen.

Module Threading würde ohne Interleaving doch nichtmal Sinn machen.

Der Memorycontroller bei HBM sitzt auf dem Stack im Logic-Die. Er kann nicht über Stackgrenzen hinaus Interleaving betreiben.
Interleaving verbessert ja nicht die Bandbreite, sondern die Auslastung der Banbreite die vorhanden ist durch gleichzeitige Reads und Writes. Dies geht bei konventionellen Channels nicht zeitgleich beim Zugriff auf Channels.

Das wäre doch eine absolute Katastrophe für HBM Speicher. Und man man bräuchte dann wohl theoretisch immer größere Bandbreiten wenn man mehr Speicher verbauen möchte - effektiv wäre das wirklich nicht. Außerdem würde die meiste Zeit ein Großteil des vorhandenen Potentials ungenutzt brachliegen.

Ich würde mich freuen, wenn Du mal in klaren, verständlichen Worten Deine Vorstellung davon darlegen könntest. Insbesondere wäre es toll, wenn Du dabei auf Verweise zu div. technischen Werbepräsentationen verzichten könntest. Das hast Du m.E. schon zur Genüge getan.
Bitte erläutere aber mal die Funktionsweise von HBM mit eigenen Worten die letztlich auch jedermann nachvollziehen kann. Insbesondere wäre es toll, wenn Du dabei darauf eingehen könntest wie genau ohne die Verwendung von Interleaving bei HBM die vorhandenen Channels/Bandbreite effektiv nutzbar sind und welchen Zweck Module-Threading ohne Interleaving dann erfüllt.

 

[r4yn3]

Das wäre doch eine absolute Katastrophe für HBM Speicher. Und man man bräuchte dann wohl theoretisch immer größere Bandbreiten wenn man mehr Speicher verbauen möchte - effektiv wäre das wirklich nicht. Außerdem würde die meiste Zeit ein Großteil des vorhandenen Potentials ungenutzt brachliegen.

Das geht soweit ich das bisher verfolgt habe bei HBM Hand in Hand. Darum müsste man ja auch, wenn man bei HBM1 8GB verbauen möchte, den Interposer doppelt so breiit machen. Das ganze bekäme dann ein 2048bit SI und die Bandbreite wäre verdoppelt.

Der Memorycontroller bei HBM sitzt auf dem Stack im Logic-Die. Er kann nicht über Stackgrenzen hinaus Interleaving betreiben.

Der Controller vom Stack kann das nicht, aber ich vermute mal der Controller in der GPU übernimmt das.

Interleaving verbessert ja nicht die Bandbreite, sondern die Auslastung der Banbreite die vorhanden ist durch gleichzeitige Reads und Writes. Dies geht bei konventionellen Channels nicht zeitgleich beim Zugriff auf Channels. Siehe Bild 1.

Und da vermute ich den Denkfehler. Das Dual Command ist für mich kein Ersatz für Interleaving. Sinngemäßg stell ich mir dass Interleaving wie Raid0 bei Festplatten vor. Ich verteile die Daten, um die Bandbreite zu erhöhen. Das Dual Command mag die Auslastung eines Channels eines Slices verbessern, nicht jedoch die Auslastung eines Stacks.

 

[Nai]

Der Controller vom Stack kann das nicht, aber ich vermute mal der Controller in der GPU übernimmt das.

Es gibt Interleaving auf verschiedenen Ebenen. Für das Interleaving auf Channelebene müssen die Requests vom L1-Cache ersteinmal durch das interne Kommunikationsnetzwerk der GPU auf die zum entsprechenden Channel passenden L2-Segmente aufgeteilt werden. Für das Interleaving innerhalb eines Channels müssen die Segmente des Memory Controllers der GPU die L2-Requests auf die entsprechenden Pseudo-Channels und Bänke aufteilen.

So eine Anmerkung am Rande: Dass der Memory-Controller auf dem Stack beim Logic-Die sitzt ist ein Fehler in Wikipedia. HBM wird analog wie GDDR5 angesteuert über Row Select, Column Select, Bank Select usw. und inklusive Timing Restriktionen. Deshalb muss die GPU irgendeine Hardware besitzen, die die Requests vom L2-Cache in einer optimierten Art und Weise in die entsprechenden Befehle für HBM umwandelt. Ergo benötigt sie bei HBM weiterhin einen Memory Controller. Der Standard schreibt dementsprechend auch zum logic DIE:

The DRAM vendor may choose to require an optional interface die that sits at the bottom of the stack and provides signal redistribution and other functions. The vendor may choose to implement many of the logic functions typically found on DRAM die on this logic die.

 

[Daedal]

So eine Anmerkung am Rande: Dass der Memory-Controller auf dem Stack beim Logic-Die sitzt ist ein Fehler in Wikipedia. HBM wird analog wie GDDR5 angesteuert über Row Select, Column Select, Bank Select usw. und inklusive Timing Restriktionen. Deshalb muss die GPU irgendeine Hardware besitzen, die die Requests vom L2-Cache in einer optimierten Art und Weise in die entsprechenden Befehle für HBM umwandelt. Ergo benötigt man bei HBM weiterhin einen Memory Controller. Der Standard schreibt dementsprechend auch zum logic DIE:

Und genau da klärt sich auf was jeder hier missversteht. Das ansprechen durch Software erfolgt exakt auf dem selben Weg wie du es hier die ganze Zeit beschreibst.

Interleaving bei GDDR5 auf Bank-Ebene, wovon wir die ganze Zeit sprechen und das wie wir gemeinsam fest gestellt haben Chanel-Threading Heisst, wir ersetzt. Durch Pseudo-channels. Dieses "Interleave Memory Mapping" wird durch den im HBM Stack verbauten Memory-Controller "übersetzt". Dies hat zur Folge, dass aus Softwaresicht/Compilersicht keinerlei Änderungen stattfinden, ebenso wenig wie der GPU-Speichercontroller etwas anderes macht als bisher. Ihm erscheint das Memory-Layout wie bisher. Was Nai beschreibt und Interleaving nennt (Memory-Threading) wurde bisher auch auf der GPU verwaltet. Doch die GPU hat gar keinen Zugriff mehr auf auf diese Hardwareebene. 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.

Nai was in Wikipedia steht ist kein Fehler und was du sagst ist ebenso richtig. Und das ist was den Unterschied ausmacht aus der Sicht eines Programmierers. Keinen. Aus Sicht der Hardwareebene und auf dieser haben wir diskutiert, sind die Veränderungen wie von mir beschrieben.

Dies habe ich ausgeführt und das ist in den Folien die hier zu sehen sind beschrieben. Nur ist diese Verwaltungsebene nicht mehr Sache der GPU, sondern des HBM-Logic Dies. Die GPU erhält ein "Interleaved Memory Mapping" zum zugreifen auf die Channels, so wie sie es bisher gewohnt war. Nur über diesen Interconnect ist derzeit nichts bekannt, ausser dass AMD wohl einen Hybrid Hyperthreading/PCIe Interconnect entwickelt hat. Doch das ist ein anderes Thema.

Jede Darstellung von HBM in den Quellen stellt den Speichercontroller auf dem Logic-Die dar und zeigt dass die I/Os des Speichers nicht an die GPU weiter verdrahtet sind wie das bei GDDR der Fall ist. Wie auch, das würde die ganze Bandbreite ja wieder auf ein SI, das auf der GPU verbaut ist limitieren und genau das ist ja laut jedem Bericht zu HBM nicht mehr der Fall.

Ergänzung (30. Mai 2015)

Deine Aussage würde bedeuten dass bei HBM regelmäßig nur ein kleiner Bruchteil der verbauten Kapazität effektiv nutzbar wäre.

Ich weiss nicht wie du zu dem Schluss gekommen bist, doch vielleicht erklärt es sich durch das eben geschriebene.

Die GPU hat vollen Zugriff durch den Interconnect und verteilt die Daten wie bisher.

 

[r4yn3]

Wenn auf der GPU kein 1028bit SI vorhanden ist, wieso ist dann ständig die Rede von einem 4096bit SI, und dass man bei nem theoretischen Dual-Link Interposer das SI auf irrsinnige 8192bit aufblasen müsste?
Wohin führt der Breite SI Bus wenn nicht zur GPU?

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.

Wo wurde denn das Interface reduziert? Der Memorycontroller auf der GPU wurde kleiner, weil man die Logik zum ansprechen der Channels mit HBM auslagert. Das Interface selbst wurde aber größer.

Wie kann man solche Behaupten in den Raum werfen ohne Fiji und dessen MC zu kennen?

 

[Daedal]

http://www.cs.utah.edu/thememoryforum/mike.pdf
Auf Seite 11 hier steht das selbe nochmal zu lesen.
Auf Seite 12 steht exakt was Nai beschreibt.
Auf Seite 13 ist der Unterschied abgebildet den ich beschrieben habe:
Oben Nais Beschreibung, unten meine Beschreibung.
Bei oberer Auslastung der Channels ist INterleaving sinnvoll und wird angewand. Limitiert allerdings 4 Banks die zusammen Interleaven können.
Bei unterer Auslastung macht Interleaving keinen Sinn mehr, da der Channel lückenlos ausgelastet ist.

Detailierter ist das in dieser Quelle unter Pseudo-Channel beschrieben, die Auszüge habe ich hier schon gepostet im Thread.
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

Besides the spacing consideration and bandwidth improvements, there are likely going to be some direct changes to the GPUs that integrate support for HBM. Die size of the GPU should go down to some degree because of the memory interface reduction. With more simplistic clocking mechanisms and lower required clock rates, as well as with much finer pitches coming in through the GPUs PHY, integration of memory on an interposer can change die requirements for memory connections. Macri indicated that it would be nearly impossible for any competent GPU designer to build a GPU that doesn’t save die space with a move to HBM over GDDR5.

Edit:
Aus diesem Grund muss man übrigens auch zwei völlig unterschiedliche GPUs herstellen wenn man sie mit HBM oder GDDR5 bestücken will. Der Platz auf dem Die für 4096-bit SI ist nicht zu realisieren in vernünftigem Kostenrahmen. Daher wird es wohl keine FijiHBM und eine Fiji GDDR5 geben.

 

[r4yn3]

Nach wie vor wirfst du die Pseudochannels und Stackübergreifendes Interleaving in einen Topf. Da wird n Schuh draus.

TSV Anbindung? Wirebonding? Was hat das jetzt damit zu tun? PHY ist das Speicherinterface. TSV sind lediglich die Verbindungeun (Daten/Strom) durch den Stack.

Wenn du sagst, das Speicherinterface wird bezogen auf seine mm² kleiner, dann ja. Dennoch sind für mich 4096bit größer, als die aktuellen 512bit.

 

[Nai]

Das ansprechen durch Software erfolgt exakt auf dem selben Weg wie du es hier die ganze Zeit beschreibst.

Ich hab mich doch die ganze Zeit schon gar nicht auf die Software bezogen. Die Software arbeitet einfach mit irgendwelchen virtuellen Addressen/Objekten/Texturen/Buffern, die dann durch die Hardware *irgendwie* auf die physikalischen Addressen und dann weiter abgebildet auf die Kanäle/Module/Bänke werden. Das Abbilden spielt für die Programmierung bezüglich Funktionalität von Software an sich ersteinmal keine Rolle und ist nur für Optimierungen interessant.

Interleaving bei GDDR5 auf Bank-Ebene, wovon wir die ganze Zeit sprechen und das wie wir gemeinsam fest gestellt haben Chanel-Threading Heisst, wir ersetzt. Durch Pseudo-Channels

Wir sprechen von Interleaving bezüglich Kanälen. . . Pseudo-Channels sind wieder etwas anderes als Bank-Interleaving. Und beim Begriff Chanel-Threading weiß ich nicht was du damit sagen möchtest.

Dieses "Interleave Memory Mapping" wird durch den im HBM Stack verbauten Memory-Controller "übersetzt".

Der GPU-Memory-Controller steuert HBM weiter über die Angabe von Bank sowie Row und Column innerhalb dieser Bank an (siehe Pin-Belegung in den Specs vom Standard). Deshalb ist auch der Memory-Controller auf der GPU weiterhin dafür verantwortlich (eine gute) Abbildung von physikalischen Addressen auf diese Bänke, Rows, Columns zu wählen, damit aufeinanderfolgende Speicherzugriffe wenn möglich nicht in die selbe Bank fallen. Denn eine solche Bank kann nur einen Zugriff gleichzeitig abarbeiten. Und das dauert bis sie fertig ist. Hierfür verwendet der Memory-Controller auf der GPU wieder ein Bank-Interleaving.

Dies hat zur Folge, dass aus Softwaresicht/Compilersicht keinerlei Änderungen stattfinden, ebenso wenig wie der GPU-Speichercontroller etwas anderes macht als bisher. Ihm erscheint das Memory-Layout wie bisher. Was Nai beschreibt und Interleaving nennt (Memory-Threading) wurde bisher auch auf der GPU verwaltet. Doch die GPU hat gar keinen Zugriff mehr auf auf diese Hardwareebene.

Das ergibt keinen Sinn für mich.

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.

Schau dir mal wieder die Specs vom Standard an. So ein HBM-Stack hat tatsächlich 1024 Datenpins und ein paar Kontrollpins. Will man die Datenrate von sämtlichen 1024 Bits nutzen, so muss man die Pins auch an die GPU anschließen. Deshalb kommen auch für jeden weiteren HBM-Stack 1024 Pins für die GPU dazu. Alternativ hat man bei den meisten Speichertechnologien (ist das bei HBM überhaupt möglich?) auch die Wahl, dass sich mehrere "Chips" eine Anbindung zur GPU teilen und der Memory Controller den Chip über ein Chip select signal auswählt. Dadurch "halbiert" sich allerdings auch die Bandbreite der beiden Chips, weil sie sich die selben Leitungen zur GPU teilen müssen.

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.

Auch nach 10 maligen Lesen ergibt dieser Block für mich keinen Sinn.

Dies habe ich ausgeführt und das ist in den Folien die hier zu sehen sind beschrieben. Nur ist diese Verwaltungsebene nicht mehr Sache der GPU, sondern des HBM-Logic Dies. Die GPU erhält ein "Interleaved Memory Mapping" zum zugreifen auf die Channels, so wie sie es bisher gewohnt war. Nur über diesen Interconnect ist derzeit nichts bekannt, ausser dass AMD wohl einen Hybrid Hyperthreading/PCIe Interconnect entwickelt hat. Doch das ist ein anderes Thema.

Das ergibt auch keinen Sinn für mich.

Jede Darstellung von HBM in den Quellen stellt den Speichercontroller auf dem Logic-Die dar und zeigt dass die I/Os des Speichers nicht an die GPU weiter verdrahtet sind wie das bei GDDR der Fall ist.

Ich kenne hier gerade keine zuverlässige Quelle, die den Memory Controller dorthinverlagert, es wird dort lediglich immer gesagt dass der Base diverse Kontrolllogik und Signalverteilung enthält. Die Ansteuerng der einzelnen Channels erfolgt aber immer noch relativ direkt, weshalb es auch die entsprechenden direkten Ansteuerungpins (Row/Column/Bank/Daten) inklusive Timing Restriktionen für die einzelnen Channels gibt. Aus diesem Grund befindet sich hier auch kein Speichercontroller in dem Sinne, was man unter einem Speichercontroller versteht.

http://www.cs.utah.edu/thememoryforum/mike.pdf
Auf Seite 11 hier steht das selbe nochmal zu lesen.
Auf Seite 12 steht exakt was Nai beschreibt.
Auf Seite 13 ist der Unterschied abgebildet den ich beschrieben habe:
Oben Nais Beschreibung, unten meine Beschreibung.
Bei oberer Auslastung der Channels ist INterleaving sinnvoll und wird angewand. Limitiert allerdings 4 Banks die zusammen Interleaven können.
Bei unterer Auslastung macht Interleaving keinen Sinn mehr, da der Channel lückenlos ausgelastet ist.

Es geht bei der Quelle in dem Gantt-Diagramm um die bessere Auslastung durch Single-Bank-Refresh. . . . Das hat einmal wieder mit Bank-Interleaving nichts zu tun. Das bewirkt eine Interleavte Aufteilung des Speichers auf die Bänke:
http://violetlife.com.ne.kr/pds1/dram/114.jpg
(Beschriftung gefällt mir hier nicht so gut aber na gut.)

 

[Daedal]

Nach wie vor wirfst du die Pseudochannels und Stackübergreifendes Interleaving in einen Topf. Da wird n Schuh draus.

Du denkst ich vermische Dinge? Schauen wir nochmals worüber wir hier diskutieren:
Nai sagte:

Durch das Interleaved-Memory-Layout besitzen alle Speicherkanäle stets in etwa die gleiche Auslastung der Bandbreite. Dadurch limitiert auch immer der langsamste aller Kanäle die Bandbreite aller anderen Kanäle. Ergo macht ein unterschiedliches Takten der Kanäle in dieser Hinsicht keinen Sinn.

Dies ist nicht korrekt wie du daraus ersehen kannst, dass jeder Stack diese Verteillung direkt im Stack vornimmt. Man könnte einen Stack mit 500 MHz betreiben und einen anderen mit 1000 MHz. Dies ist mit GDDR5 Speicherbausteinen nicht möglcih. Dem widerspricht Nai mit eben dieser Begründung.

Ich hingegen streite nicht ab, dass es unter allen Speicherstacks zu einer Last Optimierung kommt durch den GPU Controller - nur ein Idiot würde so etwas bestreiten. Doch du unterstellst eben dies.

Was ich ausgeführt habe beweist allerdings, dass Nai nicht bekannt war, dass es eine Zwischen Logik gibt auf dem Die des HBM-Stacks, der zum einen eine Reduzierung der auf der GPU verbauten Transistoren bewirkt und zum anderen eine andere Weise der Auslastung innerhalb eines HBM Stacks ermöglicht. So dass dort auf der Hardwareeben kein Interleaving mehr benutzt wird.

verwendet jede mir bekannte Speichertechnologie mit parallelen Kanälen, die für Performance und nicht Redundanz verwendet werden, dieses Layout; seien es die Bänke oder die Segmente im CPU-Cache/GPU-Cache, die Bänke im Shared-Memory der GPU, die Bänke in DRAM-Speicherchips über den Memory-Controller, die Kanäle des CPU-DRAMS bzw GPU-DRAMs und zu guter letzt ein Raid-0-Setup.

Der Speicher ist ebenfalls auf einer Granularität interleavt, so dass er auf die Speicherbänke innerhalb eines Channels nicht sequentiell abgebildet wird. Die Ursache hierfür ist, dass eine Bank nur einen Zugriff zu einer Zeit abarbeiten kann. Durch das parallele Abfragen mehrerer Bänke kann durch das Interleaving die Zugriffszeit auf eine Bank in den meisten Fällen überbrückt werden. Die Voraussetzung dafür ist jedoch, dass der angeforderte Speicher auf mehrere Bänke verteilt vorliegt, was in den meisten Fällen durch das Bank-Interleaving der Fall sein sollte. Das hat aber nichts mit dem Interleaving bezüglich Channels zu tun.
[...]
Die Timings haben mit dem Interleaving bezüglich Channels nichts zu tun. Die Granularität des Interleavings wird durch die Addressüberestzungen von virtuellen Addressen nach physikalischen Addressen bzw. die Zuweisung von physikalischen Addressen auf die einzelnen Kanäle durch die MMU und die MCU bestimmt.

Macht der Logic-Die wie ich beschrieb

https://www.computerbase.de/forum/t...mit-neuem-namen.1479141/page-26#post-17445980

This technique of dividing same memory module in two or more independent module channels is referred as module threading.

 

[r4yn3]

Meine Güte wie kann man nur....Nai ging es von vornheirein darum, dass man, um die volle Bandbreite für eine Datei aller Stacks zu nutzen, diese auf alle verteilen muss. Und da macht es einfach keinen Sinn, die Stacks unterschiedlich zu takten.

Du selber hast jetzt über mehrere Seiten hinweg ein Interleaving in jeglicher Form für HBM als unnötig erachtet. Und nun kommt: " nur ein Idiot würde so etwas bestreiten."?

Obendrein Nai noch zu unterstellen versuchen, er wusste nicht das ein HBM Stack einen Logic Die hat...wobei du selber noch nicht mal im klaren darüber bist, was TSV und PHY des Logic Die machen.
Hinzu kommt, dass dir gar nicht klar war, dass jede 1024bit eines Stacks genauso zur GPU geführt werden.

Auf der Grundlage deinens "Wissens" hab ich doch ziemlich starke bedenken, dass du weißt was genau im Logic Die vorgeht.

 

[Nai]

Ich hingegen streite nicht ab, dass es unter allen Speicherstacks zu einer Last Optimierung kommt durch den GPU Controller - nur ein Idiot würde so etwas bestreiten. Doch du unterstellst eben dies.

Darum ging es doch die ganze Zeit und du hast es vehement abgestritten

Was ich ausgeführt habe beweist allerdings, dass Nai nicht bekannt war, dass es eine Zwischen Logik gibt auf dem Die des HBM-Stacks, der zum einen eine Reduzierung der auf der GPU verbauten Transistoren bewirkt und zum anderen eine andere Weise der Auslastung innerhalb eines HBM Stacks ermöglicht. So dass dort auf der Hardwareeben kein Interleaving mehr benutzt wird.

Ich verstehe nicht wie du drauf kommst, oder was du damit sagen möchtest abgesehen von den inhaltlichen Fehlern in der Aussage.

Macht der Logic-Die wie ich beschrieb

Siehe letzten Post.

This technique of dividing same memory module in two or more independent module channels is referred as module threading.

Modulthreading ist doch komplett etwas anderes wieder, was ich bereits für dich einfach und ausführlich zusammengefasst in Deutsch erklärt habe:
https://www.computerbase.de/forum/t...mit-neuem-namen.1479141/page-26#post-17446355

 

[Daedal]

Was du Interleaving nennst ist aber etwas anderes - was wird das denn nun?
Wenn die HBM-Stacks die Verteilung der Channels selber übernehmen, warum soll dann die GPU das zusätzlich machen?
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 ->

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.

Beides ist falsch - beides aus anderen Gründen die ich versuche hier darzulegen. Vermische nicht die Argumente die Bank-Interleaving betreffen (Pseudo-Channel, Single-Bank-Refresh) und sich auf den Teil beziehen den ich zitierte, mit den Argumenten die sich auf das Memory-Management des GPU-Controllers beziehen. 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.

Wenn ihr Argumente den falsche nDingen zuordnet, solltet ihr vielleicht aufhören im Sinne einer technischen Diskussion alles und jeden INterleaving zu nennen.