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

http://www.3dcenter.org/news/was-wi...tx-12-vsr-freesync-und-hdmi-20-bieten-koennen

guck am besten selbst, Toxic hatts eben schon gelinkt. Ganz gute Übersichts-Tabelle.
Ergänzung ()

@Toxic:
Naja, ich fande diese DX-Upgrades von z. B. 10 auf 10.1 nie sonderlich gravierend... Die Spiele müssen die API ja erst mal unterstützen.
Ich frage mich eher, ob man DX11-Spiele oder noch ältere auf DX12 modden kann, zwecks Leistungssteigerung.
Es wurden ja in der Vergangenheit einige Games z. B. von DX10 auf 11 gemodded, so wie Stalker Sigerous mod. DX 12 soll ja wesentlich performanter sein, das wäre ein riesiger Nutzen auch für ältere, aber leistungshungrige Games, so wie Stalker Lost Alpha.

Aber deine Frage mit dem Hardware-Level kann derzeit wohl noch niemand beantworten, ausser AMD selbst.
Interessant finde ich indes, dass selbst die HD7000er noch VSR-fähig werden sollen. Ob meine 7950 das noch packt? :freak: Aber sicher cool für FHD-Nutzer, da wirds gut gehen und viel bringen.
Aber andererseits vielleicht nicht so klug von AMD, die alten Karten rückwirkend atttraktiver zu machen. Die User sollen ja an sich die neuen Karten kaufen, statt die alten dank Upgrade noch länger nutzen zu können... Nun ja.
 
Zuletzt bearbeitet:
johnniedelta schrieb:
Aber deine Frage mit dem Hardwae-Level kann derzeit wohl noch niemand beantworten, ausser AMD selbst.

Jau, aber deshalb hatte ich ja geschrieben "mein Tipp". Tahiti und Pitcairn haben wegen GCN 1.0 jedenfalls keinerlei Hardware-Unterstützung für Dx12, deshalb ergibt es Sinn, diese rauszuwerfen und die neue Serie aus modifizierten Hawaii-, Tonga- und Bonair-Chips zu bringen, bestenfalls mit Dx12 Hardware-Support.
 
DrToxic schrieb:
Tahiti und Pitcairn haben wegen GCN 1.0 jedenfalls keinerlei Hardware-Unterstützung für Dx12

Was ist für Dich der HW-Support bei DX12? Ich würde es weniger auf die Features beziehen, denn auf die AsyncShaders (also Performance!). Und gerade da sind doch alle GCN-Karten prima aufgestellt, oder?
 
Ich frage mich eher, ob man DX11-Spiele oder noch ältere auf DX12 modden kann, zwecks Leistungssteigerung.
Es wurden ja in der Vergangenheit einige Games z. B. von DX10 auf 11 gemodded, so wie Stalker Sigerous mod. DX 12 soll ja wesentlich performanter sein, das wäre ein riesiger Nutzen auch für ältere, aber leistungshungrige Games, so wie Stalker Lost Alpha.

Natürlich kann man das .. aber im Grunde müsste man den kompletten Code-Teil der auf die dx12 Bibliotheken referenzieren soll (api calls) neu implementieren, da die Hälfte wieder komplett anders ist bzw. anders funktioniert und/oder umbenannt bzw. ersetzt wurde.

mfg,
Max
 
Faust2011 schrieb:
Was ist für Dich der HW-Support bei DX12?

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

Sofern die Angaben der Tabelle sich letztlich bestätigen lassen, bedeutet dies, daß auch die GCN 1.0 basierten AMD-Grafikchip keinen Hardware-Support für DirectX 12 erreichen. DirectX 12.0 in Hardware wird dann aber von den GCN 1.1 & 1.2 basierten Grafikchips erreicht, ob GCN 1.2 auch DirectX 12.1 schafft, ist noch nicht gänzlich klar (liegt aber nahe).
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!).
 
Zuletzt bearbeitet:
Armandex0 schrieb:
Für mein begrenztes Verständnis steht in dem zitierten Artikel eigentlich prinzipiell genau das, was Nai gesagt hatte...

[...]

