News Next-Gen-GPUs: Grafikkarten überspringen 20 nm für 14/16 nm

Ich mag Nvidia-Terminologien nicht. Bei denen muss sich alles immer super-wichtig anhören.

Und dann präsentieren sie auf ihren Konferenzen stolz Holzattrappen... mogeln bei technischen Daten... aber das gehört jetzt nicht hierher. Sorry

Nai schrieb:

Ich stütze mich hier auf den Wert Access-Granularity:
http://www.hotchips.org/wp-content/...Bandwidth-Kim-Hynix-Hot Chips HBM 2014 v7.pdf
Wenn ich etwas falsch verstanden habe, bitte mich korrigieren.

[...]

Verstehe ich nicht, was du mir damit sagen möchtest; klingt größtenteils ziemlich widersprüchlich für mich. Quellen dafür?

Zum Vergrößern anklicken....

Du redest von Overhead bei 4K Zugriffen weil die Pakete 256 KB Größe haben. Zum einen ist die Zugriffsart in keiner Weise GPU Typisch und zum anderen gibt es bei GDDR5 Speicherzugriffen Wavefronts. Alle Speicherkanäle werden zeitgleich aktualisiert im Takt des Speichers. Alle Caches sind demnach gleich getaktet. Bei HBM ist dies nicht der Fall. Jeder Speicherkanal hat eine eigene Taktung und kann direkt refresht werden wenn nötig ohne den gesamten Speicher aktualisieren zu müssen. Das kann GDDR 5 nicht - alleine dadurch wird die Overheadrechnung falsch.

Zudem kommt, dass du dir die Daten nicht ca. ausrechnen musst anhand der Access Granularity, sondern dir die ganzen fertigen Zahlen in der selben Präsentation auf der hotchips anschauen kannst - bitte die Daten auf Seite 14 anschauen um die richtigen Zufgriffslatenzen im Vergleich DDR3/GDDR5/HBM zu nutzen.

Weiterführend zeigt Seite 15 das Dual Cmd Interface und die Auswirkungen, ebenso wie das Single Bank Refresh und programmierbare tRAS benutzt werden um eben die Bus Effizienz zu erhöhen. Diese Techniken kannst du nicht mit so einer Rechnung wie du sie halbgar aufgestellt hast vergleichen - Sorry doch das war nix fundiertes.

Mit HBM kann 500 MB Speicherbereich mit 4K Zugriffen gefüttert werden, mit den ACE, während zeitgleich der restliche Speicher völlig anders takten kann und alles aufnimmt, das parallel und in grossen Paketen durch muss...der Queue kann sehr lang werden und die Effizienz steigern ohne von kleinen Paketen unterbrochen zu werden. Die Fähigkeit von HBM die einzelnen Speicher Slices je 64-bit Anbindung unterschiedlich zu takten und dies auch dynamisch zu ändern, sowohl bei Takt als auch Speichergröße die verwendet wird, allein erfordert ein völlig anderes Caching als das was du beschrieben hast.

Zum Vergrößern anklicken....

Hier fehlt mir unter anderem noch eine Erklärung, was du hier mit den ACEs meinst. Hast du Quellen dafür? Außerdem was ist hier an meiner Betrachtung mit dem Caching und Cache-Lines falsch? (die ich eigentlich primär für GDDR5 eingebaut habe, um realistisch zu bleiben und GDDR5 nicht zu sehr zu verbessern). Wie wird deiner Meinung nach HBM gecacht?

Du redest von Overhead bei 4K Zugriffen weil die Pakete 256 KB Größe haben.

Zum Vergrößern anklicken....

Da stimmt etwas mit den Einheiten nicht.

zum einen ist die Zugriffsart in keiner Weise GPU Typisch

Zum Vergrößern anklicken....

Es gibt GPU-typische Algorithmen wo die Zugriffe sehr chaotisch sind zum Beispiel beim Raytracing; oder alternativ wo das Workingset so groß ist, dass es dir den Cache thrasht.

zum anderen gibt es bei GDDR5 Speicherzugriffen Wavefronts

Zum Vergrößern anklicken....

Meinst du hier das "Coalescing"? Das bringt dir bei chaotischen Speicherzugriffen mit relativ großem Stride nichts bis wenig.

Alle Caches sind demnach gleich getaktet. Bei HBM ist dies nicht der Fall. Jeder Speicherkanal hat eine eigene Taktung und kann direkt refresht werden wenn nötig ohne den gesamten Speicher aktualisieren zu müssen. Das kann GDDR 5 nicht - alleine dadurch wird die Overheadrechnung falsch.

