nVidia - Volta - 2017/2018 (GV100, Xavier, ...) [Archiv] - Seite 3

HOT

2017-05-10, 22:43:13

Meine Güte, haben die die Einheiten aufgebläht. Für Desktop-Volta schmeissen die sicher den ganzen Int/Tensor/FP64-Blödsinn wieder raus, das wird man bei gleicher Shaderzahl auf 600mm² kommen - passt doch für GV102 bei GP102-TDP. Bringt also schon was der Prozess.
GV104 wird sicher auch ca. 420-450mm² groß und könnte ähnlich viele Shader haben wie GP102. Man spart ca. 30% Leistungsaufnahme und etwas Fläche ggü. Pascal. Hoffentlich gibts auch architektonische Verbesserungen wie FP16-Support und echtes async-Compute und nicht nur Pascal-Featureset.

AMD wird da nichts vergleichbares haben, dafür aber sicher einen "klassichen" HPC-Vega-Chip denke ich in 2018, der Hawaii ablösen wird. Bislang ist über so ein Produkt zwar noch nichts geleakt, aber es muss sowas geben.

PHuV

2017-05-10, 22:49:38

Pascal ist also ein gekürzter Volta. Sieht nach dem selben Frontend aus nur die SMs wurden erweitert und Caches angepasst.
Nein:

https://www.computerbase.de/2017-05/nvidia-volta-gv100/
Nvidia hat den Aufbau der Streaming Multiprocessors auf Volta verändert

Und auch zur generellen Architektur gibt es Informationen. Demnach hat Nvidia die Streaming Multiprocessors gegenüber Maxwell und Pascal massiv umgebaut und für Deep-Learning-Berechnungen optimiert. Dadurch soll bei Volta auch die Energieeffizienz pro SM um 50 Prozent gegenüber Pascal ansteigen.

Leonidas, das ist an sich sehr einfach.

Du darfst den Daten und den clk Takt einfach nicht in Beziehung setzen. ;)
:

@Leonidas

Was hast Du eigentlich als Ausbildung oder Beruf gelernt? Nichts mit IT, vermute ich mal. Ich weiß nicht, wie das heute ist, aber FlipFlops, Nand,Nor, Xor-Schaltungen usw. habe ich in den 80er auf dem technischen Gymnasium gehabt, und Ende 80er im Informatikstudium, wo wir beide Male mit Transistoren und Baukästen solche einfachen Schaltungen nachbauen mußten. Da versteht man schnell die Grundlagen, wenn man so ein Ding einfach mal selbst konstruiert. Es gibt sogar einige Programme, die das simulieren:

Logic Simulator (http://www.tetzl.de/java_logic_simulator_de.html)
Logic Gate Simulator (https://academo.org/demos/logic-gate-simulator/)

Ansonsten was zum Lesen:
7 Schaltwerke (http://www.netzmafia.de/skripten/digitaltechnik/flipflop.html)

scully1234

2017-05-10, 22:51:39

Na ja schau dir Mal die Details an. Thread/Warps bleiben gleich da hat man sich mehr erhofft.

https://devblogs.nvidia.com/parallelforall/inside-volta/

Da steht auch noch so einiges mehr an Infos zur Überarbeitung

Mitunter wird man 6 Monate vor Release so oder so noch nicht mit der Tür ins Haus fallen.

Kaffeesatz lesen kann man auch beim Wahrsager

Nein:

steht doch auch in dem Dev Blog
GV102" wird dann gewiss auf den Tensor-Krempel verzichten und dafür besser zu fertigen sein.

MfG,
Raff

Falls es da per Gameworks ne Einbindung gibt, könnten die Spieledesigner für simple Physik FP16 Hairworks,Waveworks Trallala ,vielleicht auch von dem neuen Featureset profitieren?
Und Gerendert wird mit 32bit

iuno

2017-05-10, 23:11:32

Das ganze 12nm zu nennen wir echt langsam lächerlich.... keine 26Mio/mm²
Ich mach mir den Node widde widde wie er mir gefällt.
Wie gesagt: ich glaube dass TSMC einfach angepisst war, dass GF/Samsung aktuell die kleinere Zahl haben ;D

Complicated

2017-05-10, 23:44:14

Troyan

2017-05-11, 00:53:10

GV100 in voller Pracht:
http://hothardware.com/ContentImages/NewsItem/41005/content/big_tesla-v100-board.jpg.ashx?maxwidth=1170&maxheight=1170
http://hothardware.com/news/nvidia-debuts-tesla-v100-volta-gpu-dgx-1-at-gdc-2017

Jupiter

2017-05-11, 01:00:13

Was würde dies für den Nachfolgechip des GP102 bedeuten?

20 Teraflops in FP32 bei zirka 2Ghz? Tesla P100 hatte eine ähnliche Taktrate wie jetzt der Tesla V100.

Troyan

2017-05-11, 01:10:38

50% bessere Perf/W. Ergo sollten 20TFLOPs möglich sein.

Jupiter

2017-05-11, 01:31:47

Das könnte knapp für Wildlands in UHD bei 60fps reichen. Mal sehen wie sehr die gesteigerte Bandbreite in hohen Auflösungen hilft.

Außerdem bin ich auf Videospiele gespannt, welche 1080p/30fps mit 20 Teraflops anstreben. Das könnte CGI-Qualität erreichen. Konsolen werden spätestens hier anfangen, Videospiele technisch extrem zu limitieren. Assets müssen in einer viel geringeren Qualität als nötig produziert werden, generelle Beleuchtung wird einfacher weil sich sonst der Stil zu sehr unterscheidet etc.

Fetza

2017-05-11, 03:21:47

Außerdem bin ich auf Videospiele gespannt, welche 1080p/30fps mit 20 Teraflops anstreben. Das könnte CGI-Qualität erreichen. Konsolen werden spätestens hier anfangen, Videospiele technisch extrem zu limitieren. Assets müssen in einer viel geringeren Qualität als nötig produziert werden, generelle Beleuchtung wird einfacher weil sich sonst der Stil zu sehr unterscheidet etc.

Genau deswegen wird es solche Spiele auch langfristig nicht geben. ;)

Leonidas

2017-05-11, 06:52:22

Leonidas, das ist an sich sehr einfach.

Du darfst den Daten und den clk Takt einfach nicht in Beziehung setzen. ;)

...

Soweit alles klar oder?

...

Man halbiert also zuerst auf der Senderseite den internen Takt, packt ihn dann als CLK Signal auf die CLK Leitung und verdoppelt ihn dann wieder auf der Empfängerseite.

...

Soweit verstanden, oder gibt es noch Fragen?

Hab es sogar halbwegs verstanden. Danke dafür!

Zur Sicherheit: Dies bedeutet, das auf der GeForce GTX 1080 der Speichertakt in den Datenleitungen tatsächlich bei 2500 MHz liegt, korrekt? Aber in den jeweiligen Interfaces sind es dann doch wieder 5000 MHz?

Dies wäre relevant wegen dem Strombedarf der ganzen Sache. GDDR-Interfaces ziehen bei steigendem Takt gut mehr Strom und sind auch (im Gegensatz zu HBM) nicht wirklich stromsparend.

@Leonidas

Was hast Du eigentlich als Ausbildung oder Beruf gelernt? Nichts mit IT, vermute ich mal.

Gar nichts in diese Richtung (kaufmännische Ausbildung). Reinrassiger Autodidakt in allen IT-Fragen.

Loeschzwerg

2017-05-11, 07:24:10

Ganz schöner Klotz der GV100.

Scheint als wäre das "Mezzanine" Board 1:1 identisch zum Vorgänger mit GP100, also dürfte die GV100 pinkompatibel sein? Zumindest sofern das gezeigte Board kein Mockup ist.

y33H@

2017-05-11, 07:34:33

Pin- und Kühler-kompatibel sagt NV.

Loeschzwerg

2017-05-11, 07:42:59

KK, dann vermute ich selbiges auch bei GV102/GV104 usw. => Wir können uns jetzt schon ausmalen wie das Platinendesign sein wird

Skysnake

2017-05-11, 08:21:43

Ein Hammer Teil. Wundert mich, dass Nvidia so auf Monsterchips setzt. Aber viel Fläche sparen sie nicht zum 16nm im Vergleich. ca. +30% mehr Transistoren mit ca. 30% mehr Fläche.
Hier eine schöne Tabelle von heise: https://www.heise.de/newsticker/meldung/GTC-2017-Nvidia-stellt-Riesen-GPU-Volta-mit-5120-Kernen-und-16-GByte-HBM2-vor-3710317.html

Die Tensor Units überraschen jetzt doch etwas, nachdem Nvidias CEO diese letztes Jahr noch klein geredet hat bei Google - siehe: http://www.pcworld.com/article/3076740/data-center/nvidia-chief-downplays-challenge-from-googles-ai-chip.html

Es scheint als ob Nvidia hier den Spagat versucht und Google mit seinen TMUs auf Abstand halten will. Für die Consumer Produkte ist hier allerdings wenig sinnvolles dabei. Ich bin gespannt wie AMD sich hier im Markt positionieren wird. Bisher scheint Vega auf Gaming fokusiert zu sein - Volta offensichtlich ganz auf HPC mit diesem Monsterchip. Wobei man wirkich gespannt sein darf was davon in den Consumer Produkten etwas neues bringt. Aber Hut ab vor der Innovation mit den integrierten Tensor Units.
Naja, der potenzielle Markt für Inference ist auch zich mal größer als der fürs Training. Aktuell braucht man sehr viel Training, aber an sich wird das nicht so stark wachsen wie der Markt für Inference. Denn Inference willste in jedem Smartphone in jeder Überwachungskamera und überhaupt quasi überall machen.

Hab es sogar halbwegs verstanden. Danke dafür!

Zur Sicherheit: Dies bedeutet, das auf der GeForce GTX 1080 der Speichertakt in den Datenleitungen tatsächlich bei 2500 MHz liegt, korrekt? Aber in den jeweiligen Interfaces sind es dann doch wieder 5000 MHz?

Ja genau.

Dies wäre relevant wegen dem Strombedarf der ganzen Sache. GDDR-Interfaces ziehen bei steigendem Takt gut mehr Strom und sind auch (im Gegensatz zu HBM) nicht wirklich stromsparend.

Naja, du hast 32 Datenleitungen die ja mit vollem Takt laufen vs 1 Clk Leitung. Also soooo viel bringt es jetzt nicht direkt beim Energiesparen. Vor allem musst du die Clk ja auch noch hochkonvertieren und anpassen. Genau das ist aber interessant, denn wenn du eh schon Sachen fürs Upscaling machen musst, dann kannste das CLK Signal auch gleich anpassen/tunen. Und das kann deutlich die erreichbaren Datenraten steigern.

Leonidas

2017-05-11, 09:06:54

Klevapalis

2017-05-11, 09:34:46

Die Tensor Units überraschen jetzt doch etwas, nachdem Nvidias CEO diese letztes Jahr noch klein geredet hat bei Google - siehe: http://www.pcworld.com/article/3076740/data-center/nvidia-chief-downplays-challenge-from-googles-ai-chip.html
Sehe da kein klein reden. Es gibt eben Unterschiede zwischen Training und Anwendung und dies hat er hier kurz erläutert. Dass man von Seiten NVIDIA beide Seiten abbilden will, ist nun wirklich kein Wunder.

Wundert mich immer wieder, was dem Huang immer so alles unterstellt wird. Da wird nicht nur das Haar in der Suppe gesucht, sondern das Haar selbst platziert und dann drauf gezeigt :ugly:

Pirx

2017-05-11, 09:38:32

ich sage nur Holzattrappe

Klevapalis

2017-05-11, 09:40:57

ich sage nur Holzattrappe
Bei 99,99999% der Präsentationen völlig normal mit einem MockUp zu arbeiten.

Wenn man sich darüber echauffiert zeigt das nur, dass man keine Ahnung hat.

Loeschzwerg

2017-05-11, 09:52:47

ich sage nur Holzattrappe

Ich sag nur Comdex '99 ;)

Michalito

2017-05-11, 10:29:37

Wenn man sich darüber echauffiert zeigt das nur, dass man keine Ahnung hat.

Na, wenn du es daran festmachst, ob man Ahnung hat oder nicht.:freak:
Dann, erinnere ich mal kutz an Dieter Nuhrs Motto: Einfach...

scully1234

2017-05-11, 10:53:25

Ich sag nur Comdex '99 ;)

Da hat er das Kreuz Ass doch glatt mit dem schelle Wenzel gestochen:tongue:

ndrs

2017-05-11, 11:01:46

Äh, kurz zur Klarstellung.
Widerspricht sich
Dies bedeutet, das auf der GeForce GTX 1080 der Speichertakt in den Datenleitungen tatsächlich bei 2500 MHz liegt, korrekt? Aber in den jeweiligen Interfaces sind es dann doch wieder 5000 MHz?
Ja genau.

nicht mit folgendem?

Naja, du hast 32 Datenleitungen die ja mit vollem Takt laufen vs 1 Clk Leitung.

Iruwen

2017-05-11, 11:04:31

Ganz schöner Klotz der GV100.

Wenn man den Gegner nicht mit Leistung erschlagen kann, dann zumindest mit Masse :tongue:

Nakai

2017-05-11, 11:31:22

Kriton

2017-05-11, 11:47:14

Für den Fall, dass ich nicht der Einzige war, der sich bzgl. Inference ratlos gesehen hat:

https://www.quora.com/What-is-the-difference-between-inference-and-learning

Klevapalis

2017-05-11, 11:53:58

AffenJack

2017-05-11, 12:03:19

Complicated

2017-05-11, 12:15:21

Sehe da kein klein reden.
Dann nimm mal die grüne Brille ab. Die Überschrift des verlinkten Artikels heisst nicht umsonst:
"Nvidia chief downplays challenge from Google’s hyper-specialized AI chi"
Oder hier:
https://www.hpcwire.com/2017/04/10/nvidia-responds-google-tpu-benchmarking/
Responding in a blog post published earlier today (https://blogs.nvidia.com/blog/2017/04/10/ai-drives-rise-accelerated-computing-datacenter/), Nvidia is choosing to frame the recent TPU results not as a potential competitive threat, but as as a clear sign of the ascendancy of accelerated computing.

Bei 99,99999% der Präsentationen von Nvidia völlig normal mit einem MockUp zu arbeiten.
Ich habe das mal für dich korrigiert.

HOT

2017-05-11, 12:17:51

Bin auf jeden Fall sehr gespannt auf die Gamingkarten, laut Blog wurde die Energieeffizienz der Shader um 50% gesteigert, d.h. gegenüber Pascal/Maxwell kann da ein richtiger Sprung in Sachen Shaderleistung kommen.

Ich glaub, dass diese Aussage einfach falsch rüberkam. Es gibt ne Folie, die typische Compute-Workloads mit diesem Volta-Aufbau (also NICHT Gaming) ziegt, die ziemlich genau bei den 50% mehr rauskommt. Diese Aussage gilt also nur exakt für dieses Produkt ggü. dem GP100, nicht für die Gaming-Voltas. Da sowohl die Ausführungseinheiten der Gaming-Pascals anders aussehen als die des GP100 als auch die Ausführungseinheiten der GV10x anders aussehen als die des GV100 ist da einfach kein Rückschluss in irgendeiner Form zulässig. Die 50% sollte man sich komplett aus dem Kopf schlagen, wenn man über Gamingkarten spricht.

Interessant wird sein, ob NV die Tensor-Cores abgespeckt auch im Consumer-Volta einsetzt oder ob es ganz klassisch bei den FP32-Cores bleibt, um Platz einzusparen. Wenn wird man die Tensor-Cores sicherlich nicht 1:1 verbauen, wie in GV100, sondern eher 1:4 oder sowas. NV müsste da also komplett eigene Gaming-SMs für entwickeln - wenn es nicht bei klassichem FP32 bleibt. Sollte letzteres zutreffen ist Volta = Pascal + 20-30% mehr Power, sonst nix - ich glaub da aber nicht dran, FP16 wird in Zukunft wichtig und ich denke Volta wird dem Rechnung tragen.

Mal ne Verständnisfrage zum GV100, die dedizierte Int-Einheit dient doch in erster Linie zum Stromsparen oder?

Troyan

2017-05-11, 12:33:34

Dann nimm mal die grüne Brille ab. Die Überschrift des verlinkten Artikels heisst nicht umsonst:
"Nvidia chief downplays challenge from Google’s hyper-specialized AI chi"
Oder hier:
https://www.hpcwire.com/2017/04/10/nvidia-responds-google-tpu-benchmarking/

Ich habe das mal für dich korrigiert.

Höre doch endlich auf deinen Unsinn hier dauernd zu verbreiten. Der Blog-Post war eine Antwort auf die Ergebnisse von Google, die TPU mit Kepler verglichen haben und dann zum Schluss kamen, dass deren eigener Prozessor für Inference besser geeignet wäre.

Fakt ist, dass Pascal die erste Generation von nVidia war, die explizit auch für Inference dedizierte Hardware hat. Und das hat Huang so ebenfalls auch im Conference Call mitgeteilt.

Du hast am Ende nicht verstanden, um was es Huang überhaupt ging.

mksn7

2017-05-11, 12:43:27

Man wird sehen, wieviel von den SM umbauten auch tatsächlich in den Gamerchips ankommen. Dopelt soviele scheduler, aber nur single issue, und nur half rate units, wird wohl auch für gaming Sinn machen. Macht Scheduling nochmal einfacher, und senkt die beochbachtbaren Latenzen. Noch ein Schritt Richtung GCN...

Aber vielleicht trotzdem wieder 128 units pro SM, bei gleichem shared memory und Registern pro SM, also effektiv halb soviel.

Die Tensorunits sind aber sicher nicht drin. Höhere Energieeffizienz kommt vielleicht auch einfach nur durch mehr Fläche/Einheiten zustande. Ein ~40% Vorteil bei DGEMM zeigt den wirklichen FLOP Vorteil, die Zahlen die mit Boosttakt berechnet werden sind da sinnlos.

Nakai

2017-05-11, 12:46:18

Kann man die Tensorcores auch für Grafikberechnungen mit FP16 benutzen? Man sollte ja bei Volta schon 2x FP16 im Consumermarkt erwarten, wenn man gegen Vega da anstinken will. Man könnte da vielleicht die Anzahl reduzieren und damit FP16 berechnen oder macht das keinen Sinn und man wird 2xFp16 anders implementieren (oder sogar weglassen)?

Die Tensor-Cores führen FP16 FMA auf 4 4x4 Blöcke aus. Da es Mixed-Precision-Ausführung ist, also FP16 mit FP32 gemischt, ist es imo für viele Workloads nicht perfekt geeignet. Für Spiele wird das Ding nicht sonderlich auslastbar sein.

GV100 ist eine GPGPU mit dedizierten Ausführungseinheiten für Matrix-Multiplikation (welche gut für Deep Learning ausgelegt ist). Der Wettlauf auf die höchste DL-TOPs-Zahl ist ja ganz nett. Mir geht es nicht weit genug. Mir fehlt die Reduktion auf einen skalaren Wert für einzelne Neuronen.

Der Gamer-Volta wird definitiv ohne oder mit kleineren Tensor-Cores daherkommen.

scully1234

2017-05-11, 13:10:42

Der Gamer-Volta wird definitiv ohne oder mit kleineren Tensor-Cores daherkommen.

Was soviel heißt das du dir nicht gänzlich sicher bist , das Hairworks,Waveworks nicht doch eines guten Tages über die Tensor Cores angesprochen werden

Vielleicht überarbeitet man das Design ja soweit das es GeForce in die Hände spielt

Klevapalis

2017-05-11, 13:30:07

Dann nimm mal die grüne Brille ab. Die Überschrift des verlinkten Artikels heisst nicht umsonst:
"Nvidia chief downplays challenge from Google’s hyper-specialized AI chi"
Ist ja auch völlig korrekt. Die Google TPU war nie gegen einen NVIDIA-Karte gestellt und vice-versa, erst jetzt mit GV100 gibt es da eine Konkurrenz.

NVIDIA taugte nix für Interference, Googles TPU taugt nix für Learning. Verstanden?

Zu behaupten Huang hätte da irgendwas klein geredet ist Unfug. Er stellt nur die Fakten klar, dass es zwischen den zwei Produkten keine Konkurrenz gibt - unterschiedliche Anwendungsfälle. Manche hatten das eben verglichen.

Ich habe das mal für dich korrigiert.
Bullshit, troll woanders :P

Kann deinen Hass auf NVIDIA sehr gut verstehen, aber mach das doch bitte im AMD-Forum. Hier nervt das nur.

Ich glaub, dass diese Aussage einfach falsch rüberkam. Es gibt ne Folie, die typische Compute-Workloads mit diesem Volta-Aufbau (also NICHT Gaming) ziegt, die ziemlich genau bei den 50% mehr rauskommt. Diese Aussage gilt also nur exakt für dieses Produkt ggü. dem GP100, nicht für die Gaming-Voltas
Die Aussage aus dem NVIDIA Blog:
New Streaming Multiprocessor (SM) Architecture Optimized for Deep Learning Volta features a major new redesign of the SM processor architecture that is at the center of the GPU. The new Volta SM is 50% more energy efficient than the previous generation Pascal design, enabling major boosts in FP32 and FP64 performance in the same power envelope.
Warum sollte man 50% (Steigerung) in Perf/Watt nicht mit ins Gaming-Design übernehmen? Das ergibt keinen Sinn.

Für Gaming wird man das Tensorzeug rauswerfen und sicherlich auch FP64. Dazu noch NVLink und die anderen HPC-Features und fertig ist GV102.

Hübie

2017-05-11, 13:31:42

Für gewöhnlich designt niemand einen Chip für border cases. Obwohl man diese Tensor-Cores ggf. für so etwas wie OIT einsetzen könnte - zumindest stelle ich mir so etwas vor. Wir werden aber definitiv wieder einen Sprung in der Effizienz sehen. Stellt euch mal vor was alles im sub 150-Watt Bereich ginge. ;) Das ist ja der Massenmarkt.

Ich sehe auch gerade nicht wo Vega da einen Angriffsvektor hätte. Aber das kann sich ja ändern wenn harte Fakten geliefert werden. Was Raja wohl gestern dachte?

Klevapalis

2017-05-11, 13:37:37

Was Raja wohl gestern dachte?
"Scheiße." :cool:

pilzsammler2002

2017-05-11, 13:41:16

Hmmm die 50% effizienz muss man erstmal durch alle Anwendungsfälle haben... Ich bin da wie bei AMD (wo es ja auch kritisiert wird) vorsichtig :freak:

scully1234

2017-05-11, 13:49:33

Was Raja wohl gestern dachte?

We need more drums

Für gewöhnlich designt niemand einen Chip für border cases. ?

Ist die GeForce Sparte nicht derzeit das beste Pferd im Stall?

Nach nem 815er Monster Chip und damals schon angepasste Pascal GeForce, würde ich da niemals nie sagen

robbitop

2017-05-11, 13:59:52

Mit GV100 wird AMD sowieso nicht konkurrieren. Die 100 Serie wird immer mehr zum reinrassigen Computeprodukt (auch wenn es noch GPU "Gene" trägt).
Das kann und wird AMD sich nicht leisten können. Sie konsolidieren ihren Produktmix gem. Pareto.

Skysnake

2017-05-11, 14:06:30

Hört sich für mich ungewöhnlich an. Das würde bedeuten, das bei 16Gbps GDDR6 dann das Speicherinterfaces des Grafikchips mit 8000 MHz arbeitet. Auf einem nicht wirklich kleinem Stück des Siliziums. Dachte, da gäbe es dann längst Probleme mit so hohen Taktraten?!
Ja, die Speicherinterfaces laufen mit 8 GHz wenn du 16Gbs übertragen willst.
ABER! Es läuft nicht alles damit. es laufen "nur" auf TX Seite die Ausgansbuffer sowie die letzte Stufe des Serializers damit und auf der RX Seite eben die Sampling Latches, der clk Multiplier und dann noch die erste Stufe des Desirializers.

Äh, kurz zur Klarstellung.
Widerspricht sich

nicht mit folgendem?
Ähm ja danke -.-

Die Frequenz der Signale auf den Datenleitungen ist IMMER! gleich der halben Datenrate, so lange man binäre Signale übertragt.

Das Clk. Signal kann relativ willkürlich gewählt werden, wobei es sich lohnt ein Verhältnis von 2^n:1 zu wählen, weil man dann mit ganz simplen Clock Multipliern bzw. Dividern auskommt. Alles andere, wird ziemlich schnell sehr ekelhaft, wie bei PCI-E 3.0, wo dieses schema aufgebrochen wird und NUR Kopfschmerzen bereitet...

Für gewöhnlich designt niemand einen Chip für border cases. Obwohl man diese Tensor-Cores ggf. für so etwas wie OIT einsetzen könnte - zumindest stelle ich mir so etwas vor. Wir werden aber definitiv wieder einen Sprung in der Effizienz sehen. Stellt euch mal vor was alles im sub 150-Watt Bereich ginge. ;) Das ist ja der Massenmarkt.

