Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsAMD-GPU: Vega 20 erscheint in 7 nm mit 32 GB HBM2 noch dieses Jahr
Na, das ist doch mal eine Überraschung, dass AMD in der Entwicklung eines Produkts dem ursprünglichen Zeitplan voraus ist
Sehr schön auch zu lesen, dass der 7nm Prozess scheinbar schon ganz gut beherrscht wird. Bin gespannt, auf welcher Basis Nvidias nächste Generation basiert: 10nm? Weiterhin 12nm? 7nm wohl (noch) nicht.
Seinem Zeitplan voraus, aber der Konkurrenz trotzdem hinterher.
Kleinerer Fertigungsprozess, aber warscheinlich wie bei der CPU
trotzdem ineffizienter als der Mitbewerber.
Bei jeder AMD Meldung wird das Forum ekstatisch, aber keiner blickt
mal hinter das BlaBla und AMDs Versprechungen. Ein jeder Chip ist im
kleineren Fertigungsprozess zunächst einmal nur kleiner, nicht besser.
Viele lesen nur ein paar Zahlen und bilden sich daraus ihre Meinung.
Don't believe the hype, believe the review.
PS: Die Konkurrenz pennt nicht. Ein gutes Pferd springt nur so hoch wie es muss.
Diese Aussage ist klasse, denn viele hier im Forum glauben nicht mal das Immerhin sagst Du, dass ein Pferd überhaupt noch springt, während viele ja der Meinung sind, dass sich Nvidia komplett auf Pascal ausruhen wird, bis AMD überhaupt mal was konkurrenzfähiges auf den Markt bringt.
Da Nvidia jedoch Gewinne erwirtschaften muss (Investoren ein Gewinn ausschütten, Angestellte bezahlen, ...), muss man auch seinen Bestandkunden (also den Gamern, die bereits mit Pascal-Karten versorgt sind) Anreize geben, auf die nächste Generation zu wechseln. Und genau das bedeutet, dass es zum einen neue Karten geben wird (unabhängig von der Konkurrenz-Situation) und zum anderen, dass sie auch schneller sein müssen. Die Frage ist halt, wieviel schneller sie sein werden
borizb
Der Chip ist kein Konkurrenz Chip zu deinen Gaming Karten sondern ein Chip für HPC Workloads. Gibt es Tests um eine Aussage zu bestätigen ?
Speziell im Bereich Double FP ?
Bei jeder AMD Meldung wird das Forum ekstatisch, aber keiner blickt mal hinter das BlaBla und AMDs Versprechungen. Viele lesen nur ein paar Zahlen und bilden sich daraus ihre Meinung.
Don't believe the hype, believe the review.
Gestern hast Du noch gepostet, dass Intel 28C @5ghz kann und dass das bei AMD nur mit OC geht.
Heute stellst Du die These auf, dass AMD der Konkurrenz hinterher ist. Bestimmt meinst du bei der Anwendungsleistung / €.
Ich stelle die These auf, dass Du Dich mal objektiv mit dem Thema auseinandersetzen solltest.
Die Messlatte ist aber nicht die WX9100 sondern die W9100 https://geizhals.eu/amd-firepro-w9100-100-505989-a1645901.html?show_description=1
Und das Ding basiert noch auf Hawaii. Es ist maßgeblich die DP Performance die man sich vergolden lässt.
Ich denke man wird hier bei einer Vega20 Profikarte sicher bei über 5000€ liegen.
Naja, wenn die SP Werte einer Vega64 nimmt und diese durch zwei dividiert, wären sie höher als die SP Werte der WX9100.
Wenn man bedenkt, dass Vega20 noch mal höhere Taktrate als Vega64 haben könnte.
Wow. 54% mehr Hardwareaufwand. Liegt vielleicht daran, das Vega eben eine Allroundkarte ist, wo eben aufgrund von Finanziellen einschränkungen keine beschnittene reine Gaming GPU produziert werden konnte.
Vega ist keine AllRound Karte. Sie ist genauso um Computing beschnitten wie die Nvidia Pendants. Das war auch Fiji schon. (Speziell bei FP64 war Hawaii die letzte richtige Computing Karte)
Meanwhile it’s interesting to note that while Vega 10 is a replacement for Fiji, it is not a complete replacement for Hawaii. 2013’s Hawaii GPU was the last AMD GPU to be designed for HPC duties. Which is to say that it featured high FP64 performance (1/2 the FP32 rate) and ECC was available on the GPU’s internal pathways, offering a high reliability mode from GPU to DRAM and back again. Vega 10, on the other hand only offers the same 1/16th FP64 rate found on all other recent AMD GPUs, and similarly doesn’t have internal ECC. Vega 10 does do better than Fiji in one regard though, and that’s that it has “free” ECC, since the feature is built into the HBM2 memory that AMD uses. So while it doesn’t offer end-to-end ECC, it does offer it within the more volatile memory. Which for AMD’s consumer, professional, and deep learning needs, is satisfactory.
Using its many Pascal-based GPUs, Nvidia is surgical about segmentation. The largest and most expensive GP100 processor offers a peak FP32 rate of 10.6 TFLOPS (if you use the peak GPU Boost frequency). A 1:2 ratio of FP64 cores yields a double-precision rate of 5.3 TFLOPS, and support for half-precision compute/storage enables up to 21.2 TFLOPS. The more consumer-oriented GP102 and GP104 processors naturally offer full-performance FP32 but deliberately handicap FP64 and FP16 rates so you can’t get away with using cheaper cards for scientific or training datasets.
Conversely, AMD looks like it’s trying to give more to everyone. The Compute Unit building block, with 64 IEEE 754-2008-compliant shaders, persists, only now it’s being called an NCU, or Next-Generation Compute Unit, reflecting support for new data types. Of course, with 64 shaders and a peak of two floating-point operations/cycle, you end up with a maximum of 128 32-bit ops per clock. Using packed FP16 math, that number turns into 256 16-bit ops per clock. AMD even claimed it can do up to 512 eight-bit ops per clock. Of course, leveraging this functionality requires developer support, so it’s not going to manifest as a clear benefit at launch.
Double-precision is a different animal—AMD doesn’t seem to have a problem admitting it sets FP64 rates based on target market, and we confirmed that Vega 10’s FP64 rate is 1:16 of its single-precision specification. This is another gaming-specific architecture; it’s not going to live in the HPC space at all.
Das Abspecken von FP64 ist ja genau das was die Geforce im Gaming so "light" macht und der eigentliche Unterschied zur GP100/GV100.
Gut möglich dass die Vega 20 genauso 4096 Shader hat aber nun wieder ne FP64 rate von 1/2 FP32.
Edit.
Nett wäre zeitnahe ein Vega 12 Chip mit 2x4 oder 2x8 GB bei 1250 Mhz HBM und TSMC 7nm Fertigung
Auch gerne um GPGPU Mist bereinigt den ich nicht brauche.
Ergänzung ()
schon 2016 wusste man wohl ziemlich gut wie Vega 20 aussehen wird
Now here’s something interesting that we didn’t know yet. Vega20 will use 7nm GFX9 architecture. It will feature 32GB of HBM2memory with 1 TB/s of bandwidth.TBP is around 150W and it will support PCI-Express 4.0. It will also have 64 Compute Units.
Gute Frage. Was genau hat der eigentlich für Vega geleistet? Er war / ist ja so eine Art GPU-Guru (?), oder?
Wieviel von diesen ganzen „exciting“ Features kommen von seinen Ideen?
Auch wenn einige dann im Mainstream eher nich‘ so doll funktioniert haben, hat AMD ja eine Menge in Vega reingesteckt. War das schon Richtung Next-Gen? Oder hat er nur GCN optimiert?
Selbstverständlich wußte man 2016 wie Vega 20 aussehen wird. Das ist bei den Zeiten, die die Chipentwicklung braucht, völlig normal. Als Daumenregel kann man annehmen, daß 3 Jahre, bevor das erste Die aus dem fertigen Wafer geschnitten wird, Entwicklungsstop für Features ist. Ab da wird nur noch an der Realisierung gearbeitet und alles Neue wandert in die nächste Generation. Grundsätzliche Änderungen sind dann natürlich noch möglich, aber sehr teuer.
BTT:
Wolfgang schrieb:
Anhand der von Lisa Su gezeigten Vega-20-GPU lässt sich auch die Chipgröße ungefähr abschätzen. Demnach wird Vega 20 um die 350 mm² groß sein, sodass die GPU zwar deutlich kleiner als Vega 10 wäre (486 mm²), aber noch ein gutes Stück größer als Polaris 10/20 (232 mm²).
@rg88: about Khoduri: Man weiß es eben nicht. Vielleicht hat er ja ganz entscheidend zu Next-Gen beigetragen und man sieht die Früchte seiner Arbeit erst wirklich ab 2019.
Jim Keller meinte ja auch über seine Zeit bei AMD, dass das Design eigentlich schon fertig war und er „nur noch“ beim Feinschliff mitgeholfen hat.
Was ich sagen will: Da ja doch sehr viel Zeit vergeht, bis ein Design tatsächlich mal zu Kaufen ist, halte ich es für gut möglich, dass wir Khoduries Arbeit erst mit Na i oder Next-Gen sehen.
@rg88: about Khoduri: Man weiß es eben nicht. Vielleicht hat er ja ganz entscheidend zu Next-Gen beigetragen und man sieht die Früchte seiner Arbeit erst wirklich ab 2019.
Sehr unwahrscheinlich. Zumal du wohl die Rolle von ihm nicht verstanden hast. Er leitete die Projekte, er entwickelte sie aber nicht und war auch kein Archiekturarchitekt in seiner Position.
Er ist eher ein klassischer Fall des Peter-Prinzips
Unnu schrieb:
Jim Keller meinte ja auch über seine Zeit bei AMD, dass das Design eigentlich schon fertig war und er „nur noch“ beim Feinschliff mitgeholfen hat.
Quatsch. An diesem Satz stimmt überhaupt nichts. Da verdrehst du jetzt quasi alles.
Keller kam 2012 zurück zu AMD. Damit begann dann die Zen-Entwicklung. Eine neue Architektur dauert in etwa 5 Jahre.
Keller hat das Grunddesign gelegt auf der "grünen Wiese" und ein Team gebildet für die Entwicklung. Dieses Team hat dann nach dem Weggang den Feinschliff übernommen, ebenso wie diese Leute jetzt Zen+ entwickelt haben und Zen2 sowieso deren Nachfolger entwickeln.
Er war quasi fertig mit seiner Arbeit und ist dann zum nächsten Projekt und damit Arbeitgeber weitergezogen. Das Bugfixing und Optimierungen der Flaschenhälse ist nicht sein Gebiet, dafür gibts dann andere im Team.
Unnu schrieb:
Was ich sagen will: Da ja doch sehr viel Zeit vergeht, bis ein Design tatsächlich mal zu Kaufen ist, halte ich es für gut möglich, dass wir Khoduries Arbeit erst mit Na i oder Next-Gen sehen.
Ja, im Schnitt 5 Jahre. Aber solange haben schon die HBM-Karten gebraucht. Unter seiner Führung wurde faktisch kein erfolgreiches Projekt abgeschloßen, welches sich signifikant am Markt behaupten kann ohne über den Preis zu agieren. Der Mininghype war reines Glück und Zufall, nicht aber eine geplante Sache.
Hätte er ein tolles Produkt in der Pipeline gehabt, dann hätte er sicherlich davor noch die Lorbeeren eingeheimst.
Nicht ohne Grund wurden jetzt Entwickler von der CPU-Schiene zur Grafiksparte rübergeschoben um die Scherben aufzukehren und die Sparte wieder auf die richtige Bahn zu prügeln.
mMn war es ein Fehler, dass man der RTG soviele Freiheiten und autarkes agieren erlaubt hat. Er hatte das schlicht nicht im Kreuz das zu leiten.
Seine Entscheidung war es sich auf KI, AR und VR zu konzentrieren, was bisher alles erfolglos blieb. So etwas bindet nunmal massiv Ressourcen die man lieber in die normale Grafik-Chipentwicklung gesteckt hätte. Fertigungsprobleme kann man hier nicht vorschieben, dafür ist man mittelweile viel zu breit mit dem Fuß in der Tür bei diversen Auftragsfertigern. Das ist rein eine fehlerhafte Stratgie die er angewendet hat.
(siehe die großen Vega: mehr Transistoren um die Taktraten zu erhöhen. Funktioniert, hatten wir aber schon mal und nannte sich Pentium 4/Netburst. In der Theorie gut, in der Praxis massive Verschwendung von Siliziumfläche mit dem negativen Effekt, dass die Effizienz massiv sinkt und die IPC dabei auf der Strecke bleibt. Über den Takt wurde noch nie ein Prozessorkrieg dauerhaft gewonnen, das muss immer Hand-in-Hand gehen mit Architekturverbesserungen)
Ergänzung ()
drago-museweni schrieb:
Vielleicht als Vega 60 und 68, oder 66 und 74 wie auch immer ich hätte dann gerne eine wenn zumindest an der Baustelle Stromverbrauch sich einiges tut, Leistung darf natürlich auch gerne da sein...
Unwahrscheinlich. Die Architektur skaliert ja schon nicht mal mit 64 CUs wirklich.
Ergänzung ()
pipip schrieb:
syfsyn
Nur weil Navi (vermutlich) die letzte Ausbaustufe von GCN ist, heißt das lange nicht dass man nicht an der Kommunikation Anpassungen gemacht hat, sodass man ein MCM Chip machen kann, ähnlich wie es bei Ryzen der Fall ist.
Immerhin Gibt es schon den Die Verbund Zen mit Vega (RavenRidge). Das hat nichts direkt mit den CUs zu tun.
Raven Ridge hat zwei Dice auf einer gemeinsamen Siliziumfläche, also genau das Gegenteil eines MCM.
Der Vergleich mit Zen hinkt sowieso. Die CPU-Kerne arbeiten unabhängig von einander. Die Fläschenhälse sind hier eben genau die Kommunikation der Cores untereinander, besonders wenn diese nicht im selben CCX sind. Extrem, wenn es über mehre Dice geht wie bei TR und EPYC.
Bei einer CPU kostet sowas "nur" Leistung, bei Grafik muss aber die Ausgabe in quasi Echtzeit erfolgen. Das ist ein ganz anderes Problem und damit überhaupt nicht vergleichbar mit CPU-Kernen, was die GPU-Kerne da leisten müssen. Das Synchroniseren über mehrere Dice hinweg auf einem MCM wird die Hölle sein, was die Qualität, Leistung und Treiberarbeit angeblangt. Für GPGPU-Berechnungen sicherlich brauchbar, aber für Gaming? Sehr zweifelhaft, außer die haben plötzlich den heiligen Gral der Interchip-Kommunkation entdeckt. Die höhreren Latenzen lassen sich nunmal nicht wegdiskutieren
@rg88 : Nope verstanden ist das falsche Wort. Seiner Vita nach zu urteilen hätte er auch Architekt sein können.
Dass er "nur" Oberaufseher war, war mir nicht klar. Naja, PP vielleicht bei AMD, aber vorher hat er wohl nicht nur Murks gebaut.
--
Yupp, da habe ich mal was falsch gelesen - und finde das jetzt nicht mal mehr - Thnx for the lesson. Appreciated.
--
Tjoah, dann verantwortet er also den Bulli der AMD-GPU Geschichte. Auch ein Achievement.
Bei einer CPU kostet sowas "nur" Leistung, bei Grafik muss aber die Ausgabe in quasi Echtzeit erfolgen. Das ist ein ganz anderes Problem und damit überhaupt nicht vergleichbar mit CPU-Kernen, was die GPU-Kerne da leisten müssen.
Anderes Problem, ähnliche Ideen, gleiche Umsetzung ?
Es würde schon reichen, wenn zwei "G"CX einfach aufteilen, was sie berechen. Bei MGPU wird bsp das obere und das untere Bild jeweils von einen Chip berechnet. Natürlich wäre ein "nativer" chip da schneller, aber eben teurer in der Produktion und für AMD könnte sich so eine Lösung ähnlich wie bei Zen auszahlen. Mehr Geld würde dann aber im Bereich Software investiert werden müssen.
Speziell selbst wenn man nur Performance durch die Sync verlieren würde, könnte man vllt dafür jeden Chip (die kleiner sind, aber vllt dafür höher Takten können) besser auslasten.
Aber wer weiß, vllt kommt alles ganz anders und Navi wird sowas nur am Rande betreffen (oder eben gar nicht)
@pipip
"Bei MGPU wird bsp das obere und das untere Bild jeweils von einen Chip berechnet. "
Wenn die Idee funktionieren würde, denkst du nicht, dass hätte man bereits bei SLI/Crossfire umgesetzt?
So einfach wird das wohl kaum sein.
ich könnte mir wiederum vorstellen das bei GraKa s , das statt eines CCX mit 4 Kernen halt eine Vega/ Navi GPU genommen wird , und davon dann halt 2 auf einem Die in 7 nm , es würden ja 2560 Shader pro Gpu Kern reichen - zusammen hätten sie dann 5120 Shader unter 7 nm dürfte die Leistungsaufnahme trotzdem bei 200 Watt bleiben .
Es würde ja reichen wenn die 2 GPU Kerne zusammen 70 % mehr am Leistung erreichen als eine Vega GPU - man wäre dann im 1080 TI Bereich , nur muss vermutlich des öfteren der Treiber auf das Game angepasst werden , wie bei CrossFire auch , ob man das durch eine intelligente Ansteuerung umgehen kann auf dem Die ? wer weiß ?
dazu fehlt mir das nötige Fachwissen .
Ich denke AMD hat das deswegen nur noch nicht versucht , weil es einfach zuviel Leistungsaufnahme hätte bei 14 nm.
Das Problem bei AMD ist einfach , das die reine Rohleistung sich nicht in FPS niederschlägt , mal abgesehen von Nvidias Game Abwürg Technologie + Partner Programmen ...
Mehr Shader an sich bringen nur begrenzte Mehrleistung in Games , wären mehr Games auf Vulkan basierend wäre es vermutlich anders , aber so...
Das ändert doch nichts am Grundproblem. Egal ob die Chips nun aufeinander oder nebeneinander sind. Es bleibt dabei, dass diese nicht als Einheit fungieren. Das funktioniert bei Speicher, weil es da nichts gibt, was voneinander abhängig wäre.
MK one schrieb:
das statt eines CCX mit 4 Kernen halt eine Vega/ Navi GPU genommen wird , und davon dann halt 2 auf einem Die in 7 nm
Damit hast du dann die Qudratur des Kreises erfunden.
1. das gibt es schon mit den einzelnen „Kernen“. Nennt sich bei AMD CU (Compute Unit), welche bei zB vega64 wenig überraschend 64CUs bedeutet.
2. es ergibt keinerlei Sinn, dass man quasi 2 „GCX“ mit 32 CUs auf einen Die klatscht. Damit hast du sogar noch mehr SIliziumfläche vergeudet, holst dir alle Nachteile von getrennten Einheiten, wie höheren Synchronisarionsaufwand.
3. Man kann die „Kerne“ doch bereits jetzt durch die Anzahl der CUs quasi beliebig erhöhen. Das Problem dabei ist, dass man diese nicht im gleichen Maße auslastet und damit die Skalierung nicht ebenso ansteigt wie die theoretischs Mehrleistung. Das ist aber bereits ein Grundproblem der Architektur. Das dann noch auf 2 logisch getrennte Einheiten aufzuteilen würde das noch mehr verschlimmern. Das hast du ja bereits selbst geschrieben
- Thnx for the lesson. Appreciated.
