Nvidia-GPU-Roadmap auf der GTC: Volta mit Stacked DRAM - schon ab 2016?

[ruyven_macaran]

Ähm, du redest von allem, nur nicht von HSA.

Doch, genau davon rede ich. Und auch du wiedersprichst mir in deinen endlosen Schwärmereien nicht ein einziges mal.
HSA soll auf Basis von einer GPU-Technologie (OpenCL) kommen und auf Basis von einer von zwei CPU-Architekturen (x86 oder ARM). Alles weitere, was auf Softwareebene gemacht wird, um diese optimal zu nutzen, ist für Nvidia erst einmal egal. Die können nur die Hardwareseite stellen und da werden sie, auch ganz ohne bei HSA mitzumachen, Chips mit ARM-Anteil und massiven gpGPU-Fähigkeiten bringen, vereinheitlichen Adressraum haben sie afaik heute schon. Die zweite, von AMD bis vor kurzem als einzige propagandierte Variante, HSA on x86+GPU könnte Nvidia dagegen auch mit HSA-Mitgliedschaft nicht liefern.

 

[Skysnake]

Genau das ist doch der Knackpunkt. Man will gar kein OpenCL oder sonst was im Optimalfall. Du schreibst deinen Code in EINER Hochsprache, komplett abstrahiert von der Hardware, vielleicht noch ein paar Pragmas, wo parallelisiert werden kann, öhnlich openMP, und der Rest wird vom Compiler und der Hardware übernommen.

Also insbesondere, ob es jetzt z.B. besser ist, die SSE/AVX Erweiterung der CPU zu verwenden, oder eben die GPU für eine Berechnung ein zu setzen. Das ist ein gewaltiger Unterschied oder nicht?

Bei OpenCL musst du ja expliziet noch angeben, wo was zu laufen hat.

 

[ruyven_macaran]

Der Unterschied zwischen dem, was du schreibst, und dem, mit dem die Hardware angesprochen wird, ist Sache des Compilers. Nicht Sache des Hardwareentwicklers. Mir wäre nicht bekannt, dass HSA eine neue Hardwareschnittstelle vorsieht, es ist eben nur ein Compiler geplant, der automatisch auf OpenCL-Befehle zurückgreift, wann immer es sinnvoll ist. Die Hardwarehersteller (d.h.: Eigentlich fast nur AMD) kümmern sich nur darum, dass dies möglichst oft sinnvoll sein kann.

 

[Skysnake]

Genau das ist doch der Knackpunkt

Wenn es der Compiler erledigen soll, brauchst du Wissen über die Architektur. Es soll aber eben ohne Wissen über die Architektur gehen. Insbesondere soll im Optimalfall ja auch alter Code davon profitieren. Deswegen wird man wohl auch auf eine LLVM (auf den ARM Cores vielleicht laufend?) und Hardwareunterstützung setzen.

Wie gesagt, HSA ist ziemlich ambitioniert und könnte sich zu einem richtigen Gamechanger entwickeln, wenn es denn funktioniert.

 

[Ob4ru|3r]

Bitte nicht x64 sagen Das ist einfach nen breitere Speicheradresse und das wars dann auch schon.

Bei x64 denken die Leute automatisch an x86(_64) womit das aber rein gar nichts zu tun hat. nVidia wird auch in Zukunft kein x86 verwenden dürfen. Weder in Hardware noch emuliert...

Sry, Macht der Gewohnheit .... aber nicht nur bei mir: 64-bitige Register werden auch von Devs gerne mal als x64 bezeichnet, hab ich so zuletzt auf mehreren Folien zu ARM-Designs oder auf Webseiten gesehen.

Ram wird heute meist nur relativ wenig gekühlt. Stacked RAM ist da wirklich ziemlich unproblematisch. Vor allem wenn Sie ja eh direkt gut gekühlt werden.

Mir auch klar, ich mache mir da auch mehr Sorgen um die GPU selber, die bei nVidia gerne mal zu Hochöfen mutieren. Diese Hitzeproduzenten zusätzlich "einzufliesen" erscheint mir nicht allzu klug, so muss man halt ein wenig drosseln, wegen der zusätzliche Wärmeisolation durch das schiere Mehr an Material.

 

[Skysnake]

der dram kommt daneben, nicht drauf

 

[Ob4ru|3r]

Dachte schon. xD

 

[Skysnake]

Auch wenn er drauf kommt, ist es jetzt kein Beinbruch. Durch die TSVs hat man einen sehr guten Kontakt. Zudem wird man zwischen die DIEs wohl eine Verfüllung einbringen. Die Papers, die ich mal dazu gesehen hatten, kamen im Endeffekt zu dem Ergebnis, das RAM auf Logik nicht wirklich ein Problem ist. Erst wenn man Logik auf Logik packt, wirds zu einem massiven Problem.

 

[ruyven_macaran]

Wenn das aufwendige Speicherinterface entfällt, sollte es zudem möglich sein, mit Logik auf RAM zu arbeiten. PCIe- und Output-Kontakte müsste man eigentlich auch auf einem kleinen Bereich am Rand unterbringen können, da braucht man nicht mehr die große Unterseite des Chips.

 

[Skysnake]

Wat? Ich versteh grad nur Bahnhof

 

[ruyven_macaran]

Wenn man wirklich GPU und Speicherchips aufeinander (statt nebeneinander auf einen Interposer) packen wollte, dann macht das keinerlei Aussage darüber, auf welche Seite des Paketes das Substrat kommt. Wenn die GPU aus Kühlungsgründen direkt zugänglich bleiben soll, dürfte es kein Problem sein, den RAM einfach zwischen GPU-DIE und Substrat zu positionieren.

 

[Skysnake]

Immer noch Bahnhof.

 

[ruyven_macaran]

Wenn ich das richtig verstanden habe, wurde hier befürchtet, dass RAM auf der GPU die Kühlung zu stark beeinträchtigen könnte.
Wie du schon gesagt hast, kommt er a) danben und hätte b) nur wenig Auswirkung auf die Wärmeabfuhr, aber selbst wenn man ihn zukunft draufpackt und das bißchen (bei stacked DRAM ja auch ein bißchen mehr) zum Problem werden würde, ließe es sich ganz einfach umgehen: RAM unter die GPU -> Kühler hat genau den gleichen Kontakt, wie heute.

 

[Skysnake]

AH JETZT versteh ich was du meinst

Aber da muss ich dich leider enttäuschen. Das geht sooo einfach nicht.

Nicht ohne Grund hat man heute Flip-Chip designs. Du müsstest den kompletten IO-Kram durch den DRAM-Stack durch packen. Das willst du eigentlich nicht wirklich. Der ist ja schon genug durch die normale Anbindung des DRAM-Stacks durchlöchert.

Rein Prinzipiell ist es aber natürlich nicht unmöglich, wobei ich es für nicht geringe einfach/zweckdientlich halte.

 

[ruyven_macaran]

Der normale I/O Kram ist halt ziemlich rudimentär. PCI-E, 3-4 digitale Display-Ausgänge und nen multi-GPU-Connector - das sind vermutlich keine 100 pins. Bei derartigen High-End-GPUs könntest du die sogar per wire bonds an den Kanten anbinden, der Platzverbrauch durch den Stack wäre minimal.

 

[Skysnake]

nein, das kannste knicken. Vor allem mit PCI-E 3.0 kannst du keine wirebonds mehr nehmen. Da würde schlicht nichts mehr ankommen