Ich sehe auch gerade nicht wo Vega da einen Angriffsvektor hätte. Aber das kann sich ja ändern wenn harte Fakten geliefert werden. Was Raja wohl gestern dachte?

Naja, schaut euch doch mal an, wieviele Tensor Cores man hat ;)

Das Verhältnis liegt bei der 16 fachen SMX Anzahl ;) Ein Schelm wer sich dabei etwas denkt....

grauenvoll

2017-05-11, 14:13:20

Warum sollte man 50% (Steigerung) in Perf/Watt nicht mit ins Gaming-Design übernehmen? Das ergibt keinen Sinn.

Präsentationsfolien sind geduldig, da wird oft mit großen Zahlen jongliert. AMD gibt bei Vega 400% Effizienzsteigerung(Perf/W) an. In einem hochoptimierten Szenario ist das sicher auch möglich. Out-of-the-box erreicht man solche Werte meist nicht.

HOT

2017-05-11, 14:18:23

[...]

Die Aussage aus dem NVIDIA Blog:

Warum sollte man 50% (Steigerung) in Perf/Watt nicht mit ins Gaming-Design übernehmen? Das ergibt keinen Sinn.

Für Gaming wird man das Tensorzeug rauswerfen und sicherlich auch FP64. Dazu noch NVLink und die anderen HPC-Features und fertig ist GV102.

Der Satz bezieht sich glasklar auf den ersten. Das hat nichts mit Gaming-Volta zu tun. Und wie gesagt wird das in der Präsentation auch so unterfüttert. Und bitte das auch nicht auf die Goldwaage legen, nur weil das "Volta" steht, der Kontext ist absolut eindeutig. In diesem Fall meint man mit Volta GV100. Das ist auch logisch, weil NV zu Gaming Volta offensichtlich keine Angaben gemacht hat und offensichtlich keine Angaben machen will. Und diese 50% sind mit Sicherheit auch bei GV100 eher Cherrypicking, so wie Blender bei Ryzen damals. Im Durchschnitt dürfte man eher so 30-40% schneller sein.
Zudem tauchen die 50% auch an anderen Stellen auf, dort bezieht man sich auch stets auf die Architektur des GV100, nämlich Volta.

Locuza

2017-05-11, 14:20:28

“It has a completely different instruction set than Pascal,” remarked Bryan Catanzaro, vice president, Applied Deep Learning Research at Nvidia. “It’s fundamentally extremely different. Volta is not Pascal with Tensor Core thrown onto it – it’s a completely different processor.”

Catanzaro, who returned to Nvidia from Baidu six months ago, emphasized how the architectural changes wrought greater flexibility and power efficiency.

“It’s worth noting that Volta has the biggest change to the GPU threading model basically since I can remember and I’ve been programming GPUs for a while,” he said. “With Volta we can actually have forward progress guarantees for threads inside the same warp even if they need to synchronize, which we have never been able to do before. This is going to enable a lot more interesting algorithms to be written using the GPU, so a lot of code that you just couldn’t write before because it potentially would hang the GPU based on that thread scheduling model is now possible. I’m pretty excited about that, especially for some sparser kinds of data analytics workloads there’s a lot of use cases where we want to be collaborating between threads in more complicated ways and Volta has a thread scheduler can accommodate that.

“It’s actually pretty remarkable to me that we were able to get more flexibility and better performance-per-watt. Because I was really concerned when I heard that they were going to change the Volta thread scheduler that it was going to give up performance-per-watt, because the reason that the old one wasn’t as flexible is you get a lot of energy efficiency by ganging up threads together and having the capability to let the threads be more independent then makes me worried that performance-per-watt is going to be worse, but actually it got better, so that’s pretty exciting.”

Added Alben: “This was done through a combination of process and architectural changes but primarily architecture. This was a very significant rewrite of the processor architecture. The Tensor Core part is obviously very [significant] but even if you look at FP32 and FP64, we’re talking about 50 percent more performance in the same power budget as where we’re at with Pascal. Every few years, we say, hey we discovered something really cool. We basically discovered a new architectural approach we could pursue that unlocks even more power efficiency than we had previously. The Volta SM is a really ambitious design; there’s a lot of different elements in there, obviously Tensor Core is one part, but the architectural power efficiency is a big part of this design.”
https://www.hpcwire.com/2017/05/10/nvidias-mammoth-volta-gpu-aims-high-ai-hpc/

Nvidia gibt für Volta für geläufige FMA-Operationen eine Latenz von 4 Zyklen an, gegenüber 6 bei Maxwell/Pascal.
GCN liegt bekanntlich bei 4.

Klevapalis

2017-05-11, 14:29:14

Der Satz bezieht sich glasklar auf den ersten. Das hat nichts mit Gaming-Volta zu tun.
Bitte versteh das nicht als persönlichen Angriff, aber ich glaube nicht, dass du den Satz verstehst.

NVIDIA hat eine neue Shader-Architektur entwickelt, die eine 50%ig bessere Perf/Watt liefert, als was aktuell in Pascal verbaut ist und zwar in Sachen FP32 und FP64.

Wer (wie du) behauptet das kommt im Gaming-Volta nicht - das ist einfach absoluter Unfug.

TGKlaus

2017-05-11, 14:37:00

NVIDIA hat eine neue Shader-Architektur entwickelt

???

dildo4u

2017-05-11, 14:38:43

Es war lange Zeit für ein größeren Umbau,Kepler war April 2012.Alle 5 Jahre kann man vermutlich so einen Sprung erwarten,vergleichbar mit dem was AMD grad mit Ryzen gemacht hat.

HOT

2017-05-11, 14:46:24

Bitte versteh das nicht als persönlichen Angriff, aber ich glaube nicht, dass du den Satz verstehst.

NVIDIA hat eine neue Shader-Architektur entwickelt, die eine 50%ig bessere Perf/Watt liefert, als was aktuell in Pascal verbaut ist und zwar in Sachen FP32 und FP64.

Wer (wie du) behauptet das kommt im Gaming-Volta nicht - das ist einfach absoluter Unfug.
Das war nicht persönlich gemient. Aber ich versteh das sehr wohl. Gemeint ist die GV100-Architektur ggü. der GP100-Architektur, sonst gar nichts. Da sich die Gamingarchitektur grade in diesem Punkt fundamental davon unterscheidet ist dieser Schluss einfach blödinnig. Du vermischt da was, was man trennen muss. Es kann ja sein, dass Volta-Gaming 50% besser ist als Pascal-Gaming, das ist hier aber nicht abzulesen und das ist auch nicht gemeint. Es kann sein, dass Volta Gaming sogar 60% besser ist. Das wissen wir aber nicht und das steht da auch nicht.

Mandalore

2017-05-11, 14:55:34

Mache Rechnereien drüben bei videocardz gehen von 5-7% besserer IPC aus...wie kann das sein bei einem neuen SM-Design?

Klevapalis

2017-05-11, 14:55:56

???
New Streaming Multiprocessor (SM) Architecture

Das war nicht persönlich gemient. Aber ich versteh das sehr wohl. Gemeint ist die GV100-Architektur ggü. der GP100-Architektur, sonst gar nichts.
Unfug. Es gibt keine "GV100-Architektur" oder eine "GP100-Architektur". Es gibt eine Volta-Architektur und eine Pascal-Architektur und diese wird einmal in GV100 genutzt, die anderen in GP100-GP106.

Wenn nun Architektur Volta in Sachen FP32 50% mehr Perf/Watt schafft als Architektur Pascal, warum sollte man die in Volta GV10x weglassen?

Dein Denkfehler ist wohl, dass du glaubst es wären unterschiedliche Architekturen auf GP100 vs. GP102-106. Das stimmt aber natürlich nicht. Die Architektur ist identisch, auf beiden finden sich z.B. die identischen FP32-Einheiten. Vergleich GP100:
http://cdn.wccftech.com/wp-content/uploads/2016/04/NVIDIA-Pascal-SMP.jpg
GP102:
https://www.3dcenter.org/dateien/abbildungen/nVidia-GP104-Shader-Cluster.png
Wie du siehst sind die Cores identisch, egal ob GP100 oder GP102-106 bis auf eben die fehlenden DP-Einheiten für HalfRate-FP64 Berechnungen.

Es ist vollkommen logisch, dass auch GV102 & Co die effizienteren Shadereinheiten kriegen wird. Alles andere wäre doch völliger Unfug.

Locuza

2017-05-11, 15:10:26

Die SM-Cluster waren schon deutlich verschieden:

GP100:
64 Mixed-Precision FP16/FP32 ALUs
32 FP64 ALUs
256KB an Register
64KB shared memory

Alle anderen Pascal-Ableger:
128 FP32 ALUs (Nur eine Mixed-Precision FP16 ALU und 4 FP64 ALUs)
256KB an Register
96KB shared memory

Man beachte das der GP100 pro ALU effektiv mehr Register und Shared Memory zur Verfügung hat, da nur die Hälfte an ALUs pro SM existiert und darauf zugreifen muss.

Stellt sich die Frage, wie genau die Volta-Ableger für Konsumenten strukturiert werden.
Aber ich denke die Kerneigenschaften der Architektur bleiben bestehen.
Selbe ISA, effizienteres SIMT-Model etc.

Unicous

2017-05-11, 15:18:46

@Klevapalis

Du hängst dich etwas weit aus dem Fenster während du allseits bekannte Marketing-Folien als Beleg anführst die, wie Locuza schon agendeutet hat, nur die halbe Wahrheit erzählen.

AffenJack

2017-05-11, 15:30:55

Mache Rechnereien drüben bei videocardz gehen von 5-7% besserer IPC aus...wie kann das sein bei einem neuen SM-Design?

Wenn es überhaupt soviel wird. IPC ist sowieso ein nicht passender Begriff bei GPUs und gehört eher zu CPUs. Du hast bei GPUs viele Workloads die einfach direkt mit den Gflops skalieren. Wenn z.B. Fury seine Leistung nicht auf den Boden bringt, dann liegt nicht an den Shadern, diese sind wie man auch an Compute Anwendungen sieht top. Sondern an anderen Limitierungen.

Es sind eher speziellere Algorithmen, die dann auf einer GPU vorher nicht gut liefen, aber du das Redesign jetzt erst möglich werden oder deutlich besser laufen. Du als Spieler wirst nur die bessere Perf/W sehen erstmal und irgendwann in ferner Zukunft Spiele die die neuen Möglichkeiten/Features nutzen können. Oftmals sind das vor allem auch deutliche Erleichterungen für die Programmierer.

mksn7

2017-05-11, 16:09:32

Nvidia gibt für Volta für geläufige FMA-Operationen eine Latenz von 4 Zyklen an, gegenüber 6 bei Maxwell/Pascal.
GCN liegt bekanntlich bei 4.

Da ist aber nicht ganz klar, ob das wirklich 4 Clock cycles oder 4 issues sind. Zu jedem scheduler sind nur noch 16 ALUs zugeordnet, die ALUs brauchen also 2 Takte für den Warp, und es kann nur jeden zweiten Takt ein FMA gestartet werden. Vielleicht hat nvidia nur die sichtbare Latenz auf 4 Takte reduziert, es langen also vier unabhängige Befehle vor der nächsten Abhängigkeit für vollen Durchsatz. In dem Fall wären es 8 volle Taktzyklen Latenz. Längere Latenzen sind gut für Takt und Energieeffizienz, würde sich also vielleicht lohnen.

Mit dieser Zählweise hätte AMD sogar nur einen Takt/Issue Latenz.

Das neue Instructionset, das da angepriesen wird, wird wohl zu einem großen Teil auch dadurch zustande kommen, dass jetzt weniger dependency info in den code rein muss, da es ja kein dual issue mehr gibt. Das Byte format sieht also sicher deutlich anders aus, die Befehle könnten aber an sich schon noch recht ähnlich sein.

HOT

2017-05-11, 16:20:45

Klevapalis
Das ist natürlich schön einfach auf den Namen herumzureiten. Das ändert nichts daran, dass die SMs komplett unterschiedlich sind und genau dort entsteht der Löwenanteil der Abwärme, die für die Kalkulation entscheidend ist.
GV104 kann 30-60% besser sein bei gleicher TDP - oder gar noch mehr oder noch weniger - man weiss es einfach nicht, da man davon einfach nichts ableiten kann.

Klevapalis

2017-05-11, 16:21:06

Die SM-Cluster waren schon deutlich verschieden:
Darum geht es nicht. Es geht um die SM selbst.

Inwiefern unterscheidet sich denn eine FP32-ALU im GP100 von einer FP-32ALU im GP102-106?

Genau: Gar nicht. :cool:

Du hängst dich etwas weit aus dem Fenster während du allseits bekannte Marketing-Folien als Beleg anführst die, wie Locuza schon agendeutet hat, nur die halbe Wahrheit erzählen.
Ich hänge mich nicht weit aus dem Fenster, sondern sage nur, dass diese Verbesserung auch den Gaming-Volta erreichen wird. Alles Andere ist schlicht Schmu.

Selbst wenn die 50% theoretisch sind und es bei realen Workloads nur 20 oder 30% sind: Welchen Grund sollte NVIDIA haben, die Architektur nicht zu nutzen? Auch hier wieder: Gar keinen.

Das ist natürlich schön einfach auf den Namen herumzureiten. Das ändert nichts daran, dass die SMs komplett unterschiedlich sind und genau dort entsteht der Löwenanteil der Abwärme, die für die Kalkulation entscheidend ist.
Inwiefern unterscheidet sich denn der SM (nicht der SM-Cluster! Vorsicht!) zwischen GP100 und GP102-106?

HOT

2017-05-11, 16:23:16

Ich glaub du hast da ne grundlegend falsche Vorstellung... die Gaming-Pascal SMs sind näher an den Maxwell SMs als an den GP100 SMs.

Unicous

2017-05-11, 17:54:50

@Klevapalis

Nein, nein. Du hängst dich vieeeeeel zu weit aus dem Fenster wenn du davon ausgehst, dass die SMs in den Gaming-Chips ähnlich sein werden wie beim GV100. Das wäre nämlich grober Unfug seitens Nvidia. Und da Nvidia das nicht machen wird, ist es grober Unfug von deiner Seite.:wink:

Dass sich die Architektur bei den Consumer-Volta Chips weiterentwickeln wird, zweifelt im Übrigen niemand an.

Hübie

2017-05-11, 18:10:26

We need more drums

Ist die GeForce Sparte nicht derzeit das beste Pferd im Stall?

Nach nem 815er Monster Chip und damals schon angepasste Pascal GeForce, würde ich da niemals nie sagen

Ich schrieb "für gewöhnlich". Nur weil GeForce ein Zugpferd ist, bedeutet dies nicht, dass man Gameworks gleich als Zugpferd sieht. ;)

Naja, schaut euch doch mal an, wieviele Tensor Cores man hat ;)

Das Verhältnis liegt bei der 16 fachen SMX Anzahl ;) Ein Schelm wer sich dabei etwas denkt....

Ich schätze du willst auf eine Verschaltung hinaus. Aber würde das nicht ein immenses Netzwerk erfordern, was wieder die power envelope hässlich erscheinen lässt? :uponder: Daran dachte ich zugegebenermaßen auch.

Complicated

2017-05-11, 19:06:57

Kann deinen Hass auf NVIDIA sehr gut verstehen, aber mach das doch bitte im AMD-Forum. Hier nervt das nur.
Was haben sie dir denn zu trinken gegeben :eek:
Ich habe nichts behauptet, sondern einen Artikel zitiert und verlinkt wo das wortwörtlich zu lesen war und sogar die Überschrift ist. Reagiere dein Testosteron bitte woanders ab. Ist hier das Nvidia Forum wo du bestimmst was die Wahrheit ist?

Mandalore

2017-05-11, 20:24:48

@Unicous:

Kannst du das genauer erläutern, wieso GV100 Shader anders sind als zB GV102/GV104 bzw. GP100 zu GP102/GP104?

Ich meine eine FP32 Einheit von GP100 müsste doch gleich sein wie eine GP102/GP104 Einheit, oder nicht?

Oder ist alles ironisch gemeint:confused::freak:

Skysnake

2017-05-11, 20:27:15

Ich schätze du willst auf eine Verschaltung hinaus. Aber würde das nicht ein immenses Netzwerk erfordern, was wieder die power envelope hässlich erscheinen lässt? :uponder: Daran dachte ich zugegebenermaßen auch.
Nein, du kannst das, wenn ich es richtig überblickt habe recht einfach mittels Vektorinstructionen auf die ALUs mappen.

Das macht das ganze Sheduling deutlich einfacher. Wenn man jetzt das ganz geschickt mit den Scatter/gatter/Shuffle Instructionen verheiratet, kann man wohl recht effiziente Micro-Kernels bauen, die dir die Layer mit strides implementieren. Man verwendet die Daten zumeist ja Mehrfach.

Was ich nur noch nicht ganz durchdrungen habe ist, wie Sie da so viele OPs erreichen... Ich glaube nicht, dass Sie da nur Arithmetische Operationen rechnen, sondern auch so Zeug wie Shuffle etc. Anders kann ich es mir nicht erklären, selbst wenn Sie Int8 bzw. FP8 verwenden würden, wären die ALUs zu schmal. Kann aber natürlich auch sein, dass Sie die Grafik FFU verwenden. Das konnte man ja schon früher machen, wenn man ganz hart war. Für so Micro-Kernels, die man quasi über eine einzige Instruction implementieren kann könnte sich das schon lohnen.

Klevapalis

2017-05-11, 23:05:27

Nein, nein. Du hängst dich vieeeeeel zu weit aus dem Fenster wenn du davon ausgehst, dass die SMs in den Gaming-Chips ähnlich sein werden wie beim GV100. Das wäre nämlich grober Unfug seitens Nvidia. Und da Nvidia das nicht machen wird, ist es grober Unfug von deiner Seite.:wink:
Bullshit. Natürlich werden die SM-Cluster genauso "ähnlich" sein bei GV100 vs. GV102 wie heute bei GP100 vs. GP102. Und damit profitieren natürlich auch die Gamingchisp von den Perf/Waff. Alles andere ergibt exakt null Sinn.

Was haben sie dir denn zu trinken gegeben :eek:
War ja klar, dass da nichts sachliches zurück kommt ;)

Du hast behauptet, Huang hätte da etwas "klein geredet". Dem ist so aber nicht der Fall. Wenn dein Englisch nicht ausreichend ist, um den Text zu verstehen, dann nutze ihn halt nicht als Quelle - egal, was die "Überschrift" sagt :rolleyes:
Man sollte nicht auf jede " fetzige" Überschrift rein fallen, nur weil sie einem in das eigene Weltbild passen. Medienkompetenz ist es, auch den entsprechenden Text zu lesen, verstehen und ein zuordnen. Und von kleinreden kann da keine Rede sein.

iuno

2017-05-11, 23:27:08

Natürlich werden die SM-Cluster genauso "ähnlich" sein bei GV100 vs. GV102 wie heute bei GP100 vs. GP102.
Das ist ja genau der Punkt.

GP100 SM:
https://www.techpowerup.com/img/16-04-12/30b.jpg

GP102/4/6 SM:
http://core0.staticworld.net/images/article/2016/05/gp104-sm-block-diagram-100661283-orig.png
Sah bei Maxwell uebrigens genau so ^ aus.
Du koenntest also einfach mal vorher checken worueber geredet wird, bevor du bullshit callst.

Ich meine eine FP32 Einheit von GP100 müsste doch gleich sein wie eine GP102/GP104 Einheit, oder nicht?
Es faengt schon damit an, dass eine "FP32" ALU in GP100 mixed precision kann und in den gaming Chips eben nicht. Weiter geht es damit, dass der SM ganz anders aufgebaut ist (s.o) und sich damit auch die Menge an Speicher in der ganzen Hierarchie unterscheidet (Register und Caches).

ndrs

2017-05-11, 23:34:46

Bullshit. Natürlich werden die SM-Cluster genauso "ähnlich" sein bei GV100 vs. GV102 wie heute bei GP100 vs. GP102. Und damit profitieren natürlich auch die Gamingchisp von den Perf/Waff.
Gab es überhaupt schon eine Meldung auf was sich die Effizienzsteigerung bezieht? Wenn es nämlich nur Anwendungsfälle sind, die die neuen Funktionseinheiten nutzen, sehe ich keinen für für Consumer-Volta relevanten Fortschritt.

PHuV

2017-05-11, 23:51:56

Gar nichts in diese Richtung (kaufmännische Ausbildung). Reinrassiger Autodidakt in allen IT-Fragen.
Dann spiel mal solche Gaterschaltungen mit Simulationen durch, dann wird einiges schnell klarer.

Gipsel

2017-05-11, 23:55:48

Die Tensor-Cores sind ja ganz interessant. Grundsätzlich geht mir das immer noch nicht weit genug für Neuronale Netze. Aber seis drum.

Die Tensor-Cores sind dedizierte FP16-MULs und FP32-ADDs. Hier von FMA zu sprechen wäre sehr gewagt. Pro Tenor-Core sind es 64 FP16-MUL und 64 FP32-ADD. Das liegt daran, dass ein FP16-MUL ein FP32 als Ergebnis hat. Demensprechend sind die Blöcke deutlich kleiner.