Sofern HBM keine Möglichkeit der Speicherverschränkung hätte, wäre ja die ganze tolle Bandbreite plötzlich "für die Katz" und man müsste ständig für mehr Bandbreite -also das Interface am Grafikchip- sorgen wenn man dann doch mal mehr Speicher verbauen möchte?

Inwiefern steht da genau das was er gesagt hat?
Dies ist doch eindeutig Gegenteilig:
Nai schrieb:
weil sie dank des interleaved Layouts sowieso immer in etwa gleich belastet werden, bzw. bei unterschiedlicher Taktung immer der langsamste Kanal das gesamte Interface limitieren wurde.
Technische Beschreibung schrieb:
All DRAM timing restrictions are limited to a single memory module and not across memory modules.
Übersetzung: Alle DRAM Timing Beschränkungen sind limitiert auf ein einzelnes "memory module" und nicht übergreifend auf alle memory module (sollte hier nochmals die Definition von "memory module" aus der Quelle nötig sein, übersetze ich diese auch gerne)

Das tFAW timing verhindert zudem, dass mehr als 4 banks Interleaved angesprochen werden können in einem rotierenden Zugriff:
To make things worse, the DDR protocol puts another limitation for DRAM is tFAW timing. It restricts access of more than 4 banks in a rolling time window - tFAW.
->Damit ist nachgewiesen, dass Interleaving nicht über alle Speichermodule hinweg stattfindet. Damit ist schon die Grundlage überhaupt nicht gegeben zu behaupten deswegen können einzelne Speicher Segmente nicht unterschiedlich getaktet werden hinfällig.

Die weitere Annahme, dass HBM überhaupt Interleaving benötigt um nicht zu langsam zu sein ist fehlerhaft.
Auf dir Frage hin auf welches Weise sonst HBM optimiert wenn nicht mit Interleaving, habe ich auf die HBM Specs verwiesen die das beschreiben.
Was sollte bei HBM so konkret anders sein, dass das interleaved Layout nicht mehr benötigt wird?
Daedal schrieb:
Es nennt sich Dual Command Interface und ist in der selben Quelle beschrieben die du schon mehrfach selber verlinkt hast zu HBM.
Hier gerne auch die detailierte Beschreibung der relevanten Teile:
Aus der Hotchips Quelle:
http://www.hotchips.org/wp-content/...Bandwidth-Kim-Hynix-Hot Chips HBM 2014 v7.pdf
Seite 15: Row/column input through different pins

->Daraus folgen Änderungen im Zugriff auf den DRAM, wie folgt beschrieben auf Seite 16:
Es ermöglicht den bisher nicht möglichen Single Bank Refresh

->Daraus folgt die auf Seite 17 beschriebene Optimierungsmöglichkeit mit der Überschrift:
Command bus efficiency can be maximized
Darunter stehen die verwendeten Techniken: Dual Command & REF single bank

Die zweite verfügbare technische Quelle von der Memcon führt dies nun detailierter weiter:
http://www.memcon.com/pdfs/proceedings2014/NET104.pdf
Auf Seite 23 wird das Pseudo Channel Konzept vorgestellt und auf Seite 24 ist es grafisch dargestellt

->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.

495664


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:

495666


Weiterführend wird auf der Seite 25 das Limit für Interleaving im "Legacy Mode" nochmals aufgezeigt
Restriction of Gapless Bank Activation by tFAW(4 activate window)
=> tFAW=30ns > 4Bank*tRRD=16ns
=>Lower efficiency of Band Width
hbm_latenz_legacy-jpg.495670


Man sieht sehr gut wie Interleaving nach wie vor nicht die Lücken vollständig schließen kann um die Effizienz zu verbessern. Daher geht HBM einen Schritt weiter OHNE klassisches Interleaving nutzen zu müssen. Die Effizienz wird über die Pseudochannels ebenso erreicht wie bei Interleaving, mit dem Unterschied dass es nach 4 "windows" eben keine "Gap" (Lücke) gibt

Anders hier bei HBM, die Aufgrund des Pseudo-Channels keine Lücken mehr haben nach 4 "windows" sondern eine Vollständige lückenlose Auslastung des DRAMs:
hbm_latenz_pseudomode-jpg.495672


