AMD/ATI - Navi 1X (7nm, RDNA1, 2019) & Navi 2X (7nm, RDNA2, 2020) [Archiv] - Seite 34

Rampage 2

2020-06-13, 01:22:08

Weil die GDDR6 Spezifikation sagt ein GDDR6 Speichermodul hat 2 Kanäle a 16bit. Und genau deshalb hat ein GDDR6 Speichermodul 2 Kanäle a 16Bit.

Wenn man dort mehr möchte braucht es einen anderen Standard.

z.B. GDDR7 oder vielleicht sogar GDDR6X? :)

Wenn Speicherkanäle beidseitig a 32Bit bestückbar sind und sich dadurch ein 512Bit SI (relativ) einfach realisieren lässt, dann ist das eine gute Alternative, falls HBM aufgrund Kosten und/oder Stückzahlen nicht in Frage kommt und AMD bei 384Bit den Speichercontroller nicht so hoch takten (20+ Gbps) kann, wie Nvidia.:) (siehe mein Kommentar zum Zitat unter diesem Absatz)

Bei 512Bit müsste der Speicher auch nicht so hoch takten, um 1TB/sek. erreichen zu können;)

Leute, es gibt 2GB GDDR6 von Samsung bis 18GT/s. NV hat die als 14GT/s-Chips die von Anfang an auf den Turing-Quadro-Karten verbaut. Das scheint nur bei GDDR6X nicht zu gehen, vielleicht ist der schlicht nicht von Samsung sondern wieder von Micron und die machen halt nur 1GB-Chips.

Und du hältst es weiterhin für ausgeschlossen bzw. traust AMD nicht zu, in dieselbe Richtung wie Nvidia entwickelt zu haben und 18Gbps GDDR6 an einem 384Bit SI realisieren zu können?

Da Unified Shader alles können, könnte die gesamte GPU theoretisch auch Vertex-Berechnungen machen. Diese Größe ist also heutzutage ziemlich irrelevant. Wichtiger ist da schon eher, wie schnell die Dreiecke verrastert werden können. Wobei RDNA da ziemlich gut sein könnte, denn im Gegensatz zu Vega ist RDNA auch in 1080p schon schnell und scheint Richtung 4K eher Boden gegenüber Turing zu verlieren (das war bei GCN noch andersrum).

Trotzdem wüsste ich gerne, nach welcher Formel das theoretische Maximum an Polygondurchsatz berechnet wird - also wenn spaßeshalber sämtliche Recheneinheiten der GPU nur Vertex-Operationen durchführen.:)

Vor ein paar Jahren hatte mal Jemand ein Posting von mir kommentiert:

Ich hatte beide GPUs hypothetisch Rechenleistungs-normiert auf 14.336 TFlops kalibriert, also:

1080Ti @ 2 GHz
Vega64 @ 1.75 GHz

Das Kommentar war, dass eine 1080Ti @ 2 GHz 12 GTriangles/sek. schafft, eine Vega64 @ 1.75 GHz aber nur 7 GTriangles/sek. - und dass das, also das schwache Frontend, Eines (!) der maßgeblichen Gründe dafür sei, warum die 1080Ti deutlich schneller als die Vega64 ist; neben der schlechten Effizienz und/oder Auslastung der Recheneinheiten sowie Nichtfunktionieren von bestimmten Features (Primitive Shader, Draw Stream Binning Rasterizer).

R2

Digidi

2020-06-13, 02:37:24

Hier ist ein Test von Navi von Carsten (Heise) der 33% mehr Polygonen Mist wenn man nicht cullt.
https://forum.beyond3d.com/threads/benchmark-tool-like-beyond3d-suite.61013/

Der Rasterizer von Navi ist also sehr gut. Wenn NVIDIA mit 7 kommt und AMD mit 8 Rasterizer könnte das seit Langem die Führung von AMD in Geometrie sein.

Leider macht keine Zeitschrift mehr den Polygonentest mit der Byond3dsuite und seitdem Carsten nicht mehr bei PCgh ist macht der das auch nur noch nebenbei.

Berniyh

2020-06-13, 07:21:15

muss nur irgendwer sein der bei nem boardpartner arbeitet der beide marken anbietet... da wären also MSI, asus udn gigabyte... um nur mal die wichtigsten zu nennen... und jeder von denen hat sicherlich seit wochen schon finale samples.
Von den Super Karten, die angeblich nächstes Jahr kommen? Nun ja …

dargo

2020-06-13, 17:44:00

Natives 4K würde ich bei Konsolen eh für Verschwendung halten.
Es wird sicherlich wie immer laufen. Die ersten Games kommen im nativen 4k und spätere, aufwendigere Spiele gehen dann mit der Auflösung runter.

Grendizer

2020-06-13, 17:56:10

Es wird sicherlich wie immer laufen. Die ersten Games kommen im nativen 4k und spätere, aufwendigere Spiele gehen dann mit der Auflösung runter.

Das AMD für die Konsolen was DLSS mäßiges anbieten kann, können wir ausschließen ?

Nightspider

2020-06-13, 18:44:08

Checkerboard.

Wäre mal interessant wie 5K Checkerboard gegen natives 4K von der Qualität und Performance abschneiden würde. :uponder:

mboeller

2020-06-13, 18:47:39

Das AMD für die Konsolen was DLSS mäßiges anbieten kann, können wir ausschließen ?

RIS ist keine Alternative?

dargo

2020-06-13, 18:53:26

Das AMD für die Konsolen was DLSS mäßiges anbieten kann, können wir ausschließen ?
Ich weiß echt nicht was alle mit ihrem DLSS haben? Sind Artefakte neuerdings "in"? Nichts gegen solche Features wenn sie die Bildqualität nicht sichtbar verschlechtern.

Grendizer

2020-06-13, 18:57:43

Ich weiß echt nicht was alle mit ihrem DLSS haben? Sind Artefakte neuerdings "in"? Nichts gegen solche Features wenn sie die Bildqualität nicht sichtbar verschlechtern.

Ja ... aber der Effekt wird vermutlich geringer ausfallen, als wenn die Auflösung deutlich reduziert werden muss. Dann lieber geringere Auflösung mit vernünftigen AA und Upscaling, als nur die reduzierte Auflösung. Geht ja um die gesamte Lebensspanne der Konsolen. Das sie 5-7 Jahre volles 4K durchhalten werden, das glaubt glaube ich niemand.

dildo4u

2020-06-13, 19:12:53

Microsoft und Nvidia haben Direct ML Upscaling gezeigt, das läuft auf DX12 Ultimate Hardware.

15:30

http://on-demand.gputechconf.com/siggraph/2018/video/sig1814-2-adrian-tsai-gpu-inferencing-directml-and-directx-12.html

robbitop

2020-06-13, 19:15:23

RIS ist "nur" adaptives sharpening.
Checkerboard hat leider oft Bildartefakte in Bewegung und kostet extra Bandbreite für den ID Buffer. Eigentlich gelang es nur Horizon Zero Dawn hier wirklich sehr gute Ergebnisse zu liefern. Viele Studios nutzen lieber temporale Rekonstruktion. Das sieht auch sehr gut aus.

Aber: ML Upsampling wird IMO kommen. Das ist einfach die nächste Stufe des Upsamplings und hat einfach zu viel Potenzial um ignoriert zu werden. Hatte MS nicht für die XSX bereits eine Demo gezeigt?

Nightspider

2020-06-13, 19:33:08

Interessante Technik.

Ob das mit RDNA(2) geht ist aber noch nicht gesichert?

dargo

2020-06-13, 19:45:15

Das sie 5-7 Jahre volles 4K durchhalten werden, das glaubt glaube ich niemand.
Eine nicht native Auflösung auf Konsolen sehe ich nicht als Problem an. Auf Konsole wird hauptsächlich am TV im größeren Abstand gespielt. Dem 08/15 Hans fällt das doch gar nicht auf wenn es keine nativen 4k sind. Zumal auch einige TVs sehr gute Scaler haben.

mironicus

2020-06-13, 19:50:55

Das AMD für die Konsolen was DLSS mäßiges anbieten kann, können wir ausschließen ?

Über RDNA2 wissen wir praktisch so gut wie nichts bis auf die Infos die AMD bis jetzt veröffentlicht hat. Keine Leaks, keine Hinweise auf Raytracing-Geschwindigkeit. Die halten echt dicht. :freak:

Locuza

2020-06-13, 20:04:23

Microsoft hat bestätigt das die XSX-GPU Skalarprodukte für 4x INT8 und 8x INT4 unterstützt (Muss aber der Shadercore machen) und ~380 Millionen Milliarden Intersectionstests pro Sekunden ausführen kann (Das liefern parallel die Intersection-Engines, die laut Andrew Goossen von MS ~13TF wert seien).
Wie weit man damit in der Praxis kommt, die wesentlich komplexer ist, als einfache Nummern für den theoretischen Durchsatz, wird man noch abwarten müssen.
Immerhin gibt es im Vergleich zu Vanilla-Konsolen von Seiten der Hardware Fortschritte in fast jedem Bereich.

Digidi

2020-06-13, 20:58:47

Über RDNA2 wissen wir praktisch so gut wie nichts bis auf die Infos die AMD bis jetzt veröffentlicht hat. Keine Leaks, keine Hinweise auf Raytracing-Geschwindigkeit. Die halten echt dicht. :freak:

Das Lustige ist das wir auch von Nvidia nichts wissen. Siehe auch die Daten was den Theoretisch bei RT bei Nvidia möglich wäre. Auch wurde bei der letzten Generation keine Synthetischen Benchmarks gemacht.

Es macht eigentlich keiner mehr Synthetische Benchmark das ist erschrenkend.

BoMbY

2020-06-13, 21:28:54

Über RDNA2 wissen wir praktisch so gut wie nichts bis auf die Infos die AMD bis jetzt veröffentlicht hat. Keine Leaks, keine Hinweise auf Raytracing-Geschwindigkeit. Die halten echt dicht. :freak:

Viele Lücken wurden geschlossen, und Test-Samples werden vermutlich erst ab Juli im größeren Umfang verteilt, wenn das Release wirklich im September sein sollte.

Gipsel

2020-06-14, 09:33:44

Microsoft hat bestätigt das die XSX-GPU Skalarprodukte für 4x INT8 und 8x INT4 unterstützt (Muss aber der Shadercore machen) und ~380 Millionen Intersectionstests pro Sekunden ausführen kann (Das liefern parallel die Intersection-Engines, die laut Andrew Goossen von MS ~13TF wert seien).Du meinst 380 Milliarden pro Sekunde.
Mit der unklaren Performance in der Praxis hast Du aber recht, weil nämlich viel mehr zu guter Performance gehört, als nur der Maximaldurchsatz der Intersection-Engines.

Nazar

2020-06-14, 13:44:01

Gestern wurde ja ein wenig PS5 Gameplay gezeigt. Der Anteil von RT kann man da mit der Lupe suchen. Mal schauen, wie die RT Fähigkeiten bei einer Bignavi sein werden.

Ich werde weiterhin diesne Hype um RT nicht verstehen können.
99,99% aller Konslenspieler werden eh nicht erkennen könnten ob und wenn ja, was gerade mit RT "bearbeitet" wurde!
Auch die Anzahl der Spiele die RT einsetzen ist in der Gänze eher im Promillebereich zu finden. Und wenn dann RT da ist, können die meisten Spieler während des Spielens überhaupt nicht sagen, was ist RT und was nicht.
Wenn RT die Performance wenigstens verbesser nwürde.. aber ne.
Es ist so, als ob man seiner Karre ultra fette Reifen, ein "geil" aussehendes Spoilerkit verpasst, was aber niemanden während der Fahrt auf der Autobahn auffällt und schon gar nicht dem Fahrer, aber die Beschleunigung (Bildschärfe entfernter Objekte ist deutlich schlechter als ohne RT) und die Höchstgeschwindigkeit (FPS brechen massiv ein, ohne das die Spieler wirklich ein mehr an wahrnehmbarer Optik bekommen) um 40% senkt und nur auf dem Parkplaltz (Screenshots) fällt auf, was da überhaupt an optischen "Verbesserungen" gemacht wurde. Und meist ist diese optische Verbesserungen mit vielen optischen Verschlechterungen erkauft.
Was ist so geil daran, rein keinen Vorteil beim Spielen zu haben, im Gegensatz zu z.B, AA oder AF, was jedem auch während des spielens auffällt, und die Performance auch noch stärker drückt als diese wirklich positiven Effekte? :confused:

Es gibt immer noch Spiele die vor allen Rohleistung brauchen und die auch in Zukunft kein RT anbieten können und auch für VR ist das ein Schuss in den Ofen.
Was eine Verschwendung von Leistung, ein RT einzusetzen, was in der Gänze nur kostet und nur Ultranerds, wenn überhaupt, je auffallen wird.
Und wenn man dann noch sieht, was die neuen Engines gerade im Bereich Lichtberechnungen leisten können werden und das ohne RT als Fremdkörper und Leistungsfresser, dann verstehe ich es immer weiniger. :rolleyes:

RLZ

2020-06-14, 13:58:27

Ich werde weiterhin diesne Hype um RT nicht verstehen können.
99,99% aller Konslenspieler werden eh nicht erkennen könnten ob und wenn ja, was gerade mit RT "bearbeitet" wurde!
Genauso viele können nicht sagen, ob man "echte" 4K verwendet oder ob da nun vernünftiges AF verwendet wird. Des Maßstab legt man besser nicht an. :freak:

pixeljetstream

2020-06-14, 14:08:07

nazar definiere doch mal welche Teile der typischen Hardware Units unter „Rohleistung“ für dich laufen, die bei Raytracing nicht relevant sind. Aber ich wiederhole mich wie ne alte Schallplatte, Zeit für ne Pause.

Fragman

2020-06-14, 14:45:20

Wenn ich bei Ratchet wieder sehe, das es Lichter gibt, die keine Schatten werfen und Stellen hinter Objekten dann wieder hell sind, weil man nichtmal nen ao gegen lightcheck macht, warum auch immer, dann ist Nazars Aussage schon hinfällig, bevor die next gen Konsolen überhaupt raus sind.

Wieviel zb von der UE5 vom Lighting übrig bleibt, wenn wir mehre Lichtquellen haben, dynamische Vegetation und alles, muss erst noch gezeigt werden. Die aktuelle Demo lief aber schon nur mit 30 Frames. Eigentlich ein Hinweis darauf, das die Hardware an der Grenze ist. Und wie der Kommentar weiter geht, kann man sich in den entsprechenden Threads zusammen suchen, in denen davon geschrieben wird, welche Vorteile RT hat und was es bräuchte, das mit einem reinen Rastirizer hin zu bekommen. Wurde doch alles schon diskutiert. :confused:

Gipsel

2020-06-14, 14:59:45

Wenn ich bei Ratchet wieder sehe, das es Lichter gibt, die keine Schatten werfen und Stellen hinter Objekten dann wieder hell sind, weil man nichtmal nen ao gegen lightcheck macht, warum auch immer,Man sieht auch in den raytraced Reflektionen (ja, die gibt es, sind klar keine screen space reflections) fehlende Objekte, weil man da offenbar ein Teil der Geometrie vergessen hat. Aber die haben ja noch ein paar Monate, um solche Bugs auszuräumen. Final war ja das Gezeigte alles noch nicht und erst jetzt können die Studios wirklich anfangen, auf der finalen Hardware zu arbeiten (was insbesondere bei den neuen Features wichtig sein könnte). ;)

Leonidas

2020-06-15, 07:48:15

Jemand hat also Monate vor dem Launch die kompletten Performance-Werte für alle aufgeführten Karten? Sehr realistisch...

Das ist Asien. Die Performance-Werte sind natürlich eine Spekulation/Hochrechnung auf Basis der HW-Daten. In Asien stört das dann keine Sau, wenn dies nicht extra als "Annahme!" gekennzeichnet wird.

Dumm kommt das nur, wenn das irgendjemand im Westen ohne Mitzudenken für ernst nimmt. So ist es aber nicht gedacht.

robbitop

2020-06-15, 08:08:49

Geschichte wiederholt sich. 2001 wurde das gleiche über frei programmierbarere Pixelshader gesagt. 2004 das gleiche über SM3. Kostet alles zu viele Transistoren und bringt keine Rohleistung.

Heute ein integraler Bestandteil der 3d grafik, den keiner mehr missen will. Das kostet natürlich Transistoren und Performance. Raytracing ist halt der nächste Schritt, die BQ weiter zu steigern. Es dauert halt ein paar Jahre, bis das gut aussieht und die GPUs stark genug sind. Aber irgendwann muss man halt damit anfangen. Da braucht es eben ein wenig Weitblick.

Wie pixeljetstream schon schreibt: RT braucht genau wie andere Teile von 3d grafik Aspekte, anhand der es skaliert. Bandbreite, arithmetischer Durchsatz etc. Beides hängt stark zusammen.

pixeljetstream

2020-06-15, 09:12:07

Imo ist ein Problem, dass viele hier ihre Bewertung auf die einfachen Specs (tflops, Bandbreite, vram...) die man auf der Packung findet runterbrechen.
Das spiegelt aber kaum die Komplexität wider. Nur wenn Marketing sich entscheidet irgendwelche Details zu betonen bei neuer HW, wissen mehr Aussenstehende davon, auch wenn es das vorher auch gab. Zum Beispiel die Cache Verbesserungen bei Volta. Deswegen stehen die aber nicht auf der Packung ;)

Im anderen thread hatte ich paar Screenshots gepostet. Einfach das Mal Leute mehr Metriken sehen. Und das sind ja nur ein Bruchteil davon die wir als Hersteller so auslesen können.

https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12336554#post12336554

Es wäre gehaltvoller jenseits des Fachsimpelns auch Annahmen zu erweitern, hw Design ist ja mehr als die Kenngrößen auf der Packung zu definieren. Aber offensichtlich ist der Unterhaltungswert hier auch so gegeben ;)

mksn7

2020-06-15, 15:11:03

Und das sind ja nur ein Bruchteil davon die wir als Hersteller so auslesen können.

Ist echt der größere Teil der PCs unveröffentlicht? Bei den CPU Herstellern ist ja auch nicht alles dokumentiert, aber das ist gefühlt der kleinere Teil. (Und manchmal auch einfach nur weil sie falsch zählen). Irgendwo machts aber natürlich schon Sinn, weil performance counter auch recht nutzlos sind wenn man nicht genau weiß was sie zählen. Und die Leute messen gerne jeden Müll und ziehen irgendwelche Rückschlüsse draus.

