Nach dem Launch: Fragen und Antworten zu AMDs RX Vega 64 und 56

AMD gelingt mit den beiden RX-Vega-Modellen der Anschluss an Nvidias Geforce GTX 1070 und 1080. Damit stellt AMD auch im Preisbereich zwischen 400 und 600 Euro endlich wieder eine valide Option dar - allerdings mit ganz eigenen Stärken und Schwächen. Die entscheidenden haben wir bereits in unserem Vega-Launch-Test sowie dem daran anschließenden Gaming-Härtetest beantwortet. Während die Radeon RX Vega 64 in der Regel hinter der GTX 1080 rangiert, kann die RX Vega 56 besser mit Nvidias Referenzmodell der GTX 1070 mithalten. Zudem handelt es sich bei Vega direkt nach dem Launch um die Desktop-GPU mit dem umfassendsten Support für Microsofts DirectX12.

In diesem Artikel wollen wir weitere Punkte klären zu denen Fragen entweder erst später aufgetaucht sind oder zu denen wir erst später eine befriedigende respektive umfassende Antwort bekamen. Wenn Sie weitere Fragen zur Radeon RX Vega haben, von denen Sie realistischerweise annehmen, dass wir sie beantworten können, zögern Sie nicht, uns diese in den Kommentaren zu stellen!

AMD Vega: Verfügbarkeit und Preise

Zum Launch warb AMD damit, dass die Radeon RX Vega 64 "der GPU-König unter 500 US-Dollar" sein solle. Entsprechende Euro-Angebote für 499 Euro für die Vega Standalone-Version - also die reine Karte ohne Bundle - waren ebenfalls verfügbar.

• Vega 64 Black - 499€ (Standalone)
• Vega 64 Black & Silver - 609€ (inklusive Games- oder CPU+MB-Bundle)
• Vega 64 Liquid - 715€ (inklusive Games- oder CPU+MB-Bundle)

Dazu kommt, wie AMD im Nachgang des Launches mitteilte, die RX Vega 56, die für 405 Euro als Standalone-Version ab dem 28. August verfügbar sein soll.

Wie sich herausstellte, gab es die Standalone-Version der Vega 64 allerdings nur in limitierter Stückzahl. Diese seien laut AMD innerhalb kürzester Zeit abverkauft worden und damit nicht mehr verfügbar. Das erklärt auch die Gerüchte, welche besagten, AMD habe die Launch-UVP um 100 Euro angehoben - denn so könnte man die limitierte Stückzahl auch interpretieren. Die unverbindliche Preisempfehlung für die Bundle-Version bleibt laut AMD bei 609 Euro - eventuell höhere Preise, so AMD, lägen am Preisaufschlag durch den Handel, der damit seine Gewinnmarge steigern wolle.

In der Zwischenzeit hat AMD mehrere Statements zu dem Thema veröffentlicht. Man arbeite zusammen mit Partnern und Handel daran, die Lager wieder zu befüllen und man habe an den UVPs nichts geändert. Im Zweifelsfalle lohnt sich für AMDs RX Vega also immer ein Blick in den PCGH-Preisvergleich powered by Geizhals, um die günstigsten Vega-Angebote zu finden.

AMD Vega: Draw Stream Binning Rasterizer

Quelle: AMD AMD Vega Whitepaper DSBR Bandwidth Savings Vega steckt voller, mit klangvollen Schlagworten versehenen Technologien. Zwei davon widmen sich sinnvollerweise der Vermeidung unnötiger Arbeit beziehungsweise dem Einsparen von Speichertransferrate: Eine ist der Draw Stream Binning Rasterizer, kurz DSBR. Eine Rasterisierungseinheit also, welche den Strom an Zeichen-Befehlen vorsortiert. Hinter Ersterem steckt eine Fähigkeit, welche Nvidia beim Wechsel von Kepler auf Maxwell ebenfalls implementierte, darüber jedoch kein Wort verlor - obwohl man sich einig ist, dass dieses Feature zumindest für einen Teil des Effizienzzuwachses verantwortlich zeichnet. Vegas Draw Stream Binning Rasterizer ist AMDs erste Implementierung des TIle-Based-Rendering-Prinzips, Fiji und Polaris bieten das Feature nicht. Folgende Architekturen werden das Prinzip aufgreifen und gewiss weiter verfeinern.

