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

[pipip]

Quatsch. Auch nVidia würde es schon nutzen, wenn es jetzt sinnvoll wäre.

Alles klar Sontin
http://icpp2013.ens-lyon.fr/GPUs-ICPP.pdf

Hier in dem PDF gibt es eine ganz tolle Folie nämliche die Seite 23. Interessant ist, dass da von HMC gesprochen wird. Was ist daraus geworden ?
Wieso jetzt aufeinmal HBM ? Weil HBM eventuell ein von AMD mit Hynix entwickelte Speichertechnologie mit den Augenmerk auf GPUs ist ?

AMD hat Zugriff auf Gen1. Weißt du, ob NV auch Zugriff auf die Technologie hat, bzw hatte NV überhaupt die Wahl Gen1.0 zu nützten ? Wen Gen 2.0 besser verfügbar sei, weißt du bereits, wieviel davon NV bekommen wird ?
Du scheinst ja interne Daten zu haben, somit kannst du uns ja das alles erläutern.
Wäre schön blöd wenn AMD auch bei Gen 2.0 anfangs den Vortritt hat, weil man Mitentwickler ist und Erstkunde war. Ein komplettes Line Up mit HBM auf den Markt wäre dann durchaus interessant.
Könnte auch erklären, wieso NV eventuell Geld in ein besseres GDDR5 Si investiert, weil dann eventuell nur Big Pascal mit HBM kommen könnte. Da hoffe ich aber am Ende doch stark, dass GP104 doch auch mit mindestens 4-8GB HBM kommen würde.
Aber da du ja so gut bescheid weißt, kannst du ja alles was ich hinterfrage klar beantworten oder ?

 

[Mr.Seymour Buds]

Physikalische Simulationen sind ebenfalls komplex beim Zugriff auf den Speicher. Der Klassiker ist hier wahrscheinlich die N-body-Simulation, in der jeder Partikel mit jedem anderen wechselwirkt.

Also bei physikalischen Simulationen kann ich Dir sagen, dass deine Aussage falsch ist. Gerade bei CFD kommt es so gut wie immer zu Wechselwirkungen zwischen benachbarten Punkten. Und wo ist nun das Problem? Die GPU folgt dann einem intelligent programmierten Speicherzugriffsmuster und siehe da...die Performance stimmt!

 

[oldmanhunting]

Ich bin auch der Meinung, das NVidia mit HBM jetzt keine Titan X hätte bringen können und auch eine GTX 980Ti würde es ab nächsten Monat nicht geben. Somit ist es wurscht ob NVidia HBM jetzt nutzen darf oder nicht, weil die wollen zum jetzigen Zeitpunkt kein HBM, weil NVidia im Gegensatz zu AMD Heute Geld verdienen muß. Nächstes Jahr werden auch für NVidia mit 14/16 nm und HBM die Karten Neu gemischt.

Bin mir auch absolut sicher, das wenn man heute mit der Lisa T. Su über HBM spricht, dann bekommt die eine Migräne.

 

[Faust2011]

@Sontin: Du hast aber schon den Beitrag #114 hier gelesen, ja?

 

[foofoobar]

http://www.hotchips.org/wp-content/...Bandwidth-Kim-Hynix-Hot Chips HBM 2014 v7.pdf

Nehme hier den Wert Access Granularity und spiele etwas mit den Interface-Größen herum. Berücksichtige für die Vergleiche eventuell noch, dass momentan NVIDIA-GPUs 32-Byte "Cache-Lines" besitzen (eigentlich 128-Byte Cache-Lines bestehend aus vier 32-Byte Blöcken), während bei AMD-GPUs die Cache-Lines 64-Byte groß sind.



Beispiele aus typischen GPU-Anwendungen:
Die Rasterpipeline verursacht je nach Shader und Ausgangsdaten mittelmäßig chaotische Zugriffe, obwohl sie gut cacheable sind, sofern sie in die kleinen Caches (afaik worst case 8 Byte cacheplatz pro GPU-Thread bei AMD) der GPU passen.
Raytracing verursacht extrem chaotische Speicherzugriffe und ist schlecht cacheable.
Physikalische Simulationen verursachen auch oft mittelmäßige bis sehr chaotische Speicherzugriffe.

Wie paßt hier die breitere Anbindung von HBM ins Bild? Wenn der Bus n-mal breiter ist bekomme ich auch n-mal mehr Daten pro Takt durch. Ergo sollte die Latenz bis der Zugriff durch ist gleich bleiben? Bleibt also eine mögliche schlechtere Auslastung des Caches durch die schlechte Granularität übrig, die durch größere Caches für bestimmte Anwendungsfälle zu kompensieren wäre.

 

