nVidia - Pascal - GP100 - 2016 - 3D-Memory HBM, NVLINK, Mixed Precision [Archiv] - Seite 6

HOT

2015-11-09, 16:14:28

Es wird gerne die Ingeneursleistung unterschätzt, den ganzen Kram zusammenzubringen. Der Chip ist hochkomplex, der Interposer riesig und HBM2 bisher nicht im Einsatz.
Es ist eine Sache HBM2-Speicher nach Spezifikation zu bauen. Das ist sicherlich kaum ein Problem. Den anzubinden, das Ganze massenproduktionsfähig zu bekommen und auch noch die Kosten niedrig zu halten ist schon ne ganz andere Nummer. Zudem ist der Chip extrem komplex, bietet nagelneuen I/O-Krempel und kommt in einem neuen, recht teuren Prozess. Man sieht ja an Fiji, wie schwer das am Anfang war. Und der wurde sicherlich ganz bewußt in einer sehr kleinen Serie gebaut.
AMD nahm eine bewährte Architektur in einem sehr ausgereiften Prozess um das Interposer+HBM-Abenteuer zu wagen, NV versucht gleich alles auf einmal. Man sollte da nicht zu schnell Ergebnisse erwarten. So wie bei Maxwell von Tapeout zu finalem Produkt innerhalb eines Jahrs, wie bei GM200, ist da einfach nicht zu erwarten. Einen Respin beim GP100 gab es offenbar, da ist also schon 1/2 Jahr mal eben einfach weg.

Skysnake

2015-11-09, 19:02:33

Ich erinnere nur mal so am Rande an PCI-E 3.0 und welch große Probleme es damit am Anfang gab, und das sollte noch relativ simpel im Vergleich zu HBM sein.

Godmode

2015-11-09, 19:35:08

Ich erinnere nur mal so am Rande an PCI-E 3.0 und welch große Probleme es damit am Anfang gab, und das sollte noch relativ simpel im Vergleich zu HBM sein.

Wenn AMD das schafft, mit ihrem kleinen Team und den begrenzten R&D-Mitteln, sollte NV das wohl auch hinbekommen. Ziemliche Schwarzmalerei IMHO.

Nakai

2015-11-09, 19:36:14

Fiji gab es auch etliche Monate vor Launch als Samples...siehe Zauba. Das ist also erstmal kein Grund. Ob das wirklich schon Pascal ist, oder irgendetwas anderes, z.B. HPC-Spezielles ist hingegen noch nicht raus. Und ob es überhaupt ein 16nm-Sample ist, weiß man auch noch nicht.;) (Außer ich habe jetzt irgendeinen wichtigen Hinweis übersehen, der aus den Frachtbrief-Eintragungen ersichtlich wäre:confused:)

Wenn man den Preis von Fiji Samples mit diesen hier vergleicht, ist diese "GPU" ungefähr 3mal so teuer. Und klar sind das keine richtigen Preise, aber wohl doch eine Tendenz in welche Richtung es geht. Es könnte sich theoretisch um eine GM200 DualGPU handeln. Und selbstverständlich war Fiji schon deutlich länger auf Zauba unterwegs, was für einen gestiegenen Validierungsaufwand spricht.

Und wie gesagt, alles hängt an HBM2. Mich würde es nicht wundern, wenn erstmal HBM1 verbaut wird. HBM1 war ja schon ab Q3 2014 von SKHynix verfügbar. Von HBM2 fehlt noch jegliche Spur. Wenn NV in H1 2016 mit Pascal kommt, dann wird das sehr teuer und sehr selten erstmal werden.
1000$ für eine SingleGPU werden definitiv überschritten. Ich würde eher von 1500$+ ausgehen. GM200 ist auch nichtmal ein Jahr alt.

AMD nahm eine bewährte Architektur in einem sehr ausgereiften Prozess um das Interposer+HBM-Abenteuer zu wagen, NV versucht gleich alles auf einmal. Man sollte da nicht zu schnell Ergebnisse erwarten. So wie bei Maxwell von Tapeout zu finalem Produkt innerhalb eines Jahrs, wie bei GM200, ist da einfach nicht zu erwarten. Einen Respin beim GP100 gab es offenbar, da ist also schon 1/2 Jahr mal eben einfach weg.

Fiji hat auch fast ein Jahr gebraucht. Bei GM204 war es afaik ungefähr ein halbes Jahr+ vom TapeOut zu Release.

Nightspider

2015-11-09, 19:37:43

Wenn AMD das schafft, mit ihrem kleinen Team und den begrenzten R&D-Mitteln, sollte NV das wohl auch hinbekommen. Ziemliche Schwarzmalerei IMHO.

Weißt du denn wie groß die Teams von AMD und NV sind?

AMD hat auch Top-Ingenieure und die beschäftigen sich eben schon viel länger mit der Materie.
AMD hat schließlich direkt mit Hynix zusammengearbeitet.

Genau genommen kann von uns keiner einschätzen wie die Situation genau aussieht.

BlacKi

2015-11-09, 20:00:21

hbm1 kann man doch praktisch ausschließen da die speichermenge viel zu klein wäre, speziell für den prof. einsatz. gp100 muss doch eigentlich mit hbm2 kommen. alles was zu gp100 bekannt ist spricht eindeutig für hbm2.

wenn sich hbm2 verpätet, dann kommt gp104 eben mit gddr5x und gp100 kommt verspätet.

HOT

2015-11-09, 20:02:05

Wenn AMD das schafft, mit ihrem kleinen Team und den begrenzten R&D-Mitteln, sollte NV das wohl auch hinbekommen. Ziemliche Schwarzmalerei IMHO.
AMD hat das geschafft, aber nicht mit einem kleinen Team sondern mit bald einem Jahrzehnt Entwicklungsarbeit. NV wird das auch schaffen, aber nicht in Rekordzeit. Und nein, NV wird garantiert nicht auf GDDR5X setzen, das wäre bescheuert. Die werden auch botton -> top HBM2 einsetzen. Würden sie auf GDDR setzen, gäbe es schon lange umherwandernde GP104 und dann hätten die sicher nicht mit GP100 angefangen.

Ailuros

2015-11-09, 20:45:16

Godmode

2015-11-10, 13:09:38

Wohl 3 verschieden Compute Capabilities bei Pascal:
http://forums.laptopvideo2go.com/topic/31826-nvidia-geforce-driver-35866-adds-vulkan-pascal-and-volta-support/

Die CUDA-DLL nennt auch gleich ein paar Codenamen:

GP100
GP102
GP104
GP106
GP107
GP10B

GV100

Ich frage mich was GP102 sein sein soll? GP100 ist wohl klar, das ist die HPC-Variante mit NVLink. Könnte GP102 ein GP100 ohne NVLink sein?

Weißt du denn wie groß die Teams von AMD und NV sind?

AMD hat auch Top-Ingenieure und die beschäftigen sich eben schon viel länger mit der Materie.
AMD hat schließlich direkt mit Hynix zusammengearbeitet.

Genau genommen kann von uns keiner einschätzen wie die Situation genau aussieht.

Keine Ahnung, aber NV kann das ganze R&D Budget für ihre GPUs verwenden, AMD muss das auch mit der CPU Sparte teilen. Ich wollte damit nicht ausdrücken, das AMD nicht fähig ist oder sowas in der Art.

Nakai

2015-11-10, 13:39:35

Mhh, GP102 könnte zu GP100 stehen, wie G92 zu G80.
Kurz, kein NVLink, weniger MixedPrecision, weniger Caches, etc. also ein GP100 fürs Gaming.

Oder:
GP102 ist einfach ein GP100 auf anderem HBM2-Package. Also statt 4 4GB-HBM2-Stacks also 4 2GB-HBM2-Stacks und natürlich HPC-Features beschnitten.

Timbaloo

2015-11-10, 13:48:28

Also Bezechnung nicht nach GPU (Die) sondern nach dem gesamten Package inkl. Speicher?

Nakai

2015-11-10, 14:08:59

Also Bezechnung nicht nach GPU (Die) sondern nach dem gesamten Package inkl. Speicher?

Könnte ich mir vorstellen.

Hübie

2015-11-10, 15:31:55

Egal wie oft man einiges versucht zu erklaeren gibt es immer die jeweiligen hoffnungslos romantischen mit der endlosen Kaffeesatz-leserei.

GP100 wird dringend im HPC gebraucht und sonst lassen sich IHVs aus Kosten-Gruenden Zeit mit FF Prozessen.

Genauso wie die xpea Persona hier die glaubt dass die 16FF+ yields besser sei werden als bei 28HP:
https://forum.beyond3d.com/threads/nvidia-pascal-speculation-thread.55552/page-18
Idiotischer Zufall dass Apple den A9 eben nicht nur unter 16FF+ herstellt, ja warum wohl....dafuer liegt dieser Ext3h ziemlich nahe an der Realitaet.

Und so war es doch auch hier schon diskutiert worden. Big Pascal Q2 '16 HPC, dann vielleicht GP104 als GeForce und Ende '16 dann GP100 oder 102 für Desktop. Ohne 32 GiB und NVLink, aber mit HBM2 und mixed Precision. Frage ist dann für mich: wo ordnet man dann GM200 ein, da dieser doch recht Leistungsstark ist und ein hypothetischer GP104 es (rein auf die Spieleperformance bezogen) schwer haben dürfte hier zu punkten.
Schlechtere yields setzen einen deutlich kleineren Die voraus und das wiederum bedeutet nur etwas mehr oder gleich viele ALUs, ROPs, TMUs und ähnliches Frontend. Sagen wir 320 Quadratmillimeter für GP104. Das könnten dann 3072+ ALUs sein, Takt (???) 1500 MHz bei 1150 mV. Hierfür könnte man 650-750€ aufrufen und müsste GM200 auf 500-550 senken. Dann GM204 auf 400 usw. Wäre nicht abwegig, oder was denkt ihr?? Ein "Shader Multiprocessor" dürfte sich ja gar nicht so großartig verändern, wenn man den Gerüchten glauben kann...

Agent117

2015-11-10, 15:51:36

320mm² hauen denke ich schon ganz gut hin; es gab ja shconmal Gerüchte, dass
a) GP100 ca. 17Mrd Transistoren haben wird und b)16nm FF keine 600mm² großen Chips erlaubt.
Demnach könnte die Packdichte wohl wirklich bei mehr als 100% ggü. 28nm liegen.

Wirklich spannend finde ich GP102. Hier muss man vlt auch betrachten, was AMD macht und die können meiner Meinung nur wirklich Marktanteil gewinnen, wenn sie die Performancekrone holen.
Vlt wurde hier mitGP102 wirklich einen reiner Gaming Chip eingeschoben, der an die Grenzen von 16nm FF geht aber auch etwas später erscheint, um die Performancekrone nicht zu verlieren.

BlacKi

2015-11-10, 16:30:06

Hierfür könnte man 650-750€ aufrufen und müsste GM200 auf 500-550 senken. Dann GM204 auf 400 usw. Wäre nicht abwegig, oder was denkt ihr?? Ein "Shader Multiprocessor" dürfte sich ja gar nicht so großartig verändern, wenn man den Gerüchten glauben kann...

ich denke das ist zu zaghaft gedacht. ich glaube auch nicht an 750€ für gp104. eher 600 bis 650€ nachdem die preise sich stabilisiert haben.

nur meine meinung.

Hübie

2015-11-10, 16:36:20

BlacKi

2015-11-10, 16:43:03

nVidia muss aber Renditen bringen. Also ist deine Meinung da erst mal wenig relevant. Wir können uns ja auf 650 einigen.

Die Preisspanne liegt bei 650-850 und im Mittel demnach bei ~750. Okay, das eine ist der Marktpreis und das andere der USP. Ich meine natürlich letzteres in meiner obigen Aussage. Ist ja auch nur spekulativ, auf bisherigen Erfahrungen und Inforamtionen basierend.

der marktpreis wird von nvidia nur indirekt beeinflusst. nvidia hat für die 680 500$verlangt für die 980 550$.

wenn sie nicht genug karten produzieren können, dann steigt der preis halt auf 850euro, ist für mich aber nicht relevant, da der preis bei verfügbarkeit schnell sinken wird. und wer weiß wie der dollar/euro kurs nächstes jahr steht.

usp preis ist da eher stabil, darüber lässt sich ernsthafter disktutieren. aber da gehören noch mehrere faktoren dazu, auch amd spielt da eine rolle. finde aber das ist alles zu spekulativ, deshalb geh ich mal von 550-600$ usp aus.

Godmode

2015-11-10, 16:59:01

Und so war es doch auch hier schon diskutiert worden. Big Pascal Q2 '16 HPC, dann vielleicht GP104 als GeForce und Ende '16 dann GP100 oder 102 für Desktop. Ohne 32 GiB und NVLink, aber mit HBM2 und mixed Precision. Frage ist dann für mich: wo ordnet man dann GM200 ein, da dieser doch recht Leistungsstark ist und ein hypothetischer GP104 es (rein auf die Spieleperformance bezogen) schwer haben dürfte hier zu punkten.
Schlechtere yields setzen einen deutlich kleineren Die voraus und das wiederum bedeutet nur etwas mehr oder gleich viele ALUs, ROPs, TMUs und ähnliches Frontend. Sagen wir 320 Quadratmillimeter für GP104. Das könnten dann 3072+ ALUs sein, Takt (???) 1500 MHz bei 1150 mV. Hierfür könnte man 650-750€ aufrufen und müsste GM200 auf 500-550 senken. Dann GM204 auf 400 usw. Wäre nicht abwegig, oder was denkt ihr?? Ein "Shader Multiprocessor" dürfte sich ja gar nicht so großartig verändern, wenn man den Gerüchten glauben kann...

Warum sollten sie GM200 weiterlaufen lassen? Der Highendchip einer Generation lief bisher nie weiter, sondern wurde einfach nicht mehr produziert, sobald der neue Highend Chip der nächsten Generation am Markt war. Rebranding brauchen wir auch nicht, da es GP104 gibt, also wird auch kein GM204 weiter produziert. Einzig extrem beschissene Yields würden für ein weiterführen der alten Generation sprechen, aber das wird sich mit der Zeit auch verbessern.

Ailuros

2015-11-10, 18:13:59

320mm² hauen denke ich schon ganz gut hin; es gab ja shconmal Gerüchte, dass
a) GP100 ca. 17Mrd Transistoren haben wird und b)16nm FF keine 600mm² großen Chips erlaubt.
Demnach könnte die Packdichte wohl wirklich bei mehr als 100% ggü. 28nm liegen.

GM200 liegt bei irgendwo 13.5Mio/mm2. Doppelt so viel waeren 27Mio/mm2 welches verdammt schlecht waere da es bei 17Mrd. dann 629mm2 oder ich verrechne mich gerade wieder. Ich tippe eher in Richtung 35Mio/mm2 welches dann auch irgendwo 480+mm2 gibt, welches mir auch ziemlich normal erscheint.

ULP SoCs sind zwar kein Vergleich zu einem GPU chip, aber wenn Apple im A8X@20SoC knapp 24Mio/mm2 reinpacken konnte, sind 35 fuer 16FF+ ziemlich logisch/konservativ spekuliert IMHO. Je nach Transistor-count im heutigen A9@16FF+ --->101mm2 koennten es sogar fast 38Mio/mm2 sein.

BlacKi

2015-11-10, 18:26:04

GM200 liegt bei irgendwo 13.5Mio/mm2. Doppelt so viel waeren 27Mio/mm2 welches verdammt schlecht waere da es bei 17Mrd. dann 629mm2 oder ich verrechne mich gerade wieder. Ich tippe eher in Richtung 35Mio/mm2 welches dann auch irgendwo 480+mm2 gibt, welches mir auch ziemlich normal erscheint.

ULP SoCs sind zwar kein Vergleich zu einem GPU chip, aber wenn Apple im A8X@20SoC knapp 24Mio/mm2 reinpacken konnte, sind 35 fuer 16FF+ ziemlich logisch/konservativ spekuliert IMHO. Je nach Transistor-count im heutigen A9@16FF+ --->101mm2 koennten es sogar fast 38Mio/mm2 sein.
Wie Fudzilla in Erfahrung gebracht haben wollen, bringt nVidias Pascal-Chip GP100 mit 17 Milliarden Transistoren in der 16FF+ Fertigung von TSMC einiges auf die Waage – gegenüber dem GM200-Chip der Maxwell-Generation (~8 Mrd. Transistoren) wäre dies sogar etwas mehr als eine Verdopplung der Transistorenanzahl.http://www.3dcenter.org/news/hardware-und-nachrichten-links-des-24-juli-2015

Hübie

2015-11-10, 18:33:55

Warum sollten sie GM200 weiterlaufen lassen? Der Highendchip einer Generation lief bisher nie weiter, sondern wurde einfach nicht mehr produziert, sobald der neue Highend Chip der nächsten Generation am Markt war. Rebranding brauchen wir auch nicht, da es GP104 gibt, also wird auch kein GM204 weiter produziert. Einzig extrem beschissene Yields würden für ein weiterführen der alten Generation sprechen, aber das wird sich mit der Zeit auch verbessern.

Was macht dich da so sicher? :P

Ailuros

2015-11-10, 18:40:50

Wie Fudzilla in Erfahrung gebracht haben wollen, bringt nVidias Pascal-Chip GP100 mit 17 Milliarden Transistoren in der 16FF+ Fertigung von TSMC einiges auf die Waage – gegenüber dem GM200-Chip der Maxwell-Generation (~8 Mrd. Transistoren) wäre dies sogar etwas mehr als eine Verdopplung der Transistorenanzahl.http://www.3dcenter.org/news/hardware-und-nachrichten-links-des-24-juli-2015

Lies meinen Beitrag nochmal sehr vorsichtig durch. Ich hab die 17Mrd nirgends bezweifelt. Es geht um Packdichte bzw. Transistoren/mm2. Ich hoffe Agent meinte mit den 320mm2 nicht GP100, denn wenn ja waeren es >53Mio/mm2; wir sind noch bei 16 und nicht schon bei 10FF :P

Hübie

2015-11-10, 18:44:26

Die 320 mm² habe ich für GP104 angeführt, geht nicht auf Agent seine Kappe. Wobei der Name als Platzhalter des GM204-Nachfolgers herhalten soll. Also GTX 980 plus ~30% was etwa GM200 entspräche.

Da sich GM200 im Profi-Segment nicht sehr gut verkauft müsste man ja langsam die Produktion schon drosseln und Anfang 2016 auslaufen lassen.

Agent117

2015-11-10, 18:58:38

GM200 liegt bei irgendwo 13.5Mio/mm2. Doppelt so viel waeren 27Mio/mm2 welches verdammt schlecht waere da es bei 17Mrd. dann 629mm2 oder ich verrechne mich gerade wieder. Ich tippe eher in Richtung 35Mio/mm2 welches dann auch irgendwo 480+mm2 gibt, welches mir auch ziemlich normal erscheint.

ULP SoCs sind zwar kein Vergleich zu einem GPU chip, aber wenn Apple im A8X@20SoC knapp 24Mio/mm2 reinpacken konnte, sind 35 fuer 16FF+ ziemlich logisch/konservativ spekuliert IMHO. Je nach Transistor-count im heutigen A9@16FF+ --->101mm2 koennten es sogar fast 38Mio/mm2 sein.

35Mio/mm² wären schon brutal aber passt wie du schon geschrieben hast zu Apples A9 in FF+. Ich habe auch in Erinnerung, dass 16nm FF+ zunächst keinen 600mm²+ Chip zulassen soll; das passt dann auch zu einen ca. 500mm² GP100 mit 17Mrd Transistoren.
Erstaunlich nur, dass die Packdichte so brachial steigt, die Energieeffizienz sich aber laut Nvidia nur um den Faktor 1,67 steigert.

AffenJack

2015-11-10, 19:06:01

Da sich GM200 im Profi-Segment nicht sehr gut verkauft müsste man ja langsam die Produktion schon drosseln und Anfang 2016 auslaufen lassen.

Welcher GM200 im Profisegment? GM200 wurde doch erst heute im Profisegment mit Tesla M40 gelauncht.

Nakai

2015-11-10, 19:12:04

35Mio/mm² wären schon brutal aber passt wie du schon geschrieben hast zu Apples A9 in FF+. Ich habe auch in Erinnerung, dass 16nm FF+ zunächst keinen 600mm²+ Chip zulassen soll; das passt dann auch zu einen ca. 500mm² GP100 mit 17Mrd Transistoren.
Erstaunlich nur, dass die Packdichte so brachial steigt, die Energieeffizienz sich aber laut Nvidia nur um den Faktor 1,67 steigert.

Man sollte noch HBM2 in die Rechnung einbeziehen. Das spart nochmal ~50W.
Kurz die Energieeffizienz steigt schon um die 100% an. Man kann schon 80~100% Performanceboost erwarten, wenn alles linear skaliert.

Ailuros

2015-11-10, 20:14:13

35Mio/mm² wären schon brutal aber passt wie du schon geschrieben hast zu Apples A9 in FF+. Ich habe auch in Erinnerung, dass 16nm FF+ zunächst keinen 600mm²+ Chip zulassen soll; das passt dann auch zu einen ca. 500mm² GP100 mit 17Mrd Transistoren.
Erstaunlich nur, dass die Packdichte so brachial steigt, die Energieeffizienz sich aber laut Nvidia nur um den Faktor 1,67 steigert.

Das Problem mit 20SoC war/ist eben dass es leider zu viel Strom verbraucht hat fuer das was es lieferte. Hier eine weitere Bestaetigung von Huawei:

http://www.notebookcheck.com/fileadmin/Notebooks/News/_nc2/Huawei_Kirin_950_AH_06.jpg

Sonst wenn IHVs =/>35Mio/mm2 unter 16FF+ quetschen konnten, brauchen sie auch nicht wirklich >500mm2 chips am Ende.

Godmode

2015-11-10, 21:01:10

Was macht dich da so sicher? :P

Sag mir einen vernünftigen Grund warum man GM200 weiterlaufen lassen sollte? Verglichen mit GP100 wird die Titan X einfach nur arm aussehen. Sobald die Yields gut genug sind um GP100 wirtschaftlich fertigen zu können, wird GM200 ersetzt.

Pascal
-D__CUDA_ARCH__=600
-D__CUDA_ARCH__=610
-D__CUDA_ARCH__=620

Volta
-D__CUDA_ARCH__=700

Das Pascal 3 verschiedene Compute Capabilities hat, deutet wohl dann auf verschiedene ALUs hin. Eventuell bekommt nur GP100 16/32/64 Bit fähige ALUs und die Consumer Varianten nur SP ALUs.

Skysnake