Zum Hintergrund: Da die beste Arbeit die ist, die man komplett vermeiden kann, arbeiten Grafikchips mit einem Tiefenpuffer und vorgezogenen Tests verdeckter Objekte. Liegt beispielsweise eine Kiste hinter einem Haus, braucht diese nicht gezeichnet werden (ZCull), ebensowenig natürlich die Rückseite des Hauses (Backside Culling) oder Dinge, die (seitlich) außerhalb des Blickfeldes liegen (Frustum Culling). Diese Techniken sind schon ziemlich alt und über die Jahre immer weiter verbessert worden. Doch je früher die Arbeit gespart werden kann, desto besser. Darum wird inwzischen auch Geometrie vorab verworfen, die nicht Teil des gerenderten Bildes ist. Doch um final entscheiden zu können, welche Bestandteile einer Szene sichtbar sind, muss diese (tiefen-)vollständig aufgebaut sein, denn nur so können die Z-Werte einzelner Objekte miteinander verglichen werden und der Grafikchip kann entscheiden, ob die oben genannte Kiste hinter dem Haus sichtbar ist. Das bedeutet, dass jeder Tiefenwert in einen Speicherbereich geschrieben werden muss - was wiederum viel Transferrate kosten kann.

Hier setzt nun der DSBR an: Er unterteilt das Bild in kleine Kacheln, welche in einen dedizierten lokalen Speicher oder zumindest den Level-2-Cache passen, und prüft für jede dieser Kacheln die Sichtbarkeit der Objekte. Der große Vorteil: Dadurch, dass alle Sichtbarkeitsprüfungen mindestens im schnellen L2-Cache ablaufen, wird sehr viel Transferrate zum Speicher und damit auch gleichzeitig Energie eingespart. Die Größe der einzelnen Tiles ist vom Treiber abhängig und etwa vom Renderformat konfigurierbar, wie auch der komplette Einsatz des DSBR von Anwendung zu Anwendung oder API zu API unterschiedlich voreingestellt sein kann. Es existieren separate Pufferspeicher für das Binning. Laufen diese Puffer über, wird die Geometrie weiter unterteilt und die Ergebnisse werden von Puffer zu Puffer weitergereicht, was am performantesten über den L2-Cache liefe. In diesem Kontext verwundert es nicht, dass AMD eben diesen L2-Cache gegenüber Fiji von 2 auf 4 MiByte verdoppelt hat.

Unglücklicherweise, so haben wir in verschiedenen Gesprächen und Chats mit AMD-Mitarbeitern erfahren, sind jedoch die Primitive Shader bislang noch nicht aktiv. Auch der DSBR ist nicht durchgehend aktiv sondern für bestimmte APIs wie DX11 freigeschaltet und zudem von einer Treiber-Heuristik abhängig, die über dessen Nutzen entscheidet. So erkennt der Treiber etwa das Trianglebin-Tool, welches zum TBR-Nachweis bei Maxwell/Pascal eingesetzt wurde, entscheidet aber, dass kein Performance-Vorteil aufgrund der Append-/Consume-Charakteristik entstehen würde, und deaktiviert das Feature für die Anwendung. Weiterhin unklar ist, wie sich der Eingriff des HBCC bei der Speichervirtualisierung mit der expliziten Kontrolle über die Speicherbelegung durch Low-Level-APIs wie Vulkan oder DirectX 12 verträgt.

Während die Auswirkungen der Primitive Shader auf die Performance weitgehend unbekannt sind, gibt AMD an, dass der DSBR in geeigneten Szenarien einen Leistungsvorteil von zwei bis zehn Prozent bringen kann. Nicht jede Anwendung ist durch die Speichertransferrate limitiert, sodass der DSBR, auch wenn er wie in Battlefield 4 (AMDs Airfield-Test) etwa über 30 Prozent Transferratenersparnis erreicht, hier nur rund 10 Prozent höhere Fps bewirkt.

AMD Vega: Primitive Shader