[Nai]

Wie paßt hier die breitere Anbindung von HBM ins Bild?

Ich meinte das eher so: Da man beide Technologien bzw deren Interface-Größen nicht direkt miteinander vergleichen kann, kann man etwas rumprobieren, wie sich beide Technologien bei unterschiedlichen Interface-Größen im schlimmsten Fall bei Random Access verhalten.

Also bei physikalischen Simulationen kann ich Dir sagen, dass deine Aussage falsch ist. Gerade bei CFD kommt es so gut wie immer zu Wechselwirkungen zwischen benachbarten Punkten. Und wo ist nun das Problem? Die GPU folgt dann einem intelligent programmierten Speicherzugriffsmuster und siehe da...die Performance stimmt!

Bei Gitterbasierten/Stencil-Methoden ist das Speicherzugriffsmuster kein Problem; diese Verhalten sich von den Speicherzugriffen her nicht viel anders als jeder Post-Processing-Filter. Bei Partikelbasierte-Methoden sind die Speicherzugriffe jedoch relativ problematisch, da die GPU hier zuerst ne BSP-Datenstruktur bauen und diese dann noch traversieren muss.

 

[Marius]

Ich kauf mir wohl erst unter 10nm wieder was Neues

 

[Faust2011]

10nm? Hmm... Du weißt, dass das inzwischen sehr relativ ist? Siehe hier

 

[Mr.Seymour Buds]

...BSP-Datenstruktur bauen und diese dann noch traversieren muss...

Für was steht BSP?

 

[Nai]

Für was steht BSP?

Binary Space Partitioning, obwohl ich mich oben vertippt habe und eigentlich nur Space-Partitioning meinte.

 

[foofoobar]

Ich meinte das eher so: Da man beide Technologien bzw deren Interface-Größen nicht direkt miteinander vergleichen kann, kann man etwas rumprobieren, wie sich beide Technologien bei unterschiedlichen Interface-Größen im schlimmsten Fall bei Random Access verhalten.

Bei Gitterbasierten/Stencil-Methoden ist das Speicherzugriffsmuster kein Problem; diese Verhalten sich von den Speicherzugriffen her nicht viel anders als jeder Post-Processing-Filter. Bei Partikelbasierte-Methoden sind die Speicherzugriffe jedoch relativ problematisch, da die GPU hier zuerst ne BSP-Datenstruktur bauen und diese dann noch traversieren muss.

Nach der Tabelle auf Seite 14 von http://www.hotchips.org/wp-content/...Bandwidth-Kim-Hynix-Hot Chips HBM 2014 v7.pdf scheinen die Zugriffslatenzen gegenüber DDR5 gleich zu bleiben, es gehen innerhalb des Zyklus mehr Daten durch. Alles andere würde mich auch wundern, bei den Latenzen von RAM hat sich seit Jahrzehnten nichts getan.

Mit welchen Datenmengen (gesamt und pro Blatt) hat man es bei typischen Anwendungen zu tun?

 

[Faust2011]

Was sind denn für Dich typische Anwendungen?

Ich denke, es kommt vor allem auf die Datenlokalität an. Je mehr Befehle in einer gegebenen Zeit auf derselben (kleinen) Datenmenge arbeiten, desto höher der Benefit, d.h. weniger ist man von der Speichergeschwindigkeit abhängig und desto eher nähert man sich den Peak-FLOPs an.

OpenCL abstrahiert hier das Memory-Model sehr anschaulich: global, local und register. Wenn mein Algorithmus primär auf register-Daten arbeitet, dann habe ich quasi ins Schwarze getroffen. Und da ist es dann egal, ob HBM oder GDDR(3/5)-Speicher verwendet wird.

 

[Mr.Seymour Buds]

Binary Space Partitioning, obwohl ich mich oben vertippt habe und eigentlich nur Space-Partitioning meinte.

Achso okay. Hättest Du Binärbaum geschrieben, wäre das besser erkennbar gewesen

 

[Daedal]

http://www.hotchips.org/wp-content/...Bandwidth-Kim-Hynix-Hot Chips HBM 2014 v7.pdf

Nehme hier den Wert Access Granularity und spiele etwas mit den Interface-Größen herum. Berücksichtige für die Vergleiche eventuell noch, dass momentan NVIDIA-GPUs 32-Byte "Cache-Lines" besitzen (eigentlich 128-Byte Cache-Lines bestehend aus vier 32-Byte Blöcken), während bei AMD-GPUs die Cache-Lines 64-Byte groß sind.