Um diese Dinger auf voller Last zu fahren benötigt man eine abartig-hohe Register- und Speicherbandbreite. Reinher vom Konzept, bräuchte man pro Takt pro Tensor-Core Zugriff auf 4096 Bit Daten (2x64xFP16 (AxB) + 64xFP32 (+C)). Das ist verdammt viel. Wenn man spezifische Eigenschaften von CNNs berücksichtigt, kann man das ganz gut drücken.Da liegst Du zu hoch mit der Bandbreite. Die ganzen Zwischenergebnisse benötigen ja keine, die werden in der Pipeline gehalten. Effektiv benötigt man für eine Tensor-Op (R=AxB+C) genau 32 FP16 (A und B) und 16 FP32 (C) Quell-Operanden. Damit benötigt man genau so viel Registerbandbreite wie für eine normale FP32 2-Operandeninstruktion pro half-Warp (also in einem der zwei Issue-Takte pro Warp). Da ist also noch Reserve, weswegen man genügend Bandbreite hat, um dann zwei davon pro SM-Sektion (nennen wir es in Analogie zu GCN einfach mal SIMD) durchzuziehen.

=============================

https://www.hpcwire.com/2017/05/10/nvidias-mammoth-volta-gpu-aims-high-ai-hpc/

Nvidia gibt für Volta für geläufige FMA-Operationen eine Latenz von 4 Zyklen an, gegenüber 6 bei Maxwell/Pascal.
GCN liegt bekanntlich bei 4.Gut beobachtet. Schon seit Kepler war zu beobachten, daß sich nV der GCN-Architektur in einigen Details annähert (Fermi lag z.B. noch bei einer Latenz von ~20 Takten, was sukzessive gesenkt wurde). Auch bei der Unterteilung eines SMs in 4 Teile, die mehrere Instruktionen absetzen können (bei nV bis zu 2 Instruktionen alle 2 Takte, bei GCN bis zu 5 Instruktionen alle 4 Takte [die alle zwei vs. alle 4 Takte kommt von den 32 work items pro Warp bzw. 64 work items pro Wavefront]) sind Parallelentwicklungen erkennbar (genauso wie auch bei der Behandlung von Abhängigkeiten mit Hilfe von dependency counters). NVidia hat sich GCN offenbar schon genau angesehen und die für sie interessanten Aspekte herausgepickt und entsprechend adaptiert (was nicht heißt, sie würden abkupfern, eher daß AMD mit den grundsätzlichen Designentscheidungen für GCN in vielen Dingen offenbar nicht so falsch lag [was ja schon zum Start von vielen so ähnlich gesagt wurde]).

==========================

Ganz lustig ist auch, daß nV nun praktisch zugibt, daß bisher ihr "SIMT" nur SIMD mit Lanemasking, also das ganze "SIMT" reines Marketing-Gewäsch war (wie ich schon immer [also seit mindestens 6 Jahren] argumentiert habe: Warps/Wavefronts sind die echten Hardware-Threads, da jeder echte Thread einen eigenen IP benötigt [Stichwort: irreducible control flow], was er nicht hatte). NVs Lösung dazu sieht auf den ersten Blick etwas eleganter als die von AMDs GCN aus. Aber langsamer wird es bei nV auch. Das schon etwas länger spekulierte "Dynamic Warp Formation"/"Wavefront-Coalescing", also das Umbilden der Warps/Wavefronts (so daß alle work items darin kohärenten Kontrollfluß zeigen) um einen hohen Füllgrad zu behalten, ist wohl etwas schwieriger (ich würde sagen, es gibt ein paar fundamentale Probleme mit der Idee).

Hübie

2017-05-12, 00:21:23

Complicated

2017-05-12, 00:42:34

War ja klar, dass da nichts sachliches zurück kommt ;)

Du hast behauptet, Huang hätte da etwas "klein geredet". Dem ist so aber nicht der Fall. Wenn dein Englisch nicht ausreichend ist, um den Text zu verstehen, dann nutze ihn halt nicht als Quelle - egal, was die "Überschrift" sagt :rolleyes:
Man sollte nicht auf jede " fetzige" Überschrift rein fallen, nur weil sie einem in das eigene Weltbild passen. Medienkompetenz ist es, auch den entsprechenden Text zu lesen, verstehen und ein zuordnen. Und von kleinreden kann da keine Rede sein.
In einem Satz zu behaupten es stünde da nicht und im nächsten es zu negieren indem man schreibt es wäre egal was da steht macht dein auftreten hier nicht intelligenter und dein englisch auch nicht sattelfester. Mal den Klebstoff weg lassen dann wird auch der Blutdruck wieder besser....

Edit: Ach ja mit Smileys ;) :P ..etc...

Skysnake

2017-05-12, 01:02:47

Die ALUs und Flexibilität waren ja offenbar weniger das Problem bei GCN.
Meinst du die Tensor Cores sind im Grunde "nur" zusammen geschaltete ALUs? Die Ergebnisse haben ja wahrscheinlich keine Abhängigkeit untereinander. Ich checke es nicht so ganz. :D
Die ALUs wird man nutzen aber man braucht etwas extra Logik. Die Frage ist wieviel. Dafür muss man aber erst mal wissen was nvidia genau als tensor Flop zählt. Das sind wohl ziemlich sicher mehr als nur die FMAs.

Leider scheint keiner von den Medien mal kritisch nachgefragt zu haben.

Leonidas

2017-05-12, 04:15:46

Ja, die Speicherinterfaces laufen mit 8 GHz wenn du 16Gbs übertragen willst.
ABER! Es läuft nicht alles damit. es laufen "nur" auf TX Seite die Ausgansbuffer sowie die letzte Stufe des Serializers damit und auf der RX Seite eben die Sampling Latches, der clk Multiplier und dann noch die erste Stufe des Desirializers.
.

Sprich, wir müssen keine Befürchtungen haben, das bei 4000 MHz QDR dann der Stromverbrauch des Speicherinterfaces durch die Decke geht, weil die 8 GHz nur in Bruchteilen des Interfaces anliegen.

Danke für die Klarstellung.

Thema Blockdiagramme und daraus ableitbare Aussagen:

Ich würde generell annehmen, das jene Blockdiagramme nur bildliche Darstellungen einer Näherung der Wahrheit sind. Sprich, es gibt gleich zwei Ansätze, wo das Bild dann am Ende nicht exakt mit dem Text übereinstimmen muß. Ergo: Was festes in Bezug auf internen Aufbau ist da nicht herauszulesen. Jede Einheit könnte auch nur rein virtuell existieren, die Einheiten-Gruppen könnten real anders aufgelöst sein etc. etc.

Interessanter Gedanke hierzu:

Wer sagt uns, das die FP64-Einheiten absolut komplette FP64-Einheiten sind - und nicht vielleicht nur Zusatzeinheiten, die es denn FP32-Einheiten ermöglichen, FP64 auszuführen.

Oder umgedreht: Echte FP64-Einheiten, wo die FP32-Einheiten nur virtuell sind und dafür sorgen, das eine FP64-Einheit zwei FP32-Operationen abarbeiten kann.

Wenn nicht, dann wäre die Frage: Sooo viele Hardware-Einheiten - und warum kann man die nicht alle gleichzeitig nutzen? Die Rechenleistung würde explodieren, zumindest ergäbe es eine schöne Marketingzahl. Das nVidia sich diese Chance zur großen Zahl entgehen läßt, deutet darauf hin, das gleichzeitige Nutzung technisch unmöglich ist - was wiederum darauf hindeutet, das einige Einheiten nur virtuell oder als Register existieren.

Skysnake

2017-05-12, 07:34:47

Sprich, wir müssen keine Befürchtungen haben, das bei 4000 MHz QDR dann der Stromverbrauch des Speicherinterfaces durch die Decke geht, weil die 8 GHz nur in Bruchteilen des Interfaces anliegen.

Danke für die Klarstellung.

Doch wir müssen Angst haben, dass die Leistungsaufnahme explodiert, wenn man auf 4 GHz QDR gehen würde. Aus 2 Gründen

1. Bei 4 GHz QDR hat man eine Datenrate von 16 Gbs also 8 GHz. Das ist schon verdammt hoch. Signale kann man ja auch immer mittels Fouriereihenentwicklung darstellen, und eine gute Faustregel ist, das man mindestens die 5. Oberwelle. Das wären also 5*8GHz, also 40 GHz Signale, die man über die Leitungen übertragen muss!

Bei so hohen Frequenzen werden FR4 PCBs praktisch zu Leitern und du hast eine riesige Dämpfung, weshalb man dann riesige Treiber braucht, damit am Ende überhaupt noch etwas ankommt. Zudem braucht man dann noch mehr Bufferchains etc etc.

Der Zusammenhang ist da hochgradig! nicht linear zwischen Datenrate und Verbrauch. Nur mal so als Randnotiz. State of die Art sind 25 Gbs Signalleitungen. Allein da eine beschissene Clk zu treiben kostet richtig Strom. Du mist da schnell mal bei mW für fast keine Funktionalität bzw. Lasten ...

CMOS Schaltungen werden bei so hohen Frequenzen auch immer kritischer. Die machen das teils einfach nicht mehr mit, oder man muss Sie schon prügeln. (Erfahrung aus 28nm HPP Designkit, mit den FinFets sieht es deutlich besser aus, aber man bekommt die Dinger nicht mehr mit Strom versorgt. Sprich die Packdichte ist dadurch limitiert, wieviel der Wiring für Daten und wieviel für GND+VDD draufgeht. Die Transistoren könnten aber mehr, nur bruzeln dir dann die Versorgungsleitungen weg... Das war schon in 28nm so.

2. Die Schaltungsteile auf den höchsten Frequenzen sind zwar die kleinsten, bzw die mit den wenigsten Transistoren wohl (je nach Zählweise), aber die werden wohl für den Großteil der Leistungsaufnahme verantwortlich sein.

Thema Blockdiagramme und daraus ableitbare Aussagen:

Ich würde generell annehmen, das jene Blockdiagramme nur bildliche Darstellungen einer Näherung der Wahrheit sind. Sprich, es gibt gleich zwei Ansätze, wo das Bild dann am Ende nicht exakt mit dem Text übereinstimmen muß. Ergo: Was festes in Bezug auf internen Aufbau ist da nicht herauszulesen. Jede Einheit könnte auch nur rein virtuell existieren, die Einheiten-Gruppen könnten real anders aufgelöst sein etc. etc.

Interessanter Gedanke hierzu:

Wer sagt uns, das die FP64-Einheiten absolut komplette FP64-Einheiten sind - und nicht vielleicht nur Zusatzeinheiten, die es denn FP32-Einheiten ermöglichen, FP64 auszuführen.

Oder umgedreht: Echte FP64-Einheiten, wo die FP32-Einheiten nur virtuell sind und dafür sorgen, das eine FP64-Einheit zwei FP32-Operationen abarbeiten kann.

Wenn nicht, dann wäre die Frage: Sooo viele Hardware-Einheiten - und warum kann man die nicht alle gleichzeitig nutzen? Die Rechenleistung würde explodieren, zumindest ergäbe es eine schöne Marketingzahl. Das nVidia sich diese Chance zur großen Zahl entgehen läßt, deutet darauf hin, das gleichzeitige Nutzung technisch unmöglich ist - was wiederum darauf hindeutet, das einige Einheiten nur virtuell oder als Register existieren.
Erzähl ich seit Maxwell, aber ich erzähl ja nur bullshit....

Hübie

2017-05-12, 07:46:14

Kepler hat afaik dedizierte FP64-Units. Fraglich ob man beides aufgrund des kleinen registerspace nutzen kann. Aber wer sagt denn dass du bullshit redest? :| So abwegig ist es ja nun nicht. Beim GP100 wäre ich mir wiederum nicht sicher. Es sollte grundsätzlich einfach sein dies heraus zu finden, für jemand der davor sitzt.

ps: Hast du Zugang zu jedec.org, Skysnake? Da gibt's die Specs für HBM & GDDR als pdf.

Leonidas

2017-05-12, 08:26:16

Doch wir müssen Angst haben, dass die Leistungsaufnahme explodiert, wenn man auf 4 GHz QDR gehen würde. Aus 2 Gründen.

Alles klar. Blickpunkt auf die Datenrate, nicht auf die pure Interface-Taktrate. Und aus dieser Sicht wird also auch QDR kein Bremser im Stromverbrauch, weil mehr an Daten zu verarbeiten ist auch da.

Das limitiert IMO GDDR-Speicher ziemlich sicher. Zwar kann man sich technisch mit Tricks wie QDR weiterhelfen, aber wenn der Stromverbrauch im Interface immer mehr zunimmt, wird es irgendwann effizienter, mittels HBM zu arbeiten.

Hübie

2017-05-12, 08:53:01

Ich denke dass beides spätestens 2025 nicht mehr existiert. Denn beide Lösungen haben ziemlichr Nachteile, wobei ich HBM da zumindest technisch vorn sehe; nur die Sache mit der Wirtschaftlichkeit... Das ließe sich über Stückzahlen regeln, aber ob IHVs bereit sind da so in Vorleistung hingehen steht eben auf einem anderen Papier.

ndrs

2017-05-12, 09:48:16

Signale kann man ja auch immer mittels Fouriereihenentwicklung darstellen, und eine gute Faustregel ist, das man mindestens die 5. Oberwelle. Das wären also 5*8GHz, also 40 GHz Signale, die man über die Leitungen übertragen muss!
Ich glaub da fehlt beim ersten Satz etwas. Könntest du das zum Verständnis vervollständigen? Was muss man mit der 5. Oberwelle tun?

Klevapalis

2017-05-12, 09:54:42

Das ist ja genau der Punkt.

GP100 SM:
GP102/4/6 SM:
Sah bei Maxwell uebrigens genau so ^ aus.
Du koenntest also einfach mal vorher checken worueber geredet wird, bevor du bullshit callst.
Und welchen Unterschied gibt es nun konkret in den SM-Clustern, außer die FP64-Fähigkeit? Und komm jetzt bitte nicht mit der Registergröße: Dass man die bei Halfrate-DP64 anpassen muss, ist logisch.

Gab es überhaupt schon eine Meldung auf was sich die Effizienzsteigerung bezieht? Wenn es nämlich nur Anwendungsfälle sind, die die neuen Funktionseinheiten nutzen, sehe ich keinen für für Consumer-Volta relevanten Fortschritt.
FP32 Berechnungen. Also 100% dessen, was aktuell in Gamingrechner auf den Shadern läuft.

In einem Satz zu behaupten es stünde da nicht und im nächsten es zu negieren indem man schreibt es wäre egal was da steht
Lesekompetenz Sechs. Wenn die Aussage von Huang kein kleinreden zeigen, dann ist es egal, ob es in der Überschrift steht oder ob du es behauptest. Die Behauptung ist und bleibt falsch.

r-or

2017-05-12, 09:56:36

Ich glaub da fehlt beim ersten Satz etwas. Könntest du das zum Verständnis vervollständigen? Was muss man mit der 5. Oberwelle tun?
... das PCB / Layerdesign für die 5. Oberwelle auslegen muss, damit die rechtecksignale noch einigermaßen rechteckig ankommen, schätze ich mal

ndrs

2017-05-12, 11:03:29

FP32 Berechnungen. Also 100% dessen, was aktuell in Gamingrechner auf den Shadern läuft.
Könntest du eine Folie o.ä. verlinken? Ich konnte jetzt auf die schnelle immer nur Aussagen im Kontext Neuronale Netze finden.
... das PCB / Layerdesign für die 5. Oberwelle auslegen muss, damit die rechtecksignale noch einigermaßen rechteckig ankommen, schätze ich mal
Ja, könnte passen. Danke (y)

AffenJack

2017-05-12, 11:08:43

Könntest du eine Folie o.ä. verlinken? Ich konnte jetzt auf die schnelle immer nur Aussagen im Kontext Neuronale Netze finden.

Musst doch nur die Daten und TDP angucken:
https://www.computerbase.de/2017-05/nvidia-volta-gv100/

10,6Tflops bei 300W GP100 vs 15 Tflops bei 300W GV100.
Sind also nicht ganz 50%, aber das gleiche lässt sich bei Consumervolta erwarten.

Klevapalis

2017-05-12, 11:10:50

Könntest du eine Folie o.ä. verlinken? Ich konnte jetzt auf die schnelle immer nur Aussagen im Kontext Neuronale Netze finden.
https://devblogs.nvidia.com/parallelforall/inside-volta/
1. Punkt der Key Features.

Skysnake

2017-05-12, 11:30:26

Signale kann man ja auch immer mittels Fouriereihenentwicklung darstellen, und eine gute Faustregel ist, das man mindestens die 5. Oberwelle braucht. Das wären also 5*8GHz, also 40 GHz Signale, die man über die Leitungen übertragen muss!]
Ich glaub da fehlt beim ersten Satz etwas. Könntest du das zum Verständnis vervollständigen? Was muss man mit der 5. Oberwelle tun?
Ich kaufe ein "braucht" :biggrin:

Das mit dem Rechtecksignal passt schon, allerdings hast du bei der 5. Oberwelle noch nicht wirklich etwas, was viel mit einem Rechteck zu tun hat.

Siehe auch https://de.wikipedia.org/wiki/Datei:Fourier_synthesis.svg

In https://de.wikipedia.org/wiki/Fourierreihe

Ok die 5. sieht an sich schon recht rechteckig aus, daher reicht es ja auch, aber von einem echten Rechteck ist man noch SEHR weit weg. Da muss man eher Richtung 100. Oberwelle oder so gehen.

Siehe dazu auch: http://www.mb.uni-siegen.de/fkm/lehre/festigkeitslehre_ws12_13/fourierreihenentwicklung.pdf

Daher sieht das Zeug auf den Messdiagrammen auch eher immer wie ein Sinus aus...

Und dann kommt ja noch die Dämpfung durch den Kanal dazu. Also die Stecker, und vor allem auch das PCB, aber auch die Impedanz miss matches. usw usf.

Das kann man dann als Dämpfung über die Frequenz plotten, wie hier https://www.researchgate.net/figure/220588448_fig18_Channel-jitter-amplification-a-Frequency-response-of-4-backplane-channels-b-Channel

oder gleich als 2/4 Tor Analyse wie hier: https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&ved=0ahUKEwjw9JyVherTAhWItRoKHXaJA4QQFghAMAQ&url=https%3A%2F%2Fopus4.kobv.de%2Fopus4-fau%2Foai%2Fcontainer%2Findex%2FdocId%2F67&usg=AFQjCNHEH05k84w0e2OLv2Q3Zdp9U1VzOw&cad=rja
Oder auch leichter verständlich hier: https://de.wikipedia.org/wiki/Zweitor

Ich muss aber auch ganz klar zugeben, das ich mit den Tor analysen nicht wirklich selbst gearbeitet habe. Also mal kurz mit nem Studienkollegen über seine Arbeit draufgeschaut, ob das passen kann, daher habe/hatte ich ein ganz rudimentäres Verständnis, aber bis ins letzte habe ich das auch nicht durchdrungen....

ndrs

2017-05-12, 12:15:12

10,6Tflops bei 300W GP100 vs 15 Tflops bei 300W GV100.
Naja, dass man theoretische Maximalleistung und TDP nicht generell für Effizienzaussagen nutzen sollte, sollten uns diverse Tests gelehrt haben.
https://devblogs.nvidia.com/parallelforall/inside-volta/
1. Punkt der Key Features.
Danke.
Ich kaufe ein "braucht" :biggrin:
Danke. Alles folgende ist weitestgehend bekannt.

Kriton

2017-05-12, 12:32:10

War ja klar, dass da nichts sachliches zurück kommt ;)

Du hast behauptet, Huang hätte da etwas "klein geredet". Dem ist so aber nicht der Fall. Wenn dein Englisch nicht ausreichend ist, um den Text zu verstehen, dann nutze ihn halt nicht als Quelle - egal, was die "Überschrift" sagt :rolleyes:
Man sollte nicht auf jede " fetzige" Überschrift rein fallen, nur weil sie einem in das eigene Weltbild passen. Medienkompetenz ist es, auch den entsprechenden Text zu lesen, verstehen und ein zuordnen. Und von kleinreden kann da keine Rede sein.

In einem Satz zu behaupten es stünde da nicht und im nächsten es zu negieren indem man schreibt es wäre egal was da steht macht dein auftreten hier nicht intelligenter und dein englisch auch nicht sattelfester. Mal den Klebstoff weg lassen dann wird auch der Blutdruck wieder besser....

Edit: Ach ja mit Smileys ;) :P ..etc...

Und wenn Ihr beide mal inhaltlich "argumentieren" würdet, und nicht gegen die Person gerichtet, dann hätten wir sogar so etwas wie eine "Diskussion".

bertramfx

2017-05-12, 12:35:46

Gerade fürs Gaming is GV100 doch interessant: ordentlich Power für clevere KI basierend auf deep learning.

Der_Korken

2017-05-12, 13:52:15

Gerade fürs Gaming is GV100 doch interessant: ordentlich Power für clevere KI basierend auf deep learning.

Bevor wir derartige Methoden für die KI von Spielfiguren sehen, wird noch viel Zeit vergehen. Außerdem müsste man sicherstellen, dass die KI auf jedem System korrekt arbeitet (wer hat schon einen GV100, damit man sowas voraussetzen könnte?) und sie nicht besser wird, je dicker das System, auf dem man spielt :freak:.

Troyan

2017-05-12, 14:25:36

Für Strategiespielen wäre es sogar möglich. Man sendet das Pattern des Spielers an die Cloud und lässt das Netzwerk a) damit trainieren und b) bei jeder Party entsprechend die Ergebnisse analysieren. Wenn also der Spieler immer über die linke Seite kommt, sollte nach einer Weile die KI links verstärken. Gibt bestimmt viele Möglichkeiten die KI dynamischer gestalten zu können.

Klevapalis

2017-05-12, 15:38:40

Bevor wir derartige Methoden für die KI von Spielfiguren sehen, wird noch viel Zeit vergehen. Außerdem müsste man sicherstellen, dass die KI auf jedem System korrekt arbeitet (wer hat schon einen GV100, damit man sowas voraussetzen könnte?) und sie nicht besser wird, je dicker das System, auf dem man spielt :freak:.
Google möchte seine AlphaGo-KI bereits trainieren auch StarCraft spielen zu können:
https://www.heise.de/newsticker/meldung/DeepMind-Nach-Go-lernt-Googles-KI-Starcraft-II-3457371.html

Könnte für Spiele tatsächlich sehr interessant sein, wenn sich die KI im Spiel auf den Spieler einstellt. Zumindest viel interessanter, als die heutzutage strunzdummen "Gegner".

@Kriton:
Das Thema ist durch, keine der Aussagen von Huang im Interview belegt, dass er irgendwas klein redet. Eine sachliche Analyse der Marktsituation ist doch völlig ok.

bertramfx

2017-05-12, 15:45:47

=Floi=

2017-05-12, 18:13:17

Hübie

2017-05-12, 21:46:57

Hat eigentlich einer gesehen welches Datum auf dem GV100 drauf war? 10. Woche 2017 müsste es afaik gewesen sein. Revision A1. Die youtube-Bilder taugen leider nix.

y33H@

2017-05-12, 21:56:04