Quelle: AMD AMD Vega Whitepaper Primitive Shader In eine ähnliche Kerbe wie der DSBR schlägt der oder die sogenannte(n) Primitive Shader. Dabei handelt es sich um eine Zusammenfassung verschiedener Aufgaben der Vertex- und Geometry-Shader innerhalb der GPU-Pipeline, um - richtig - Arbeit zu sparen. Wie AMD uns unmissverständlich bestätigte, sind Primitive Shader allerdings in aktuellen Treibern noch nicht aktiv - anderslautende Informationen beruhten auf Missverständnissen. Man arbeite derzeit an einer Version, die mangels API-Support erst einmal im Treiber hinterlegt werden solle, um dann bei Bedarf als alternativer Pfad, sozusagen als Umleitung für die normale Bearbeitungsreihenfolge, aktiviert werden zu können. Das klingt ganz nach einer selektiven Aktivierung, solange Spieleprogrammierer dies nicht etwa über Vulkan- oder Open-GL-Erweiterungen (die es derzeit auch noch nicht gibt) aktiv implementieren.

Einmal aktiv, können Primitive Shader dazu genutzt werden, nicht sichtbare Geometrie aus der Pipeline zu entfernen, noch bevor Sie wertvolle Ressourcen im Bereich des DSBR belegen. Primitive Shader können also dem DSBR helfen, effizienter zu arbeiten, indem etwa weniger Geometrie Batches angelegt werden müssen. Im Idealfall reichen die auf der GPU befindlichen, spezialisierten Pufferspeicher länger oder gar für den gesamten Sortierungsprozess aus, sodass der Umweg über mehrere Durchläufe und den Level-2-Cache nicht gegangen werden muss.

Quelle: AMD AMD Vega Whitepaper Vega NGG Fast Path Mittels des "Vega NGG Fast Path", so AMD, sei Vega 10 in der Lage, bis zu 17 Polygone pro Takt zu entfernen - bei einem Limit von nach wie vor 4 gezeichneten Dreiecken pro Takt. Primitive Shader sind wahrscheinlich, sofern gewisse Voraussetzungen wie gemeinsamer Zugriff auf alle Daten, gegeben sind, mit den vorhandenen, DX12-tauglichen Shader-Rechenwerken umzusetzen. Möglicherweise könnte diese Bedingung des gemeinsamen Datenzugriffs einen Probelauf in Architekturen wie Polaris bislang verhindert haben.

AMD Vega: High-Bandwidth Cache und Controller

Für Vega setzt AMD auf High Bandwidth Memory der zweiten Generation: HBM gen2, oft auch noch verkürzter HBM2. Dieser werde laut aktueller Aussage von AMD derzeit ausschließlich von Samsung beigesteuert und bietet im Vergleich zum Vorgänger HBM gen1 höhere Frequenzen und Kapazitäten. Bei der Vega 10 hat AMD aus Kostengründen daher auf die Hälfte des HBM1-Speichercontrollers im Vergleich zum Vorgängerchip Fiji verzichtet, erreicht mit bis zu 483 GB/s aber trotzdem nahezu dieselben Transferraten - bei halbem Materialeinsatz. Im Gegensatz zur Vega Frontier Edition (PCGH-Test), welche mit 16 GiByte ausgestattet ist, müssen AMDs Gamerkarten der RX-Vega-Reihe bislang mit "nur" 8 Gigabyte auskommen.

Doch AMD bewirbt den Grafikspeicher inzwischen als "High Bandwidth Cache", den Speichercontroller entsprechend als High Bandwidth Cache Controller. Das Ganze funktioniert wie virtualisierter Speicher und der HBCC kann den lokalen HBM2 als Cache für die meistbenötigten Daten nutzen. Dessen Größe lässt sich relativ frei wählen - bei den PCGH vorliegenden Vega-Karten und unseren mit 32 GiByte RAM ausgestatteten Testsystemen bis zu 24 GiByte. Praktisch ist, dass das HBCC Memory Segment als einheitlicher Pool erscheint (unified memory), Applikationen sehen folglich nicht 8 + x GiByte, sondern beispielsweise volle 32 GiByte.

GPU und Treiber kümmern sich bei aktivem HBCC um die intelligente Verwaltung der Speicherressourcen, beispielsweise darum, dass häufig benötigte Daten im HBM verweilen und häufig verwendete Pakete aus dem RAM gezogen und danach lokal vorgehalten werden. Das funktioniert nicht nur bei einer Überbelegung, also mehr als 8 GiByte Speicherverbrauch, sondern auch darunter - hier ist die bessere Aufteilung der Daten in Caching-freundliche Pages von Vorteil. Gegenüber der Standard-Zuteilung ("Allocation") lassen sich so effizientere Zugriffsmuster realisieren. Wir haben dem Thema "HBCC" zwischenzeitlich einen eigenen Artikel gewidmet und dort zeigte sich, dass in Einzelfällen bis zu 14 Prozent höhere Fps-Raten möglich sind. Während in unseren Tests vereinzelt zwar die Frametimes schlechter, teils aber auch besser ausfielen, beobachteten andere Tester auch Verschlechterungen speziell bei den 99th-Percentiles (also den verteilten Minimal-Fps).