Dino-Fossil

2020-06-15, 15:55:44

Imo ist ein Problem, dass viele hier ihre Bewertung auf die einfachen Specs (tflops, Bandbreite, vram...) die man auf der Packung findet runterbrechen.
Das spiegelt aber kaum die Komplexität wider.

Die meisten von uns sind nun mal nicht mehr als interessierte Laien. Einige wenige haben noch ein bisschen Grundlagen-Hintergrund und nur ein ganz kleiner Bruchteil ist da wirklich tief drin. Also kaum anders zu erwarten von uns Unwissenden. :biggrin:

Aber andererseits dürften so manche hier gerne mehr lesen wollen, wenn die Eingeweihten mal die entsprechenden Hintergründe/Infos/Zusammenhänge raushauen.

Also wenn du (oder auch andere) dich mal in einer ruhigen Minute bemüßigt fühlst, uns ein wenig zu erleuchten und ein-zwei Zeilen (oder auch ein paar mehr) dazu schreibst, denke das würden hier viele gerne lesen. ;)

dildo4u

2020-06-15, 15:56:14

Radeon Pro 5600M mit 8GB HBM 2 fürs Mac Book 16.

https://ir.amd.com/news-releases/news-release-details/new-amd-radeontm-pro-5600m-mobile-gpu-brings-desktop-class

BoMbY

2020-06-15, 15:57:10

Also ist Navi12 ein Navi10 mit HBM2 statt GDDR6.

Edit: Und das läuft mit ca. 1 GHz statt 2 GHz in der 5600M-Variante? Das dürfte relativ wenig Strom ziehen ...

Edit2: Ahh ja, 50W TGP.

dildo4u

2020-06-15, 16:02:49

Klar die 5600M mit GDDR6 zieht über 100 Watt das dürfte zu viel für die Mac Kühlung sein. https://youtu.be/D0CNfjv2tgA?t=383

mironicus

2020-06-15, 17:29:31

Dann muss Apple aber was an ihrer USB-C Stromzufuhr ändern. Die kriegen das zusammen doch niemals mit 100 Watt geregelt. Vielleicht gehen ja 130 Watt wie Dell es schon verwendet.

Geht mal davon aus das diese zusätzliche Aufrüstungs-Option bei Apple mindestens 500 Euro zusätzlich kosten wird, vielleicht sogar mehr.

EDIT: Ich hatte recht, Apple will 700$ Aufpreis für den 5600M. :)

Dampf

2020-06-15, 18:55:47

Hä, warum denn nur 394 GB/s mit HBM2, sollten da nicht viel schnellere Bandbreite möglich sein? Warum denn dann nicht einfach GDDR6 nehmen...

dildo4u

2020-06-15, 19:01:03

Verbraucht zu viel Strom das MacBook verträgt vermutlich gerade so 50 bis 60 Watt für die GPU.

The card has the same Total Graphics Power (TGP) as Radeon Pro 5500M and Radeon Pro 5300M, which is 50W. This is likely why the graphics card is clocked at relatively low frequency.

https://videocardz.com/newz/amd-launches-radeon-pro-5600m-with-navi-12-gpu-featuring-8gb-hbm2-memory

basix

2020-06-15, 19:02:50

Verbraucht zu viel Strom das MacBook verträgt vermutlich gerade so 50 bis 60 Watt für die GPU.

Und der geringe Footprint des Chips + Speicher ist auch ein Faktor ;)

Linmoum

2020-06-15, 19:21:31

https://www.amd.com/en/technologies/rdna-2

Kann da nicht mal AMDs Putzfrau den "Oh Shit"-Knopf drücken und alles relevante für einen Moment leaken? :hammer:

Berniyh

2020-06-15, 19:51:40

Also ist Navi12 ein Navi10 mit HBM2 statt GDDR6.
Das war eigentlich schon länger klar.
Auch die Vermutung als Apple-spezifisches Produkt stand schon im Raum.
Edit: Und das läuft mit ca. 1 GHz statt 2 GHz in der 5600M-Variante? Das dürfte relativ wenig Strom ziehen ...

Edit2: Ahh ja, 50W TGP.
1.1 GHz stand schon länger als Taktrate im Linux Kernel. Das hat schon (bei mir und anderen) für etwas Verwunderung gesorgt. Scheint aber tatsächlich so zu sein, dass es sich um ein low-power Produkt handelt.

Berniyh

2020-06-15, 19:53:09

Hä, warum denn nur 394 GB/s mit HBM2, sollten da nicht viel schnellere Bandbreite möglich sein? Warum denn dann nicht einfach GDDR6 nehmen...
HBM2 ist halt auch stromsparender. Ob es das nun an der Stelle wert ist? Keine Ahnung.
Aber bei Apple Produkten ist nicht immer alles auf Vernunft basiert.

mironicus

2020-06-15, 19:59:44

HBM2 ist halt auch stromsparender. Ob es das nun an der Stelle wert ist? Keine Ahnung.
Aber bei Apple Produkten ist nicht immer alles auf Vernunft basiert.

Diese GPU wird momentan wohl die effizienteste auf dem Markt sein.

Sunrise

2020-06-15, 20:06:11

Nach der News wünscht man sich dann doch wieder HBM bei Big Navi.

Laut AMD, wenn es Sinn ergibt:

1. Maximale Leistung/W zusätzlich zu den schon enormen RDNA2-Verbesserungen
2. Sehr viel Bandbreite ohne Probleme (Big Navi evtl. sogar für den nächsten MacPro-Ausbau)
3. Bei einem 505mm²-Die überhaupt kein Thema

Sollte allerdings NV mit GDDR6X (20Gbps bzw. 21Gbps) und einem 384bit SI dann im Endeffekt billiger und schneller sein, wird AMD etwas auf Marge verzichten müssen, eben ein Halo-Produkt.

Hoffen wirs mal, auch wenn ich nicht so recht daran glaube (wahrscheinlich zu teuer). Wobei NV das Paket sicher auch nicht gerade geschenkt bekommen wird, da sie das mögliche wohl wieder ausreizen.

Schade, dass man nichts Handfestes über beide Seiten weiß, das Warten über den Sommer fällt schwer.

fondness

2020-06-15, 20:18:55

LOL, die machen nur für Apple ein eigenes Design?

Unicous

2020-06-15, 20:28:17

Nicht das erste Mal. Siehe z.B. Pro Vega M.

unl34shed

2020-06-15, 20:31:14

Hoffen wirs mal, auch wenn ich nicht so recht daran glaube (wahrscheinlich zu teuer). Wobei NV das Paket sicher auch nicht gerade geschenkt bekommen wird, da sie das mögliche wohl wieder ausreizen.

Die große Frage ist doch wie teuer GDDR6X (wenn es ihn denn gibt) werden wird. Der wird durch die hohen Taktraten eh schon nicht billig und kommt der nicht von allen 3 RAM Herstellern wird es dem Preis auch nicht helfen.

Im Prinzip könnte Navi21 sogar 4 Stacks HBM2 haben und würde wohl noch weniger Flächer verbrauchen als mit 384bit GDDR6. HBM gibt es mittlerweile wohl auch von SK Hynx und angeblich bekommt man das ganze packaging bei TSMC gemacht, was dem Preis zu gute kommen sollte.

dargo

2020-06-15, 20:33:24

LOL, die machen nur für Apple ein eigenes Design?
Wenn die gesicherten Abnahmestückzahlen zum akzeptablen Preis stimmen warum denn nicht?

fondness

2020-06-15, 20:36:57

Wenn die gesicherten Abnahmestückzahlen zum akzeptablen Preis stimmen warum denn nicht?

Die Stückzahlen scheinen mir dafür viel zu klein. Die GPU ist nur optional und Apple verlangt satte $700 Aufpreis. Wer nimmt die bei einem MacbookPro dazu?
Aber vielleicht setzt Apple ja wirklich solche Stückzahlen ab, dass sich das lohnt.

Unicous

2020-06-15, 20:41:16

Es gibt genug Idioten, und vielen Firmen ist es fast schon egal wie teuer Apple ist, Hauptsache Apple.

Apple ist offensichtlich bereit viele, viele Millionen in eine effiziente GPU mit kleinem footprint auf dem Mainboard zu stecken und man sieht am Aufpreis, dass sie auch keine Scham kennen, sich das entsprechend bezahlen zu lassen.

dargo

2020-06-15, 20:41:57

@fondness

Also solche Verträge stelle ich mir folgendermaßen vor... Apple sichert zu im Zeitraum X Y Stückzahlen zum Preis Z zu nehmen. Wenn das sich für AMD wirtschaftlich lohnt passt doch alles. Ob Apple all die Hardware dann los wird kann doch AMD egal sein. Dann hat eben Apple schlecht kalkuliert.

SKYNET

2020-06-15, 20:46:44

Die Stückzahlen scheinen mir dafür viel zu klein. Die GPU ist nur optional und Apple verlangt satte $700 Aufpreis. Wer nimmt die bei einem MacbookPro dazu?
Aber vielleicht setzt Apple ja wirklich solche Stückzahlen ab, dass sich das lohnt.

also alle die ich kenne und die dinge rkaufen, kaufen grundsätzlich in maximal konfiguration...

Berniyh

2020-06-15, 20:48:27

LOL, die machen nur für Apple ein eigenes Design?
Zumindest ist Apple bislang der einzige bekannte Abnehmer.
Aber Apple bekommt ja auch exklusiv den Vollausbau des Navi14 Chips.
Nach der News wünscht man sich dann doch wieder HBM bei Big Navi.

Laut AMD, wenn es Sinn ergibt:

1. Maximale Leistung/W zusätzlich zu den schon enormen RDNA2-Verbesserungen
2. Sehr viel Bandbreite ohne Probleme (Big Navi evtl. sogar für den nächsten MacPro-Ausbau)
3. Bei einem 505mm²-Die überhaupt kein Thema

Sollte allerdings NV mit GDDR6X (20Gbps bzw. 21Gbps) und einem 384bit SI dann im Endeffekt billiger und schneller sein, wird AMD etwas auf Marge verzichten müssen, eben ein Halo-Produkt.

Hoffen wirs mal, auch wenn ich nicht so recht daran glaube (wahrscheinlich zu teuer). Wobei NV das Paket sicher auch nicht gerade geschenkt bekommen wird, da sie das mögliche wohl wieder ausreizen.

Schade, dass man nichts Handfestes über beide Seiten weiß, das Warten über den Sommer fällt schwer.
Ja, würde es mir auch wünschen, dafür würde ich auch etwas draufzahlen.
Ob es nun wirklich (noch) so viel günstiger ist wissen wir natürlich nicht genau. Vermutlich aber schon, sonst würde Nvidia ja auch verstärkt HBM2 einsetzen.

Unicous

2020-06-15, 21:01:04

Ich wette Apple hat zumindest auch einen Teil der Entwicklungskosten bezahlt, egal ob es durch ein Vorauszahlung geschieht oder einen hohen Fixpreis für das Endprodukt.

Das rechnet sich für AMD, zumal sie den HBM vermutlich auch selbst sourcen und dann die Kosten weitergeben.

mironicus

2020-06-15, 21:01:09

Wenn AMD uns lieb hat, dann nehmen sie HBM2e für Navi21, den bis jetzt schnellsten Speicher dieser Art. :)

Das gibt mindestens einen Durchsatz von 1,2 TB/Sekunde.

Kein HBM = kein Halo Produkt.

dargo

2020-06-15, 21:08:07

Kein HBM = kein Halo Produkt.
Ja... sieht man besonders gut an der "Luftpumpe" @Vega VII.

robbitop

2020-06-15, 21:09:56

Wobei das nicht am HBM lag, sondern an der uArch. Mit GDDR5 wäre Vega noch ineffizienter gewesen.

Berniyh

2020-06-15, 21:16:01

Die Stückzahlen scheinen mir dafür viel zu klein. Die GPU ist nur optional und Apple verlangt satte $700 Aufpreis. Wer nimmt die bei einem MacbookPro dazu?
Aber vielleicht setzt Apple ja wirklich solche Stückzahlen ab, dass sich das lohnt.
Wir wissen ja auch nicht, ob das immer so geplant war wie nun umgesetzt.
Evtl. hatte AMD ja mal damit geplant – ggf. mit Apples finanzieller Unterstützung für die Entwicklung – Navi12 mit HBM als Version oberhalb der 5700 XT zu bringen, das dann aber unterlassen, weil zu teuer o.ä.
Ja... sieht man besonders gut an der "Luftpumpe" @Vega VII.
Die VII wurde ja auch nicht für den Desktop gebaut, das war ja mehr ein Verlegenheitsprodukt da Navi10 einfach zu spät kam und man was zur CES brauchte. Sonst hätte es die Karte gar nicht gegeben.
Passender ist da eher das Beispiel Vega 56/64 und da hat HBM2 zumindest schlimmeres verhindert. Hat halt nur leider auch bewirkt, dass man in der Preisgebung etwas limitiert war und – da auch Vega11/12 auf HBM2 basierten – konnte nix auf Basis von Vega im Mid-Range Segment bringen was sich rentiert hätte.
Letzteres ist eigentlich der einzige und wesentliche Bock den sich AMD mit HBM2 eingefangen hat.
Auf Grund des Mining-Murks konnte man ja auch die Vegas für ziemlich gute Preise absetzen und hat da sicher auch einiges an Gewinn gemacht.

BoMbY

2020-06-15, 21:23:39

HBM ist zweifellos die beste Lösung. Vielleicht nicht die günstigste, aber exakte Details dazu sind ja schwer zu bekommen.

Es dürfte auch etwas günstiger werden wenn AMD auf eine ähnliche Lösung wie EMIB setzt (gab ja schon Patente), wonach das Bild von Navi12 auch aussieht. Und zwei HBM2e-Stapel würden ja locker für Navi21 reichen was die Bandbreite angeht. Als Standard-Kühllösung wäre sicher etwas wie der Vega64 AIO zu bevorzugen.

Badesalz

2020-06-15, 21:37:29

dargo

2020-06-15, 21:41:37

@robbitop und Berniyh

Den Sarkasmus in meinen Post echt nicht erkannt? Beim nächsten Mal hänge ich den passenden Smiley dran.

LasterCluster

2020-06-15, 21:47:15

Die Stückzahlen scheinen mir dafür viel zu klein. Die GPU ist nur optional und Apple verlangt satte $700 Aufpreis. Wer nimmt die bei einem MacbookPro dazu?
Aber vielleicht setzt Apple ja wirklich solche Stückzahlen ab, dass sich das lohnt.

Mac Pro? Schau dir dort einfach mal die Preisstaffelung an. Dann kommen dir die 700€ wie ein Preis beim KiK vor.

Berniyh

2020-06-15, 22:00:10

Sie ist doch mit gleicher Wattzahl 30% schneller als eine Vega64 :tongue:
Nichtsdestotrotz, eine Graka die 3.36 Tflops in FP64 macht, ist für mich keine Gamerkarte…

Andererseits hab ich mich schon paar mal gefragt, ob AMD mit den Ansätzen wirklich ineffizient ist oder einfach quasi alle so proggen, daß es auf NV am besten rennt und das eben nicht auf AMD voll rennt.
Wie man das halt schon ewig sagt, daß GCN halt schon Leistung hat(te), es aber nicht auf die Straße bringt...
Du hast die Antwort doch teilweise schon selbst geliefert. Vega hat sehr viel Rohleistung, setzt die aber in Games unzureichend um.
In verschiedenen Mining-Projekten hingegen arbeiten die Teile verdammt gut (z.B. auch in Folding@Home).

Hätte man es für Games besser umsetzen können? Natürlich, aber Marktführer war und ist nun mal Nvidia, welche zudem noch viele Verträge mit Spielestudios haben welche dann spezifisch optimieren.
Dass es zumindest zu einem (größeren) Teil an der Optimierung liegt kann man auch daran erkennen, dass der Rückstand auf eine 2080 (Ti) sehr stark je nach Spieletitel schwankt. Bei manchen (wie z.B. Spielen auf Basis der Unreal Engine) ist es halt ganz übel, bei anderen weniger.

Aber das ist natürlich auch nur an der Oberfläche kratzen. Das Problem ist schon vielschichtiger.
@robbitop und Berniyh

Den Sarkasmus in meinen Post echt nicht erkannt? Beim nächsten Mal hänge ich den passenden Smiley dran.
Nicht sonderlich drauf geachtet.

amdfanuwe

2020-06-15, 22:19:42

unl34shed

2020-06-15, 23:41:55

Was sind die 2 Balken unter den HBM Chips? 2 weitere Chips?
Separate 12nm PCIe 4.0 Phys und sonstiger I/O? Wären dafür aber ziemlich groß.

Spacer damit der Anpressdruck gleichmäßiger ist. der HBM scheint nicht ganz mittig zu sitzen.

Daredevil

2020-06-15, 23:42:59

Irgendwie schon komisch, dass Apple mit sowas um die Ecke kommt und da kein RDNA2 verbaut wird. :[

amdfanuwe

2020-06-16, 00:06:47

Spacer
Danke, hab ich die einfachste Lösung übersehen.

Badesalz

2020-06-16, 00:44:06

Hätte man es für Games besser umsetzen können? Natürlich, aber Marktführer war und ist nun mal Nvidia, welche zudem noch viele Verträge mit Spielestudios haben welche dann spezifisch optimieren.
Dass es zumindest zu einem (größeren) Teil an der Optimierung liegt kann man auch daran erkennen, dass der Rückstand auf eine 2080 (Ti) sehr stark je nach Spieletitel schwankt. Bei manchen (wie z.B. Spielen auf Basis der Unreal Engine) ist es halt ganz übel, bei anderen weniger.

Aber das ist natürlich auch nur an der Oberfläche kratzen. Das Problem ist schon vielschichtiger.Es könnte also auch stimmen (könnte) was ich mir schon letztes Jahr dachte, daß AMD die eigenen Ansätze auch wenn vielleicht besser, nun endgültig aufgab, und die Rechenaufgaben mt RDNA nun sozusagen eher like-NV erledigt, wodurch man auch in den Games besser aufholt?

Bei den paar Sachen wo man besser aufgepasst hat welche Code man auf AMd und welchen auf NV laufen lässt, kloppt sich eine VegaVII schonmal mit eine TitanXP, mal auch mit einer TitanV. Bei ziemlich intensiven Workloads... Und bei nicht weniger intensiven, wird sie plötzlich auch mal verhaut... ;)
Nun. Egal (leider). Der Drops ist halt gelutscht. Interessant aber trotzdem auch, daß hier die Konsolen nicht zogen. Auf denen solls ja meist bestmöglich laufen, in die haben (noch) GCN. Hmm...