10/17 und A1 auf der für Fotos hingelegten V100.

Hübie

2017-05-12, 22:02:05

Hatte aus Zeitmangel nur computerbase abgeklappert. :redface: Das ist auch in der Tat der erste Chip bzw. einer der ersten. Krass wie schnell das eigentlich ging. Macht Amkor eigentlich auch für NV das packaging? Ich hab vergessen wer das war.

y33H@

2017-05-12, 22:05:27

NV wollte nicht sagen wer das Packaging macht, könnte auch direkt bei TSMC passieren.

Iruwen

2017-05-12, 22:19:12

ebay kann bis heute nicht mal von verbrauchsgütern und "nur mal angesehen" entscheiden. labert keinen mist, wir sind noch zig jahre von wirklich brauchbarer AI entfernt! Das ganze thema ist auch nur wieder huang marketing. in 3 jahren krähr kein hahn mehr danach.
Man sollte einfach nicht alles in einen Topf schmeißen. Hier für Doofe: https://blogs.nvidia.com/blog/2016/07/29/whats-difference-artificial-intelligence-machine-learning-deep-learning-ai/

Hübie

2017-05-12, 22:23:56

Wenn ein System sich selbst programmieren kann ist es intelligent. Es lernt selbstständig. So gesehen gibt es dass abseits einiger Labore nicht. Es ist außerdem tatsächlich gefährlich. Man schaue sich nur mal uns Menschen an - das meine ich keineswegs spaßig.

MiamiNice

2017-05-13, 00:05:52

Wenn ein System sich selbst programmieren kann ist es intelligent. Es lernt selbstständig. So gesehen gibt es dass abseits einiger Labore nicht.

Es existiert Code der sich selbst weiter entwickeln kann? Heute?

Hübie

2017-05-13, 00:27:06

Ja!

Digidi

2017-05-13, 00:35:18

Ich kaufe ein "braucht" :biggrin:

Das mit dem Rechtecksignal passt schon, allerdings hast du bei der 5. Oberwelle noch nicht wirklich etwas, was viel mit einem Rechteck zu tun hat.

Siehe auch https://de.wikipedia.org/wiki/Datei:Fourier_synthesis.svg

In https://de.wikipedia.org/wiki/Fourierreihe

Ok die 5. sieht an sich schon recht rechteckig aus, daher reicht es ja auch, aber von einem echten Rechteck ist man noch SEHR weit weg. Da muss man eher Richtung 100. Oberwelle oder so gehen.

Siehe dazu auch: http://www.mb.uni-siegen.de/fkm/lehre/festigkeitslehre_ws12_13/fourierreihenentwicklung.pdf

Daher sieht das Zeug auf den Messdiagrammen auch eher immer wie ein Sinus aus...

Und dann kommt ja noch die Dämpfung durch den Kanal dazu. Also die Stecker, und vor allem auch das PCB, aber auch die Impedanz miss matches. usw usf.

Das kann man dann als Dämpfung über die Frequenz plotten, wie hier https://www.researchgate.net/figure/220588448_fig18_Channel-jitter-amplification-a-Frequency-response-of-4-backplane-channels-b-Channel

oder gleich als 2/4 Tor Analyse wie hier: https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&ved=0ahUKEwjw9JyVherTAhWItRoKHXaJA4QQFghAMAQ&url=https%3A%2F%2Fopus4.kobv.de%2Fopus4-fau%2Foai%2Fcontainer%2Findex%2FdocId%2F67&usg=AFQjCNHEH05k84w0e2OLv2Q3Zdp9U1VzOw&cad=rja
Oder auch leichter verständlich hier: https://de.wikipedia.org/wiki/Zweitor

Ich muss aber auch ganz klar zugeben, das ich mit den Tor analysen nicht wirklich selbst gearbeitet habe. Also mal kurz mit nem Studienkollegen über seine Arbeit draufgeschaut, ob das passen kann, daher habe/hatte ich ein ganz rudimentäres Verständnis, aber bis ins letzte habe ich das auch nicht durchdrungen....
Was mich Mal interessiert wäre wie viele Trägerwellen ein Frequenzband hat. Man könnte ja Daten nicht nur mit ganzzahligen Frequenzen übertragen sondern auch alle Frequenzen die dazwischen sind. Also z.B 1234.65MHz Wenn man Zeit unendlich genau Messen könnte hätte man dann auch nur bei 1 Hz unendlich viele Trägerfrequenzen.

gravitationsfeld

2017-05-13, 01:22:09

Ja!
Nein.

Hübie

2017-05-13, 01:35:19

Doch. Punkt. Man entwickelte bereits eine AI die sich selbst erweitern kann. Was die nicht kann: Die Hardwarefähigkeiten erkennen und auf deren Basis, wie Maschinencode, sich selbstständig erweitern und eine eigene Sprache daraus entwickeln (wozu dann noch high level??). Das sind vorwiegend Optimierungsprogramme die einen effizienteren Algorithmus entwickeln. Im Vergleich schnitten diese immer besser ab. Das braucht so unheimlich viel Rechenkapazität, dass es unpopulär ist. Wir können nun also definieren wovon wir sprechen. Von Mustern wie bei Lebewesen sind wir Lichtjahre entfernt. Ist hier aber OT!

Skysnake

2017-05-13, 08:09:06

Was mich Mal interessiert wäre wie viele Trägerwellen ein Frequenzband hat. Man könnte ja Daten nicht nur mit ganzzahligen Frequenzen übertragen sondern auch alle Frequenzen die dazwischen sind. Also z.B 1234.65MHz Wenn man Zeit unendlich genau Messen könnte hätte man dann auch nur bei 1 Hz unendlich viele Trägerfrequenzen.
Nur funktioniert das nicht...

1. arbeiten die Interfaces über die wir reden nicht mit Trägerfrequenzen, sondern sind übertragen die Daten binär. Deshalb erreicht man auch die hohen Frequenzen in der Datenübertragung

2. nimmt man Amplitudenmodulation hinzu, dann haste vielleicht die Trägerfrequenz bei 1GHz, aber die Daten werden nicht mit der Frequenz aufmoduliert, sondern mit sehr viel niedrigeren Raten. Irgendwo im kHz bis MHz Bereich.

3. Du hast nicht eine Speizung von 1 Hz in deinem Beispiel, sondern von 1/(1/Freq - 1/Freq-1Hz). Zumindest wenn ich gerade keinen Denkfehler habe. Das ist dann der Frequenzunterschied, den du auflösen können musst. Du musst ja immer das entsprechende Datensignal mit einem Bandpass rausfiltern. Derart genau Bandpassfilter kannst du aber nicht bauen!

also wie gesagt, das funktioniert nicht. Es gibt schon seine Gründe, warum man selbst bei Richtfunk nur relativ geringe Datenrate trotz immensem Aufwand hinbekommt.

Skysnake

2017-05-13, 08:23:19

Also ich schau mir gerade noch den Stream an, und da hatte er es von den TensorFlops und das sieht für mich aus, als ob Sie da Äpfel mit Birnen vergleichen.

Sie sprechen ja davon, dass Sie D=A*B+C beschleunigt haben. Jetzt ist die Frage, welche Annahmen da reinfließen. Es sieht für mich aber nach folgendem aus:

for i in A
for j in B
for k in C
D[k] = A[i]*B[j]+C[k]
end
end
end

Das sind natürlich verdammt viele Operationen wenn man das so hinschreibt, aber eigentlich ist das Bullshit, weil man schlicht einen beschissenen Algorithmus verwendet hat. Man kann das auch ganz anders machen

for i in A
for j in B
tmp= A[i]*B[j]
for k in C
D[k] = tmp+C[k]
end
end
end

Damit spart man sich halt K Operationen... Und bei nem 4x4x4 wären das 4x Operationen und zwar 16 mal. Ich muss mir das nochmals von Hand durchrechnen, aber ich glaube das könnte die Erklärung dafür sein, dass die auf so hohe Flops kommen.

AffenJack

2017-05-13, 09:11:38

Außer den Tensor Cores kann Volta ja jetzt INT32 parallel zu FP32 berechnen. Wofür braucht man das denn? Wahrscheinlich auch nur für sehr speziellen Code oder?

|MatMan|

2017-05-13, 10:00:32

Troyan

2017-05-13, 11:25:26

Außer den Tensor Cores kann Volta ja jetzt INT32 parallel zu FP32 berechnen. Wofür braucht man das denn? Wahrscheinlich auch nur für sehr speziellen Code oder?

Legacy-Code. Die Tensor-Cores übernehmen alle Funktionalitäten, die GP100 und GP10x für Deep Learning in den Markt prachten. Die INT-Inference Möglichkeit wird demnach über die gesonderten INT-Einheiten abgebildet.

Soweit ich das sehe, wird weder FP16 noch die INT-Fähigkeiten über die FP32 Einheiten bereitgestellt.

Hübie

2017-05-13, 12:54:10

Das ergibt keinen Sinn. Was bringt dich zu dieser These?

Skysnake

2017-05-13, 13:25:36

Deine beiden Algorithmen sind einfach falsch. Eine Matrixmultiplikation (https://de.wikipedia.org/wiki/Matrizenmultiplikation) geht schlicht anders, als das was du da rechnest. Mathematik erstes Semester ;)
:P Du brauchst mir sicherlich nicht erzählen, was eine Matrixmultiplikation ist :ucrazy:

Wie kommst du überhaupt auf Matrikmultiplikation? Weder die Animation noch die Indizes legen das nahe, wenn könnte man noch übers Skalarprodukt sprechen.

Ist aber am Ende SCHEIS egal, denn so lange nVidia nicht genau spezifiziert, WIE sie GENAU die Operationen zählen ist das mal voll fürn ARSCH....

Und für den Fall, dass du es noch immer nicht begriffen hast. Es sollte nur als Beispiel dafür dienen, das man verdammt kreativ Ops zählen kann.... Ist das wirklich so schwer zu verstehen?

Wovon man z.B. recht sicher ausgehen kann ist, dass Sie annehmen, das man implizit eine Typeconversion von FP16 auf FP32 macht beim Ergebnis, obwohl das ja gar nicht klar ist, dass das Erforderlich ist...

Und damit ist das für mich auch EOD. Geilt euch ruhig an den 120 TensorFlops auf und schlagt euch die Birne ein. Das Marketing von nVidia freuts....

Echter Interesse am Thema und der Implikationen scheint ja eh keiner zu haben. Sonst hätte schon längst mal jemand gefragt, was passiert, wenn man einen 5x5 oder gar 6x6 Stencil nimmt, oder unterschiedliche Strides....

Kriton

2017-05-13, 13:28:43

Wenn Du das für Laien einigermaßen erklären kannst, würde es mich interessieren.

Complicated

2017-05-13, 14:00:17

https://blogs.nvidia.com/wp-content/uploads/2017/04/table-tpu-gpu.png
K80 und P40 verglichen mit Googles TPU - von Nvidia

Nach der Lesart dieser Tabelle sind die P40 48 INT8 doppelt so schnell als die 90 INT8 der TPU (Inferences/sek)
It asserts, among other things, that the TPU has 13x the inferencing performance of the K80. However, it doesn’t compare the TPU to the current generation Pascal-based P40.

Warum das so der Fall sein soll geht nicht wirklich aus dem Blogpost hervor. Dies wirkt wie Nvidia-typische kreative Mathematik:
Hier der ganze Blog: https://blogs.nvidia.com/blog/2017/04/10/ai-drives-rise-accelerated-computing-datacenter/
Wenn mir jemand erklären kann warum der P40 doppelt so schnell sein soll trotz halb so vielen INT8 TOPS wäre ich dankbar.

Edit: Ach ich hab den kleinen Hinweis entdeckt - es sind doppelt soviele Inferences die unterhalb von 10ms Latenz liegen. Na also Nvidia-Mathe ;)

Troyan

2017-05-13, 15:09:05

Das ergibt keinen Sinn. Was bringt dich zu dieser These?

P100 unterstützt keine INT-Beschleunigung. Inference-Anfragen, die darauf basieren, können nur auf P4 und P40 Karten beschleunigt werden. Wenn ein Cloud-Anbieter z.B. auf GV100 wechselt, muss irgendwie sichergestellt werden, dass solche Algos weiterhin unterstützt werden.

Bei GV100 sind Trainings- und Inference-TOPS exakt identisch: 120TFLOPs.

AffenJack

2017-05-13, 16:15:51

Wenn Du das für Laien einigermaßen erklären kannst, würde es mich interessieren.

Lass dir das von wem anders erklären, denn Skysnake hat noch immer noch begriffen, dass es um Matrixmultiplikation geht. Jeder schreibt ganz klar, dass es darum geht und es deswegen 128 Flops pro Tensor Unit sind (64 FMA), aber er will es ja besser wissen. Bei Nakai, Hübie oder Gipsel biste da an einer besseren Adresse.

P100 unterstützt keine INT-Beschleunigung. Inference-Anfragen, die darauf basieren, können nur auf P4 und P40 Karten beschleunigt werden. Wenn ein Cloud-Anbieter z.B. auf GV100 wechselt, muss irgendwie sichergestellt werden, dass solche Algos weiterhin unterstützt werden.

Bei GV100 sind Trainings- und Inference-TOPS exakt identisch: 120TFLOPs.

Nur sind INT32 Einheiten wohl deutlich teurer als 4xInt8 Leistung. Ich zitiere dazu mal Arun aus B3d, der recht viel Ahnung hat, auch der Rest ist ein generell lesenswerter Post:

The one thing I'm most surprised by is that they have *full-speed* INT32; presumably full-speed INT32 MULs, not just INT32 ADDs? If so, that's quite expensive... More expensive than the Vec2 INT16/Vec4 INT8 they had on GP102/104. I wonder why? I can't think of any workload that needs it, the only benefit I can think of is simplifying the scheduler a bit. Are they reusing the INT32 units in some clever way - e.g. sharing them with FP64? There are 'interesting' unusual ways you could share some of the INT logic with some other pipelines (rather than just over-speccing the mantissa for FP32 and clock gating it when not doing INT32) but that wouldn't allow full generality of co-issue with all other pipelines which is what they are implying.

https://forum.beyond3d.com/posts/1980763/

Es muss also wohl nen anderen Grund als 4xInt8 haben, wieso man INT32 verbaut.

Klevapalis

2017-05-13, 17:28:49

Wenn mir jemand erklären kann warum der P40 doppelt so schnell sein soll trotz halb so vielen INT8 TOPS wäre ich dankbar.
TOPS = Theoretische Rechenleistung
Interference/Sec = Praktische Rechenleistung

Ist ja auch bei Radeon vs. GeForce nicht anders. Nominal haben Erstere eine 20-30% höhere Rechenleistung, praktisch ist die GeForce dann aber trotzdem minimal schneller in Sachen FPS.

edit: Steht sogar so in den Kommentaren. Hätte man lesen können. Wenn man gewollt hätte :ugly:

Digidi

2017-05-13, 17:46:20

Mal eine Frage, mit dem neuen Sheduling hat Volta jetzt endlich Async Compute?

Skysnake

2017-05-13, 17:49:47

Lass dir das von wem anders erklären, denn Skysnake hat noch immer noch begriffen, dass es um Matrixmultiplikation geht. Jeder schreibt ganz klar, dass es darum geht und es deswegen 128 Flops pro Tensor Unit sind (64 FMA), aber er will es ja besser wissen. Bei Nakai, Hübie oder Gipsel biste da an einer besseren Adresse.

Dann rechne mal vor, wie man auf 120 TFlops kommt, wenn man simple Matrixmultiplikation macht, wobei du auch mal genauer spezifizieren könntest, ob du jetzt Matrix-Scalar, Matrix-Vector oder MAtrixMAtrix-Multiplikation meinst.

Auf die Rechnung bin ich aber mal gespannt. Mit dem was man weiß, geht sich das nämlich niemals aus....

Sprich an irgend einer Stelle wird man kreativ zählen, oder aber massiv an Flexibilität einbüßen.

Das PRoblem ist doch wieder mal, das nVidia einen Marketingbegriff erfunden hat - TensorFlop - ohne ihn genau zu spezifizieren....

Aber statt große Reden zu schwingen und einem ans Bein pissen kannste mich ja mal gern aufklären, damit ich nicht dumm sterben muss....

PS: Genau so Leute wie du sind auch der Grund, warum ich hier weniger schreibe und euch auch das eine oder andere nicht stecke.

Nur noch ein kleiner Dämpfer für die nVidia Jünger, die an nVidias Craftsmanship glauben. GV100 ist nicht the big thing dieses Jahr. Und jetzt viel Spaß beim heulen/leugnen. Wir sprechen uns Anfang 2018 noch mal. Die Qulle ist ausgetrochnet...

scully1234

2017-05-13, 18:19:56

Sprich an irgend einer Stelle wird man kreativ zählen, oder aber massiv an Flexibilität einbüßen.
...

Mit anderen Worten ist das das Hintertürchen, falls es doch stimmen sollte oder wie?

Nur noch ein kleiner Dämpfer für die nVidia Jünger, die an nVidias Craftsmanship glauben. GV100 ist nicht the big thing dieses Jahr. Und jetzt viel Spaß beim heulen/leugnen. Wir sprechen uns Anfang 2018 noch mal. Die Qulle ist ausgetrochnet...

Entschuldigung aber du klingst schon genau so prophezeiend wie Horn

Einfach mal irgendwas in den Flur geworfen , ohne irgendwelche belastbaren Quellen

Mit der Hoffnung das sich in einem Jahr wo es dann ja konkret würde, sowieso keiner mehr daran erinnert was hier mal stand

Complicated

2017-05-13, 18:26:12

TOPS = Theoretische Rechenleistung
Interference/Sec = Praktische Rechenleistung

edit: Steht sogar so in den Kommentaren. Hätte man lesen können. Wenn man gewollt hätte :ugly:Schwachsinn-hättest du mal meinen Beitrag richtig gelesen:
Edit: Ach ich hab den kleinen Hinweis entdeckt - es sind doppelt soviele Inferences die unterhalb von 10ms Latenz liegen. Na also Nvidia-Mathe ;)

gravitationsfeld

2017-05-13, 18:31:10

Doch. Punkt. Man entwickelte bereits eine AI die sich selbst erweitern kann
Er sprach von Code. Es gibt keine AI die Code schreibt. Fertig aus.

AnnoDADDY

2017-05-13, 18:32:31

Er sprach von Code. Es gibt keine AI die Code schreibt. Fertig aus.

Und was macht sie dann wenn sie sich erweitert? Wird wahrscheinlich neuer Code sein. Ist nur ne Frage der Zeit das ganze.

Timbaloo

2017-05-13, 18:33:31

GV100 ist nicht the big thing dieses Jahr.

Wir sprechen uns Anfang 2018 noch mal.

https://static.superdeluxe.com/dankland/generators/when-your-mom-says-yaass--full.jpg

gravitationsfeld

2017-05-13, 18:34:55

Und was macht sie dann wenn sie sich erweitert? Wird wahrscheinlich neuer Code sein. Ist nur ne Frage der Zeit das ganze.
Es gibt keine AI die sich "erweitert". Es gibt nur neuronale Netze die ihre Gewichte aendern und vielleicht Neuronen hinzufuegen.

Nichts davon ist Code.

Klevapalis

2017-05-13, 19:23:57

Schwachsinn-hättest du mal meinen Beitrag richtig gelesen:
Interferences <10ms = praktische Leistung

Die TPU könnte theoretisch mehr, die ALUs verhungern aber mangels Speicherbandbreite.

AffenJack

2017-05-13, 19:54:01

Dann rechne mal vor, wie man auf 120 TFlops kommt, wenn man simple Matrixmultiplikation macht, wobei du auch mal genauer spezifizieren könntest, ob du jetzt Matrix-Scalar, Matrix-Vector oder MAtrixMAtrix-Multiplikation meinst.

Keine wirkliche Ahnung und ist auch nicht mein Gebiet. Aber ich vertraue einfach den Leuten die Ahnung haben und anscheinend nicht dran zweifeln. Die Tensor Units machen eine 4x4x4 Matrix Multiply+Accumulate. Daher verstehe ich darunter MatrixMatrixMultiplikation. Klingt für mich als Laie jetzt recht logisch nach 64FMA Operationen pro Tensor, bei 4x4 wären es eben 16. Sindwa also schon bei 128 Flops pro Tensor Unit, also 1024 Flops pro SM. Das mit 80 SM und dem Takt multiplizieren und du hast deine 120Tflops, soweit ich das verstehe.

Sprich an irgend einer Stelle wird man kreativ zählen, oder aber massiv an Flexibilität einbüßen.

Flexibel hört sich das für mich gar nicht an, aber solange es die DL Leute so brauchen reicht es auch aus.

Das PRoblem ist doch wieder mal, das nVidia einen Marketingbegriff erfunden hat - TensorFlop - ohne ihn genau zu spezifizieren....

Schau dir Googles TPU an. Die verwenden wohl genau die gleiche Definition und Intel wird es mit Lake Crest bestimmt auch tun

PS: Genau so Leute wie du sind auch der Grund, warum ich hier weniger schreibe und euch auch das eine oder andere nicht stecke.

Kann ich nix dafür. Ich kann es Leuten die keine Ahnung durchgehen lassen, wenn sie komisches Zeug schreiben, aber bei dir weiß ich dass du nicht dumm bist und Ahnung hast. Aber sobald du Nvidia liest ist da leider alles vorbei und es kommt ganzschön viel merkwürdiges Zeug.

Nur noch ein kleiner Dämpfer für die nVidia Jünger, die an nVidias Craftsmanship glauben. GV100 ist nicht the big thing dieses Jahr. Und jetzt viel Spaß beim heulen/leugnen. Wir sprechen uns Anfang 2018 noch mal. Die Qulle ist ausgetrochnet...

Es wird interessant wie Lake Crest wird, aber Intel müsste es schon derbe verhauen, wenn ein purer DL Beschleuniger GV100 nicht klar in diesem Einsatzgebiet schlägt bei den Tensorflops die du so gern magst:wink: Ich hoffe nur du redest nicht von Knights Mill, denn bei dem hab ich schon mehr Zweifel.

Achill

2017-05-13, 20:14:39

Sprich an irgend einer Stelle wird man kreativ zählen, oder aber massiv an Flexibilität einbüßen.

Mit anderen Worten ist das das Hintertürchen, falls es doch stimmen sollte oder wie?

Nein, es verhält sich wie mit den SIMD von heutigen CPUs. Die Daten und Algorithmen müssen passend dafür sein, damit diese Einheiten genutzt werden können / ein SWE muss dies explizit nutzen wollen - es ergibt sich nicht automatisch.

Daraus ergibt sich die Einschränkung und damit der Verlust von Flexibilität...

iuno

2017-05-13, 20:25:18