2015-11-10, 22:55:08

Durchaus möglich, wäre aber schon eine recht große Investition in den Compute-Bereich, allerdings muss nVidia da halt auch wirklich liefern.
GM200 liegt bei irgendwo 13.5Mio/mm2. Doppelt so viel waeren 27Mio/mm2 welches verdammt schlecht waere da es bei 17Mrd. dann 629mm2 oder ich verrechne mich gerade wieder. Ich tippe eher in Richtung 35Mio/mm2 welches dann auch irgendwo 480+mm2 gibt, welches mir auch ziemlich normal erscheint.

ULP SoCs sind zwar kein Vergleich zu einem GPU chip, aber wenn Apple im A8X@20SoC knapp 24Mio/mm2 reinpacken konnte, sind 35 fuer 16FF+ ziemlich logisch/konservativ spekuliert IMHO. Je nach Transistor-count im heutigen A9@16FF+ --->101mm2 koennten es sogar fast 38Mio/mm2 sein.
Der ganze NVLink geraffel wird aber eine ziemlich geringe Packdichte haben, und auch nicht wirklich klein ausfallen bei so vielen Lanes und so hohen Taktraten. Dafür wird das Speicherinterface kleiner. Schwer da abzuschätzen, was da wie überwiegt. Je kleiner der Anteil an reinen Compute-Sachen ist, bzw Caches/Registern, desto schwerwiegender sind die low "density analog-"Bereiche.

Man muss sich allerdings auch wieder fragen, was da alles mit rein gezählt wird... Man kann da ja sehr kreativ zählen, wie wir von AMD wissen ;)

Timbaloo

2015-11-10, 23:05:58

Das Pascal 3 verschiedene Compute Capabilities hat, deutet wohl dann auf verschiedene ALUs hin. Eventuell bekommt nur GP100 16/32/64 Bit fähige ALUs und die Consumer Varianten nur SP ALUs.
Wars nicht so, dass FP16 auch für Spiele interessant wäre? Weil dann sollten die Consumer-Chips auch FP16 können. Siehe auch Tegra X1.

kdvd

2015-11-11, 00:57:12

FP16/32 Mixed Mode werden auch die kleineren Pascals können, aber die extra FP64er werden wohl wieder nur auf GP100 zufinden sein. Ausser Nvidia hat ALUs die alles können und effektiv sind.

Hübie

2015-11-11, 01:23:59

Welcher GM200 im Profisegment? GM200 wurde doch erst heute im Profisegment mit Tesla M40 gelauncht.

Quark. Quadro M6000 gibt es schon lange. Und weshalb man erst jetzt so halbherzig M40 launcht kannst du dir ja denken. ;)
Am 19. sollte es wieder was neues geben.

Sag mir einen vernünftigen Grund warum man GM200 weiterlaufen lassen sollte? Verglichen mit GP100 wird die Titan X einfach nur arm aussehen. Sobald die Yields gut genug sind um GP100 wirtschaftlich fertigen zu können, wird GM200 ersetzt.

Das vielleicht nicht gleich ein ganzes Lineup auf einem neuen Prozess zur Verfügung steht wäre doch ein vernünftiger Grund, findest du nicht? Schau dir mal die aktuellen Zahlen von den grünen an und rate mal wo fette Margen liegen. :biggrin:

Godmode

2015-11-11, 07:57:46

FP16/32 Mixed Mode werden auch die kleineren Pascals können, aber die extra FP64er werden wohl wieder nur auf GP100 zufinden sein. Ausser Nvidia hat ALUs die alles können und effektiv sind.

Wäre natürlich auch eine Möglichkeit. Die Frage ist da aber, wieviel Aufwand ist es, eine FP16/32 ALU noch FP64 fähig zu machen? Ist das wirklich so teuer, oder ist das eine produktpolitische Entscheidung?

Das vielleicht nicht gleich ein ganzes Lineup auf einem neuen Prozess zur Verfügung steht wäre doch ein vernünftiger Grund, findest du nicht? Schau dir mal die aktuellen Zahlen von den grünen an und rate mal wo fette Margen liegen. :biggrin:

Sie könnten natürlich wieder das Spielchen spielen, dass sie zuerst GP104 bringen, der dann schneller ist, als der jetzige GM200 und unter dem Namen GTX 1080 liefe. GM200 könnte dann als GTX 1070 laufen, falls der Prozess wirklich so schweineteuer ist, wie Ailuros meint.

GP100 wird wohl ziemlich sicher zuerst in den Profimärkten vorgestellt werden, weil dort kann NV pro GPU deutlich mehr einnehmen, wodurch das ganze früher die Wirtschaftlichkeit erreicht. Wenn die Fertigung billiger geworden ist, könnte GP100 - oder wie auch immer die Consumervariante heißen mag - für uns Endkunden vorgestellt werden.

Hübie

2015-11-11, 08:16:55

Thunder99

2015-11-11, 12:57:21

Dann steigt wohl der durchschnittliche Verkaufspreis. Nvidia Kunden wurden ja schon in der Vergangenheit darauf sensibilisiert :wink:

Godmode

2015-11-11, 13:30:38

Ich bin mir ziemlich sicher, dass wir keine vierstellige Zahl sehen werden.
Der Prozess müsste doppelt so teuer sein um einen die Nummer zu versauen. Das ist glaub ich nicht ganz der Fall. Allerdings ist das assembling recht teuer. Also das Produkt selber wird deutlich höhere Kosten haben, die man mit Mengen abfedern müsste, was "dank" suboptimaler yieldrates anfangs schwierig werden dürfte.

Die Zahl war nur ein Beispiel, was für ein Produkt ich meine.

Dann steigt wohl der durchschnittliche Verkaufspreis. Nvidia Kunden wurden ja schon in der Vergangenheit darauf sensibilisiert :wink:

Ich gehe auch fast davon aus, dass wir wieder mal etwas mehr gemolken werden.

Kartenlehrling

2015-11-11, 13:59:38

N0Thing

2015-11-11, 14:01:23

Die Hersteller können ja eine Backplate aus Blei für die Kunden mitliefern, die nicht nach Balkenlänge sondern nach Gewicht kaufen. :D

Godmode

2015-11-11, 15:11:23

Bin auf die grösse der Karten gespannt, die Gtx750ti hatte damal bei mir schon ein Waauu Effekt gehabt.
Wenn man seine 1000g schwere GTX980ti gegen ein kleines stück Pfund Pascal Butter austauscht, will die Leute sehen die sich nicht fragen:" wofür haben ich 1499€ bezahlt?".

Die TDP wird ja trotzdem irgendwo bei 250W bleiben für den großen Pascal. Also entweder Hybridkühler so wie bei der Fury, oder eben normaler DHE, wie bisher. Zumindest könnten sie den Kühler weiter verbessern, weil der ist ja seit der Ur-Titan ziemlich gleich geblieben.

Agent117

2015-11-11, 15:30:24

Man sollte noch HBM2 in die Rechnung einbeziehen. Das spart nochmal ~50W.
Kurz die Energieeffizienz steigt schon um die 100% an. Man kann schon 80~100% Performanceboost erwarten, wenn alles linear skaliert.

Nein, die ersparnis durch HBM bedeutet doch dass die Architektur und Fertigung umso weniger mehr Effizient werden.

Mal ausgehend von der Titan X mit 250W TDP und Verbrauch bei Spielen.
250W/1,67=150W
150W+50W (Ersparnis durch HBM) = 200W
200W/250W = 0,8.
Das heißt, angenommen HBM spart 50W, liegt der Effizienzgewinn aus neuer Fertigung und neuer (weitestgehend gleicher?) Architektur bei gerade mal 25%. Das wäre schon sehr sehr wenig was 16nm FF+ dann an Energiebedarf einspart.
80-100% Performanceplus erscheinen da doch eher utopisch außer Nvidia geht auf >300W TDP.
AMD gibt hingegen ja sogar 2*Perf/W an, wobei hier die zusätzliche Ersparnis durch HBM wegfällt, wenn sie Fiji als Basis nehmen. Hoffe mal das Post GCN hält was es verspricht und es am Ende nicht auf HawaiiXT bezogen war und das dann noch unter günstigsten Bedingungen.

Nakai

2015-11-11, 17:08:46

Wäre natürlich auch eine Möglichkeit. Die Frage ist da aber, wieviel Aufwand ist es, eine FP16/32 ALU noch FP64 fähig zu machen? Ist das wirklich so teuer, oder ist das eine produktpolitische Entscheidung?

Naja der Schritt von 16 auf 32 ist ja ähnlich zu 32 auf 64. Kurz, das wird kein großes Problem sein. Die Frage ist eher, wie sehr die FPUs dadurch aufgebläht werden und wie sich die Latenzen diesbezüglich verhalten. Womöglich haben Mixed-Precision-FPUs eine deutlich höhere Latenz. Hierzu gibt es auch ein Paper. Dadurch wird die Taktfähigkeit etwas eingeschränkt. NVs Latenz liegt bei 5 (6?) Takten, AMDs bei 4. Ergo könnte das auch ein Grund sein, wieso die NVs besser taktbar sind.
Es kommt eben immer drauf an.

Nein, die ersparnis durch HBM bedeutet doch dass die Architektur und Fertigung umso weniger mehr Effizient werden.

Mhh, wieso addierst du die 50W?
Laut TSMC bringt 16FF+ 60~70% bessere Energieeffizienz. Ich denke in den Zahlen ist HBM noch nicht einbezogen.

Agent117

2015-11-11, 18:51:03

Mhh, wieso addierst du die 50W?
Laut TSMC bringt 16FF+ 60~70% bessere Energieeffizienz. Ich denke in den Zahlen ist HBM noch nicht einbezogen.

Ok, TSMCs Aussagen sind natürlich auch ein Anhaltspunkt, meine Grundlage war jedoch die Nvidia Roadmap zu Pascal
http://www.nextplatform.com/wp-content/uploads/2015/03/nvidia-tesla-roadmap.jpg
Da liegt Maxwell bei 25 SGEMM/W und Pascal bei 40-42; das entspricht dann auch der 1,67-fach höheren Effizienz die Nvidia schonmal nannte.

Dort sollte der HBM Vorteil auch bereits drinnstecken, wird ja auch unter Pascal angegeben.
Die 50W habe ich vorhin drauf addiert um zu zeigen, dass Pascal im neuen Prozess ohne den HBM Vorteil nur 25% effizienter wird.

Hübie

2015-11-11, 19:26:25

iuno

2015-11-11, 19:28:21

Solche Angaben sind natuerlich hoechst ungenau. Noch dazu, wird Nvidia die naechste Generation wohl wieder mehr ausfahren, einfach weil sie es muessen Maxwell ist auf DX11 und Energiesparen getrimmt. Beim Computing ist die Effizienz ja nicht ueber Kepler oder GCN, wenn eine Karte derselben Leistungsklasse wieder mehr Watt aufnehmen darf, sinkt dementsprechend der Effizienzgewinn. Moeglicherweise beruecksichtigen sie das ja in so einem Diagramm.
@Huebie: Wenn es ums Produkt geht liegt man aber richtig, das mitzunehmen, denn daran wird letztendlich gemessen werden. Bei der Nano wird ja auch nicht GCN 1.3 wegen der hoeheren Effizienz gelobt und im Vorfeld hat sich viel um das Thema gedreht. Letztendlich bleibt HBM immer noch sehr spannend, auch oder gerade weil das bei Fiji nicht so ganz hingehauen hat.

Ailuros

2015-11-11, 19:33:39

Die 2-fache Perf/W von Fiji hat Hawaii als Grundlage. Und was bitte hat die Effizienz der GPU mit HBM gemein? Du misst mit zweierlei Maß. Du betrachtest ein hypotetisches Produkt, nicht den Chip. Das bitte ich zu differenzieren. ;)

Schon seit Jahren haben alle IHVs bei jeder neuen "Generation" doppelt so hohe Leistung im Hinterkopf. Mit wenigen Ausnahmen gilt es fast immer nur ist es auch immer ein "bis zu" und eben nicht Durchschnitts-wert. Wer verrueckt hohe perf/W Unterschiede zwischen Pascal und Maxwell sehen will sollte einfach FP64 throughput/Watt zwischen GP100 und GM200 vergleichen :P Nicht dass es fair ist, aber der Verbraucher der einen ehlendig hohen Preis fuer das erste bezahlen wird, will wohl auch etwas mehr "halo" als nur beschissene 70% Unterschied sehen :freak::P

Hübie

2015-11-11, 19:36:49

Ausgehend von Hawaii ist unfair genug :biggrin:

Agent117

2015-11-11, 19:37:03

Die 2-fache Perf/W von Fiji hat Hawaii als Grundlage. Und was bitte hat die Effizienz der GPU mit HBM gemein? Du misst mit zweierlei Maß. Du betrachtest ein hypotetisches Produkt, nicht den Chip. Das bitte ich zu differenzieren. ;)

Hast du eine Quelle dafür dass sie sich auf Fiji beziehen? Habe das noch nie so gehört, wäre aber interessant und zumindest ein wenig genauer dann.

Die Roadmap betrachtet das fertige Produkt in Form einer Tesla. Das ist höchst wahrscheinlich das, was man mit einem GP100 erreichen kann und der kommt ja bekanntlich mit HBM. Welchen Sinn würde es auch machen auf einer Roadmapnur die GPU zu betrachten wenn die Effizienz des fertigen Produktes dann noch deutlich durch HBM erhöht wird?

Nur die GPU betrachtet wäre GP100 dann nur 25% effizienter als GM200.
Die zusätzliche Ersparnis aus HBM bringt ihn dann auf einen Effizienzgewinn von 67% (Nvidia Angabe).

Hübie

2015-11-11, 19:39:46

Ich meine es stand auf damaligen Folien als * markiert. Wurde aber auch mehrfach erwähnt. Google das mal selber.

Solche Angaben sind natuerlich hoechst ungenau. Noch dazu, wird Nvidia die naechste Generation wohl wieder mehr ausfahren, einfach weil sie es muessen Maxwell ist auf DX11 und Energiesparen getrimmt. Beim Computing ist die Effizienz ja nicht ueber Kepler oder GCN, wenn eine Karte derselben Leistungsklasse wieder mehr Watt aufnehmen darf, sinkt dementsprechend der Effizienzgewinn. Moeglicherweise beruecksichtigen sie das ja in so einem Diagramm.
@Huebie: Wenn es ums Produkt geht liegt man aber richtig, das mitzunehmen, denn daran wird letztendlich gemessen werden. Bei der Nano wird ja auch nicht GCN 1.3 wegen der hoeheren Effizienz gelobt und im Vorfeld hat sich viel um das Thema gedreht. Letztendlich bleibt HBM immer noch sehr spannend, auch oder gerade weil das bei Fiji nicht so ganz hingehauen hat.

Ich sage ja nicht dass es verkehrt ist, denn am Ende halte ich ein Produkt in den Händen. ;) Beim Die selber rechnet man aber eben kein RAM mit ein.

Edit: Okay waren wohl nur 1,5x. Nano hat 2x.

The Fury X is a liquid-cooled card, while the vanilla Fury sticks to air cooling. The Nano is a six-inch-long, air-cooled card that Su says is good for two times the performance-per-watt of the R9 290X. The Fury X will be 1.5 times as power-efficient as the 290X.

Quelle (http://techreport.com/news/28481/amd-fiji-gpu-rides-in-on-four-radeon-r9-fury-graphics-cards)

Ailuros

2015-11-11, 19:48:17

Perf/W ist hoeher bei Pascal vs. Maxwell als Maxwell vs. Kepler eben weil der Prozess diesmal einiges dazuliefert. Sonst wer sich amuesieren will: http://semiaccurate.com/forums/showpost.php?p=247961&postcount=260

Nakai

2015-11-11, 19:49:52

Ok, TSMCs Aussagen sind natürlich auch ein Anhaltspunkt, meine Grundlage war jedoch die Nvidia Roadmap zu Pascal
http://www.nextplatform.com/wp-content/uploads/2015/03/nvidia-tesla-roadmap.jpg
Da liegt Maxwell bei 25 SGEMM/W und Pascal bei 40-42; das entspricht dann auch der 1,67-fach höheren Effizienz die Nvidia schonmal nannte.

Dort sollte der HBM Vorteil auch bereits drinnstecken, wird ja auch unter Pascal angegeben.
Die 50W habe ich vorhin drauf addiert um zu zeigen, dass Pascal im neuen Prozess ohne den HBM Vorteil nur 25% effizienter wird.

Oke, verstehe.

Mhh, das ist SGEMM. Das ist ja Matrizen Multiplikation bei Single Precision.
NV hat die Roadmap auch kontinuierlich geändert, bzw. oft angepasst.
AMD hat eine 50W Einsparung zwischen GDDR5 und HBM angegeben. Dabei sind die 50W im Vergleich zwischen 8GHz 128Bit GDDR5 und ein HBM-Stack gemessen. Kein IHV hat dabei den GDDR5 mal so richtig ausgefahren.

Und nochmal, das ist SGEMM, also Single Precision. Das hat erstmal nicht soviel mit Double Precision oder Half Precision zu tun. Außerdem ist die Roadmap sehr widersprüchig, aber dennoch ausschlaggebend. Die Frage ist eher, was man hier vergleicht. Der Sprung von Kepler auf Maxwell ist nahezu 100%. In GPU Computing war Maxwell schon deutlich performanter als Kepler. Kurz die 100% treffen eigentlich am besten auf GK104 und GM204 zu.

Wir können gerne extrapolieren, von GM200 auf GP100 mit den 67% Vorteil. Das sollte dann so leicht über 5000SPs hinauskaufen.
Ich bin mal sehr milchmädchenhaft. Bei einer GPU sind etwa 50% der Diesize mit SMs/CUs besetzt. Umso größer der Chip wird desto größer wird auch der Anteil der SMs/CUs. Bei GK110 sind es eher 50~60% SMs. Nehmen wir mal doppelte Packdichte dank 16FF+, dann wäre GM200 etwa 300mm² groß. Bei ~67% mehr SMs wär man leicht über 400mm². Da kommen natürlich noch Verbesserungen, etwas mehr Cache und natürlich stärker DP-Support, als auch MixedPrecision hinzu und man kommt schnell an die 500mm² hin. So DP-Einheiten oder DP-Support wird auch etwas an der Effizienz nagen und den Stromverbrauch erhöhen. Vor allem werden es diesmal Multi-Precision-Einheiten, ergo werde die definitiv mehr Energie schlucken.

Summa summarum:
5120 SPs (klingt gut)
40 SMs
8 GPCs ala 5 SMs pro GPC
128 ROPs (8 GPCs; 16 Pixel pro GPC)
320 TMUs
8MB L2-Cache

8 GPCs würde gut zu den 4 ROP-Partitions, sowie 4 HBM-Stacks, passen. Je Stack benötigt man 8 Memory Channels mit 128 Bit. Pro Memory Channel gibt es ein L2-Cache. Bei der hohen Packdichte würde mich verdammt viel Cache nicht wundern. Ich sage mal 8MB L2-Cache, also pro Memory Channel 256KB L2-Cache. AMD hat bei Fiji wohl 64KB pro Memory Channel eingebaut gehabt. Ahja damit wäre GP100 deutlich mehr an Compute orientiert als alle Vorgänger, vor allem wenn man 4:2:1 - HP : SP : DP besitzt.
Wobei man sagen muss, dass dieses Verhältnis wohl schon früher promotet wurde, falls es tatsächlich zutrifft. :confused:

€: Ahja den Takt hab ich absichtlich nicht milchmädchen-gerechnet. So groß wie GM200 wird GP100 mit Sicherheit nicht. Selbstverständlich das maximal vernünftige.

Ailuros

2015-11-11, 19:53:41

Ich weiss zwar nichts aber ich bezweifle so langsam auch dedizierte FP64 Einheiten bei Pascal. Mit 1:2 wuerde ich da nicht rechnen weil es ziemlich teuer ist aus den eigentlichen FP32 ALUs.

AffenJack

2015-11-11, 20:03:22

Kommt drauf an ob GP100 überhaupt noch für Consumer kommt. Mit dem Auftauchen dieses ominösen GP102 wäre ich mir da nicht mehr sicher. Mag sein, dass Nvlink/DP einfach zuviel Platz wegnimmt und man diesmal die Chips wirklich trennt und dann könnte man auch 1:2 DP reinpacken.

Ailuros

2015-11-11, 20:13:17

Im allerbesten Fall wird IMHO GP100 bei =/>3.5 TFLOPs DP liegen. An mehr glaube ich erst wenn ich es sehe.

Nakai

2015-11-11, 20:17:13

Ich weiss zwar nichts aber ich bezweifle so langsam auch dedizierte FP64 Einheiten bei Pascal. Mit 1:2 wuerde ich da nicht rechnen weil es ziemlich teuer ist aus den eigentlichen FP32 ALUs.

Ich gehe auch nicht von dedizierten FP64 Einheiten aus. Und wenn es kein 1:2 Verhältnis wird, kann man dementsprechend natürlich eine höher Anzahl an SPs verbauen. Bei 6000 SPs und nur 1:3 oder gar 1:4, kommt man auf 2000 FP64-FMAs und respektive 1500 FP64-FMAs pro Takt. Das ist jämmerlich wenig. Auch im Hinblick was ich im B3D geschrieben habe, wäre man gegenüber einem Hawaii-Nachfolger in der DP-Performance völlig unterlegen.
AMD könnte mit 16FF+ auch wieder 1:2 bringen und die SP-Anzahl hochschrauben.
Selbstverständlich ist DP auch nur ein Teilbereich von vielen im HPC-Sektor.

Kommt drauf an ob GP100 überhaupt noch für Consumer kommt. Mit dem Auftauchen dieses ominösen GP102 wäre ich mir da nicht mehr sicher. Mag sein, dass Nvlink/DP einfach zuviel Platz wegnimmt und man diesmal die Chips wirklich trennt und dann könnte man auch 1:2 DP reinpacken

Das ist eben eine extra SKU. Die Frage ist eher, ob GP102 nur ein GP100 mit weniger HBM2-RAM ist oder tatächlich eine andere SKU. Falls letzteres sieht es eher nach einem Highend-Gaming-Chip aus, nicht Performance-Segment wie GP104.

€:
Im allerbesten Fall wird IMHO GP100 bei =/>3.5 TFLOPs DP liegen. An mehr glaube ich erst wenn ich es sehe.

Das wäre verdammt schwach.

Timbaloo

2015-11-11, 20:22:28

GP102 ist der Performance-Chip mit 8GB HBM2. Der GP104 ist dann der Performance-Chip mit 7+1GB :P

AffenJack

2015-11-11, 20:31:01

Im allerbesten Fall wird IMHO GP100 bei =/>3.5 TFLOPs DP liegen. An mehr glaube ich erst wenn ich es sehe.

Das klingt mir schon sehr pessimitisch und nicht der allerbeste Fall. Normalerweise sollten etwa 4 Tflops DP drin sein. Das würde auch zu den Nv Folien bei 1:3 DP am ehesten passen.

Ailuros

2015-11-11, 20:34:37

Das klingt mir schon sehr pessimitisch und nicht der allerbeste Fall. Normalerweise sollten etwa 4 Tflops DP drin sein. Das würde auch zu den Nv Folien bei 1:3 DP am ehesten passen.

Ich hab nicht mit den moeglichen ALU Anzahlen von Pascal gerechnet, sondern dass ich ernsthaft bezweifle dass sie mehr als 15 GFLOPs DP/W haben werden. Im Gegenfall haben die Intel KNL engineers die Konkurrenz wieder brutal unterschaetzt. 1:3 ist uebrigens nicht unbedingt = 4 TFLOPs. Bei hypothetischen 10.5 TFLOPs SP sind es immer noch "nur" 3.5 TFLOPs DP.

AffenJack

2015-11-11, 20:41:21

Ailuros

2015-11-11, 20:46:09

Ich hab auch nicht mit ALU-Zahlen gerechnet, sondern pur mit Gflops. Nvidia sagt Pascal ist 2x Perf/W Maxwell in Sgemm. Dementsprechend kann man auf jeden Fall 12 Gflops Leistung erwarten und da habe ich schon nen Puffer eingerechnet, wenn man bedenkt, dass die Tesla M40 bis auf 7 Gflops boostet. Bei 12 Tflops sindwa halt bei 4 Tf DP und das klingt für mich eher wie das Minimum, was man schaffen sollte.
Man muss sehen, dass AMD wohl eher in der Region 6 Gflops landen sollte mit deren 1:2DP. Da sind 4Gflops schon ziemlich wenig.

Selbst NV behauptet nicht MEHR 2x die SGEMM Leistung; schau Dir mal den neuesten slide ein klein bisschen vorsichtiger an und ja es wurde schon damals hier oefters besprochen.

http://wccftech.com/nvidia-pascal-gpu-manufactured-tsmc-16nm-ff-node-flagship-single-chip-card-feature-16-gb-hbm2-vram/

Das wäre verdammt schwach.

Intel hatte KNL vor geraumer Zeit mit 14-15 GFLOPs DP/W "vorangekuendigt". Mein Bauchgefuehl: Intel hat sich mal wieder leicht ueberschaetzt und NV liegt irgendwo in dem Bereich mit Pascal.

AffenJack

2015-11-11, 20:54:11

Das liegt nur daran, dass Nvidias Praktikant zu blöd war ordentliche folien zu machen.
Siehe bei PCGH hier:
http://www.pcgameshardware.de/Geforce-GTX-Titan-X-Grafikkarte-260203/Specials/Nvidia-Roadmap-Pascal-Volta-1153842/galerie/2347230/

Da steht explizit 2x Sgemm und 4x Mixed Precision. Die 4x FP16 sind auch noch bei deinem wccftech link vorhanden und das geht nur mit 2xSingle Precision. Das ganze mit weniger als 2x SP ist einfach nen dämliches Missverständnis wegen schlechter Folien.

Ailuros

2015-11-11, 20:59:22

Oder die Werte sind schon richtig eingetragen und marketing war mal wieder kreativ genug etwas aufzurunden. Der ganze 10x Mal Mist fuer Pacal ist ja sowieso Marketing-Duennschiss. Ich bleibe persoenlich konservativ bis wir mehr wissen.

AffenJack

2015-11-11, 21:06:11

Wir werden sehen. Das ist alles rätselraten im Moment. Die ganzen Werte auf den Folien kann man eigentlich nicht für voll nehmen, da sie immer mal wieder irgendwie geändert werden. Vielleicht erhoffe ich mir auch einfach dadurch, dass wir nen großen Prozessprung haben zu viel.

Ailuros

2015-11-11, 21:11:50

Bei 2.1x Mal so viel Transistoren im Vergleich zu GM200 und "a shitload" mehr DP habe ich schon meine Vorbehalte.

AffenJack

2015-11-11, 21:44:31

Joa, prinzipiell schon, aber es würde auch nicht alles verdoppelt zu GM200. Rops, Gpcs. Das könnte weniger skaliert werden. Bei Rops bin ich mir zb sicher, dass es 128 werden und das sind nur +33%. Aber gehen wir mal nochmal zur DP Rate zurück. Was für Konfigurationen würde Maxwell/Pascal überhaupt erlauben so architektonisch. 1:3 ist nämlich totaler Blödsinn und ja gar nicht möglich bei 128SP weils ne ungerade Zahl ergibt. Die 128 SP sind in 4x32 aufgeteilt und dementsprechend würde ich auch da wieder ne Gleiche Anzahl an SP erwarten wie man es auch gerade sieht. Im Moment würde ich mir da entweder 10 oder 12 DP Einheiten pro 32 SP vorstellen (11 gefällt mir nicht da ungerade). Also 40 oder 48SPs pro SMM und 1:3.2 oder 1:2,66 DP Rate.

Ailuros

2015-11-12, 07:55:27

Je weniger die Bloecke ausserhalb der eigentlichen ALUs skalieren (TMUs stecken ja schon in den ALUs und weniger als 2 quads/SMM waere ein Rueckschritt), desto weniger wird auch die eigentliche Leistung der GPU (ausserhalb vom number-crunching) skalieren.

Wenn sie tatsaechlich keine dedizierten FP64 SPs haben sollten, dann kann ich mir nichts anderes als 4:2:1 FP64/32/16 momentan vorstellen.

Hübie

2015-11-12, 08:39:59

Ailuros

2015-11-12, 08:43:25

Natuerlich mein ich dasselbe. Wenn es aber keine dedizierten FP64SPs sind und wir gehen von sagen wir mal 48 SMMs aus, sind wir bei 3.07 TFLOPs bei 1GHz Takt und 1/4 der FP32 Leistung. Oder GP100 ist am Ende doch eine weitere FP64 Pflaume und wir pinkeln schon seit Monaten an den falschen Baum.

Hübie

2015-11-12, 10:04:17

Hm. :uponder: Ich überlege auch gerade wie sehr FP64 eigentlich gefordert ist und so aus vergangenen Gesprächen ging nie hervor, dass es oft eingesetzt wird. Andererseits könnte es sich um ein Henne-Ei-Problem handeln.

Nakai

2015-11-12, 11:38:55

AMD hat auch ohne ded. FP64 ALUs 2:1 hinbekommen. Kostet halt ne Menge Pfade, mehr Register und somit geopferte Effizienz wenn man jetzt noch FP16 dazu haben will. Also ausgehend von FP32 wäre FP16 doppelt und FP64 halb so schnell. Hab ich n Denkfehler? :| Oder meinst du jetzt quantitativ das selbe? :biggrin:

btw: Netter Beitrag bei semiaccurate =)