B@ndit

2020-06-16, 00:46:24

Schon ein sehr merkwürdiger Chip, mit den 40 CUs. Erinnert mich ein bisschen an Tonga, aus dem man auch nie wirklich schlau geworden ist.

Kann jemand Abschätzen was eine 5700XT bei diesen Taktraten verbraucht?

Klar schwer zu vergleichen, aber gefühlt sollte ein Chip der 1,1GHz bei 50W (inklusive HBM?) macht, 1,5GHz doch unter 150W schaffen oder?

Zumindest für eine mobile Gaming SKU bei 80 bis 100W sollte das Teil ja eigentlich recht interessant sein.

Daredevil

2020-06-16, 00:50:32

Undervolting mit ner 5700xt ( ASIC Werte )
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12051507#post12051507

dargo

2020-06-16, 00:56:56

Kann jemand Abschätzen was eine 5700XT bei diesen Taktraten verbraucht?

Klar schwer zu vergleichen, aber gefühlt sollte ein Chip der 1,1GHz bei 50W (inklusive HBM?) macht, 1,5GHz doch unter 150W schaffen oder?

Wieso abschätzen? :tongue:

5700XT @1,5Ghz (Realtakt 1,46Ghz) und 840mV (Default-Spannungskurve) ergeben hier ziemlich genau 100W im Schnitt GPU-Power (gesamte Karte dann ca. 125W).

Edit:
5700XT @1,1Ghz (Realtakt 1,075Ghz) und 750mV (Default-Spannungskurve) ergeben hier im Schnitt ca. 74W GPU-Power. Nur wäre dieses Setting bei Navi10 ziemlich sinnfrei da die 750mV auch noch bei 1250Mhz anliegen, erst mit höheren Takt steigt die Spannung über 750mV an. In so tiefen Regionen wirst du dann auch nicht mehr so viel Verlustleistung einsparen können. Schließlich "säuft" der Speichercontroller weiter wie Referenz. Bei 1,1Ghz GPU würden der Karte auch 128Bit SI reichen um weiter die Verlustleistung zu drücken. Oder halt 256Bit und deutlich weniger Takt am Speicher sowie Speichercontroller. Je nachdem was effizienter ist.

dildo4u

2020-06-16, 03:53:20

Das Ding könnte deutlich besser Gamen als Nvidias 50 Watt Lösung, die 1650 ti hat nur 4Gb.
Nur wäre es für Windows Systeme viel zu teuer, zum Glück gibt es genug Leute die auf MacOS Programme angewiesen sind.

basix

2020-06-16, 08:22:50

https://pics.computerbase.de/9/3/4/9/9/article-630x354.3dbf7fa1.jpg
Was sind die 2 Balken unter den HBM Chips? 2 weitere Chips?
Separate 12nm PCIe 4.0 Phys und sonstiger I/O? Wären dafür aber ziemlich groß.

Interessant finde ich auch, wie sie den Command Processor und Shader Engine verglichen mit Navi 10 neu angeordnet haben. Sieht für mich deutlich dichter gepackt aus.

mironicus

2020-06-16, 08:43:40

Wohl ein Fake-Leak aber da hat sich jemand schon Mühe gegeben. Nach diesen Daten wäre Raytracing auf Big Navi so schnell, dass es nur minimale Performance-Verluste gibt. Und im Schnitt 31% schneller als eine RTX 2080 Ti.

H8W_0gFzRGk

M4xw0lf

2020-06-16, 09:39:03

:ulol:

amdfanuwe

2020-06-16, 09:43:22

Da stolpert man direkt über die 14GB. Was soll das denn für ein Speicherinterface sein?
7 Speicherkanäle? Salvage Chips wegen Defekt in einem Speicherkanal? So schlechter Yield, das selbst das Top Produkt mit Salvage Chips bestückt wird?
Andererseits könnte der Chip wirklich 7 Speicherkanäle haben um zu garantieren, dass genügend Chips für eine 6800XT/6900 12GB 72CU abfallen. Dürften dann nur wenige Chips übrig bleiben, die nicht verwendet werden können.

mironicus

2020-06-16, 09:57:42

Vielleicht gibt es ja noch eine 16 GB-Variante und die heißt dann 6950 XT. :)

JVC

2020-06-16, 10:11:36

Ich glaube an ne XTX ;)
(die X1950 XTX steht schon ganz vorne im Regal ^^)
Soll ja ein "hallo" Produckt sein ...

M.f.G. JVC

Cyberfries

2020-06-16, 10:18:05

Da stolpert man direkt über die 14GB. Was soll das denn für ein Speicherinterface sein?

Na ist doch logisch: Ein 288bit Speicherinterface, mit 1,5GB Speichersteinen.
Macht 13,5GB, aufgerundet 14GB.

basix

2020-06-16, 10:27:55

Na ist doch logisch: Ein 288bit Speicherinterface, mit 1,5GB Speichersteinen.
Macht 13,5GB, aufgerundet 14GB.

:D Im Prinzip gar nicht so eine schlechte Idee. 288bit ist aber sehr krumm

Langlay

2020-06-16, 10:39:39

Ja wenn dann 448Bit mit 1GB Speicherchips.

Cyberfries

2020-06-16, 10:47:15

An anderer Stelle wurde darüber spekuliert, dass GDDR6X weg von den bekannten
32bit-Speichersteinen geht, hin zu zusammengefassten Einheiten mit z.B. 64 oder 128bit.
288bit wären es bei 3x 96bit.
Realistisch? In keiner Weise.
Die 14GB sind höchstwahrscheinlich ein Tippfehler, alle anderen Optionen, egal ob 448bit nativ,
von 512bit abgespeckt oder gar Salvage-HBM, sind doch zu unwahrscheinlich.

Langlay

2020-06-16, 10:53:51

Naja 448bit nativ würde ich für wahrscheinlicher halten als 512bit nativ. Allerdings ich denke auch es BigNavi wenn dann mit 384Bit kommt oder auch eher weniger wahrscheinlich mit 2 Stacks HBM.

unl34shed

2020-06-16, 19:05:30

N12 ist sehr strange, sollte der "Die Shot" von AMD ansatzweise stimmen...
Hier mal neben N10 gelegt und auf eine gleiche WGP Größe skaliert.

Das Ganze ist um Faktor 10 Skaliert, die Maße also durch 10 teilen für mm.
Basis WGP Größe:
Die Size = 190mm²:
WGP 3,75 = 3,75mm²
L2 6,21 -> 5,635mm²
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=70558&stc=1&d=1592326074

Basis HBM2 Größe:
Die Size = 209mm²:
WGP 3,75 -> 4,25mm²
L2 6,21 -> 6,37mm²
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=70559&stc=1&d=1592326460
Bilder von Techpowerup (https://www.techpowerup.com/gpu-specs/amd-navi-12.g922)

Aber was hat AMD bei N12 den Command Processor gemacht? Wurde der beschnitten oder die Anzahl der ACEs halbiert?
Der IO Bereich scheint auch noch etwas kleiner geworden zu sein.

Wie gesagt, vorausgesetzt das zeigt die eigentliche Chipgröße.

Locuza

2020-06-16, 19:25:06

Das I/O-Zeug passt ungefähr mit dem echtem N10 die shot überein, falls man es etwas in die breite zieht, aber die Innereien der GPU, wie WGPs etc. sind völlig daneben.
https://www.flickr.com/photos/130561288@N04/49411586768/in/dateposted/

Auf der Basis würde ich mich gar nicht bemühen, irgendetwas zu vermessen.

unl34shed

2020-06-16, 19:37:48

Keine Angst, komplett überbewerten werde ich das nicht, vor allem ist die Basis ja eh ein Rendering.

Rampage 2

2020-06-16, 19:46:52

An anderer Stelle wurde darüber spekuliert, dass GDDR6X weg von den bekannten
32bit-Speichersteinen geht, hin zu zusammengefassten Einheiten mit z.B. 64 oder 128bit.

Genau das hatte ich ja ggü. Langlay nahegelegt: dass ein hypothetischer GDDR7 oder jetzt auch GDDR6X (falls er tatsächlich existiert) 64Bit-Speicherkanäle bzw. 2x32Bit-Speicherkanäle (einseitige Bestückung bzw. beidseitige Bestückung/Clamshell-Mode) ermöglicht bzw. ein 512Bit-Interface einfacher zu implementieren ist...

Ich glaube aber auch, dass die 448Bit Salvage sind und der eigentliche Chip 512Bit breit ist...

R2

robbitop

2020-06-16, 20:04:01

Zu GDDR5X gab es schon in 2015 Einträge bei der JEDEC. Pascal kam erst Frühjahr 2016.
Zu GDDR6X gibt es auf der JEDEC Seite gar nichts. Kann gut sein, dass das entweder gar kein richtiger separater Standard ist oder aber die Leaks in der Hinsicht leicht abgefälscht waren.

mczak

2020-06-16, 20:05:04

Der Takt ist schon enorm tief bei der Pro 5600M. Ist ja immer noch dieselbe Architektur, der Spannungs/Frequenzverlauf dürfte da auch nicht wesentlich anders aussehen als bei der 5700. Wahrscheinlich könnte man also auch einen Chip mit weniger CUs bauen mit höherem Takt der praktisch dieselbe Effizienz erreicht.
Aber es würde mich nicht erstaunen wenn man den Chip z.B. auch in einem zukünftigen iMac finden würde mit sagen wir mal 50% höherem Takt und 70% höherer TGP...

Unicous

2020-06-16, 20:34:26

Micron hat GDDR5X doch erst im Nachhinein spezifizieren lassen, ich schätze mal weil Nvidia gemeckert hat, dass sie eine second source für die Chips haben wollen. AMD hat GDDR5X nie genutzt, weil GDDR6 eh schon in Entwicklung war.

Verstehe auch nicht, was das mit dem Releasedatum von Pascal zu tun hat? Dass Pascal GDDR5X von Micron nutzt war offensichtlich von langer Hand geplant bzw. eine Kollaboration beider Unternehmen.

Ob GDDR6X echt ist, wird sich eh noch zeigen. Vielleicht vermarktet Micron auch nur einen speed bump um hype für ihre langweilige und überteuerte Produktsparte zu erzeugen.:freak:

robbitop

2020-06-16, 21:09:40

Na Pascal war die erste gpu die das nutzte und der Standard war lange vorher bekannt. Die Annahme wäre jetzt nicht so weit hergeholt, dass das mit neuen RAM Stamdards auch so ist. Dass die zumindest namentlich auf der jedec bekannt sind bevor Produkte mit dem Dtamdard herauskommen.

Unicous

2020-06-16, 21:25:13

Ein "Standard" den de facto nur eine einzige Firma in ihren Produkten für einen vergleichsweise kurzen Moment genutzt hat. (edit: und von einer einzigen Firma produziert wurde, afaik)

Ich würde mal vermuten, dass Nvidia zu der Zeit noch davon ausging, dass GDDR6 noch eine Weile auf sich warten lässt und deswegen mit Micron diese Partnerschaft einging, aber auch darauf bedacht war nicht von ihnen bis aufs Lebensende abhängig zu sein. Dass diese ausgeweitet wurde kann man ja auch daran sehen, dass Nvidia danach die ersten GDDR6 Chips exklusiv von Micron bezogen hat. Es wurde auch gemunkelt, dass Nvidia dafür ein halbes Jahr exklusiv Microns GDDR6 Chips nutzen konnte.

Wir werden sehen, ob GDDR6X real ist, wer es produziert, wer es nutzt und ob es ein "Standard" wird.:wink:

horn 12

2020-06-16, 22:46:12

https://forums.guru3d.com/threads/amd-big-navi-rx-6900xt-14gb-leak.432840/

30-ter Septemer wäre Typisch zu damaligen Guten AMD GPU Produkten erneut ein Mittwoch
Release was bei Vega und Co immer ein Donnerstag...

Linmoum

2020-06-16, 22:51:07

Der Wochentag wird AMD vollkommen egal sein, davon ab war's bei Navi ein Sonntag.

Daredevil

2020-06-18, 00:46:53

Hier hat wer schon das MacBook mit der 5600M
6HLr9jbx2RI

Die Kiste schlägt knapp die Vega56 im iMac Pro im Unigine Heaven Bench, nur halt unplugged im MacBook Pro. :D
Und das ganze ist schneller, als wenn man ne 5700XT mit nem eGPU Gehäuse ansteckt.

Eldoran

2020-06-18, 05:01:54

Hier hat wer schon das MacBook mit der 5600M
https://youtu.be/6HLr9jbx2RI

Die Kiste schlägt knapp die Vega56 im iMac Pro im Unigine Heaven Bench, nur halt unplugged im MacBook Pro. :D
Und das ganze ist schneller, als wenn man ne 5700XT mit nem eGPU Gehäuse ansteckt.
Bei Apple ist nie so ganz klar, ob da nicht irgendwelche Firmwarehacks etc. dahinter stecken, aber die angegeben Benchmarkwerte erklären auch den Sinn der neuen GPU - bei dem Verbrauch liefert sie zumindest bei den Benchmark Szenarien deutlich mehr Leistung. Bezogen auf die Werte scheint der Aufpreis nicht einmal überzogen, Performance/$ ist eigentlich ganz gut.

dildo4u

2020-06-18, 06:32:41

Hier hat wer schon das MacBook mit der 5600M
https://youtu.be/6HLr9jbx2RI

Die Kiste schlägt knapp die Vega56 im iMac Pro im Unigine Heaven Bench, nur halt unplugged im MacBook Pro. :D
Und das ganze ist schneller, als wenn man ne 5700XT mit nem eGPU Gehäuse ansteckt.
Schätze mal bei Vega gibt es massive Probleme mit dem Treiber oder die GPU ist massiv untertaktet im Mac.
Hab grad mal die Settings im Video gebencht 120 fps mit meiner 1070.(Heaven 4.0)

mironicus

2020-06-18, 09:30:11

Hab grad mal die Settings im Video gebencht 120 fps mit meiner 1070.(Heaven 4.0)

Versuch mal die TDP auf 50 Watt zu begrenzen, dann hast du einen fairen Vergleich.

robbitop

2020-06-18, 10:04:55

Wobei dann die Spannungs/Frequenzkurve sicher noch Optimierungspotenzial hätte.

Daredevil

2020-06-18, 10:17:08

Natürlich ist die Vega im iMac stark gedrosselt, es geht ja um den Vergleich

dildo4u

2020-06-18, 10:22:48

Versuch mal die TDP auf 50 Watt zu begrenzen, dann hast du einen fairen Vergleich.
Ich vermute mal das ist auf Level mit einer 1660 TI Max Q, das scheint der Gegenspieler im Mobile Bereich zu sein.
Technik mit HBM 2 ist cool der Preis ist absurd aber gut für AMD wenn sie was von der Marge mitnehmen.

Daredevil

2020-06-18, 11:02:22

Können Nvidia Karten denn auch "Unplugged" so eine Leistung abrufen?
Mit meiner 1050 in nem Acer Notebook ging das früher nicht. ^^

MasterElwood

2020-06-18, 11:07:21

https://pics.computerbase.de/9/3/4/9/9/article-630x354.3dbf7fa1.jpg
Was sind die 2 Balken unter den HBM Chips? 2 weitere Chips?
Separate 12nm PCIe 4.0 Phys und sonstiger I/O? Wären dafür aber ziemlich groß.

wie man sieht ist das aber eindeutig eine Special Edition NUR für die Xbox :biggrin:

Cyberfries

2020-06-18, 11:54:13

Wilde Spekulation:
Zu Navi 2x sind gerüchteweise Chipgrößen bekannt (505mm², 340mm² & 240mm²).
Die übliche Auflösung lautet, dass diese Chips zu Navi 21, Navi 22 und Navi 23 gehören, mit 80-128CUs auf 505mm².

Nun ist Navi 12 frisch aufgetaucht, mit recht geringen Ausmaßen.
Sofern die Bilder korrekt sind, geht dieser Schwund neben dem Interface zum Großteil auf Kosten von IO und Command Processor.
Die Milchmädchenrechnung eines doppelten Navi 12 ergäbe rund 380mm² für 80CUs.

Versuchsweise etwas genauer spekuliert:
- 35mm² IO
- 2x 15mm² HBM2e Interface
- 10mm² Command Processor
- 80x 3,3mm² je CU
Schon liegen wir bei 339mm² für Navi 21 mit 80CUs und 2xHBM2e - Natürlich nur sofern diese Shrinks machbar sind.

Was ist dann der 505mm² Chip?
- Arcturus?
Nur 340mm² für den größten Chip? Passt das zu AMDs Speerspitze?
- Vega 20 lag bei 331mm². Sofern das für die gewünschte Leistung reicht - warum nicht?
Wie passen die 400Watt zu 340mm²?
- Wenn die 400Watt nicht zu Navi21 gehören, sondern zu Arcturus ergibt das ganze wesentlich mehr Sinn.
Nur 2 HBM Stapel?
- Das erlaubt theoretisch 32GB Speicher und 920 GByte/s, sollte reichen.

Berniyh

2020-06-18, 12:29:24

Die 400W waren einfach nur Quark. War ja aus der Quelle leider zuletzt schon mehrfach so.

Aber ich hab auch schon überlegt, ob man evtl. Navi12 genutzt hat um quasi eine Art Probelauf auf kleiner Flamme für Big Navi zu unternehmen, mit Apple als finanzielles Zugpferd.
Aber so richtig mag ich das nicht glauben.

Die zuletzt genannten 14 GB VRAM kann ich mir auch nicht vorstellen. AMD ist hier generell eher spendabel und ich kann mir wirklich nicht vorstellen, dass man beim zukünftigen Halo Produkt die 16 GB der VII unterbieten wird.
Ne, 16 GB werden das mindestens (und vermutlich auch exakt).

HOT

2020-06-18, 12:44:08

Das Ding hat kein 512 Bit Interface, das ist eh totaler Quatsch. Wenn N12 HBM hat, hat der Dicke auch HBM.

robbitop

2020-06-18, 17:40:11

Die Treiberpatches sagen aber gddr6. Das macht HBM relativ unwahrscheinlich. Bisher waren die Infos aus solchen Treiberpatches iirc immer akurat.

unl34shed

2020-06-18, 17:43:04

Die Stelle im Patch ist aber auch nur ein Emulation Mode, anderen Falls wird es (Memory Type und with) von der Karte gelesen.

Dural

2020-06-18, 17:45:32

Naja 512Bit eigentlich auch.

Locuza

2020-06-18, 17:54:49

Die Stelle im Patch ist aber auch nur ein Emulation Mode, anderen Falls wird es (Memory Type und with) von der Karte gelesen.
Es ist nicht nur ein Patch, es gibt mehrere Codebereiche die nur GDDR6 erwähnen und kein einziges mal HBM bzw. eine allgemeine Liste an Speichertypen.

Berniyh

2020-06-18, 18:05:37

Die Stelle im Patch ist aber auch nur ein Emulation Mode, anderen Falls wird es (Memory Type und with) von der Karte gelesen.
hm, ich hab mir die Patches jetzt nicht so im Detail angeschaut (bzw. ist schon ein bisschen her), aber ich hab das so verstanden, dass es schon um GDDR6 im Allgemeinen ging für Navi2x. Bei der Sache mit dem Emulation Mode ging es darum, dass man zunächst dachte da wäre ein 128 Bit (?) Speicherinterface implementiert, was halt doch arg klein wäre.

Berniyh

2020-06-18, 18:06:56

Es ist nicht nur ein Patch, es gibt mehrere Codebereiche die nur GDDR6 erwähnen und kein einziges mal HBM bzw. eine allgemeine Liste an Speichertypen.
Stimmt, wobei es ja nicht gesagt ist, dass die Patches schon komplett vollständig sind und auch nicht, dass damit explizit Big Navi behandelt wird. Könnte sich ja auch um Navi22/23 handeln und Big Navi kommt erst noch.
Ist jetzt nicht unbedingt extrem wahrscheinlich, aber möglich wäre es. ;)