Wie kommst du überhaupt auf Matrikmultiplikation? Weder die Animation noch die Indizes legen das nahe, wenn könnte man noch übers Skalarprodukt sprechen.
Ich denke schon, dass es um Matrix-Matrixmultiplikation geht. A, B, C und D sind jeweils 4x4 Matrizen. Es wird auch nicht darum gehen, die Komplexitaet zu reduzieren. Ich denke man war da einfach auch bei der Visualisierung sehr kreativ. Ich nehme an, dass bei der Animation bei Pascal gemeint ist, dass man 4er SIMD hat und immer einen ganzen Vektor hernimmt. Das aendert aber natuerlich an der Komplexitaet nichts, liegt ja immer noch in O(n^3). Da man in dieser "Interpretation" schon nur noch 16 "Schritte" braucht, frage ich mich auch wo der 12x hoehere Durchsatz herkommt.

Kann man eigentlich die Int, FP64, FP32 und Tensor ALUs gleichzeitig verwenden oder nur jeweils ein Typ pro SM oder so? Bei Pascal gab es iirc auch Unklarheiten darueber, ob es ueberhaupt noch dedizierte FP64 ALUs sind, weil irgendwas nicht zusammengepasst hat, obwohl sie die Einheiten auch extra im Blockdiagramm aufmalen. Kann es

AffenJack

2017-05-13, 22:05:27

Ich denke schon, dass es um Matrix-Matrixmultiplikation geht. A, B, C und D sind jeweils 4x4 Matrizen. Es wird auch nicht darum gehen, die Komplexitaet zu reduzieren. Ich denke man war da einfach auch bei der Visualisierung sehr kreativ. Ich nehme an, dass bei der Animation bei Pascal gemeint ist, dass man 4er SIMD hat und immer einen ganzen Vektor hernimmt. Das aendert aber natuerlich an der Komplexitaet nichts, liegt ja immer noch in O(n^3). Da man in dieser "Interpretation" schon nur noch 16 "Schritte" braucht, frage ich mich auch wo der 12x hoehere Durchsatz herkommt.

Kann man eigentlich die Int, FP64, FP32 und Tensor ALUs gleichzeitig verwenden oder nur jeweils ein Typ pro SM oder so? Bei Pascal gab es iirc auch Unklarheiten darueber, ob es ueberhaupt noch dedizierte FP64 ALUs sind, weil irgendwas nicht zusammengepasst hat, obwohl sie die Einheiten auch extra im Blockdiagramm aufmalen. Kann es

Lass die Annimationen lieber bei Seite und lies dir eher das inside volta durch:https://devblogs.nvidia.com/parallelforall/inside-volta/

Die 12x Nummer ist ja selbst von der Berechnung Blödsinn, alleine schon dass man GP100 von 10,6 auf 10 runter rundet um im Vergleich zu 120Tflops auf 12x zu kommen. FP16 lässt man dann auch schön unter den Tisch fallen.

FP32 und INT32 gehen auf jeden Fall gleichzeitig, dass haben sie erwähnt. Arun bei b3d glaubt auch, dass Tensor plus FP gleichzeitig gehen müsste.
https://forum.beyond3d.com/posts/1980763/

MiamiNice

2017-05-13, 22:09:11

|MatMan|

2017-05-14, 01:46:09

:P Du brauchst mir sicherlich nicht erzählen, was eine Matrixmultiplikation ist :ucrazy:

Wie kommst du überhaupt auf Matrikmultiplikation? Weder die Animation noch die Indizes legen das nahe, wenn könnte man noch übers Skalarprodukt sprechen.

Ist aber am Ende SCHEIS egal, denn so lange nVidia nicht genau spezifiziert, WIE sie GENAU die Operationen zählen ist das mal voll fürn ARSCH....
Lies doch einfach den Blog von nVidia. Da steht explizit "Matrix-Matrix multiplication (BLAS GEMM)" und "Each Tensor Core performs 64 floating point FMA mixed-precision operations per clock" - aber es kann natürlich sein, dass nVidia das frei umdefiniert hat.

Es ist inzwischen einfach witzig zu lesen wie du abgehst, wenn es um nVidia geht :D

Hübie

2017-05-14, 02:50:42

Er sprach von Code. Es gibt keine AI die Code schreibt. Fertig aus.

Wer ist "Er"? :|
Und erzähl das mal Deep Mind Technologies und all den anderen Forscherteams in den USA, Deutschland, der Schweiz und sonst wo. Woher nimmst du denn bitte deine Gewissheit? :rolleyes:

Edit: Zur Anregung: https://www.technologyreview.com/s/603381/ai-software-learns-to-make-ai-software/

Leonidas

2017-05-14, 04:24:01

Mal zurückkommend auf die Gamer-Chips von Volta:
https://www.3dcenter.org/news/wie-nvidias-volta-gaming-chips-unter-der-12nm-fertigung-aussehen-koennten

GV102:
540-615mm²
6-9 Raster Engines
42-45 Shader-Cluster
384 Bit GDDR6 Interface

GV104:
360-390mm²
4-6 Raster Engines
28-30 Shader-Cluster
256 Bit GDDR6 Interface

GV106:
220-245mm²
2-3 Raster Engines
14-15 Shader-Cluster
192 Bit GDDR5X Interface

(hochgerechnet aus dem bekannten GP104 Die-Shot)

gravitationsfeld

2017-05-14, 05:03:12

Wer ist "Er"? :|
Und erzähl das mal Deep Mind Technologies und all den anderen Forscherteams in den USA, Deutschland, der Schweiz und sonst wo. Woher nimmst du denn bitte deine Gewissheit? :rolleyes:

Edit: Zur Anregung: https://www.technologyreview.com/s/603381/ai-software-learns-to-make-ai-software/
Es gibt keine AI die Software schreibt. Es gibt selbsterweiternde Machine-Learning-Modelle. Das ist etwas voellig anderes.

Digidi

2017-05-14, 09:25:19

Die Rasterizer- und Shaderanzahl von Gp100 und Gp102 waren ja gleich. Also wird wohl Gv102 genau so mit 6 Rasterizer und den 5200 Shadern kommen.

Fragman

2017-05-14, 12:00:09

...
384 Bit GDDR6 Interface

schliesst doch dann wieder 16gb karten aus, oder?

wobei, wenn sie den neuen ram verwenden wollen, rennen sie eh wieder in dieselbe falle wie schon bei pascal. ram ist zu teuer fuer mehr.

uweskw

2017-05-14, 12:11:54

Dann rechne mal vor, wie man auf 120 TF kommt ..

das ist das ist doch ganz einfach. Lass einen Marketing-Fuzzy rechnen. Die kommen auch bei einem 12V Autoradio für 29,00€ auf 1600 Watt:freak:
Alles Definitionssache.

was mich viel mehr interessiert, ist wieso sich Nvidia gezwungen sieht ein Risiko mit über 800 mm* einzugehen. Da ist wohl noch irgendetwas oder irgendwer im Hintergrund von dem wir noch recht wenig wissen.

Greetz
US

Skysnake

2017-05-14, 12:36:39

Lies doch einfach den Blog von nVidia. Da steht explizit "Matrix-Matrix multiplication (BLAS GEMM)" und "Each Tensor Core performs 64 floating point FMA mixed-precision operations per clock" - aber es kann natürlich sein, dass nVidia das frei umdefiniert hat.

Es ist inzwischen einfach witzig zu lesen wie du abgehst, wenn es um nVidia geht :D
Warum nicht gleich so? Nen link wäre zwar noch nett gewesen, aber so habe ich es auch gefunden. Die Seite hatte ich sogar mal offen, dann aber unabsichtlich zugemacht und nicht wieder gefunden....

Der Artikel ist auf jeden Fall erhellend, auch wenn nicht zwingend in allen belangen.

Nach der Lektüre kann man auf jeden Fall sagen, dass Sie nur Mul und Add zählen für die Matrix-Matrix Multiplikation plus die Additionen für den MAtrix-Addition, aber nicht die implizitien Type-Conversions, was man durchaus hätte machen können wenn man dieZahl noch weiter pushen wollte.

Vor allem ist mir jetzt auch mal klar geworden, was das 4x4x4 genau bedeutet, es ist die Dimension der drei Matrizen.... AxBxC -> matmul(A,B) + C Das hatten Sie auf dem DeepLearning Workshop von nVidia leider nicht erklärt...

Die Latenz der Cores wurde ja auf 4 cycles reduziert. Das passt ganz gut mit dem matmul der 4x4 Matrix zusammen. Man braucht für jedes Element nämlich 4 Multiplikationen und 3 Additionen, was man mit 4 FMA Instructionen gut abbilden kann. Man kann auch wunderbar shuffle Instructionen benutzen, um die Daten entsprechen anzupassen, wenn man die Berechnung eines Jeden Elements auf 4 Takte verteilt.

Eine TensorUnit besteht also wahrscheinlich aus 64 FP16 Cores equivalenten, bzw. einem Core, der eine SIMD64 Instruction ausführen kann. In dem Fall müssten dann immer 4 4x4x4 TensorOps inflight sein pro TensorUnit, damit man die Pipeline füllen kann. Das würde sich dann von den Datenabhängigkeiten mit den 4 Takten Latenz ausgehen.

Die FP32 Units der SMX (CudaCores) kann man dann verwenden um die MatrixMatrixAddition zu machen. Das geht sich dann auch aus.

Die Frage ist dann nur noch, woher die INT32 Ops herkommen, die man parallel zu den FP32 Instructionen ausführen kann. Man müsste mal schauen, wie groß der Addierer und Multiplizierer für FP64 ist. Eventuell würde das ja passen. Wenn ja, würde das dafür sprechen, das man zumindest hier doch dedizierte FP64 Units hat. Ich würde allerdings noch nicht darauf wetten, so lange man nicht weiß, das man statt INT32 auch FP64 Instructionen parallel zu den TensorOPs ausführen kann.

NAch den für mich neuen Infos würde ich von folgender Architektur ausgehen

16 FP32 Units pro SM, die auch FP64 können mit 2:1 Speed und daneben jeweils 2 Tensor Units, die MatMul für 4x4 Matrizen hardcoded haben mit FP16, wobei man immer 4 4x4 Matrizen gleichzeitig ausführen muss für maximalen Durchsat bzw. Peak.

Das wären dann also quasi 64 FP32 Units, die 2xFP16 pro Takt ausführen können. Also quasi 128 FP16 FMA Units.

So macht das durchaus Sinn und sieht auch vernünftig aus. Erwähnt werden sollte btw. auch mal, das man die TensorUnits wohl üder cuBLAS ansprechen wird können! Ok, dann nur mit FP16, was nicht sooo geil ist, aber immerhin kann man es direkt ansprechen! Das ist bei nVidia nicht selbstverständlich.

Soweit so gut also.
Kommen wir jetzt allerdings zu einem PRoblem. Wenn ich mich an den Workshop erinnere, und auch sonst mal z.B. hier reinschaue: http://image-net.org/challenges/talks/ilsvrc2015_deep_residual_learning_kaiminghe.pdf

Dann nutzt man eher 1x1, 3x3, 5x5 Matrizen und nicht 4x4 :freak:

Gut, wenn 4x4 so "billig" im Vergleich zum Rest wird, wird sich das eventuell ändern, aber ich bin mir nicht sicher, ob 4x4 wirklich optimal für heutige Netze ist. Das könnte eventuell auch der Grund sein, warum man nicht wirklich die LEistung auf die Straße bekommt, wenn man sich die Benchmarks zu den netzen anschaut.

scully1234

2017-05-14, 12:55:45

was mich viel mehr interessiert, ist wieso sich Nvidia gezwungen sieht ein Risiko mit über 800 mm* einzugehen. Da ist wohl noch irgendetwas oder irgendwer im Hintergrund von dem wir noch recht wenig wissen.

Greetz
US

Weil es Verträge gibt wie bei jedem anderen Unternehmen auch

Wenn der kleinerer Prozess nunmal noch nicht reif ist, so muss man die vorgesehenen Spezifikationen eben im alten Node gießen

Es scheint möglich ,und die amerikanischen Großrechner werden es vergüten ,allen voran Summit

uweskw

2017-05-14, 13:17:25

Weil es Verträge gibt wie bei jedem anderen Unternehmen auch.....

Verträge die NV zwingen über 800mm² in einem neuen Prozess zu gehen? Erscheint mir schwer nachvollziebar.

greetz
US

Complicated

2017-05-14, 13:17:47

was mich viel mehr interessiert, ist wieso sich Nvidia gezwungen sieht ein Risiko mit über 800 mm* einzugehen. Da ist wohl noch irgendetwas oder irgendwer im Hintergrund von dem wir noch recht wenig wissen.
Das ist IMHO ganz klar IBM - Sierra und Summit sollen 2017 hochfahren und Anfang 2018 für User verfügbar sein.

Aus 2014:
http://www.anandtech.com/show/8727/nvidia-ibm-supercomputers
Aus 2016:
https://www.nextplatform.com/2016/11/20/details-emerge-summit-power-tesla-ai-supercomputer/
Way back when, in early 2015, Nvidia said that it would be able to deliver Pascal GPUs with 32 GB of HBM memory on the package that delivered 1 TB/sec of bandwidth into and out of that GPU memory. What really happened was that Nvidia was only able to get 16 GB of memory on the package and only delivered 720 GB/sec of bandwidth with that on-package HBM with the Tesla P100 card. No one is making promises about the amount of GPU memory or bandwidth coming with Volta, as you can see above. What Nvidia has said, way back in 2015, is that the Volta GP100 GPUs would deliver a relative single precision floating general matrix multiply (SGEMM) of 72 gigaflops per watt, compared to 40 SGEMM gigaflops per watt for the Pascal GP100.

If you use that ratio, and then cut it in half for double precision, then a Volta GPU held at a constant 300 watts (the same as the Pascal package) would have a little over 9.5 teraflops of double precision performance, and four of them would deliver 38.2 teraflops of oomph, the vast majority of the more than 40 teraflops of performance expected in the Summit node.

Diese Ansage ist offensichtlich um 2 TFlops verfehlt worden mit 7,5 TFlops DP bei GV100. Aus dem Artikel geht auch hervor, dass deshalb die Node-Zahl erhöht wurde und auch das Powerbudget um 30% erhöht wurde. Selbiges gilt für Sierra. Ich denke Nvidia muss hier ganz schön Klimmzüge machen um das ganze ohne größere Verluste in trockene Tücher zu bringen bis 2018. Da spielt es keine Rolle ob man bei der Fertigung draufzahlt und da nimmt man auch schlechteste Yields in Kauf. Die Kosten wenn man Sierra und Summit ein Jahr verschieben müsste würden da um ein vielfaches größer sein. ich bin gespannt ob das irgendwie in den Büchern zu finden sein wird, oder ob das im Datacenter-Segment noch über die Margen abzufedern ist, solange man in der Timeline liefert.

scully1234

2017-05-14, 13:56:49

Ich denke Nvidia muss hier ganz schön Klimmzüge machen um das ganze ohne größere Verluste in trockene Tücher zu bringen bis 2018. .

So "Klimmzüge" das man meint in Q3 private Firmen zu versorgen mit dem Chip, mit denen man keine vertraglichen Bündnisse hat bisher.

Man scheint wohl doch etwas kostendeckender zu fahren , wie das Bild was du zeichnen möchtest

=Floi=

2017-05-14, 14:01:24

wie viele chips bekommt man eigentlich aus einem wafer?

Troyan

2017-05-14, 14:02:59

~65 Stück.

Kriton

2017-05-14, 14:13:30

(...)private Firmen zu versorgen mit dem Chip, mit denen man keine vertraglichen Bündnisse hat bisher.

Das wissen wir nicht.

scully1234

2017-05-14, 14:17:30

das wissen wir seit der Keynote

https://www.nvidia.com/en-us/data-center/dgx-1/?ncid=van-dgx-1

Auslieferung in Q3 bei sofortiger Bestellung hieß es da

Tesla V100 will become available starting from Q3 2017. A DGX-1 system powered by the new GPUs will set you back $149,000 for example. (http://hexus.net/tech/news/graphics/105562-nvidia-tesla-v100-volta-gv100-gpu-announced/)

Digidi

2017-05-14, 14:17:59

So "Klimmzüge" das man meint in Q3 private Firmen zu versorgen mit dem Chip, mit denen man keine vertraglichen Bündnisse hat bisher.

Man scheint wohl doch etwas kostendeckender zu fahren , wie das Bild was du zeichnen möchtest
Es geht um die Leistung und nicht um die Versorgungslage. Die haben bestimmt viele Chips. Aber die Chips bringen nicht die Leistung die Vertraglich zugesichert wurde.

Im übrigen sind solche Verträge daran schuld das es immer noch itanium von Intel gibt:

https://www.computerbase.de/2017-05/itanium-9700-kittson-intel-cpu/

Achill

2017-05-14, 14:23:52

So "Klimmzüge" das man meint in Q3 private Firmen zu versorgen mit dem Chip, mit denen man keine vertraglichen Bündnisse hat bisher.

Man scheint wohl doch etwas kostendeckender zu fahren , wie das Bild was du zeichnen möchtest

Das wissen wir nicht.

Sehe ich auch so...

Sierra und Summit sind ja vom US Department of Energy in Auftrag gegeben und sollen wohl 2017 fertig werden: https://video.golem.de/pc-hardware/14386/das-doe-und-nvidia-stellen-die-supercomputer-sierra-und-summit-vor.html

Bei sowas werden i.d.R. schon Verträge geschlossen ... und in den Staaten gibt es i.d.R. auch Strafzahlungen und keine Zuschüsse (wie in DE) wenn ein Projekt mal nicht so gut läuft / in Time ist.

--
Edit: Damit erscheint NVLink und das es von IBM mit gepushed wird, in einen ganz neuen Licht. Beide Firmen liefern die zwei neuen Super-Computer.

Eine interessante Frage ist dann, wie viel von den Auftrag/Aufträgen ggf. schon in den Büchern verbucht ist.

scully1234

2017-05-14, 14:32:50

Es geht um die Leistung und nicht um die Versorgungslage. Die haben bestimmt viele Chips. Aber die Chips bringen nicht die Leistung die Vertraglich zugesichert wurde.

Das weisst du woher?

Weil da mal 9,5 TFLOPs projiziert waren Anno Dazu Mal

Vielleicht hat man die Fläche für die Tensor Cores ja absichtlich geopfert ,weil es die Firmen gebraucht haben für ihre neuronalen Netze

Von denen war damals noch keine Rede...

Kriton

2017-05-14, 14:37:42

das wissen wir seit der Keynote

https://www.nvidia.com/en-us/data-center/dgx-1/?ncid=van-dgx-1

Auslieferung in Q3 bei sofortiger Bestellung hieß es da

Ich bezog mich auf Complicateds Anmerkungen.

Complicated

2017-05-14, 14:51:07

Das weisst du woher?

Weil da mal 9,5 TFLOPs projiziert waren Anno Dazu Mal

Vielleicht hat man die Fläche für die Tensor Cores ja absichtlich geopfert ,weil es die Firmen gebraucht haben für ihre neuronalen Netze

Von denen war damals noch keine Rede...
Also Nvidia hat 9,5 angekündigt und 7,5 geliefert. Das ist deutlich weniger als projiziert, da sind wir uns doch wohl einig. IBM erhöht darauf hin die GPU-Zahl pro Node auf 6 anstatt 4 GPUs. Ursprünglich (ISC 2015) hat Steve Oberlim (Nvidia CTO) 3.500 Nodes (noch mit 4 GPUs) für die Performance angekündigt:
https://www.nextplatform.com/2015/08/04/future-systems-pitting-fewer-fat-nodes-against-many-skinny-ones/
https://3s81si1s5ygj3mzby34dq6qf-wpengine.netdna-ssl.com/wp-content/uploads/2015/08/future-systems-nvidia-node-size.jpg

Während Ende 2016 daraus schon 6 GPUs pro Node und 4.500 Nodes wurden. Die Performance pro Node blieb bei 40 TFlops trotz 50% GPU zusätzlich. Der Verbrauch ist 30% hoch gegangen.

https://3s81si1s5ygj3mzby34dq6qf-wpengine.netdna-ssl.com/wp-content/uploads/2016/10/oak-ridge-summit.jpg

Digidi

2017-05-14, 15:10:40

Wahrscheinlich ist das dem Produktionsprozess geschuldet. Volta war für 7 nm geplant. Leider hat sich der 14nm Prozess schon so weit nach hinten verschoben das der 7nm auch noch verspätet anfingen.

Bin mal gespannt wie das weiter geht mit 7nm ist man schon so gut wie am Ende des möglichen angekommen. Jetzt kann es nur noch in die Breite gehen.

Complicated

2017-05-14, 15:19:10

Volta war eigentlich noch vor Pascal geplant, also ursprünglich sicher nicht in 7nm.
Siehe Roadmap aus 2014 https://www.heise.de/newsticker/meldung/Nvidia-Entwicklung-gebremst-Volta-wohl-noch-vor-2020-2160743.html
So tauchte der im Jahr 2013 als Maxwell-Nachfolger angekündigte Grafikchip "Volta" nicht mehr auf, stattdessen projizierte der Nvidia-Boss Jen-Hsun Huang "Pascal" für 2016 an die Wand. Auch vom ursprünglich für Maxwell geplanten "Unified Virtual Memory" war nichts mehr zu sehen, stattdessen soll Pascal "Unified Memory" bieten.

Auf Anfrage von heise online erklärte Nvidia, dass die GPU-Generation Volta aber nicht gestrichen sei, sondern erst nach Pascal erscheinen werde.

iuno

2017-05-14, 15:25:04

Namen sind nur Schall und Rauch. Volta war nie vor Pascal geplant, sondern Pascal wurde eingeschoben. Dazu ist Pascal auch noch das geworden, was urspr. fuer Maxwell geplant war. Folgerichtig verschiebt sich die ganze Roadmap. Wenn es um solche langfristige Projektionen geht, macht man das aber auch nicht an ein paar Zahlen an einem finalen Produkt fest.

Complicated

2017-05-14, 15:30:34

Also wenn Volta nie vor Pascal geplant war wie erklärst du dir dann dass Volta direkt nach Maxwell geplant war. Du kannst doch jetzt nicht hier hin stehen und behaupten die Roadmaps vor dem Juli 2014 haben nie existiert ^^. Und wenn Pascal "eingeschoben" wurde, wo wurde es dann eingeschoben? Vor Volta? Also sollte es dann wo kommen?

Ist doch nur wieder semantisches rumgezicke um vom Thema abzulenken. Volta ist mehrfach verschoben worden und vor allem sind die Features mehrfach verschoben worden. Und Volta war ursprünglich nicht für 7nm geplant als Maxwell-Nachfolger - und nur darum ging es doch in meinem Posting.

Und wenn Namen Schall und Rauch sind, dann sollten wir vielleicht alle Threads über Maxwell, Pascal und Volta zusammenführen, da wir sowieso über ein und das selbe reden?:freak:

Es ist jedenfalls nicht der Produktionsprozess daran Schuld, dass Nvidia erst mit Pascal die Features des für Maxwell versprochenen Chips geliefert hat. Es waren Nvidias Performance-Optimierungen die eben die Features gestrichen hat. Kurzfristig hat es sich ja enorm ausgezahlt, nun muss man sehen ob man das rechtzeitig doch noch integriert bekommt.

AffenJack

2017-05-14, 15:32:30

Achill

2017-05-14, 15:44:19

[..]
Die Nodeerhöhung hat damit aber nix zutun, denn sonst hätten auch 3700 Nodes gereicht. Irgendwer in der Regierung dachte sich aber wohl wir wollen 200 Tflops. Bei den für GV100 veröffentlichten Daten und 4500 Nodes ist man bei 205 Tflops :-) Womit die 30% Mehrverbrauch sich auch relativieren, da man 33% mehr Leistung als ursprünglich angenommen hat.