AMD ist auch etwas anders als wohl NV. Bei Gcn wird ja die Latenz erhöht, laut Folien, ergo loopen wohl die SPs. Bei NV und MixedPrecision wird wohl tatsächlich der Durchsatz angepasst. Also Fp32 ist splitbar in 2 Fp16. Im Endeffekt sind es dann Fp32 units mit 2 Fp16 support. Bei Fp64 wär es ähnlich. Im Grunde sind es aufgeblähte Fp32/64 units.

Ich kann mir dann nichts anderes vorstellen, wie 4 : 2 : 1 für fp16 : fp32 : fp64, auch wegen der Pipeline Struktur. Aber es gibt immer Möglichkeiten. ^^
Ich kann mir schon 4:2:0.5 theoretisch vorstellen, aber dann sind die Sps wohl nochmal in Paare aufgebaut. Je nachdem was architekturell möglich ist, gibt es verschiedene Möglichkeiten.

€: fp64 wird erst gefordert, wenn die Präzision nicht mehr ausreicht. Es gibt auch andere numerische Möglichkeiten bevor man auf Fp64 umschwenken sollte. Lineare Summen vermeiden, Operanden bei Addition und Subtraktion sollten ähnlich groß sein, Roundoff Error schätzen und dann anpassen, Algorithmen umstellen, dass numerische Operationen wenig Fehler provozieren, also Daten sortieren und anordnen, etc
Wenn das nichts hilft, dann Fp64. Und da ist Gcn mit Hawaii sehr verzeihend...auch generell.

Ailuros

2015-11-12, 12:05:47

Ich kann mir selber mal ehrlich schwer vorstellen dass sie es mit dem Kepler Kaese bis zu Volta fuer FP64/HPC aushalten koennen, aber es waere schon ein witziger "Zufall" da ich auch bei Pascal nicht wirklich wuesste wieso die Eile fuer HBM *hust*. Von dem abgesehen mir macht - egal welcher IHV - stets ein neuer Speichercontroller hoellisch viel Angst. Fiji ist auch kein Parade-beispiel und bei NV hat es mehrere Male in der Vergangenheit auf Anhieb nicht geklappt. Hoffen wir mal dass es hier makellos gelaufen ist.

Godmode

2015-11-12, 12:17:50

Hübie

2015-11-12, 12:20:01

Mein Verständnis war bisher FP32/2=2*16 und FP64=2*32 (Loop, nicht parallel). Dafür bräuchte man ja eben die erwähnten Register (nicht nur weil zahlen größer sein können).

Ailuros

2015-11-12, 12:27:39

Ein NV30 wäre ja schon längst mal wieder überfällig. ;D Richtige Fehlschläge gabs ja schon länger nicht mehr bei NV, wenn man mal vom hohen Stromverbrauch von GF100 absieht.

Beim NV30 hatten sie die TSMC Richtlinien fuer den Prozess nicht respektiert und die ersten chips die damals zurueckkamen waren zu 100% mausetot. Sonst war das eigentliche Problem von GF100 der kaputte MC :P

Sunrise

2015-11-12, 12:43:31

Ein NV30 wäre ja schon längst mal wieder überfällig. ;D Richtige Fehlschläge gabs ja schon länger nicht mehr bei NV, wenn man mal vom hohen Stromverbrauch von GF100 absieht.
Die haben ihre Lektion gelernt, weshalb bei Pascal zuviele Änderungen nicht förderlich sind und man hier eher einen X1 auf High-End-Compute hochskaliert mit NVLink erwarten sollte als eine komplett auf HBM ausgelegt neue Architektur. Das konnte man perfekt im Voraus anhand X1 planen und NVLink und HBM müssen da ja auch noch irgendwo reinpassen. Änderungen über das komplette LineUp erwarte ich erst mit Volta, was man auch daran erkennen können wird, dass NV hier mit Pascal wohl stärker auf die Märkte aufteilen muss und auch mehrere GPUs benötigt um alles optimal zu bedienen. GP100 wird sich wohl von dem Rest stärker unterscheiden als bisher angenommen.

Eine GPU auf 16nm FF+ um die 500mm² mit 16GB HBM2 und sämtlichen Firlefanz kann man unter 1000$ MSRP erstmal komplett vergessen. Man schaue sich nur mal bei AMD die Preise an und die verkaufen sicher nicht mit der super Marge die NV hat, bei weit weit geringeren Mengen.

Erst werden die Großkunden ordentlich zur Kasse gebeten, darauf aufbauend baut man eine GPU mit maximaler SP-Performance und natürlich den kleineren Ablegern davon. Wieso eine Gaming-GPU überhaupt DP benötigt muss man mir erstmal erklären und das wird immer schlimmer, weil Gaming-Anforderungen und Compute sich einfach immer mehr außeinanderbewegen.

Godmode

2015-11-12, 13:08:07

Beim NV30 hatten sie die TSMC Richtlinien fuer den Prozess nicht respektiert und die ersten chips die damals zurueckkamen waren zu 100% mausetot. Sonst war das eigentliche Problem von GF100 der kaputte MC :P

Ah das mit den TSMC Richtlinien hatte ich schon wieder vergessen.

Die haben ihre Lektion gelernt, weshalb bei Pascal zuviele Änderungen nicht förderlich sind und man hier eher einen X1 auf High-End-Compute hochskaliert mit NVLink erwarten sollte als eine komplett auf HBM ausgelegt neue Architektur. Das konnte man perfekt im Voraus planen und NVLink und HBM müssen da ja auch noch irgendwo reinpassen. Tiefe Änderungen erwarte ich erst mit Volta, was man auch daran erkennen können wird, dass NV hier mit Pascal wohl stärker auf die Märkte aufteilen muss und auch mehrere GPUs benötigt um alles optimal zu bedienen.

Eine GPU auf 16nm FF+ um die 500mm² mit 16GB HBM2 und sämtlichen Firlefanz kann man unter 1000$ MSRP erstmal komplett vergessen. Man schaue sich nur mal bei AMD die Preise an und die verkaufen sicher nicht mit der super Marge die NV hat, bei weit weit geringeren Mengen.

Erst werden die Großkunden ordentlich zur Kasse gebeten, darauf aufbauend baut man eine GPU mit maximaler SP-Performance und natürlich den kleineren Ablegern davon. Wieso eine Gaming-GPU überhaupt DP benötigt muss man mir erstmal erklären und das wird immer schlimmer, weil Gaming-Anforderungen und Compute sich einfach immer mehr außeinanderbewegen.

Das es noch teurer wird, erwarten ja mittlerweile viele hier. Man kann echt hoffen, dass sie einen GM200 Nachfolger für Spieler bringen, weil wie du schon sagst, brauchen wir als Spieler hauptsächlich FP32 Power. Ein doppelter GM200 mit 16 GB VRAM wäre schon verdammt nett. Allerdings bezweifle ich eine reine Verdoppelung fast. Eher 50% mehr SPs und etwas höher Takt reicht ja auch für die typischen 60-70% Mehrleistung. Das Ding sollte dann deutlich kleiner als 500 mm2 ausfallen und man hätte sogar noch Platz für einen Refresh, sollte es mit dem Nachfolgeprozess wieder Probleme geben.

Eine der spannendsten Fragen ist für mich aber immer noch, ob so ein GP102 NVLink hat oder nicht. GP102 könnte also der geistige Nachfolger von GM200 sein (optimiert auf Gaming und FP32 Leistung). NVLink könnte trotzdem an Board sein, aber eventuell nicht mit 4 sondern nur mit 2 Links. Damit könnte man echt schöne Dual-GPU Karten bauen. 16 GB HBM2 VRAM wäre natürlich auch an Board.

GP100 wäre dann der richtige Nachfolger von GK210 und würde diesen in allen Punkten massiv übertrumpfen. Sie könnten bei GP100 dann sogar die TMUs weglassen, bzw. deutlich weniger davon verbauen, ebenso die ROPs. Das Ding würde also fast nur mehr aus SMs und Caches bestehen. HBM2 würde dann ~1TB/s Bandbreite liefern, damit das Ding auch ausgelastet werden kann. Im HPC Sektor kann so ein Ding wohl problemlos um mehre tausend Euro verkauft werden, wodurch dann auch die Marge wieder passt.

GP104 ist dann ein kleinerer GP102, ohne NVLink, aber mit HBM2.

Hmm, irgendwie kommt mir das recht vernünftig vor, so als Laie.

Ailuros

2015-11-12, 13:28:50

Einheiten ganz entfernen oder reduzieren kostet zu viel Zeit und Aufwand.

igg

2015-11-12, 13:53:40

Wann kommen eigentlich GTX1080 und GTX1070 wahrscheinlich? Q2 und Sommer wird oft genannt, das kann ja von März, Juli oder September sein...

BlacKi

2015-11-12, 15:00:22

Wann kommen eigentlich GTX1080 und GTX1070 wahrscheinlich? Q2 und Sommer wird oft genannt, das kann ja von März, Juli oder September sein...
du sagst es, dabei ist nichtmal q2 sicher.

sicherlich kommen die zwischen januar 2016 und märz 2017. wahrscheindlich aber irgendwann im sommer^^

Godmode

2015-11-12, 15:21:41

Einheiten ganz entfernen oder reduzieren kostet zu viel Zeit und Aufwand.

Ok, ich habe dazu zu wenig wissen, aber wenn du es sagst, glaube ich es dir.

Wann kommen eigentlich GTX1080 und GTX1070 wahrscheinlich? Q2 und Sommer wird oft genannt, das kann ja von März, Juli oder September sein...

GP104 IMHO irgendwann nächstes Jahr zwischen Anfang Sommer bzw. Herbst. Das richtet sich wohl nach den Yields, bzw. wie schnell die Kosten für 16FF+ sinken.

GP102 als GM200 Nachfolger dann 2017. Das sagte ich schon vor langer Zeit, nur dass ich immer vom GP100 für Endkunden ausging. Mit diesem Releasezyklus verdient NV das meiste Geld, daher wird das ziemlich sicher so kommen.

igg

2015-11-12, 15:33:32

GP104 IMHO irgendwann nächstes Jahr zwischen Anfang Sommer bzw. Herbst. [...9

GP102 als GM200 Nachfolger dann 2017. Das sagte ich schon vor langer Zeit, nur dass ich immer vom GP100 für Endkunden ausging.
Danke für die Info! Ich bin mir nicht sicher ob sie dadurch, insb. dem späten GP104 Launch, nicht zuviele Marktanteile verlieren. Die 390 ist mit Blick auf VRam und Preis deutlich attraktiver als 970/980 (ganz zu schweigen von dem 3.5 GB Debakel), selbst ich als AMD-Treiberleid-geplagter überlege schon mir deshalb eine 390 zu holen...

Godmode

2015-11-12, 15:36:39

Danke für die Info! Ich bin mir nicht sicher ob sie dadurch, insb. dem späten GP104 Launch, nicht zuviele Marktanteile verlieren. Die 390 ist mit Blick auf VRam und Preis deutlich attraktiver als 970/980 (ganz zu schweigen von dem 3.5 GB Debakel), selbst ich als AMD-Treiberleid-geplagter überlege schon mir deshalb eine 390 zu holen...

Es ist nur meine Einschätzung, Infos hat leider momentan wohl niemand.

980/970 verkaufen sich ja wie geschnitten Brot. Solange AMD nicht mit was neuem ankommt, hat NV überhaupt keinen Stress.

Rampage 2

2015-11-12, 15:39:32

GP104 IMHO irgendwann nächstes Jahr zwischen Anfang Sommer bzw. Herbst. Das richtet sich wohl nach den Yields, bzw. wie schnell die Kosten für 16FF+ sinken.

Q2 2016 ist für GP104 nicht mehr wahrscheinlich?:eek:

R2

Godmode

2015-11-12, 16:42:08

Q2 2016 ist für GP104 nicht mehr wahrscheinlich?:eek:

R2

Wir wissen nicht einmal ob dieser überhaupt schon sein Tapeout hatte, IIRC.

Mandalore

2015-11-12, 19:02:01

Ok, ich habe dazu zu wenig wissen, aber wenn du es sagst, glaube ich es dir.

GP104 IMHO irgendwann nächstes Jahr zwischen Anfang Sommer bzw. Herbst. Das richtet sich wohl nach den Yields, bzw. wie schnell die Kosten für 16FF+ sinken.

GP102 als GM200 Nachfolger dann 2017. Das sagte ich schon vor langer Zeit, nur dass ich immer vom GP100 für Endkunden ausging. Mit diesem Releasezyklus verdient NV das meiste Geld, daher wird das ziemlich sicher so kommen.

Das ist wohl Über-Pessimistisch:freak::cool:. AMD wird garantiert vor Sommer was veröffentlichen und Nvidia ebenso. 2017 für einen GP102 als GM200-Nachfolger ist viel zu spät, da ist ja Volta schon da...

Nakai

2015-11-12, 21:11:35

Wie sieht es mir einfachen Shrinks aus?

Godmode

2015-11-12, 21:55:03

Das ist wohl Über-Pessimistisch:freak::cool:. AMD wird garantiert vor Sommer was veröffentlichen und Nvidia ebenso. 2017 für einen GP102 als GM200-Nachfolger ist viel zu spät, da ist ja Volta schon da...

Volta am Desktop 2017!? Sicher nicht!

Und ich sagte ja Anfang Sommer bis Herbst (Back2School)

Skysnake

2015-11-12, 23:20:09

...
€: fp64 wird erst gefordert, wenn die Präzision nicht mehr ausreicht. Es gibt auch andere numerische Möglichkeiten bevor man auf Fp64 umschwenken sollte. Lineare Summen vermeiden, Operanden bei Addition und Subtraktion sollten ähnlich groß sein, Roundoff Error schätzen und dann anpassen, Algorithmen umstellen, dass numerische Operationen wenig Fehler provozieren, also Daten sortieren und anordnen, etc
Wenn das nichts hilft, dann Fp64. Und da ist Gcn mit Hawaii sehr verzeihend...auch generell.
Und woher nimmst du die Entwickler, die die numerische Stabilität untersuchen und eben ausschliesen, dass das in jedem Fall keine Probleme macht SP zu benutzen? Ganz zu schweigen davon, dass du ja auch noch massig Mannarbeitsjahre im Code versenkst, um überhaupt diesen entsprechend an zu passen.

Entsprechende Entwickler wachsen nicht auf Bäumen. Nicht umsonst hat die EU jetzt sogar ein Projekt aufgelegt, dass den HPC-Usern/Entwicklern helfen soll ihre Codes zu verbessern...

Hübie

2015-11-13, 00:16:56

Aber auch abseits der Fertigung war NV30 hinsichtlich der µ-Arch sagen wir mal suboptimal. Nur in INT12 war er halbwegs stark. FP16 ging so, FP32 meh. Dazu noch das CineFX "Feature", dass TMUs und ALUs sich gegenseitig blockiert haben.

Dazu wenig ST Fillrate, Bandbreite, weniger ROPs, Registerknappheit etc. Der hohe Takt glich sicher etwas aus - aber stark auf Kosten der Leistungsaufnahme. Man hat Transistoren ohne Ende verballert - für Dinge, die zur Lebzeiten der GPU wenig/nichts gebracht haben.

Das Ding war auf ganzer Linie eine Blamage. Wären Spiele damals arithmetikintensiver gewesen, wäre es auch für NV40 und G7x blamabel geworden. Streng genommen kam man erst mit G80 und dessen neuer µ-Arch aus dem Schlamasseln heraus.

NV30. Da klingelte bei mir doch sofort etwas. :freak: Das waren noch die Zeiten wo ich mich fragte wie man so einen Schund für teuer Geld kaufen kann. :P Sommer 2002 brachte ATi einen Überflieger der erst im Frühjahr einigermaßen gekontert wurde. Was haben meine Kumpels und ich gelacht, als der Föhn vorgestellt wurde :biggrin: Ein Evergreen (oh man was für ein Wortspiel, wenn man bedenkt dass AMD auch einen Evergreen hatte und nVidia grün ist)! ;D;D:freak:

Wie sieht es mit einfachen Shrinks aus?

Shrink wovon jetzt?´:confused: (fify)

Timbaloo

2015-11-13, 00:21:33

Und woher nimmst du die Entwickler, die die numerische Stabilität untersuchen und eben ausschliesen, dass das in jedem Fall keine Probleme macht SP zu benutzen?
Wie wird denn ohne diese Entwickler der Code hinsichtlich numerischem Verhalten verifiziert? Ist ja nicht so, dass FP64 == "alles automatisch gut". Sprich wenn die Leute zu blöd sind den Einfluss des Wechsels von FP64->FP32 beurteilen zu können, dann sind sie faktisch gesehen auch zu blöd ihren FP64-Code zu beurteilen. Nur ist da die Wahrscheinlichkeit eines Problems geringer. Das ist aber ein sehr zweischneidiges Schwert, denn jeder Entwickler mit ein bißchen Hirn wird "crash early" bevorzugen. Und wenn tatsächlich "Mannjahre" benötigt werden um den Code von FP64->FP32 anzupassen (ohne Maßnahmen um das numerische Verhalten bei FP32 zu verbessern), dann solltest du die "Coder" (weil mehr sind sie dann nicht) sofort entlassen.

Letztlich ist es eine recht einfache Kosten/Nutzen-Rechnung. Läuft dein Code unter FP32 ungefähr halt so lang, verursacht er ungefähr die halben Kosten im Betrieb, rechtfertigt ab einer gewissen Zeit die Optimierung des Codes auf FP32. Wenn möglich.

Skysnake

2015-11-13, 06:55:33

Wer entwickelt denn Code? Da gibt es doch drei Gruppen:

1. Wissenschaftler die neue Probleme lösen wollen in kleinen Teams, wo kein ausgewiesener IT-Experte dabei ist.
2. Große Wissenschaftsteams/Projekte bei denen es dediziert Leute gibt, die sich nur um so etwas kümmern
3. Wirtschaft

Bei 1 ist es nicht unüblich, dass die Rechenzeit nicht direkt bezahlen und bei 3. kommt es darauf an, was die Konkurrenz so macht. So lange die nicht schneller ist, reicht es einfach FP64 rein zu knallen. Wems zu langsam ist, der soll halt mehr Hardware kaufen in der Regel. Hardware kostet ja nicht wirklich etwas.

Der Punkt ist doch einfach, das FP64 schlicht ein NoBrainer ist. Natürlich verschenkt man damit viel, aber man kann sich 100% sicher sein, das man damit nichts kaputt macht. Bevor man damit wirklich richtig Schaden anrichtet, eben weil man unnötig lange rechnet, muss ne Aplikation durchoptimiert sein.

Lass die Leute mit ihrer Zeit mal vorher lieber I/O, MPI, Vectorisierung, Loopunrolling usw RICHTIG implementieren. Was bringt es dir, wenn du nen geilen Pseudocode hast, bei dem du mit FP32 auskommst, die Leute dann das aber wie Horst in echtem Code implementieren, so das du ständig die Pipeline leer läuft, Cachelines nur teilweise genutzt werden oder gar Cache trashing betrieben wird...

Wie gesagt, schau dir mal das Projekt an. Das wird es schon nicht ohne Grund geben ;)

