HSR: Hidden Surface Removal

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

   HSR in Hardware (Fortsetzung)

Die Kachelung des Z-Buffers hat komprimierungstechnisch Vorteile: Es ist wahrscheinlich, dass die Z-Werte um ein bestimmtes Pixel herum ähnlich sind. Damit wiederholen sich zwangsläufig bestimmte Bitfolgen in den Z-Wert-Bitmustern, was die Komprimierung erst möglich macht. Ziemlich effektiv wären Algorithmen wie das LZW-Verfahren, doch um die Schaltkreis-Elemente zu verringern und eine große Parallelisierbarkeit bei den erforderlichen Berechnungen zu erreichen, kommt nur eine "Doppelt differenzielle" Komprimierung zum Zuge.

Einfach gesagt werden die Unterschiede der Unterschiede zwischen den jeweiligen Z-Wert-Bitfolgen gespeichert. Dadurch ergeben sich meistens längere Bitfolgen, die aus lauter Nullen bestehen, was sich ganz gut komprimieren lässt. Wie das nun genau gemacht wird, wissen wir leider auch nicht (vermutlich RLE oder Huffman, oder eine Kombination dessen). Offizielle Informationen hierzu sind leider recht dürftig, die tatsächlich implementierten Verfahren werden von den Entwicklern wie ein Betriebsgeheimnis gehütet.

Durch die Einteilung des Z-Buffers in Kacheln ergeben sich natürlich auch wieder die genannten speichertechnischen Vorteile, da das Schreiben eines ganzen Blockes viel effektiver ist (Stichworte "Block Write" und "Burst Write"), als jeden Z-Wert einzeln zu schreiben. Mögliche Nachteile ergeben sich beim Rendern von sehr kleinen Dreiecken, wo für wenige Pixel immer komplette Z-Kacheln bearbeitet werden müssen. Letztlich ist die Z-Komprimierung aber lohnend. Übrigens erlaubt die Kachelung des Z-Buffers weitere Rendering-Beschleunigungen wie "Fast-Z-Clear", was allerdings nicht mehr Gegenstand dieses Artikels ist.

Einen anderen Weg als Hyper-Z schlug die GeForce3 ein. Es gibt bei dieser zwar keinen Mechanismus, der einige "unnötige" Z-Zugriffe erkennen und abfangen kann, dafür wird der Z-Test vor dem eigentlichen Rendering gemacht. Stellt sich dabei heraus, dass das Pixel ohnehin nicht sichtbar ist, kommt es gar nicht erst in die Pipeline. Wertvolle Bandbreite und GPU-Takte werden so gespart. Die Komprimierung von Z-Werten beherrscht die GeForce3 ebenfalls. Die Radeon 8500 kombiniert übrigens den vorgezogenen Z-Test mit HyperZ, was eine sehr effektive Lösung darstellt.

Dass etliche Pixel umsonst gerendert werden, da sie im Laufe der Bilderzeugung überschrieben werden, können beide Ansätze aber nicht verhindern. Eine einfache Lösung kann es nicht geben, da man ja wie gesagt alle Dreiecke kennen muss, bevor entschieden werden kann, von welchen Dreiecken welche Pixel sichtbar sind. Um vollständiges vorgezogenenes HSR zu ermöglichen, muss man mit einer verzögerten Bildberechnung leben: Während der eine Teil des Grafikchips die Dreiecke des aktuellen Bild sammelt, wertet der andere Teil die Dreiecke des vorherigen Bilds aus und rendert sie. Wegen der Verzögerung heißt solche Hardware auch Deferred Renderer.

Die Berechnung der Sichtbarkeit lässt sich besonders effektiv erledigen, wenn nicht nur der Z-Buffer, sondern auch der Framebuffer in kleine Kacheln zerlegt wird. Pro einzelne Kachel sind dann nur wenige Dreiecke zu berücksichtigen, die Berechnung der gegenseitigen Überdeckungen lässt sich somit auf ein realisierbares Maß verringern. Dafür steigt der so genannte Overhead an, was in diesem Falle der zusätzlichen Verwaltungsaufwand für die Kacheln ist. Deshalb sind zu kleine Kacheln auch wieder ungünstig, weil das Bild es bei kleiner Kachel-Größe natürlich in sehr, sehr viele Einzel-Kacheln zerlegt werden müsste.