Ich würde das nicht so Verallgemeinern. Wenn jemand in der Regierung / ein Berater der DOE clever war, dann hat man beschrieben welche Datenmengen mit welchen Algorithmen in einer bestimmten Zeit verarbeiten werden können müssen.

Die Tflops sind peaks, damit ist nicht gegeben das diese auch im konkreten Modell/Fall erreicht werden.

Legt man dies als Annahme zugrunde, dann kann man die Erhöhung auch als Notwendiges Übel ansehen, um den Vertrag bzgl. real nutzbarer Rechenleistung zu erfüllen.

=Floi=

2017-05-14, 16:35:03

wäre man irgendwelchen verträgen hinterher, dann würde volta doch anders aussehen oder man hätte pascal GP102 geliefert. Es ergibt keinen sinn, weil so viel "schrott" für spezielle bereiche verbaut wurde. Hätte man druck gehabt hätte man das komplett weglassen oder verkleinern können.

Blediator16

2017-05-14, 16:45:45

Hast du jemals eine GPU von egal welchem GPU Entwickler gesehen, die so riesig war? Ich kann mir kaum vorstellen, dass Nvidia sich dachte "komm warten wir ab bis wir kaum noch kleinere Transistoren bauen lassen können und dann blasen wir die GPU so auf wie noch nie und riskieren damit die miesesten Yiels ever".

Das kann kein Zufall sein, als eine Notfalllösung für welche Probleme es da auch gab.

Troyan

2017-05-14, 16:48:25

Es gab keine Probleme. Hier bringt nVidia innerhalb von 12 Monaten eine neue GPU auf den Markt, die den Vorgänger um 40%+ schlägt. Der Konkurrent ist noch nichtmal in der Lage eine 16nm GPU zu bringen, die besser ist als das 28nm Zeug der Konkurrenz.

Wenn man 815mm^2 produzieren kann, dann macht man das.

dildo4u

2017-05-14, 16:53:17

Complicated

2017-05-14, 17:02:07

Der Konkurrent ist noch nichtmal in der Lage eine 16nm GPU zu bringen, die besser ist als das 28nm Zeug der Konkurrenz.
Ja das stimmt - Schande über AMD, dass sie niemals ein 16nm Design in der Pipeline hatten ;D Völliges Unvermögen.

Schaffe89

2017-05-14, 17:11:00

Volta war eigentlich noch vor Pascal geplant, also ursprünglich sicher nicht in 7nm.
Siehe Roadmap aus 2014 https://www.heise.de/newsticker/meldung/Nvidia-Entwicklung-gebremst-Volta-wohl-noch-vor-2020-2160743.html

Pascal wurde eingeschoben, ansonsten wären Volta und Pscal ja wohl gleichzeitig gekommen.
Volta vor Pascal geplant? Wie kommt man nur auf sonen kruden Unsinn?:rolleyes:
Wie immer gehts maximal darum Nvidia schlecht zu machen. Leg mal ne andere Schallplatte auf.

Troyan

2017-05-14, 17:14:15

Ja das stimmt - Schande über AMD, dass sie niemals ein 16nm Design in der Pipeline hatten ;D Völliges Unvermögen.

Ach, Polaris10 ist besser als GM200? Wobei, beim Stromverbrauch stimmt das. ;D

nVidia produziert seit letztem Jahr 470mm^2 und 610mm^2 16nm Dies. AMD kann nichtmal einen 500m^2 Die vernünftig in den Markt bringen und Typen wie du faseln hier von "Problemen" bei Volta.

nVidia kann solche Dies produzieren. Damit ist das Thema beendet.

Vermutlich war das damals ohne Tensor Cores geplant,die werden ordentlich Die Space belegen.

Nope. GV100 ist 34% größer und bietet 50% mehr Ausführungseinheiten. Und diese wiederum sind komplexer als bei GP100. Ausführungseinheiten an sich kosten kaum Fläche. Alles drum herum ist viel teurer.

scully1234

2017-05-14, 17:18:40

Volta vor Pascal geplant? Wie kommt man nur auf sonen kruden Unsinn?:rolleyes:
.

http://www.fudzilla.com/media/k2/items/cache/76ec6b67ba35a301572c1bae863f320e_XL.jpg

was siehst du da nach Maxwell ?

Also ja er hatte damit schon recht, und das wurde auch oft genug diskutiert ,das man Pascal vorgezogen hat
Vermutlich war das damals ohne Tensor Cores geplant,die werden ordentlich Die Space belegen.

sagte ich ja bereits nur ist man darauf gar nicht eingegangen

Was wäre denn wenn man dedizierte FP64 Einheiten geopfert hat, zu Gunsten der Tensor Cores

Complicated

2017-05-14, 17:24:44

Volta vor Pascal geplant? Wie kommt man nur auf sonen kruden Unsinn?:rolleyes:
Wie immer gehts maximal darum Nvidia schlecht zu machen. Leg mal ne andere Schallplatte auf.
Wie immer bist du einfach nicht im Bilde. Die Roadmap die Scully1234 verlinkt hat stammt aus 2013.

Schaffe89

2017-05-14, 18:39:16

Also ja er hatte damit schon recht, und das wurde auch oft genug diskutiert ,das man Pascal vorgezogen hat

Pascal steht dort nirgends auf den Folien, woher will er wissen, dass Pascal nach Volta geplant war?:confused:
Das ist nichts als eine Spekulation und auf die kann man bekanntlich nix geben.
Wäre Pascal nach Volta eingezeichnet, dann würde es Sinn machen, aber so ist Pascal einfach ein zwischenSchritt zwischen Maxwell und Volta, das sieht man alleine schon an den ganzen Verbesserungen die Volta gegenüber Pascal besitzt.

scully1234

2017-05-14, 19:07:21

Pascal steht dort nirgends auf den Folien, woher will er wissen, dass Pascal nach Volta geplant war?:confused:
.
https://www.heise.de/newsticker/meldung/Nvidia-Entwicklung-gebremst-Volta-wohl-noch-vor-2020-2160743.html

HOT

2017-05-14, 19:10:23

AFAIK war das ursprünglich Kepler - Maxwell - Einstein - Volta.
Da war Maxwell sicherlich noch als reines DX11-Produkt geplant (die LowLevel-APIs kamen ja erst im Jahr 2013 überhaupt auf), Einstein quasi als 20nm-Maxwell und Volta dann ein 14nm-Produkt, damals dachte man ja, dass auch TSMC auf 14nm geht.
Daraus wurde Kepler - Maxwell (nur ein Produkt) - Maxwell 2 (kein 20nm) - Volta. Letztendlich wurde dann aber noch ein 16nm-Maxwell2 für Consumer-Markt eingeschoben, genannt Pascal, also
Kepler - Maxwell (nur ein Produkt) - Maxwell2 - Pascal - Volta.

Mancko

2017-05-14, 19:10:38

Pascal war ein reiner Zwischenschieber. Der war nicht nach Volta geplant. Der war ursprünglich überhaupt nicht geplant und auf keiner Roadmap. Diverse Leute die sich auskennen und nah an Nvidia und auch TSMC drann sind haben das schon öfters bestätigt.

Die Verschiebung der Fertigungsprozesse hatten Nvidia dazu gezwungen hier umzuplanen. Das ist nun mal so. Darauf müssen Nvidia und AMD immer wieder reagieren. Fakt ist aber, dass Nvidia seit Maxwell eindeutig beweist wie Geräusch- und Problemlos sie Produkte auf neuen Fertigungsprozessen zum Teil auch in unterschiedlichen Foundries und mit zum Teil recht großen GPUs herausbringen. Das dürfte AMD am meißten Kopfschmerzen machen.

scully1234

2017-05-14, 19:19:38

Pascal war ein reiner Zwischenschieber. .

Ob nun Zwischenschieber oder nicht, fakt ist jedenfalls das Volta ursprünglich vor dieser Generation ,unmittelbar nach Maxwell ins Rennen gehen sollte.

Also ja er war vor Pascal eingeplant

Was nun der Grund dafür war Volta zu verschieben, ist da auch erstmal zweitrangig. Aber vielleicht plaudert Jensen ja irgendwann mal wieder aus dem Nähkästchen warum und wieso

Mancko

2017-05-14, 19:21:56

Ob nun Zwischenschieber oder nicht, fakt ist jedenfalls das Volta ursprünglich vor dieser Generation ,unmittelbar nach Maxwell ins Rennen gehen sollte

Das habe ich auch gar nicht bestritten. Ich habe doch gesagt, dass Verzögerungen bei den Fertigungsprozessen bzw. den nicht einzuhaltenden Projektionen dazu geführt haben. Sowas gibt es nun mal. Umso beeindruckender wie gut und wie verlässlich Nvidia auf sowas reagiert.

MiamiNice

2017-05-14, 19:38:12

Skysnake

2017-05-14, 20:10:31

Also Nvidia hat 9,5 angekündigt und 7,5 geliefert. Das ist deutlich weniger als projiziert, da sind wir uns doch wohl einig. IBM erhöht darauf hin die GPU-Zahl pro Node auf 6 anstatt 4 GPUs. Ursprünglich (ISC 2015) hat Steve Oberlim (Nvidia CTO) 3.500 Nodes (noch mit 4 GPUs) für die Performance angekündigt:
https://www.nextplatform.com/2015/08/04/future-systems-pitting-fewer-fat-nodes-against-many-skinny-ones/
https://3s81si1s5ygj3mzby34dq6qf-wpengine.netdna-ssl.com/wp-content/uploads/2015/08/future-systems-nvidia-node-size.jpg

Während Ende 2016 daraus schon 6 GPUs pro Node und 4.500 Nodes wurden. Die Performance pro Node blieb bei 40 TFlops trotz 50% GPU zusätzlich. Der Verbrauch ist 30% hoch gegangen.

https://3s81si1s5ygj3mzby34dq6qf-wpengine.netdna-ssl.com/wp-content/uploads/2016/10/oak-ridge-summit.jpg
Jo, das hat man nicht halten können, da es den Nodeshrink auf 10nm nicht gab. Deswegen wurden 6 GPUs pro Node reingehauen. Die Nodeerhöhung hat damit aber nix zutun, denn sonst hätten auch 3700 Nodes gereicht. Irgendwer in der Regierung dachte sich aber wohl wir wollen 200 Tflops. Bei den für GV100 veröffentlichten Daten und 4500 Nodes ist man bei 205 Tflops :-) Womit die 30% Mehrverbrauch sich auch relativieren, da man 33% mehr Leistung als ursprünglich angenommen hat.

Bei solchen Systemen sind die Angaben bei der Leistung etc eh nicht star. Man kann einfach vorher nie vorraussehen wie sich das entwickelt. Man wollte ja auch deutlich mehr NV-Memory als man am Ende bekommen hat. Im Laufe des Projektes sieht man dann wo es hingeht und man versucht etwa bei den Zielvorgaben rauszukommen.
NAja, das würde ich nicht so einfach von der HAnd schieben. Von was du ja meines Wissens nach da sprichst sind die PeakFlops. Die werden in solchen Verträgen aber normal nicht fixiert, sondern z.B. die Linpack Ergebnisse, oder von sonst irgend einem Benchmark.

Genau da hat Pascal aber z.B. entgegen aller erwartungen nach in Linpack ein ziemlich schwaches Ergebnis abgeliefert. Trotz der ganzen Änderungen, die eigentlich die Effizienz (LinpackFlops/PeakFlops) hätten steigern sollen im Vergleich zu Kepler, ist sie sogar gesunken.

Btw. bei Intel und KNL ist Sie auch ziemlich enttäuschend und für Skylake muss man das Gleiche erwarten. Sprich, obwohl man viel tut und vor allem die Peak-Flops sich gut entwickeln, kommt hinten nicht das raus, was man erwartet, was sich zu einem echten Problem entwickelt, denn Linpack ist nun wirklich tot optimiert und im Vergleich zu echten Applikationen meist verdammt gutartig.

Complicated

2017-05-14, 20:19:27

Pascal steht dort nirgends auf den Folien, woher will er wissen, dass Pascal nach Volta geplant war?:confused:

Pascal war ein reiner Zwischenschieber. Der war nicht nach Volta geplant.
Also ihr seid die besten Trolle hier überhaupt. :freak:

Ich schreibe Volta wurde nach hinten verschoben und war deshalb nicht in 7nm geplant. Und ihr stürzt euch darauf ich hätte geschrieben Pascal wäre irgendwann später geplant gewesen - spielt das denn eine Rolle ob Pascal ein "Zwischenschieber" war oder tatsächlich geplant war nach Volta? Ist Volta deshalb nicht verschoben worden wie in den Links belegt? Ist Volta deshalb doch in 7nm geplant gewesen in 2014?

Rabulistik in Reinform und eine Diskussion über etwas vom Zaun brechen das überhaupt keiner Diskussion würdig ist.

Wurde denn nun Volta NICHT verschoben eurer Meinung nach? Und wurde Volta ursprünglich auf 7nm geplant? Na los jetzt, reitet das Pferd bis es umkippt.

Nur zur Erinnerung worum es eigentlich geht hier:
Wahrscheinlich ist das dem Produktionsprozess geschuldet. Volta war für 7 nm geplant. Leider hat sich der 14nm Prozess schon so weit nach hinten verschoben das der 7nm auch noch verspätet anfingen.
Volta war eigentlich noch vor Pascal geplant, also ursprünglich sicher nicht in 7nm.
Siehe Roadmap aus 2014 https://www.heise.de/newsticker/meldung/Nvidia-Entwicklung-gebremst-Volta-wohl-noch-vor-2020-2160743.html
Und damit sollte das auch gut sein und bitte zurück zum Thema.

Digidi

2017-05-14, 20:58:40

Ich glaube Volta war Ursprünglich nicht für 7nm geplant, nachdem Pascal eingefügt wurde dann aber schon. Und jetzt geht man auf 12nm nur um noch etwas zu retten.

fondness

2017-05-14, 21:28:05

Ach, Polaris10 ist besser als GM200? Wobei, beim Stromverbrauch stimmt das. ;D

nVidia produziert seit letztem Jahr 470mm^2 und 610mm^2 16nm Dies. AMD kann nichtmal einen 500m^2 Die vernünftig in den Markt bringen und Typen wie du faseln hier von "Problemen" bei Volta.

nVidia kann solche Dies produzieren. Damit ist das Thema beendet.

NV hat keine Foundry und produziert gar nichts. Damit ist das Thema beendet.

Schaffe89

2017-05-14, 21:52:34

https://www.heise.de/newsticker/meldung/Nvidia-Entwicklung-gebremst-Volta-wohl-noch-vor-2020-2160743.html

Auch in dem Link steht da nix davon was Complicated behauptet.

Ob nun Zwischenschieber oder nicht, fakt ist jedenfalls das Volta ursprünglich vor dieser Generation ,unmittelbar nach Maxwell ins Rennen gehen sollte.Also ja er war vor Pascal eingeplant

Pascal gab es ja überhaupt nicht, demnach kann Volta auch nicht vor Pascal eingeplant worden sein. Es haben sich wie so oft einfach die Planungen nach hinten verschoben, da die Fertigungsprozesse auch nicht so gekommen sind wie geplant.
Wieder mal ne absolut sinnlose Debatte. Von mir aus war Volta auch vor Kepler eingeplant. Sowas von egal.
Also ihr seid die besten Trolle hier überhaupt.

Du bist derjeniege der hier Spekulationen als Fakten verkauft und wieder mal hereintrollt.
Du wusstest ganz genau bevor du diesen Schmarrn abgelassen hast, dass das wieder einfach mal nicht stimmt.

spielt das denn eine Rolle ob Pascal ein "Zwischenschieber" war oder tatsächlich geplant war nach Volta?

Wer will denn hier außer dir bitte bestreiten, dass Pascal ein Zwischenschieber war. Ich hoffe doch niemand. Eigentlich spielt sowas überhaupt keine Rolle.
Das spielt erst eine Rolle nachdem du wieder so No-Brainer raushaust wie hier.
Iuno hat schon alles relevante direkt nach deinem Beitrag gesagt aber du musst wieder sinnlos widersprechen.

Skysnake

2017-05-14, 22:02:25

Ich habe mir mal das Bild vom GV100 von http://www.anandtech.com/show/11367/nvidia-volta-unveiled-gv100-gpu-and-tesla-v100-accelerator-announced geschnappt und analysiert.

1. Schritt perspektivische Entzerrung mittels Gimp
2. Farbkurve korrigiert (jetzt sieht man auch deutlich, das man neben der eigentlich GPU und dem HBM2 jeweils noch an den Ecken kleine extra DIEs hat. Oben sieht man die horizontalen Abtrennungen und unten recht die verticale. Da sind also insgesamt wohl 9 DIEs auf dem Interposer. )
3. Ausmessen der Dimensionen vom HBM2 (109x102 oben rechts, 109x105 unten rechts, 111x105 unten links, 112x103 oben rechts, also im Schnitt 110x104 Pixel)
4. Ausmessen der Dimensionen vom GPU DIE (367x294)
5. Aus http://www.anandtech.com/show/9969/jedec-publishes-hbm2-specification habe ich die Spezifikation von HBM2 mit 7,75mm x 11,87mm = 91,9925mm²
6. Berechnen der Fläche pro Pixel 91,9925/(110*104)=0,0080424 mm²/Pixel

Wenn man jetzt aber die Verhältnisse aus 3. und 5 nimmt, dann kommt man einmal auf 1:1,06 für HBM2 auf GV100 und das andere mal 1:1,53 laut Spec.

Gehen wir also mal davon aus, das aus welchen Gründen auch immer, der klar ersichtliche horizontale Strich doch keinen extra DIE markiert, sondern auch zum HBM2 gehört, dann kommen wir auf

or: 123x113
ur: 125x111
ul: 124x112
ol: 127x110
avg: 124,75x111,5

Damit kommen wir aber gerade mal auf 1:1,12.

Also das passt vorne und hinten nicht zusammen mit den Spezifikationen von HBM2. Oder ist die Spezifikation, die ich habe völlig veraltet und damit falsch???

Da passt doch irgendetwas vorne und hinten nicht. Womit man allerdings dann auch keine Schätzung der DIE size machen kann. Mit den Werten würde ich dann nämlich über 860mm² kommen...

EDIT: hier sieht man auch nochmals die extra DIEs ziemlich gut:https://1.f.ix.de/imgs/18/2/1/9/9/2/6/9/Volta-3165e75150c08d02.jpeg

Für mich sieht das von den Reflexionen her nicht so aus, als ob das der Interposer drunter wäre

EDIT2:
Ok ich habe das Ganze nochmals mit dem Bild aus dem letzten Link wiederholt, da komme ich jetzt auf einen Faktor 1:2,8 Sprich das perspektive korrigieren verzerrt alles völlig -.- Das kann man also total vergessen...

Man kann aber wohl davon ausgehen, dass der DIE wirklich über 800mm² groß ist. Krasses teil also. Ich bin ja eigentlich davon ausgegangen, dass Sie den Interposer gemessen hätten, aber der scheint nochmals deutlich größer zu sein. Die spannende Frage ist jetzt natürlich noch, was die Dinger unter/über den HBM2 stacks sind.

AffenJack

2017-05-14, 22:06:40

NAja, das würde ich nicht so einfach von der HAnd schieben. Von was du ja meines Wissens nach da sprichst sind die PeakFlops. Die werden in solchen Verträgen aber normal nicht fixiert, sondern z.B. die Linpack Ergebnisse, oder von sonst irgend einem Benchmark.

Genau da hat Pascal aber z.B. entgegen aller erwartungen nach in Linpack ein ziemlich schwaches Ergebnis abgeliefert. Trotz der ganzen Änderungen, die eigentlich die Effizienz (LinpackFlops/PeakFlops) hätten steigern sollen im Vergleich zu Kepler, ist sie sogar gesunken.

Btw. bei Intel und KNL ist Sie auch ziemlich enttäuschend und für Skylake muss man das Gleiche erwarten. Sprich, obwohl man viel tut und vor allem die Peak-Flops sich gut entwickeln, kommt hinten nicht das raus, was man erwartet, was sich zu einem echten Problem entwickelt, denn Linpack ist nun wirklich tot optimiert und im Vergleich zu echten Applikationen meist verdammt gutartig.

Das mit Linpack etc stimmt natürlich, aber ich glaube nicht, dass dies bei der Ursprungsplanung groß anders war. Nvidia sollte die Effizienz da schon ziemlich gut einschätzen können, schließlich simuliert man solche Chips doch. Klar kann es dann etwas darunter liegen, aber ich glaube nicht, dass man da fundamental anders geplant hat. Es ist ja auch alles eine Frage des ganzen Drumrums mit Interconnects usw. oder spielen die bei Linpack nicht so eine Rolle?

Zu den kleinen Minidies an den Ecken, können das vielleicht irgendwie Spacer sein aus welchem Grund auch immer? Zum HBM gehört das Zeug nicht.

Schaffe89

2017-05-14, 22:09:30

Also wenn Volta nie vor Pascal geplant war wie erklärst du dir dann dass Volta direkt nach Maxwell geplant war.

Mal dir mal einen Zeitstrahl auf Papier und dann überlege wie sowas passieren kann.

Volta ist mehrfach verschoben worden und vor allem sind die Features mehrfach verschoben worden.

Ach was natürlich ist da was verschoben worden und zwar nach hinten, was Platz für den Zwischenschieber Pascal machte, der ganz grob gesagt ein Shrink von Maxwell und angepassten Taktraten ist.
Wie zur Hölle soll Volta vor Pascal geplant gewesen sein, wenn Pascal überhaupt nicht auf der alten Roadmap drauf ist und von der Grafik IP her weit hinter Volta hinterherhinkt.

Ersetz doch deine Planungsaussagen einfach mal mit einem Datum, anstatt mit Codenamen, dann machts auch Sinn.
Wie "Volta war noch vor 2016 ursprünglich geplant." Oder sowas. Volta vor Pascal verwirrt nur und genau so wars in deinen Gedankengängen auch geplant um wieder ne völlig hirnlose Diskussion anzuzetteln.

Ist doch nur wieder semantisches rumgezicke um vom Thema abzulenken.

Ja aber von dir, nicht von anderen.

Kepler-Maxwell--Volta wurde eben Kepler-Maxwell-Pascal-Volta und es war kein Kepler-Maxwell-Volta-Pascal geplant, so wie du dich wieder in Polemik verstrickst und dann anderen semantisches rumgezicke vorwirfst.
Am ende heißts nämlich wieder das hättest du nicht gesagt, aber genau das hast du und das war auch der einzige Punkt in dem es in der Diskussion ging.
Auszudrücken dass Volta sich verschoben hat, hätte man auch ganz einfach mit einem Datum angeben können. Ergo 2014 fürhestens vielleicht mal geplant und dann auf 2017 hinausgezögert oder was auch immer.
Dass sich Volta verschoben hat, hat übrigens hier niemand bestritten, so wie du es wieder meinst gelesen zu haben.