Insbesondere bei dem ganzen Katz & Maus Spiel was AMD und Nvidia zuletzt immer wieder veranstaltet haben.

unl34shed

2020-06-18, 21:45:33

Es ist nicht nur ein Patch, es gibt mehrere Codebereiche die nur GDDR6 erwähnen und kein einziges mal HBM bzw. eine allgemeine Liste an Speichertypen.

Vielleicht bin ich blind, aber wird das auch an einer anderen stelle als in der if mit "amdgpu_emu_mode == 1" gesetzt?

Und wenn man nach amdgpu_emu_mode sucht, findet man infos dazu, dass es nur für die emulation auf "1" gesetzt wird. (Software emulation oder evtl. FPGA board?)

In den bereichen, in denen amdgpu_emu_mode == 0 ist, steht nichts mehr von GDDR6, da wird es von der Grafikkarte ausgelesen.

Locuza

2020-06-18, 22:27:29

Ja, aber z.B. der atomfirmware header für Sienna Cichlid hat explizit nur GDDR6 Einträge:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next-sienna_cichlid&id=bb7d41201dac9c1c386ce721697d13772c57d1c2

Zum AMDGPU_emu_mode habe ich nur diesen Abschnitt gefunden:
/**
* DOC: emu_mode (int)
* Set value 1 to enable emulation mode. This is only needed when running on an emulator. The default is 0 (disabled).
*/
MODULE_PARM_DESC(emu_mode, "Emulation mode, (1 = enable, 0 = disable)");
module_param_named(emu_mode, amdgpu_emu_mode, int, 0444);
https://elixir.bootlin.com/linux/v4.19/source/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c

Berniyh

2020-06-18, 22:32:06

Navi12 hat an der Stelle den Vorteil für AMD, dass HBM2 für Navi bereits im Treiber implementiert ist.
ggf. ist es eine kleine Änderung (oder gar keine?) notwendig um das zum Laufen zu bekommen?

Berniyh

2020-06-18, 22:43:06

Ja, aber z.B. der atomfirmware header für Sienna Cichlid hat explizit nur GDDR6 Einträge:
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next-sienna_cichlid&id=bb7d41201dac9c1c386ce721697d13772c57d1c2
Und dann schau dir mal den relevanten Teil für Navi1x (v10) an:
struct atom_vram_module_v10 {
// Design Specific Values
uint32_t memory_size; // Total memory size in unit of MB for CONFIG_MEMSIZE zeros
uint32_t channel_enable; // bit vector, each bit indicate specific channel enable or not
uint32_t max_mem_clk; // max memory clock of this memory in unit of 10kHz, =0 means it is not defined
uint16_t reserved[3];
uint16_t mem_voltage; // mem_voltage
uint16_t vram_module_size; // Size of atom_vram_module_v9
uint8_t ext_memory_id; // Current memory module ID
uint8_t memory_type; // enum of atom_dgpu_vram_type
uint8_t channel_num; // Number of mem. channels supported in this module
uint8_t channel_width; // CHANNEL_16BIT/CHANNEL_32BIT/CHANNEL_64BIT
uint8_t density; // _8Mx32, _16Mx32, _16Mx16, _32Mx16
uint8_t tunningset_id; // MC phy registers set per
uint8_t vender_rev_id; // [7:4] Revision, [3:0] Vendor code
uint8_t refreshrate; // [1:0]=RefreshFactor (00=8ms, 01=16ms, 10=32ms,11=64ms)
uint8_t vram_flags;»»···»··· // bit0= bankgroup enable
uint8_t vram_rsd2;»·»···»··· // reserved
uint16_t gddr6_mr10; // gddr6 mode register10 value
uint16_t gddr6_mr1; // gddr6 mode register1 value
uint16_t gddr6_mr2; // gddr6 mode register2 value
uint16_t gddr6_mr7; // gddr6 mode register7 value
char dram_pnstring[20]; // part number end with '0'
};

Trotzdem gibt es einen HBM2 Chip.

Voodoo6000

2020-06-18, 23:04:52

6bN_G4dxJLQ

Locuza

2020-06-19, 00:36:28

Und dann schau dir mal den relevanten Teil für Navi1x (v10) an:
struct atom_vram_module_v10 {
[...]

Trotzdem gibt es einen HBM2 Chip.
Ich bin kurz die Navi12 Patches durchgegangen und dort habe ich jetzt explizit auch nichts gesehen, was den HBM-Support verraten hätte.
Das ist iirc durch eine zweiteilige Kombination klar gewesen, wo im offenen Treiber die Rede von 16 SDP-Interfaces für Navi12 war und dann wurde die Channel-Breite von 128-Bit in einer GPU-Treiber Datei gefunden, was früh den Schluss zu einem HBM-Interface mit 2048-Bit erlaubt hat.

Ich denke zwar nicht das AMD einen potentiell hinters Licht führt, mit GDDR6-Einträgen, die nicht direkt für Sienna Cichlid (Navi21) selber bestimmt sind, sondern für Navi22/23, aber du könntest Recht haben, dass es sich hierbei nicht um einen Schwarz auf Weiß Beweis handelt und man die Tür noch offen halten kann.

Leonidas

2020-06-19, 04:55:11

https://pbs.twimg.com/media/Eaxk01GU4AEy9Dj.jpg

Quelle:
https://twitter.com/KOMACHI_ENSAKA/status/1273503657342849024

PS: Ist wohl schon einige Jahr alt:
https://www.techpowerup.com/forums/threads/hunting-titans-the-amd-new-flagship.211183/

HOT

2020-06-19, 08:03:29

Berniyh

2020-06-19, 08:34:05

Ich bin kurz die Navi12 Patches durchgegangen und dort habe ich jetzt explizit auch nichts gesehen, was den HBM-Support verraten hätte.
Das ist iirc durch eine zweiteilige Kombination klar gewesen, wo im offenen Treiber die Rede von 16 SDP-Interfaces für Navi12 war und dann wurde die Channel-Breite von 128-Bit in einer GPU-Treiber Datei gefunden, was früh den Schluss zu einem HBM-Interface mit 2048-Bit erlaubt hat.
Das war aber nicht im Kernel Treiber, sondern Mesa und pal.
Ist aber inzwischen dort auch wieder verschwunden und die Daten werden aus den FW Dateien ausgelesen.

Edit: generell haben die FW Dateien für AMD den Vorteil, dass es kein Review gibt und keine Deadlines. Die können sie also auch sehr kurzfristig veröffentlichen. Beim Linux Kernel und bei Mesa gibt es halt eine Vorlaufzeit von mindestens 4 Monaten von Veröffentlichung bis Release.
Wer sagt eigentlich, dass Sienna Cichlid N21 sein soll? Kann doch sein, dass damit einer der kleineren Chips gemeint ist.
Ja. Zumindest mir ist auch noch überhaupt nicht klar, ob mit Sienna Cichlid Navi2x allgemein gemeint ist oder einer der einzelnen Chips.
Patches gibt es ja nur zu Sienna Cichlid, aber ich würde erwarten, dass wenn man jetzt Patches veröffentlicht die auch für alle vorzustellendenen Karten valide sind.
ok, könnte natürlich sein, dass die beiden anderen Chips deutlich später kommen.

HOT

2020-06-19, 08:37:26

Lt. AMD selbst startet der Spass schon mit dem Großen und es gibt das komplette Lineup noch dieses Jahr als Mischung aus neuen und alten Chips. Das würd eher dagegen spechen, dass Sienna Cichlid ein einzelner Chip ist, das stimmt schon. Es ist also weiterhin alles offen.

robbitop

2020-06-19, 09:14:56

Ich kann mich noch vaage erinnern, dass es beim letzten Mal (Treiberpatch) auch ähnlich war. Es kann ja theoretisch nicht so kommen etc. Aber genau so kams dann. :D

Berniyh

2020-06-19, 10:13:32

Ich kann mich noch vaage erinnern, dass es beim letzten Mal (Treiberpatch) auch ähnlich war. Es kann ja theoretisch nicht so kommen etc. Aber genau so kams dann. :D
Generell muss man sagen, dass die Sache mit Navi12 + HBM sich extrem lange hingezogen hat.
Die ersten Patches zu dem Chip gab es ja vor ca. einem Jahr. Im Herbst wussten wir zumindest, dass das Speicherinterface ähnlich groß wie bei Navi10 ist, aber, dass HBM2 (wahrscheinlich) zum Einsatz kommt wissen wir erst seit Februar oder so.

Meiner Meinung nach zeigt Navi12 eben recht klar, dass man HBM2 für Big Navi zum aktuellen Zeitpunkt nicht ausschließen kann.
(Damit will ich jetzt nicht sagen, dass es sehr wahrscheinlich ist, aber ausgeschlossen eben auch nicht.)

robbitop

2020-06-19, 10:44:47

Es wäre technisch die mit Abstand beste Wahl. Die Frage ist allerdings, ob dann Verfügbarkeit und Kosten noch passen. Ganz ohne Grund ist das Zeug ja nicht im HPC/Profibereich. Vega64 war ja die letzte Consumer GPU damit. Vega7 war ja wegen der Verzögerung von N10 nochmal als Consumerkarte gebracht und dann auch ganz schnell EOL genommen.
Auch NV setzt das nur im Consumerbereich ein. Trotz Bandbreiten- und Energieeffizienzvorteil.
N12 kostet im Macbook ja richtig Aufpreis und ist dort nötig um in der TDP zu bleiben und verwendet ja auch nur 2x stacks.

Ich würde es auch toll finden - bin aber aus o.g. Gründen sehr skeptisch.

HBM wäre allerdings eine Möglichkeit, nochmal einen auf 80CUs draufzusetzem (ohne dass Bandbreite und TDP so krass limitiert). Mal schauen / ggf überrascht uns AMD ja noch. Die gefühlt deutlich höhere Wahrscheinlichkeit ist IMO aber GDDR6.

Digidi

2020-06-19, 11:37:55

reaperrr

2020-06-19, 11:41:52

Die ersten Patches zu dem Chip gab es ja vor ca. einem Jahr. Im Herbst wussten wir zumindest, dass das Speicherinterface ähnlich groß wie bei Navi10 ist, aber, dass HBM2 (wahrscheinlich) zum Einsatz kommt wissen wir erst seit Februar oder so.
Naja, wer News zu dem Thema relativ aufmerksam verfolgt hat, konnte das schon in November 2019 wissen:
http://www.redgamingtech.com/navi-12-isnt-big-navi-but-instead-navi-10-with-hbm2-rumor/

Ist den Bandbreite überhaupt noch der Flaschenhals. Man hat mitlerweille für alles eine Kompression. Zudem wurde ja das Streaming zwischen Festplatte und Ram GPU verbessert. Ich glaube nicht das wir noch Bandbreitenlimitiert sind.
HBM2(e) würde wenn, dann wegen der Effizienz verbaut, nicht wegen der Bandbreite.
Die 5700 XT ist nicht wirklich bandbreitenlimitiert, also würden ~860-900 GB/s Bandbreite für Big Navi auch reichen, was auch mit 18Gbps @ 384bit GDDR6 oder 14Gbps @ 512bit G6 möglich wäre.

Hauptgrund, warum ich an der Verwendung von HBM2 zweifle sind sowohl die Kosten je GB VRAM als auch die Kosten je GB/s Bandbreite. AMD bräuchte für o.g. Bandbreite entweder den schnellsten (und damit je GB garantiert teuersten) HBM2e @ 2048bit, oder "billigen" 900MHz-HBM2 @ 4096bit. 3072bit ist mit HBM viel schwerer als 384bit mit GDDR6, weil die Chips direkt am Interface sitzen müssen, und du entweder einen genauso großen Interposer wie für 4096bit brauchst, oder den Chip extrem länglich machen musst, um alle HBM-Chips auf eine Seite packen zu können. Beides kostentechnisch suboptimal, deshalb so gut wie ausgeschlossen.

Ein breiteres GDDR6-SI dagegen mag etwas mehr Chipfläche und Strom kosten, aber wenn der Chip dadurch 20$ mehr kostet, du dafür aber 150-200€ weniger Kosten je Karte für Speicher und Packaging/Assembly hast, ist das unterm Strich trotzdem die ökonomisch sinnvollere Variante.

robbitop

2020-06-19, 11:46:56

Ist den Bandbreite überhaupt noch der Flaschenhals. Man hat mitlerweille für alles eine Kompression. Zudem wurde ja das Streaming zwischen Festplatte und Ram GPU verbessert. Ich glaube nicht das wir noch Bandbreitenlimitiert sind.

AMD Könnte mit Ihren 8 Raster Enginges im Gegensatz zu Nvidias 7 einen leichten Vorteil haben die 80 Cus auch wirklich auszulasten. Ich glaube das wir seit jarhen Front End limitiert sind. Gerade bei AMD, weil die Jobs aus dem Frontend nicht gescheit auf die CUs aufgeteilt werden können.
Kompression hat vieles verbessert. Aber zaubern kann man nicht. Gerade der Framebuffer/GBuffer Zugriff ist stark fragmentiert und hoch frequentiert.

Für 80CUs mit >2 GHz braucht man halt grob 2x Bandbreite von N10. Für 384bit wären das dann halt >20GTs. Oder aber man verbaut >384 bit.
Das wird von der Anordnung bei den hohen Taktraten der Speicherbausteine aber schnell schwierig.

Es bleibt in jedem Fall spannend. :)

HOT

2020-06-19, 12:09:37

RT braucht Bandbreite.

Complicated

2020-06-19, 12:25:06

In der aktuellen Situation der verfügbaren Wafer-Mengen bei TSMC, sollte man auch diesen Flaschenhals auf dem Schirm haben. Wenn 50mm² (willkürliche Zahl) weniger Fläche auf dem Die benötigt wird für HBM, könnte AMD besonders bei kleineren GPUs wie Navi12 die Anzahl der Produkte/Wafer erhöhen und auf diese Weise schnell 20-25% Diefläche (spekuliert von mir) einsparen und zeitgleich die Yield verbessern mit den kleineren Dies (weitere 7nm-Waferfläche gespart). Eventuell gab es da einen wirtschaftlichen Faktor in der Konstellation der das sinnvoller erscheinen lies im Gesamtkonzept von AMD. Dieser Faktor würde weniger Einfluß haben je größer der Die ist und dann wieder die mögliche Bandbreite als dominierenden Faktor für die Entscheidung GDDR/HBM in den Vordergrund rücken, sowie die Kosten für Interposer, PCB, Packaging und Speicher.

In 28nm war ein 1024-SI für HBM ungefähr grob so groß wie ein 64-bit GDDR5 SI.
Mir ist noch kein ähnlicher Vergleich auf 7nm bekannt. Gibt es einen Dieshot von der Radeon Pro VII der das vielleicht zeigt wie groß die HBM-SIs in 7nm ausfallen? In der Annahme, dass die PHYs für HBM und GDDR ähnlich schlecht skalieren bei kleineren Nodes, würden dann die beiden HBM Stacks auch in 7nm so viel PHY-Fläche benötigen wie ein 128-Bit SI für GDDR. Dass dies nicht reichen würde für Navi12 ist klar, wenn man die selbe Chipgröße zugrunde legen will.

Berniyh

2020-06-19, 13:04:58

Auch NV setzt das nur im Consumerbereich ein. Trotz Bandbreiten- und Energieeffizienzvorteil.
Ja, aber Nvidia konnte sich bei High-End GPUs halt auch fast alles erlauben da man ja so gut wie keinen Gegenwind bekam.
Kann ja sein, dass man HBM2 auch im Consumerbereich eingesetzt hätte, hätte es vernünftige Konkurrenz gegeben.
N12 kostet im Macbook ja richtig Aufpreis und ist dort nötig um in der TDP zu bleiben und verwendet ja auch nur 2x stacks.
2 Stacks sollten doch auch reichen. Und bzgl. Preis ist Navi12 an der Stelle auch keine wirkliche Referenz, denn Apple lässt sich halt prinzipiell alles vergolden.
Ich würde es auch toll finden - bin aber aus o.g. Gründen sehr skeptisch.
Geht mir genauso. ;)

Berniyh

2020-06-19, 13:09:35

Naja, wer News zu dem Thema relativ aufmerksam verfolgt hat, konnte das schon in November 2019 wissen:
http://www.redgamingtech.com/navi-12-isnt-big-navi-but-instead-navi-10-with-hbm2-rumor/
Das basiert ja letztendlich auf den Dingen die ich hier aufgezeigt hat und nein, das sagte nicht aus, dass da HBM2 zum Einsatz kommt, sondern das spekuliert er einfach nur als Option (was auch in meinen Beiträgen erwähnt wurde).

Zumal er von Navi23 als "Nvidia Killer" spricht, was aber eher Navi21 sein sollte (wobei das mit dem "Killer" eh so ne Sache ist …).

