Ein erster Blick auf die G80-Technologie

28. Dezember 2006 / von aths / Seite 2 von 5

   Die neuen TMUs

All die schöne Rechenleistung im Shader nützt wenig, wenn nicht auch anständige Texturierungs-Leistung vorhanden wäre. Der G80 hat nach traditioneller Zählweise 32 TMUs (24 bei der GTS-Version), wobei jede TMU pro Takt bis zu zwei bilineare Samples berechnen kann. Dabei müssen die beiden Samples aus derselben Textur stammen. Somit lässt sich trilineare Filterung und anisotrope Filterung beschleunigen. Trilinear anisotrope Filterung ließe sich sogar noch mal zusätzlich beschleunigen. Ob Nvidia diese (völlig legale) Optimierung nutzt, um bei trilinear anisotroper Filterung 25 Prozent der Samples zu sparen, muss noch ausgemessen werden (unser dafür gedachtes Tool hat leider noch einen seltsamen Flaschenhals, so dass wir bisher noch keine vernünftigen AF-Füllratenmessungen vornehmen konnten).

Man darf nicht auf die Idee kommen, von "eigentlich 64 TMUs" auszugehen, weil pro Takt eben nur maximal 32 gefilterte Texel erzeugt werden können. Die 32 G80-TMUs sind jedoch besser als 32 trilineare TMUs, weil auch AF beschleunigt wird. Der NV10-Chip (GeForce 256) hat mit einem ähnlichen System nur trilineare Filterung beschleunigen können. Mit Beschleunigung trilinearer Filterung wird natürlich auch trilineares AF beschleunigt – die GeForce4 Ti konnte jedoch, als Ausnahme, mit zwei vollen bilinearen TMUs pro Pixelpipe erstaunlicherweise bilineares AF nicht beschleunigen, was noch die GeForce3 bot, und die GeForceFX ebenfalls beherrscht.

Wir möchten die Texturfilter-Performance heute nicht en detail behandeln, aber kurz die Frage klären, ob die Bandbreite überhaupt ausreicht, um die TMUs auszulasten. Bei 32-Bit-Texturen und der Annahme, dass pro bilinearem Sample im Durchschnitt ein neues Texel gelesen werden muss (und der Rest aus dem Cache kommt), würden 147,2 GB/s alleine für die Texturen benötigt werden. Bei unkomprimierten 32-Bit-Texturen ist demnach nicht genug Bandbreite da (147,2 GB/s benötigt, nur 86,4 GB/s vorhanden) – doch die Output-Leistung ist noch immer unübertroffen. Bei allen DXT-Formaten (mit maximal 8 Bit pro Texel) ist jedoch genug Bandbreite vorhanden.

Die TMUs sind in gewissen Grenzen entkoppelt. Jede Vec16-ALU verfügt über ihre "vier" TMUs und kann nur diese für ihre Berechnungen nutzen. Diese vier TMUs sind natürlich tatsächlich eine TMU mit vierfach ausgelegten Einheiten, wobei jede der vierfach ausgelegten Filter-Einheiten wiederum doppelt ausgelegt ist. Beim Vergleich der Texel-Leistung mit dem ALU-Durchsatz sind natürlich die Taktunterschiede zu berücksichtigen.

Ein Threading-Mechanismus sorgt dafür, dass während der Texturfilterung die ALU mit Berechnungen für andere Pixel ausgelastet werden kann. Wenn gerade welche anstehen, können die ALUs auch Vertex-Berechnungen vornehmen, während die TMUs für einen Pixelshader Texturen filtern. Den Rechenwerken ist es schließlich egal, woher ihre Daten kommen, und das Unified-Shader-Konzept leitet alle Shader durch dieselben ALUs. Die Daten in korrekter Reihenfolge wieder aus dem ALUs zu bekommen, erfordert natürlich entsprechende Schaltungen, deren Komplexität im Vergleich zum Transistorcount rein für die Rechenwerke oft unterschätzt wird.

Mit dem G80-Threading lässt sich aber keine vollständige Effizienz-Maximierung erreichen. Es gilt also nicht: Anzahl benötigter Takte = Maximum aus TMU-Takten und ALU-Takten. Dies könnte im Einzelfall erreicht werden, muss aber nicht. Trotzdem – das Texturieren blockiert nun im Vergleich zum G70 deutlich seltener die ALUs. Mit dem Threading werden sowohl TMU- als auch ALU-Werke besser ausgelastet, die Pro-Takt-Leistung steigt gegenüber dem G70.