Zumindest im Launch-Treiber hat AMD den HBCC ab Werk deaktiviert - sie können und sollten ihn aber wieder einschalten. Auf unsere Nachfrage hin sagte AMD, dass man auch bei aktivierten HBCC keine Performance-Nachteile befürchten müsse - umso unverständlicher, warum die Einstellung ab Werk nicht gesetzt ist.

AMD Vega: HBM gen2 und die Temperaturen

Bereits im Test der Vega FE bemerkten wir, dass die Temperaturen des HBM2 mit bis zu 95° Celsius sehr hoch ausfallen und an der spezifizierten Drossel-Grenze von eben diesen 95 ° Celsius liegen. AMD wollte bislang nicht bestätigen, ob diese Temperaturauslesung korrekt ist - wir gehen jedoch davon aus, auch wenn HWInfo64 einige andere Werte bei Vega nicht richtig zuordnet. Jedenfalls erläuterte uns AMD, dass HBM2 beim Temperaturmanagement von Vega mit berücksichtigt wird und entsprechende Maßnahmen getroffen würden, sollte die Throttle-Grenzen von 95 °C erreicht werden. Man drossele zwar nicht den HBM2 selbst, senke aber intern den GPU-Takt, sodass die Belastung und damit auch Leistungsaufnahme sowie Temperatur des Speichers sinke.

Quelle: PC Games Hardware HWInfo64: HBM2-Temperaturen von 95° C beim ETH-Mining. Beim extrem von der Speicherleistung abhängigen Ethereum-Mining mit dem ethminer 0.12.0 zeigte sich auf der Radeon RX Vega 64 dann auch prompt die Auswirkung. Die Mining-Leistung lag Anfangs bei 35,9 MH/s und blieb dort, solange die angezeigte HBM2-Temperatur unterhalb von 85 °C verweilte. Ab 85 bis hinauf zu 95 °C sank die Performance schrittweise zunächst auf 34,9, dann auf 33,3 und auf 32,8 MH/s, um beim Erreichen der 95-Grad-Celsius-Marke dann auf 29,7 MH/s abzufallen. Die in GPU-z, Wattmann oder HWInfo64 angezeigten Taktraten blieben jedoch ohne Indiz für eine Drosselung, die daher wohl rein intern geschieht.

Wichtig: In Spielen haben wir im vergleichbaren Aufbau beim Betrieb mit Werkstaktraten nicht derart hohe HBM2-Temperaturen erreicht.

Beim Umbau auf den Nachrüstkühler Morpheus II sank diese Temperatur übrigens deutlich, ebenso beim manuellen Erhöhen der Lüfterdrehzahlen auf der RX Vega 56 und RX Vega 64. Erstere ist durch ihren niedrigeren Speichertakt ab Werk übrigens bei Weitem weniger anfällig für große HBM2-Hitze: Hier kamen wir selbst beim Ethereum-Abbau nur mit Speicher-OC (960 MHz) und erhöhtem Power-Target (+15%) an die 85-Grad-Celsius-Marke.

AMD Vega: SoC und Infinity Fabric

Vega 10 ist AMDs erste GPU, welche das auf den Ryzen-Prozessoren bekannte Infinity Fabric setzt. Dieses interne Netz verbindet quasi sämtliche internen IP-Blöcke wie etwa den Video-Decoder, das HBM, die Shader-Engines, die ACEs, Display-Engines oder auch den PCI-Express-Anschluss.

Das Infinity Fabric besteht dabei aus einer Control- und einer Datenschicht. Über erstere laufen Sensor- und Steuerdaten, die etwa für das thermische oder Power-Management benötigt werden. Ebenfalls hierüber wird zum Beispiel auch die Kopierschutzkette für HDCP sichergestellt. Über die Datenschicht hingegen werden auch die Nutzdaten zwischen den internen Engines übertragen, auch die gewaltigen Datenmengen zwischen Level-2-Cache und HBM-Speicher. Über das Infinity Fabric wird über ein Priorisierungssystem außerdem sichergestellt, dass zeitkritische Nutzdaten Vorrang haben.