Zum Vergrößern anklicken....

Der Refresh kostet gemäß meinen Quellen nur 5 bis 10 der Peak-Bandbreite bei GDDR5.

Zudem kommt, dass du dir die Daten nicht ca. ausrechnen musst anhand der Access Granularity, sondern dir die ganzen fertigen Zahlen in der selben Präsentation auf der hotchips anschauen kannst - bitte die Daten auf Seite 14 anschauen um die richtigen Zufgriffslatenzen im Vergleich DDR3/GDDR5/HBM zu nutzen. Weiterführend zeigt Seite 15 das Dual Cmd Interface und die Auswirkungen, ebenso wie das Single Bank Refresh und programmierbare tRAS benutzt werden um eben die Bus Effizienz zu erhöhen.

Zum Vergrößern anklicken....

Es ging hier nicht um die Latenzen sondern um die Speicherbandbreite. Da man bei GDDR5 bei 32-Byte Transaktionen trotz Refresh etc. in etwa 80 bis 90 \% der Peak-Bandbreite nutzen kann, kann HBM in meiner (vereinfachten) Rechnung auch nur maximal um circa 20 \% zu schlecht wegkommen. Ich nehme aber an, dass es auch bei HBM effekte auftreten werden, die dazu führen, dass man nur ein paar Prozent weniger als die Peak-Bandbreite erreichen können wird.

Diese Techniken kannst du nicht mit so einer Rechnung wie du sie halbgar aufgestellt hast vergleichen - Sorry doch das war nix fundiertes.

Zum Vergrößern anklicken....

So eine Rechnung ist natürlich nur eine (vereinfache) Überschlagsrechnung die die Problematik aufzeigen sollte, bei welcher man nicht alle Faktoren berücksichtigt. Und diese Rechnung kommt eben im Worst-Case auf eine deutlich schlechtere Performance von HBM, unabhängig davon ob HBM jetzt 10 oder 20 Prozent schneller ist. Wenn du es schaffst eine solche bessere Rechnung aufzustellen, dann tue das bitte. Ich fände es sehr interessant, wenn du zu einem anderen Ergebnis kommen würdest, weil ich dann wüsste, was ich "falsch" gemacht hätte.

Es geht um Datendurchsatz und Latenzen. Und du behauptet etwas unausgegorenes das keinerlei praktische Bedeutung hat. Mit HBM wäre die GTX 970 nicht so ein Problemfall auf dem siebten Speicherkanal, weil zwei Speicherbereiche den selben L2 Cache nutzen müssen.

Raytracing...was soll das für eine Relevanz für eine Consumer GPU haben? Und was ist da ein typischer Workload bitte. Cinebench? Reden wir hier schon wieder über etwas das keiner benutzt ausser ein Paar Studios, die dafür weder eine Radeon noch eine Geforce GPU benutzen?

Offensichtlich hast du die HBM Quellen nur halbherzig gelesen und solltest keine falschen Cache Architekturen als gegeben annehmen.

Du kannst nur Überschlagen, wenn du alle Faktoren berücksichtigst. Das hast du nicht..im Gegenteil du hast dir irgendeine Zahl raus gepickt und eine falsche Annahme aufgestellt...verkauf das bitte nicht als Fakt.

Und nur weil du eine Phantasierechnung aufstellst..muss ich nicht auch eine aufstellen...ich warte bis AMD die neue Architektur und die Implementation veröffentlicht und beschäftige mich mit Fakten.

Nai & Daedal, könntet Ihr beiden Euch auf eine gemeinsame Sprache einigen? Das würde vielleicht bei Euren Missverständnissen helfen und es auch außenstehenden etwas einfacher machen, Euch zu folgen. Es ist ja nicht ganz uninteressant.

@Nai: bitte nicht mehr von Transaktionen sprechen. Dieses Wort ist mMn deplatziert. Es bezeichnet einfach die kleinste Menge an Daten, die man aus einem Speicherfeld auslesen kann.

@Daedal: Wavefront? Das Hardware-Scheduling einer Menge von Threads, die zu einem Zeitpunkt auf den Shadern laufen sollen, nennt AMD Wavefront. Ist es das, was Du meinst? Dasselbe nennt Nvidia übrigens Warp.

Korrekt Faust. Bei HBM ist das völlig anders, da eben nicht der gesamte Speicher zeitgleich bei jedem Takt refresht werden muss. Das gesamte Scheduling wird anders. Daher sind auch solche Rechnungen nicht anwendbar.