Beispiele aus typischen GPU-Anwendungen:
Die Rasterpipeline verursacht je nach Shader und Ausgangsdaten mittelmäßig chaotische Zugriffe, obwohl sie gut cacheable sind, sofern sie in die kleinen Caches (afaik worst case 8 Byte cacheplatz pro GPU-Thread bei AMD) der GPU passen.
Raytracing verursacht extrem chaotische Speicherzugriffe und ist schlecht cacheable.
Physikalische Simulationen verursachen auch oft mittelmäßige bis sehr chaotische Speicherzugriffe.

Nach der Tabelle auf Seite 14 von http://www.hotchips.org/wp-content/...Bandwidth-Kim-Hynix-Hot Chips HBM 2014 v7.pdf scheinen die Zugriffslatenzen gegenüber DDR5 gleich zu bleiben, es gehen innerhalb des Zyklus mehr Daten durch. Alles andere würde mich auch wundern, bei den Latenzen von RAM hat sich seit Jahrzehnten nichts getan.

Mit welchen Datenmengen (gesamt und pro Blatt) hat man es bei typischen Anwendungen zu tun?

Eben foofoobar hat da einen Punkt. Da frage ich mich wie du aus Cache Anbindungen auf den hinterlegten Speicher Rückschlüsse ziehst und dessen Random Access Werte. Und erst Recht zu der Behauptung kommst HBM hätte schlechtere Werte. Als Beweis führst du Cache Hierarchien von AMD und Nvidia bei GDDR5 Speicher an. Wie kommst du darauf, dass diese übertragbar sind?

 

[foofoobar]

Was sind denn für Dich typische Anwendungen?

Spiele im allgemeinen und die oben erwähnte Binary Space Partitioning insbesondere auch in Spielen.

 

[Nai]

Nach der Tabelle auf Seite 14 von http://www.hotchips.org/wp-content/u...02014 v7.pdf scheinen die Zugriffslatenzen gegenüber DDR5 gleich zu bleiben, es gehen innerhalb des Zyklus mehr Daten durch. Alles andere würde mich auch wundern, bei den Latenzen von RAM hat sich seit Jahrzehnten nichts getan.

Es geht hier mir auch nicht um die Latenzen (Latency Hiding auf der GPU funktioniert dank bis zu 64-Fachen "SMT" idr ganz gut), sondern um die Random-Access-Performance von modernen DRAM-Technologien, welche auch nicht besser wird. Denn ironischer Weise eignet sich moderner DRAM, obwohl er Random-Access im Namen hat, erstaunlich und konstant schlecht für Random-Access.

Mit welchen Datenmengen (gesamt und pro Blatt) hat man es bei typischen Anwendungen zu tun?

Wie beziehungsweise worauf bezogen meinst du das?

Da frage ich mich wie du aus Cache Anbindungen auf den hinterlegten Speicher Rückschlüsse ziehst und dessen Random Access Werte. Und erst Recht zu der Behauptung kommst HBM hätte schlechtere Werte.

GDDR5 benötigt 32-Byte Transaktionen um die Peak-Bandbreite zu erreichen; HBM 256-Byte-Transaktionen.
Wenn eine GPU beispielhaft mit 4-Byte Zugriffen komplett random auf GDDR5 zugreift, dann erreicht sie bei 0 \% Cache-Trefferrate und 32-Byte Cache-Lines (eine Transaktion pro Cache-Line) gerade einmal 1/8 der Peak-Bandbreite. Bei 64-Byte Cache-Lines (zwei Transaktionen pro Cache-Line) sind es schon 1/16. Bei den 256-Byte Transaktionen von HBM (und damit sehr wahrscheinlich mindestens 256 Byte-Cache-Lines) sind es bei 0\% Cache-Trefferrate nur noch 1/64 der Peak-Bandbreite. Da HBM bei typischen Anbindungen nicht ganz 4 oder 8 mal so schnell wie GDDR5 ist, eignet es sich folglich im "Worst-Case" deutlich schlechter für Random-Access als GDDR5. Aus dem Grund wird auch ein gutes funktionierendes Caching bei HBM sogar noch wichtiger damit die GPU die Bandbreite gut ausnutzen kann.

In diesem Forum?
Spiele!

Naja spätestens hier scheiden sich wohl die Geister, weil ich mich nicht so für Performance in Spielen interessiere.

 

[Daedal]