Die G80-TMUs können jetzt auch FP32-Texturfilterung. Das ist kein Wunder, da die Unified Shader ja auch als Vertexshader eingesetzt werden können und man im Vertex-Bereich immer mit FP32 arbeitet, also auch FP32-Texturen nutzen sollte (NV40 und G70 können im Vertexshader auf Texturen nur ungefiltert zugreifen). FP32-Texturfilterung läuft allerdings mit einem Viertel der Geschwindigkeit, FP16-Texturfilterung mit halber Geschwindigkeit im Vergleich zur normalen RGBA8888-Texturfilterung. Natürlich kann man die FP32-Texturfilterung auch für Pixelarbeit nutzen.

Uns ist bisher nicht ganz klar, wie die Filterung von FP16- und FP32-Werten intern realisiert ist. Allerdings ist dies für die Praxis auch nicht von Belang, wichtig ist, dass selbst bei FP16-Texturen pro Takt 32 Texel gefiltert werden könnten – in der Praxis limitiert die Bandbreite. Trotzdem können bestimmte Sachen beim HDR-Rendering auf dem G80 ziemlich effizient berechnet werden. G71 und R580 haben das für sinnvolles HDR-Rendering erforderliche Featureset nur teilweise implementiert, der G80 kann durchweg mit Gleitkomma-Zahlen arbeiten, ohne deswegen die Multisampling-Fähigkeit zu verlieren (G71) oder Texturfilterung einzubüßen (R580).

Nicht nur, dass die Texturierungs-Grundleistung höher ist, trilinear oder 2x AF gibt es zudem (rein von der Füllrate her) kostenlos obendrauf. Die Entkopplung sorgt außerdem dafür, dass sich TMUs und ALUs seltener gegenseitig blockieren. Aus unserer Sicht inakzeptabel ist der Treiber-Standard, der ab 2x AF keine trilineare Filterung mehr bietet. Diese "Optimierung", welche eine volle trilineare Filterung verhindert, muss vom Anwender manuell abgeschaltet werden. Angesichts der extrem guten G80-TMU-Architektur ist uns das völlig unverständlich.

   Die neuen ROPs

Während es acht Shader-Gruppen gibt, sind bei der GeForce 8800 GTX sechs ROP-Gruppen vorhanden, fünf bei der GeForce 8800 GTS (entsprechend der Anzahl der einzelnen 64-Bit-Speicherinterfaces). Pro Gruppe gibt es zwar nur vier Alphablending-Einheiten, aber 32 Z-Test-Units. Sofern Farbe im Spiel ist, lassen sich immerhin noch 16 Z-Test-Units nutzen (diese Optimierung mit verdoppelter Z/Stencil-Testrate für farbloses Stencil- und Z-Rendering gibt es seit dem NV30).

Die G80-ROPs sind demnach für 4x Multisampling optimiert. Die auf den ersten Blick unvernünftig hohe Zahl von bis zu 192 Z-Tests pro Takt – sofern keine Farbe im Spiel ist – bringt Nutzen bei einem vorgezogenen Z-Pass. Bisher dauerte ein vorgezogener Z-Pass im Vergleich zum eigentlichen Rendering noch so lange, so dass die im anschließenden Farb-Rendering gesparte Füllrate damit kaum aufgewogen wurde – zumal der Vertexshader zweimal benutzt werden muss.

Beim G80 stehen die Chancen besser, mit dieser Technik die Gesamtgeschwindigkeit zu steigern, zumal man sich den zweiten Vertexshader-Pass (mittels Zwischenspeicherung der Ergebnisse des ersten Passes) sparen kann. 3D-Engines mit Stencil-Schatten benötigen ohnehin einen vorgezogenen Z/Stencil-Pass. Kurz gesagt: Von der Z/Stencil-Rohleistung profitiert jede entsprechende Anwendung, angepasste Software kann nochmals deutlich effizienter mit der Vertex- und Z/Stencil-Leistung umgehen.

Kein genannter Chip kann seine ROP-Leistung ausnutzen, weil dazu die Bandbreite nicht ausreicht. Warum hat Nvidia trotzdem so viele ROP-Einheiten eingebaut? Die ROP-Units sind im Vergleich zu den ALUs und TMUs relativ klein, somit lohnt es sich, lieber etwas mehr von den ROPs einzubauen, damit die teuren ALUs garantiert nicht ausgebremst werden.