Godmode

2015-11-13, 08:08:30

Shrink wovon jetzt?´:confused: (fify)

Zb. Maxwell Shrinks.

Ailuros

2015-11-13, 08:55:59

Zb. Maxwell Shrinks.

Ich bezweifle dass es so etwas im strengen Sinn ueberhaupt noch gibt. Es gab Meldungen in der Vergangenheit dass es angeblich Maxwell shrinks schon Anfang 2015 geben wird; da man schon in 2014 fuehlen konnte wie hoch die Preise fuer 16FF+ sein werden und das Apple von Anfang an des Jahres darunter mit voller Pulle fuer die iPhones herstellen wird. IMHO haben sie die Zwischenzeit ausgenutzt und irgendwelchen Schnickschnack noch dazugesteckt. Anders an direkte shrinks hab ich in letzter Zeit nie geglaubt.

Godmode

2015-11-13, 09:09:04

Ailuros

2015-11-13, 09:24:17

AffenJack

2015-11-13, 09:55:02

Ich glaube auch nicht an Shrinks, habe nur seine Frage beantwortet. Was will man den mit einem GM200 in 16FF+ wirklich? Der Chip wird zwar kleiner, hätte aber trotzdem noch das Problem, dass man mindestens ein 384 Bit SI braucht. Unter dem Strich wäre man wohl nicht wirklich schneller als GM200 und der Stromverbrauch soll sich ja bei einem reinen Shrink auch nicht merklich verbessern, wenn an der grundlegenden Struktur nichts geändert wird.

Frag mal deine Quelle nach GP102, ob ich hier richtig liege.

GM200 geht schlecht, wie du schon sagst, aber zumindest GM206 eignet sich relativ gut dafür dank 128bit. Kann mir vorstellen, dass wir mit GP107 nen sehr ähnlichen Chip sehen werden, nur halt mit Pascal Schnickschnack. Der wäre auch wichtig fürs Notebooksegment und so könnte ich mir vorstellen, dass dies wieder der erste Chip wird, der bei Consumer auftrifft.

Godmode

2015-11-13, 10:23:53

Ich hab den Sport schon seit langem aufgegeben. Das mit den shrinks kam von einem semi-oeffentlichen forum. Erinyes ist der einzige Sterbliche den ich kenne der wahren Zugang direkt zu NV engineering hat, aber der sagt sowieso alles was er weiss oeffentlich bei B3D aus und er hat seit dem letzten Juni dort nicht gepostet. Auf jeden Fall muessten sie IMO bis zu Q3 mit allen 16FF+ tapeouts fertig sein; der erste wenn ich mich richtig erinnere war Parker irgendwo im Mai. Dabei hat Erinyes nie etwas ausserhald dem GP100 tapeout berichtet weil er einfach nicht ueber die kleineren nachgefragt hat. Wenn er mal wieder bei B3D auftaucht schick ich ihm eine PM.

Na gut, dann müssen wir eben warten, bis uns irgend jemand einen Fetzen zuwirft, so unspannend das auch ist.

GM200 geht schlecht, wie du schon sagst, aber zumindest GM206 eignet sich relativ gut dafür dank 128bit. Kann mir vorstellen, dass wir mit GP107 nen sehr ähnlichen Chip sehen werden, nur halt mit Pascal Schnickschnack. Der wäre auch wichtig fürs Notebooksegment und so könnte ich mir vorstellen, dass dies wieder der erste Chip wird, der bei Consumer auftrifft.

Gerade bei Notebooks würde eine reiner Shrink IMHO nicht wirklich helfen. Dort will man minimalen Stromverbrauch bei maximaler Leistung.

AffenJack

2015-11-13, 10:42:10

Einen reinen Shrink wirds auch gar nicht geben, wie Ailuros schon schrieb. Ich meine eben einen Pascal der von den Einheitenzahlen ähnlich wie GM206 ist.

Nakai

2015-11-13, 12:08:39

Lass die Leute mit ihrer Zeit mal vorher lieber I/O, MPI, Vectorisierung, Loopunrolling usw RICHTIG implementieren. Was bringt es dir, wenn du nen geilen Pseudocode hast, bei dem du mit FP32 auskommst, die Leute dann das aber wie Horst in echtem Code implementieren, so das du ständig die Pipeline leer läuft, Cachelines nur teilweise genutzt werden oder gar Cache trashing betrieben wird...

Wie gesagt, schau dir mal das Projekt an. Das wird es schon nicht ohne Grund geben ;)

Bitte übertreib nicht. Etwas auf die Numerik einzugehen, ist doch ein Grundbestandteil eines jeden Studiums. Und klar, dort wird Numerik auch nicht sonderlich tief behandelt, es kann ja als ein eigener wissenschaftlicher Teilbereich gesehen werden. Worauf ich hinaus will ist, dass man immer auf die Numerik schielen sollte. Man sollte mit der numerischen Ausführung vertraut sein, wie IEEE-754 funktioniert, wie gerundet wird, dass Float-Operationen niemals assoziativ sind (+, *), etc...damit wären schon vielen Leuten geholfen.
Was ich schon in Projekten von Forschungsbereichen von absoluten Eliteuniversitäten für Fehler gesehen habe. :freak:
Da werden Floats miteinander verglichen (:freak:), Float-Summen linear summier (:freak::freak:), keine konkreten Compiler-Flags für Math und Optimierung gesetzt (man sollte schon wissen, was die -Oxflags tun), auch für unterschiedliche Architekturen (:freak::freak::freak:), die FPU wird nicht richtig eingestellt (Control-Register).

Es würde oft schon helfen, wenn die Entwickler etwas besser aufpassen würden und bestimmte Operationen einfach nicht anwenden. Die OpenCL-Specs erlauben zB Rundungsfehler für Operationen (Fehler in ULPs). Bei vielen Math-Libs werden bei den Methoden die maximalen Fehler öfter angegeben (auch in ULPs). Es gibt dann auch immer den Punkt zwischen Performance und Genauigkeit.

...

Etwas anderes...wenn NV bisher bei Pascal keine nennenswerten DP-Marketingzahlen veröffentlich hat und diese Thematik nicht anschneidet, wird Pascal keine nennenswerten DP-Funktionalitäten haben. Bei NV kann man immer von der Marketingseite auf die technische Seite schließen. ;D

Godmode

2015-11-13, 12:09:08

NV30 Diskussion gesplittet: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=568417

Nakai

2015-11-13, 12:29:02

Die Shrink-Idee kommt mir eher auf den Hinblick von GM107, GM204 und GM206. Diese Chips sind relativ groß und haben nur sehr kleine Speicher Interfaces.
GM204 - ~400mm² - 256Bit
GM206 - ~230mm² - 128Bit
GM107 - ~150mm² - 128Bit

Da könnte ich mir einen Shrink gut vorstellen, welcher das SI beibehält.

Hübie

2015-11-13, 15:02:45

Hier (http://newsroom.altera.com/press-releases/nr-dram-sip.htm) mal ein Häppchen in Hinblick auf HBM2. Wenn es nach StefanV geht hat AMD natürlich die ganze Arbeit geleistet :rolleyes: SCNR. Jetzt kann man sich ja ein buntes Bild malen wie wahrscheinlich es ist dass (Big) Pascal kein HBM2 nutzen wird.

Unicous

2015-11-13, 15:56:17

Was willst du uns damit sagen?:confused:

Die Dinger kommen erst 2017.

Altera will start shipping Stratix 10 FPGAs and SoCs in 2016 and Stratix 10 DRAM SiP products will start shipping in 2017.

Auch wenn StefanVs Kommentare hanebüchen sind, sehe ich jetzt hier keinen unmittelbaren Zusammenhang zu Pascal.

horn 12

2015-11-13, 17:28:41

Zudem erwarten sich wohl alle zuviel von den Neuen, in nicht allzuschneller Zukunkt kommenden NV bzw. AMD Karten der nächsten Generation! Dies sei wohl mal gesagt.
Jene kochen auch nur mit Wasser und werden es nicht allzuhastig angehen im Neuen, NICHT ÜBERSCHAUBAREM Fertigungsverfahren.

Ailuros

2015-11-13, 17:35:51

Du erwartest traditionell NUR viel von AMD chips; von NV chips eher zu 180 Grad das Gegenteil. Weder zu viel Optimismus, noch zu viel Pessimismus ist gesund.

horn 12

2015-11-13, 17:43:43

Dies kann gut möglich sein :-)

Godmode

2015-11-18, 14:50:46

Nicht wirklich was neues:
http://vrworld.com/2015/11/16/nvidia-unveils-pascal-gpu-16gb-of-memory-1tbs-bandwidth/

H1/2016 steht da drinnen, aber nicht welcher Pascal genau und für welche Märkte. Außerdem schreiben sie, dass wir am Anfang wohl maximal 16GB HBM2 sehen werden und erst später 32GB Versionen.

Und NOAA bekommt auch einen neuen kleinen (kleiner als Summit/Sierra) Super Computer mit 760 Pascal GPUs:
http://www.theregister.co.uk/2015/11/16/nvidia_noaa/

mczak

2015-11-18, 17:25:12

H1/2016 steht da drinnen, aber nicht welcher Pascal genau und für welche Märkte. Außerdem schreiben sie, dass wir am Anfang wohl maximal 16GB HBM2 sehen werden und erst später 32GB Versionen.

Ich habe ja schon immer vermutet dass am Anfang wohl eher keine 8Hi HBM2 Stacks zu erwarten sind, das wäre dann die Bestätigung... Immerhin sieht es so aus als würde man die doppelte Bandbreite gegenüber HBM1 gleich erreichen, da war ich auch skeptisch...

Godmode

2015-11-18, 18:36:13

1 TB/s hören sich gut an, wobei laut Diagramm unten eher 700-800 GB/s realistisch sind. Wenn man von den 48 GFlop/w FP32 ausgeht (steht auf der SGEMM/W Roadmap), muss das Ding um die 12 TFlop/s in FP32 schaffen. Wenn man jetzt die verschiedenen möglichen Splits FP64/FP32 angeguckt, bleibt als wahrscheinlichste Variante nur mehr der 1:3 Split wie schon bei GK110 bzw. GK280 über, weil 1:2 wäre extrem viel FP64 Leistung und 1:4 zu wenig, IMHO.

1:4 = 3,1 TFlop/s FP64
1:3 = 4,1 TFlop/s FP64
1:2 = 6,1 TFlop/s FP64

Das ganze könnte man gut in 8 GPCs organisieren, was auch wieder zu den 4 HBM Interfaces passen würde. Ob es jetzt 5120 - 6144 SPs werden ist dann egal. Weniger ALUs/mehr Takt und umgekehrt. Das ganze könnten man wohl in etwas über 500mm2 bei einer Packdichte von 32 Mio/mm2 packen.

Die Idee von den 4,1 TFLop/s FP64 kommt übrigens aus dieser Roadmap:
http://abload.de/img/screenshot2015-11-18a0wq72.png

http://www.ecmwf.int/sites/default/files/HPC-WS-Posey_0.pdf

Edit: wenn man sich die Beschriftungen genau anguckt, liegt Pascal wohl eher irgendwo in der Mitte von 3 und 4. Die Beschriftungen dürften stimmen, weil sonst hätte man M1060, M2050 nicht mittens in die Linie rein gezeichnet. Mit Quadrate stellen dann das Jahr dar.

Hübie

2015-11-18, 19:05:02

=Floi=

2015-11-18, 19:06:48

was kommt denn da für eine krasse x86 cpu?

w0mbat

2015-11-18, 19:18:11

Zen :ugly:

Locuza

2015-11-18, 19:26:11

Skylake-E mit 512-Bit AVX.
Davor Haswell mit FMA3, als 2014 Pump-Up.

Agent117

2015-11-18, 19:33:31

Ich weiß nicht ob es schon bei Pascal einsetzen wird, aber bei Volta mit Sicherheit: die GPCs werden in ihrer Gänze etwas eingedampft und breit unter einander angeschlossen. Bei GK110 hat man das nicht und kommt eigentlich nur wegen der 15 SMX á 64 FP64-ALUs auf ein 1:3 Verhältnis (256 ALUs wovon 192 FP32 sind). Das wird also eher bei 1:4 landen. 1:2 klingt nach to good to be true...

Du meinst also (noch) kleinere GPCs bei Nvidia? Warum sollte das notwendig sein für eine hohe DP Rate oder worin liegt der Unterschied zu SP? Man kann so ein GPC anscheinend nahezu beliebig groß machen, muss es dann nur auch "mächtiger" anbinden. Gehst du von dezidierten Einheiten aus?

http://www.ecmwf.int/sites/default/files/HPC-WS-Posey_0.pdf

Edit: wenn man sich die Beschriftungen genau anguckt, liegt Pascal wohl eher irgendwo in der Mitte von 3 und 4. Die Beschriftungen dürften stimmen, weil sonst hätte man M1060, M2050 nicht mittens in die Linie rein gezeichnet. Mit Quadrate stellen dann das Jahr dar.

Interessant ist ja auch dass AMDs Greenland laut dem folgenden Link auch 4Tf DP haben soll. (Die wissen da zwar nicht ob DP oder SP, woanders stand aber mal explizit DP)

http://wccftech.com/amd-opteron-mcm-zeppelin-cpu-greenland-hbm-data-fabric/

Waren die HPC Chips bisher immer der Top Dog einer Serie, könnte sich dies nun mit der nächsten Generation ändern und man konzentriert sich eher darauf mehrere zu verbinden über NV-Link oder AMDs Interconnect Sache.
Für Supercomputer geht es sowieso nicht anders und schaden wird dies nur dem, der sich eine einzige Profikarte kauft und dann statt der Leistung eines 600mm² Monsters nur die einer 400mm² GPU bekommt.

Ich lehne mich mal extrem weit aus dem Fenster und behaupte dass Nvidia zuerst einen ca. 400-450mm² großen GP100 sowohl für den Profimarkt als auch für Destop leistungsmäßig mit GM200 + 30 bis 40% bringt. GP104 wird leistungsmäßig leicht unter GM200 liegen.
Später kommt dann für High End Gaming der GP102. Würde auch zu ihrer bisherigen Preis- und Releasestrategie passen. GP100 kann man bei Spielern locker 800 verlangen wenn er 30% über GM200 liegt. Im Laufe der Zeit und wenn GP102 dann raus ist, fällt dieser in Richtung 500 bis 600 und der GP102 Top Dog wird zu Titan Preisen verkauft.

Hugo

2015-11-18, 19:48:56

gab es nicht mal eine Diskusion, dass die FP64 ALUs auch für FP32 zur Verfügung stehen?
Ich stell mir das so vor: ein Cluster hat zB 256 ALUs wovon 128 FP64 können.
Da hätte man ein 2:1 Verhältnis
wäre sowas möglich?

Hübie

2015-11-18, 20:00:18

Also welcher jetzt wer ist, kann man ja noch nicht sagen, aber ich schätze GP102 ist GeForce mit etwa 524 mm² und ohne NVLink (irgendwann wird auch der letzte Träumer einsehen dass diese Technologie nicht mit Pascal auf dem Desktop-Markt kommen wird). GP100 dann full-featured Chip mit NVLink. Dedizierte FP64 ALUs? Haben den Vorteil schnell, also mit sehr geringer Latenz Code auszuführen, aber den Nachteil Energie zu verbraten, Platz einzunehmen und im Desktop (fast) gar nicht genutzt zu werden. Und afaik wird Volta der HPC-Bomber.
Bei 32 SMM und jeweils 64 ded FP64 ALUs könnte man es sich zwar vom Platz her erlauben, aber wer sagt denn dass mein Tipp mit 524 mm² stimmt? :freak: :confused:

Edit: @Agent117: Bitte nicht SMM und GPC verwechseln ;)

Godmode

2015-11-18, 21:14:55

Ich weiß nicht ob es schon bei Pascal einsetzen wird, aber bei Volta mit Sicherheit: die GPCs werden in ihrer Gänze etwas eingedampft und breit unter einander angeschlossen. Bei GK110 hat man das nicht und kommt eigentlich nur wegen der 15 SMX á 64 FP64-ALUs auf ein 1:3 Verhältnis (256 ALUs wovon 192 FP32 sind). Das wird also eher bei 1:4 landen. 1:2 klingt nach to good to be true...

Edit: Und 17,8 Mrd geteilt durch deine 32 Mio sind etwa 550 sqmm. :tongue:

Wenn du 1:4 annimmst, kommst du aber auf eine deutlich niedrigere FP64 Rate, also unter 3 TFlop/s. Wenn der Chart die Wahrheit sagt, kann das also nicht sein. Wenn man 1:2 annimmt, stimmt die FP32 Rate von 48 GFLop/W Watt wieder nicht. Bzw. man hätte deutlich mehr FP64 Leistung, fast schon soviel, was erst mit Volta kommt, es kann also auch nicht 1:2 sein. Bleibt nur 1:3 über.

@Packdichte: Ja ich habe nur mit 17,0 Mrd. gerechnet, mein Fehler.

Ich lehne mich mal extrem weit aus dem Fenster und behaupte dass Nvidia zuerst einen ca. 400-450mm² großen GP100 sowohl für den Profimarkt als auch für Destop leistungsmäßig mit GM200 + 30 bis 40% bringt. GP104 wird leistungsmäßig leicht unter GM200 liegen.
Später kommt dann für High End Gaming der GP102. Würde auch zu ihrer bisherigen Preis- und Releasestrategie passen. GP100 kann man bei Spielern locker 800 verlangen wenn er 30% über GM200 liegt. Im Laufe der Zeit und wenn GP102 dann raus ist, fällt dieser in Richtung 500 bis 600 und der GP102 Top Dog wird zu Titan Preisen verkauft.

Wie soll GP100 bitte so langsam sein, kannst du mir das erklären? Wir sprechen hier von 11-12 TFlop/s FP32 Leistung!

gab es nicht mal eine Diskusion, dass die FP64 ALUs auch für FP32 zur Verfügung stehen?
Ich stell mir das so vor: ein Cluster hat zB 256 ALUs wovon 128 FP64 können.
Da hätte man ein 2:1 Verhältnis
wäre sowas möglich?

Das passt eben nicht, siehe meine Antwort auf Hübies Post.

AffenJack

2015-11-18, 21:19:59

Wenn du 1:4 annimmst, kommst du aber auf eine deutlich niedrigere FP64 Rate, also unter 3 TFlop/s. Wenn der Chart die Wahrheit sagt, kann das also nicht sein. Wenn man 1:2 annimmt, stimmt die FP32 Rate von 48 GFLop/W Watt wieder nicht. Bzw. man hätte deutlich mehr FP64 Leistung, fast schon soviel, was erst mit Volta kommt, es kann also auch nicht 1:2 sein. Bleibt nur 1:3 über.

Da ich gerne korinthenkacke, 1:3 ist nicht möglich. Nur 1:2,66, 1: 2,91 oder 1:3,2, wobei 1:2,91 eher unwahrscheinlich klingt. :smile:

Agent117

2015-11-18, 21:43:03

Wie soll GP100 bitte so langsam sein, kannst du mir das erklären? Wir sprechen hier von 11-12 TFlop/s FP32 Leistung!

