Demirug
2003-06-07, 18:06:13
DR ist ja als ein Mittel zur Reduktion das Arbeitswolumen im Pixelbereich bekannt. Alle derzeit bekannten DR Verfahren bauen auf dem entfernen von nicht sichtbaren Pixeln bevor sie die Pixelpipelines erreichen auf.
Seit der letzten erfolgreichen implementierung (Kyro) eines DR Verfahrens hat sich bekanntermassen einiges getan. Inzwischen werden ja zusätzliche Teile der 3d-Pipelines auch von den Chips mit übernommen. Als grössten Teil kann man hier das Vertexprocessing im Vertexshader zu nennen.
Daraus entstehen für einen DR neue Probleme. Die Möglichkeiten der VS führen nun zu mehr und komplexeren Verticen welche dann natürlich mehr speicher brauchen. Hinzu kommt noch das Vertexprocessing vor dem HSR durchgeführt werden muss weil es ja erst die entgültige Positions der Verticen bestimmt. Dadurch muss die VS Einheit eines DR mindestens die gleiche Leistung wie die eines IMR bringen.
Aber muss das wirklich so sein? Ich denke nicht.
Überlegen wir uns einmal was ein Vertexshader alles tun muss. Zum einen berechnen sie natürlich die bereits erwähnte Position. Aber Zusätzlich müssen ja auch noch einige Operationen für die Lichtberechnung und Texturekoordinaten durchgeführt werden. Diese Werte sind für das HSR aber vollkommen überflüssig weil sie keinerlei Einfluss darauf haben. Die einzige logische schlussfolgerung daraus ist das man die Ausführung der Programmteile die für diese Werte zuständig sind einfach verzögert bis man die Werte wirklich braucht. Der Treiber müsste dafür das VS Programm analysieren und in zwei Teile trennen. Den Positionsteil und dem ganzen Rest.
Exemplarisch würde das bei einem TBDR wie folgt aussehen.
1. Phase
für Jedes Polygon
speichere die REndersettings für diese Polygon
für jedes Dreieck im Polygon
Berechne für jede der 3 Verticen des Dreiecks die Position oder
hole sie aus einem Cache
Speichere die für das HSR benötigenten Dreiecksdaten sowie die
fortlaufende Nummer des Dreiecks in die dazugehörige Tile.
2. Phase
für jede Tile
für jedes Dreieck
HSR Test durchführen.
3. Phase (auf Tilebasis)
Ausführen des zweiten Teil des Vertexprogramms für jede Vertice
die zu einem noch sichtbaren Dreieck gehört.
4. Phase (auf Tilebasis)
Ausführen der Pixelprogramme für jeden sichtbaren Pixel in der Tile
Kommen wir nun zu den Vor und Nachteilen
Vorteile:
- Für Verticen die nicht zum entgültigen Bild beitragen wird nur die Position berechnet was Vertexshader leistung spart
- Nur für die benötigten Verticen müssen die Grunddaten die zum berechnen von Licht oder Texturekoordinaten eingeladen werden. Damit läst sich unter umständen Bandbreite sparen.
- Beim speichern der Displayliste muss nur das nötigste gespeichert werden. Das spart auf jeden Fall Bandbreite.
Nachteile:
- Die Vertexshader einbindung in den Chip wird komplexer.
- Wenn Dreiecke in mehr als einer Tile liegen kann es passieren das Verticen doppelt berechnet werden müssen. Kostet Vertexshaderleistung und Bandbreite. Ein Tile übergreifender Cache könnte hier aber etwas abhielfe schaffen.
- Die gegenseitige Kopplung von Vertex und Pixelshader wird bei diesem Verfahren wieder grösser da nur auf Tileebene der Workload verteilt werden kann.
IMO sollte aber das Verzögern des Vertexprocessings einen Vorteil bringen. Um das ganze genau durchzurechnen fehlt mir leider wieder mal die notwendige Hardware.
Seit der letzten erfolgreichen implementierung (Kyro) eines DR Verfahrens hat sich bekanntermassen einiges getan. Inzwischen werden ja zusätzliche Teile der 3d-Pipelines auch von den Chips mit übernommen. Als grössten Teil kann man hier das Vertexprocessing im Vertexshader zu nennen.
Daraus entstehen für einen DR neue Probleme. Die Möglichkeiten der VS führen nun zu mehr und komplexeren Verticen welche dann natürlich mehr speicher brauchen. Hinzu kommt noch das Vertexprocessing vor dem HSR durchgeführt werden muss weil es ja erst die entgültige Positions der Verticen bestimmt. Dadurch muss die VS Einheit eines DR mindestens die gleiche Leistung wie die eines IMR bringen.
Aber muss das wirklich so sein? Ich denke nicht.
Überlegen wir uns einmal was ein Vertexshader alles tun muss. Zum einen berechnen sie natürlich die bereits erwähnte Position. Aber Zusätzlich müssen ja auch noch einige Operationen für die Lichtberechnung und Texturekoordinaten durchgeführt werden. Diese Werte sind für das HSR aber vollkommen überflüssig weil sie keinerlei Einfluss darauf haben. Die einzige logische schlussfolgerung daraus ist das man die Ausführung der Programmteile die für diese Werte zuständig sind einfach verzögert bis man die Werte wirklich braucht. Der Treiber müsste dafür das VS Programm analysieren und in zwei Teile trennen. Den Positionsteil und dem ganzen Rest.
Exemplarisch würde das bei einem TBDR wie folgt aussehen.
1. Phase
für Jedes Polygon
speichere die REndersettings für diese Polygon
für jedes Dreieck im Polygon
Berechne für jede der 3 Verticen des Dreiecks die Position oder
hole sie aus einem Cache
Speichere die für das HSR benötigenten Dreiecksdaten sowie die
fortlaufende Nummer des Dreiecks in die dazugehörige Tile.
2. Phase
für jede Tile
für jedes Dreieck
HSR Test durchführen.
3. Phase (auf Tilebasis)
Ausführen des zweiten Teil des Vertexprogramms für jede Vertice
die zu einem noch sichtbaren Dreieck gehört.
4. Phase (auf Tilebasis)
Ausführen der Pixelprogramme für jeden sichtbaren Pixel in der Tile
Kommen wir nun zu den Vor und Nachteilen
Vorteile:
- Für Verticen die nicht zum entgültigen Bild beitragen wird nur die Position berechnet was Vertexshader leistung spart
- Nur für die benötigten Verticen müssen die Grunddaten die zum berechnen von Licht oder Texturekoordinaten eingeladen werden. Damit läst sich unter umständen Bandbreite sparen.
- Beim speichern der Displayliste muss nur das nötigste gespeichert werden. Das spart auf jeden Fall Bandbreite.
Nachteile:
- Die Vertexshader einbindung in den Chip wird komplexer.
- Wenn Dreiecke in mehr als einer Tile liegen kann es passieren das Verticen doppelt berechnet werden müssen. Kostet Vertexshaderleistung und Bandbreite. Ein Tile übergreifender Cache könnte hier aber etwas abhielfe schaffen.
- Die gegenseitige Kopplung von Vertex und Pixelshader wird bei diesem Verfahren wieder grösser da nur auf Tileebene der Workload verteilt werden kann.
IMO sollte aber das Verzögern des Vertexprocessings einen Vorteil bringen. Um das ganze genau durchzurechnen fehlt mir leider wieder mal die notwendige Hardware.