Diskussion zu: AMD Vega Architecture Preview

[Leonidas]

Link zum Artikel:
https://www.3dcenter.org/artikel/amd-vega-architecture-preview

Update 17:58
Schreibfehler gefixt

[HeinLo]

Bitte bitte nicht GCN 2.0 sagen, das stiftet unheilsame Verwirrung.
Wenn ich richtig informiert bin waren wir mit Polaris offiziell schon bei GCN Generation 4. (GCN 1.x Nomenklatur war eine Erfindung von Anandtech)

Die eigentliche Sensation fehlt IMHO in der Zusammenfassung:
Mit der Neudefinition des VRAM als Cache und dem HBM Cache Controller soll auch für Game-Engines die Speicherverwaltung neu geregelt werden. In einem der Videos spricht der Produktmanager David Nalasco davon, dass dies für die Programmierer automatisch gemacht wird, also durch den Treiber auf Basis der API (ich vermute erst ab Vulkan/DX12). Das ist mal wieder so ein Feature das erst Jahre später mal Früchte trägt wenn die 8GB RAM nicht mehr ausreichen, als Cache aber schon...

Ansonsten wird wohl Deferred Rendering bevorzugt und gleichzeitig die Architektur der Render-Backends Geometrie/Compute/Pixel weiter vereinheitlicht. Vielleicht gibt es in der nächsten Gen dann wirklich nur noch generische Compute Units. Schon der Stardock Chefentwickler meinte mal er könnte sich künftig vorstellen nur noch per Compute zu rendern(!)

Bleibt mir nur zu hoffen, dass die bekannte Roadmap Folie genauestens eingehalten wird und Vega etwas früher im Kalenderjahr erscheint als Polaris...

[Gast]

Warum sollte man es als GCN 2.0 bezeichnen?

AMD gibt die Bezeichnugn vor, es ist nicht sehr klug da wieder inoffizeille Bezeichnungen zu nutzen.

Ausserdem ist das "inoffizielle GCN 2.0" doch schon für GCN3 und GCN4 verwendet worden.

[Isch]

Die eigentliche Sensation fehlt IMHO in der Zusammenfassung:
Mit der Neudefinition des VRAM als Cache und dem HBM Cache Controller soll auch für Game-Engines die Speicherverwaltung neu geregelt werden.
Wenn AMD das hinbekommt onChip mit dem Controller die NvMe und Netzressourcen via PCIe direkt anzubinden wäre das genial. Bei dem SSG Prototyp hat man noch einen externen PLX Chip hergenommen, durch die Virtualisierungsfeatures im Fijii war das wohl möglich. Dass das auch beim Gaming das Streaming von Texturen eleminieren könnte war damals schon klar, aber dass AMD darauf konsequent Umschwenkt ist eine echte Überraschung, intern gelöst würden da nochmals Latenzen eleminiert.
Man muss aber abwarten ob das in dieser Generation wirklich schon so daher kommt, der Vega war doch längst fertig im Design, als wir die SSG Prototypen gesehen haben, oder nicht? Oder ist deshalb Vega etwas später dran, weil der PCIe Switch rein musste? Oder war der Prototyp nur dafür da die Softwareentwicklung rechtzeitig anzutriggern? Oder ist das dann erst unter Scalability Next Gen Memory bei Navi in der Pipeline.... Fragen über Fragen...

[HeinLo]

Wenn AMD das hinbekommt onChip mit dem Controller die NvMe und Netzressourcen via PCIe direkt anzubinden wäre das genial.
Im Pro Segment wäre ein schneller GPU-Beschleuniger mit 2-4 M.2 Slots eine feine Sache wenn man dann wahlweise eine Kombination von NV-RAM und Netzwerkadapter drauf packen könnte. Letztere gibt es aber noch nicht sonderlich viele. So ein Rechenknecht wäre relativ unabhängig vom Host-System, das macht bei Renderfarmen und Computeclustern Sinn. Die Richtung wäre zumindest damit möglich, warten wir es ab...

[Gast]

Wenn AMD das hinbekommt onChip mit dem Controller die NvMe und Netzressourcen via PCIe direkt anzubinden wäre das genial.
An sich soll das der HBCC machen, allerdings ist die Bandbreite dessen was real dahinter steckt, also was der HBCC wirklich alleine machen kann und was weiterhin im GPU Treiber gemacht werden muss, recht groß. Das ganze klingt implizit zumindest teilweise programmierbar. Meine Spekulation dazu ist, dass es im besten Fall das System RAM direkt per DMA nutzt, nachdem entsprechende Bereiche per Treiber zugewiesen wurden und ein generisches Interface für block devices. Für direkt auf der Karte angeschlossene SSDs wird da vermutlich weiterhin ein extra chip verbaut werden, der das interface bereitstellt, beim Rest wird das vermutlich das Betriebsystem bzw. der Treiber bereitstellen müssen.
Anderenfalls wäre der HBCC eher ein programmierbares embedded SOC und bei dem Durchsatz müsste das auch noch relativ leistungsstark sein - so wie diverse teure server netzwerkkarten. Möglicherweise überschätze ich aber auch die Komplexität hinter NVMe.
Für mich wirkt es eher so, als ob der Sinn eher darin besteht, dass das für die Programmierung völlig transparent im Hintergrund passiert.