Wurden die denn für GP100 mal bestätigt oder anhand anderer Infos als höchstwahrscheinlich genannt? Was gegen meine Theorie von einem kleineren Chip spricht sind natürlich die 17Mird. Transistoren aber die müssen sich ja nicht zwingend auf GP100 beziehen.

12 TFlop SP Leistung und dann wie auf der Folie 4 TFlop DP oder ähnliche Werte gingen nur mit dezidierten Einheiten. Das glaube ich eher weniger. Man spricht hier doch von Mixed Precision und Amd hat mit Hawaii doch eindrucksvoll gezeigt dass es möglich ist ohne groß DIE-Size zu opfern FP64 einzubauen mit doppelter Latenz.

Was wären denn deiner Meinung nach die Nachteile eines langsamen 400mm² GP100?

@Hübie. Ich meinte schon die GPC das Nvidias Pendant zu AMDs "Shader Engine"

Godmode

2015-11-18, 21:44:44

Da ich gerne korinthenkacke, 1:3 ist nicht möglich. Nur 1:2,66, 1: 2,91 oder 1:3,2, wobei 1:2,91 eher unwahrscheinlich klingt. :smile:

192 FP32 ALUs und 64 FP64 ALUs pro Shader Multiprozessor. Davon jeweils 4 Stück in einen GPC rein und 8 GPCs im gesamten. Macht 192*4*8 = 6.144 FP32 ALUs, was bei 950 MHz 11,674 TFLop/s FP32 ergibt.

Godmode

2015-11-18, 21:52:29

Wurden die denn für GP100 mal bestätigt oder anhand anderer Infos als höchstwahrscheinlich genannt? Was gegen meine Theorie von einem kleineren Chip spricht sind natürlich die 17Mird. Transistoren aber die müssen sich ja nicht zwingend auf GP100 beziehen.

12 TFlop SP Leistung und dann wie auf der Folie 4 TFlop DP oder ähnliche Werte gingen nur mit dezidierten Einheiten. Das glaube ich eher weniger. Man spricht hier doch von Mixed Precision und Amd hat mit Hawaii doch eindrucksvoll gezeigt dass es möglich ist ohne groß DIE-Size zu opfern FP64 einzubauen mit doppelter Latenz.

Was wären denn deiner Meinung nach die Nachteile eines langsamen 400mm² GP100?

@Hübie. Ich meinte schon die GPC das Nvidias Pendant zu AMDs "Shader Engine"

Diese Leistungsdaten ergeben sich aus den momentan verfügbaren Folien von NV. Wenn das nicht kompletter Blödsinn ist was da draufsteht, ist das IMHO ein sehr gut Anhaltspunkt. Es könnte natürlich sein, dass die eine SGEMM Folio mit 48 GFlop/W einen reinen FP32 Chip beschreibt und die andere Folie sich auf einen FP64 lastigen Chip bezieht. Hört sich für mich aber eher unwahrscheinlich an.

Ja genau, ich gehe von dezidierten Einheiten aus, sonst macht meine Interpretation keine Sinn. GP102 als Gamerchip könnte dann kleiner ausfallen, hätte aber mehr FP32 Power als GP100, weil dieser mit höherem Takt laufen könnte.

Warum sollten sie den Chip so klein machen? Wenn sie von 17,8 Mrd. Transistoren sprechen, kann das Ding nur Groß werden. mit 400mm2 wäre das nicht IMHO nicht Leistungsfähig genug und sie könnten das was auf den Roadmaps steht nicht erreichen.

AffenJack

2015-11-18, 21:59:26

192 FP32 ALUs und 64 FP64 ALUs pro Shader Multiprozessor. Davon jeweils 4 Stück in einen GPC rein und 8 GPCs im gesamten. Macht 192*4*8 = 6.144 FP32 ALUs, was bei 950 MHz 11,674 TFLop/s FP32 ergibt.

Seit wann ist Pascal denn ein Kepler Abkömmling geworden? Es sind 128 FP32 pro SMM, geteilt in 4x32SP und da Pascal wohl eher kleinere Veränderungen hat wirds auch dabei bleiben. Pro SMM dann halt 40 oder 48 FP64 ALUs würde gehen, wenns nicht 1:2 oder 1:4 wird.

Godmode

2015-11-18, 22:08:54

Seit wann ist Pascal denn ein Kepler Abkömmling geworden? Es sind 128 FP32 pro SMM, geteilt in 4x32SP und da Pascal wohl eher kleinere Veränderungen hat wirds auch dabei bleiben. Pro SMM dann halt 40 oder 48 FP64 ALUs wäre meine Erwartung.

Ja, es ist der geistige Nachfolger von GK280. GM200 hat ja keine nennenswerte FP64 Leistung und war nur ein Lückenfüller, wegen der Prozessproblematik.

Ich wollte schon fast SMP schreiben (Shader Multiprocessor Pascal), damit diese Frage nicht aufkommt. 192 habe ich gewählt, damit man genau 4 SMP pro GPC hat und 1:3 bei FP64:FP32 erreicht. Mit 128 müsste man 6 SMPs pro GPC verbauen. Ich glaube dass die Variante mit 192 SPs billiger ist.

Agent117

2015-11-18, 22:34:56

Diese Leistungsdaten ergeben sich aus den momentan verfügbaren Folien von NV. Wenn das nicht kompletter Blödsinn ist was da draufsteht, ist das IMHO ein sehr gut Anhaltspunkt. Es könnte natürlich sein, dass die eine SGEMM Folio mit 48 GFlop/W einen reinen FP32 Chip beschreibt und die andere Folie sich auf einen FP64 lastigen Chip bezieht. Hört sich für mich aber eher unwahrscheinlich an.

Ja genau, ich gehe von dezidierten Einheiten aus, sonst macht meine Interpretation keine Sinn. GP102 als Gamerchip könnte dann kleiner ausfallen, hätte aber mehr FP32 Power als GP100, weil dieser mit höherem Takt laufen könnte.

Warum sollten sie den Chip so klein machen? Wenn sie von 17,8 Mrd. Transistoren sprechen, kann das Ding nur Groß werden. mit 400mm2 wäre das nicht IMHO nicht Leistungsfähig genug und sie könnten das was auf den Roadmaps steht nicht erreichen.

Die 17 Mrd sind der größte Anhaltspunkt für einen großen GP100 wenn sie für ihn gelten. Die 48 GFlop/W (sieht für mich eher nach 44 aus aber egal) bringen doch ohne Kenntnis der Leistungsaufnahme nichts.

Ich kann mir nur schwer vorstellen dass GP100 exklusiv für den Professionellen Markt wird denn Nvidia sagte selbst dass die exklusive Entwicklung dafür erst in par Jahren tragbar wird. Dann gilt aber entweder GP100>GP102>GP104 oder aber GP102>GP100>GP104.
GP102 ist eigentlich das noch viel größere Mysterium und für so ganz unwahrscheinlich halte ich es auch nicht, dass er gegen ein aus gutem Grund die Performancekrone erklimmendes AMD eingeschoben werden musste.

Godmode

2015-11-18, 22:54:44

Die 17 Mrd sind der größte Anhaltspunkt für einen großen GP100 wenn sie für ihn gelten. Die 48 GFlop/W (sieht für mich eher nach 44 aus aber egal) bringen doch ohne Kenntnis der Leistungsaufnahme nichts.

Ich kann mir nur schwer vorstellen dass GP100 exklusiv für den Professionellen Markt wird denn Nvidia sagte selbst dass die exklusive Entwicklung dafür erst in par Jahren tragbar wird. Dann gilt aber entweder GP100>GP102>GP104 oder aber GP102>GP100>GP104.
GP102 ist eigentlich das noch viel größere Mysterium und für so ganz unwahrscheinlich halte ich es auch nicht, dass er gegen ein aus gutem Grund die Performancekrone erklimmendes AMD eingeschoben werden musste.

Die Leistungsaufnahme habe mit mit den üblichen 250W angenommen. Wir haben also drei Konstanten:

40-48 GFlop/W FP32
250 W
3,5-3,8 TFLop/s FP64

Aus diesen drei Zahlen habe ich dann den Rest abgeleitet.

Ich habe meine These ja schon vor vielen Seiten vorgelegt:
GP100 wird hauptsächlich als FP64 und NVLink Zugpferd verkauft. (Cuda Arch 600)
GP102 könnte ein reiner FP32 Chip, wie schon GM200 werden. Dadurch wäre dieser auch relativ klein und wäre aber was FP32 angeht, trotzdem vor GM200. NVLink eher unwahrscheinlich, IMHO. Wenn sie es für SLI auf einer Platine nutzen wollen, wäre es aber schon denkbar und deutlich besser als die extrem veraltete SLI-Bridge, bzw. der Umweg über das PCIe-Interface.
GP104 wäre dann ein kleinerer GP102, hätte aber den gleichen Aufbau, inkl. Cachegrößen, TMUs, etc. in den SMPs (Cuda Arch 610).
Die kleineren Chips würden dann unter Cuda Arch 620 laufen

AffenJack

2015-11-18, 23:22:28

Ja, es ist der geistige Nachfolger von GK280. GM200 hat ja keine nennenswerte FP64 Leistung und war nur ein Lückenfüller, wegen der Prozessproblematik.

Ich wollte schon fast SMP schreiben (Shader Multiprocessor Pascal), damit diese Frage nicht aufkommt. 192 habe ich gewählt, damit man genau 4 SMP pro GPC hat und 1:3 bei FP64:FP32 erreicht. Mit 128 müsste man 6 SMPs pro GPC verbauen. Ich glaube dass die Variante mit 192 SPs billiger ist.

Nein, das macht keinen Sinn. Man ist bewusst auf 128 SP pro SMM runter gegangen mit Maxwell, weil es Architektonisch anscheinend mehr Sinn macht. Es war eine Evolution von Kepler und man wird jetzt nicht ne Rolle rückwärts machen. Pascal dürfte relativ ähnlich wie Maxwell sein vom Shaderaufbau und schon gar nicht wird man bei Pascal innerhalb einer Architetkur 2 ganz verschiedene Shader haben, weil da viel zu viel dran hängt.

Hübie

2015-11-19, 02:38:28

Die Leistungsaufnahme habe mit mit den üblichen 250W angenommen. Wir haben also drei Konstanten:

40-48 GFlop/W FP32
250 W
3,5-3,8 TFLop/s FP64

Aus diesen drei Zahlen habe ich dann den Rest abgeleitet.

Ich habe meine These ja schon vor vielen Seiten vorgelegt:
GP100 wird hauptsächlich als FP64 und NVLink Zugpferd verkauft. (Cuda Arch 600)
GP102 könnte ein reiner FP32 Chip, wie schon GM200 werden. Dadurch wäre dieser auch relativ klein und wäre aber was FP32 angeht, trotzdem vor GM200. NVLink eher unwahrscheinlich, IMHO. Wenn sie es für SLI auf einer Platine nutzen wollen, wäre es aber schon denkbar und deutlich besser als die extrem veraltete SLI-Bridge, bzw. der Umweg über das PCIe-Interface.
GP104 wäre dann ein kleinerer GP102, hätte aber den gleichen Aufbau, inkl. Cachegrößen, TMUs, etc. in den SMPs (Cuda Arch 610).
Die kleineren Chips würden dann unter Cuda Arch 620 laufen

Üblich sind btw. 225 Watt. Bei Quadros wird das öfter mal auf 250 Watt engehoben, aber wenn wir von HPC sprechen, dann doch bitte Tesla und somit 225 Watt. Gerne auch 235. Dann hast du deine 11+ TFLops. Wie kommst du eigentlich auf 950 MHz?

Ailuros

2015-11-19, 06:14:40

Üblich sind btw. 225 Watt. Bei Quadros wird das öfter mal auf 250 Watt engehoben, aber wenn wir von HPC sprechen, dann doch bitte Tesla und somit 225 Watt. Gerne auch 235. Dann hast du deine 11+ TFLops. Wie kommst du eigentlich auf 950 MHz?

In der Mehrzahl der Faelle aber auch marketing-technisches Gefusel eben weil sie zu oft nicht alle clusters auf Anhieb einschalten koennen bei anstaendigen yields. Wenn die yields dann besser werden und alle clusters moeglich sind und noch ein metal spin dazu kommt bleibt man auch nicht auf "nur" 225W stecken. Tesla K40 ist ein voller Kepler aber ein GK100b metal spin mit einer TDP von 235W bei 745/875MHz (core/boost), 1500MHz Speicher, GTX780Ti = 875/928/1750NHz @250W TDP. Sooo falsch hat er nicht gerechnet ;)

Hübie

2015-11-19, 06:22:59

Deshalb sagte ich gerne auch 235 Watt. Und das wird sich so schnell nicht ändern.

Ailuros

2015-11-19, 07:07:25

Deshalb sagte ich gerne auch 235 Watt. Und das wird sich so schnell nicht ändern.

Wenn man bei der 250 oder 235 oder 225W Rechnung die Frequenz oder noch besser auch die Anzahl der moeglichen clusters in betracht nimmt, ist die Rechnung nicht falsch. Es muss hauptsaechlich die perf/W Relation stimmen. Anders wenn ich als "sichere" konstante sagen wir mal 12 GFLOPs DP/W habe ist es eigentlich egal ob ich mit 225, 235 oder 250W rechne.

Hübie

2015-11-19, 09:28:13

Initial ging es ja um die Rückwärtsrechnung. Man muss dann immer so mit den Zahlen jonglieren, dass der Clou passt. Denn mehr als zerfetzte Infos haben wir ja nicht.

Ich bin mir nur in einer Sache sicher: Wenn Big-Pascal als GeForce gelauncht wird, erblassen wir blöden GM200-Geschädigten und wollen haben. :biggrin:
Ich persönlich hatte zuviel Hoffnung in Fiji gesetzt, da auf dem Papier ein Monster herauskommen müsste. Dann aber so eine Ente wurde und ich schließlich doch wieder Jensen Geld in den Rachen warf. Also mach ich es dieses Mal so, dass ich nix erwarte. =)

Godmode

2015-11-19, 09:32:58

Nein, das macht keinen Sinn. Man ist bewusst auf 128 SP pro SMM runter gegangen mit Maxwell, weil es Architektonisch anscheinend mehr Sinn macht. Es war eine Evolution von Kepler und man wird jetzt nicht ne Rolle rückwärts machen. Pascal dürfte relativ ähnlich wie Maxwell sein vom Shaderaufbau und schon gar nicht wird man bei Pascal innerhalb einer Architetkur 2 ganz verschiedene Shader haben, weil da viel zu viel dran hängt.

GK104 hatten ebenfalls fast keine DP-Einheiten, im Gegensatz zu GK110. Also haben wir hier schon innerhalb einer Familie zwei verschiedene Architekturen gehabt. Diesemal haben wie sogar drei verschiedene Architekturausprägungen in der Pascal Familie (siehe Cuda Compute Capability für Pascal)

Und ich wiederhole mich noch einmal: GP100 ist der Nachfolger von GK280 und nicht von GM200. Ob der Aufbau mit 192 SPs pro Shader Multiprozessor bleibt oder eben auf 128 wie bei GM200 zurück geht, ist ohne mehr Information wohl nicht zu beantworten.

http://regmedia.co.uk/2012/11/11/nvidia_tesla_k10_k20_features.jpg

Üblich sind btw. 225 Watt. Bei Quadros wird das öfter mal auf 250 Watt engehoben, aber wenn wir von HPC sprechen, dann doch bitte Tesla und somit 225 Watt. Gerne auch 235. Dann hast du deine 11+ TFLops. Wie kommst du eigentlich auf 950 MHz?

Der Ausgangspunkt meiner Rechnung waren immer die 48 GFlop/W FP32. Der Einfachheit habe ich mit 6144 FP32 ALUs gerechnet (192*4 SMPs*8 GPCs). Den Takt habe ich dann entsprechend angepasst, damit ca. 48 GFlop/W FP32 herauskommen. Die Anzahl der Einheiten ist in diesem Fall egal, man könnte wohl auch weniger SPs nehmen und dafür mehr Takt. Einheiten schätzen ist wirklich nur raten, verlassen kann man sich nur auf GFlop/W

Wenn ich mit deinen 225 W rechne, braucht man 890 MHz bei 6144 SPs um auf 48 GFlop/W FP32 bzw. 10,94 TFLop/s FP32 zu erreichen.

Ich habe übrigens keine deaktivierten Clusters in meiner Berechnung. Damit ist eigentlich fix zu rechnen bei so einem Monster Chip. Das würde die Leistung nochmal etwas verringern, bzw. den Takt etwas nach oben Treiben.

Dural

2015-11-19, 09:33:36

4TF DP finde ich jetzt nicht so der Hammer.

Ailuros

2015-11-19, 09:42:54

4TF DP finde ich jetzt nicht so der Hammer.

Im Gegenteil ist es verdammt viel im Vergleich zu heute vorhandenen Raten und GPU Bandbreiten generell. Theoretisch mehr ist immer moeglich, nur brauchen wir dann auch einen halbwegs logischen Vorschlag der eben NICHT etliche tausende $ pro SKU in der Herstellung kosten wuerde.

GK104 hatten ebenfalls fast keine DP-Einheiten, im Gegensatz zu GK110. Also haben wir hier schon innerhalb einer Familie zwei verschiedene Architekturen gehabt. Diesemal haben wie sogar drei Verschiedene Architekturausprägungen in der Pascal Familie (sieh Cuda Compute Capability für Pascal)

Und ich wiederhole mich noch einmal: GP100 ist der Nachfolger von GK280 und nicht von GM200. Ob der Aufbau mit 192 SPs pro Shader Multiprozessor bleibt oder eben auf 128 wie bei GM200 zurück geht, ist ohne mehr Information wohl nicht zu beantworten.

Der Ausgangspunkt meiner Rechnung waren immer die 48 GFlop/W FP32. Der Einfachheit habe ich mit 6144 FP32 ALUs gerechnet (192*4 SMPs*8 GPCs). Den Takt habe ich dann entsprechend angepasst, damit ca. 48 GFlop/W FP32 herauskommen. Die Anzahl der Einheiten ist in diesem Fall egal, man könnte wohl auch weniger SPs nehmen und dafür mehr Takt. Einheiten schätzen ist wirklich nur raten, verlassen kann man sich nur auf GFlop/W

Wenn ich mit deinen 225 W rechne, braucht man 890 MHz bei 6144 SPs um auf 48 GFlop/W FP32 bzw. 10,94 TFLop/s FP32 zu erreichen.

Ich habe übrigens keine deaktivierten Clusters in meiner Berechnung. Damit ist eigentlich fix zu rechnen bei so einem Monster Chip. Das würde die Leistung nochmal etwas verringern, bzw. den Takt etwas nach oben Treiben.

Mich wuerde es verdammt ueberraschen wenn sie am heutigen 4*SIMD32 etwas aendern wuerden pro cluster. Sonst wie ich gerade bei B3D schrieb: wenn Pascal FP16 genauso implementiert hat wie in Maxwell/ULP sehe ich keinen besonderen Grund wieso sie NICHT dedizierte FP64 SPs benutzen sollten. Einziger Grund der dagegen sprechen wuerde waere dass sie zu stark am Rand der fuer 16FF+ vorgeschlagenen die area waeren wie beim GM200. Im letzten Fall sind es schon 600mm2, ergo waere der zusaetzliche DP Schnickschnack dort von 30-40 zusaetzlichen mm2 zu gewagt.

Hübie

2015-11-19, 10:14:34

4TF DP finde ich jetzt nicht so der Hammer.

Wie bitte? Wohl den Verlauf nicht mitbekommen oder was? :|

@Godmode: Wieso nun wieder 192? :freak: Kepler hat man nicht richtig auslasten können und hatte zudem zu wenig registerspace bzw. bräuchte auch ein größeren L2$.

Godmode

2015-11-19, 10:26:39

Mich wuerde es verdammt ueberraschen wenn sie am heutigen 4*SIMD32 etwas aendern wuerden pro cluster. Sonst wie ich gerade bei B3D schrieb: wenn Pascal FP16 genauso implementiert hat wie in Maxwell/ULP sehe ich keinen besonderen Grund wieso sie NICHT dedizierte FP64 SPs benutzen sollten. Einziger Grund der dagegen sprechen wuerde waere dass sie zu stark am Rand der fuer 16FF+ vorgeschlagenen die area waeren wie beim GM200. Im letzten Fall sind es schon 600mm2, ergo waere der zusaetzliche DP Schnickschnack dort von 30-40 zusaetzlichen mm2 zu gewagt.

Ich gehe zu 100% von dezidierten FP64 Einheiten aus mit einem Verhältnis von 1:3 (FP64/FP32). Meine Rechnung lässt in diesem Fall gar keine andere Möglichkeit zu. Die FP32 Einheiten dürften auch etwas größer ausfallen, da sie eben nun auch FP16/Int8 können müssen.

Das Problem was ich mit 4*SIMD32 FP32 habe ist, dass sich dann 1:3 nicht richtig ausgeht. Außerdem würde 4*SIMD32 bedeuten, dass wir 48 Shader Multiprozessoren brauchen, bei 6*SIMD32 hingegen nur 32. Als Laie kann ich nicht beantworten, was mehr kostet, denke aber dass mehr SPs pro Shader Multiprozessor billiger ist.

Wie bitte? Wohl den Verlauf nicht mitbekommen oder was? :|

@Godmode: Wieso nun wieder 192? :freak: Kepler hat man nicht richtig auslasten können und hatte zudem zu wenig registerspace bzw. bräuchte auch ein größeren L2$.

Ließt du auch was ich schreibe? Recht viel genauer kann ich meine Gedankengänge nicht mehr darlegen. :tongue:

Da GK110 die von dir angesprochenen Probleme hatte, wurde eben GK210 entwickelt.

AffenJack

2015-11-19, 10:29:16

GK104 hatten ebenfalls fast keine DP-Einheiten, im Gegensatz zu GK110. Also haben wir hier schon innerhalb einer Familie zwei verschiedene Architekturen gehabt. Diesemal haben wie sogar drei verschiedene Architekturausprägungen in der Pascal Familie (siehe Cuda Compute Capability für Pascal)

Und ich wiederhole mich noch einmal: GP100 ist der Nachfolger von GK280 und nicht von GM200. Ob der Aufbau mit 192 SPs pro Shader Multiprozessor bleibt oder eben auf 128 wie bei GM200 zurück geht, ist ohne mehr Information wohl nicht zu beantworten.

