News Radeon R9 390(X): AMD spricht über den HBM-Grafikspeicher von Fiji

[Dark_Knight]

Alles was bisher hier kommt sind Spekulatius. Außer es hat hier schon jemand wirkliche Benchmarks und darf sie aus NDA Gründen noch nicht zeigen, aber dann sollte derjenige endlich ruhig sein. Ich glaube viele sind einfach zu ungeduldig was HBM nun wirklich zu leisten vermag auf einem "alten" 28mm Chip. Denn das wäre ja schon einmal ein Indiz wo die Reise hingeht. Das ihr euch jetzt in technischen Details verstrickt wo der eine nicht weiß was der andere jetzt sagen will, macht die Sache nicht besser. Am besten warten wir halt noch den 1 Monat ab. Ich persönlich finde dieses ewige Abwarten und erst zeigen auf irgendwelchen Veranstaltungen auch einfach bescheuert, aber so funktioniert das Marketing nun einmal.
Ich lese an sich gerne solche "News" Threads, weil es teils gutes Entertainment bietet, trotzdem sollte dich das auch in Grenzen halten. Für mich kommt ihr teils aber vom Thema ab und kommt vom HBM Speicher zur GTX 970 mit ihrem 3,5GB normalen und 500MB Krüppelspeicher. Warum? Ich meine das Ding ist eine solide Karte wenn man es schaffen würde nur die 3,5GB voll angebundenen Speicher anzusprechen und die restlichen 500MB so zu sagen abtötet. Lässt sich aber nur schwer realisieren, von daher ist es eine eher schlecht zu gebrauchende Karte wenn man sein System ausreizen will. Aber das ist ja auch nicht das Thema.

Somit kommen wir wieder zu dem Punkt der eigentlich wichtig ist, was kann HBM wirklich effektiv leisten und hat wer schon Benchmarks parat oder nicht?

 

[Daedal]

@Dark_Knight
Du hast sicherlich Recht.
Es ist halt manchmal nicht so einfach zu erkennen wer noch an Informationen interessiert ist oder daran rabulistische Lücken zu finden die er nutzen will zum diskreditieren.

Nenn es doch endlich auch mal richtig und nicht Single-Cell-Refresh. Single Bank Refresh hat mal wieder gar nichts mit der genannten Problematik zu tun.

Aus Quelle:
http://www.hardwareluxx.de/index.ph...ine-erhoehung-der-speicherbandbreite-ist.html

3. Single Refresh Bank/Cell bei HBM:

Da wir hier ja über HBM Speicher sprechen so wie AMD in der News-Überschrift.

 

[Nai]

Aus Quelle:
http://www.hardwareluxx.de/index.php...reite-ist.html

Dadurch, dass du dich auf eine Quelle stützt, die es auch falsch bezeichnet hat, werden eine Posts nicht besser. Der Begriff ist zudem unsinnig, was ein Leser der den Kontext versteht gemerkt hätte, da nicht einzelne Zellen sondern einzelne Bänke durch den Befehl refresht werden. Du magst doch Quellen oder? Dann ziehe dir mal die HBM Specs http://www.jedec.org/standards-documents/docs/jesd235 und schaue nach. Da steht: Function: Single Bank Refresh ; Symbol: REFSB. Single Cell Refresh kommt nicht in den Specs vor. Eigentlich sollte man bei Hardware immer die offiziellen Specs oder Herstellerdokumente als vertrauenswürdige Quelle verwenden und nicht irgendwelche "zwielichtigen" Newsseiten referrenzieren. Das lernt man recht schnell in einem jedem Studium.

In dem Kontext fand ich es auch amüsant, dass du folgendes geschrieben hast:

