AMD Radeon: Vega 20 und Vega 12 in Linux-Patches vermerkt
AMD hat in den vergangenen Wochen mehrere Linux-Patches veröffentlicht, die bereits Code für die zwei GCN-Gen-5-GPUs Vega 20 und Vega 12 enthalten. Während bei Vega 20 ziemlich klar ist, dass es sich um einen 7-nm-Shrink für den HPC-Markt handeln dürfte, kann man bei Vega 12 nur raten, wofür der Grafikchip gedacht ist.
Linux-Patches bietet öfters einen Einblick, woran Chiphersteller zurzeit arbeiten. Im Falle von AMD ist das weiterhin die fünfte Generation des Graphics Core Next (GCN) alias Vega. Im Rahmen der CES im Januar 2018 gab AMD bereits bekannt, an einem 7-nm-Shrink einer Vega-GPU zu arbeiten, die für den High-Performance-Computing-Markt (HPC) bestimmt ist. Aufgrund der Positionierung und früherer Leaks ist die Wahrscheinlichkeit hoch, dass es sich um Vega 20 handelt.
Ein Reddit-Nutzer hat Vega 20 nun in einem Linux-Commit entdeckt, der sechs PCI-IDs aufführt. Unterschiedliche Kennungen werden für unterschiedliche Produkte verwendet, beispielsweise verschiedene Ausbaustufen mit voll- und teildeaktivierten GPUs oder aus mehreren Modellreihen à la Radeon Instinct und Radeon Pro. Gerüchte, die nun schon ein halbes Jahr alt, aber bislang noch nicht widerlegt worden sind, gehen davon aus, dass AMD Vega 20 eine 1:2 FP64:FP32-Rate spendieren könnte. Damit handle es sich um einen geistigen Nachfolger für Hawaii, der die doppelte Genauigkeit (Double Precision, FP64) halb so schnell wie die einfache Genauigkeit (Single Precision, FP32) berechnen konnte. Zudem soll das Speicher-Interface 4.096 statt 2.048 Bit breit werden, womit Vega 20 vier HBM2-Stacks mit einer Übertragungsrate von insgesamt 1 TB/s anbinden könnte. Mittels 8 GiByte großen 8-Hi-Stacks ließen sich 32 GiByte Grafikspeicher realisieren, wie ihn bereits Hawaii im Profisegment als Firepro W9100 anbietet.
In einem Linux-Patch wird darüber hinaus Vega 12 vermerkt, bei dem völlig unklar ist, um welche GPU es sich handelt. Spekulationen gingen in Richtung Vega Mobile, einem kleineren Ableger für Notebooks oder der Semi-Custom-Lösung auf Intels Kaby-Lake-G-Package. Ersterer könnte allerdings auch schlichtweg Vega 11 als zweite GCN-Gen-5-GPU heißen, solange AMD V11 nicht eingestampft hat. Ein AMD-Mitarbeiter verriet im Forum von phoronix.com (via 3DCenter), dass Vega 12 noch nicht angekündigt worden sei und es noch keine öffentlichen Informationen zu der GPU gebe.
. AMD bring wenigstens IMMER brauchbare IGP´s raus ganz im Gegensatz zu Intel bisher (Iris Pro aussen vor).
Ich hatte mit meinen AMD APUs schon so oft Pech und Probleme, da ist mir dann doch der zuverlässige Intel Treiber und die angeblich so unbrauchbare Intel iGPU zum Arbeiten lieber.
@Locuza: vielen Dank für die Ausführliche Antwort zum Thema warum Transistoren zu Vega hinzukamen (weiß nicht ob dieser Thread oder ein anderer) um ihn höher Taktbar zu machen.
Dachte, dass diese erwähnten Schritte nicht MILLIARDEN von Transistoren fressen, hab mich wohl geirrt und danke für die Aufklärung.
Das entspricht die Reichweite (max. 1,5Ghz/6,9Tflops) von P10&20
Ein HBM² 4GB stack geht bis 256GB/s
Hier muss HBCC dann die Vorteile ausspielen, um die 6GB der GTX1060 ausgleichen zu können.
Vega22 mit 24/28CUs ist ja schon fertig (mobile). Vega12 könnte schon das Desktop-Pendant sein.
Jede Operation auf einem Chip benötigt Zeit, sei es die Addition, das Dekodieren der Befehle usw.
Dabei wartet die nachfolgende Einheit auf die Daten der Vorherigen um diese dann weiter zu verarbeiten. Das Problem entsteht nun, wenn du mehrere dieser Operationen in einem Takt abarbeiten willst (z.B. Multiplikation und Addition MADD). Braucht die Multiplikation 5ns und die Addition 5ns, musst du der kompletten MADD-Operation (mindestens) 10ns geben um ein valides Ergebnis zu bekommen, damit wäre die effektive Taktung 100MHz. Packst du ein Register zwischen Addition und Multiplikation, wird der Wert zwischengespeichert und jede Einheit kann mit dem für sich maximalen Takt von 5ns/200MHz arbeiten. Nur kosten diese Register Platz, weil das FlipFlops sind. Diese haben dann natürlich auch nochmal Laufzeiten, die dann aber wieder in die Gleichung mit rein wandern, also wäre der effektive Takt wohl eher 150MHz im Beispiel.
Kannst dich ja mal in FPGAs / VHDL einlesen, arbeite da seit einem Jahr in der Branche
Etwas "optimiert" beim Ausdruck und deiner Kritik und vielen Beiträgen würde ich und vermutlich andere in vielen Punkten zustimmen, aber wenn wieder einmal ein Absoluthammer kommt, dann wirst du eben angefahren.
Das dürfte aber jedem aufgefallen sein, das das so ist, das muss man eigentlich nicht mehr drüber diskutieren.
"Ich sehe da Polaris deutlich effizienter. Vega ist einfach eine Katastrophe und kann nichts besser als Polaris (außer Features mit an Board zu haben die im großen und ganzen absolut sinnfrei sind) und Polaris konnte schon nichts besser als Hawai. Und nun lässt man Hawai von den Treibern her verhungern, Hawai wird immer langsamer und fällt immer weiterhinter Polaris zurück und das obwohl Hawai von der Rohleistung locker mithalten kann."
Du sagst pauschal, dass Vega nichts besser kann als Polaris und die Features absolut sinnfrei sind und dann auch noch das Polaris nichts besser konnte als Hawaii.
Das stimmt eben nicht, da es viele Feinheiten gibt und du kehrst alles pauschal unter einem Teppich.
Hätte AMD mal die Extrawürste bei Vega beiseite gelassen, würden sie heute viel besser dastehen.
Spekulativ würde ich den höheren Taktbereich schon dazurechnen, weil der sich bei Vega in der Praxis wenig zeigen kann, dass hätte AMD sich teilweise wohl sparen können, aber der Rest hat schon seinen Stellenwert und wenn du alles streichst und dich nur auf die Performance konzentrieren möchtest, dann bist du auch mittel- bis langfristig in einer ungünstigen Position.
Irgendwann musst du Grundlagen und neue Features etablieren.
Gerade in Bezug auf DX12 war AMD der letzte, welcher FL12_1 implementiert hat und es gibt auch schon Spiele, welche immerhin von den Rendering-Features Gebrauch machen, leider eben noch Nvidia exklusiv.
Und das sagt dir genau wer? Halte ich für reine Spekulation.
Ich denke dass bei Raven Ridge ein großer Anteil an der CPU hängt, was die Mehrleistung der integrierten GPU angeht.
Die alte IGP wird fast durchgängig von der ultralangsamen CPU gebottleneckt.
[Ins Forum, um diesen Inhalt zu sehen]
https://www.hotchips.org/...
Das gilt für die Vega FE mit 484 GB/s und 13,7 TFLOPs als theoretisches Maximum.
Das sind 35,3 GB/s pro TFLOP, wobei in der Praxis eine FE und RX64 eher bei 1400-1500 Mhz anliegt das sind 39,6-42 GB/s pro TFLOP.
Radeon RX Vega 64 & 56 im Test: Der helle Stern wirft lange Schatten (Seite 3) - ComputerBase
RavenRidge darf sich offiziell zusammen mit der CPU 47 GB/s mit Sinlge-Rank DDR4 teilen, bei theoretisch 1,76 TFLOPs wären das nur auf die GPU bezogen 26 GB/s pro TFLOP.
Taktraten der RavenRidge GPU in der Praxis habe ich nicht gefunden, aber es ist wahrscheinlich das diese nicht niedriger am Maximum liegen, als bei den großen Vegas und wenn du sogar nur 5-10GB/s für die CPU abziehst, dann landest du fast bei der Hälfte der Bandbreite pro TFLOP im Vergleich zu den Desktop-Karten.
Und was glaubst du passiert mit den Zahlen da oben in Bezug auf RavenRidge? Die fallen besser aus, weil RavenRidge viel mehr an der Bandbreite hungert.
Kleine Verbesserungen, aber auch Verschlechterungen durch Kastrationen und mangelnder Bandbreite, die Polaris ordentlich einbremst.
Aber klar, so ein Polaris mit 200 Watt Verbrauch ist natürlich ganz doll und enorm besser als Hawai in 28nm.
Du unterschätzt wie gut Hawai war und immernoch wäre.
Ich sehe seit Hawai unterm Strich keine Verbesserungen mehr bei AMD, außer das was der Shrink ohnehin an Effizienzssteigerung mit sich bringt.
Der unterschiedliche Kompromissmix sagt dir nicht zu, meinetwegen, aber das Polaris nichts besser kann ist damit nur pauschale Polemik.
Und es geht ja auch gleich weiter, indem du einfach vermutest das jegliche Effizienzsteigerung sowieso vom shrink kommt und damit die Architektur nichts geleistet hat.
Wenn wenigstens der HBCC funktionieren würde, aber das ist ja auch ein Trauerspiel.
Wieder in der aktuellen PCGH zu lesen. Selbst wenn 10,5GB benötigt werden, bringt der HBCC in der aktuellen PCGH wiedermal nix, so wie er noch nie spürbar i-was gebracht hat.
Sowie z.B. hier nicht:
AMDs HBCC-Feature kann (in der richtigen Situation) bis zu 70% Mehrperformance bringen | 3DCenter.org
Oder 24% bessere Frametimes und 10% mehr FPS unter Anno 2205 oder 13% bessere FPS und Frametimes unter COD.
Dishonored II und Deus Ex auch mit 20% Frametime-Verbesserungen.
Radeon RX Vega 64 & 56 im Test: Der helle Stern wirft lange Schatten (Seite 7) - ComputerBase
Das fällt bei einigen Spielen definitiv in den Bereich von spürbar.
Lässt du die Pauschalaussage mit "hat nie etwas spürbar gebracht" weg, dann kann man dem Ganzen ja in vielen Punkten zustimmen.
Es ist ein Trauerspiel, wenn das Feature im Schnitt keinen Performanceboost bietet und man als Nutzer praktisch keine Ahnung hat, wann der HBCC einem helfen könnte und wann er sogar schadet, weil das hängt stark vom Spiel ab, der RAM-Menge die man zuweist usw.
Als Enthusiast und erfahrener Nutzer, welcher sich auch Berichte durchliest, kann man da einen Mehrwert schon extrahieren, aber wirklich schnigge ist das so sicherlich nicht.
Damit kann ich den Inhalt nicht nachprüfen und er ist für mich wertlos.