AMD Navi: Gerüchte um neuen Cluster-Zuschnitt für mehr Effizienz

Leonidas schrieb:

Schließlich tritt die GeForce RTX 2070 auf Basis des TU106-Chips mit einer ähnlichen Anzahl an Shader-Einheiten (2304) an. Um jene nVidia-Grafikkarte mit 2560 Shader-Einheiten bei der Performance erreichen zu können, müsste AMD letztlich eine vergleichbare Recheneffizienz aufbieten – ein Thema, bei welchem AMD bis zuletzt klar zurücklag. Es wäre ergo ein regelrecht großer Schritt, wenn AMD in dieser Frage mit der Navi-Architektur ein (grobes) Gleichziehen mit nVidia gelingen könnte – gerade auch angesichts der viel geringeren R&D-Möglichkeit von AMD. Einen ersten Hinweis darauf, wie dies ermöglicht wurde, liefert dann die zweite dargebrachte Information, welche auch diejenige ist, welche derzeit noch bei Twitter zu sehen ist: Danach verändert AMD mit der Navi-Architektur den Aufbau der Shader-Cluster von 4x SIMD-16 Einheiten auf 2x SIMD-32 Einheiten. Die Anzahl der Shader-Einheiten bleibt dabei auf 64 pro Shader-Cluster gleich (mit "4x SIMD-16" sind keine 16 Bit gemeint, sondern 16 ALU-Lanes, mittels Multiplikation ergibt sich dann die Anzahl der Shader-Einheiten). Es werden von den zugrundeliegenden Hardware-Einheiten (Vektor-ALUs) somit schlicht weniger, dafür aber entsprechend breitere verbaut.

Laut einem diesbezüglich erhellenden Posting im 3DCenter-Forum liegt der Effekt der ganzen Aktion in einer geringeren Komplexität des Designs, was letztlich zu einer besseren Energieeffizienz führt. Dies wäre ein Grundstein zu höheren Taktraten, welche dann wiederum der Recheneffizienz zugute kommen – und AMD eventuell in die Lage versetzen, mit viel weniger Shader-Einheiten beachtbar mehr Performance zu erzeugen als bei den bisherigen AMD-Grafikchips. Logischerweise kann diese Veränderung des Aufbaus der Shader-Cluster nur ein einzelner Baustein auf dem Weg zu dieser Zielsetzung sein, zum guten Gelingen dürfte AMD noch einiges mehr an der Navi-Architektur herumschrauben müssen.

Zum Vergrößern anklicken....

Gipsel schrieb:

Nur hat Navi offenbar immer noch die gleiche ISA (mit ein paar neuen Befehlen, aber nichts Weltbewegendes [solche kleinen Änderungen gab es auch schon vorherigen GCN-Iterationen]).

==========================