Das ist etwas völlig anderes, paar DP Einheiten reinhauen zusätzlich in die SM verändert nicht soviel, aber 192 SP und 128 SP sind einfach verschiedene Architekturen. Da passt registerspace etc. wie Hübie schreibt alles schon nicht mehr. GP100 mag vom Sinn her ein Nachfolger von Kepler sein,da Maxwell kein DP hat. Aber von der Architektur wird er viel mehr ein Maxwell sein als ein Kepler. Wäre 16nm früher verfügbar gewesen, hättest du Maxwell halt mit DP statt ohne DP gesehen. Das ist nen minimaler Aufwand.

Godmode

2015-11-19, 10:45:26

Das ist etwas völlig anderes, paar DP Einheiten reinhauen zusätzlich in die SM verändert nicht soviel, aber 192 SP und 128 SP sind einfach verschiedene Architekturen. Da passt registerspace etc. wie Hübie schreibt alles schon nicht mehr. GP100 mag vom Sinn her ein Nachfolger von Kepler sein,da Maxwell kein DP hat. Aber von der Architektur wird er viel mehr ein Maxwell sein als ein Kepler. Wäre 16nm früher verfügbar gewesen, hättest du Maxwell halt mit DP statt ohne DP gesehen. Das ist nen minimaler Aufwand.

Ich habe mich übrigens immer verschrieben, das Ding das ich meinte heißt GK210 und nicht GK280. Der Chip wird zweimal auf den Tesla K80 Boards verbaut. Genau dort wurden die Probleme der zu kleinen Register und Caches von GK110/b angegangen.
http://www.anandtech.com/show/8729/nvidia-launches-tesla-k80-gk210-gpu

Wenn du mir erklärst, wieviele FP64 Einheiten und wie angeordnet du zu den 4*SIMD32 FP32 Einheiten packst um auf ca. 3,64 TFlop/s FP64 Leistung kommst, lasse ich mich umstimmen.

Hübie

2015-11-19, 10:58:53

60 Multiprozessoren á 128 ALUs bei 1:4 ratio... Takt kannst du dann beinahe würfeln. Oder nimmst halt 56. Kombinationsmöglichkeiten gibt es genug. Und ja ich lese was du schreibst, aber irgendwie packst du mal FP32&64 in einen Pott, dann mal wieder nicht. Oder missverstehen wir uns? :|
Das mit GK280 wollte ich dir nicht so unter die Nase reiben und wir alle wissen ja was du meinst.

Rate mal wieso K80 aufgelegt werden musste. ;)
Das mit GK104<->110 ist übrigens ein gutes Argument.

Godmode

2015-11-19, 11:14:56

60 Multiprozessoren á 128 ALUs bei 1:4 ratio... Takt kannst du dann beinahe würfeln. Oder nimmst halt 56. Komvinationsmöglichkeiten gibt es genug. Und ja ich lese was du schreibst, aber irgendwie packst du mal FP32&64 in einen Pott, dann mal wieder nicht. Oder missverstehen wir uns? :|
Das mit GK280 wollte ich dir nicht so unter die Nase reiben und wir alle wissen ja was du meinst.

Rate mal wieso K80 aufgelegt werden musste. ;)
Das mit GK104<->110 ist übrigens ein gutes Argument.

Hui, das wären dann 7680 SPs bei 700 MHz um 48 GFlop/W FP32 zu erreichen. Allerdings erreichen wir dann wieder keine 3,5 TFlop/s FP64, sondern nur 2,69. Der verlinkte Chart von mir sagt aber was anderes. Mir kamen meine 6144 SPs schon verdammt viel vor, selbst für 17,8 Mrd. Transistoren.

Was meinst du mit ich packe FP32&64 in einen Pott? Ich gehe davon aus, das ein Shader Multiprozessor dreimal so viele FP32 Einheiten wie FP64 Einheiten hat.

Eventuell ist das schon wieder untergegangen, aber nochmal unsere Konstanten:

ca. 3,6 TFLop/s FP64 Leistung (Quelle: http://www.ecmwf.int/sites/default/files/HPC-WS-Posey_0.pdf)
ca. 48 GFlop/W FP32 Leistung (Quelle: http://www.extremetech.com/wp-content/uploads/2015/03/Pascal1.png)
ca. 225 Watt

Den Rest kann man ausrechnen und mit meiner Konfiguration, lassen sich die Zahlen am besten erreichen. Berichtigt mich, wenn ich mich wo vertan habe.

Hübie

2015-11-19, 11:28:39

Ich wollte nur sagen, dass man viel jonglieren kann. :) Mag sein, dass du nah dran oder gar einen Treffer hast, nur versteifen würde ich mich nicht darauf. Da die Packdichte ja nicht überall steigt kann man sagen, dass in den ALUs eher Faktor 2,55x und in anderen Bereichen eher 2,00x erreicht wird. Im Mittel hat man dann die 2,20x. Das sind ja eh alles nur grobe und theoretische Angaben.

Aus den slides da erkennt man ja ebenfalls keine konkreten Zahlen. Die 48 z.B. sind ja eher vage. Maxwell hat ja je nach Takt irgendwo was bei 25 GFlops/W und nun schau mal wo genau das da auf dem slide sein soll :D

Godmode

2015-11-19, 11:32:45

Hübie

2015-11-19, 11:42:12

Ich habe einfach ein Problem im Kopf mit dedizierten FP64 Units. :D

Godmode

2015-11-19, 11:44:47

Kann ich verstehen, ich finde das auch irgendwie "unelegant".

Da schreibt übrigens wer ab von uns: :biggrin:
https://forum.beyond3d.com/posts/1882167/

AffenJack

2015-11-19, 12:54:33

Wenn du mir erklärst, wieviele FP64 Einheiten und wie angeordnet du zu den 4*SIMD32 FP32 Einheiten packst um auf ca. 3,64 TFlop/s FP64 Leistung kommst, lasse ich mich umstimmen.

Ich kann auch nur mutmaßen, da ich nicht genug von der Architektur weiß, was möglich wäre. Prinzipiell könnte ich mir 48 FP64 oder 40 FP64 pro 128 FP32 vorstellen, aber ich weiß nicht ob sowas architekturell Sinn macht.
5120 FP32 Shader plus 1920 FP64 oder 1600 FP64. Dazu 320 TMUS, 128 Rops, 8 GPCs. Der Platz den die Nichtverdopplung an Rops,TMUs einbringt wird in DP investiert. Dazu 10% mehr Takt durch 16FF.

Godmode

2015-11-19, 13:17:50

40*FP64 klingt aber sehr seltsam? Normalweise sind immer 32 SPs eine SIMD-Einheit. 48 ginge mit einer SIMD32 und einer SIMD16 Einheit, was aber auch irgendwie "unrund" erscheint.

Nakai

2015-11-19, 13:42:24

Ok, das mit der Packdichte ist jedenfalls ein interessantes Detail.

Im Diagramm steht auch noch Pascal 2xSGEMM/W, was dann gut zu den 48 passen würde, oder?

Ich will mich gar nicht versteifen, bin für alles offen, solange es schlüssig erklärt ist.

Die Packdichte wird eher gegen 35Mio Transen/mm² wohl gehen. GP100 wird kleiner als GM200.

DP:SP entweder 1:2 oder 1:4. Ich gehe mittlerweile von dedizierten FP64-Units aus und keine vollkommenen Mixed-Precision-Units. Falls doch, dann entweder 1:2 oder 1:4. Mit dedizierten DP-SIMDs kann man noch ganz andere Verhältnisse hinbekommen...je nach Implementierungsart.

N0Thing

2015-11-19, 13:50:53

Eventuell ist das schon wieder untergegangen, aber nochmal unsere Konstanten:

ca. 3,6 TFLop/s FP64 Leistung (Quelle: http://www.ecmwf.int/sites/default/files/HPC-WS-Posey_0.pdf)
ca. 48 GFlop/W FP32 Leistung (Quelle: http://www.extremetech.com/wp-content/uploads/2015/03/Pascal1.png)
ca. 225 Watt

Den Rest kann man ausrechnen und mit meiner Konfiguration, lassen sich die Zahlen am besten erreichen. Berichtigt mich, wenn ich mich wo vertan habe.

Anhand des Diagramms liegt aus meiner Sicht der FP32-Wert eher bei 40GFlop/W und ca. 4TFlop/s FP64 laut der Präsentationsfolie (Seite 7). Keine Ahnung, ob man das unter einen Hut bekommt. :D

Godmode

2015-11-19, 13:54:25

Anhand des Diagramms liegt aus meiner Sicht der FP32-Wert eher bei 40GFlop/W und ca. 4TFlop/s FP64 laut der Präsentationsfolie (Seite 7). Keine Ahnung, ob man das unter einen Hut bekommt. :D

Du ließt die Folie falsch. Nicht die Quadrate stellen den Leistungswert dar, sondern die Beschriftungen. Die Quadrate stellen nur das Jahr dar.

N0Thing

2015-11-19, 13:56:26

Dann wären es immer noch keine 48, da die Beschriftung deutlich darunter liegt.

Godmode

2015-11-19, 14:03:04

Dann wären es immer noch keine 48, da die Beschriftung deutlich darunter liegt.

Argl, sorry meinte natürlich die DP Folie im PDF auf Seite 7.

N0Thing

2015-11-19, 14:05:49

Ah, stimmt. Das sind die Markierungen für das Jahr. :redface:

Dural

2015-11-19, 14:22:15

Nakai

2015-11-19, 14:23:59

Bei GK110 waren es pro SM ja 6 Ports mit 32 FP32-Units. Es gab noch 2 Ports mit je 32 FP64-Units. Womöglich wurden die gleichen Ports wie bei den FP32-Units verwendet, womöglich 3 Ports je FP64-SIMD. Bei Kepler war es ein großer globaler Scheduler für alle Ports. Wie die Einheiten hinter den Ports organisiert sind, kA (SFUs, LD/ST). Womöglich wird mehr blockiert, wenn bestimmten Instruktionen geschedult werden.
Maxwell hat pro Block als pro 32er-FP32-SIMD, SFU-SIMD, LD/ST-SIMD einen dedizierten Scheduler. Pro Maxwell SM eben vier dieser Blöcke. Das spart Verdrahtung und wohl Energie, da die ganze Scheduling Logk deutlich kleiner ist. Womöglich liegt hinter dem FP32-SIMD-Port eine dedizierte FP64-Unit. Wie die aufgebaut ist, ob hier gesharte Ressourcen mit den FP32-Units gibt, kA. Jedenfalls sieht Pascal so aus, dass die FP32-Units zu Mixed-Precision-Units aufgewertet wurden. Hierzu wäre das Effektivste eindeutig eine Rate von 1:4.
Wie das alles zusammenpasst? Pascal hat etwa 60% mehr FP32-Leistung. Da passt schonmal gut zu ~5000SPs.
Mit DP-Rate von 1:4 und höherem Takt wird man dementsprechend schon gut vorwärts kommen. Man schafft auf jeden Fall 3 TFLOPs. NV hat auch schon ungerade GPC-Zahlen genommen, siehe GK110 mit 5 GPCs.
Ich würde sagen wir sehen etwas zwischen 5000~6000SPs und 1:4 DP:SP-Rate.

€: Wenn Greenland das ist, was ich denke, dann liefert AMD ähnlich viel SPs wie NV mit einem DIE der kleiner ist und eine höhere DP-Rate aufweißt. Bei Greenland sollte man von etwa 4~5 TFLOPs bei DP ausgehen.

AffenJack

2015-11-19, 14:38:17

40*FP64 klingt aber sehr seltsam? Normalweise sind immer 32 SPs eine SIMD-Einheit. 48 ginge mit einer SIMD32 und einer SIMD16 Einheit, was aber auch irgendwie "unrund" erscheint.

Im Moment liegt man bei 4 FP64 pro 128 SP bei Maxwell. Ich hab einfach lapidar vielfaches davon als mögliche Konfigurationen der DP Shader angenommen. kann aber natürlich auch völlig falsch sein. Ich lasse mich gerne des besseren belehren. 4:1 oder 2:1 wären das einfachste, aber vielleicht gehen halt auch andere Konfigurationen.

Godmode

2015-11-19, 14:45:03

Nakai

2015-11-19, 14:46:12

NV hat eine Warpsize von 32. Kurz man braucht irgendwelche Teiler von 32.

Sgemm ist Matrixmultiplikation, was auch sehr cachelastig ist.

Nakai

2015-11-19, 15:05:24

@Nakai:

Was mich an 1:4 so stark stört ist, der FP32 GFlop/W Wert bei 65 (sic!) liegen müsste, um eben die 3,6 TFLop/s FP64 Leistung laut Chart auf Seite 7 zu erreichen. Laut SGEMM/W Chart, liegt dieser aber höchsten bei 48. Ob sie da so stark untertreiben? Das Ding hätte 14,7 TFlop/s FP32 Leistung, bei 6144 SPs.

Ich kann nur das wiederholen:
ca. 3,6 TFLop/s FP64 Leistung (Quelle: http://www.ecmwf.int/sites/default/f...WS-Posey_0.pdf)
ca. 48 GFlop/W FP32 Leistung (Quelle: http://www.extremetech.com/wp-conten...03/Pascal1.png)
ca. 225 Watt

Ein Fehler könnte allerdings darin liegen, dass ich SGEMM/W mit Peak FP32 GFlop/W gleichsetze. Weiß man wie nah SGEMM an der theoretischen Peak-Rechenleistung liegt?

Zum letzteren, das steht auch in deinem ersten Link.
Wenn die Andeutungen darin richtig sind, dann hat GP100 6000 SPs und DP:SP von 1:4.
Der Takt wird wohl über 1GHz sein. Das Problem mit dem 48GFLOP/W in SGEMM FP32 ist, wenn NV DP:SP - 1:4 liefert ist der gesamte Durchsatz bzw die Bandbreite für DP überdimensioniert, sprich man liefert doppelt soviel Bandbreite, wie es eigentlich Durchsatz bei DP gibt (dazu bräuchte man DP:SP von 1:2). Ergo klingt das eher danach, dass GP100 unter SP throtteln kann, während unter DP dies nicht passiert, weil das Design nicht ausgeglichen ist. Außerdem wird NV bei GP100 wohl eher etwas zu 12000SPs als Marketingzahl angeben (Mixed-Precision).
Bei 6000SPs und 1,2 Ghz hat man schon 3,6 TFLOPs DP. Bei SP-Workloads geht der Takt eben etwas runter...also auf 1,0 Ghz oder so. Die ganzen Interfaces werden auch nur zu 50% ausgelastet.;)

Etwas technischeres. Wenn man von SP auf DP geht müssen die FPUs deutlich aufgebläht werden. Die Multiplizierer innerhalb der FPU vervierfachen sich bei einer Verdopplung. Gut FP64 ist vom Bit-Aufbau des IEEE754-Datentyps auch keine reine einfache Verdopplung.^^
Ein Verhältnis von 1:4 ist dennoch nah am Optimum. Also Verdopplung gleich Vervierfchung ist gleich DP:SP-Durchsatz. Womöglich baut man die Units so um, dass 32 FP32-SIMDs auch als 8 FP64-SIMDs sich verhalten können. Es müssen immer 4 FP32-Units zu einer FP64 zusammenegschalten werden. Das wäre dann auch Mixed-PRecision, blos etwas anders.^^

N0Thing

2015-11-19, 15:06:13

Ich kann nur das wiederholen:
ca. 3,6 TFLop/s FP64 Leistung (Quelle: http://www.ecmwf.int/sites/default/f...WS-Posey_0.pdf)
ca. 48 GFlop/W FP32 Leistung (Quelle: http://www.extremetech.com/wp-conten...03/Pascal1.png)
ca. 225 Watt

Ein Fehler könnte allerdings darin liegen, dass ich SGEMM/W mit Peak FP32 GFlop/W gleichsetze. Weiß man wie nah SGEMM an der theoretischen Peak-Rechenleistung liegt?

Auf Seite 13 des PDF findet man beide Werte für K20X und K40:

Peak SP 3.93 TF vs. Peak SGEMM 2.95 TF bei K20X und
Peak SP 4.29 TF vs. Peak SGEMM 3.22 TF bei K40.

Nakai

2015-11-19, 15:08:59

Achtung unter SP stirbt Kepler an REgisterbandbreite...das hat Maxwell nicht mehr.

Godmode

2015-11-19, 15:14:54

Zum letzteren, das steht auch in deinem ersten Link.
Wenn die Andeutungen darin richtig sind, dann hat GP100 6000 SPs und DP:SP von 1:4.
Der Takt wird wohl über 1GHz sein. Das Problem mit dem 48GFLOP/W in SGEMM FP32 ist, wenn NV DP:SP - 1:4 liefert ist der gesamte Durchsatz bzw die Bandbreite für DP überdimensioniert, sprich man liefert doppelt soviel Bandbreite, wie es eigentlich Durchsatz bei DP gibt (dazu bräuchte man DP:SP von 1:2). Ergo klingt das eher danach, dass GP100 unter SP throtteln kann, während unter DP dies nicht passiert, weil das Design nicht ausgeglichen ist. Außerdem wird NV bei GP100 wohl eher etwas zu 12000SPs als Marketingzahl angeben (Mixed-Precision).
Bei 6000SPs und 1,2 Ghz hat man schon 3,6 TFLOPs DP. Bei SP-Workloads geht der Takt eben etwas runter...also auf 1,0 Ghz oder so. Die ganzen Interfaces werden auch nur zu 50% ausgelastet.;)
Etwas technischeres. Wenn man von SP auf DP geht müssen die FPUs deutlich aufgebläht werden. Die Multiplizierer innerhalb der FPU vervierfachen sich bei einer Verdopplung. Gut FP64 ist vom Bit-Aufbau des IEEE754-Datentyps auch keine reine einfache Verdopplung.^^
Ein Verhältnis von 1:4 ist dennoch nah am Optimum. Also Verdopplung gleich Vervierfchung ist gleich DP:SP-Durchsatz. Womöglich baut man die Units so um, dass 32 FP32-SIMDs auch als 8 FP64-SIMDs sich verhalten können. Es müssen immer 4 FP32-Units zu einer FP64 zusammenegschalten werden. Das wäre dann auch Mixed-PRecision, blos etwas anders.^^

Ich dachte immer der Takt muss nur bei starker FP64 Last abgesenkt werden? Bei GK210 wird das zumindest gemacht, siehe Seite 8:

http://www.mpcdf.mpg.de/about-mpcdf/news-events/content/gpu_workshop_2015/Koehler_Nvidiaroadmap.pdf

Auf Seite 13 des PDF findet man beide Werte für K20X und K40:

Peak SP 3.93 TF vs. Peak SGEMM 2.95 TF bei K20X und
Peak SP 4.29 TF vs. Peak SGEMM 3.22 TF bei K40.

Achtung unter SP stirbt Kepler an REgisterbandbreite...das hat Maxwell nicht mehr.

Schade das K80 dort fehlt, der das Problem nämlich nicht mehr hat, IIRC.

Nakai

2015-11-19, 15:21:32

GK110 hat ein DP:SP-1:3. Bei 1:4 könnte das sehr ausgeglichen sein. Dafür hat man den Vorteil dass man die Bandbreiten für SP und HF nicht benötigt, weil der Durchsatz diese eh nicht erreicht...wenn das Design ausbalanciert ist.
Und klar kostet DP immer was, die Frage ist eher, wieviel?

€: DA steht DGEMM. Das Matrixmultiplikation. Such mal nach der Implementierung diebzüglich, denn diese lastet die GPU wohl ziemlich übel aus, weil sehr viel SharedMemory und optimierte Speicherzugriffe verwendet werden. Man müsste SGEMM mit DGEMM vergleichen.

Godmode

2015-11-19, 15:34:27

SGEMM ist Float
DGEMM ist Double

Glaubst du das die Implementierung da großartig anders ist? Das dürfte wohl Die CUBLAS Lib sein, aber ich such nochmal extra.

Nakai

2015-11-19, 15:44:50

Godmode

2015-11-19, 16:26:10

Das ist mir klar. Ich meinte, wenn bei sgemm auch gethrottelt wird, liegts an der Implementierung und nicht am Datentyp. Aber klar DP kostet Energie, nichts ist umsonst. Und DP:SP Verhältnis entscheidet auch über die Energieeffizienz.

€: DP:SP von 1:4 ist so ziemlich am Optimum, auch reinher von der Energieeffizienz, sowie Ressourceneffizienz.

Das steht leider nirgend wo was bei SGEMM passiert.

Wenn du sagst, dass DP:SP von 1:4 ziemlich am Optimum liegt, glaube ich dir das. Dann war ich mit meiner 1:3 Geschichte wohl auf dem Holzweg.

Nakai

2015-11-19, 16:29:47

Theoretisch. Laut specs erreicht so ein k40 oder k80 bei Peak-Boost auch immer 1:3 bei DP. Hängt aber auch immer von der Auslastung des Kernels ab.

Ahja eine niedrigere DP:SP Rate sollte auch weniger Energie verbraten, einfach weil der Durchsatz nicht so hoch ist.

Hübie

2015-11-19, 17:08:13

Im Vergleich zu AMD wird das wohl nicht reichen, deswegen.
Gerade da AMD in letzter zeit viel vom HPC Markt spricht und sich dort bemüht muss NV doch sehr aufpassen und da könnten 4TF DP nicht ausreichen.

Lediglich die S9150 bietet mehr DP TFlops pro Watt als die Konkurrenz. Aber glaube gegen die dual Tesla K80 wars das auch wieder (müsste jetzt gucken, aber bin zu faul ;D).

Dural

2015-11-19, 17:43:29

ich spreche nicht von den aktuellen 28nm GPUs ;)

Godmode

2015-11-19, 18:39:33

Auf b3d meint übrigens iMacmatician, dass die Quadrate doch die richtigen Werte darstellen und nicht nur das Jahr darstellen, wie ich gemutmaßt habe. Somit wären wir doch eher bei fast 4 TFlop/s FP64. Er hat das alles schön im einer Tabelle dargestellt:

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

Daraus kann man jetzt folgendes schließen:

Annahme:
4 TFlop/s FP64 laut Chart
6144 FP32 SPs

1.) GP100 hat 1:2 und ist verglichen mit GM200 eigentlich eine FP32 Krücke, wenn man die Anzahl der Transistoren betrachtet. Der Takt läge bei 650 MHz.
2.) GP100 hat 1:4 und wäre somit ein absolutes FP32 Monster. 16 TFlop/s wäre fast ein Faktor 2,6 gegenüber GM200. Man bräuchte aber auch 1300 MHz, was mir zuviel vorkommt.
3.) GP100 hat 1:3 und wäre in FP32 etwa doppelt so schnell wie GM200. Das wäre mit 980 MHz möglich.
4.) Es ist alles ganz anders und ich habe viele sinnlose Posts zum Thema geschrieben. :)