Wirklich handfest wurde das mit HBM2 erst auf Basis eines späteren Leaks, wobei ich gerade leider nicht mehr weiß aus welcher Richtung der kam.

HOT

2020-06-19, 13:16:13

Also Mac-Aufpreise HBM in die Schuhe zu schlieben ist sportlich (oder dämlich, kann mich nicht entscheiden :D).

robbitop

2020-06-19, 13:20:37

Das nicht unbedingt. Aber sie Preise ermöglichen mehr Spielraum in Bezug auf Marge und geringere Menge - also kein so hoher Stückzahlbedarf.

BlacKi

2020-06-19, 13:42:24

Das nicht unbedingt. Aber sie Preise ermöglichen mehr Spielraum in Bezug auf Marge und geringere Menge - also kein so hoher Stückzahlbedarf.
exakt. das sehe ich auch so wenn ich mir den takt ansehe. der niedrige verbrauch durch den niedrigeren takt lässt ich apple sicher was kosten. 1000mhz ist schon sehr niedrig.

robbitop

2020-06-19, 13:47:56

Jap. Der Betriebspunkt macht irre viel aus. Da ist ein Fullnodesprung oftmals schnell aufgefressen heutzutage für ein paar hundert mhz.

BlacKi

2020-06-19, 13:55:40

man kann schon ungefähr vom halben preis reden, wenn statt hbm gddr5/6 nehmen würde, den chip mit nur ca 24-28CU bei 1900mhz boosten lassen würde, bei selber performance, aber fast doppeltem verbrauch.

Locuza

2020-06-19, 13:58:15

Wer sagt eigentlich, dass Sienna Cichlid N21 sein soll? Kann doch sein, dass damit einer der kleineren Chips gemeint ist. Die Breite des Frontends ist hier doch gar kein Indiz, siehe Tonga. Das ist doch auch eher ein mittelgroßer Fisch, das passt doch gar nicht zu N21. Da wird ich mal eher davon ausgehen, dass es sich um den mittelgroßen Chip handelt, der eben das gleiche Frontend wie der Große hat aber eben deutlich weniger CUs.
Das war aber nicht im Kernel Treiber, sondern Mesa und pal.
Ist aber inzwischen dort auch wieder verschwunden und die Daten werden aus den FW Dateien ausgelesen.

Edit: generell haben die FW Dateien für AMD den Vorteil, dass es kein Review gibt und keine Deadlines. Die können sie also auch sehr kurzfristig veröffentlichen. Beim Linux Kernel und bei Mesa gibt es halt eine Vorlaufzeit von mindestens 4 Monaten von Veröffentlichung bis Release.

Ja. Zumindest mir ist auch noch überhaupt nicht klar, ob mit Sienna Cichlid Navi2x allgemein gemeint ist oder einer der einzelnen Chips.
Patches gibt es ja nur zu Sienna Cichlid, aber ich würde erwarten, dass wenn man jetzt Patches veröffentlicht die auch für alle vorzustellendenen Karten valide sind.
ok, könnte natürlich sein, dass die beiden anderen Chips deutlich später kommen.
Sienna Cichlid = Navi21, ist mittlerweile relativ eindeutig.
Sienna Cichlid ist ein definierter ASIC Type, keine Serie.
Dabei wurde beim DCN-Patch die gleiche ID gefunden, welche man damals bei Navi21 gefunden hat, P_A0 = 40:
https://videocardz.com/newz/amd-sienna-cichlid-gpu-appears-in-linux-driver-patches-is-this-big-navi

IIRC habe ich auch hier mal andere Einträge gesehen, aber mit den RadeonSI-Commits ist es jetzt eindeutig, Sienna Cichlid ist GFX1030:
case CHIP_SIENNA:
return "gfx1030";

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5383/diffs?commit_id=9538b9a68ed9aa0f8a231d6bf681f6f0a2a9d341

NAVI21:gfx1030
NAVI22:gfx1031
NAVI23:gfx1032
VANGOGH:gfx1033
VANGOGHLITE:gfx1040
https://twitter.com/_rogame/status/1273792793144688640

Wenn man den Kommentaren folgt wurde VANGOGH auch zuerst erst als 1032 ausgewiesen, wobei dieser nun GFX1033 trägt.
Aber alles was sich die letzten Monate für Navi21 ergeben hat, stimmt jetzt mit dem überein, was bei Sienna Cichlid in den Treibern gelistet wurde.

Generell muss man sagen, dass die Sache mit Navi12 + HBM sich extrem lange hingezogen hat.
Die ersten Patches zu dem Chip gab es ja vor ca. einem Jahr. Im Herbst wussten wir zumindest, dass das Speicherinterface ähnlich groß wie bei Navi10 ist, aber, dass HBM2 (wahrscheinlich) zum Einsatz kommt wissen wir erst seit Februar oder so.
[...]
Der konkrete Hinweis darauf, den ich kenne, stammt vom Dezember 2019:
juergbi
67 points ·
5 months ago

For Navi12 dram_channel_width_bytes is 16, i.e., 128 bits per channel, while for Navi10 it's 2, i.e., 16 bits per channel. num_chans is 16 for both, resulting in a total dram width of 2048 bits for Navi12 (and 256 bits for Navi10). This is another hint towards HBM.
https://www.reddit.com/r/Amd/comments/ef0zjq/navi12_arcturus_renoir_gpu_firmware_info_shader/fbxv1sp/

Ist den Bandbreite überhaupt noch der Flaschenhals. Man hat mitlerweille für alles eine Kompression. Zudem wurde ja das Streaming zwischen Festplatte und Ram GPU verbessert. Ich glaube nicht das wir noch Bandbreitenlimitiert sind.
[...]
Navi10 skaliert sehr schlecht nach oben.
18% GPU-OC bringen weniger als die Hälfte an realer Performance.
https://www.techspot.com/review/1883-overclocking-radeon-rx-5700/

In der aktuellen Situation der verfügbaren Wafer-Mengen bei TSMC, sollte man auch diesen Flaschenhals auf dem Schirm haben. Wenn 50mm² (willkürliche Zahl) weniger Fläche auf dem Die benötigt wird für HBM, könnte AMD besonders bei kleineren GPUs wie Navi12 die Anzahl der Produkte/Wafer erhöhen und auf diese Weise schnell 20-25% Diefläche (spekuliert von mir) einsparen und zeitgleich die Yield verbessern mit den kleineren Dies (weitere 7nm-Waferfläche gespart). Eventuell gab es da einen wirtschaftlichen Faktor in der Konstellation der das sinnvoller erscheinen lies im Gesamtkonzept von AMD. Dieser Faktor würde weniger Einfluß haben je größer der Die ist und dann wieder die mögliche Bandbreite als dominierenden Faktor für die Entscheidung GDDR/HBM in den Vordergrund rücken, sowie die Kosten für Interposer, PCB, Packaging und Speicher.

In 28nm war ein 1024-SI für HBM ungefähr grob so groß wie ein 64-bit GDDR5 SI.
Mir ist noch kein ähnlicher Vergleich auf 7nm bekannt. Gibt es einen Dieshot von der Radeon Pro VII der das vielleicht zeigt wie groß die HBM-SIs in 7nm ausfallen? In der Annahme, dass die PHYs für HBM und GDDR ähnlich schlecht skalieren bei kleineren Nodes, würden dann die beiden HBM Stacks auch in 7nm so viel PHY-Fläche benötigen wie ein 128-Bit SI für GDDR. Dass dies nicht reichen würde für Navi12 ist klar, wenn man die selbe Chipgröße zugrunde legen will.
Fritzchens Fritz/OC_Burner hat zu Vega10 und Vega20 die shots erstellt:
https://www.flickr.com/photos/130561288@N04/40482186211/
https://www.flickr.com/photos/130561288@N04/48243282516/

Bei der HBM-PHY-Größe scheint sich von 14nm zu 7nm kaum etwas getan zu haben:
https://blog.coelacanth-dream.com/image/2020/03/24/compare-vega10-vega20.webp
https://blog.coelacanth-dream.com/posts/2020/03/24/vega10-vega20-dieshot-guess/

Berniyh

2020-06-19, 14:22:35

Sienna Cichlid = Navi21, ist mittlerweile relativ eindeutig.
Sienna Cichlid ist ein definierter ASIC Type, keine Serie.
Dabei wurde beim DCN-Patch die gleiche ID gefunden, welche man damals bei Navi21 gefunden hat, P_A0 = 40:
https://videocardz.com/newz/amd-sienna-cichlid-gpu-appears-in-linux-driver-patches-is-this-big-navi

IIRC habe ich auch hier mal andere Einträge gesehen, aber mit den RadeonSI-Commits ist es jetzt eindeutig, Sienna Cichlid ist GFX1030:

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5383/diffs?commit_id=9538b9a68ed9aa0f8a231d6bf681f6f0a2a9d341
Ah danke, das war mir noch nicht aufgefallen, bzw. hatte ich noch keine Zeit mit die Mesa Patches im Detail anzuschauen.
Aber ja, damit ist die Zuordnung Sienna Cichlid = Navi21 eigentlich fix.
Ob Navi21 dann auch wirklich Big Navi ist ist noch mal eine andere Frage, aber gilt schon als wahrscheinlich, denn mindestens den wollte AMD ja dieses Jahr noch bringen. Da man ja grob 4 Monate Vorlaufzeit rechnen muss würde es wenig Sinn machen jetzt erst mit Patches für den Mid-Range Chip zu starten.

Heißt dann aber auch, dass in den nächsten Wochen noch weitere Patches für die anderen beiden Chips zu erwarten sind (so denn diese noch dieses Jahr veröffentlicht würden).

Der konkrete Hinweis darauf, den ich kenne, stammt vom Dezember 2019:

https://www.reddit.com/r/Amd/comments/ef0zjq/navi12_arcturus_renoir_gpu_firmware_info_shader/fbxv1sp/
Danke, das war mir auch noch nicht aufgefallen.
Kann gerade nicht nachschauen, aber sind die Parameter für Navi21 nicht auch angegeben?

Locuza

2020-06-19, 15:01:53

Ein Fingerzeig Richtung große GPU sind die vorhandenen Adaptive Voltage Frequency Modules, von denen Sienna Cichlid 67 hat, während es bei Navi10 nur 36 sind.
Und sowie es ausschaut wird Big Navi der erste RDNA2-Ableger werden.
Entsprechend ist das Bild hierbei schon relativ klar.

Eine gute Frage ist wirklich, ob Navi22 oder 23 es noch 2020 schaffen?

Bezüglich der Speicher-Parameter weiß ich gar nicht, wie die Leute aus den Dateien die Informationen extrahieren.
Aber ich denke wenn es zu Navi21/Sienna Cichlid etwas geben würde, dass Komachi, rogame oder andere da schon nachgeschaut und die Information geteilt hätten.

BoMbY

2020-06-19, 15:03:06

LLVM: [AMDGPU] Add gfx1030 target (https://github.com/llvm/llvm-project/commit/9ee272f13d88f090817235ef4f91e56bb2a153d6)

Soweit ich das sehen kann noch nichts spektakuläres, auch noch nichts mit Raytracing.

BoMbY

2020-06-19, 15:26:23

horn 12

2020-06-19, 15:27:01

Rechne AMD bringt 3 Karten,- und davon 2 Karten mit 16GB HBM² Speicher,- die Letztere mit 12 GDDR6.

Sollte bald Leaks geben.

Locuza

2020-06-19, 15:38:02

@BoMby

Wenn man nur die Zeit und Geduld hätte das alles zu lesen. :D
Das erste Patent fand ich aber interessant von der Überschrift her.
Keine Ahnung woher rogame die Einträge hat, aber bezüglich RDNA2 gibt es Folgendes:
https://pbs.twimg.com/media/Ea1uOXAWAAEdg0m?format=png&name=900x900
https://twitter.com/_rogame/status/1273795780009222144/photo/1

Ich nehme an die Zahl 64 steht für Double-Precision bei der Instruktion und AMD würde in Zukunft solche Operationen gerne ersetzen.
Oder es ist schon implementiert und man behält sich gewisse Dinge nur als Backup vor?

BoMbY

2020-06-19, 15:40:50

Das von rogame sind vermutlich Dumps aus einer von AMD's Windows-Treiber DLLs. Die enthalten seit längerer Zeit bereits Referenzen auf die Intersection-Funktionen/Instruktionen. Der DX12-Treiber hat ja auch schon ewig eine DXR-Implementierung.

Berniyh

2020-06-19, 15:49:00

Rechne AMD bringt 3 Karten,- und davon 2 Karten mit 16GB HBM² Speicher,- die Letztere mit 12 GDDR6.

Sollte bald Leaks geben.
Das würde aber 2 Chips bedeuten und momentan haben wir nur Hinweise auf einen Release von einem Chip in den nächsten Monaten.

Berniyh

2020-06-19, 15:52:31

Bezüglich der Speicher-Parameter weiß ich gar nicht, wie die Leute aus den Dateien die Informationen extrahieren.
Das ist halt ein Binärdatenformat. Sobald man ein bisschen über die Struktur der Daten in Erfahrung gebracht hat kann man das auch in halbwegs sinnvollen Klartext umwandeln.
Zumindest soweit es nicht verschlüsselt ist.

horn 12

2020-06-19, 15:57:34

BigNavi ist für Beides konzipiert
GDDR6 und HBM Stacks!

unl34shed

2020-06-19, 16:01:34

BigNavi ist für Beides konzipiert
GDDR6 und HBM Stacks!

Das macht mMn. überhaupt keinen Sinn.

Langlay

2020-06-19, 16:05:26

Das macht mMn. überhaupt keinen Sinn.

Naja wenn wir Horns andere Leaks als Grundlage nehmen, dürfte BigNavi jetzt weder HBM noch GDDR6 haben *g

Berniyh

2020-06-19, 16:15:37

Naja wenn wir Horns andere Leaks als Grundlage nehmen, dürfte BigNavi jetzt weder HBM noch GDDR6 haben *g
Big Navi mit DDR4 als VRAM?
Will AMD endlich dafür sorgen, dass APUs bei der Leistung mit dedizierten Karten mithalten können? :D

dargo

2020-06-19, 16:15:46

exakt. das sehe ich auch so wenn ich mir den takt ansehe. der niedrige verbrauch durch den niedrigeren takt lässt ich apple sicher was kosten. 1000mhz ist schon sehr niedrig.
Naja... wie willst du sonst in 50W mit 40CUs reinpassen? Das Ding wird max. mit 750mV angesteuert. Mich würde es nicht mal wundern wenn AMD hier für Apple weitere Optimierungen implementiert hat falls der Prozess es zulässt, sodass das Ding eventuell sogar mit 700-725mV läuft. Schon Navi10 Desktop macht mit 750mV über 1,2GHz.

Leonidas

2020-06-19, 16:23:33

BigNavi ist für Beides konzipiert
GDDR6 und HBM Stacks!

Am besten übereinander gestappelt?

Sorry, wer baut für einen Flächenbedarf von ca. 10-15% (Interface+Controller) gleich 2 Interfaces in seinen Chip - wovon dann nur eines genutzt wird?

BlacKi

2020-06-19, 16:26:18

Naja... wie willst du sonst in 50W mit 40CUs reinpassen? Das Ding wird max. mit 750mV angesteuert. Mich würde es nicht mal wundern wenn AMD hier für Apple weitere Optimierungen implementiert hat falls der Prozess es zulässt, sodass das Ding eventuell sogar mit 700-725mV läuft. Schon Navi10 Desktop macht mit 750mV über 1,2GHz.
so siehts aus.

Daredevil

2020-06-19, 16:49:50

Apple selbst optimiert ja auch die Hardware unter MacOS.
Die Intel Prozessoren performen ja z.T. auch unter MacOS besser als unter Windows, einfach weil man dort mit weniger Spannung hantiert. UV Build in quasi.

Was anderes wird das wohl auch nicht sein. Einfach eine takt optimierte Grafikkarte.
Zeit, sich bei Apple zu bewerben, Dargo. :D

Complicated

2020-06-19, 17:47:14

Fritzchens Fritz/OC_Burner hat zu Vega10 und Vega20 die shots erstellt:
https://www.flickr.com/photos/130561288@N04/40482186211/
https://www.flickr.com/photos/130561288@N04/48243282516/

Bei der HBM-PHY-Größe scheint sich von 14nm zu 7nm kaum etwas getan zu haben:
https://blog.coelacanth-dream.com/image/2020/03/24/compare-vega10-vega20.webp
https://blog.coelacanth-dream.com/posts/2020/03/24/vega10-vega20-dieshot-guess/
Danke für die Dieshots :up:

Wenn man das mal in Richtung 5nm/3nm extrapoliert wird das SI deutlich abspecken müssen um nicht zu immer mehr Diefläche zu verbrauchen in Relation. Der Weg mit 2 HBM-Stacks scheint fast vorgezeichnet, wenn man sieht wieviel Bei Vega 20 schon eingespart werden konnte. Hier muss auch es für GDDR auch ein Limit bei der Wirtschaftlichkeit geben beim Flächenanteil. Möglicherweise zeigt Navi12 wo das liegt für AMD.

basix

2020-06-19, 19:32:29

Danke für die Dieshots :up:

Wenn man das mal in Richtung 5nm/3nm extrapoliert wird das SI deutlich abspecken müssen um nicht zu immer mehr Diefläche zu verbrauchen in Relation. Der Weg mit 2 HBM-Stacks scheint fast vorgezeichnet, wenn man sieht wieviel Bei Vega 20 schon eingespart werden konnte. Hier muss auch es für GDDR auch ein Limit bei der Wirtschaftlichkeit geben beim Flächenanteil. Möglicherweise zeigt Navi12 wo das liegt für AMD.

Bei TSMC 5nm gibt es 20-30% Scaling bei Analog und PHY Zeugs ;)

Complicated

2020-06-19, 20:25:47

Guter Hinweis. Hab das hier gefunden daraufhin:
https://fuse.wikichip.org/news/3398/tsmc-details-5-nm/
TSMC also optimized analog devices where roughly 1.2x scaling has been achieved. At IEDM, Geoffrey Yeap gave a little more color to that density by reporting that for a typical mobile SoC which consists of 60% logic, 30% SRAM, and 10% analog/IO, their 5 nm technology scaling was projected to reduce chip size by 35%-40%.
Ändert allerdings nichts daran, dass der Rest besser skaliert und so der Bereich trotzdem immer mehr Flächenanteil benötigt auf dem Chip.
At IEDM, TSMC reported 1.84x density improvement over the company’s own N7 node.