Aus diesem völlig anderen Aufbau des Speichersubsystems ergibt sich folgende Zusammenfassung meiner Ausführung:
Das Feature des Single Bank Refresh ist die Zentrale Änderung die HBM einige Eigenschaften verleihen die bisher nciht möglich waren. es basiert darauf, dass HBM deutlich mehr I/O Pins zur Verfügung hat (auch das steht am Anfang in beiden Quellen) und diese wiederum exklusiv für den Row oder Column Zugriff genutzt werden können (Auch das steht in selbigen beiden Quellen).

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.
http://en.wikipedia.org/wiki/High_Bandwidth_Memory
High Bandwidth Memory combines through-silicon vias (TSV) and microbumps to connect multiple (currently 4 to 8) dies of memory cell arrays on top of each other. The memory controller is contained on a separate die at the very bottom of the stack.

Und nein das hier habe nicht ich bei Wikipedia eingetragen:
The HBM DRAM is tightly coupled to the host compute die with a distributed interface. The interface is divided into independent channels. Each channel is completely independent of one another. Channels are not necessarily synchronous to each other. The HBM DRAM uses a wide-interface architecture to achieve high-speed, low-power operation. The HBM DRAM uses differential clock CK_t/CK_c. Commands are registered at the rising edge of CK_t, CK_c. Each channel interface maintains a 128 bit data bus operating at DDR data rates.

Da ich allerdings hier erlebt habe wie sogar seriöse technische Quellen schlecht geredet wurden habe ich das ganze etwas mehr ausgeführt. Der Fakt bleibt bestehen, dass bei HBM die Speicherbausteine je 128-bit Channel unterschiedlich konfigurierbar sind, was deren Verarbeitungsgeschwindigkeit betrifft. Dies ergibt noch weitere Eigenschaften, die ich jetzt aber nicht auch noch hier einbringen will, da es schon so recht komplex ist. Ich führe es gerne weiter aus wenn wir uns auf diese Basis einigen können.

Sorry für den langen post, doch es sind nun mal grundlegende Dinge die aufeinander aufbauen und Abhängigkeiten schaffen. Gerne lass ich mir von jemandem einen logischen Fehler in den Ausführungen zeigen, doch bitte dann auch mit einer Quelle die belastbar ist und auch das enthält was ausgeführt wird.
 

Anhänge

  • HBM_Latenz_Legacy.JPG
    HBM_Latenz_Legacy.JPG
    126,8 KB · Aufrufe: 633
  • HBM_Latenz_PseudoMode.JPG
    HBM_Latenz_PseudoMode.JPG
    143,6 KB · Aufrufe: 636
Zuletzt bearbeitet:
Und das ist jetzt die belastbare Quelle? Ich versteh das echt nicht mehr wo ihr eure Foren Etiquette her habt.....bin wohl zu alt für diese Diskussionen.

Einfach mal nen Einzeiler eingeworfen...
 
Ich werde hier nicht mehr im Detail auf den Post, den ich einmal wieder als ein Off-Topic-Ablenkungsmannöver betrachte, eingehen oder im Detail korrigieren. Es ging hier die Ganze Zeit schon darüber, wie die GPU die Last der Bandbreite durch Interleaving auf die 8 Speicherkanäle von HBM aufteilen kann. Du redest hier schon im zweiten Post in Folge über das Interleaving und die Ansteuerung innerhalb eines Speicherkanals.

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.)
Genau hier scheiterte es schon an deinem Verständnis, weil ich das gar nicht erklärte.

