Ein Blick auf die Effizienz-Features bei GeForce 3/4

20. März 2003 / von aths / Seite 1 von 5

   Das Bandbreiten-Problem

Der Grund, dass 3D-Grafikchips um Größenordnungen schneller 3D-Grafik berechnen können als CPUs liegt darin, dass die 3D-Logikbausteine dafür sehr "stur" sein dürfen. Eine CPU hingegen muss flexibel sein und praktisch jeder Anforderung gerecht werden. Sie bleibt beim Render-Vorgang ja auch nicht untätig, sondern hat beispielsweise auf der Geometrie-Ebene jede Menge Arbeit zu leisten (das ist auch im T&L-Zeitalter nicht anders). Um komplizierte Dinge, wie sie 3D-Rendering darstellen, überhaupt handhaben zu können, wird der Vorgang in viele kleine Schritte aufgeteilt. Für kleine Schritte wird dann die erforderliche Rechenlogik in Hardware gegossen, ebenso natürlich die koordinierende Logik.

Um Berechnungen zu beschleunigen — 3D-Rendering ist Mathematik pur — lohnt es sich, häufig benutzte Logikbausteine mehrfach "einzulöten". Eine CPU profitiert von einem solchen Vorgehen längst nicht immer, da die Auslastung der verschiedenen Einheiten unvorhersehbar und ungleichmäßig ist. Anders bei der GPU, also einem 3D-Grafikchip: Von den Polygon-Koordinaten zum sichtbaren, texturiertem Dreieck sind es im Groben immer die gleichen Schritte. Sehr angenehm ist der Umstand, dass jedes Pixel für sich betrachtet werden kann und vom Nachbarn unabhängig ist. So lässt sich durch eine Mehrfachauslegung der gesamten Render-Pipeline die Leistung entsprechend fast linear steigern (bei den neusten Pixelshader-Pipelines sieht es etwas anders aus, doch das ist für unser Thema nicht relevant).

CPU- und GPU-Pipelines haben jedoch auch einiges gemeinsam: So muss man zwischen "Durchlaufzeit" und "effektiver Bearbeitungszeit" unterscheiden. Der Voodoo Graphics Chipsatz zum Beispiel kann pro Takt einen einfach texturierten Pixel in den Framebuffer schreiben. Dieser kam jedoch mehrere Takte zuvor in die Pipeline. Direkt nachdem der Grafikchip die Daten von der CPU bekommt, dauert es einige Takte bis die Pipeline durchlaufen wurde, und dann purzeln "am anderen Ende" der Pipeline die Pixel heraus.

Der Voodoo2 Chip konnte pro Takt schon zwei Texturen auf ein Pixel applizieren, was im Groben einer superskalaren Architektur entspricht, doch erst der TNT-Chip hat zwei komplette Pipelines. Es ist zu beachten, dass diese "Berechnungs-Röhren" bis heute nicht völlig unabhängig arbeiten: Jede ihrer Texture Stages verwendet z.B. immer dieselben Texturen. Wären alle Dreiecke nur 1 Pixel groß, würde das Vorhandensein von 2 Pipelines nichts bringen. Da Dreiecke jedoch fast immer sehr viel größer sind, hält sich der "Verschnitt" in Grenzen.

Diese Vorrede soll einen Hinweis darauf geben, wie sich die Leistung von Grafikchips steigern lässt: Man verbaut mehrere Pipelines. Leider ist das nur die halbe Wahrheit. Denn egal, was der Grafikchip auch gerade zu tun mag — so gut wie immer gibt es einen Bedarf, auf den Grafikkarten-RAM zuzugreifen, beispielsweise gehen ständig Z-Werte über den Bus (was Z-Werte sind, wird noch geklärt).

Ist der Bus gerade nicht frei, muss gewartet werden, doch das bringt dann gleich alle Pipelines ins Stocken. Solche Zwangspausen kosten dementsprechend viel Leistung. Das Speicherinterface zum lokalen RAM bietet eine gewisse Bandbreite, welche die Leistung des Chips begrenzt. In diesem Artikel geht es darum, welche Möglichkeiten genutzt werden, um dieses Problem in den Griff zu kriegen. Als Beispiel soll uns die so genannte "Lightspeed Memory Architecture" von GeForce3 und GeForce4 dienen, auf andere Chips gehen wir nur am Rande ein.

In diesem Artikel geht es nicht um Maßnahmen, die der Programmierer treffen könnte, sondern nur darum, was der Chip tun kann, wenn die Optimierung für den Anwender völlig transparent sein soll. Was kluge Programmierung — durchaus unter Verwendung chipspezifischer Features — bringen kann, haben wir bereits in einem früheren Artikel gezeigt.

Dass die verfügbare Speicherbandbreite einer Grafikkarte in der Praxis viel eher einen Flaschenhals darstellt als die Füllratenleistung des Chips, wurde frühzeitig erkannt. Die Füllrate ergibt sich, wenn man die Anzahl der pro Takt in den Framebuffer geschriebenen Pixel mit der Taktfrequenz multipliziert. Bei 4 Piplines und 200 MHz sind das dann 800 Megapixel als theoretischer Spitzenwert. Die Bandbreite berechnet sich so: Logische Interfacebreite x Speicher-Taktrate. Beim DDR-Interface verdoppelt sich nicht etwa die Taktrate, wie Marketing-Zahlen suggerieren, sondern die logische Interfacebreite. Das hat ungünstige Auswirkungen, über die noch gesprochen wird.