BlacKi

2020-06-19, 21:39:58

Wenn man das mal in Richtung 5nm/3nm extrapoliert wird das SI deutlich abspecken müssen um nicht zu immer mehr Diefläche zu verbrauchen in Relation.
war das nicht so, das man abstand zwischen den pins braucht? die sind nicht so groß weil man das SI nicht kleiner machen kann, sondern um die kontakte vom silizium auf den träger hinzubekommen? bei einem 2048 bit SI braucht man wohl einfach mehr platz für die kontakte, als mit 256/384bit.

Complicated

2020-06-19, 22:55:33

Nur ist das 2048 HBM-SI halb so groß wie das 256 bit SI für GDDR (Ausgehend von 28nm und 14nm). Trifft also so nicht zu.

unl34shed

2020-06-19, 23:31:43

GDDR6 braucht auf Grund des deutlich höheren Taktes und der externen Speicherchips ein größeres Interface, da die Treiber stärker ausgelegt sein müssen. Man musst eine deutlich größere parasitäre Kapazität in kürzerer Zeit umladen.

Wie Complicated sagt, ist ein 1024bit HBM IF ein gutes Stück kleiner als 128bit GDDR6, weil bei HBM außerdem noch einen Silizium Interposer zum Einsatz kommt, der bei der Fertigung feinere Strukturen erlaubt und daher geringere Abstände zwischen den Pins erlaubt.

BlacKi

2020-06-19, 23:37:33

das geht alles an meiner aussage vorbei.

ich meinte damit, dass das shrinken von 14nm auf 7nm des SI wegen dem abstands der pins nicht weiter shrinken kann.

unl34shed

2020-06-19, 23:45:08

Naja, die hast auch "bei einem 2048 bit SI braucht man wohl einfach mehr platz für die kontakte, als mit 256/384bit." geschrieben und die Zahlen implizieren, dass du HBM und GDDR6 meinst.

Ansonsten ja, aktuell wird der Pitch der Pins von dem Fertigungsprozess des Interposers/Substrats definiert und nicht vom Prozess der Chips, da dieser viel kleiner ist.

BlacKi

2020-06-19, 23:47:43

welches der beiden SI kann man besser shrinken?

amdfanuwe

2020-06-20, 00:46:06

das geht alles an meiner aussage vorbei.

ich meinte damit, dass das shrinken von 14nm auf 7nm des SI wegen dem abstands der pins nicht weiter shrinken kann.
Die Pins können über den ganzen Chip verteilt werden, hat nichts mit der Größe des SI zu tun.

Gratzner

2020-06-20, 01:27:02

Ansonsten ja, aktuell wird der Pitch der Pins von dem Fertigungsprozess des Interposers/Substrats definiert und nicht vom Prozess der Chips, da dieser viel kleiner ist.

Also die Solder Bumps sind auf der obersten Schicht der Metallisierung und haben erstmal wenig mit den Strukturgrößen des FEOL zu tun.

Die Pins können über den ganzen Chip verteilt werden, hat nichts mit der Größe des SI zu tun.

Selbst wenn es nicht so wäre, bei 150µm pitch bekommt man 256 Anschlüsse in weniger als 6mm^2 untergebracht, was damit keinesfall den Flächenverbrauch der GDDR6-Schnittstelle erklären würde.

Es gibt ja noch andere Teile, die sich ganz schlecht shrinken lassen, z. B.: Widerstände. Bei den ganzen (G)DDR-Speicher gibt es typischerweise auf beiden Seiten mehrere Widerstände für die on-die-termination. Bei DDR2 und DDR3 waren es, glaube ich, 3 Widerstände pro Anschluss.

Bei HBM übernimmt vielleicht der Interposer die Terminierung, was auf jeden Fall zu Flächenersparnis führen würde

Complicated

2020-06-20, 06:58:55

Man sollte auch nicht die Leitungslänge ausser acht lassen. HBM hat einen deutlich kürzeren Signalweg.

Zossel

2020-06-20, 07:52:36

Man sollte auch nicht die Leitungslänge ausser acht lassen. HBM hat einen deutlich kürzeren Signalweg.

Weswegen die parasitären Induktivitäten und Kapazitäten gegen die man antreiben sind kleiner sind.
Ob HBM Leitungen "elektrisch kurz" ?(<Lambda/4)? genug sind wo man die Leitungsanpassung vernachlässigen kann weiß ich nicht. (Jemand Wissendes anwesend?)
Auch die Schutzdioden dürften bei HBM wesentlich kleiner ausfallen oder können entfallen.

horn 12

2020-06-20, 08:56:26

Fakt ist dass speziell bei dieser AMD Generation HBM² Speicher mehr Sinn macht als bei den vielen Vega Karten welche bis dato Releast wurden.
Man könnte viele Fliegen mit eine Klappe schlagen und auf eine etwas Geringe Marge schielen.
Aber Marktanteile ist das A und O bei AMD geworden.

https://www.youtube.com/watch?time_continue=1210&v=h8H_7VguCzg&feature=emb_logo

Bei den Preisen Traut sich AMD aber was und wirkt extrem Selbstbewusst
Zudem kann dies echt auf HBM² hinweisen... und die 779 Dollar wäre wohl RTX 2080 Super Performance (mindestens)
Auch wenn dies Spekulation meinerseits ist.

BlacKi

2020-06-20, 10:15:17

Selbst wenn es nicht so wäre, bei 150µm pitch bekommt man 256 Anschlüsse in weniger als 6mm^2 untergebracht, was damit keinesfall den Flächenverbrauch der GDDR6-Schnittstelle erklären würde.
braucht das hbm si nicht deutlich mehr microbump kontakte als gddr? also 2048 vs 256bit?

eigentlich der falsche fred, aber über eine kurze antwort würde ich mich freuen.

vinacis_vivids

2020-06-20, 10:28:48

Am besten übereinander gestappelt?

Sorry, wer baut für einen Flächenbedarf von ca. 10-15% (Interface+Controller) gleich 2 Interfaces in seinen Chip - wovon dann nur eines genutzt wird?

"Multi-Level Cache Hiercharchy"

https://abload.de/img/861-cache-diagram3jkwy.jpg

L1 <-> L2 <-> SOC Fabric <-> xxx GDDR6 & xxx HBM³

So ein riesen BIG-NAVI Chip kann quasi im Speicher Schwimmern:
Radeon VII: 1TB/s
RX 5700XT: 448GB/s

Der HMB ist dem GDDR6 Speicher sicherlich vorrangig zu behandeln.

Außerdem hat AMD ja bereits eine Radeon Pro SSG mit 16GB HMB² + 2TB SSD.

Big Navi Speichersystem:
Bandbreite: 8 GB HBM2 : 2.4 Gbps per pin x 1024 bit bus = 307.2 GBps
Bandbreite "Pack" 4 HBM2 : 307.2 GBps x 4 = 1228.8 GBps = 1.2 TBps

Summarum: 32GB HBM2 2048bit @ 1228 GB/s + 64 GB GDDR6 256bit @ 448 GB/s

robbitop

2020-06-20, 10:46:28

Das macht aus Latenz und Bandbreiten Gründen IMO wenig Sinn, HBM und GDDR zu kombinieren. Für solche Hierarchien (mit zunehmenden Level wird Performance/Latenz für Menge eingetauscht) sind HBM und GDDR zu ähnlich in Bezug auf Performance/Latenz/Größe.
Dazu kommt, dass man 2x große Interfaces verbauen muss.

EDRAM oder ein großer SRAM böte sich als Zwischenhierarchiestufen vor GDDR an. Als nachgelagerte Stufe kann man den RAM nutzen und danach eine SSD. Eine direkt angebundene SSD ist sicherlich sinnvoll.

Damit man das sinnvoll nutzen kann für 3D Grafik muss der Entwickler aber sicherlich einiges machen. Die Nextgen Konsolen werden hier einen Anreiz setzen.

Berniyh

2020-06-20, 11:06:40

Wenn man HBM2 nutzt und daher eh den Interposer mit der teureren Packaging Technologie eh nutzt, dann werden die Mehrkosten für etwas mehr HBM2 RAM nicht aufwiegen, dass man ein zusätzliches Speicherinterface mit extra Anbindung zu den Speicherchips einbaut.
SSD evtl. schon, aber GDDR6 sicher nicht.

Die eigentlichen Speicherchips sind ja nicht im Wesentlichen das was HBM2 teurer macht.

robbitop

2020-06-20, 11:10:39

Ggf wird 3D Stacking von DRAM irgendwann mal für SoCs aber auch für GPUs eine sinnvolle Cachestufe ausmachen. Die Entfernung wäre dann so gering, dass Latenz und Bandbreite potenziell proftieren könnte. Man stelle sich 1gb schnellen L4 vor. Das würde such das SI einer GPU potenziell entlasten. Sah man ja schon bei Crystallwell mit nur 128 mb (als Chiplet).

KarlKastor

2020-06-20, 11:28:03

https://www.youtube.com/watch?time_continue=1210&v=h8H_7VguCzg&feature=emb_logo

Ist das der neue Standard? In Erzählerstimme noch irgendwie versuchen einen Spannungsbogen aufzubauen und ne tolle Geschichte erzählen? Ich schaue ja schon keine Video Reviews etc an weil die alle rumschwafeln und in 20 min kaum Informationen rüber kommen. Aber das ist ja schon der Wahnsinn. Einfach im tollen Erzählstil viel Schwachsinn erzählen. Es scheint einigen Leuten zu gefallen.
Und was für ein Unsinn ist denn bitte stacked NAND?
Welchen Vorteil hat solch lahmer Speicher direkt am Die?

[MK2]Mythos

2020-06-20, 11:55:24

Ist das der neue Standard? In Erzählerstimme noch irgendwie versuchen einen Spannungsbogen aufzubauen und ne tolle Geschichte erzählen? Ich schaue ja schon keine Video Reviews etc an weil die alle rumschwafeln und in 20 min kaum Informationen rüber kommen. Aber das ist ja schon der Wahnsinn. Einfach im tollen Erzählstil viel Schwachsinn erzählen. Es scheint einigen Leuten zu gefallen.
Und was für ein Unsinn ist denn bitte stacked NAND?
Welchen Vorteil hat solch lahmer Speicher direkt am Die?
Du bist ja noch relativ frisch hier, deswegen mein persönliche guideline im Umgang mit horns Postings:
- meistens trifft exakt das Gegenteil von dem ein, was horn prophezeit
- grundsätzlich nicht seine links anklicken
- geheime, persönliche Quellen sind entweder ausgedacht, oder stammen von einem Troll

Wenn du dich grob daran hältst, ersparst du dir viel Frust und Zeitverschwendung! :up:
macht manchmal aber auch Spaß

mironicus

2020-06-20, 11:59:27

[MK2]Mythos

2020-06-20, 12:03:27

Wäre es denn denkbar, das AMD irgendwann mal eine Mainstream-GPU mit zusätzlichem SSD-Speicher (z.B. 256 GB) auf den Markt bringt? Das was sich jetzt bei den neuen Konsolen anbahnt, könnte so auf dem PC elegant gelöst werden.
Ich könnte mir gut vorstellen dass wir das schon bei dieser Generation sehen werden, analog zu den Konsolenlösungen.

robbitop

2020-06-20, 12:10:54

Ich denke es wird reichen, PCIe angebundene SSDs zu nutzen. Die Latenz von SSD ist verglichen mit der des PCIes und RAM sehr hoch. Macht kaum einen Unterschied. Man wird M2 SSDs besser nutzen können. IMO wird es im Consumerbereich mittelfristig nicht nötig sein, SSDs direkt auf die Grafikkarte zu integrieren.
Die aktuelle Bremse ist eher auf der Softwareseite (API und die Applikation selbst). Nicht die Hardware selbst. DX12 Ultimate und entsprechend optimierte Spiele werden das ändern.

Gratzner

2020-06-20, 12:16:38

braucht das hbm si nicht deutlich mehr microbump kontakte als gddr? also 2048 vs 256bit?

Ja, die Beobachtung ist jedoch, dass ein HBM Interface kleiner ist als ein GDDR(6) Interface

Ob HBM Leitungen "elektrisch kurz" ?(<Lambda/4)? genug sind wo man die Leitungsanpassung vernachlässigen kann weiß ich nicht. (Jemand Wissendes anwesend?).

So die "Binsenweisheit" ist, elektrisch Kurz (im Sinne von, ab wann man Leitungsabschluss/Terminierung für Reflexionsunterdrückung vernachlässigen kann) ist, wenn die Signallaufzeit kürzer ist als 1/6 der Anstiegszeit, was sich Wahrscheinlich nur auf Tankleitungen/Interruptleitungen bezieht, Datenleitungen sind nochmals weniger kritisch

Man sollte auch nicht die Leitungslänge ausser acht lassen. HBM hat einen deutlich kürzeren Signalweg.
Weswegen die parasitären Induktivitäten und Kapazitäten gegen die man antreiben sind kleiner sind.

Mal ganz vorsichtig. Der Wellenwiderstand ist teils völlig unabhängig von der Leitungslänge bzw. spielt im Vergleich zu anderen Leitungsparametern keine Rolle. Kommt jetzt sehr genau auf den Umstand an.

Auch die Schutzdioden dürften bei HBM wesentlich kleiner ausfallen oder können entfallen.

Es geht vermutlich um ESD-Schutz? Eigentlich sind die immer gleich. Man muss immer irgendwie das Machine Model oder das Charged Devices Model beachten. Es kommen übrigens zum Schutz nicht nur Dioden vor, sondern auch Transistoren und Widerstände. Da wird teilweise ein spezieller Feldeffekttransistor gebaut, der einen parasitären Bipolartransistor erzeugt (ggNMOS)

Gratzner

2020-06-20, 12:23:21

Ggf wird 3D Stacking von DRAM irgendwann mal für SoCs aber auch für GPUs eine sinnvolle Cachestufe ausmachen. Die Entfernung wäre dann so gering, dass Latenz und Bandbreite potenziell proftieren könnte.
Bei einer Ausbreitungsgeschwindigkeit von 21 cm/ns (in Kupfer) erreicht man durch Stacking kaum einen Latenzvorteil

robbitop

2020-06-20, 12:30:38

Der kommt IMO nicht primär von der Signalgeschwindigkeit selbst sondern von der deutlich einfacheren Anbindung/Interface. Bei kurzen Entfernungen können höhere Taktraten gefahren werden und frequenznormiert kostet jedes bit weniger pj an Energie.

Nur mal als Beispiel: ein IMC spart schnell mal 10ns im Unterschied zwischen onchip und auf dem gleichen Träger. Noch wesentlich mehr bei klassischen MCs in der Northbridge.

Die Geschwindigkeit der Elektronen im Leiter ist nur eine von vielen Komponenten, die Einfluss haben.

BlacKi

2020-06-20, 12:35:13

Ja, die Beobachtung ist jedoch, dass ein HBM Interface kleiner ist als ein GDDR(6) Interface

dann könnte der vorteil vom hbm SI zunehmend schwinden mit dem weiteren verkleineren des prozesses.

die frage würde ich gerne Locuza stellen, da er die benötigten flächen wohl allzugut kennt.

robbitop

2020-06-20, 12:40:40

Gratzner

2020-06-20, 12:48:29

GDDR wird nicht über microbumps angebunden, da kein silicon interposer nötig. Entsprechend über reguläre Kontakte der GPU (balls). Die sind im Vergleich zu den Mikrobumps relativ groß.

balls selber sind es ja nur auf dem Package, auf dem Die bleiben es micro bumps. Und die micro bumps sind auch nur auf der obersten Schicht der Metallisation und können prinzipiell auch über andere Chipbereiche liegen

BlacKi

2020-06-20, 12:55:00

Beide Interfaces schrumpfen doch auch mit Shrinks - allerdings nur wenig. Das Verhältnis sollte aber ähnlich bleiben. GDDR wird nicht über microbumps angebunden, da kein silicon interposer nötig. Entsprechend über reguläre Kontakte der GPU (balls). Die sind im Vergleich zu den Mikrobumps relativ groß.
meine these ist ja, umso weniger microbumps umso besser lässt es sich shrinken. die antwort die ich gerne hätte wäre jetzt: ja/nein, um soviel.

robbitop

2020-06-20, 13:01:05

@Gratzner
Ja stimmt - du hast Recht. :)

@Blacki
Ich bin da leider auch kein Experte. Allerdings sind die Transistoren ja auf einem anderen Layer als die Verdrahtung auf einem Die. Meine Vermutung wäre: solange der resultierende die nicht pad limitiert ist (also nicht zu klein ist), sollte das keine limitierende Größe für das Shrinkverhalten jeweils sein.

Lasse mich hier aber auch gern korrigieren.

Complicated

2020-06-20, 13:11:24

Hier mal konkretere Vergleichszahlen und auch die von mir gesuchte Kennzahl der SI-Größenunterschiede der PHYs allgemein:
https://www.rambus.com/blogs/memory-systems-for-ai-part-6/
https://www.rambus.com/wp-content/uploads/2020/03/gddr6-hbm2-chart.png

Also ein Flächenvorteil von 50-75% des HBM-SI sowie ein Verbrauchsvorteil von Faktor 3,5 bis 4,5. Normiert auf 256 GB/s. Nachteile wie bekannt auf der Kostenseite, jedoch ohne Berücksichtigung der höheren PCB-Kosten und Komplexität bei GDDR6.

BlacKi

2020-06-20, 14:17:46

Bei der HBM-PHY-Größe scheint sich von 14nm zu 7nm kaum etwas getan zu haben:
ich habs mit paint ausgerechnet.
vega10 vs vega 20 bei 2048bit = 3,6% kleiner.

p10 gddr5 vs n10 gddr6 jeweils 256bit = 24,2% kleiner.

ich wage eine prognose: der flächenvorteil und der stromvorteil auf dem silizium von hbm wird richtung 5-3nm dahinschmelzen, aber nicht besser sein.
es könnte aber auch einfach das SI selbst von gddr5 auf 6 kleiner geworden sein.

Gratzner

2020-06-20, 14:32:22

ich weiß nicht, ob man vega 20 vs vega 10 als guten Vergleich nehmen kann. Vega 20 sah imho nach ein Chip aus, wo man jetzt eher weniger Aufwand investiert hat

robbitop

2020-06-20, 14:33:44

Vega20 war hauptsächlich ein schneller shrink. Sehe ich auch so.

BlacKi

2020-06-20, 14:35:01

dann warten wir mal auf einen n12 die shot^^