Die weitere Annahme, dass HBM überhaupt Interleaving benötigt um nicht zu langsam zu sein ist fehlerhaft.
Also noch einmal ein Beispiel für dich, was ich mit Interleaving bezüglich Kanälen meine:
Nehmen wir an wir würden unsere virtuellen Addressen linear auf physische Addressen abbilden. Dann wäre beispielhaft 0 bis 512 MiByte der 1. Kanal, 512 bis 1024 MiByte der 2. Kanal usw. . Nehmen wir an ein Objekt wäre 50 MiByte groß. Dann würde es wahrscheinlich komplett in einem der beiden Kanäle liegen. Beim Lesen dieses Objektes würde der andere Kanal unbenutzt bleiben, die Speicherbandbreite wäre dementsprechend halbiert. Deshalb trickst man, dass man die virtuellen Addressen interleaved auf die physischen abbildet: 0 bis 1 MiByte der erste Kanal, 1 bis 2 MiByte der zweite Kanal, 2 bis 3 MiByte der erste Kanal, 3 bis 4 MiByte der zweite Kanal usw. . Durch dieses Interleaving würde sich das Objekt nun halbe halbe in beiden Kanälen befinden, wodurch man auch die Bandbreite beider Kanäle ausnutzen könnte.
Diese Problematik hat mit dem, was du geschrieben hast *nichts* zu tun.
 
Zuletzt bearbeitet:
Erstaunlich, dass so eine Ente 500 Kommentare nach sich zieht...
Aber die Speicherdiskussion muss wohl nicht hier so ausgeweitet werden, es geht schliesslich um die neue GPU von AMD und nicht um eine Vertiefung zum Thema RAM.

Mal gespannt, wieviele solcher Bashing-"News" bis zum endgültigen Release seitens AMD hier noch auf CB kommen...
Vielleicht

"AMD kehrt für Fiji zu 40nm-Fertigung zurück"

als neuer Reisser im Ticker...:freak:
Ob Nvidia Schmiergeld zahlt, damit solche Artikel gepostet werden? Zuzutrauen wärs ihnen:mad:
 
Nun ich schlage vor, dass du einfach mal die richtigen Begriffe verwendest.

Was du beschreibst nennt sich nicht Interleaving, sondern Module-Threading:
Deshalb trickst man, dass man die virtuellen Addressen interleaved auf die physischen abbildet: 0 bis 1 MiByte der erste Kanal, 1 bis 2 MiByte der zweite Kanal, 2 bis 3 MiByte der erste Kanal, 3 bis 4 MiByte der zweite Kanal usw. . Durch dieses Interleaving würde sich das Objekt nun halbe halbe in beiden Kanälen befinden, wodurch man auch die Bandbreite beider Kanäle ausnutzen könnte.

B. Impact on DRAM Performance

The DDR3 column granularity is 64 Bytes, it means that minimum data accessed with DDR3 memory is 64 bytes through a read or write operation. But some classes of applications do not require such a high granularity and faces performance penalty. On top of this, DRAM timing parameters like tRRD, tFAW etc are also an overhead on the available bandwidth. These restrictions have tremendous effect on DQ bandwidth as shown in Table-II. This table shows the DQ bandwidth loss due to tRRD and tFAW restrictions for different speed grades of DDR3 using datasheet specified standard IDD7 patterns. The total losses are in the range of 25% to 50%.

All DRAM timing restrictions are limited to a single memory module and not across memory modules. So if memory module is split in two or more module channels on the same module substrate and accessed separately, then the access granularity can be reduced and timing restrictions can be minimized. This technique of dividing same memory module in two or more independent module channels is referred as module threading.

II. MODULE THREADING

Threading simply means the process of bringing concurrency into a system. In a memory system, concurrency is brought about by increasing the number of banks. There are many ways of adding banks into a memory system. One of these techniques is Module threading. It is an approach of allowing a single memory module to be separated into two or more independently accessible data groups, or threads. It uses standard DRAMs which are accessed in parallel by time multiplexed chip-select. Based on the access granularity requirement, system can use dual or quad threading. In dual threading, two memory channels on same module are used and in quad threading, four memory channels on same module are used. The quad and higher threading can be applied if enough RQ bandwidth is available for command scheduling. The module threading offers following advantages:-
Das wäre dir beim lesen meiner Quelle aufgefallen.

Nun, dann sollten wir das wohl hier beenden. Die Wissenslücke ist ja schlimmer als ich bisher annahm. Und es ist auch nach wie vor kein Wille zu erkennen auch nur einen Link zu posten zu diesen Wirr durcheinander geworfenen Bezeichnungen. Ich habs wenigstens probiert.
 