Auf Seite 15 (http://www.cs.utah.edu/thememoryforum/mike.pdf) steht auch, dass der Speichercontroller Temperaturdaten aus dem HBM Speicher erhält und entsprechend den Takt anpassen kann um TDP-Budgets einzuhalten.

Wenn man sich Seite 15 anschaut steht da:

HBM supports Temperature Compensated Self Refresh
-Temperature dependent refresh rates with several temperature ranges (e.g. cool/standby, normal, extended, emergency)
-Temperature sensor can be read by memory controller to adjust its refresh rates as well

Also Temperaturabhängige Refresh-Rates; das hat nichts mit dem Speichertakt und TDP-Budget zu tun! So wie du permanent den falschen Fachbegriff Single-Cell-Refresh komplett aus dem Zusammenhang verwendest, fragt man sich wirklich ob du überhaupt weißt, was das ist.

Welche Fakten hast du denn hier eingebracht?
Keine Links, keine technischen Quellen
..hmmm
Provozieren dich technische Whitepapers und Präsentationen?

1. Das Angeben von Quellen macht deine falschen Folgerungen aus den Quellen auch nicht korrekter
2. Ich schreibe meine Posts größtenteils aus dem Kopf heraus mit Wissen aus meinem CS Studium. Zudem würde es meine Posts m.E. sehr zerstückeln, wenn ich alles mit Quellen belegen würde. Sollte aber ein Leser dazu mehr lesen wollen dann kann er danach googlen und sollte eigentlich genügend Quellen finden. Denn das ist eigentlich relativ grundlegend was ich meistens schreibe. Wenn nicht, dann kann er auch nachfragen und ich gebe Quellen (indem ich Google verwende ) an. Ist nicht so, dass ich in dem Fall einen auf Daedal machen würde und sagen würde: "Dir fehlen komplett die Grundlagen und ich erkläre dir das nicht verständlich, weil es so komplett grundlegend ist"

Wenn du keine Zusammenhänge in meinen Quellen erkennen kannst, solltest du mehr Grundlagen erlernen. Ich kann sehr gut erkennen wenn ein softwarefokusierter Gesprächspartner Defizite hat zu sehen was hinter seinem Abstraktionslayer passiert.

Deine Quellen versteht man. Nur deine Folgerungen sind, wie von mir bereits erläutert, teils falsch, teils sinnfrei. Auf Nachfragen gehst du nicht ein, Fachbegriffe verwendest du falsch. Gleichzeitig kannst du keinen Fehler an meinen Ausführungen finden, abgesehen davon, dass Single-Cell-Refresh die Antwort auf alle Probleme ist. Was soll ich davon halten, außer dass du keine Ahnung hast worüber du schreibst? Bin ja nicht der einzige, der bereits zu dem Schluss gekommen ist. . .

 

[Daedal]

Dadurch, dass du dich auf eine Quelle stützt, die es auch falsch bezeichnet hat, werden eine Posts nicht besser. Der Begriff ist zudem unsinnig, was ein Leser der den Kontext versteht gemerkt hätte, da nicht einzelne Zellen sondern einzelne Bänke durch den Befehl refresht werden.

Nein, muss sie auch nicht. Es soll nur zeigen, dass du dich auf Begriflichkeiten stürzt die noch nicht mal eindeutig definiert sind. Die Verwendung von Banks/Ranks/Cell variiert je nach Hardwarelevel oder Sprache der techischen Quelle. Das selbe erlebst du auch bei normalem RAM und daher muss man den Kontext verstehen in dem diese Begriffe verwendet werden. Sofern man daran interessiert ist über die technische Seite von HBM zu diskutieren.

Zu Temperature Self Refresh:

Also Temperaturabhängige Refresh-Rates; das hat nichts mit dem Speichertakt und TDP-Budget zu tun!

Ich zweifel daran wie jemand der des englischen mächtig ist diesen Satz zitieren kann:

Temperature dependent refresh rates with several temperature ranges (e.g. cool/standby, normal, extended, emergency)

Um dann zu behaupten das hätte nichts mit Speichertakt und TDP zu tun. Das ist wirklich keine Basis um über diese Technik mit dir zu diskutieren.

 

[Nai]

Nein, muss sie auch nicht. Es soll nur zeigen, dass du dich auf Begriflichkeiten stürzt die noch nicht mal eindeutig definiert sind.

Der Begriff Single-Bank-Refresh ist in Bezug auf HBM eindeutig definiert.

Die Verwendung von Banks/Ranks/Cell variiert je nach Hardwarelevel oder Sprache der techischen Quelle.

Ich kenne keine Terminologie, wo der Begriff Zelle synonym zum Begriff Bank verwendet wird. Dementsprechend ist der Begriff Single-Cell-Refresh unsinnig. Ich reite normalerweise nicht auf Begrifflichkeiten herum. Wenn jemand aber Fachbegriffe falsch umformt, so dass ihre Bedeutung verloren geht, und zudem sie ständig Out-Of-Context verwendet, führt das Gesamtbild dazu, dass ich den Wissensstand des Autors bezweifle.

Um dann zu behaupten das hätte nichts mit Speichertakt und TDP zu tun. Das ist wirklich keine Basis um über diese Technik mit dir zu diskutieren.

Es handelt sich hier um Temperaturabhängigen Refresh. So kurz zusammengefasst:
Es ist DRAM ("Dynamischer" RAM), weshalb die Ladung in den Zellen nach einiger Zeit refresht werden müssen. Silizium ist Heißleiter, weshalb es höhere Leckströme bei höheren Temperaturen gibt. Dadurch entladen sich die Kondensatoren der Zellen schneller, weshalb sie bei höheren Temperaturen häufiger refresht werden müssen. Bisher wie bei GDDR5 wurde die Refresh-Rate so groß gewählt (ist das wirklich bisher so? finde keine Quelle dazu), dass sie selbst bei den worst case Temperaturen ausreicht um die Daten im DRAM zu bewahren. Bei HBM wird die Refresh-Rate so gewählt, dass sie bei der aktuellen Temperatur ausreicht um die Daten zu bewahren. Dadurch wird bei HBM etwas Bandbreite und etwas elektrische Leistung eingespart.

Du folgerst aus der Gegebenheit:

Temperature sensor can be read by memory controller to adjust its refresh rates as well

,dass

Auf Seite 15 (http://www.cs.utah.edu/thememoryforum/mike.pdf) steht auch, dass der Speichercontroller Temperaturdaten aus dem HBM Speicher erhält und entsprechend den Takt anpassen kann um TDP-Budgets einzuhalten.

Das ist komplett etwas anderes als die Refresh-Rate an die Temperatur anzupassen.

 

[Daedal]

HBM hat tatsächlich weder Ranks, noch Banks oder Cells. Die korrekte Terminologie, welche sich durchsetzen wird, ist "Slices". Jedes Slice kann man als Bank oder Cell betrachten. Jedes Slice hat zwei "subbanks" die mit jeweils einem 64-bit Channel angesprochen werden.
1 GB HBM besteht derzeit aus einem Stack der 4-Hi ist (ein "Hi" entspricht einem Slice). Jeder Stack ist aus 4x256 MB grossen DRAM-Dies zusammengesetzt.

Single-Bank-Refresh ist der refresh eines Slices - dies ist die Granularität die hier von HBM-Speichercontrollern genutzt werden kann. Sowohl für Taktraten als auch für ECC Features.

Seite 20 und 21 des schon mehrfach geposteten Links:
http://www.memcon.com/pdfs/proceedings2014/NET104.pdf

 

[Nai]

Ok, nachdem du meinen letzten Post fast komplett ignoriert hast, versuchst du es nun mit der nächsten Sau?

HBM hat tatsächlich weder Ranks, noch Banks oder Cells. Die korrekte Terminologie, welche sich durchsetzen wird, ist "Slices". Jedes Slice kann man als Bank oder Cell betrachten. Jedes Slice hat zwei "subbanks" die mit jeweils einem 64-bit Channel angesprochen werden.
1 GB HBM besteht derzeit aus einem Stack der 4-Hi ist (ein "Hi" entspricht einem Slice). Jeder Stack ist aus 4x256 MB grossen DRAM-Dies zusammengesetzt.

Schau dir das Bild auf Seite 20 doch an. Das was du sagst ergibt keinen Sinn wieder und ist komplett falsch. Die Relationen der Terminologie in einem HBM-Stack sehen gemäß der Präsentation wie folgt aus:
Eine HBM-Stack besteht aus 4 gestapelten DRAM-DIEs (Cores) und einem Base-DIE. Einen gestapelten DIE bezeichnet man auch als Slice.
Jeder Core besitzt 2 Channels.
Jeder Channel besitzt 8 Bänke
Jede Bank besteht aus 2 Subbänken
Jede Bank ist 0.5 GB groß, also besitzt sie mindestens 0.5 G an DRAM-Zellen

Single-Bank-Refresh ist der refresh eines Slices - dies ist die Granularität die hier von HBM-Speichercontrollern genutzt werden kann.

Single-Bank-Refresh ist ein Refresh einer einzelnen Bank innerhalb eines Channels innerhalb eines Slices. . . . .

Aber ich sehe schon, ich kämpfe hier gegen Windmühlen

 

[Daedal]

So kurz zusammengefasst:
Es ist DRAM ("Dynamischer" RAM), weshalb die Ladung in den Zellen nach einiger Zeit refresht werden müssen. Silizium ist Heißleiter, weshalb es höhere Leckströme bei höheren Temperaturen gibt. Dadurch entladen sich die Kondensatoren der Zellen schneller, weshalb sie bei höheren Temperaturen häufiger refresht werden müssen. Bisher wie bei GDDR5 wurde die Refresh-Rate so groß gewählt (ist das wirklich bisher so? finde keine Quelle dazu), dass sie selbst bei den worst case Temperaturen ausreicht um die Daten im DRAM zu bewahren.

Dies ist absolut korrekt und gut zusammen gefasst. Was nun hier bei HBM zum tragen kommt ist die Granularität, die der Speichercontroller nutzen kann um den Speicher unterschiedlich zu takten. Dies ist bei GDDR5 nicht möglich und daher müssen alle Speicherbausteine mit der selben Taktrate laufen - nicht so bei HBM.

Ergänzung (24. Mai 2015)

Ok, nachdem du meinen letzten Post fast komplett ignoriert hast, versuchst du es nun mit der nächsten Sau?

Wohl nur zu langsam darauf geantwortet.^^

Ergänzung (24. Mai 2015)

Single-Bank-Refresh ist der refresh eines Slices - dies ist die Granularität die hier von HBM-Speichercontrollern genutzt werden kann. Sowohl für Taktraten als auch für ECC Features.

Der Teil den du ignoriert hast.

Ergänzung (24. Mai 2015)

Jeder Channel besitzt 8 Bänke
Jede Bank besteht aus 2 Subbänken

Schau dir das Bild noch mal genau an und du wirst die Besonderheit sehen: Die Subbanks sind jeweils einem anderen Speichercontroller zugeordnet. Die Beschriftung sagt: keine I/O Abhängikeit der Subbanks. Die Bank ist sozusagen gesplittet.

Auf dieser Eigenschaft, die bisheriger GDDR5 nicht hat, basieren die Möglichkeiten des Speichercontrollers diese Bereiche unterschiedlich zu takten: Sei es wegen Temperaturdifferenzen im linken oberen HBM-Stack oder sei es wegen Asynchronem Computing - hier wird es möglich je nach GPU-Last oder Speicherbandbreite eine optimale Balance der Takte von GPU und Speicher "on-the-fly" zu balancieren. Es wird nie wieder Speicherbandbreitentests geben wie den der zuletzt hier auf CB erschienen ist. Sollte der Speicher zu langsam sein, kann die GPU etwas runter takten um höheren Takt im Speicher zu ermöglichen innerhalb des selben TDP-Budgets. Natürlich nur wenn dort auch das Limit liegt.

Nenne es meinetwegen einen Bandbreiten-Turbo, der sich dynamisch an den Bedarf anpasst.

 

[Nai]

Dies ist absolut korrekt und gut zusammen gefasst.

Damit sagst du immer noch nicht wie du aus einer Folie temperaturabhängigen Refresh folgerst, dass HBM seinen Takt gemäß TDP anpasst.

Was nun hier bei HBM zum tragen kommt ist die Granularität, die der Speichercontroller nutzen kann um den Speicher unterschiedlich zu takten. Dies ist bei GDDR5 nicht möglich und daher müssen alle Speicherbausteine mit der selben Taktrate laufen - nicht so bei HBM.

Die unterschiedliche Taktung bezieht sich auf die Channels innerhalb eines Stacks (aus den Specs):

Each channel provides access to an independent set of DRAM banks. Requests from one channel may not
access data attached to a different channel. Channels are independently clocked, and need not be
synchronous.

Bereits bei GDDR5 könnte man theoretisch auch die Channels auch unterschiedlich Takten wenn man wollte. Das hat man aber aus nahelegenden Gründen (In etwa gleiche Last wegen dem Interleaved Speicherlayout) nicht gemacht.

Single-Bank-Refresh ist der refresh eines Slices - dies ist die Granularität die hier von HBM-Speichercontrollern genutzt werden kann. Sowohl für Taktraten als auch für ECC Features.

Das ist wieder falsch. Single-Bank-Refresh bezieht sich auf eine einzelne Bank innerhalb eines Channels. Des Weiteren ist die Granularität Channel-Basiert und nicht Slice-Basiert; man kann die Channels in einem Slice voneinander unabhängig ansteuern. Siehe obiges Zitat aus dem Standard.

Schau dir das Bild noch mal genau an und du wirst die Besonderheit sehen: Die Subbanks sind jeweils einem anderen Speichercontroller zugeordnet. Die Beschriftung sagt: keine I/O Abhängikeit der Subbanks. Die Bank ist sozusagen gesplittet.

Auf dieser Eigenschaft, die bisheriger GDDR5 nicht hat, basieren die Möglichkeiten des Speichercontrollers diese Bereiche unterschiedlich zu takten

I/O Unabhängigkeit bezieht sich darauf, dass sich die Zugriffe auf eine (Sub-)Bank nicht gegenseitig beeinflussen bzw. stören können. Des weiteren Laufen die Bänke und Subbänke in einem Speicherchannel mit dem selben Takt. Nur die Bänke aus unterschiedlichen Channels sind voneinander unabhängig taktbar; ebenso wie die Channels von GDDR5 bereits (in ihrer Taktung) voneinander unabhängig waren.

Sei es wegen Temperaturdifferenzen im linken oberen HBM-Stack oder sei es wegen Asynchronem Computing - hier wird es möglich je nach GPU-Last oder Speicherbandbreite eine optimale Balance der Takte von GPU und Speicher "on-the-fly" zu balancieren. Es wird nie wieder Speicherbandbreitentests geben wie den der zuletzt hier auf CB erschienen ist.

Der Block ist wieder ein Kandidat für: http://www.reddit.com/r/WritingPrompts/

Sollte der Speicher zu langsam sein, kann die GPU etwas runter takten um höheren Takt im Speicher zu ermöglichen innerhalb des selben TDP-Budgets. Natürlich nur wenn dort auch das Limit liegt.

Das wäre bereits jetzt mit GDDR5 möglich. . . .

Dafür, dass ich im Gegensatz zu dir keine Ahnung von der Hardware habe, machst du gerade aber ganz schön viele Fehler bei der Diskussion.

 

[Daedal]

Bereits bei GDDR5 könnte man theoretisch auch die Channels auch unterschiedlich Takten wenn man wollte. Das hat man aber aus nahelegenden Gründen (In etwa gleiche Last wegen dem Interleaved Speicherlayout) nicht gemacht.

Eine Quelle bitte die diese Fähigkeit dem GDDR5 Controller zuspricht. Bis dahin ist es für mich Blödsinn von dem ich bisher noch nie was gehört haben und erfunden ist von dir.

Das ist wieder falsch. Single-Bank-Refresh bezieht sich auf eine einzelne Bank innerhalb eines Channels. Des Weiteren ist die Granularität Channel-Basiert und nicht Slice-Basiert; man kann die Channels in einem Slice voneinander unabhängig ansteuern. Siehe obiges Zitat aus dem Standard.

Das ist falsch, denn die Granularität ist immer 128-bit Dualchannel. Siehe Quelle Seite 20/21 über die wir immer noch reden. Also auch nicht Slice-basiert, sondern 1/4 des Slices= je DRAM Baustein, derer 4 einen Slice ergeben.

I/O Unabhängigkeit bezieht sich darauf, dass sich die Zugriffe auf eine (Sub-)Bank nicht gegenseitig beeinflussen bzw. stören können. Des weiteren Laufen die Bänke und Subbänke in einem Speicherchannel mit dem selben Takt. Nur die Bänke aus unterschiedlichen Channels sind voneinander unabhängig taktbar; ebenso wie die Channels von GDDR5 bereits (in ihrer Taktung) voneinander unabhängig waren.

Quelle? Dies ist in der Quelle mit keinem Wort erwähnt, was es sehr unwahrscheinlich macht, das dies das wichtigste Featuire ist. Es mag stimmen, aber wohl lediglich ein Nebeneffekt sein. Sofern du eine Quelle hast die dies bestätigen kann.

Das wäre bereits jetzt mit GDDR5 möglich. . . .

Dafür, dass ich im Gegensatz zu dir keine Ahnung von der Hardware habe, machst du gerade aber ganz schön viele Fehler bei der Diskussion.

Dafür dass du keine einzige Quelle richtig lesen kannst und weiterhin keine Quellen für eine einzige deiner Behauptungen lieferst, scheinst du sehr überzeugt zu sein.

Aber ich habe es wenigstens nochmal versucht...

 

[Nai]

Eine Quelle bitte die diese Fähigkeit dem GDDR5 Controller zuspricht. Bis dahin ist es für mich Blödsinn von dem ich bisher noch nie was gehört haben und erfunden ist von dir.

Folgt eigentlich ganz einfach aus den Eigenschaften eines Channels. Ich dachte du bist so der Hardwarepro . . . .

Speicherchannels zeichnen sich dadurch aus, dass sie voneinander unabhängig ansteuerbar sind. Ergo kann man sie natürlich auch unterschiedlich takten, sofern man es nur möchte und den Memory-Controller dementsprechend entwirft. Ob jetzt der GDDR5 Memory Controller von aktuellen GPUs das unterstützt ist wieder ein anderes Bier, analog ob es ein zukünfiger HBM Memory Controller jetzt tatsächlich unterstützt. Zumindest bei aktuellen Intel-CPUs kann man beim Memory-Controller für jeden Channel eigene Timings definieren, sogar wenn die Taktraten bei beiden Channels identisch sein müssen.

Das ist falsch, denn die Granularität ist immer 128-bit Dualchannel. Siehe Quelle Seite 20/21 über die wir immer noch reden. Also auch nicht Slice-basiert, sondern 1/4 des Slices= je DRAM Baustein, derer 4 einen Slice ergeben.

Der Begriff DualCannel kommt mal wieder gar nicht vor in der Präsi; ein weiterer Fehler deinerseits; der restliche Sinn von dem was du hier sagen willst erschließt sich mir wieder nicht . . . Es werden Channels und nicht Slices "angesteuert", jeder Channel liefert jeweils pro Takt 256 Bit Daten per Double Data Rate. Die Slices haben mit der externen Ansteuerung und der Granularität nichts zu tun. Unter anderem deswegen erwähnen die Specs die Slices nur mal kurz, gehen aber nicht weiter drauf ein, und beschreiben nur das Verhalten der einzelnen Channels.

Quelle? Dies ist in der Quelle mit keinem Wort erwähnt, was es sehr unwahrscheinlich macht, das dies das wichtigste Featuire ist. Es mag stimmen, aber wohl lediglich ein Nebeneffekt sein. Sofern du eine Quelle hast die dies bestätigen kann.

Jeder Channel hat ein Clock-Signal und Timings, die für alle Bänke gleich sind. Ergo benötigt jede der Bänke des Channels auch gleich Lange für jede der Operationen, wodurch sie "gleich getaktet" sind. Siehe wieder Specs, wo ich Link oben gepostet habe.

Dafür dass du keine einzige Quelle richtig lesen kannst und weiterhin keine Quellen für eine einzige deiner Behauptungen lieferst, scheinst du sehr überzeugt zu sein.

Bisher hast du mir noch keinen Fehler aufzeigen können wie ich deine Quellen verwende, während ich deine Posts problemlos zerpflücken konnte. Die Tatsache, dass ich bereits die Specs verlinkt habe und referenziere vergisst du eben mal.

 

[Daedal]

Folgt eigentlich ganz einfach aus den Eigenschaften eines Channels. Ich dachte du bist so der Hardwarepro . . . .

Quelle zu den Eigenschaften des GDDR5-Channels aus denen das folgt? Schon wieder keine einzige Quelle zu keiner deiner Aussagem^^

Der Begriff DualCannel kommt mal wieder gar nicht vor in der Präsi; ein weiterer Fehler deinerseits; der restliche Sinn von dem was du hier sagen willst erschließt sich mir wieder nicht . . . Es werden Channels und nicht Slices "angesteuert", jeder Channel liefert jeweils pro Takt 256 Bit Daten per Double Data Rate.

Seite 20 der Präsentation unten rechts die Tabelle: Ch./Slice: 2

Überschrift der Folie 21:
Each HBM die has 2 channels
1 channel consists of 128 TSV I/O with 2n prefetch

Wenn ich das Dualchannel/Slice nenne ist das durchaus legitim - ergibt sich aus der Quelle die ich gepostet habe und hier noch mal zitiert habe zu deinem Verständnis. Es wäre hilfreich wenn du den selben Willen zeigen würdest.

Bisher hast du mir noch keinen Fehler aufzeigen können wie ich deine Quellen verwende, während ich deine Posts problemlos zerpflücken konnte. Die Tatsache, dass ich bereits die Specs verlinkt habe und referenziere vergisst du eben mal.

Eigentlich schon mehrere - wir nähern uns aber langsam dem Verständnis - wohl spätestens wenn du mal ernsthaft versuchst selber eine Quelle für deine Aussagen zu posten die diese untermauern.
Wo ist ein Link zu Specs (wovon?)?

 

[Nai]

Quelle zu den Eigenschaften des GDDR5-Channels aus denen das folgt? Schon wieder keine einzige Quelle zu keiner deiner Aussagem^^

Weil die einzelnen Memory-Channels voneinander unabhängig sind ist es prinzipiell möglich. Man macht es allerdings im Speziellen aus den oben beschriebenen Gründen wegen des Interleaved Layouts nicht; deshalb kann ich auch keine Quelle mangels Existenz liefern.

Wenn ich das Dualchannel/Slice nenne ist das durchaus legitim

Ok war unklar formuliert.

Überschrift der Folie 21:
Each HBM die has 2 channels
1 channel consists of 128 TSV I/O with 2n prefetch

Dadurch ergibt das was du gesagt hast immer noch keinen Sinn. Slices spielen immer noch keine Rolle bei der Ansteuerung.

Wo ist ein Link zu Specs (wovon?)?

Zu HBM. Siehe link oben: http://www.jedec.org/standards-documents/docs/jesd235

 

[Cool Master]

@Nai

Das ist kein Spec sondern einfach ein Standard. Die Hersteller können und dürfen davon abweichen.

 

[Nai]

Das ist kein Spec sondern einfach ein Standard. Die Hersteller können und dürfen davon abweichen.

Meines Sprachverständnisses nach bezeichnet man die Voraussetzungen die ein Standard an die Implementierungen stellt auch oft als Specs. Siehe zum Beispiel "OpenGL Specification"

 

[Daedal]

Eine Quelle bitte die diese Fähigkeit dem GDDR5 Controller zuspricht. Bis dahin ist es für mich Blödsinn von dem ich bisher noch nie was gehört haben und erfunden ist von dir.

Das ist ja alles wundervoll. Aber ich warte immer noch wann du zum Punkt kommst und eine Quelle für das anbietest was ich auch gefragt habe??

Zudem ist es ja wohl unstrittig, dass GDDR5 kein Singel Bank Refresh beherrscht und ebenso keine separaten Column und Row I/Os hat. Nun wie machen die das denn ohne diese Eigenschaften die der Controller ansprechen muss? Schön dass der Channel etwas kann wie jeder x-beliebige.

Ergänzung (24. Mai 2015)

Zu HBM. Siehe link oben: http://www.jedec.org/standards-documents/docs/jesd235

Und jetzt bitte eine Quelle zu GDDR5 der das selbe kann deinen Ausführungen nach. ich brauch keine Quelle die mir zeigt was ich sowieso schon schreibe, sondern die mal belegt was du hier so behauptest.

The interface is divided into independent channels. Each channel is completely independent of one another. Channels are not necessarily synchronous to each other.

Ergänzung (24. Mai 2015)

Dadurch ergibt das was du gesagt hast immer noch keinen Sinn. Slices spielen immer noch keine Rolle bei der Ansteuerung.

Zitiere bitte wo ich das behauptet habe. Slices sind nur die Gruppierung - ich nannte es Granularität die der Controller ansteuern kann. Das sollte nun geklärt sein und auch endlich Sinn ergeben für dich.

 

[Nai]

Das ist ja alles wundervoll. Aber ich warte immer noch wann du zum Punkt kommst und eine Quelle für das anbietest was ich auch gefragt habe??

Ich kann im Speziellen keine Quelle dafür liefern, weil ich keine gefunden habe. Wahrscheinlich deshalb weil es wie bereits erklärt extrem suboptimal ist, das zu machen. Analogerweise kannst du keine Quelle liefern, dass es nicht möglich ist. Ich kann dir aber nocheinmal ausführlicher erklären wieso es prinzipiell bereits bei GDDR5 beziehungsweise bei jeder Speicherarchitektur mit unabhängigen Kanälen möglich ist:

Jeder GDDR5 Channel besitzt seine eigenen/s:
-GDDR5 Chips
-Kommunikationsleitungen (Taktsignal, Steuerleitungen, Addressleitungen, Datenleitungen) zur GPU
-Segment vom GDDR5 Speichercontroller

Betrachtet man nur die GDDR5 Chips und die Kommunikationsleitungen, so sind die einzelnen Channels komplett voneinander unabhängig. Dadurch stören sie sich auch nicht gegenseitig, wenn man die Channels mit unterschiedlichen Taktraten betreibt. Das einzige Problem ist der Speichercontroller der GPU, welcher eben auch unterstützen muss, dass seine einzelnen Segmente mit unterschiedlichen Taktraten laufen können. Da man den Speichercontroller abgesehen davon dass er die einzelnen GDDR5-Kanäle korrekt ansteuern muss beliebig entwerfen kann ist es möglich.

Da du so ein Hardwarepro bist und die grundlegende Behauptung bereits "Blödsinn" war, kannst du mir sicher sagen, was an meiner Begründung falsch ist.

Zudem ist es ja wohl unstrittig, dass GDDR5 kein Singel Bank Refresh beherrscht und ebenso keine separaten Column und Row I/Os hat. Nun wie machen die das denn ohne diese Eigenschaften die der Controller ansprechen muss? Schön dass der Channel etwas kann wie jeder x-beliebige.

Was hat das wieder damit zu tun?

Ich bezog mich mit "ansteuern" hierauf:

Single-Bank-Refresh ist der refresh eines Slices - dies ist die Granularität die hier von HBM-Speichercontrollern genutzt werden kann. Sowohl für Taktraten als auch für ECC Features.

Mit Gruppierung statt Granularität ergeben die Sätze immer noch keinen Sinn bzw sind weiterhin falsch. Aber diese Falschheit deckt sich interessanterweise mit deinem komplett falschen Begriffsverständnis, was du vermutlich komplett falsch aus http://www.memcon.com/pdfs/proceedings2014/NET104.pdf Folie 20 abgeleitet hast:

HBM hat tatsächlich weder Ranks, noch Banks oder Cells. Die korrekte Terminologie, welche sich durchsetzen wird, ist "Slices". Jedes Slice kann man als Bank oder Cell betrachten. Jedes Slice hat zwei "subbanks" die mit jeweils einem 64-bit Channel angesprochen werden.
1 GB HBM besteht derzeit aus einem Stack der 4-Hi ist (ein "Hi" entspricht einem Slice). Jeder Stack ist aus 4x256 MB grossen DRAM-Dies zusammengesetzt.

Slice, Bank(http://en.wikipedia.org/wiki/Memory_bank), Cell(http://en.wikipedia.org/wiki/Memory_cell_(binary)), ist doch alles das selbe . Die Restlichen Relationen sind auch komplett falsch wie von mir bereits im Post https://www.computerbase.de/forum/t...eicher-von-fiji.1477084/page-22#post-17425383 erläutert wurde. Es ist sehr schwer mit dir zu diskutieren, unter anderem deshalb weil du permanent alle Fachbegriffe komplett durcheinander schmeißt, und 90 \% deiner Aussagen unter anderem deshalb keinen Sinn ergeben. Tragisch, dass du dich selbst als Hardwarepro betrachtest; eventuell ein Resultat des Dunning-Kruger-Effekts?

 

[Daedal]

Ich kann im Speziellen keine Quelle dafür liefern, weil ich keine gefunden habe. Wahrscheinlich deshalb weil es wie bereits erklärt extrem suboptimal ist, das zu machen. Analogerweise kannst du keine Quelle liefern, dass es nicht möglich ist.

Spar dir deine weiteren Ausschweifungen...das sagt doch alles aus. Ich soll jetzt eine Quelle dafür bringen dass etwas NICHT möglich ist von dem du behauptest es geht. Nur hast du keine Quellen gefunden, weil das ja sowieso niemand macht, weil es sinnlos wäre....na halt ich das aus. Dann lösch ich mal diesen Thread in meinen Abos. ^^

Daran ändert sich auch nichts weil ich versehentlich 3 mal Cell anstatt Bank geschrieben habe Aufgrund der unterschiedlichen Verwendung in den Quellen...von denen du ja immer noch keine aufbieten kannst. Dies war ja schon geklärt - wenn du meinst, dass diese Begrifflichkeiten etwas an der funktionsweise ändern, dann bitte schön.

 

[Moon_Knight]

Daedal nervt so extrem...

Mal etwas anderes gruseliges:
AMD - Analysten erwarten Konkurs bis 2020

In letzter Zeit häuften sich ja auch mal wieder die Nachrichten zum desolaten Zustand (z.B. http://winfuture.de/news,86695.html )

Selbst AMD-Finanzchef Devinder Kumar äußerte sich ja, um eine Übernahme schmackhaft zu machen:
http://www.gamestar.de/hardware/prozessoren/amd-fx-9590/amd_prozessoren,701,3086125.html

Mit Fiji rechnet AMD ja selbst nur mit einem Umsatzzuwachs von 5%. ( http://www.pcgameshardware.de/AMD-R...Specials/R9-390X-Release-Preis-Daten-1154596/ )

So richtig stolz scheint AMD auf Fiji und der restlichen 300er-Serie aber nicht zu sein, so war zumindest der Eindruck auf dem Financial Analyst Day. Der Umsatz mit Desktop-Grafikkarten soll im zweiten Halbjahr nur um etwa 5 Prozent zunehmen, bei ohnehin schon schlechten Absätzen erscheint das nicht viel. Fiji dürfte so nur eine Überbrückungslösung sein, um für dieses Jahr irgendetwas Neues im High-End-Portfolio zu haben.

Mal gucken, wie sie sich diesmal noch rauswinden (es wird sie wohl keine Formel 1 Werbung mehr retten), oder ob Samsung doch zuschlägt, wenn es billig genug geworden ist.

 

[Cool Master]

Mal etwas anderes gruseliges:
AMD - Analysten erwarten Konkurs bis 2020

Und Täglich grüßt das Murmeltier.... Meine Analyse besagt das Gegenteil. Ohhh ich könnte ja Analyst werden