AnarchX

2015-11-19, 19:17:54

Vielleicht auch wieder etwas "krummes" wie bei GK110. 36 SMP -> 4608SPs: 4*3*3.
Da die FP32-Projektionen zwischen 1,4 und 2,0 laut NV liegen, sind 1:4 und 16 TFLOPs FP32 nicht ganz so realistisch.

FP64-Takt könnten wohl bei <=1GHz liegen. Bei FP32 wäre es interessant, wenn man ähnlich wie die A9-SoCs Taktgewinne aus 16nm ziehen könnte. Vielleicht erreicht man ~1,2GHz Basis-Takt.

Troyan

2015-11-19, 20:25:25

ich spreche nicht von den aktuellen 28nm GPUs ;)

Und was bringt es AMD? :confused:
Recheneinheiten sind spottbillig - platz- wie energiemäßig.

Teuer ist die Verteilung von Threads sowie das Bewegen von Daten auf dem Chip. Die reine Rechenleistung hat kaum eine Aussagekraft.

Dazu kann man sich auch das hier anhören: http://images.nvidia.com/events/sc15/SC5102-path-exascale-computing.html

nVidia hat Pascal am Laufen und im Labor. ;)

Kartenlehrling

2015-11-19, 21:29:08

In wie weit kann man die schlechte Entwicklung von Intel cpu auf 14nm mit der von der GPU vergleichen?
Sehen wir jetzt wirklich nur 3D Plastigattrappen oder werden sie nur "schweine Teuer"?

http://www.computerbase.de/2015-11/intel-fertigung-14-nm-verfehlt-prognosen-ausblick-auf-10-und-7-nm/
Intel-Fertigung : 14 nm verfehlt Prognosen

AnarchX

2015-11-19, 21:56:47

AffenJack

2015-11-19, 22:16:54

Jo, nach seinen Worten schon, aber wir wissen ja eigentlich, dass 900 mm² unmöglich machbar ist. Vielleicht meint er einen 30x30 Interposer mit 900 mm². Amd hat bei Fiji ja auch mit 1011 mm² geworben.

Godmode

2015-11-19, 22:49:30

Er könnte sich versprochen haben, was aber eher unwahrscheinlich ist. Eventuell meint er wirklich den Interposer?

AffenJack

2015-11-19, 23:36:01

Er wiederholt es indem er sagt 10mm sind 1/3 der Seitenlänge und 1/9 der Fläche von Pascal. Da gibts auf jeden Fall keinen Versprecher. Ich glaube an die Interposergröße. Dieses "Charge-Recycled Signaling" wird übrigens auch mit Pascal zuerst eingeführt.

Skysnake

2015-11-20, 00:16:19

Ailuros

2015-11-20, 06:29:44

Und was bringt es AMD? :confused:
Recheneinheiten sind spottbillig - platz- wie energiemäßig.

Teuer ist die Verteilung von Threads sowie das Bewegen von Daten auf dem Chip. Die reine Rechenleistung hat kaum eine Aussagekraft.

Dazu kann man sich auch das hier anhören: http://images.nvidia.com/events/sc15/SC5102-path-exascale-computing.html

nVidia hat Pascal am Laufen und im Labor. ;)

Du bist wohl davon ausgegangen dass er weiss wovon er redet oder? :P

Auf b3d meint übrigens iMacmatician, dass die Quadrate doch die richtigen Werte darstellen und nicht nur das Jahr darstellen, wie ich gemutmaßt habe. Somit wären wir doch eher bei fast 4 TFlop/s FP64. Er hat das alles schön im einer Tabelle dargestellt:

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

Daraus kann man jetzt folgendes schließen:

Annahme:
4 TFlop/s FP64 laut Chart
6144 FP32 SPs

1.) GP100 hat 1:2 und ist verglichen mit GM200 eigentlich eine FP32 Krücke, wenn man die Anzahl der Transistoren betrachtet. Der Takt läge bei 650 MHz.
2.) GP100 hat 1:4 und wäre somit ein absolutes FP32 Monster. 16 TFlop/s wäre fast ein Faktor 2,6 gegenüber GM200. Man bräuchte aber auch 1300 MHz, was mir zuviel vorkommt.
3.) GP100 hat 1:3 und wäre in FP32 etwa doppelt so schnell wie GM200. Das wäre mit 980 MHz möglich.
4.) Es ist alles ganz anders und ich habe viele sinnlose Posts zum Thema geschrieben. :)

Moment....packen wir es nochmal von Anfang an....Ihr redet bei B3D ueber Seite 7 hier ja? http://www.ecmwf.int/sites/default/files/HPC-WS-Posey_0.pdf

Die Praesentation ist ziemlich alt und die 4 TFLOPs DP wuerde ich NICHT als garantiert ansehen, denn IHVs treffen nicht immer ihre design-targets deshalb halten sie auch meistens die Fresse wenn es zu langjaehrigen Projektionen kommt. Ich bezweifle erstmal dass GP100 mit 1000GB/s ankommen wird, ergo wieso soll der linke chart am Ende zu 100% korrekt sein? Der Zweck der Seite ist einzuschaetzen wie es mit diversen Konstanten in absehbarer Zukunft aussehen koennte im allerbesten Fall. Dabei mal an der Seite wieso soll Volta nur ein Bandbreiten-Steigerung von 20% vs. Pascal haben bei einer DP Steigerung nach dem linken chart von 75%?

Da ich gerade im KNL thread etwas gelesen habe: http://images.anandtech.com/doci/9802/Overview.png ....nur weil NV keine relevanten footnotes wie die unten rechts hat, heisst es noch lange nicht dass es auch nicht bei NV's Projektionen anwendbar ist.

Um Huebie's Bedenken mitzuberechnen ganz einfach beim ersten Schub fuer HPC only:

42 SMMs@1GHz = 10.752 TFLOPs FP32 oder 21.504 TFLOPs FP16
1680 SPs@1GHz = 3.36 TFLOPs FP64
TDP: 225W

Alles rein spekulativ, aber mal sehen ob die diversen Abschreiber wieder so bloed sind es als Fakten weiterzutragen.

Dural

2015-11-20, 09:06:45

oder er meint mit dem HBM Speicher zusammen :freak: wahrscheinlich ist es schon der Interposer :)

Hübie

2015-11-20, 10:07:27

ich spreche nicht von den aktuellen 28nm GPUs ;)

Ach so. Diese theoretischen Zahlen sind eh keine sehr guten Anhaltspunkte, wenn man mal real-Anwendungen damit vergleicht. Auch wird DP immer wieder zu hoch bewertet. Das meiste ist noch single precision.

Wenn AMD es schafft nicht nur auf dem Papier zu glänzen, dann kann man sagen es reicht nicht mehr. Vorher ist das eher ein Luftschloß. An der Situation auf dem CPU-Markt merkt man was passiert wenn ein IHV ins Hintertreffen gerät, daher wünsche ich mir wirklich dass AMD zurückkehrt. :biggrin:

Edit: Ach ja und natürlich meint er das Package, nicht den nackten Die.

Ailuros

2015-11-20, 10:13:44

Bei der relativ "kleinen" package Groesse kann ich mir keinen die mit mehr als 500mm2 vorstellen.

AffenJack

2015-11-20, 10:27:49

Kommt drauf an wie groß HBM2 im Vergleich zu HBM1 ist. Bei Prototypen hatte AMD nen 502 mm Die auf nem 818 mm Interposer. Aber ja sollte eher in der 500 Region liegen.

Unicous

2015-11-20, 10:35:10

Wie groß?:confused:

Die Stacks werden wahrscheinlich etwas höher sein, dass sie (zumindest deutlich) mehr Fläche haben glaube ich nicht.

HBM2 ist wie vor einer Weile festgestellt wurde, nur ein Marketingname von SK hynix für die Umstellung auf kleinere Strukturbreiten und damit einhergehend höhere Kapazität und andere "Verbesserungen", die die eigentliche HBM Spec eh schon vorsieht.

AffenJack

2015-11-20, 11:26:57

Jo ging mir um mehr Fläche wegen der deutlich höheren Kapazitäten. 4GB Stacks, statt der 1 GB bei Fiji sind ja 2 Prozesssprünge bei gleicher Fläche.

Botcruscher

2015-11-20, 11:57:03

Ich bezweifle erstmal dass GP100 mit 1000GB/s ankommen wird, ergo wieso soll der linke chart am Ende zu 100% korrekt sein?
Der Punkt dürfte auf dem Papier wohl noch am einfachsten zu erreichen sein. 4096bit bei 1GHz ist nicht utopisch. Hynix wird die Fertigung im Moment so weit unter Kontrolle haben. Intels Probleme bei der 14nm Fertigung machen mir im Moment deutlich mehr Sorgen. Das bedeutet auch für die anderen nichts gutes.

Ailuros

2015-11-20, 16:37:21

Der Punkt dürfte auf dem Papier wohl noch am einfachsten zu erreichen sein. 4096bit bei 1GHz ist nicht utopisch. Hynix wird die Fertigung im Moment so weit unter Kontrolle haben. Intels Probleme bei der 14nm Fertigung machen mir im Moment deutlich mehr Sorgen. Das bedeutet auch für die anderen nichts gutes.

Es klingt lediglich zu viel Bandbreite auf einen einzigem Schuss, waerend Volta dann nur einen "Bandbreiten-refresh" abbekommen soll? Mir klingen z.B. 800 GB/s fuer Pascal und dann 1200GB/s fuer Volta um einiges logischer.

Sunrise

2015-11-20, 16:48:15

Es klingt lediglich zu viel Bandbreite auf einen einzigem Schuss, waerend Volta dann nur einen "Bandbreiten-refresh" abbekommen soll? Mir klingen z.B. 800 GB/s fuer Pascal und dann 1200GB/s fuer Volta um einiges logischer.
Es ist mir so oder so ein Rätsel, was die ~750MB/s (Pascal) und 900MB/s (Volta) Angaben bei HBM2 darstellen sollen, denn Hynix spezifiziert max. 256MB/s pro Modul für HBM2 bei 1,2V.

Entweder das stellt wirklich eher den internen Bedarf an Bandbreite dar (es ist eine Schätzung, anhand diverser Berechnungen) oder aber NV betreibt die Module nicht bei voller Spannung. Alles andere ergibt für mich keinen Sinn.

Godmode

2015-11-20, 16:48:30

Es klingt lediglich zu viel Bandbreite auf einen einzigem Schuss, waerend Volta dann nur einen "Bandbreiten-refresh" abbekommen soll? Mir klingen z.B. 800 GB/s fuer Pascal und dann 1200GB/s fuer Volta um einiges logischer.

Der Pascal Schriftzug steht ja deutlich unter 1 TB/s, eventuell ist das eine Andeutung. Ich habe den Chart ursprünglich ja so interpretiert, das die "Labels" den Wert darstellen. Das wurder auf B3D zumindest für die bestehenden GPUs widerlegt. Es sieht sehr komisch aus, das die Labels für Pascal und Volta so stark verschoben sind. Keine Ahnung, vielleicht hat das Diagramm auch jemand gemacht, der keine Ahnung hat, oder wahrscheinlich wurde da absichtlich was verschleiert um Verwirrung zu stiften.

Godmode

2015-11-23, 13:10:13

Eine Vermutung von Arun aus dem B3D Forum:

Also I still suspect this is finally the generation where NVIDIA makes a HPC-only chip without a rasteriser. They've already gone in that direction with K80 by making a new chip with a bigger register file etc... The next logical step is to optimise it further by removing 3D-only subsystems, and optimising the flagship 3D GPU by keeping a very low FP64 ratio (and smaller local memory than the HPC chip, and possibly not including NVLink)

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

Das wäre dann wohl die endgültige Trennung von HPC und Gaming. Kann sich jemand von euch vorstellen, dass schon GP100 ohne Rasteriser daherkommt? Das gute wäre, wir würden auch mit Pascal wieder einen hochgezüchteten Gamingchip ala GM200 bekommen, ohne viel DP und HPC Extras.

AffenJack

2015-11-23, 13:22:03

Nicht unmöglich, aber im Moment glaube ich da noch nicht so ganz dran. Kann man da nicht noch viel mehr als den rasteriser wegfallen lassen, was ist zb mit TMUs? Ich würde mir da einfach eine größere Steigerung als die Angaben auf den Folien bisher vorstellen. Meine Vermutung für diesen schritt war eher Volta, vor allem da der Prozesssprung zu Volta auch nur miserabel sein wird und 10nm kaum Fortschritte bringen soll, aber trotzdem wieder eine fast Verdopplung/W anstehen soll.

Ailuros

2015-11-23, 13:25:28

Es muss nicht unbedingt eine einfache Vermutung sein. Es wuerde mich SEHR ueberraschen wenn er als engineer nicht weiss womit andere IHVs mehr oder weniger kochen. Ausser er will auf nicht auf seine Kollegen ueber ihm nicht hoehren und strickt mal wieder seine albernen Thesen zusammen wie z.B. "hotclocked TMUs" :P

Sonst so toll wie die Idee auf Anhieb klingen mag:

1. 17b und das grosse geleakte package gilt wohl fuer GP100-hypothetisch HPC only?

2. das kleinere package bzw. "GP102" ist dann wohl der gaming only chip, wobei mir aber im relativen Sinn das package zu klein klingt fuer etwas dass wirklich deutlich schneller sein wird als GM200, oder ich verpasse wieder wesentliches.

Nicht unmöglich, aber im Moment glaube ich da noch nicht so ganz dran. Kann man da nicht noch viel mehr als den rasteriser wegfallen lassen, was ist zb mit TMUs? Ich würde mir da einfach eine größere Steigerung als die Angaben auf den Folien bisher vorstellen. Meine Vermutung für diesen schritt war eher Volta, vor allem da der Prozesssprung zu Volta auch nur miserabel sein wird und 10nm kaum Fortschritte bringen soll, aber trotzdem wieder eine fast Verdopplung/W anstehen soll.

Ist 10FF oder jeglicher vergleichbarer Prozess zu beschissen, ist es wahrscheinlicher dass es die IHVs einfach wieder ausfallen lassen. Sonst fuer den raster units, wie viel Platz nehmen die Dinger denn ueberhaupt ein? 5% oder irgend ein anderes einstelliges Prozentual?

Godmode

2015-11-23, 13:29:54

Ich fragte vor ein paar Seiten mal, ob man nicht die TMUs, etc. weglassen kann. Ailuros meinte dann, dass das weglassen von Einheiten im Design sehr viel Arbeit verursacht und nicht trivial ist. Damit sich das auszahlt, muss man wohl wirklich alles weglassen, was nur für 3D relevant ist. (TMUs, Polymorph Engine, Tesselator, Rasterizer, ...)

Ailuros

2015-11-23, 13:31:14

Ich frage vor ein paar Seiten mal, ob man nicht die TMUs, etc. weglassen kann. Ailuros meinte dann, dass das weglassen von Einheiten im Design sehr viel Arbeit verursacht und nicht trivial ist.

Ich lass mich gerne eines besseren belehren, aber da die TMUs in den SMMs stecken klingt es nicht nach einfacher Lego-arbeit wo man die textur-Bausteine einfach herauszieht.

Godmode

2015-11-23, 13:35:42

Ich lass mich gerne eines besseren belehren, aber da die TMUs in den SMMs stecken klingt es nicht nach einfacher Lego-arbeit wo man die textur-Bausteine einfach herauszieht.

Wenn sie das aber bei GP100 von Anfang an geplant gehabt hätten, sollte das doch möglich sein oder nicht? Irgendwann muss man den ersten Schritt machen.

Ailuros

2015-11-23, 13:52:53

Wenn sie das aber bei GP100 von Anfang an geplant gehabt hätten, sollte das doch möglich sein oder nicht? Irgendwann muss man den ersten Schritt machen.

Vielleicht haetten sie die eine quad TMU von jedem SMM entfernt, aber mir macht die Geschichte generell von vorne bis hinten keinen Sinn. Wieso braucht man ganze 17 Mrd. Transistoren fuer eine HPC only Schleuder wenn Intel beim KNL mit "nur" 7.1-8 Mrd. auskommt? Ausser natuerlich GP102 bzw. das kleinere package ist die HPC only Schleuder und GP100 ein "3D mostly" GM200 Nachfolger?

Hübie

2015-11-23, 13:59:15

Die TMUs kannst du sogar im HPC für Transformationen (Koordinatensystem...) nutzen. Was gemeint ist, wären wohl eher ROPs und ein paar Sachen am Frontend, was du weglassen kannst. Und ja es wäre durchaus an der Zeit die beiden Wege langsam zu trennen. Ob es sich kostenmäßig amortisieren wird, kann ich natürlich nicht sagen, aber manchmal muss man eben bewusst Miese machen um den return of Investments auch, in diesem Falle für Volta, vom Start weg zu erhalten. Vielleicht sammelt man jetzt Erfahrungen damit und macht dann für Volta eben dass passende Produkt daraus.

ROPs sind ja auch von den Multiprozessoren entkoppelt. Die von Arun angesprochenen Punkte hatte ich ja schon im HWL vorgetragen, wo dann ein paar Tr0lle meinten es stets besser zu wissen :rolleyes: Ich gehe jedenfalls mit seinen Vermutungen konform.

Godmode

2015-11-23, 14:04:19

Vielleicht haetten sie die eine quad TMU von jedem SMM entfernt, aber mir macht die Geschichte generell von vorne bis hinten keinen Sinn. Wieso braucht man ganze 17 Mrd. Transistoren fuer eine HPC only Schleuder wenn Intel beim KNL mit "nur" 7.1-8 Mrd. auskommt? Ausser natuerlich GP102 bzw. das kleinere package ist die HPC only Schleuder und GP100 ein "3D mostly" GM200 Nachfolger?

Wenn man sich die mögliche SP Anzahl von GP100 überlegt, dazu deutlich größere Caches und Registerfiles, und natürlich das NVLink Interface, kommt schon ordentlich was zusammen. Und vielleicht wird der Chip ja dieses mal wirklich extrem Breit um eben auch mit AMD mithalten zu können, was die Rechenleistung angeht.

Die TMUs kannst du sogar im HPC für Transformationen (Koordinatensystem...) nutzen. Was gemeint ist, wären wohl eher ROPs und ein paar Sachen am Frontend, was du weglassen kannst. Und ja es wäre durchaus an der Zeit die beiden Wege langsam zu trennen. Ob es sich kostenmäßig amortisieren wird, kann ich natürlich nicht sagen, aber manchmal muss man eben bewusst Miese machen um den return of Investments auch, in diesem Falle für Volta, vom Start weg zu erhalten. Vielleicht sammelt man jetzt Erfahrungen damit und macht dann für Volta eben dass passende Produkt daraus.

ROPs sind ja auch von den Multiprozessoren entkoppelt. Die von Arun angesprochenen Punkte hatte ich ja schon im HWL vorgetragen, wo dann ein paar Tr0lle meinten es stets besser zu wissen :rolleyes: Ich gehe jedenfalls mit seinen Vermutungen konform.

Die Verschaltung müsste dadurch wohl auch etwas einfacher werden.

Wusste nicht das im Hardwareluxx solche Sachen diskutiert werden, aber es würde mich nicht wundern, wenn man dort getrollt wird. ^^

Edit: Gerade den Thread dazu gelesen und die ganze Zeit OMFG denken müssen.

HOT

2015-11-23, 15:31:54

Also zusammengefasst:
GP100 = reiner HPC-Chip, erst als NVLink-Modul, später evtl. PEG (Tesla), Xeon Phi-Konkurrent
GP102 = mit ähnlichen Specs reiner Gaming-Chip mit eigener Maske ohne groß DP+NVLink als neue Titan
GV100 = wieder reiner HPC-Chip?

Ailuros

2015-11-23, 21:15:19

Wenn man sich die mögliche SP Anzahl von GP100 überlegt, dazu deutlich größere Caches und Registerfiles, und natürlich das NVLink Interface, kommt schon ordentlich was zusammen. Und vielleicht wird der Chip ja dieses mal wirklich extrem Breit um eben auch mit AMD mithalten zu können, was die Rechenleistung angeht.

Ja momentchen....und der hypothetische "3D chip" ist dann wie gross genau? 12 -13Mrd. Transistoren? Klingt nicht besonders ueberzeugend.

reaperrr

2015-11-24, 04:07:44

Ja momentchen....und der hypothetische "3D chip" ist dann wie gross genau? 12 -13Mrd. Transistoren? Klingt nicht besonders ueberzeugend.
GM204 x 2 (mit 2048 bit HBM2 statt breiterem GDDR5 SI) wären wohl "nur" ~10Mrd. Transistoren.

Ailuros

2015-11-24, 06:38:35

GM204 x 2 (mit 2048 bit HBM2 statt breiterem GDDR5 SI) wären wohl "nur" ~10Mrd. Transistoren.

Das waere ein guter Nachfolger fuer GM204 sprich "GP104". Ich frage ueber den angeblichen high end/3D chip der hypothetisch GM200 folgen wuerde.

Hübie

2015-11-24, 07:12:52

GM204 x 2 (mit 2048 bit HBM2 statt breiterem GDDR5 SI) wären wohl "nur" ~10Mrd. Transistoren.

Und ziemlich genau 300 sqmm (etwas darunter).

Godmode

2015-11-24, 09:43:50

Ja momentchen....und der hypothetische "3D chip" ist dann wie gross genau? 12 -13Mrd. Transistoren? Klingt nicht besonders ueberzeugend.

Entweder nur 12-13 Mrd. oder eben ein verdoppelter GM200 mit 14-16 Mrd. Was klingt den nicht überzeugend, dass er so wenige Transistoren hätte?

Ailuros

2015-11-24, 09:54:26

Entweder nur 12-13 Mrd. oder eben ein verdoppelter GM200 mit 14-16 Mrd. Was klingt den nicht überzeugend, dass er so wenige Transistoren hätte?

Es schwirrten zwei packages bei Zauba rum; ein grosses (welches wohl der 17b chip) und ein kleineres. Das letzte klingt mir zu klein fuer 14-16b und da es keine radikalere Aenderungen in den Pascal ALUs geben wird, klingt es nicht unbedingt danach dass es einen groesseren Leistungs-abstand haben wird zu GM200 als bei GM200 vs. GK110. Bei einer relativ aehnlichen Architektur koennen wohl schwer z.B. 50% mehr Transistoren bedeutend Mehrleistung als +50% bedeuten.

Godmode

2015-11-24, 10:00:17