Zuletzt bearbeitet:
Nun ich schlage vor, dass du einfach mal die richtigen Begriffe verwendest.
Ich habe es allgemein als interleaved, interleaving, interleaved memory layout usw. bezeichnet, da es auf sehr vielen Ebenen stattfindet.
AMD programming guide bezeichnet es im Speziellen als channel interleaving/channel remapping (hab ich vorhin auch den Link gepostet)
Mein Bios unterscheidet zwischen channel interleaving und bank interleaving.
Also passt mein Begriff diesbezüglich.

Was du beschreibst nennt sich nicht Interleaving, sondern Module-Threading:
Hast du das überhaupt gelesen? Module-Threading ist wieder etwas anderes und entspricht in etwa dem Pseudo-Channel von oben. Wird dir klar, wenn du dir die Gantt-Diagramme aus dem Paper anschaust und mit denen oben vergleichst.

Die Wissenslücke ist ja schlimmer als ich bisher annahm.
:lol:
 
Zuletzt bearbeitet:
owai. :freaky:

Ich finds allgemein ganz interessant. Also rein subjektiv argmumentiert einer der beiden hier deutlich fundierter, wärnend Participant 2 viel eher Abschnitte zusammengoogled zu posten scheint ohne sich über die genauen Zusammenhänge im klaren zu sein (ggf fehlender Praxisbezug?). Kann täuschen da ich selbst nich vom Fach bin.

Aber nur weiter, ich finde es wie gesagt interessant.
 
Zuletzt bearbeitet:
Nai schrieb:
Ich habe es allgemein als interleaved, interleaving, interleaved memory layout usw. bezeichnet, da es auf sehr vielen Ebenen stattfindet.
Wie hilfreich :freak:

*Rant gelöscht*

Bezeichnend, dass gerade du dich mehrfach über die Bezeichnung Bank/Cell echauffiert hast in dem selben Thread - und dort verwenden die Quellen tatsächlich beide Begriffe für das selbe. Und hier ist das natürlich völlig einleuchtend nun - Das ist ja schon keine Nebelkerze mehr sondern eine ganze Nebelwand die du verbreitest.

Zudem auch noch deine falsche Definition nach wie vor nicht beweist was du behauptet hast. Das sollte dabei mal nciht untergehen. Wie HBM mit Dualcommand höhere Speiherauslastung erreicht habe ich dargelegt und auch warum das Interleaving dort keine Relevanz mehr hat. Das selbe gilt für Module-Threading, aus exakt den selben Gründen, da dies nichts anderes ist als eine andere Skalierungsebene.
Ergänzung ()

Nai schrieb:
Mein Bios unterscheidet zwischen channel interleaving und bank interleaving.
Also passt mein Begriff diesbezüglich.
Nein weil beides kein Module-Threading ist.
 
So wie ich das interpretiere, wird es dieses Modul threading ja gerade mit dem Ziel der Speicherverschränkung (das ist, was ich unter interleaving verstehe) geben.
Klar dass jedes Modul seinen eigenen Beschränkungen unterliegt (wie bisher auch). Trotzdem wird man auf interleaving eben nicht verzichten.
 
Bezeichnend, dass gerade du dich mehrfach über die Bezeichnung Bank/Cell echauffiert hast in dem selben Thread - und dort verwenden die Quellen tatsächlich beide Begriffe für das selbe.
Single-Cell-Refresh ergibt keinen Sinn, weil eben nicht eine einzelne Speicherzelle sondern eine einzelne Speicherbank refresht wird; der Begriff war semantisch falsch. Interleaving beschreibt allgemein eine bestimmte zyklische Aufteilungstechnik die auf verschiedenen Ebenen innerhalb des Speichers angewendet wird, um dessen Parallelität (Channels/Bänke) überhaupt gut auszunutzen zu können. Deshalb war der allgemeine Begriff nicht semantisch falsch. Ob man jetzt irgendwann einen etwas anderen Begriff als den Fachbegriff oder eine Umschreibung des Fachbegriffs verwendet ist m.E. egal, so lange die Semantik gewahrt bleibt.