Skysnake

2017-05-14, 22:20:35

Das mit Linpack etc stimmt natürlich, aber ich glaube nicht, dass dies bei der Ursprungsplanung groß anders war. Nvidia sollte die Effizienz da schon ziemlich gut einschätzen können, schließlich simuliert man solche Chips doch. Klar kann es dann etwas darunter liegen, aber ich glaube nicht, dass man da fundamental anders geplant hat. Es ist ja auch alles eine Frage des ganzen Drumrums mit Interconnects usw. oder spielen die bei Linpack nicht so eine Rolle?

Ne, das ist ja das "schöne" an Linpack, der Rechenaufwand (Volumen) steigt schneller als die Datenmenge (Oberfläche), die du kommunizieren musst. Das ist ja auch ein Grund, warum man den Speicher meist ziemlich vollknallt. Damit wird die einzelne Berechnung zwar sehr langsam, aber der Interconnect etc. werden ziemlich irrelevant. Viel Speicher hilft hier viel ;)

Das ist schon ein Problem an Linpack, was auch diskuttiert wird. Das fatale ist halt, das man die Flop-Effizienz nicht steigern konnte, sondern diese sogar gesunken ist. Das konnte man wirklich nicht erwarten und halt sicherlich außerhalb von nVidia keiner erwartet.

Bei derartigen Projekten, wo man ja Produkte kauft, die es noch gar nicht gibt, kauft man immer die Katze im Sack.... Und da rechnet man immer mit dem, was man aus der Erfahrung heraus annehmen kann, und das hier für Pascal mindestens die Effizienz von Kepler. Real ist es aber eben dann doch schlechter geworden als der Worstcase, was ich bzw. bis heute noch nicht verstehe!

Zu den kleinen Minidies an den Ecken, können das vielleicht irgendwie Spacer sein aus welchem Grund auch immer? Zum HBM gehört das Zeug nicht.
Kann sein. HBM und damit die Interposer, machen wohl durchaus thermische Probleme. Kann also sein, dass das zur Stabilisierung des gesamten Packages dient, oder als zusätzliche Kühlerauflagefläche. Keine Ahnung.

Die Idee klingt aber auf jeden Fall mal vernünftig. :up:

Troyan

2017-05-15, 00:36:28

NV hat keine Foundry und produziert gar nichts. Damit ist das Thema beendet.

Deswegen haben GP107 und Polaris 11 auch die selbe Charakteristik bzgl. Taktbarkeit und Stromverbrauch. :rolleyes:

Und TSMC hat extra Anpassung für nVidia beim "12"nm FF Prozess umgesetzt.

Hübie

2017-05-15, 00:52:45

Man habt ihr Langeweile. 2013 war Pascal weder vor, noch nach Volta geplant. Ich erzähl mal kurz was ich weiß:
2011 merkte man, dass Kepler doch ein weitaus größerer Wurf als gedacht. HPC wurde ein festes Standbein und so entschied man für diesen Markt zu entwickeln (!). Der Plan war: Kepler -> Maxwell (anfangs sogar in 20 nm geplant, dann auf Volta geschoben und letztlich für HPC verworfen) -> Volta (1st HPC Chip) -> next Gen. Der Name Pascal fiel da nicht. 20 nm war nicht rentabel für große Designs und so blieb Maxwell auf 28 nm. 2013/14, zwei Jahre später merkte man, dass die Anforderungen für HPC (im speziellen machine learning) extrem ambitioniert waren und man unmöglich die Ziele erreichen konnte und außerdem nicht die Ressourcen hatte. Also hat man aus dem was wir als Volta kennen Projekte abgespalten und in 2,5 Jahren Pascal auf die Beine gestellt. Also ist Pascal so was wie Volta 0.5. Das wurde 2014 dann so eingeschoben und fest mit enger Kooperation von TSMC in 16 nm durchgeführt (samt den Designrules). Nun wusste man auch schon was das Design leisten kann und nannte den Wurf nach Maxwell, Pascal, dann Volta und anschließend Einstein. Pascal kam also aus heiterem Himmel aus diversen Gründen dazwischen. Ist schon etwas komplizierter in der Summe, aber irrelevant. Alberne Diskussion.

Thema AI können wir woanders besprechen. Am MIT wurde einer AI gelehrt Programmiersprachen zu lernen und die konnte dann einen Sortieralgorithmus durch samples schreiben. Vielleicht finde ich den Artikel. Gn8.

iuno

2017-05-15, 04:06:15

Kann sein. HBM und damit die Interposer, machen wohl durchaus thermische Probleme. Kann also sein, dass das zur Stabilisierung des gesamten Packages dient, oder als zusätzliche Kühlerauflagefläche. Keine Ahnung.
Hatte mich auch schon gefragt, wozu das ist. Das sieht man auf den Bildern eigentlich ganz gut.

Bei GP100 hatten sie aber auch schon so ein "Fuellmaterial" zwischen den Chips, damit die Oberflaeche plan ist. Auch die Stacks sind ja in der Hoehe so gemacht, das sie genauso hoch sind wie die GPU, was bei Fiji afaik auch nicht der Fall war. Dieses Material sieht man aber auch bei V100 (zwischen den Chips und komplett aussen rum), daher wuerde ich eigentlich schon annehmen, dass das was wie weitere Minidice aussieht, irgendeine besondere Funktion hat.
Der "dieshot" hilft hier allerdings auch kein bisschen weiter, der ist ja nicht mal richtig rum :ugly:

https://pics.computerbase.de/7/8/1/0/6/9-1080.3675311377.jpg

https://scr3.golem.de/screenshots/1705/Nvidia-Volta-GV100/Nvidia-Volta-GV100-02.jpg

Leonidas

2017-05-15, 04:46:54

Ich bin ja eigentlich davon ausgegangen, dass Sie den Interposer gemessen hätten, aber der scheint nochmals deutlich größer zu sein. Die spannende Frage ist jetzt natürlich noch, was die Dinger unter/über den HBM2 stacks sind.

Dazu gab es mehrfach klare Aussagen, das NV sogar zwei Interposer verwenden muß, weil einer nicht mehr reicht. Zum Vergleich: Interposer bei Fiji war 1011mm² und damit schon grenzwertig.

Skysnake

2017-05-15, 07:55:52

Sie meinten, Sie müssten das Ding zwei mal Belichten, aber das es 2 Interposer sind, wäre mir neu.

Und selbst wenn dem so wäre, man sieht ja insgesamt 9 DIEs auf dem eigentlichen Interposer. 1xGPU + 4xHBM2 +4xdie seltsamen Dinger über/unter den HBMs

HOT

2017-05-15, 09:29:14

Das mit den 2 Interposern wird schon stimmen, wenn der einfach zu groß ist.

Complicated

2017-05-15, 09:32:56

Die 16nm Designs von AMD konnten bisher nicht mal der 28nm Generation von NVIDIA das Wasser reichen. Und die Aussage ist völlig korrekt.
Mal wieder keine Fakten gelernt - Es gibt keine 16nm Designs von AMD - setzen sechs. Weder Samsung noch GF haben eine 16nm Fertigung. Gibt es so etwas wie ein Troll-Trainingszentrum wo ihr den Unsinn gemeinsam lernt?

@Topic
"Zusatz-Dies" beim Volta Package sind mit ziemlicher Sicherheit "Spacer" oder auch Füllmaterial. Wie iuno schon schrieb wurde es auch bei Pascal schon genutzt. Ich vermute hier wurde nun optimiert wegen den mechanischen Druckpunkten und stabilisiert über den ganzen Interposer hinweg. Zu Pascal gab es mal diese schematische Darstellung:
http://www.planet3dnow.de/vbulletin/threads/422600-AMD-Interposer-Strategie-Zen-Fiji-HBM-und-Logic-ICs/page7
http://pics.computerbase.de/7/1/5/8/3/15-1080.1731623009.jpg

Dass es zwei Interposer sind wäre mir auch neu, allerdings würde es mich nicht überraschen bei der Größenordnung - Fiji soll damals am Limit gewesen sein was einzelne Interposer-Fläche angeht. Es würde auch diese zusätzlichen Stabilisierungs-Füllungen gut ins Bild passen. Die Frage ist ob Nvidia nun "stiched Interposer" verwendet. Darauf hat Altera ein Patent: https://www.google.com/patents/US20140175666

AffenJack

2017-05-15, 09:33:08

Klevapalis

2017-05-15, 09:37:46

Mal wieder keine Fakten gelernt - Es gibt keine 16nm Designs von AMD - setzen sechs. Weder Samsung noch GF haben eine 16nm Fertigung. Gibt es so etwas wie ein Troll-Trainingszentrum wo ihr den Unsinn gemeinsam lernt?
Ach so, du weißt nicht, dass defakto GF/Samsung 14nm = TSMC 16nm sind und denkst jetzt, dich mit solchen Klugscheissereien als besonders belesen heraus kristallisieren zu können. ;D

Na wenn du meinst :ugly:

Das mit den 2 Interposern hat Golem geschrieben nach dem Deap Dive. Aber Ryan von Anandtech meinte, dass dies falsch ist und er in der gleichen Präsentation mit saß. Stattdessen wird 2 mal belichtet. Ich vertraue einem native Speaker da mehr, ist wohl eher ein Übersetzungsfehler.
Wenn es tatsächlich zwei Interposer wären, müsste man das sehen. Auf den Bildern ist es aber eine durchgehende Fläche.

HOT

2017-05-15, 09:40:11

Doch es gibt 16nm Designs, von Sony und Microsoft.

Complicated

2017-05-15, 09:50:34

Ach so, du weißt nicht, dass defakto GF/Samsung 14nm = TSMC 16nm sind und denkst jetzt, dich mit solchen Klugscheissereien als besonders belesen heraus kristallisieren zu können. ;D
So ein Bullshit:
http://cms.edn.com/ContentEETimes/Images/EETimes_cte/Linley%20node%20table%20x%20800.png

wie man an Apples A9 wohl deutlich sehen kann ist es nicht das selbe.
Doch es gibt 16nm Designs, von Sony und Microsoft.
Und mit welchem Nvidia Design sollte AMD da konkurrieren oder verglichen werden können mit seiner Konsolen-APU, wie die beiden Trolle das hier behaupten? Aber du hast recht es ist ein 16nm Design.
Also ich präzisiere: Es gibt keine AMD GPU auf 16nm. Und Nvidia baut nur GPUs und ARM-SoCs, daher bleibt der Vergleich Blödsinn.

Chris Lux

2017-05-15, 11:46:39

https://devblogs.nvidia.com/parallelforall/inside-volta/

Der für mich interessanteste Abschnitt ist: Independent Thread Scheduling

y33H@

2017-05-15, 14:18:18

Das mit den 2 Interposern hat Golem geschrieben nach dem Deap Dive. Aber Ryan von Anandtech meinte, dass dies falsch ist und er in der gleichen Präsentation mit saß. Stattdessen wird 2 mal belichtet. Ich vertraue einem native Speaker da mehr, ist wohl eher ein Übersetzungsfehler.Bei mir steht nicht, dass zwei Interposer verwendet werden, sondern eben die Maske für die Belichtung zweigeteilt ist.

Wo finde ich Ryans Aussage?

Klevapalis

2017-05-15, 14:27:07

Bei mir steht nicht, dass zwei Interposer verwendet werden, sondern eben die Maske für die Belichtung zweigeteilt ist.
Du meinst dies hier?

Der Interposer, auf welchem der GV100 und die vier HBM2-Speicherstapel sitzen, sprengt die Dimensionen der Maske (Reticle), weshalb zwei benötigt werden.

Kann man so und so lesen, weil "zwei" sich sowohl auf den Interposer, als auch auf die Maske bezogen kann. Habs auch auf die Interposer bezogen gelesen.

Unicous

2017-05-15, 14:29:22

@ y33H@

https://forum.beyond3d.com/posts/1980841/

y33H@

2017-05-15, 14:30:27

Ich präzisiere die Formulierung, sehe das Problem nun.

Klevapalis

2017-05-15, 14:32:57

Ich präzisiere die Formulierung, sehe das Problem nun.
:up:

Hübie

2017-05-15, 15:49:02

https://devblogs.nvidia.com/parallelforall/inside-volta/

Der für mich interessanteste Abschnitt ist: Independent Thread Scheduling

Ist wohl AC.
Interessant in dem Kontext ist auch: "computation and addressing calculations". Könnte Skalareinheiten andeuten.

OC_Burner

2017-05-15, 16:26:44

EDIT: hier sieht man auch nochmals die extra DIEs ziemlich gut:https://1.f.ix.de/imgs/18/2/1/9/9/2/6/9/Volta-3165e75150c08d02.jpeg

Für mich sieht das von den Reflexionen her nicht so aus, als ob das der Interposer drunter wäre

EDIT2:
Ok ich habe das Ganze nochmals mit dem Bild aus dem letzten Link wiederholt, da komme ich jetzt auf einen Faktor 1:2,8 Sprich das perspektive korrigieren verzerrt alles völlig -.- Das kann man also total vergessen...

Man kann aber wohl davon ausgehen, dass der DIE wirklich über 800mm² groß ist. Krasses teil also. Ich bin ja eigentlich davon ausgegangen, dass Sie den Interposer gemessen hätten, aber der scheint nochmals deutlich größer zu sein. Die spannende Frage ist jetzt natürlich noch, was die Dinger unter/über den HBM2 stacks sind.

Wenn man dein Bild vom ersten EDIT nimmt und man von einer Boardgröße von 140mm x 78mm ausgeht und das Bild entsprechend verzehrt kommt man auf eine Die-Size von sage und schreibe 870mm² sowie einer Interposergröße von 1510mm². Die HBM-Stacks sind jeweils 4x 0,94mm² groß. Irgendwas stimmt da nicht wobei die Verzehrung eigentlich korrekt sein müsste.:freak:

iuno

2017-05-15, 16:28:53

Weiss man ueberhaupt, wie gross Samsungs Stacks sind?
Die einzigen Groessenangaben die ich kenne, sind von Hynix.

Hübie

2017-05-15, 17:05:25

Man kann auch das Package der dual-N-Channel MOSFETs als Orientierung nehmen. Das überlasse ich allerdings euch. :D

Leonidas

2017-05-15, 17:44:14

Das mit den 2 Interposern hat Golem geschrieben nach dem Deap Dive. Aber Ryan von Anandtech meinte, dass dies falsch ist und er in der gleichen Präsentation mit saß. Stattdessen wird 2 mal belichtet. Ich vertraue einem native Speaker da mehr, ist wohl eher ein Übersetzungsfehler.

Wenn es tatsächlich zwei Interposer wären, müsste man das sehen. Auf den Bildern ist es aber eine durchgehende Fläche.

https://forum.beyond3d.com/posts/1980841/

Gut, das geklärt zu haben. Danke euch allen!

y33H@

2017-05-15, 19:30:50

Was interpretiert ihr den Satz auch falsch :P :ugly:

Chris Lux

2017-05-15, 20:11:59

Ist wohl AC.
Interessant in dem Kontext ist auch: "computation and addressing calculations". Könnte Skalareinheiten andeuten.
Ich glaube, das hat erst einmal nichts mit Async Compute zu tun. Es ist vielmehr die Möglichkeit in einem Warp (Thread Group of 32) nicht stur Threads auszumaskieren, welches divergent sind. Es wird jetzt möglich sein Berechnungen der divergenten Zweige zu interleaven. Jeder Thread hat nun seinen eigenen Instruction Counter, nicht mehr nur der Warp.

Eine sehr coole Sache, wenn man Graphik-Code schreibt. Der ist von Natur aus sehr divergent.... ;)

AffenJack

2017-05-15, 20:21:07

Jop, mit async hat eher das hier zu tun glaube ich:

https://pbs.twimg.com/media/C_fs13WUMAAdFAy.jpg:large

Kein Software sheduling mehr, sondern wieder zurück zu Hardware Scheduling. Genauso wieder eine Zusammenlegung von L1 und Shared Memory wie früher. Man hat schon in manchen Bereichen ne Rolle rückwärts gemacht.

Troyan

2017-05-15, 20:32:41

Nein, das ist für Virtualisierung.

Hübie

2017-05-16, 00:25:13

Ich glaube, das hat erst einmal nichts mit Async Compute zu tun. Es ist vielmehr die Möglichkeit in einem Warp (Thread Group of 32) nicht stur Threads auszumaskieren, welches divergent sind. Es wird jetzt möglich sein Berechnungen der divergenten Zweige zu interleaven. Jeder Thread hat nun seinen eigenen Instruction Counter, nicht mehr nur der Warp.

Eine sehr coole Sache, wenn man Graphik-Code schreibt. Der ist von Natur aus sehr divergent.... ;)

Ich habe zugegebenermaßen nur deinen Satz gelesen, weil ich noch keine Zeit fand mir die Marketing-Broschüre für Volta anzusehen. :redface:

gravitationsfeld

2017-05-16, 00:49:07

https://devblogs.nvidia.com/parallelforall/inside-volta/

Der für mich interessanteste Abschnitt ist: Independent Thread Scheduling
Du hast den Haken im Kleingedruckten uebersehen:
The per-thread program counter (PC) that forms part of the improved SIMT model typically requires two of the register slots per thread.
Ne danke.

Ueberhaupt steht da auch, dass ein Cycle immer noch SIMT die gleiche Instruction ausfuehren muss. Der Durchsatz wird dadurch also wohl nicht erhoeht?

Der Vorteil scheint wohl nur zu sein um Deadlocks etc. zu vermeiden. Schau dir das Schaubild an zu "Volta independent thread scheduling enables interleaved execution of statements from divergent branches. This enables execution of fine-grain parallel algorithms where threads within a warp may synchronize and communicate."

Ich haette lieber ne Skalareinheit gehabt um den ganzen Skalarcode aus den Warps rauszubekommen. Aber vielleicht lassen sie sich da noch nicht in die Karten schauen.

Skysnake

2017-05-16, 07:25:54

ja es geht um deadlock Vermeidung. Darüber hinaus kann man ja jetzt auch zwischen Blocks syncen.

Das will man ja schon lange, damit man nicht immer Kernels neu starten muss um globale Syncs zubekommen. Das kann schon sehr viel bringen bei kleinen Kerneln, die man aber sehr sehr sehr oft ausführen muss.

An sich kann das AMD wohl durch die GDS schon seit GCN1, aber der Software support dafür ist ja bis heute nicht dafür da... FAIL von AMD an dieser Stelle...

Ich bin mal gespannt, ob es jetzt mit VEGA endlich kommt. Ich könnte es mir bei AMD ja echt vorstellen, dass Sie es vielleicht sogar erst in der nächsten Gen dann mit der Software supporten. Einmal mehr eine große ungenutze Chance.

Complicated

2017-05-16, 11:48:19

https://community.amd.com/thread/210432
It seems that you need the OpenCL 1.2 ABI to enable the GDS functionarity.
I also found out that you can access the GDS on RX 480 on Ubuntu 16.04.02 LTS with AMDGPU-Pro 16.60. All you have to do is to set the m0 register to 0x1000. By default, you can only access 4096 bytes at a time
The lower 16 bits of M0 reg specifies the size of the accessable gds memory, set it to 0xFFFF!
The upper 16 bits are the base offset in the physical GDS memory, just leave it to 0.
So basically the M0 reg does some basic memory protection.

mksn7

2017-05-16, 14:03:19

Man hätte ja vorher auch schon einen globalen sync basteln können, mittels atomics. Ist nur gefährlich, weil man sicher stellen muss dass das komplette Grid auf einmal gescheduled werden kann, weil sonst keine Forward Garantie. Um das sicher zu unterstützen, muss nvidia in der Lage sein, den state von thread blocks die schon gescheduled sind auszulagern, andere thread blocks starten, und dann später wieder laden. So gibts auch hier Forwardgarantie bei mehr größeren Grids.

Skysnake

2017-05-16, 14:20:36

Das wurde sogar schon gemacht. An sich kann man damit aber nur so viele Threads starten wie mal ALUs hat.

Es sei denn, man hat ein paar Kenntnisse übers Sheduling. Dann geht auch etwas mehr, aber nicht viel mehr, und das ist eben noch immer VIEL! zu wenig, um die GPU vernünftig auslasten zu können. Daher macht das fast nie Sinn. Der Leistungsverlust ist so meist höher als wenn man den Kernel einfach mehrfach startet...

https://community.amd.com/thread/210432
Und warum wird das irgendwo in nem Forum besprochen, und nicht groß und breit ausgetreten und wenn möglich sogar direct über eine Hersteller-Erweiterung von OpenCL verfügbar gemacht?

Sorry, aber das ist genau die Art von FAIL die ich meine. Selbst wenn Sie etwas gebacken bekommen, dann bekommen Sie es nicht gebacken darüber so zu reden, dass die Leute auch etwas davon mitbekommen... Tu Gutes und sprich darüber...

Complicated

2017-05-16, 14:43:51

Es ist im Reference Guide zu finden und auch schon eigentlich ein alter Hut:
http://developer.amd.com/wordpress/media/2013/07/AMD_Sea_Islands_Instruction_Set_Architecture.pdf
Ab Seite 294.

Hier auf Folie 12 zu finden:
http://developer.amd.com/wordpress/media/2013/06/2620_final.pdf
Neue Aufbereitung in 2015 "revisited"
https://community.amd.com/thread/170216
OpenCL Compiler listen es:
http://llvm.org/devmtg/2010-11/Villmow-OpenCL.pdf
Aus 2010 sogar schon bei der HD5870 gelistet Folie 7:
http://www.highperformancegraphics.org/previous/www_2010/media/Hot3D/HPG2010_Hot3D_AMD.pdf

Das waren jetzt nur die ersten paar Treffer bei der Google Abfrage - weiss nicht was du genau dabei erwartet hast.

mksn7

2017-05-16, 16:26:00

Es sei denn, man hat ein paar Kenntnisse übers Sheduling. Dann geht auch etwas mehr, aber nicht viel mehr, und das ist eben noch immer VIEL! zu wenig, um die GPU vernünftig auslasten zu können. Daher macht das fast nie Sinn. Der Leistungsverlust ist so meist höher als wenn man den Kernel einfach mehrfach startet...

So genau Kentnisse brauchts doch da gar nicht?
In cuda speak: block_count = sm_count * blocks_per_sm
Beides lässt sich zumindest bei CUDA leicht zur Laufzeit herausfinden. Bei OpenCL ist der SM count einfach, aber wieviel blocks pro SM gehen ist herstellerübergreifend vielleicht nicht so einfach.

Das ist auch gleichzeitig genau die Anzahl threads mit der 100% occupancy erreicht werden kann und wo keine tail effects auftreten. Also kein performance verlust. Ich konfiguriere fast alle Kernel calls so.

Nvidia gibt dafür keine Garantie, gibt aber zu dass das praktisch bis jetzt immer funktioniert.

Skysnake

2017-05-16, 17:55:15

Nein, das ist zu viel.

Auf der sicheren Seite bist du, wenn du So viele Warps startest, dass du genau einen Thread pro ALU hast.