Ein weiterer Vorteil von HBM ist ja auch dass am Speicheranbindung wertvolles SI gespart werden kann welches dann für Shader verwendet werden kann oder der Chip kleiner wird. Nur weil der hochgelobt "Technologieschuppen" NV mit dem vielen Geld dass sie mit überteuerten Mittelklasse Karten verdienen nicht in der Lage war HCM zum Laufen zu bringen muss man jetzt nicht die Gesamte Technologie schlechtreden und behaupten es würde keinen Vorteil gegenüber GDDR5 geben. Ich hoffe dass NV nächstes Jahr nur sehr wenige HBM Chips bekommt.

Witzigerweise ist AMD als einziger sowohl im HMC als auch im HBM Konsortium. Auch bei HMC ist AMD Mitentwickler. Nvidia ist bisher in keinem der beiden Konsortien und Intel auch nicht. Intel ist lediglich beteiligt an Micron die es entwickeln. Bei beiden Speichertechnologien ist AMD mit federführend.

Zu HMC: Hier werden Micron und Intel als Entwickler der Technologie genannt. Kein Wort dabei zu AMD.

Also bitte:
http://www.hybridmemorycube.org/about.html
Das Konsortium hat so ziemlich jeden als Mitglied der irgendwie in der Industrie vertreten ist. Sogar SK Hynix als HBM Erfinder ist dort mit drin. Allerdings finde ich AMD da jetzt auch nicht und kann mich auf Anhieb nicht erinnern wo ich kürzlich die Meldung zu AMDs Beitritt gelesen hatte. Ich schau aber ob ich es finde.
Edit: Habe es gefunden
http://www.eetimes.com/document.asp?doc_id=1280684

The HMC group consists of more than 100 companies including Micron’s rivals Samsung and SK Hynix as well as potential customers such as AMD, Cray, Fujitsu, IBM, Marvell, ST Microelectronics and Xilinx. Missing are big potential users including Intel and Nvidia.

Zum Vergrößern anklicken....

Und witzigerweise ist Intel als Entwickler kein Mitglied des Konsortiums - denn dann müssten sie ja alles an IP teilen. So können sie als Entwickler eigene Änderungen proprietär machen und nicht an das Konsortium weiter geben - als Mitglied muss man das sowohl bei HBM als auch bei HMC wenn der JEDEC Standard zertifiziert wird. Nvidia ist noch nicht mal dem HBM Konsortium beigetreten, doch dies dürfte ja mit der Ankündigung HBM zu nutzen bald erfolgen. Also zumindest ist mir keine Pressemitteilung bisher aufgefallen, jedoch wird diese erwartet - wohl aber kaum im Vorfeld vom AMDs Launch von HBM basierenden GPUs.

AMD setzt nun ab der 300er Serie auf HBM und auch Nvidia springt ab Pascal nächstes Jahr auf den HBM-Zug auf. Was soll nun HMC? Ist das für die ferne Zukunft? Ich hätte es eher als Konkurrent zu HBM eingeschätzt... jedoch sollte inzwischen das Rennen zugunsten von HBM gelaufen sein.

HMC hat andere Vorteile für Server Umgebungen und wird erst interessant bei 3D Stacking auf den GPU/CPU Die. HBM wollte zuerst mit 2.5D Technik auf Interposer kommen, was Nvidia nicht machen wollte. Dies ist verständlich, denn Nvidia hat noch nie Interposer verwendet und hat auch keinerlei Erfahrung oder IP für die Interconnects untereinander...deshalb sind sie auch dabei NVlink zu etablieren. Dieser Technologische Vorsprung aus der Serverumgebung macht es AMD möglich vorhandene etablierte IP zu nutzen für Interposer-Konfigurationen wie die R395X2. Das wird keine normale Dual-GPU mit separaten Speicherpools.

HMC hingegen wird erst noch zur Konkurrenz werden oder eben in bestimmten Nischen seine Vorteile ausspielen, sobald 3D Stacking interessant wird.

Faust2011 schrieb:

@Nai: bitte nicht mehr von Transaktionen sprechen. Dieses Wort ist mMn deplatziert. Es bezeichnet einfach die kleinste Menge an Daten, die man aus einem Speicherfeld auslesen kann.

Zum Vergrößern anklicken....

Faust2011, Nai hat da aber den richtigen Begriff verwendet. Im Zusammenhang mit CUDA spricht auch Nvidia (und ich^^) von Transaktion(en) oder im englischen eben von Transaction(s).

Global memory access of 32, 64, or 128-bit words by a half-warp of threads can result in as few as one (or two) transaction(s) if certain access requirements are met

Zum Vergrößern anklicken....