Im Jahre 1999 stelle sich ungefähr folgende Situation dar: Durch eine Verbreiterung der Architektur — schon die originale GeForce verfügt über gleich 4 Pipelines — und das Aufkommen von 32-Bit-Rendering wuchs der Verbrauch von Bandbreite viel schneller als die verfügbare Speichertechnologie zu liefern imstande war. Mit den Einsatz von DDR-SDRAM war das Problem nicht gelöst, sondern nur vorläufig etwas abgemildert.

   Was kann man tun?

Beginnen wir die Betrachtung mit einer Milchmädchen-Rechnung am Beispiel der GeForce2 Pro.

• Die verfügbare Speicherbandbreite beträgt 128 Bit (Datenleitungen) x 2 (DDR-Technologie) x 200 MHz = 6400 MB/Sekunde.

• Wenn jede der 4 Pipelines pro Takt ein trilinear gefiltertes Pixel erzeugen soll, so benötigt man pro trilinearem Texel 8 Farbwerte aus der Textur, also 8 Werte á 32 Bit = 32 Bytes. Das x 4 (da 4 Pipelines) und x 200 (da 200 MHz Takt) ergibt nun 25600 MB/s, die erforderlich wären. Nicht berücksichtigt ist der Z-Test (Sichtbarkeits-Test), der immer aus einem Lesezyklus besteht und je nach Ergebnis des Tests ("ist das Pixel sichtbar oder nicht?") im Falle der Sichtbarkeit einen weiteren Z-Schreibzyklus und das Schreiben des fertigen Pixels in den Framebuffers nach sich zieht.

Das Problem mit der benötigten Texturbandbreite wird erheblich abgemildert, indem in der Realität aus einem onchip-Cache gesampelt wird. Nur der Cache greift dann je nach Erfordernis über das Speicherinterface auf den RAM zu. Das bringt dann allerdings den Umstand erhöhter Latenzzeiten mit sich — den Cache neu zu füllen, kostet natürlich seine Zeit und dauert länger, als einfach nur ein einziges Pixel über den Bus zu schaufeln. In Wahrheit übersteigt die Z-Bandbreite zum Beispiel die tatsächlich erforderliche Textur-Bandbreite. Unsere Rechnung ist also nicht sehr stimmig, verdeutlicht aber das Problem: Die verfügbare Bandbreite ist bei GeForce2 viel zu knapp, um die theoretische Füllrate zu verwirklichen.

In der Praxis ist das Speicherinterface bis einschließlich GeForce2 eher auf 16-Bit-Rendering ausgelegt und beim 32-Bit-Rendering halbiert sich praktisch die Füllratenleistung (was für die GeForce2 MX übrigens genauso gilt). Um die Füllrate ausschöpfen zu können, müsste die Bandbreite erhöht werden. Da die Speichertechnologie aber schon an ihre Grenzen stößt und mit dem Fortschritt im GPU-Bereich nicht mehr Schritt hält, bleibt nur der Weg, die Nutzung der vorhandenen Bandbreite zu verbessern. Dafür gibt es drei unterschiedliche Ansatzpunkte:

• Methode 1) Vermeidung von "unsichtbarer Arbeit". Viele Pixel werden im Laufe des Renderings überschrieben. Würden sie gar nicht erst gerendert, enfällt für diese Pixel der Tribut an Speicherbandbreite.

• Methode 2) Je nach Entropie-Verhalten Redundanzen in den Daten vermeiden. Was das bedeutet, wird noch Fachwort-frei besprochen.

• Methode 3) Verlagerung von Datenströmen, die normalerweise über den Bus gehen, in den Chip. Denn im Chip selber gibt es praktisch unbegrenzt Bandbreite.

Am konsequentesten ist hier der Kyro-Chip. Er kombiniert Methode 1 mit Methode 3 und ist der effizienteste Multitexturing-Renderer, den es gibt. Wie das genau vor sich geht, soll unser Thema aber nicht sein. Da die Feature-Palette des Kyro auch das für prozedurale Texturen wichtige EMBM (Enviromental Bumpmapping) sowie Dot3 Bump Mapping beherrscht, sind bei entsprechender Multitexturing-Programmierung viele Pixel Shader Effekte möglich.

Dennoch, weil sehr wichtige Features wie Anti-Aliasing und anisotropes Filtering reichlich unoriginell umgesetzt wurden und extrem Leistung fressen, kann man Kyro für heutige Spiele nicht mehr empfehlen. Zumal er wegen mangelndem Support von Cubemaps leider untauglich für die Doom3-Engine ist. Damit soll veranschaulicht werden, dass supergeniale Bandbreitennutzung wenig bringt, wenn Rohleistung und Featureset nicht mehr zeitgemäß sind.

Das Problem mit der Speicherbandbreite hatte auch ATi erkannt, die mit R100 (originale Radeon) erstmalig in ihrer Firmengeschichte einen brauchbaren 3D-Chip entwickelten. Die Radeon bekam ein Maßnahmen-Paket namens "Hyper-Z" spendiert. Wie schon gesagt, fällt auf dem Datenbus ein ständiger Verkehr von Z-Werten an. Es lag nahe, hier anzusetzen, um die theoretisch vorhandene Leistung besser ausschöpfen zu können. Unser Thema ist aber im speziellen die "Lightspeed Memory Architecture" von GeForce3 und GeForce4, abgekürzt LMA.

Die Bezeichnung ist eine weitere Ausgeburt des Marketings, allerdings halten wir den Begriff "Architecture" nicht für zu hoch gegriffen: Eine einzelne Maßnahme bewirkt wenig. Um wirklich etwas zu erreichen, muss die ganze Architektur darauf ausgelegt sein. In der Tat ist LMA dem Hyper-Z (welches weniger Komponenten umfasst) insgesamt überlegen. Auf die in LMA verwirklichten Techniken wollen wir nun konkret eingehen. Dabei sortieren wir sie nach den drei oben vorgestellten Methoden.