Es schwirrten zwei packages bei Zauba rum; ein grosses (welches wohl der 17b chip) und ein kleineres. Das letzte klingt mir zu klein fuer 14-16b und da es keine radikalere Aenderungen in den Pascal ALUs geben wird, klingt es nicht unbedingt danach dass es einen groesseren Leistungs-abstand haben wird zu GM200 als bei GM200 vs. GK110. Bei einer relativ aehnlichen Architektur koennen wohl schwer z.B. 50% mehr Transistoren bedeutend Mehrleistung als +50% bedeuten.

Ich gehe ja davon aus, dass wir zuerst GP104 sehen, damit sollte das Jahr 2016 gut zu überbrücken sein. Vielleicht gehört dieses kleine Package ja zu GP104. Das Ding könnte etwa soviele SPs wie ein GM200 haben, aber dafür mehr Takt. GP102 können sie dann im Jahr 2017 bringen. Somit würde die aktuelle Produktstrategie konsequent weitergeführt werden. An den Bilanzen sieht man ja, dass diese Strategie perfekt funktioniert.

Ailuros

2015-11-24, 10:08:55

Ich gehe ja davon aus, dass wir zuerst GP104 sehen, damit sollte das Jahr 2016 gut zu überbrücken sein. Vielleicht gehört dieses kleine Package ja zu GP104. Das Ding könnte etwa soviele SPs wie ein GM200 haben, aber dafür mehr Takt. GP102 können sie dann im Jahr 2017 bringen. Somit würde die aktuelle Produktstrategie konsequent weitergeführt werden. An den Bilanzen sieht man ja, dass diese Strategie perfekt funktioniert.

Durchaus logische These; nur an mehr Takt glaube ich zugegeben nicht. Somit hat man wieder eine schoen niedrige "TDP" zum vermarkten und die Hersteller koennen froehlich weiterhin uebertakten.

***edit: haetten sie zumindest Parker vorgestellt haetten wir schon die ersten Indizien was sie eventuell unter 16FF+ anstellen koennten. Bei einfach mehr clusters aber die gleiche/vergleichbare 1GHz Frequenz fuer GP10B waere es schon mal eine Indizie wie es unter 16FF+ aussehen koennte.

Godmode

2015-11-24, 10:50:14

Durchaus logische These; nur an mehr Takt glaube ich zugegeben nicht. Somit hat man wieder eine schoen niedrige "TDP" zum vermarkten und die Hersteller koennen froehlich weiterhin uebertakten.

***edit: haetten sie zumindest Parker vorgestellt haetten wir schon die ersten Indizien was sie eventuell unter 16FF+ anstellen koennten. Bei einfach mehr clusters aber die gleiche/vergleichbare 1GHz Frequenz fuer GP10B waere es schon mal eine Indizie wie es unter 16FF+ aussehen koennte.

Von mir aus wird das Ding auch breiter, Platz haben sie ja dank 16nmFF+ genug. Wichtig ist nur, dass man Leistungstechnisch einen gewissen Prozentsatz auf GM200 drauflegt, damit man die alten Titan X und GTX 980 Ti Käufer nochmal zur Kasse bieten kann.

HOT

2015-11-24, 12:24:31

Godmode

2015-11-24, 13:06:49

Das kleine Package war zu klein für GP104. Das wird irgendein ARM-Gedöns oder ein I/O-Chip für NV-Link sein, das ist meine Vermutung. Gibts abseits dessen überhaupt irgendeinen Hinweis auf andere Chips bis auf den GP100?

Ok, ich habe nicht mehr im Kopf wie groß das Ding wirklich war.

Hinweise gibt es nicht wirklich, nur einen Eintrag im Treiber über neue Cuda Compute Fähigkeiten. Bei der Pascal Architektur wird es davon drei verschiedene geben. Weiters schwirren ein Haufen Codenamen (GP100, GP102, GP104, GP106, GP107, GP10B) herum. Wenn sie die Zauba-Leaks gefixt haben, sehen wir überhaupt nichts mehr. Viele Hinweise der Vergangenheit kamen ja von dieser Import-Datenbank.

Und nochmal zu deiner Vermutung, dass NV 2016 keine Chips für Spieler bringt: Soll dann laut deiner Meinung die gesamte Pascal Familie erst 2017 erscheinen? Bisher war es immer der Fall, dass die Produkte einer Generation über den Zeitraum von etwa zwei Jahren gestreckt wurden. Der einzige Grund der für dich spricht, wäre eine extrem schlechte Ausbeute, wovon man aber bisher nichts gehört hat.

Mandalore

2015-11-24, 13:15:23

Was ist eigentlich so besonders an Volta Ail? Wenn ich mir deine Kommentare durchlese dann scheinst du extrem viel von dem Ding zu erwarten im Gegensatz zu Pascal...

Godmode

2015-11-24, 13:18:45

Was ist eigentlich so besonders an Volta Ail? Wenn ich mir deine Kommentare durchlese dann scheinst du extrem viel von dem Ding zu erwarten im Gegensatz zu Pascal...

Volta wird wieder ein größerer Umbau der Architektur IMHO.

N0Thing

2015-11-24, 13:42:42

Und da Pascal kaum Änderungen gegenüber Maxwell bringen soll, ist Volta natürlich schon automatisch interessanter.

HOT

2015-11-24, 14:37:44

Ok, ich habe nicht mehr im Kopf wie groß das Ding wirklich war.

Hinweise gibt es nicht wirklich, nur einen Eintrag im Treiber über neue Cuda Compute Fähigkeiten. Bei der Pascal Architektur wird es davon drei verschiedene geben. Weiters schwirren ein Haufen Codenamen (GP100, GP102, GP104, GP106, GP107, GP10B) herum. Wenn sie die Zauba-Leaks gefixt haben, sehen wir überhaupt nichts mehr. Viele Hinweise der Vergangenheit kamen ja von dieser Import-Datenbank.

Und nochmal zu deiner Vermutung, dass NV 2016 keine Chips für Spieler bringt: Soll dann laut deiner Meinung die gesamte Pascal Familie erst 2017 erscheinen? Bisher war es immer der Fall, dass die Produkte einer Generation über den Zeitraum von etwa zwei Jahren gestreckt wurden. Der einzige Grund der für dich spricht, wäre eine extrem schlechte Ausbeute, wovon man aber bisher nichts gehört hat.

Die Codenamen werden denke ich tatsächlich zutreffend sein. NV wird sicherlich anders als AMD wieder alles auf die neue Fertigung umstellen, das haben die immer so gehandhabt. Inwieweit Pascal mit Maxwell verwandt ist wird sich zeigen, ich glaube schon, dass man da vor allem im Frontend einiges erneuert haben wird. Meiner Einschätzung nach kann man aber die Shaderanzahlen wohl vergleichen.
Meiner Ansicht nach werden aber gerne einfach die Zeiträume nicht ausreichend betrachtet, die nötig sind, um etwas Neues auf die Beine zu stellen. Es geht ja nicht nur darum, ob TSMC FF+ soweit hat, dass man darauf was produzieren könnte. Es geht ja auch um NVidias Strategie und wann der optimale Zeitpunkt ist, um überhaupt in die neue Fertigung einzusteigen und mit welchem Produkt. Im Gegensatz zu AMD hat NV eine sehr komfortable Situation erreicht, die müssen eben nicht alles übers Knie brechen und das könnte im Nachhinein einiges an Kosten einsparen ohne großartig die Marktchancen zu schmälern. Um den Vergleich zu AMD zu ziehen: AMD hatte die ganzen letzten Jahre einen gewaltigen Kostendruck. Die mussten einsparen, wo es nur geht. Deshalb gibt es auch nur eine 28nm-Generation, das musste halt vorhalten, bis man eine neue Generation in einem FF-Prozess bringen kann. Ich selbst hätte letztes Jahr auch alles darauf verwettet, dass auch AMD in 28nm noch mal alle Register zieht - das kam aber nie. Als absehbar war, dass man verhältnismäßig schnell an einen FF-Prozess kommt, hat man natürlich die knappen Ressourcen komplett da hingeleitet. NV tat genau das nicht. Die sahen in 28nm noch so viel ungenutztes Potenzial, dass sie mit ihren Möglichkeiten eine seht gut darauf angepasste, clevere Architektur geplant hatten. Das hat den riesigen Vorteil, dass man billig bleibt. Natürlich werden sie die Möglichkeiten des FF+(C)-Prozesses komplett ausschöpfen, aber eben nicht schon in 2016. Nur da, wo es wirklich wehtut muss man was machen, deshalb der GP100. Die hatten ganz schlicht und ergreifend für mein Empfinden etwas (im nachhinein eher unbegründete) Panik vor Intels XeonPhi, AMD sehen die doch kaum noch als Konkurrenz im Profibereich. Sicherlich ist NV von Hawaiis DP-Stärke etwas überrumpelt worden, aber AMD bietet dennoch einfach nicht die Softwarebasis um bei den "Großen" mitzuspielen. Die versuchen jetzt erst mal mit Greenland und der Boltzmann-Initiative überhaupt da hineinzukommen.
Ganz nebenbei kann NV mit dem GP100 Erfahrungen sammeln, die sich bei den Grafikchips dann auszahlen werden. Gut Ding will Weile haben.

Troyan

2015-11-24, 14:46:10

Maxwell wurde im Februar 2014 eingeführt. 2 Jahre bevor wir überhaupt 16nm Produkte sehen werden.
Maxwell v2 ist dann auch nur noch eine leicht verbesserte Varianten von der Grundarchitektur.

nVidia wird 16nm flächendeckend verwenden. Darüber muss man sich doch überhaupt unterhalten. Und die werden es wie in den letzten Jahren zeitnah zu AMD machen.

Godmode

2015-11-24, 14:47:33

@Hot:
Wir können beide können ja wetten. Ich sehe GP104 im Jahr 2016 irgendwo zwischen Mai und Oktober.

Agent117

2015-11-24, 15:05:34

Es schwirrten zwei packages bei Zauba rum; ein grosses (welches wohl der 17b chip) und ein kleineres. Das letzte klingt mir zu klein fuer 14-16b und da es keine radikalere Aenderungen in den Pascal ALUs geben wird, klingt es nicht unbedingt danach dass es einen groesseren Leistungs-abstand haben wird zu GM200 als bei GM200 vs. GK110. Bei einer relativ aehnlichen Architektur koennen wohl schwer z.B. 50% mehr Transistoren bedeutend Mehrleistung als +50% bedeuten.

Das kleine wird das GP104 Package, den würde ich auf 9-11 Mrd Transistoren schätzen dann könnte das hinhauen.
Bleibt Nvidia ihrer bisherigen Strategie treu, bringen sie erst GP104 sobald die Yields das für einen ca. 300mm² Chip zulassen und dann ca. ein halbes Jahr später den größeren GP102.
Etwa so: GM200-->GP104 in Q3 16--> GP102 in Q1 17
Also ähnlich zu Maxwell nur 2 Jahre später.
Das Package von GP102 kursiert dann vlt einfach noch nicht bei Zauba.

HOT

2015-11-24, 15:55:05

Wieviel Pins hatte das Teil? 1000? Das ist kein GP104, definitiv nicht. Fiji hat trotz HBM weit über 2k, GP100 über 2,5k.
1k könnte höchstens für einen GP107 oder sowas low-End-mäßiges reichen. Das wird aber was ganz anderes sein. War nicht auch der Preis extrem niedrig? Wovon träumt ihr eigentlich nachts? :freak:

@Hot:
Wir können beide können ja wetten. Ich sehe GP104 im Jahr 2016 irgendwo zwischen Mai und Oktober.
Ich halte es einfach nur für total unrealistisch, das ist alles.

Maxwell wurde im Februar 2014 eingeführt. 2 Jahre bevor wir überhaupt 16nm Produkte sehen werden.
Maxwell v2 ist dann auch nur noch eine leicht verbesserte Varianten von der Grundarchitektur.

Maxwell 2 gibts seit Ende 2014, GM200 seit Frühjahr und GM206 seit noch später. Die Chips sind nagelneu! GK110 war über 2 Jahre das Top-Produkt, GF100 (mit Umweg über GF110) ebenfalls. Bleibt doch mal auf dem Teppich. Es geht nicht immer schneller, es geht immer langsamer.

nVidia wird 16nm flächendeckend verwenden. Darüber muss man sich doch überhaupt unterhalten. Und die werden es wie in den letzten Jahren zeitnah zu AMD machen.
Das würd ich nie abstreiten, traditionell verwendet NV immer den neuesten Prozess, selbst für alte Technik.

Lasst doch mal gemütlich NV den GP100 fertigstellen und Intel auf dem Profimarkt mal ein bisschen Angst machen, man kann dann bis Ende 2016 oder Anfang 2017 gemütlich auf einen voll ausgereiften, gut durchdachten GP104 warten, oder etwas früher, wenn man es ganz eilig hat, einen AMD Greenland kaufen, der wird ja das Gegenstück dazu sein.

Ailuros

2015-11-25, 10:12:51

Und da Pascal kaum Änderungen gegenüber Maxwell bringen soll, ist Volta natürlich schon automatisch interessanter.

Nicht wenn 10FF wieder im Arsch ist; wir haben noch eine geraume Zeit bis zu Volta.

Aber wenn wir schon dabei sind: http://cdn.wccftech.com/wp-content/uploads/2015/11/NVIDIA-HBM-Memory-Crisis.jpg jetzt verstehe ich endlich warum die peak Bandbreite auf Volta so relativ gering ausfallen wird. Von wegen HBM als Heilmittel fuer alles. Wenn NV nicht schon ab Pacal die HPC only chips abkapselt dann wird es so oder so nicht mehr allzu lange dauern.

Godmode

2015-11-25, 10:43:27

Das sieht ja übel aus. Andererseits, brauchen wir fürs Gaming wohl kaum 2 TB/s in nächster Zeit.

Ailuros

2015-11-25, 10:48:37

Das sieht ja übel aus. Andererseits, brauchen wir fürs Gaming wohl kaum 2 TB/s in nächster Zeit.

Nein aber ab Volta dann schon, sie koennen ja nicht ewig unter 2 TB/s herumtuemmeln waehrend sich die DP Raten mit jeder Generation zumindest verdoppeln. Das heisst aber dann schon dass von einem Punkt ab nur noch dedizierte HPC chips Sinn machen koennen und je frueher sie damit anfangen desto besser.

Hübie

2015-11-25, 10:51:43

Wieviel Pins hatte das Teil? 1000? Das ist kein GP104, definitiv nicht. Fiji hat trotz HBM weit über 2k, GP100 über 2,5k.

Moment. Interposer oder Die?

Godmode

2015-11-25, 10:55:36

Nein aber ab Volta dann schon, sie koennen ja nicht ewig unter 2 TB/s herumtuemmeln waehrend sich die DP Raten mit jeder Generation zumindest verdoppeln. Das heisst aber dann schon dass von einem Punkt ab nur noch dedizierte HPC chips Sinn machen koennen und je frueher sie damit anfangen desto besser.

Was sagt den die Spalte HBM2 eigentlich aus in dem Chart? Man könnte es so deuten, das 8 HBM2 Stacks doppelt soviel Strom verbrauchen wie 4. Oder meinst soll das bei HBM2 2 TB/s schneller HBM2 Speicher sein?

Ich gehe schon davon aus, dass auch dieser Speicher weiterentwickelt wird, vor allem was Stromverbrauch und Kapazität angeht.

Sunrise

2015-11-25, 13:55:21

Der Chart zeigt uns doch lediglich die Grenzen von aktuellem HBM2 bzw. einen um 50% verbessertem HBM2 (sprich, bessere Effizienz), z.b. auf einem neuen Prozess und/oder neuer Iteration von HBM anhand der HBM2-Grunddaten. Nur eine Hochrechnung.

Natürlich ist HBM2 auch irgendwann am Ende, aber das ist doch völlig normal. Dann gibt es eben "besserem" HBM oder etwas anderes, wenn 2 TB/s wirklich nötig sind.

Bisher haben wir noch keine GPU-Architektur gesehen, die das annähernd benötigt. Sowas kommt erst deutlich nach Volta.

Man darf ja nicht vergessen, dass die Einheiten der GPU dafür auch mitwachsen müssen, entweder in Form der Komplexität oder der Anzahl. Da benötigen wir sowieso kleinere Strukturgrößen.

Abseits davon kann ich ein paar Angaben auf dem Chart nicht nachvollziehen, denn der Unterschied von GDDR5 zu HBM sieht mir etwas zu klein aus, aber nun gut, NV sollte da schon (hoffentlich) reale Angaben benutzt haben.

Ailuros

2015-11-25, 16:27:21

Der Zweck ist wohl zu zeigen dass Prozesse nicht das einzige Problem der absehbaren Zukunft sein werden. Die Meldung dahinter bleibt gleich: IHVs muessen sich dieser neuen Realitaet dementsprechend anpassen.

Sonst fuer Volta spezifisch, angenommen sie brauchen wirklich fuer Pascal und eine 24/12/4 TFLOP Kombination 1 TB/s Bandbreite. Wenn jetzt angenommen Volta bei 7 TFLOP DP liegt dann sind "nur" 20% mehr Bandbreite eine zu bescheidene Steigerung, oder natuerlich um 180 Grad gedreht Pascal hat eine Unmenge zu viel Bandbreite.

Hübie

2015-11-25, 16:53:52

Nur mal zum Vergleich: Wissenschaftler hatten mal etwa hochgerechnet was unsere Augen an "Daten" verarbeiten. Ins binäre System umgerechnet waren das etwa ~9 Terabyte pro Bild und man sagt ja dass wir etwa 20-35 Hz "Abtastfrequenz" haben. Also ist es definitiv noch ein weiter weg bis zur äquivalenten Darstellung unserer Wahrnehmung.
Bis dahin wird das Problem der Bandbreite auch stets bestehen bleiben. :D

Nakai

2015-11-25, 18:29:24

Godmode

2015-11-25, 18:45:36

Im b3d wird gerade eine geleakte Slide bzgl Gp100 diskutiert. Wenn es 1:2:4 Verhältnis gibt, was die Solide erwähnt, und 4 TFlops DP angepeilt sind, dann kann jeder sich ausmalen, wie GP100 aussehen kann.

Neuer Tipp: Man verbaut nur splitbare FP64 units. Wären bei 4TFlops DP 4000 SPs, also 2000 DP-SPs, splitbar nach obigen Verhältnis.

Ziemlich langweile SP Leistung wenn das so kommt. Ich bleibe bei 1:3 DP:SP, mit dezidierten FP64 Units. Die FP32 Einheiten sind dann teilbar in 2xFP16.

Nakai

2015-11-25, 19:31:21

Mhh war nur ein Fallbeispiel. Solche MixedPrecision FP64 units sind teurer als standard FP units und verbrauchen auch mehr Energie. Ein Grund andere Sachen rauszuschmeisen.

N0Thing

2015-11-25, 19:35:24

Wofür stehen denn die Zahlen in den grünen Kästchen bei der Nvidia Folie (http://www.donotlink.com/hgqq)?

Godmode

2015-11-25, 19:39:25

Wofür stehen denn die Zahlen in den grünen Kästchen bei der Nvidia Folie (http://www.donotlink.com/hgqq)?

Das sind die Bits der Floatingpoints Zahlen. Sign, Exponent, Mantisse.

Hier nach IEEE: https://en.wikipedia.org/wiki/IEEE_floating_point

Nakai

2015-11-25, 19:39:59

Aufbau des Zahlenformats: 1 bit Vorzeichen, und dementsprechend Exponent und Mantisse.

€: 2 slow

N0Thing

2015-11-25, 19:41:39

Ah, danke. Da hätt ich auch selber drauf kommen können. :redface:

Hübie

2015-11-25, 19:44:21

Das sind die Bits. Operanden, Parität und State (aber das kann dir wer anders sicher exakter benennen :D).

Edit: Zu lahm :D

Skysnake

2015-11-25, 19:47:43

Naja, schauen wir mal, ob das für nVidia wirklich aufgeht, und die Leute Mixed-Precision so nutzen wie Sie es denken.

Ich seh das eher kritisch. Den Aufwand um zu validieren, das DP nicht nötig ist, wird zumindest aus dem Scientific Umfeld wohl eher die Minderheit betreiben.

Godmode

2015-11-25, 20:02:33

Sie haben ja schon vorgezeigt, wo man zb. FP16 benutzen kann (zB. Weight Update beim Deep-Learning). Wenn ich mit FP16 die vierfache Leistung bekomme, wird man sich schon die Mühe machen und die numerische Stabilität überprüfen. Clusterzeit ist ja meines Wissen nach nicht so einfach zu bekommen. (Proposal, Juri, ...)

Nakai

2015-11-25, 20:34:41

Ja, bei Künstlichen Neuronalen Netzen ist das so eine Sache. Deren Anforderungen an numerische Präzision ist relativ gering, wenn man bedenkt, dass selbst Implementierungen mit fix-point 8bit sogar existieren.

€: Deep CNNs, mit denen sich NV profiliert, sind eh gut für GPGPUs geeignet. Ich denke NV setzt auf ein interessantes Pferd in diesem Bereich.

Skysnake

2015-11-25, 20:41:58

Neuronale Netze sind halt die neue Sau, die durchs Dorf getrieben wird, die da wie du schon sagst relativ unkrtisch sind und überschaubar, das ist aber bei weiten nicht überall der Fall.

Und am Ende kommt es eben darauf an, was dann wirklich Rechenzeit frisst, und da werden CFDs usw deutlich mehr verschlingen als das neuronale netze Geraffel, und genau da ist es eben nicht mehr so schön.

Aber ist doch klar, das man die Sau durchs Dorf treibt, die von den eigenen Ideen möglichst optimal profitiert. Das heist aber noch lange nicht, dass das auch auf andere Bereiche übertragbar ist.

@Rechenzeit:
Ist immer die Frage, ob es Scientific oder Wirtschaft ist. Die Wirtschaft schaut schon sehr genau auf ihre Rechenzeit. Wenn aber irgendwas aus der Forschung kommt, und irgend nen Doktorand da was antwickelt, dann ist Rechenzeit erstmal ein untergeordnetes Problem. Die Wird ja eh beantragt irgendwann mal, und dann gewährt, und was man damit macht ist ja wurscht. Zudem ist da einfach keine Manpower da um sich um solchen Firlefanz gedanken zu machen.

Selbst bei so manchen Arbeitsgruppen wird man sich um so was als letztes kümmern.

Wo es wirklich sich lohnt ist, wenn man weiß, dass das Ding einfach x Millionen Corestunden verballert. Dann hat man auch ne Chance, seine Investition wieder rein zu holen. Die Entwickler, die sich so gut mit dem Zeug auskennen verdienen ja zum Glück nicht wirklich schlecht.