Ich glaube das ist der springende Punkt, wenn ich alles richtig verstanden habe. Es geht um die Wortlänge, mit der lesend auf den Global Memory (Device Memory) zugegriffen wird. Im Idealfall ist das ein 128-bit langer Zugriff (coalesced -> threads lesen nicht 'out of sequence' + nicht 'misaligned', also Zugriff an einer Adresse, mit einem ganzzahligen Teiler von 128-bit -> richtige Startadresse). Nur wenn man das so macht, bekommt man in CUDA die volle Bandbreite hin (strided Zugriff mit einem Offset > 1 verringern die effektive Bandbreite auch drastisch (bis auf unter 10%), aber: wenn man den Offset geschickt wählt, wird es besser).

Es gibt übrigens auch fette Unterschiede zwischen den ComputeCapabilities (also den GPU Gen`s), den die Cache Hierarchie wurde seit 1.0 stark umgebaut (zb Shared Memory ~ so schnell wie Register). Ab CC 1.2 können auch kleinere Transactions genutzt werden (32 B, 64 B, 128 B).

Wenn ich was testen soll, immer her mit dem Code Sitze hier an CC 3.5 und nvcc aus CUDA 7.0.

Und zu HBM, ich würde hier wirklich keine vorschnellen "Rechnungen" machen. Und die Behauptung, dass HBM in einem wie auch immer gearteten "worst-case" Szenario langsamer als GDDR5 ist, muss ich auch erstmal anzweifeln. Bereits vom Aufbau und Anschluss würde ich eher das Gegenteil behaupten, dass HBM GDDR5 eigentlich immer überlegen sein wird.

Ach ja und eines noch: Es heisst nicht umsonst GPGPU. Die heute aktuellen Aufbauten (Maxwell) sind auch verdammt gut für Probleme geeignet, die eben nicht nur thread-parallel ausgeführt werden ("SIMD" / "SIMT"). Auch branching läuft mit den Caches und dem GPU Aufbau verhältnismäßig "gut" (klar CPUs sind hier besser, wenn der Programmablauf nur noch *wenig* parallelen Anteil hat, kommt halt auf das genaue Problem an. Oder man nimmt dafür gleich die Vektorinstruktionen in der CPU).

Irgendwo hat auch wer geschrieben, dass es Unified Memory noch nicht gibt. Nur mal so, das gibt es bereits und nvcc kann mit entsprechenden Programmcodes bereits umgehen.

Egal ob nun R9 oder Pascal, so viel schneller Speicher auf dem Chip wird bei GPUs den fettesten Performancesprung der letzten Jahre bringen. Da bin ich mir sicher.

Faust2011

HBM und HCM verfolgen die selben Ziele. HBM und HCM unterscheiden sich aber soviel ich verstanden habe bei ihrem Fokus.
HCM sollte den Flaschenhals lösen, der aktuell mit DDR gegeben ist. Theoretisch bräuchte doch ein X86 Core mit sagen wir 16GB HMC keinen DDR3 oder DDR4 Speicher mehr oder (zumindestens bei Consumer und Notebooks werden zum Beispiel von den wenigsten aufgeschraubt)?
HBM wurde von Hynix in Zusammenhang für GPUs entwickelt. Das würde auch der Grund sein, wieso NV von HCM zu HBM umgeschwenkt ist, weil HBM eben für GPU Anwendungen besser geeignet ist.

Es wäre nicht unrealistisch, wenn AMD eines Tages sowohl HMC als auch HBM nützten könnte. Intel kann mit seinen MIC auf HCM zurückgreifen, weil MIC ja hauptsächlich aus X86 besteht und meist auch die bessere Fertigung besitzt und somit Power Comsuption kompensiert wird, da ist wohl mehr Datendurchsatz das wichtigste.

Ich bilde es mir zu mindestens ein, das mal so gelesen zu haben. Auf google sollte sich also was finden lassen dazu...

Das würde aber auch erklären wieso Hynix im Konsortium von HMC dabei ist (um auch HMC herstellen zu können). AMD wollte eventuell einen speziellen 3D Speicher für Grafikkarten und Hynix hat sich somit mit AMD dies Aufgabe angenommen. Für Hynix wäre das ja eine Win-Situation, weil sie dann sämtliche AMD GPUs mit Speicher beliefern könnten und da jetzt NV dazugekommen ist, haben sie quasi den Checkpoint.

http://www.extremetech.com/computin...-between-wide-io-hbm-and-hybrid-memory-cube/2

HBM is explicitly designed for graphics, but it’s a specialized application of Wide I/O 2.

Zum Vergrößern anklicken....

http://www.extremetech.com/computin...es-between-wide-io-hbm-and-hybrid-memory-cube

HMC is designed to emphasize massive amounts of bandwidth at higher power consumption and cost than Wide I/O 2

Zum Vergrößern anklicken....

HMC scheint auch etwas mehr Banbreite zu haben, aber mehr zu verbrauchen und ist teurer als HBM.
Das könnte schon der Grund sein, wieso NV von HMC auf HBM umgestiegen ist.

DDR hat im Vergleich bis auf seine "Flexibilität" fast nur Nachteile. Höher Verbrauch, mehr Die-Fläche, wesentlich geringerer Durchsatz.

Auch ist HMC scheinbar PCB based und HMC ist mit dem Chip auf einem Interposer.

Danke für die Übersicht und die Links. Die waren mir nicht alle bekannt.

Danke Euch allen für die Infos zu HBM/HMC. Muss das erstmal sacken lassen...

Stacked Memory scheint ja der Trend der Zukunft zu sein, nachdem man auch bei SSDs 3d-RAM einsetzt.

Faust2011 schrieb:

Ich mag Nvidia-Terminologien nicht. Bei denen muss sich alles immer super-wichtig anhören.

Zum Vergrößern anklicken....

Transaktion ist in diesem Kontext schon das richtige Wort.

foofoobar schrieb:

Transaktion ist in diesem Kontext schon das richtige Wort.

Zum Vergrößern anklicken....

Dann erklär mir mal bitte wie es Nvidia meint und wie sich das zu Datenbank-Transaktionen (wo sich das Wort vermutlich herleitet) abgrenzt.

Faust2011,

Kapital 5.3.2 in der aktuellen Dokumentation:

Global Memory

Global memory resides in device memory and device memory is accessed via 32-, 64-, or 128-byte memory transactions. These memory transactions must be naturally aligned: Only the 32-, 64-, or 128-byte segments of device memory that are aligned to their size (i.e., whose first address is a multiple of their size) can be read or written by memory transactions.

Zum Vergrößern anklicken....

@ Daedel: Was du schreibst ergibt m.E. keinen Sinn, sei es weil mir das nötige Fachwissen fehlt oder weil es tatsächlich sinnlos ist. Da du bislang immer auf Fragen abwertend, abweisend oder ausweichend reagiert hast, nehme ich an, dass letzteres der Fall ist und du das was du schreibst selbst nicht erklären kannst. Da so m.E. auch die gesamte Diskussion sinnlos ist, ignoriere ich dich in Zukunft.

@ Terminologie: Es gibt leider im (GP)-GPU-Bereich extrem viele unterschiedliche Terminologien, wie zum Beispiel die von Intel, AMD, NVIDIA bzw. CUDA, OpenCL, OpenGL, DirectX, C++-Amp uvm. . Diese Terminologien zeichnen sich dadurch aus, dass sie mehr oder weniger aus Prinzip für jedes Konzept oder jede Begebenheit einen neuen Begriff einführen. Zum Beispiel, das was in CUDA Thread-Block heißt, heißt in OpenCL und OpenGL Work-Group und in DirectX Thread-Group. Deshalb gibt es dort bei Begrifflichkeiten oft kein richtig oder falsch, was wiederum zu einem gewissen Chaos führt. Ich versuche mich allerdings immer an die NVIDIA-Terminologie zu halten, damit das was ich schreibe wenigstens innerlich konsistent ist.

@ Selbstverbesserung, da meine Berechnung der Transaktionsgröße wahrscheinlich doch falsch war: Der Wert der "Access-Granularity" berechnet sich in den Slides aus "IO*Prefetch pro IO". Dieser Wert gibt gemäß der Formel an, wie viel Daten der DRAM-Chip pro Zugriffszyklus übertragen kann. Die "Access-Granularity" entspricht deshalb nur dem was ich mit "Transaktionsgröße" meinte, sofern es nur einen Kanal pro Speicher-Chip wie beim GDDR5 gibt. Es gibt bei HBM aber acht Kanäle pro Chip, welche sich von einander unabhängig ansteuern lassen. Dementsprechend berechnet sich die Transaktionsgröße beim HBM aus "IO*Prefetch pro IO / Zahl der Kanäle". Also ist die Transaktionsgröße bei HBM weiterhin wie beim GDDR5 32 Byte. Ich hoffe das passt nun so .

Interessanterweise gibt es andere Quellen die unter der Access-Granularity das verstehen, was ich mit Transaktionsgröße meinte, wodurch das ganze leider ein Missverständnis meinerseits wegen unterschiedlichen Begriffsdefinitionen gewesen ist.