AMD bohrt – nicht wie NVIDIA – einfach die Vec32 zu Vec64-Einheiten auf – was auch möglich gewesen wäre – sondern geht einen anderen Weg, der eine gewisse Flexibilität ermöglicht: Sie fügen einen zweiten Vektor-Pfad in die Vec32 ein, so werden aus den Vec32 nun (vereinfacht) Vec32+32 Einheiten und AMD nähert sich hier ein Stück NVIDIA und Ampere/Ada an.
AMDs Lösung ermöglicht nun zwei Optionen – die NVIDIA bei Ampere und ADA nicht hat, dafür hat das NVIDIA-Design andere Vorteile*:
- AMD kann zwei Wave32-Befehle mit dem gleichen Operator auf einer Vec32+32 ausführen.
- AMD kann einen Wave64-Befehl innerhalb eines Taktes auf einer Vec32+32 ausführen.
Und genau hier liegt aktuell auch ein Teil der Probleme von RDNA3 und warum RDNA3 nicht so schnell agiert, wie man annehmen könnte. AMD kann die Vec32+32 genauso wenig vollständig auslasten, besonders in niedrigen Auflösungen, wie NVIDIA ihre SM mit 64 + 64. Beide Hersteller haben in dieser Generation – und das ist ein Novum – fast das gleiche Auslastungsproblem.
AMD muss ihren Shader-Compiler innerhalb von 3 Generationen erneut umbauen und dieses Mal wird es knackig. Es ist nicht einfach nur eine Umstellung von Wave64 auf Wave32 – was schon zu einigen Problemen führte – sondern AMD muss dem Shadercompiler beibringen, dass er sowohl gleiche aber dennoch unabhängige Operatoren im Shader in zwei Wave32-Befehlen zusammen fasst. Oder, dass der Shader bei Bedarf entscheiden kann, statt einem Wave32-Befehl einen Wave64-Befehl zu nutzen. Möglich ist das – AMD hat Erfahrung mit VLIW-Architekturen, ich schreibe nur TeraScale – gleichzeitig ist das aber aufwendig und komplex.