Daredevil

2020-06-20, 14:39:26

Worüber wird hier eigentlich gerade diskutiert?
Ob HBM2 sinn macht, oder ob es möglich ist?

Weil die Frage der Möglichkeit ist doch eigentlich schon glasklar, AMD hatte drei Generationen lang jetzt HBM verbaut, wieso sollte die Möglichkeit jetzt nicht auch gegeben sein? Da muss man doch nicht drüber diskutieren, was mehr Platz weg nimmt.
Einzig und alleine der Sinn ist doch die Frage, ob AMD sich hier auch nochmal aus dem Fenster lehnt und "HighEnd" verbaut beim Speicher und das ist ja irgendwie nur eine Frage des Budgets bzw. des angepeilten Preises.

Wenn AMD jetzt nicht super unklug ist, werden sie aber auch hier zweigleisig fahren, warum auch nicht, wenn es bezahlt wird?
Die Gamer bekommen GDDR6 und die Enthusiasten/Pro User bekommen HBM. Stichwort BigNavi mit HBM im MacPro.

Wenn Apple ne kleine Navi Karte mit HBM für 900€ anbieten kann, dann wird es dafür auch Käufer geben.
Käufer, die auch einen MacPro mit ner HBM Navi kaufen für 2000-3000€.
Und wenn so eine MacBookPro 40CU Navi mit HBM kommt, dann kommt an der Stelle auch sicherlich eine größere in einen potentiellen iMac.

Polaris hatte doch auch als RX Vega M GL HBM dazu gekleistert bekommen, Intel wird den Chip doch auch nicht von Grund auf erneuert haben, mh?

dildo4u

2020-06-20, 14:46:01

Nvidia hat die Preise so hoch getrieben, das es für AMD kein sinn machen würde kein HBM2 zu nutzen.
Das könnte das Puzzleteil sein was Nvidia kalt erwischt selbst wenn die AMD GPU wieder zu viel Saft will erlaubt HBM2 mehr Luft dafür.

mironicus

2020-06-20, 15:01:18

Für Apple baut AMD sicher auch ein Big Navi mit HBM2-Speicher. Kann anders gar nicht sein.
Aber für uns...? :D

Daredevil

2020-06-20, 15:08:53

Seit grob 1 1/2 Jahren gibt es nun die VII zu kaufen, Startpreis war 699€, Tiefstpreis 509€ und aktuell gibt es die Karte immer noch zu kaufen für 569€.

Es wird ja immer gerne gesagt ( von mir z.B. ) dass ne VII nur Fanservice war und das nur als Übergang galt zu Navi bzw. manche Sagen, AMD verliert damit Geld bzw. die Anzahl ist nur begrenzt. Na aber wie begrenzt muss eine Karte denn sein, wenn man sie nach 1 1/2 Jahren immer noch kaufen kann? ^^
Hier haben wir halt sehr viel, sehr schnellen Speicher für Vergleichsweise sehr wenig Geld.

Und auch wenn die Architektur vielleicht einfach nur "WinzigVega in 7nm" ist, trotzdem muss man sowas ja bauen und die VII war halt die erste 7nm Karte, heute wird das vielleicht? günstiger zu bauen sein.

Alles andere für ne richtige BigNavi unter der Speicherausstattung der VII hätte für mich ein geschmäckle. Sollen se gerne die gleiche Menge und Geschwindigkeit verbauen, da kann sich doch keiner beschweren, wenn die GPU dann noch Arschschnell ist mit PCIe 4.0.

robbitop

2020-06-20, 15:21:51

Vega 7 ist seit Sommer 2019 EOL. Die wurde nur 5 Monate produziert - aus genau dem Grund. Wenn es die noch zu kaufen gibt, dann nur weil sie noch rumliegt und der Bedarf ggf zu wenig war.

Locuza

2020-06-20, 15:48:52

ich habs mit paint ausgerechnet.
vega10 vs vega 20 bei 2048bit = 3,6% kleiner.

p10 gddr5 vs n10 gddr6 jeweils 256bit = 24,2% kleiner.

ich wage eine prognose: der flächenvorteil und der stromvorteil auf dem silizium von hbm wird richtung 5-3nm dahinschmelzen, aber nicht besser sein.
es könnte aber auch einfach das SI selbst von gddr5 auf 6 kleiner geworden sein.
Ich komme da nicht auf so krasse Zahlen beim P10 vs. N14.
https://abload.de/img/p10-vs-n14dnj3l.jpg

Ein 32-Bit Segment für das PHY ist bei P10 ~4mm² groß.
Bei Navi14 gibt es wie bei P10 unterschiedlich ausgelegte PHYs.
Jedenfalls ist ein 16-Bit Segment mit dem kleinen schwarzen Abstand zum Chip-Rand 1.79mm² groß bzw. zwei davon 3.58mm² und damit nur ~10% kleiner.
Maximal positiv betrachtet, mit dem anderem PHY (nicht im Bild) und ohne jegliche Abstände, komme ich auf 1.71mm² für ein 16-Bit Segment bzw. zwei davon ergeben ~3.42mm², ~14% kleiner.
Aber ein ganzes 32-Bit Segment bei Navi14 mit anderen Elementen ist 4.02mm² groß, wo ich aber nicht alles inkludiert habe, der Rahmen noch paar Pixel wegschneidet und auch der Abstand zum Chiprand nicht eingerechnet wurde.

Vom Flächenverbrauch scheint sich weder positiv, noch negativ viel verändert zu haben, für eine entsprechende Bit-Breite.
Wobei in Bezug auf die Geschwindigkeit das natürlich toll ist, offiziell läuft es statt mit 8Gbps mit 14Gbps (+75%).

BlacKi

2020-06-20, 16:20:59

hast recht, ich hab vorhin die bereiche falsch interpretiert.

reaperrr

2020-06-20, 16:37:05

Polaris hatte doch auch als RX Vega M GL HBM dazu gekleistert bekommen, Intel wird den Chip doch auch nicht von Grund auf erneuert haben, mh?
Das Argument versteh ich nicht. Dass die unterstützten Speicherarten nicht fest an die Architektur gekoppelt sind stellt hier glaub ich keiner in Frage. Ein eigener, extra für Intel designter Chip war es aber schon, nur halt keine neue Architektur.

Es geht einfach nur darum, ob in Anbetracht von GDDR6 das Kosten-/Nutzen-Verhältnis von HBM2(e) gut genug für den Spieler-Karten-Markt ist. Nvidia wird im Consumer-Bereich die letzten Jahre, einschließlich Turing und Gerüchten zufolge auch bei Gaming-Ampere, nicht grundlos bei GDDR geblieben sein.

Na aber wie begrenzt muss eine Karte denn sein, wenn man sie nach 1 1/2 Jahren immer noch kaufen kann? ^^
Keine Nachfrage, da im Vergleich zu Nvidia zu lahm un im Vergleich zur 5700XT zu teuer + mehr Architektur-Schwächen.

robbitop

2020-06-20, 16:40:28

Jep das sind alles individuelle IP blocks die relativ unabhängig voneinander implementiert werden können. Vieles ist bei AMD dann an eine Fabric angeschlossen (mWn auch IF). Entsprechend kann auch vieles kombiniert werden.

mboeller

2020-06-20, 17:30:54

basierend auf dem Radeon Pro 5600m Bild von Golem:
https://www.golem.de/2006/149102-234099-234098_rc.jpg

und der Info von anandtech über die HBM2-Chip Abmessungen (https://www.anandtech.com/show/9969/jedec-publishes-hbm2-specification) komme ich für ein 1024bit-HBM Interface auf ca. 12mm² (1,85 x 6,45mm)

Ein 512bit GDDR6 Interface wären ca. 64mm² (basierend auf den Infos von Locuza, siehe oben)

4096bit HBM2 (also 4 Stacks) wären ca. 48mm²

Nur wenn auch 2 Stacks mit 2048bit ausreichend sind hat HBM2 einen großen Vorteil (40mm²), ansonsten sehe ich jetzt keinen großen Vorteil für HBM2 gegenüber einem 512bit GDDR6 Speicherinterface (abgesehen vom Verbrauch natürlich).

mironicus

2020-06-20, 17:40:08

Ist es vielleicht ein gutes Omen für AMD, das es 7 Jahre her ist, das sie NVidia das letzte Mal geschlagen haben? :)

Berniyh

2020-06-20, 17:56:04

Nvidia wird im Consumer-Bereich die letzten Jahre, einschließlich Turing und Gerüchten zufolge auch bei Gaming-Ampere, nicht grundlos bei GDDR geblieben sein.
Naja, warum soll man denn irgendwas ändern, wenn es praktisch keine Konkurrenz gibt?
Nvidia hier als Motivation zu nehmen zieht nicht so richtig.
Maximal Ampere, aber das Design der Karte liegt auch schon etwas zurück, evtl. war ihnen da noch nicht klar wie Navi2x einzuordnen ist (soweit es ihnen denn jetzt klar ist, uns ist es das ja nicht wirklich).
Ein 512bit GDDR6 Interface wären ca. 64mm² (basierend auf den Infos von Locuza, siehe oben)

4096bit HBM2 (also 4 Stacks) wären ca. 48mm²

Nur wenn auch 2 Stacks mit 2048bit ausreichend sind hat HBM2 einen großen Vorteil (40mm²), ansonsten sehe ich jetzt keinen großen Vorteil für HBM2 gegenüber einem 512bit GDDR6 Speicherinterface (abgesehen vom Verbrauch natürlich).
Reicht das Argument Verbrauch denn nicht?
Und 4096bit HBM2 braucht es eher nicht. Je nachdem auf welche Version man Zugriff hat sollten 2048bit genügen.
Zudem könnte man ja auch 3 Stacks verbauen wie das Nvidia bei Ampere scheinbar macht.

Gegenüber 512bit GDDR6 bleibt zudem noch der Vorteil des einfacheren Board Designs bestehen.

Edit: wenn ich mich nicht verrechnet habe, dann wären 512bit GDDR6 mit 24 GT/s (was ja absolut High-End ist) ca. 1.5 TB/s (mit 18 GT/s wären es 1.2 TB/s). Wäre aber schon eine ziemlich aufwendige und teure Lösung.
HBM2e schafft pro Stack 460 GB/s, d.h. 3 Stacks wären ca. 1.4 TB/s. 4 Stacks wären entsprechend dann 1.8 TB/s.
Mit HBM2e sollten also 3 Stacks für vergleichbare Performance zu 512bit GDDR6 auf jeden Fall genügen.

BoMbY

2020-06-20, 18:16:02

Eine Lösung mit drei Stack würde ich für sehr unwahrscheinlich halten. Ich denke auch zwei Stapel mit je 460 GB/s würden vollkommen ausreichen.

Wobei man vermutlich eher 4 Stapel HBM2 (z.B. 4x 4GB Samsung Aquabolt mit je 256 GB/s) als 512 Bit GDDR6 machen wird. Ich könnte mir auch vorstellen dass 4x Aquabolt mit je 4 GB günstiger als 2x HBM2e mit 8 GB ist.

mironicus

2020-06-20, 18:20:24

Angenommen es wäre HBM2e mit 1,8 TB Durchsatz. Wäre das schon wieder "zuviel" als nötig oder wäre das sogar nützlich für Features wie Raytracing?

Daredevil

2020-06-20, 18:25:44

Das wäre soviel, dass ich mein Mining Rig damit großflächig ausstatten würde :D

BoMbY

2020-06-20, 18:30:57

Ich hab gerade nochmal drüber nachgedacht, und wenn Navi21 tatsächlich mit dem Gedanken an 3x HBM2e gebaut wurde, dann sollte er natürlich auch entsprechend lang sein (z.B. ~ 17x30) so dass drei HBM2e-Module auf eine Seite passen, was dann zumindest auf dem Package/Interposer nicht zu viel Platz verschwendet. Wäre natürlich eine mögliche Lösung.

mironicus

2020-06-20, 18:35:08

Hoffentlich gibt es irgendwann auch mal ein Kühlerleak für Navi21, daraus könnte man ableiten, ob HBM verwendet wird oder nicht.

Berniyh

2020-06-20, 18:39:44

Eine Lösung mit drei Stack würde ich für sehr unwahrscheinlich halten. Ich denke auch zwei Stapel mit je 460 GB/s würden vollkommen ausreichen.
hm, da wäre ich mir unsicher.

Wenn man Zugriff auf 18 GT/s GDDR6 hat, dann wären 384 bit doch 864 GB/s.
2 HBM2e Stacks mit 460 GB/s wären 920 GB/s, also kaum Vorteil von der Seite aus.
Ich schätze mal in dem Fall würde man dann doch evtl. eher das 384bit GDDR6 Interface wählen, ggf. mit noch schnelleren Speichermodulen für die Version für Enthusiasten.

Wobei es doch auch Meldungen zu noch schnelleren HBM Modulen gab, bin mir aber nicht mehr sicher wo/wann und wie schnell die genau sein sollen.
Und ob die für AMD dann auch verfügbar wären ist ja auch noch so eine Geschichte.

In jedem Fall sollten aber 3 Stacks genügen um eigentlich jeden nur erdenklichen Fall im Gaming-Bereich abzudecken.
Ob man dann aus Symmetriegründen doch lieber 4 Stacks einsetzt würde ich bezweifeln.
Nvidia nutzt ja ebenfalls 3 Stacks bei Ampere. Weiß man da eigentlich wie die angeordnet sind?

BlacKi

2020-06-20, 18:42:22

Reicht das Argument Verbrauch denn nicht?
wenn das gerücht stimmt mit 400w feuer frei, dann spielt der unterschied gddr6 bs hbm wirklich keine rolle mehr. wenn man versucht die karte unter 300w zu halten, dann schon.

Berniyh

2020-06-20, 18:59:06

wenn das gerücht stimmt mit 400w feuer frei, dann spielt der unterschied gddr6 bs hbm wirklich keine rolle mehr. wenn man versucht die karte unter 300w zu halten, dann schon.
Die 400W halte ich für Quatsch. Zumindest nicht Stock. Evtl. veranstaltet der eine oder andere Hersteller sowas, wer weiß.

Aber letztendlich wird der Vorteil im Verbrauch immer signifikant sein, insbesondere bei 512 Bit GDDR6 vs. 3072bit oder 4096bit HBM2e.

Kann man das denn auf Basis von Navi12 und Navi10 hochrechnen?
Irgendwer hat doch neulich da schon Vergleiche gezogen, wenn ich mich recht entsinne?

Complicated

2020-06-20, 20:03:33

Also ein Flächenvorteil von 50-75% des HBM-SI sowie ein Verbrauchsvorteil von Faktor 3,5 bis 4,5. Normiert auf 256 GB/s. Nur auf den Controller und das SI bezogen.

mironicus

2020-06-20, 20:19:09

400 Watt wäre hinnehmbar wenn der Chip dafür 120 CU hätte.

robbitop

2020-06-20, 20:21:59

Dann wäre die Auslastung der CUs bei halbwegs normalen Auflösungen wahrscheinlich unschön niedrig.

mironicus

2020-06-20, 20:39:44

Ich hatte gerade einen absurden Gedanken.

Nach der Vorstellung des 5600M im Macbook Pro frage ich mich wie die User hier wohl reagieren würden, wenn ein Big Navi + 16 GB HBM2-Speicher als diskrete Laptopgrafik im nächsten Macbook Pro erscheinen würde, limitiert auf 50 Watt Verbrauch, und natürlich ein voller Chip allererster Güte - dafür mit einen Aufpreis von sagen wir mal 1500 Euro. Nichts ist unmöglich, wenn Apple das will liefert ihnen AMD genau was sie wollen. :D

reaperrr

2020-06-20, 20:54:05

Nvidia nutzt ja ebenfalls 3 Stacks bei Ampere. Weiß man da eigentlich wie die angeordnet sind?
:rolleyes:

6, nicht 3. An jeder Längsseite 3, wobei der A100 ja nur 40GB aktiv und damit wohl insgesamt 5 hat. (G)A100 hat ein 6144bit HBM SI.

https://www.computerbase.de/2020-05/nvidia-ga100-ampere/

BoMbY

2020-06-20, 21:12:48

https://www.computerbase.de/2020-05/nvidia-ga100-ampere/

Ahhja, das ist ein gutes Bild. So grob die Hälfte davon wäre dann etwa wie man sich Navi21 mit drei HMB2e-Stapeln vorstellen könnte. Eventuell mit den HBM2-Stapel auch quer statt längst, um mehr in eine quadratische Form zu kommen? Dann müssten die aber auf jeden Fall dafür sorge tragen dass die Höhe perfekt ausnivelliert wird.

Locuza

2020-06-20, 21:21:36

Fritzchens Fritz/OC_Burner hat Gott sei Dank schon mehrere Chips in einer Übersicht maßstabsgetreu skaliert, weswegen es einfach war die ungefähre PHY-Fläche auszurechnen.
https://www.flickr.com/photos/130561288@N04/46202429935/in/photolist-2gv6r83-2gv6Ugs-2doKwKz-R25vsi-2eGQz3S-29ZRWdW-28koy4b-28koBa1-28kozA9-2b6hCEt-2b6hzoi-NXDD33-29ZRZmQ-2b21TcS-2b21U65-29PKKCu-28aiJiE-29mnXXL-29mohM9-29moeKY-24NZn9C-FdEDNT-24NZors-23vBQnT-23vBPER-23MTxzL-GJVDw3-GJVGyq-GJVJs5-24NZ8Yu-23vCQsF-23vBLg6-23MTPRU-24FgMzM-24Fgwcn-21VhF3q-23Auibh-24BsCVq-23j7SN8-21VhKGq-21VhHJN-23j7Uk6-24FgBR8-GxxKeA-24npdqy-2355WHF-2355VZM-24npdHC-2355Y4X-2355Xza

https://abload.de/img/gpusk7kfr.jpg

Wenn wir z.B. G5@8Gbps (32-Bit, 32GB/s) mit HBM2@1.89 (1024-Bit, 242GB/s) bei Vega10 vergleichen, dann könnte man das grob so betrachten.
Für 14nm G5 Polaris:
4mm² = 32 GB/s (G5) | /32
0.125mm² = 1 GB/s | * 242
30.25mm² = 242 GB/s