Da du aber gewisse Latenzen hast, kannste mehr starten. Das Problem ist nur, du musst sehr genau wissen, was du machst, sonst kannste in einen life lock rennen...

Es ist im Reference Guide zu finden und auch schon eigentlich ein alter Hut:
http://developer.amd.com/wordpress/media/2013/07/AMD_Sea_Islands_Instruction_Set_Architecture.pdf
Ab Seite 294.

Hier auf Folie 12 zu finden:
http://developer.amd.com/wordpress/media/2013/06/2620_final.pdf
Neue Aufbereitung in 2015 "revisited"
https://community.amd.com/thread/170216
OpenCL Compiler listen es:
http://llvm.org/devmtg/2010-11/Villmow-OpenCL.pdf
Aus 2010 sogar schon bei der HD5870 gelistet Folie 7:
http://www.highperformancegraphics.org/previous/www_2010/media/Hot3D/HPG2010_Hot3D_AMD.pdf

Das waren jetzt nur die ersten paar Treffer bei der Google Abfrage - weiss nicht was du genau dabei erwartet hast.
Ja super, genau das meine ich doch....

Der GDS war sogar schon bei der 5870 erwähnt. Da hatten Gipsel und ich schon vor Jahren drüber diskuttiert.

Das Problem ist, es gibt keinen API Call, um das in einer Hochsprache wie OpenCL zu nutzen.

Kein Mensch wird dir den Assembler hinschreiben. Da wirste bekloppt im Kopf!

Genug Leute winken dir ja schon ab, wenn du ihnen mit CUDA/OpenCL kommst. Da ist MPI und OpenMP das höchste der Gefühle, und MPI auch meist bulk synchronous....

Wenn es einen einfachen call geben würde, dann würden es die Leute vielleicht nutzen, aber so fasst man das nicht mal mit der Beiszange an.

Ich hab es mir mal überlegt, aber wegen dem großen Aufwand gelassen, zumal aus meiner Sicht nicht gut dokumentiert war, wie man das jetzt genau benutzt um Effekt XY zu erreichen.

Also z.B. Ich habe eine 2D Heatequation zu lösen und will alle Iterationen ohne Kernelstart ausführen. Das sollte an sich mit dem GDS gehen, aber kennst du eine implementierung?

Oder willste es machen? Also ich nicht, da man absolut nicht abschätzen kann, ob wie lange es dauert dass das Ding läuft. In OpenCL ist das Arbeit von einem Nachmittag from scratch...

mksn7

2017-05-16, 19:16:40

Nein, das ist zu viel.

Auf der sicheren Seite bist du, wenn du So viele Warps startest, dass du genau einen Thread pro ALU hast.

Ich hab mal versucht zu verstehen was du meinst. Ich denke du hast Recht, wenn der warp scheduler so lange weiter von den gleichen warps scheduled, solange die issuen können. Dann könnten wartende warps konitinuierlich spinnen, während andere threads nicht zur Ausführung kommen. Meinst du das?

Wenn der scheduler sich so verhielte, könnte man sich zumindest ein wenig helfen, indem man nur einen (maximal großen) thread block pro SM startet, und dort bei jedem spin eine barrier rein macht.

Loads von volatile addressen könnten lang genuge Latenzen produzieren, damit alles anderen warps schedulen können. Bei Kepler wären das nur 16 warps per scheduler.

Vielleicht probier ichs mal aus.

Edit: Mit Kepler+CUDA gehts. Der Scheduler macht wohl round robin von allen issue-fähigen warps.
Edit2: Aber warps dürfen auf keinen Fall divergieren, sonst geht alles kaputt... Und das passiert ganz schnell. Genau das wird mit Volta einfacher, es geht vorwärts auch wenn warps divergieren.
Edit 3: Mund zu voll genommen. Es geht fast immer. Damn.

Skysnake

2017-05-16, 21:14:18

Genau das meinte. ;) :up:

Und das mit dem Edit3 haste ja inzwischen auch rausbekommen. Es geht halt fast immer mit den höheren Latenzen.

Wenn man ganz ganz ganz sicher gehen will, kann man halt nur so viele Warps starten, das man genau einen Thread pro ALU hat. Das ist 100% sicher. Ich hatte aber mal mit jemanden gesprochen, das auch etwas mehr geht, wenn man es denn "richtig" macht.

Dafür braucht man aber Kenntnisse übers sheduling, und die rückt nVidia normal nicht raus. Derjenige hatte da auch ganz klar ziemlich zu gemacht und von nem Kollegen schon nen bösen Blick bekommen für das was er erzählt hat....

mksn7

2017-05-16, 22:54:08

Ich hab doch was falsch gemacht. Ich dachte ich bin schlau und erzwinge im Spinlock einen neuen Wert mit:

val = atomicCAS(tag, 0, 0)

Da hab ich nicht dran gedacht dass das im Warp divergieren kann. Den pointer tag als volatile markieren langt aber auch. Jetzt gehts grad vorläufig, aber ob alles auch korrekt ist muss ich noch schauen. Es ist definitiv nicht einfach. Und nützliche Arbeit hab ich auch noch keine gemacht, innerhalb der Schleife kann ich jetzt nur noch warp uniform branches machen, sonst gehts kaputt.

Bei 104 thread blocks mit 256 threads braucht jede Barrier etwa 0.14ms. Ich sollte extra kernel calls auch mal benchen.

104 thread blocks sind 13*8, die maximale occupancy auf einer K20m mit 13 SMs.

Complicated

2017-05-17, 02:37:31

Genug Leute winken dir ja schon ab, wenn du ihnen mit CUDA/OpenCL kommst. Da ist MPI und OpenMP das höchste der Gefühle, und MPI auch meist bulk synchronous....

Jetzt mach mal einen Punkt. Fail war dein Statement. AMD ist hier Schuld, dass Entwickler nicht entwickeln wie es sich gehört?

Ich war vor 2 Monaten in einem Seminar gesessen wo ein Java-Trainer den Leuten erzählt hat man sollte immer doubles nehmen um Variablen zu definieren, da es ja heutzutage keine Rolle mehr spielt ob 32 oder 64 bit genutzt werde bei dem reichlichen Speicherangebot in den Systemen. Auf meine Frage hin wie er denn das mit GPU-Computing vereinbaren könne wo der Performance-Einbruch erheblich sein könne, je nach GPU die genutzt werde. Da hat er mich angeschaut wie ein Auto...nur nicht so schnell. GPU-Computing? So etwas gibt es?

Ich will damit sagen "Fail" ist was geschult wird und viel weniger wie AMD irgendwelche exotischen Fesatures kommuniziert die kaum einer nutzt obwohl "Fusion" ein alter Hut ist. Wäre das für Entwickler von Belang wären Nvidias GPUs vor 3 Generationen obsolet gewesen. Unified Memory ist nur bei CUDA neu.

gravitationsfeld

2017-05-17, 03:21:37

Er hat recht. Es ist fail, wenn es in OpenCL nicht unterstuetzt wird. GDS gibt es bei AMD bestimmt schon seit 10 Jahren.

Complicated

2017-05-17, 03:25:19

OpenCL wird aber unterstützt.

gravitationsfeld

2017-05-17, 03:33:48

Nur mit irgendwelchen Hacks die nicht dokumentiert sind. Es funktioniert auch nur mit CL 1.2, nicht mit neueren Versionen. Das ist doch kein Zustand.

Skysnake

2017-05-17, 09:33:38

Complicated, darum geht es doch, wie ich schon sagte. Tu Gutes und SPRICH darüber!

Genau das macht AMD aber nicht. Auch das ROCm und HIP ziehen nicht wie Sie sollten. Es fehlt an Schulungsmaterial, hands on labs, usw usf.

Kennst du ein "hallo world" von AMD, wo Sie zeigen, wie man den GDS mit Compute nutzt?

Nein?

Na sowas aber auch....

GDS so wie es jetzt ist, benutzt du vielleicht in der Forschung an irgendwelchen Instituten, die sich nur mit Compilerbau, Programmiermodellen usw usf beschäftigen, aber ansonsten wird das keiner mit der Beiszange anfassen.

Wie gesagt, selbst ich bin davor zurückgeschreckt, weil das meiner Meinung nach nicht vernünftig nutzbar ist, und ich schrecke an sich auch nicht davor zurück ein bischen inline assembler zu schreiben... Da ist die Doku aber 1A....

iuno

2017-05-17, 11:18:56

Ich war vor 2 Monaten in einem Seminar gesessen wo ein Java-Trainer den Leuten erzählt hat man sollte immer doubles nehmen um Variablen zu definieren, da es ja heutzutage keine Rolle mehr spielt ob 32 oder 64 bit genutzt werde bei dem reichlichen Speicherangebot in den Systemen. Auf meine Frage hin wie er denn das mit GPU-Computing vereinbaren könne wo der Performance-Einbruch erheblich sein könne, je nach GPU die genutzt werde. Da hat er mich angeschaut wie ein Auto...nur nicht so schnell. GPU-Computing? So etwas gibt es?
Voellig falsche Zielgruppe. Und natuerlich ist es scheiss egal, wenn man irgendwie gerade Programmieren lernt und eine handvoll Variablen hat. Java hat mit high performance eh nichts zu tun und mit HPC und GPGPU noch weniger.

Auch das ROCm und HIP ziehen nicht wie Sie sollten. Es fehlt an Schulungsmaterial, hands on labs, usw usf.

Kennst du ein "hallo world" von AMD, wo Sie zeigen, wie man den GDS mit Compute nutzt?
Der stack ist ja auch noch nichtmal fertig. Es werden hin und wieder mal demos gezeigt, die irgendwie extra dafuer lauffaehig gemacht wurden und das wars.

Was wuerde man denn mit einem GDS machen? Waere mal interessant die Redaktion zu sehen, wenn man die moegliche Anwendung beschreibt und die fehlende Funktionalitaet auf GitHub bei ROCm als Issue eintraegt.

Complicated

2017-05-17, 11:26:09

@iuno
Na danke für den Hinweis. Wenn ich es nicht selber in dem von dir zitierten geschrieben hätte wäre mir das ja gar nicht aufgefallen.

@Skysnake und gravitationsfeld
Ihr solltet einfach mal unterscheiden zwischen "gibt es nicht" und "es ist kompliziert und schlecht dokumentiert". Was anderes habe ich nicht geschrieben und da braucht es keine Nachfasserei nach dem Motto "Ja stimmt es existiert ja doch, aber nicht so wie ich es gerne hätte - also gibt es das nicht." Ich wollte den Offtopic einfach nicht falsch stehen lassen. Müssen wir auch wirklich nicht hier vertiefen, gerne in einem anderen Thread.

Skysnake

2017-05-17, 14:59:50

Ich hatte von Anfang an gesagt, das es keinen Software Support gibt, und damit OpenCL gemeint, was im folgenden Post auch spätestens klar hätte sien können, da ich gesagt habe, das Sie ja wenigstens eine OpenCL Erweiterung hätten bringen können....

Aber seis drum.

Der Punkt ist, man kann es nicht mit Hochsprachen nutzen, und damit ist es tot. Das gleiche Geraffel auch bei einigen Offload Sachen bei Infiniband. So lange die nicht über MPI supported werden, ist das ganz überwiegend tot.

Hübie

2017-05-17, 19:18:16

Ähm, Skysnake? Es heißt Kneifzange, nicht Beißzange. :D

Ansonsten: Die Architekturen beider IHV nähern sich einander an. Beide sind also weit vom Optimum. ;)
Ob Volta nun eine Skalareinheit hat ist mir noch nicht klar.

Skysnake

2017-05-17, 22:09:18

Nach dem was man bisher weiß, würde ich sagen nein.

Blediator16

2017-05-17, 22:30:24

https://youtu.be/Y2VF8tmLFHw?t=3067
Könnte das u.a. der Grund gewesen sein, dass Nvidia eine noch nie da gewesene GPU in der Größe maß schneidern musste?

Troyan

2017-05-17, 22:45:04

Nö. Die produzieren, weil sie es können. Immerhin wollen sie auch die FP64 Leistung erhöhen.

Ohne einen wirklich kleineren Prozess, muss man eben in die Breite gehen.

/edit: Ich dachte beim ersten Lesen, dass Googles TPU2 180TFLOPs mit einem Chip erreicht. Sieht aber eher danach aus, dass die 180TFLOPs nur mit dem Cloud-Board erreicht wird.

Skysnake

2017-05-17, 22:53:12

Naja, da macht ein Chip wohl 45 TFLOPs, ist jetzt halt die Frage, wie viel sich davon real auf die Straße bringen lassen, und was das Ding dann am Ende schluckt.

Du kannst aber davon ausgehen, dass das nVidia nicht bekannt war. Google ist da sehr sehr sehr verschlossen.

Btw. Ich habe mich die letzte Woche mit dem Benchmarking von Systemen für TensorFlow beschäftigt, und bin dabei auf den DeepBench von Baidu gestoßen. Die wollen da representative kernelteile benchen, damit man unabhängig von konkreten Netzen die Hardware vergleichen kann. Auch da habe ich aber keine 4x4 MAtrizen gefunden, wie auch schon bei den konkreten Netzten, die ich mir angeschaut hatte und hier auch mal etwas verlinkt hatte.

Also keine Ahung, ob man die 120TensorFlops wirklich nutzen kann in realen Anwendungen. Das wird besonders spannend in Bezug auf die TPUv2 von Google.

Insgesamt zeigt es aber eben ein Problem. Wenn man groß genug ist, bzw. man das oft genug machen muss, dann lohnt sich einfach ein ASIC dafür.

Ich gehe daher auch stark davon aus, dass die Sensorhersteller wie Bosch über kurz oder lang, das Inferencing direkt in den Sensoren machen werden, oder eigene Steuergeräte anbieten werden.

Ich bin da mal gespannt, wie sich nVidia da behauptet.

Das Google aber vor allem ihre TPU in der Cloude ALLEN!!! anbietet ist schon sehr überraschen. Auch das man Forschern 1000 der DInger wohl für umme zur Verfügung stellt, wenn Sie sich die Cloude nicht leisten können ist mal eine Ansage.

Google kann da nVidia, Intel und nun auch AMD ziemlich den Spaß an der Sache verderben, denn wenn Google denen kaum etwas abnimmt sondern im großen Maße ihre eigenen Chips einsetzt, dann wird das nicht spurlos an Ihnen vorbei gehen.

Vor allem lohnt es sich für google ja mehr von den Dingern einzusetzen, dann sinken die Stuckkosten, weil sich die Entwicklungskosten auf eine höhere Stückzahl aufteilen.

Ich denke das wird im nächsten Jahr echt spannend, zumal Google mit TensorFlow ja auch ein populäres Framework unter ihrer Fuchtel haben...

AffenJack

2017-05-17, 23:28:42

Joa, Google könnte den allen schon den Spaß verderben, aber die Chipanbieter sind ja nur der Nebenschauplatz. Viel schlimmer ist das Ding für die Hauptziele von Google, Amazon und die anderen Cloudanbieter werden verdammt Marktanteile federn lassen, wenn es so gut ist, wie es sich anhört.

Aber wo wir schonmal bei ASICs sind. Xavier hat ja auch nen DL Asic eingebaut und mit 30TOPS bei 30W ist das Ding immerhin auch 3mal so effizient wie GV100. Nvidia hat angekündigt, dass der ASIC Open Source ist, aber wieso macht man das? Könnte jetzt nicht einfach ne xbeliebige chinesische Klitsche kommen und den ASIC bauen oder in deutlich größer bauen und damit auch Nvs Chips platt machen? Da es Open Source ist, würde Nvidia da doch nichtmal Geld von sehen. Worin besteht der Sinn hinter einem Open Source ASIC für Nvidia?

Troyan

2017-05-18, 00:38:33

Google und nVidia machen im grunde das selbe: Spezialisierte Cores für Deep Learning. Wundert nicht, dass beide Firmen zeitgleich mit den selben Sachen kommen.

Ansonsten kann die Google-Ankündigung sogar vorteilshaft für nVidia sein. Andere Infrastrukturanbieter müssen nun mit Google mithalten und können zur Zeit nur auf Volta zurückgreifen.

gravitationsfeld

2017-05-18, 05:05:17

Die proprietaeren Google-Tensor-Chips sind auf jeden Fall effizienter als NVIDIAs Loesung aber eben auch mehr massgeschneidert.

Achill

2017-05-18, 10:01:49

[..] Wundert nicht, dass beide Firmen zeitgleich mit den selben Sachen kommen.[..]

https://cloudplatform.googleblog.com/2016/05/Google-supercharges-machine-learning-tasks-with-custom-chip.html

Google hat die erste Version der TPU 2014/2015 eingeführt. Die Entwicklung wird also auch entsprechend früher begonnen haben. NV hat also nachgezogen und wir wissen nicht, ob die Systeme miteinander Vergleichbar sind hinsichtlich der Flexibilität.

Troyan

2017-05-18, 11:13:07

https://cloudplatform.googleblog.com/2016/05/Google-supercharges-machine-learning-tasks-with-custom-chip.html

Google hat die erste Version der TPU 2014/2015 eingeführt. Die Entwicklung wird also auch entsprechend früher begonnen haben. NV hat also nachgezogen und wir wissen nicht, ob die Systeme miteinander Vergleichbar sind hinsichtlich der Flexibilität.

TPU1 war nur für Inference gedacht mit seinen 8-bit INT Einheiten. Schlussendlich kommt Volta und TPU2 zeitnah mit ähnlichen Ansätzen. Das ist auch nur logisch, da beide Firmen von anfang an zusammenarbeiten und den Markt begleitet haben.

Hübie

2017-05-18, 13:56:45

Achill

2017-05-18, 14:33:13

TPU kann schon mal kein graphics :D

Und NV TensorCores werden wir auch nicht bei graphics sehen - außer es gibt irgendwann mal ein Schick Schnack im GW ... ;)

Hübie

2017-05-18, 14:40:34

Wenn wir den Verbrauch bei den Matrixoperationen wüssten könnten wir eventuell Rückschlüsse auf das Wie ziehen. Skysnake, und ich ehrlich gesagt auch, glauben dass es eine feste Verdrahtung von ALUs und SIMD Slots sind (ums mal blöd auszudrücken). Im Umkehrschluß würde also ein Großer Teil nicht mehr für Graphics zur Verfügung stehen.
Der These entgegen steht die schier riesige Fläche des Dies. Wobei der Fertigungsvorteil ebenfalls eine Unbekannte ist (33% mehr ALUs und 33% mehr Fläche, ausgehend vom GP100).:D

Nakai

2017-05-19, 20:54:32

FPGAs sind auch noch ziemlich nett, wenn es ums DL geht. Ich vermute die nächste Generation von FPGAs, werden eine große Menge an DSP-Slices bekommen, um eben Neuronale Netzwerke nochmal gut zu beschleunigen. Ebenso macht es für mich keinerlei Sinn neuronale Netzwerke auf FP-Hardware auszuführen. FixedPoint/Integer-Arithmetik ist ausreichend und verbrät deutlich weniger Energie. Man muss nur auf die numerischen Eigenheiten etwas achten, aber das lässt sich gut bei einem FPGA anpassen.

Ansonsten spezialisierte ASICs sind das Ziel fürs Deep Learning und nichts anderes.

Digidi

2017-05-22, 23:08:55

Volta Titan leak!

http://www.overclock.net/t/1630852/fb-picture-of-volta-titan-leaked-by-nvidia-intern

Nakai

2017-05-22, 23:25:54

Keine Titan, eher eine Quadro oÄ. Aber ja dieses Jahr sollte noch eine Volta GPU für die Consumer kommen. Eher GV104. GV102 dann nächstes Jahr.

Blediator16

2017-05-22, 23:36:06

Entweder will da jemand dem Typen schaden oder es ist ein riesen Idiot.

AffenJack

2017-05-22, 23:36:47

Volta Titan leak!

http://www.overclock.net/t/1630852/fb-picture-of-volta-titan-leaked-by-nvidia-intern

Oder fake, ich meine wer posted denn bitte die ID, damit alle sehen wer das leakt? Ich habe da arge Zweifel, vor allem auch weil das ne Titan sein soll. Das wäre etwas früh in Anbetracht dessen, dass die wohl Q1 2018 erscheinen wird.

@Nakai
Ja GV104 könnte ich mir mittlerweile für Weihnachten vorstellen, nachdem Hynix 14Gbps GDDR6 für Q4 angekündigt hat.

Nakai

2017-05-23, 00:05:14

@Nakai
Ja GV104 könnte ich mir mittlerweile für Weihnachten vorstellen, nachdem Hynix 14Gbps GDDR6 für Q4 angekündigt hat.

Ich bin mir ziemlich sicher, dass wir hier irgendwas in diesem Jahr sehen werden. So ein GV104 wird so ~40% auf eine GP104 drauflegen, einfach weil man 40% mehr Bandbreite hat.

So einen GV104 kann man mit ~3200 SPs bei 400mm² erwarten dürfen. Die Taktraten werden ähnlich sein, wie die von GP104, womöglich ein Stück weit höher.

Digidi

2017-05-23, 00:12:40

AffenJack

2017-05-23, 07:43:40

Ich bin mir ziemlich sicher, dass wir hier irgendwas in diesem Jahr sehen werden. So ein GV104 wird so ~40% auf eine GP104 drauflegen, einfach weil man 40% mehr Bandbreite hat.

So einen GV104 kann man mit ~3200 SPs bei 400mm² erwarten dürfen. Die Taktraten werden ähnlich sein, wie die von GP104, womöglich ein Stück weit höher.

Ich würde 3584 Shader nicht mal ausschließen bei GV104, wenn man das ganze mit GV 100 vergleicht:

GV100 Die Size gegen GP100 :+34%
Shader : +40%
Nvlink 4 vs 6: +50%
L1 Cache/Shared Memory pro SM: +45%
L2 Cache: +50%
+ Tensor Cores + Int 32 - FP16

Da ist also durchaus einiges um mehr als die Shader skaliert worden und die Tensor Cores sollen groß sein, trotzdem ging die Die Size nur 34% hoch. GV104 dürfte nur eine L1 Cache/SM Vergrößerung abbekommen und da erwarte ich eine kleinere Steigerung als bei GV100. L2 steigerte man bei GV100 eher, da man nicht so große Bandbreitensteigerungen gesschafft hat und das für HPC wichtiger ist. Der kann bei GV104 auch gleich bleiben. Dafür hoffe ich auf FP16, aber das sollte nun nicht so groß sein. Insgesamt könnte sich das unter Umständen mit 3584SP bei ~400mm² ausgehen. Taktraten werden nicht mehr hoch gehen. GV100 ist da ne gute Orientierung.

40% ist zu viel. Der 12nm Prozess bringt kaum Vorteile und ist eher ein Pseudo 14/16nm Prozess. Man sieht es ja an GV100 man braucht viel Fläche für die vielen Shadern. Eine 1080ti ist ja gerade Mal 25% schneller als eine normale 1080

Nur wenn du CPU-Limits oder bestimmte schlecht skalierende Spiele in Betracht ziehst. Sonst sinds über 30% https://www.3dcenter.org/artikel/launch-analyse-nvidia-geforce-gtx-1080-ti/launch-analyse-nvidia-geforce-gtx-1080-ti-seite-3