Wieso die drei Turing-Chips [1] so vergleichsweise "dick" ausgefallen sind, ergibt sich beim Blick auf die seitens Videocardz [2] freundlicherweise mitgelieferten Blockdiagramme (selbst wenn es sich hierbei nur um Schemabilder handelt): nVidia hat die Shader-Cluster von Turing gegenüber früheren nVidia-Architekturen maßgeblich aufgebohrt, es kommen neben einem extra RT-Core pro Shader-Cluster auch noch 64 Integer-Einheiten sowie 8 Tensor-Cores neu hinzu. Schon allein die letzten beiden belegen im Schemabild mehr Fläche aus die eigentlichen (FP32) Shader-Einheiten, eingerechnet des extra RT-Cores ist es offensichtlich, das hier direkt in den Shader-Clustern sehr viel Chipfläche für die neuen Eigenschaften und Funktionen der Turing-Architektur zur Verfügung steht. Auf den ganzen Chip bezogen kann davon ausgehen, das alle diese Turing-bezogenen Neuerungen für ca. 50-55% mehr Chipfläche (bei gleicher Anzahl an Shader-Einheiten) sorgen dürften.
Dazu gehört vor allem auch ein Punkt, welcher bislang noch nicht thematisiert wurde, sich jedoch klar aus dem zur Verfügung stehenden Material ergibt: Die Shader-Cluster von Turing tragen nur noch die Hälfte an konventionellen Shader-Einheiten – sprich nur noch 64 anstatt der bislang bei nVidias Gaming-Grafikchips üblichen 128 Shader-Einheiten (nur bei den HPC-Chips GP100 & GV100 hatte nVidia bereits nur noch 64 Shader-Einheiten pro Shader-Cluster verbaut). Eine echte Verkleinerung ist dies allerdings nicht, denn da die Anzahl der Shader-Einheiten schließlich weiterhin gewachsen ist, bedeutet dies, das es mit der Turing-Generation nunmehr wesentlich mehr Shader-Cluster gibt – und damit auch mehr Verwaltungslogik samt Level1-Cache. Pro Shader-Einheit gerechnet verdoppelt sich die Verwaltungslogik und der Level1-Cache bei der Turing-Architektur glatt – ob die Register-Files und der Texturen-Cache im gleichen Maßstab mitgewachsen sind, wird später anhand genauerer Daten noch herauszufinden sein.
Da heutzutage keine höhere Texturier-Power mehr benötigt wird, sinkt allerdings auch die Anzahl der Textureneinheiten pro Shader-Cluster von bisher 8 auf 4 ab – was aber letztlich weiterhin zum selben Verhältnis von Texturier- zu Shader-Einheiten von 1:16 führt. Gleiches gilt für die Load/Store-Einheiten in den Shader-Clustern, welche von 32 auf 16 reduziert werden, was ebenfalls pro Shader-Einheit gerechnet keinen Unterschied macht. Allein die Anzahl der "Special Functions Units" (SFUs) hat nVidia mit der Turing-Architektur augenscheinlich maßgeblich reduziert, von vorher 32 pro Shader-Cluster auf nun noch 4, was pro Shader-Einheit gesehen nur noch ein Viertel der früheren Anzahl ergibt. Ob die SFUs bei Turing mächtiger geworden sind oder schlicht weniger gebraucht werden in der heutigen Zeit, muß sich noch ergeben – in aller Regel wird diese Spezialeinheit aber nicht einmal von größeren Hardwaretests erwähnt, scheint also nicht wirklich wichtig zu sein.
| Kepler | Maxwell 2 | Pascal | Turing | |
|---|---|---|---|---|
| gilt für Grafikchips | GK110, GK104, GK106, GK107, GK208 | GM200, GM204, GM206 | GP102, GP104, GP106, GP107, GP108 (nicht für GP100) | TU102, TU104, TU106 |
| DirectX 12 Feature-Level | 11_0 | 12_1 | 12_1 | 12_1 |
| Durchsatz pro Raster-Engine | 8 Pixel/Takt 1 Triangle/Takt |
16 Pixel/Takt 1 Triangle/Takt |
16 Pixel/Takt 1 Triangle/Takt |
? |
| Aufbau der Shader-Cluster | 192 Shader-Einheiten (FP32), 16 Textureneinheiten, 32 Load/Store-Einheiten, 32 SFUs, 8 FP64-Einheiten, 1x Kontrolllogik, 65536x 32-bit Register File (256 kByte), 64 kByte Level1-Cache, 48 kByte Texturen-Cache (GK110: 64 anstatt 8 FP64-Einheiten) |
128 Shader-Einheiten (FP32), 8 Textureneinheiten, 32 Load/Store-Einheiten, 32 SFUs, 4 FP64-Einheiten, 4x Kontrolllogik, 65536x 32-bit Register File (256 kByte), 96 kByte Level1-Cache, 48 kByte Texturen-Cache | 128 Shader-Einheiten (FP32), 8 Textureneinheiten, 32 Load/Store-Einheiten, 32 SFUs, 4 FP64-Einheiten, 4x Kontrolllogik, 65536x 32-bit Register File (256 kByte), 96 kByte Level1-Cache, 48 kByte Texturen-Cache | 64 Shader-Einheiten (FP32), 4 Textureneinheiten, 16 Load/Store-Einheiten, 4 SFUs, ? FP64-Einheiten, 64 Integer-Einheiten (INT32), 1 RT-Core, 8 Tensor-Cores, 4x Kontrolllogik, ? Register File (? kByte), 96 kByte Level1-Cache, ? kByte Texturen-Cache |
| TMU/SE-Verhältnis | 1:12 | 1:16 | 1:16 | 1:16 |
| DP/SP-Verhältnis | 1:24 (GK110: 1:3) | 1:32 | 1:32 | ? |
| wichtige Fortschritte | - | doppelter Pixel-Durchsatz der Raster-Engines, kleinere Shader-Cluster, deutlich mehr Kontrolllogik pro Shader-Einheit, größere Caches pro Shader-Einheit | nominell keine Architektur-Verbesserungen | kleinere Shader-Cluster, mehr Kontrolllogik pro Shader-Einheit, größere Caches pro Shader-Einheit |
Diese insgesamte Änderung am Aufbau der Turing Shader-Cluster ergibt aus unserer Sicht eine exzellente Architektur-Verbesserung zugunsten einer besseren Auslastung der Shader-Einheiten, durchaus nicht unähnlich dem früheren Sprung von der Kepler-Architektur (192 Shader-Einheiten pro Shader-Cluster) auf die Maxwell-Architektur (128 Shader-Einheiten pro Shader-Cluster). Genau über diesen Punkt dürften letztlich die von nVidia schon genannten Performancegewinne pro Shader-Einheit [7] herkommen und Turing somit Takt- und Einheiten-normiert ein deutlich besseres Performancebild als Pascal erreichen lassen. Unklar ist derzeit allerdings noch, wie sich die neuen Integer-Einheiten gut nutzen lassen bzw. welchen Performance-Beitrag jene leisten können. Angeblich lassen sich die neuen Integer-Einheiten gleichzeitig mit den üblichen FP32-Einheiten nutzen – ob dies auch bedeutet, das sich jenen sogar gleichzeitig in voller Anzahl nutzen lassen können, muß sich ebenfalls erst noch ergeben.
Der Großteil dieser Architektur-Verbesserung sollte sich allerdings recht einfach in die Praxis übertragen lassen, da für diese Shader-Cluster-internen Änderungen die Mitarbeit der Spieleentwickler (beispielsweise über extra Render-Pfade) eben zumeist nicht erforderlich ist. Vielmehr muß nVidia einfach mit den Grafikkarten-Treibern eine gewisse Grundlagen-Arbeit leisten, damit jener bei den Turing-Grafikkarten die Vorzüge der Turing-Architektur von ganz alleine richtig ausnutzt. Selbige Arbeit kann schon mit den ersten Treibern auf einem gutklassigen Niveau liegen, ist also normalerweise keine langwierige Angelegenheit. Trotzdem können sich auch im weiteren Verlauf noch nachträgliche Performanceeffekte zugunsten dieser Architektur-Verbesserungen ergeben, wenn sich die Spieleentwickler auf die neuen Gegebenheiten feiner einstellen bzw. später einfach nicht mehr mit Blick auf ältere Beschleuniger entwickeln.