Für die gleiche Bandbreite benötigt G5 drei mal soviel Platz, wie HBM2.
Gegenüber G6 schrumpft der Vorteil.
32-Bit belegen grob 4.02mm², leisten 56 GB/s und bei 242GB/s wäre der Flächenverbrauch, vereinfacht hochgerechnet, bei 17.37mm².
Aber dabei vergleicht man natürlich das neuste G6-Design, mit dem ersten HBM2-Design von Vega10, dennoch würde dabei G6 für die gleiche Bandbreite ungefähr 57% mehr Platz belegen.
Bzw. bei 484GB/s sind 22.06mm² für HBM2 nötig gewesen, bei G6 vereinfacht wären es 34.74mm², 12mm² Differenz ist hierbei nicht die Welt bzw. das könnte man auch einfach nachchecken bei Navi10, der hat ja ein 256-Bit Interface mit 448GB/s.
ABER, darauf habe ich jetzt keine Lust mehr. :redface:

Berniyh

2020-06-20, 21:41:45

Nur auf den Controller und das SI bezogen.
Ja, das war mir klar, aber ich meinte jetzt real in W für einen potentiellen Big Navi mit sagen wir 80 CU und 384 Bit vs. 512 Bit vs. HBM2e (2-4 Stacks).
Müsste man doch nachrechnen können wie viel Power das am Ende kostet, ggf. noch mit unterschiedlichen Taktraten.

Berniyh

2020-06-20, 21:42:45

:rolleyes:

6, nicht 3. An jeder Längsseite 3, wobei der A100 ja nur 40GB aktiv und damit wohl insgesamt 5 hat. (G)A100 hat ein 6144bit HBM SI.

https://www.computerbase.de/2020-05/nvidia-ga100-ampere/
hm stimmt, wie komm ich denn jetzt auf 3?
Sorry, mein Fehler.

unl34shed

2020-06-20, 21:49:45

Ja, das war mir klar, aber ich meinte jetzt real in W für einen potentiellen Big Navi mit sagen wir 80 CU und 384 Bit vs. 512 Bit vs. HBM2e (2-4 Stacks).
Müsste man doch nachrechnen können wie viel Power das am Ende kostet, ggf. noch mit unterschiedlichen Taktraten.

Gab Mal die Grafik, ist allerdings nur GDDR5
https://www.overclock.net/photopost/data/1620549/0/0a/0ae145d8_NV-HB.png

Berniyh

2020-06-20, 22:36:03

Die Grafik verstehe ich nicht wirklich.

(Ist aber meiner Meinung nach auch ziemlich grottig gemacht. Was ist denn der Unterschied innerhalb einer Kategorie auf der X Achse? Größe Speicherinterface bzw. Anzahl Stacks?)

Locuza

2020-06-20, 22:59:36

Links stehen Zahlen für den Energieverbrauch, Rechts für die Bandbreite.
Die Balken beziehen sich nur auf den Energieverbrauch, während die schwarze Linie sich auf die Bandbreite bezieht.
Weniger als 500GB/s konsumieren bei GDDR5 laut der Grafik >70W, HBM1 bei mehr Bandbreite nur 40W.
Wie breit oder schnell das Interface bei Nvidias Berechnung ausfällt, ist leider nicht angegeben.
Es soll sowieso nur primär ein Fingerzeig auf kommende Probleme sein, denn selbst 50% effizienterer HBM2-Speicher würde nach der Rechnung 160W bei 3-4TB/s konsumieren.
HBM war ein deutlicher Fortschritt gegenüber GDDR(5), aber wenn es nicht erneut große Innovationen geben wird, wird es eklig.

------

Übrigens scheint sich wirklich fast nichts für die HBM2-PHY-Größe von 14nm GloFo zu 7nm TSMC getan zu haben:
https://abload.de/img/vega20-phy-kleinlljwa.jpg

Brillus

2020-06-20, 23:31:47

Gab Mal die Grafik, ist allerdings nur GDDR5
https://www.overclock.net/photopost/data/1620549/0/0a/0ae145d8_NV-HB.png
Das müsste die Nvidia Folie sein wo sie zeigen wollten warum HBM eigentlich scheiße ist.

Locuza

2020-06-20, 23:57:37

BlacKi

2020-06-21, 00:13:26

anders funktioniert das nv bashing aber nicht.

unl34shed

2020-06-21, 00:31:07

Von der Notwendigkeit von >2 TB/s sind wir allerdings auch noch weit entfernt (zumindest im Consumer bereich). Und um in diese Regionen mit herkömmlichen GDDR zu kommen würde noch deutlich mehr Energie benötigt.

Ich glaube aber auch, dass ein Problem der Grafik ist, dass Nvidia nicht die Speichermenge zu den Balken angegeben hat.
Unter der Grafik steht nur HBM2, nicht HBM2e, dass gab es damals auch noch nicht. Das bedeutet, auch, dass für die Verdopplung der Bandbreite auch das Speicher Interface verdoppelt wurde und wir hier für die 2TB/s mit 120W hier von einem 8192 bit HBM2 Interface reden dürften. Wenn man nur den Takt erhöht (HBM2e), dann steigt der Verbrauch vermutlich deutlich geringer an, da es nur IO (den roten Teil) betreffen sollte.

Und nicht vergessen, HBM3 kommt auch noch und soll effizienter sein, vielleicht sind dann sogar 2TB/s bei 60 W möglich, dann braucht man auch nur ein 4096 bit Interface.

E: Und mit GDDR6 bräuchte man für die 2TB/s ein 1024bit SI @ 16GT/s (oder 800bit@20GT/s) um das zu knacken, wie viel verbraucht das dann? Reichen da 200W?

anders funktioniert das nv bashing aber nicht.

:confused::confused::confused:

Der_Korken

2020-06-21, 00:35:30

Wobei man ja sagen muss, dass das Problem der hohen "IO-Power" (gemeint sind vermutlich die PHYs auf der GPU selbst) schon gut gelöst ist, wenn man mal GDDR5 und HBM vergleicht. Der Verbrauch hängt im wesentlichen von den Speicherzellen selbst ab, dagegen kann man erstmal nicht viel machen.

Allerdings: HBM ist von 2017 und wir reizen selbst im Jahre 2020 immer noch nicht die 2TB/s aus, die Nvidia da auf die Folie gemalt hat. Die neuen Highend-Karten werden vielleicht auf 1TB/s kommen, HPC auf 1,5TB/s. Bis man wirklich 4TB/s braucht, gibt es längst HBM3, wo durch gesenkte Spannung und/oder größeren Prefetch der Verbrauch pro übertragenem Bit wieder stark gesunken ist. So wie beim Sprung von GDDR5 auf GDDR6 eben. So lange man noch sinnvoll Grakas auf GDDR-Basis bauen kann, muss man sich keine Sorgen machen, dass HBM nicht mehr reichen könnte, imho.

[MK2]Mythos

2020-06-21, 00:41:45

Da redet man doch eh über reichlich ungelegte Eier, bis wir im Consumerbereich 2TB/s Speichertransferrate sehen und benötigen werden, dauert es doch bei der gegenwärtigen Schlagzahl eh noch mindestens 3 Jahre und wer weiß was wir dann für Speicherlösungen haben werden. Es ist doch hoffentlich konsens dass hbm(xyz) die effizienteste Möglichkeit ist, der GPU Speicher zu spendieren.

BlacKi

2020-06-21, 01:01:21

Mythos;12343864']Es ist doch hoffentlich konsens dass hbm(xyz) die effizienteste Möglichkeit ist, der GPU Speicher zu spendieren.
und warum diskutieren wir darüber?

Mythos;12343864'] dauert es doch bei der gegenwärtigen Schlagzahl eh noch mindestens 3 Jahre
und nv hat schon vor jahren darauf hingewiesen das hbm zwar der next step ist, aber man noch effizienter werden muss. bislang ist keine lösung nach hbm bekannt.

SKYNET

2020-06-21, 11:18:09

Das war und ist eine völlige Fehlinterpretation der Folie.
https://cdn.wccftech.com/wp-content/uploads/2015/12/Nvidia-Looming-Memory-Crisis-SC15-635x291.jpg

Was man auch weiß, wenn man die Folie versteht, da sie HBM als deutlich effizienter gegenüber den anderen Speicherlösungen präsentiert, aber HBM ist leider auch nicht die ultimative Lösung für die Speicherskalierung.
HBM ist geboren, weil GDDR5 (und auch GDDR6) aus der Puste kam, was die Versorgung von sehr hohen Bandbreiten für eine gewisse Wattanzahl und Größe angeht.
Es musste ein fundamental neues Konzept her.
Aber (aktueller) HBM selber wird unattraktiv bei 2-4TB/s, denn dann konsumiert das Speichersystem alleine schon deutlich über 100W.

Es ist im Prinzip nur ein Fingerzeug auf die Zukunft gewesen, die sich wieder als sehr problematisch erweisen wird, wenn es nicht erneut massive Innovationen bei der Speichertechnologie geben wird

HBM ist immernoch die "überlösung" weil rechne mal aus, wieviel GDDR6 brauch für 4TB bandbreite... da brauchst ja nen 2048er interface, das alleine dürfte schon ziemlich hungrig sein, die 64 speicherchips die man als min. brauch ebenso(2.5W x 64 = 160W)... und dann brauchste auch nen PCB das so gross is wie nen mATX board, und weil die signalwege sehr lang ausfallen dürften bei dem speicher = mehr spannung um das zu stabilisieren... kannst also nachher drauf kochen auf dem ding.

für hohe bandbreite ist/war und wird wohl min. bis gddr7 sein: HBM

unl34shed

2020-06-21, 11:21:27

Du vergisst den MemoryController, der noch mal ein Vielfaches der 160W ziehen dürfte...

Berniyh

2020-06-21, 11:29:17

Die Grafik ist bestenfalls misleading. Mindestens hätte man das als Watt pro Bandbreite auftragen können oder irgendwas in der Art.
Dazu noch die fehlenden Labels …

Wenn ich sowas in einem Probevortrag zeigen würde würde das von meinen Kollegen zerpflückt werden.

Aber irgendwas um 4 TB/s Bandbreite kann uns ja auch vollkommen wurscht sein.
1-1.5 TB/s bekommt man locker mit HBM2e hin ohne abgefahrene Dinge zu praktizieren.

SKYNET

2020-06-21, 12:31:46

Du vergisst den MemoryController, der noch mal ein Vielfaches der 160W ziehen dürfte...

bei GDDR nicht anders... ;)

gehe eh davon aus, das der massive sprung bei der leistungsaufnahme der neuen generationen von AMD und NV eh daher rührt, das die speichercontroller komplett aufgebohrt wurden.

unl34shed

2020-06-21, 12:35:58

ich meinte das hypotetische GDDR Interface ;)

Bei HBM scheint das ja recht wenig zu kosten im Vergleich und der Verbrauch hauptsächlich vom Speicher selbst zu kommen

TheGood

2020-06-21, 16:15:00

Stimme dem zu, wenn man sich die letzten Videos von Igor ansieht, kann ein HBM mit seinem SI gar nicht so aufwändiger sein. Aber das sgt ein Laie, ich weiss ja nicht wieviel spannungswandler für hbm benötigt werden.

Langlay

2020-06-21, 16:24:00

Aber das sgt ein Laie, ich weiss ja nicht wieviel spannungswandler für hbm benötigt werden.

https://www.igorslab.de/heisses-eisen-im-test-amd-radeon-vii-mit-viel-anlauf-und-wind-auf-augenhoehe-zur-geforce-rtx-2080/3/?amp=1

Vega20 hat 2 Phasen für den HBM. Ich denke das sollte es auch für BigNavi reichen. Da scheint es keine grossen Probleme zu bekomen bezüglich Stromversorgung.

horn 12

2020-06-21, 16:49:07

Zudem der 7nm Chip größer (um 500mm²) und auch mit 3-fach Kühler zu bängigen wäre
Im Gegensatz zu 331 mm² bei Vega VII

Linmoum

2020-06-21, 16:50:39

Das wäre auch bei der VII gegangen, die Konstruktion war nur ein kompletter fail.

horn 12

2020-06-21, 16:52:23

Horizontale Lamellen hätten schon was gebracht, aber dies war zu sehr ein Schnellschuss...
Trotzdem Geile Karte auch wenn meine Dahin ist.

BoMbY

2020-06-24, 10:15:41

Rytracing-Patentsturm:

WATER TIGHT RAY TRIANGLE INTERSECTION WITHOUT RESORTING TO DOUBLE PRECISION (http://www.freepatentsonline.com/20200193685.pdf)
EFFICIENT DATA PATH FOR RAY TRIANGLE INTERSECTION (http://www.freepatentsonline.com/20200193684.pdf)
ROBUST RAY-TRIANGLE INTERSECTION (http://www.freepatentsonline.com/20200193683.pdf)
MERGED DATA PATH FOR TRIANGLE AND BOX INTERSECTION TEST IN RAY TRACING (http://www.freepatentsonline.com/20200193682.pdf)
MECHANISM FOR SUPPORTING DISCARD FUNCTIONALITY IN A RAY TRACING CONTEXT (http://www.freepatentsonline.com/20200193681.pdf)

Noch ein weiteres neu veröffentlichtes RT-Patent:

Robust ray-triangle intersection (http://www.freepatentsonline.com/10692271.pdf)

Und dazu nochmal das erste:

TEXTURE PROCESSOR BASED RAY TRACING ACCELERATION METHOD AND SYSTEM (http://www.freepatentsonline.com/20190197761.pdf)

Natürlich heißt dass nicht das alles davon tatsächlich zum Einsatz kommen wird, vielleicht sogar gar nichts, aber immerhin scheint AMD nicht komplett untätig gewesen zu sein ...

Edit: Ahh, das war gar nicht neu, das war nur eine neue Nummer und ein "Grant" statt "Application", sorry.

Zossel

2020-06-24, 17:33:16

So die "Binsenweisheit" ist, elektrisch Kurz (im Sinne von, ab wann man Leitungsabschluss/Terminierung für Reflexionsunterdrückung vernachlässigen kann) ist, wenn die Signallaufzeit kürzer ist als 1/6 der Anstiegszeit, was sich Wahrscheinlich nur auf Tankleitungen/Interruptleitungen bezieht, Datenleitungen sind nochmals weniger kritisch

Kriegt man single-ended Leitungen überhaupt hinreichend genau auf eine definierte Impedanz für diesen HF-Kram?

basix

2020-06-24, 18:45:50

Kriegt man single-ended Leitungen überhaupt hinreichend genau auf eine definierte Impedanz für diesen HF-Kram?

Eigentlich alle modernen High Bandwidth Interconnects auf Package- und Chipebene sind heutzutage Single Ended, weil deutlich energieeffizienter als Differential Ended (fast 2x) und fast halbierte Pinzahl, was das Interface anbelangt.

Den "quasi differentiellen" Rückwärtskanal bekommt man oft (meistens?) über GND. Die Impedanzanpassung kann man also via GND-Plane und Leiterbahnform beeinflussen als auch Termination Widerstände in die Chips integrieren. Allenfalls macht man noch ein Link Training darüber, siehe z.B. DDR4.

Beispiele:
Siehe z.B. Nvidia mit GND referenced signaling oder AMDs IFOP SERDES. Hierbei ist oft die Clock Leitung Differential und die Datenleitungen Single Ended. Bei den Datenleitungen ist die Impedanz im Prinzip genau gleich wichtig wie beim Clock, aber aufgrund im Chip eingebauten ECC-Algorithmen werden einzelne Bitfehler bei den Daten toleriert und korrigiert. Beim Clock wäre das deutlich ungünstiger.

Zossel

2020-06-24, 18:58:07

Den "quasi differentiellen" Rückwärtskanal bekommt man oft (meistens?) über GND. Die Impedanzanpassung kann man also via GND-Plane und Leiterbahnform beeinflussen als auch Termination Widerstände in die Chips integrieren. Allenfalls macht man noch ein Link Training darüber, siehe z.B. DDR4.

Nur hat die einzelne Leitung Masse nicht für sich alleine. Wenn nebenan gleichzeitig tausende von Gatekapazitäten umgeladen werden bleibt das nicht ohne Auswirkung auf alles was sich auf Masse bezieht.

BTW: Was ist eigentlich Link Training genau? Zusätzliche schaltbare Widerstände die durch parallelschaltung die Impedanz an die tatsächlichen Gegebenheiten besser anpassen können?

basix

2020-06-24, 21:06:07

Dass die Masse eben "common" ist, ist die Crux am ganzen. SNR ist kritisch. Nvidia hat dort viel in Research investiert. Zum Ground referenced signaling von denen gibt es z.B. ein Paper. Wie das dann im Detail gelöst ist kann ich nicht sagen. Evtl. kann man jeder einzelnen Datenleitung eine leicht zueinander verschobene Phasenlage zuweisen. Damit liessen sich die Transientenströme quasi mitteln und je nach GND und Leitungsimpedanz sehen die Fremdsignale der anderen Datenleitungen dann mehr wie ein DC-Offset aus und entlastet gleichzeitig die Stromversorgung.

Link Training kann eine Impedanzanpassung beinhalten. Kenne mich aber nicht wirklich mit dem Thema aus. Eine andere Möglichkeit wäre, dass der Empfänger den Samplingzeitpunkt variiert und optimiert. Das kann sogar so weit gehen, dass man gewisse Parameter anhand der Temperatur noch weiter beeinflusst ;)

Skysnake

2020-06-24, 21:29:06

Nur hat die einzelne Leitung Masse nicht für sich alleine. Wenn nebenan gleichzeitig tausende von Gatekapazitäten umgeladen werden bleibt das nicht ohne Auswirkung auf alles was sich auf Masse bezieht.

BTW: Was ist eigentlich Link Training genau? Zusätzliche schaltbare Widerstände die durch parallelschaltung die Impedanz an die tatsächlichen Gegebenheiten besser anpassen können?
Basix hat es ja schon angedeutet. Das kann viel oder fast nichts bedeuten.

Im einfachsten Fall werden einfach die Impedanzen durch schaltbare Widerstände/Kapazitäten angepasst. Es kann aber auch sein, das man Signalpegel anpasst, oder die Sampling clock hin und her schiebt.

Alles im Bereich von 2 bis 1024 Einstellungen pro Wert etwa :freak:

Link Training bezieht sich im Allgemeinen aber auf die initiale Herstellung der Verbindung. Das kann bei den neuen HDR Glasfaserkabeln dann durchaus auch Minuten dauern... (Bis zu 15 wenn ich die Release notes richtig im Kopf habe)

Es gibt aber auch Verfahren, insbesondere Anpassungen bezüglich der Temperature die während des Betriebs ablaufen. Das läuft dann aber eher unter Link Monitoring/Tuning.