Weil immer gleich ganze Kacheln in den Framebuffer geschrieben werden, ließe sich solche Hardware sogar mit Single Buffering betreiben, was die Render-Verzögerung wieder ausgleicht. Denn um den Bildaufbau "im Hintergrund" zu gewährleisten, ist herkömmliche Hardeware auf Double Buffering angewiesen, was ebenfalls eine Bildverzögerung bedeutet. Die einzigen auf dem Markt befindlichen Chips, die vollständiges vorgezogenes HSR beherrschen, ist die 4000-er Reihe von ImgTech (konkret sind das STG4000, STG4500 und STG4800) - besser als Kyro, Kyro 2 und Kyro 2 SE bekannt.

Dass sich diese spezielle Rendering-Technik lohnt, wird deutlich, wenn man die (schwachen) technischen Daten der Kyros mit der herauskommenden praktischen Leistung vergleicht: Mit nur 230 Megatexel Füllrate (Kyro1, 115 MHz) zersägte sie problemlos eine GeForce2 MX (im 32-Bit-Modus 350 Megatexel Füllrate) bzw. mit 350 MegaTexel (Kyro 2, 175 MHz) kann sie durchaus mit einer GeForce2 GTS (im 32-Bit-Modus 800 MegaTexel) mithalten.

Allerdings bedeutet dieses vorgezogene HSR nicht, dass der Overdraw auf Null gesenkt wird. Der Overdraw-Faktor gibt an, wieviele Pixel pro sichtbaren Pixel gerendert werden müssen. Bei halbdurchsichtigen Polygonen (für Rauch usw.) muss natürlich der Hintergrund mitgerendert werden. Bei Transparenz sinkt der Effizienz-Vorteil der Kyros also. Doch ein Vorteil kann dem Kyro auch unter "schlechtesten" Umständen nicht genommen werden: Da das Rendering pro Kachel vollständig im internen Cache abläuft, fallen Framebuffer-Zugriffe nur als Block-Übertragung im Burst-Modus an und Z-Zugriffe auf den Grafik-RAM sind vollkommen unnötig.

Diese Bandbreitenersparnis sorgt für einen Leistungsvorteil. Allerdings können die herkömmlichen Architekturen durch ausgetüftelte Speicher-Steuerungen wie z.B. der Crossbar Memory Controller bei GeForce3 /Ti und GeForce4 MX/Ti ebenfalls die "alten" Brute-Force-Renderer überflügeln, weil auch sie weniger Bandbreite verschwenden. Natürlich stoßen sie dabei aber nicht in die Regionen der Effizienz eines Kyro-Chips vor.

Die Kyro-Funktionalität ist relativ schwer zu erreichen. Da half auch der 3dfx-HSR-Treiber für den VSA-100 (Voodoo 4/5) nichts. Dieser versuchte, bestimmte Dreiecke vor dem Rendering wegzuoptimieren. Das hatte allerdings so seine Tücken: In OpenGL waren (teilweise schwere) Grafikfehler nicht auszuschließen, und für Direct3D gab es diese Option von vornherein nicht.

Lediglich die Glide-Schnittstelle zeigte auch mit der HSR-Option keine Grafikfehler, dafür gelegentliches Bildruckeln. Denn wurde die CPU nicht rechtzeitig mit der Optimierung fertig, wurde das gesamte Bild verworfen und das alte Bild als neues angezeigt - wovon sich übrigens auch Framecounter verwirren ließen, welche teilweise zweimal soviel fps anzeigten wie tatsächlich gerendert wurden.

Glide war aber schon auf der Voodoo3 schnell genug, dass es der HSR-Option eigentlich nicht bedurfte (von Anti-Aliasing mit Voodoo 4/5 vielleicht einmal abgesehen), und um sie in OpenGL sinnvoll zu nutzen, brauchte man neben einer sehr schnellen CPU auch die Bereitschaft, gelegentliches Dreiecksflackern in Kauf zu nehmen. HSR muss also die Hardware (oder Spiele-Engine) machen, treiberseitig lässt sich da nichts wirklich sinnvolles erreichen.