HSR: Hidden Surface Removal

14. November 2002 / von aths / Seite 3 von 5

   HSR in Hardware (Fortsetzung)

Nur Gigapixel (erst von 3dfx gekauft, dann von nVidia beim 3dfx-Ende mit übernommen) entwickelte für den PC-Markt ebenfalls die Technik, HSR komplett vor dem Rendering zu machen. Der Gigapixel-Chip war dem Kyro von den "Features" her zwar unterlegen (nur DirectX6, Kyro ist DirectX7 compliant), hatte aber viel mehr Rohpower: Statt 2 Pipelines á 1 TMU verfügte er über 4 Pipelines á 2 TMUs. 3dfx wollte die Gigapixel-Technologie für die Generation nach dem Rampage (also "Mojo") übernehmen. Was nun nVidia mit der Technik vorhat, ist nicht bekannt - immerhin haben sie sich ein paar Patente sichern lassen, welche für deferred Rendering zu gebrauchen sind.

PowerVR entwickelte schon früher Chips für den PC-Markt (z.B. PCX1, oder den brauchbareren PCX2) und auch die Grafik-Hardware für den Dreamcast (der nicht mehr hergestellt wird). Gigapixel stand mit Microsoft in Verhandlung, um die Grafik für die Xbox zu liefern, aber nVidia bekam dann den Auftrag. Sowohl im PC- als auch Konsolen-Bereich hat diese Technik also einen Rückschlag erlitten. Es gibt allerdings ernsthafte Anzeichen, dass PowerVR einen Kyro-Nachfolger entwickelt, welcher die Kyro-Effizienz mit vollwertigem DirectX9-Support kombinieren soll.

Solche Verfahren neu zu entwickeln und in Hardware zu gießen, ist aber teuer, weshalb ATi und nVidia lieber ihre jeweiligen Methoden verfeinern. Die GeForce4 hat die meisten Radeon 8500 Features diesbezüglich übernommen, während die Radeon 9700 mit flexibler Kachel-Größe und verbesserten Komprimierungs-Verfahren die HyperZ-Technologie so effizient machte wie noch nie. Vom NV30 ist wiederum eine weitere Verbesserung zu erwarten.

Ob sogenannte Immediate Renderer auch langfristig gegen Deferred Renderer Bestand haben, ist strittig, denn trotz der Effizienz-Nachteile waren alle bisherigen Spitzen-Rennpferde immer Immediate Rendering Architekturen. Ob sich die Steigerung der Integration immer weiter vorantreiben lässt, Multichip-Architekturen eine Neugeburt erleben oder sich zunächst Deferred Rendering durchsetzt - die Zukunft wird es zeigen.

T&L kann der CPU zwar etwas Rechenlast abnehmen, aber praktisch nichts fürs HSR tun. Da Backface Culling (worauf wir gleich eingehen) erst nach der Transformation appliziert werden kann, kann T&L in dieser Hinsicht auch für erhöhte AGP-Buslast sorgen, da erst einmal alle Dreiecke zur Grafikkarte müssen.

Sinnvoller T&L-Einsatz arbeitet allerdings mit Meshes und/oder Vertex Buffern, wodurch dieser Nachteil weniger ins Gewicht fällt. Dazu muss die Engine allerdings extra für Hardware T&L ausgelegt worden sein. Ein einfacher Patch, der dafür sorgt, T&L nun über die Grafikkarte machen zu lassen, hat nur in den seltensten Fällen für Leistungssteigerungen gesorgt. In OpenGL war Hardware T&L dagegen von Anfang an vorgesehen, hier profitieren Anwendungen, wenn bei der Programmierung die empfohlener Richtlinien eingehalten wurden, mehr.

   HSR in Software