GDDR5 benötigt 32-Byte Transaktionen um die Peak-Bandbreite zu erreichen; HBM 256-Byte-Transaktionen.
Wenn eine GPU beispielhaft mit 4-Byte Zugriffen komplett random auf GDDR5 zugreift, dann erreicht sie bei 0 \% Cache-Trefferrate und 32-Byte Cache-Lines (eine Transaktion pro Cache-Line) gerade einmal 1/8 der Peak-Bandbreite. Bei 64-Byte Cache-Lines (zwei Transaktionen pro Cache-Line) sind es schon 1/16. Bei den 256-Byte Transaktionen von HBM (und damit sehr wahrscheinlich mindestens 256 Byte-Cache-Lines) sind es bei 0\% Cache-Trefferrate nur noch 1/64 der Peak-Bandbreite. Da HBM bei typischen Anbindungen nicht ganz 4 oder 8 mal so schnell wie GDDR5 ist, eignet es sich folglich im "Worst-Case" deutlich schlechter für Random-Access als GDDR5. Aus dem Grund wird auch ein gutes funktionierendes Caching bei HBM sogar noch wichtiger damit die GPU die Bandbreite gut ausnutzen kann.

Das ist ja alles ganz nett. Doch das ist nicht das wie HBM.spezifiziert ist. Wie wirkt sich diese Cachezugriffe aus, dass HBM Speicher je 256 KB Slice separat refresht werden kann?
Cache Latenzen ändern sich mit der Größe des verwendeten Caches.Darüber ist noch gar nichts bekannt bei verwendeten HBM Speicher. Deine Rechnung ist rein hypothetisch und IMHO auch nicht zutreffend.

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.

 

[Faust2011]

@Nai, es ist doch ganz interessant zu lesen, was Du hier ausführst. Ich würde mich gerne kurz einklinken:

Denn ironischer Weise eignet sich moderner DRAM, obwohl er Random-Access im Namen hat, erstaunlich und konstant schlecht für Random-Access.

Eigentlich ist das gar nicht ironisch. Ein Blick auf die Historie der Entwicklung des DRAMs sollte Klarheit bringen. Das RAM ist als Matrix organisiert und bevor Daten ausgelesen werden können, müssen diese adressiert werden. Das erfolgt zweistufig: zuerst RAS (also die Zeile), dann CAS (Spalte). Anschließend stehen die Daten bereit. Nun hat sich in der Vergangenheit herausgestellt, dass eigentlich oft aufeinanderfolgende Daten gelesen werden müssen. Dementsprechend hat man das optimiert, sodass der DRAM-Chip selbst die Adressen weiterzählt. Das sind die Verfahren à la BURST-Mode, EDO-RAM, ... . Und genau diese Erweiterung hälst Du nun dem DRAM vor, dass er eben nicht Random-Access sei. Das ist ironisch

GDDR5 benötigt 32-Byte Transaktionen um die Peak-Bandbreite zu erreichen; HBM 256-Byte-Transaktionen.

Mit dem oben gesagten meine ich nun auch zu verstehen, was Du mit diesen Transaktionen meinst. Bei GDDR5 ist das nichts anderes als die Herausgabe von maximal 32 Byte Daten nach Anlage der RAS-CAS (so wie ich oben geschrieben hatte). Bei HBM-Speicher ist das natürlich deutlich mehr, da hier vermutlich durch das Stacking des Speichers eine Adresse n Bytes in m Speicherfelder anspricht... dementsprechend hat man dann n*m Bytes gelesen (256 Bytes). Ist das korrekt soweit? Das Wörtchen Transaktion hat mich dabei in den letzten Tagen irritiert, da ich dabei immer Datenbank-Transaktionen (bzw. eine Folge von Schreib-/Lese-Zugriffen) im Hinterkopf hatte.

 

[Mr.Seymour Buds]

Also ich würde bei HBM nicht zu sehr in die Kristallkugel schauen. Oder gibt es von AMD Whitepaper, die bereits einen genauen, technischen Einblick in die Technologie geben? Bei Nvidia ist es mir bekannt, für Pascal und Stacked-DRAM gibt es sowas noch nicht.

 

[Nai]

Doch das ist nicht das wie HBM.spezifiziert ist.

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.

Wie wirkt sich diese Cachezugriffe aus, dass HBM Speicher je 256 KB Slice separat refresht werden kann? Cache Latenzen ändern sich mit der Größe des verwendeten Caches.

Sinn? Zusammenhang zu meinem Post?

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.

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

Eigentlich ist das gar nicht ironisch.

Dieser Ausdruck stammte eigentlich aus einer CUDA-Präsentation, die ich eigentlich Quoten wollte doch leider nicht mehr finde gerade

Ist das korrekt soweit? Das Wörtchen Transaktion hat mich dabei in den letzten Tagen irritiert, da ich dabei immer Datenbank-Transaktionen (bzw. eine Folge von Schreib-/Lese-Zugriffen) im Hinterkopf hatte.

Meines Kenntnissstandes ja. Ich verwendete den Begriff Transaktionen, weil NVIDIA den verwendet.