Zudem auch noch deine falsche Definition nach wie vor nicht beweist was du behauptet hast.
Ok, erklären wir einmal die Quelle, die Daedel so out of Context gepostet hat: Beim Modulthreading wird ein Dimm in zwei (oder mehr) "Module" aufgeteilt. Die Module teilen sich die Ansteuerungsleitungen des DIMMs. Um eins der Module beim Ansteuern auszuwählen wird das Chip-Select Signal des DIMMs verwendet. Jedes Modul erhält die Hälfte der Datenleitungen des DIMMs. Durch das Aufteilen des Dimms in zwei Module wird zudem die Anzahl der Bänke verdoppelt und die "Breite" einer jeden Bank, also wie viel Daten pro Takt die Bank liefern kann, halbiert. Die beiden Module verhalten sich abgesehen davon, dass sie sich die Addressleitungen teilen, wie unabhängige Kanäle. Dadurch werden folgende Effekte erzielt:
-Die Zahl der Bänke verdoppelt sich, man kann mehr parallele Speicherzugriffe durchführen
-Die Timingrestriktionen tRC, tRRD and tFAW werden gelockert, wodurch man mehr Bandbreite ausnutzen kann
-Die Transaktionsgröße halbiert sich mit der Breite von 64 Byte auf 32 Byte der over-fetch wird bei chaotischen Zugriffen reduziert
Damit verhält sich das ganze so ähnlich wie die obigen Pseudo-Kanäle.

Das hat so ungefähr mal wieder gar nichts damit mit dem Interleaving bezüglich Channels zu tun, was ich in meinem letzten Post beschrieben habe. Als ein lustiger nebeneffekt gilt, dass man dieses Modul-Threading nur gut ausnutzen kann, wenn man zusätzlich (zum Channel und Bank Interlaving) den Speicher interleaved auf die Module abbildet. Wie man sieht, wird Interleaving auf sehr vielen Ebenen benötigt.
 
Zuletzt bearbeitet:
Armandex0 schrieb:
Trotzdem wird man auf interleaving eben nicht verzichten.
Natürlich wird man es - man braucht weder Interleaving noch Module-Threading. HBM nutzt Dual Command in Verbindung mit Single Bank Refresh.

Das habe ich beschrieben und das bleibt gültig auch wenn man jetzt anfängt die Begriffe zu verschieben. Schau dir einfach die beiden Diagramme an und zeige mir wo HBM bei der Auslastung noch Interleaving nutzen kann mit Pseudo-Channels. Was soll man denn da Interleaven?

Die Funktion hat Nai doch auch beschrieben:
Nai schrieb:
Beim Lesen dieses Objektes würde der andere Kanal unbenutzt bleiben, die Speicherbandbreite wäre dementsprechend halbiert. Deshalb trickst man,
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.

Nichts was Nai schreibt ist falsch (ausser den Begriffen) doch ist ebenso auch nicht relevant in der gesamten Diskussion zu den Eigenschaften von HBM. HBM kann dies oder jenes nicht wegen Interleaving ist das selbe als wenn man behauptet auf der Strasse könne man nicht laufen, weil im Fluss Wasser fließt. Hier fehlt einfach der logische Zusammenhang.
Ergänzung ()

Nai schrieb:
Single-Cell-Refresh ergibt keinen Sinn, weil eben nicht eine einzelne Speicherzelle sondern eine einzelne Speicherbank refresht wird; der Begriff war semantisch falsch.

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?

Wahrscheinlich meinst du dann doch irgendwann Intels Hyperthreading, das ja auch eine Art von Interleaving ist. Oder AMDs CMT das dies ja auch macht...

Dass es für jeden Slice einen eigenen Memorycontroller mit 128-bit Dual-Channel gibt der ganz alleine seinen 256 MB-Speicherbereich verwaltet ist dir dabei bisher mehrfach entgangen obwohl ich es geschrieben habe. 8 Channels pro GB HBM die nicht Interleaven auf irgendeinem Level mit den anderen 3 GB bei 4 GB HBM Ausbau.
 
Zuletzt bearbeitet: (Zitat zu Bezugbeitrag zugefügt)
Zurück
Oben