Dass Hardware und Software zusammenspielen müssen, ist eine Binsenweisheit. Man kann auf Software-Seite einiges tun, um wenigestens teilweises HSR zu machen. Hierbei ist klar, dass jeweils nur ganze Dreiecke rausfliegen können. Wenn ein Dreieck nur teilweise abgedeckt ist, wäre es zu CPU-aufwändig, es in Unter-Dreiecke zu zerlegen, um nur die sichtbaren Teile rendern zu lassen. Die zusätzlichen Eckpunkte, die dabei entstünden, würden im übrigen auch die AGP-Buslast erhöhen.

Eine sehr alte Methode für HSR in Software wäre das "Backface Culling". Hat man einen geschlossenen, konvexen Körper, kann man ja nur auf die Vorderseite der Oberfläche sehen. Beispielsweise die Kugel-Innenfläche ist nicht sichtbar. Werden die Dreiecks-Koordinaten im Uhrzeigersinn angegeben und sind sie nach der Transformation im entgegengesetzten Uhrzeigersinn ausgerichtet, so bedeutet dies, das man die "Rückseite" vor sich hat, die man wie gesagt ohnehin nicht sieht. Damit kann das gesamte Dreieck rausfliegen. Backface Culling kann übrigens auch in Hardware gemacht werden. Man spart also bei einzelnen Objekten rund 50% Dreiecksfläche.

Alte Software-Engines arbeiten selten mit einem Z-Buffer, weil das eine Masse an ineffizienten Hauptspeicherschreibzugriffen bedeutet. Eine Methode war, zunächst alle Dreiecke zu sammeln und sie dann von hinten nach vorne zu sortieren. Dann wurde das Bild aus der Tiefe heraus bis in den Vordergrund aufgebaut, wobei neue Dreiecke (die also weiter vorne stehen) die alten (die im Hintergrund stehen) einfach übermalten.

Diese Methode leidet aber an einer Reihe von Nachteilen. Zunächst kostet das Sammeln der Dreiecke Speicherplatz und das Sortieren Rechenzeit. Je nach Lage der Dreiecke ist eine exakte Sortierung, die Überdeckungsfehler immer ausschließt, praktisch nicht möglich. Mit steigender Polygonzahl wird dieses Verfahren sehr ineffektiv, für kleine und einfache Körper wird es in Verbindung mit Backface Culling aber noch heute eingesetzt, zum Beispiel bei Java-Software-Renderern.

Einige alte DOS-Computerspiele, wie z.B. Golfsimulationen, haben eine Adaption dieses Verfahrens aber mit Erfolg angewendet: Bäume und Sträucher wurden als einfache Textur mit Transparenz-Information abgespeichert, und ein Aufbau aller Flora-Texturen von hinten nach vorne ergab dann eine gefällige Grafik.

Für 3D-Grafikkarten ist aber eine genau entgegengesetzte Dreiecks-Sortierung von Vorteil. Denn würde von hinten nach vorne gerendert, müsste für jedes neue Dreieckspixel ein neuer Z-Wert geschrieben werden. Bei einen Bildaufbau von vorne nach hinten würde hingegen Z-Bandbreite eingespart, da bei "weggeworfenen" Pixeln der Z-Schreibzugriff entfällt. Neue Hardware, die über das EarlyZ-Test Feature verfügt (Z-Test vor dem Rendering), kann dank so genanntem Front-to-Back-Rendering sogar richtig Füllrate sparen, da hier ja nicht nur der finale Z-Schreibzugriff, sondern gleich auch das Rendering des Pixels entfällt.

Allerdings bedeutet Dreiecks-Sortierung gerade bei heutigen Polygonzahlen erhebliche CPU-Rechenzeit. Außerdem muss berücksichtigt werden, dass jeder Textur-Wechsel das Rendering für eine kurze Zeit stocken lässt. Unnötige Textur-Wechsel zu vermeiden kann sinnvoller sein, als Füllrate zu sparen. Aus diesem Grunde ist es eher üblich, dass nur jeweils die Rendering-Reihenfolge ganzer Objekte sortiert wird. Aber das ist noch nicht alles, was die 3D-Engine fürs HSR tun kann.