An das Infinity Fabric können zudem weitere IP-Blöcke vergleichsweise einfach und vor allem kostengünstig angeschlossen werden - ob es sich dabei um einen neuen Video-Decoder handelt oder künftig um CPU-Kerne (Stichwort Raven-Ridge-APUs) oder weitere Grafikchips im Rahmen eines Multi-Chip-Modules, welche AMD wie Nvidia erforschen, sei dahingestellt.

AMD Vega: Wofür sind 40% mehr Transistoren als bei Fiji nötig?

Viele Nutzer fragen sich, warum bei Vega 10 im Vergleich zum Vorgänger-Chip Fiji satte 40 Prozent mehr Transistoren nötig sind, wo doch weder Rechenwerke (nach wie vor 4.096) noch Textureinheiten (unverändert 256) oder Rasterendstufen (64 hüben wie drüben) hinzugekommen sind; denn auch die Performance pro Megahertz hat laut gängiger Tests offenbar keine gewaltigen Sprünge hingelegt. Quelle: AMD AMD Vega Techday Vega 10 GPU Um die Komplexität des Chips zu verdeutlichen, hat AMD in seiner Präsentation zu Vega 10 dargelegt, dass allein 45 MiByte an Speicher (SRAM) auf dem Chip vorhanden sind. Ein guter Teil davon entfällt auf die Register-Files der Vektor-Rechenwerke mit insgesamt 16 MiByte, auch die pro Shader-Cluster "NCU" vorhandenen, 64 KiByte fassenden Local-Data-Shares schlagen insgesamt mit 4 MiByte zu Buche. Der von 2 auf 4 MiByte vergrößerte L2-Cache ist ebenfalls ein Brocken. Weiteres "Kleinvieh" sind die Skalar-Register (64 × 3,2 KiB), L1-/Texturcaches (64 × 16 KiB), Color-, Z- und ROP-Caches sowie die L1-Daten- und Instruktions-Caches für die Skalareinheiten, welche sich nunmehr maximal drei der 16 Compute Units in jeder der vier Shader-Engine teilen, sodass ergo mindestens jeweils 24 von ihnen vorhanden sein müssen - auch das sind 50 Prozent mehr als bei Fiji.

Hier schlägt dann auch die von AMD angegebene Aufwendung eines großen Teils der zusätztlichen Transistoren für eine bessere Taktbarkeit durch, denn die zusätzlichen Skalar-Caches sind eingebaut worden, um die Verdrahtungswege zu verkürzen und so den höheren Takt sicherzustellen, und nicht primär, um mehr Kapazität pro CU zur Verfügung zu stellen.

Noch nicht berücksichtig haben wir dabei die lokalen Binning-Caches für den DSBR sowie die Cache-Tags, die im HBCC-Komplex ebenfalls außerhalb der Buffer gespeichert werden können sowie andere, weniger bekannte Caches wie den Parameter-Cache, der etwa in der Xbox Scorpio bereits 1 MiByte fasst und in Vega 10 noch deutlich größer ausfallen dürfte.

Features wie der aufwendigere Rasterisierer, der nun auch Conservative Rasterization (Tier 3) beherrscht oder die doppelte FP16-Rate ("Rapid Packed Math"), gibt es ebenfalls nicht umsonst. In unserer Überschlagsrechnung sind wir bisher allerdings nur auf rund 30 MiByte gekommen - unbekannte Größen etwa für die Geometry-Buffer oder HBCC-Cache/Tags sei dank. Denkbar ist auch, dass bei den SRAM-Zellen einiges an Redundanz vorhanden ist, denn "Reserve"-CUs als Ganzes bietet Vega 10 nicht.

Artikel teilen

Nach dem Launch: Fragen und Antworten zu AMDs RX Vega 64 und 56 Auch nach dem offiziellen Launch der beiden AMD-Vega-Modelle Radeon RX Vega 64 und RX Vega 56 bleiben noch Fragen offen: Ist die derzeitige Performance repräsentativ? Sind Vega-Features wie HBCC, DSBR oder Primitive Shaders aktiv? Wie viel Performance schlummert noch im Treiber? Und nicht zuletzt: Wo bekomme ich die RX Vega 64 zur Launch-UVP von 499 Euro? Wir geben Antworten.

Per E-Mail versenden

94