Das sind keine Bits sondern die Anzahl der SIMD-Lanes in einer Vektor-ALU. GCN hat bisher pro CU vier Vektor ALUs verbaut, die physisch 16 Lanes breit sind (16 x 32bit = 512 bit), aber logisch 64 Lanes breite Vektoren verarbeiten (eine Wavefront, also 64x32bit = 2048bit). Eine Vektor-ALU arbeitet also über 4 Takte eine Instruktion ab (wenn es breiter als 32bit pro lane wird [double precision], dauert es länger).
Das Gerücht lautet also, daß es jetzt nur noch zwei physisch 32 Lanes (32 x 32bit = 1024bit) breite Vektor-ALUs geben soll.
Dies würde z.B. erklären, warum es jetzt (also ab Navi) Register-Bank-Konflikte geben kann (falls die Registerfiles identische Bandbreite behalten), da man nur noch 2 Takte (statt 4 Takte) Zeit hat, alle Operanden zu lesen. Selbst bei Hinzufügen eines in der Diskussion stehenden register file caches/result buffers (wie auch immer man das genau bezeichnet), um das zu kompensieren, steht dann bei einer im Prinzip halbierten Bandbreite der Registerfiles pro Flop (gleiche Bandbreite, doppelte Flops pro vALU) eine in der Summe geringere Komplexität und niedrigere Stromaufnahme zu Buche. Ich hatte ja schon mal eine Halbierung der Registerbandbreite (bei Beibehaltung der Größe der vALUs) in den Raum gestellt. Die Verdopplung der vALU-Breite bei Beibehaltung der Registerbandbreite hätte natürlich einen sehr ähnlichen Effekt.
Aber 32 Lanes breite vALUs würde auch bedeutet, daß man mindestens 2 Wavefronts pro vALU benötigt (bleiben aber 4 pro CU), um auch bei reinen vALU-Instruktionen keine Pipeline-Bubbles zu erzeugen, da back-to-back issue von abhängigen Instruktionen mit nur 2 Takten ALU-Latenz vielleicht etwas sportlich aussieht (nur für einfache Bit-Operationen oder Integer-Adds würde es vermutlich gehen), wenn man 1,5 - 2 GHz Takt anpeilt und geringer Stromverbrauch ein Ziel ist (was es bei GPUs immer ist). Bisher haben alle GCN-Varianten 4 Takte ALU-Latenz für die meisten Instruktionen, was dann logisch (da Ausführung einer Wavefront über 4 Takte) zu einem einzigen "issue-Takt" wird (erlaubt das Absetzen voneinander abhängiger vALU-Befehle direkt nacheinander ohne Erzeugung von Pipeline-Bubbles). Das geht dann nicht mehr ganz so. Ist aber vielleicht auch nicht der ganz große Verlust, wenn der Rest stimmt.

Zum Vergrößern anklicken....

PCGH-Redaktion schrieb:

Der Ansatz könne jedenfalls generell richtig sein, denn AMD muss versuchen, GCN näher an die Effizienz der Nvidia-Karten zu bringen, womit architektonische Änderungen durchaus in Frage kommen - wenn auch sicher keine Wunder ohne Neuentwurf zu erwarten sind.

Zum Vergrößern anklicken....

Don-71 schrieb:

, das Navi eine erhebliche Veränderung in der Architektur darstellt

Zum Vergrößern anklicken....

0tze schrieb:

Naja ob das wirklich enorme Veränderungen in der Architektur sind? Kenne mich mit dem genauen Aufbau von Gpu etc nicht aus, da ich nicht aus dem Fachgebiet stamme, aber nur diese eine Änderung von 4x16 auf 2x32 soll amd katapultartig effizienter machen? War da nicht noch massen an HPC Ballast den man entfernen könnte/müsste?

Zum Vergrößern anklicken....

AlexAwesome schrieb:

Da mit Navi von Anfang an der Mainstream angepeilt wurde, kann es sein, dass Navi gar keinen HPC Ballast an Bord hat.
Und angsichts der Steam Charts könnte Navi bei entsprechendem Preis und Performance/Verbrauch die ganzen alten Nvidia Karten ablösen die in Umlauf sind (siehe Top Ten der Charts).

Zum Vergrößern anklicken....

Krabonq schrieb:

Bitte, bitte, bitte hör endlich auf mit diesen dummen subjektiven Bewertungen.
Es ist unerträglich.

Zum Vergrößern anklicken....

Don-71 schrieb:

Das kommt darauf an, was man als HPC oder Compute Ballast bezeichnet?!

In den meisten Neuerscheinungen 2018 und 2019 haben gerade Polaris und Vega erheblich besser abgeschnitten, als noch 2016 und 2017, gerade in letzter Zeit , von wenigen Ausnahmen im AAA Bereich abgesehen, kommen die AMD Grafikkarten bei den neuen Triple AAA Spielen richtig in Fahrt, was nach Spekulationen in verschiedenen Fachforen, durchaus daran liegen kann, das die neuen Spiele mehr auf Compute optimiert sind, und somit AMD seine Rohleistung besser auf die Straße bekommt, insoweit wird AMD bei Navi sicher auch einen Kompromiss suchen, aber wie schon angedeutet wurde, steht bei Navi eindeutig oder ausschließlich die Spieleleistung im Aufgabenheft.

Zum Vergrößern anklicken....