Kacha schrieb:
Andere Frage, tippst du darauf, dass das dynamische CU Clustering Einzug gefunden hat oder nicht? Fuer mich sieht es derzeit nicht so sehr danach aus. Allerdings faellt es mir schwer zu glauben, dass der 128MB Infinity Cache das alles leistet. Ja, Caches koennen extrem viel ausmachen, aber die doppelte Leistung eines 384 Bit Interfaces waere wirklich krass.
Ich sag es ganz ehrlich: Ich rate da nicht, sondern warte ab.
Im gewissen Sinn haben sie ja die »dynamischen« CU bereits bei RDNA mit der WGP/DualCU eingeführt. Wie weit es nun durch die neue Cache-Hiarchie erweitert wurde? Keine Ahnung. Ich muss die Papers sehen, dann kann ich es genauer einschätzen.
Das 128 MB zusätzlicher Cache den Bandbreitennachteil von 256-Bit gegenüber 384-Bit ausgleichen kann? Auf jeden Fall, ob es am Ende die »doppelte« Leistung ist? Jein! Es kommt da auf einige Sachen an. Ich mutmaße nicht umsonst, dass der Infinity-Cache als auch Smart-Access »Nachfolger« des HBCC sind.
RDNA hat bereits massiv beim Cache zugelegt. L0-Caches für die CU (vormals L1), pro Shader Engine ein gemeinsamer L1-Cache von 128 KiB und dann ein großer L2-Cache von 4 MiB. Bereits hier zeigte sich, was AMD vorhat um die GPU unabhängiger von der Bandbreite sowie Latenz des Speicherinterfaces abzukoppeln.
Nimmt man jetzt HBCC - die Grundlage - wendet diese auf die Caches L1 bis zum VRAM an und setzt noch den »Infintiy Cache« als L3 mit 128 MiB dazwischen, dann kann man da wunderbar mit den »Pages« arbeiten.
Dazu kommt, dass AMD mit Vega einen »Tiled-Based-Render« eingeführt hat im Treiber und mit RDNA ben der Wechsle von Wave64 zu Wave32.
Geht man nun einzeln an die Sachen ran, dann ist das alles »unspektakulär«, betrachtet man aber alle im Kontext, verstehe ich langsam, warum sowohl Vega als auch Navi am Anfang »durchwachsen« waren.
HBCC = VRAM <-> System-RAM, nette Idee. Brachte im VRAM-Limit etwas. Die Grundlage der »Pages« als kleinste Block der verwaltet wird, bietet einiges an Potenzial.
DSBR = Umstieg auf einen Tiled-Based-Render. Damals noch 1. Generation. Daher durchaus »Fehleranfällig«. Gleichzeitig, wird das Bild in passende Happen geteilt. Man denke nun an die »Pages« beim HBCC.
Wave64 => Wave32 = Feinere Granulierung bei den Shader-Threads auf der GPU. Bessere Auslastung der ALUs und »kleinere« Datenhunger pro Wave.
Gehen wir nun auf die Pages zurück: DSBR als auch die Umstellung auf Wave32 veringern die »Datenmenge« die pro Tile als auch eben pro Shader benötigt werden. Sieht man sich nun die Pages von HBCC an: Mich würde es nicht wundern, wenn AMD nun eben diesen Pages-Ansatz vom L1 bis zum VRAM nutzt und Pages entsprechend der Tiles aufbaut und im Infinity-Cache die Pages der Tiles aufbewahrt, die nun berechnet werden und dann die Tiles in den L2 und L1 verschieben.
Genau so denke ich auch, dass man darauf achtet, dass Shader einer Tile primär in derselben Shader-Engine ablaufen, so dass man die Querverbindung nutzen kann.
Aber alles jetzt »Rätelsraten«, ich warte auf die Papers!
