Ein bisschen Grundlagen dazu, ich hoffe das beantwortet eure Fragen; wenn nicht nochetwas sagen. Ich verwende für folgende Erklärung mein "Verständnis" der GPU-Hardware. Teilweise ist das aber etwas spekulativ, da NVIDIA nicht dokumentiert wie sie auf ihren GPUs den Rasterisierungsprozess implementieren:
Es gibt zwei Arten von Kompressionsalgorithmen: Verlustbehaftete und verlustfreie. Bei NVIDIAs-Delta-Color-Kompression handelt es sich um einen verlustfreien Ansatz. Er reduziert die Größe eines Pixelblockes von 8 x 8 Pixeln mit 256 Byte auf einen Wert zwischen 32 Byte und 256 Byte. Die Textur liegt dementsprechend auch im DRAM der GPU in Form von 32 Byte bis 256 Byte großen komprimierten Pixelblöcken vor. Dient die Textur als Framebuffer für einen Zeichenvorgang, so sind *wahrscheinlich* die ROPs dafür verantwortlich die Ergebnisse des Fragmentshaders on the fly zu komprimieren. Analog werden beim Auslesen durch die GPU die komprimierten Blöcke aus dem DRAM der GPU geladen und dann *wahrscheinlich* durch die Texture-Units on the fly entpackt. Da Entpacken und Verpacken durch Spezialhardware vollbracht wird, kostet das keine Rechenzeit der Shaderkerne, allerdings Fläche auf dem DIE und etwas zusätzliche Abwärme. Dadurch, dass nur die kleineren komprimierten Daten zwischen dem GPU DIE und dem DRAM ausgetauscht werden, wird allerdings DRAM-Bandbreite eingespart.
Nun zur Frage ob man durch die Kompression auch Speicherplatz spart. Das ist wiederum davon abhängig, wie
die komprimierten Pixelblöcke im Speicher der GPU angeordnet sind. Sind sie dicht an dicht gepackt oder befinden sich zwischen ihnen Lücken? Das folgt leider nicht aus den Spezifikationen, deswegen ist folgendes etwas spekulativ:
Zunächst zum lesenden Zugriff:
Der Texturzugriff ist immer zufällig. Das heißt die GPU muss extrem leicht für einen zufällig gegebenen Pixelblöck mit den Koordinaten U und V bestimmen können, an welcher Addresse er sich in komprimierter Form im DRAM der GPU befindet. Die GPU kann diese Addresse nur direkt aus U und V berechnen, wenn die Anfangsaddressen der komprimierten Pixelblöcke alle den selben Abstand im Speicher besitzen. Selber Abstand heißt, dass zum Beispiel der 1. Block an Addresse 0 startet, der 2. Block an Addresse 256, der 3. Block an Addresse 512 usw. Da die Blöcke allerdings unterschiedliche Größen von 32 Byte bis 256 Byte besitzen enstehen auf diese Art und Weise unweigerlich unbelegte Lücken in der Speicherbelegung, wodurch wiederum der Verbrauch an DRAM-Platz durch die Kompression nicht gesenkt wird. Alternativ zum Berechnen könnte die GPU auch ein Inhaltsverzeichnis verwenden, in welchem für jeden komprimierten Pixelblock die Startaddresse im DRAM steht. Auf diese Weise könnten die einzelnen komprimierten Pixelblöcke einen unterschiedlichen Abstand im DRAM besitzen und gemäß ihrer komprimierten Größe dicht an dicht gepackt sein. Im Inhaltsverzeichnis würde dann beispielhaft soetwas stehen wie Block 0 der Größe 32 Byte startet an Addresse 0, Block 1 der Größe 64 Byte startet an Addresse 32, Block 2 der Größe 32 Byte startet an Addresse 96. Dadurch benötigt die GPU zwar einen Overhead an Speicherplatz für das Inhaltsverzeichnis. Insgesamt ließe sich jedoch der Speicherplatzverbrauch der Textur reduzieren.
Als Nächstes zum schreibenden Zugriff, also zum Beispiel wenn die Textur als Framebuffer dient:
Hier hat man das Problem, dass die komprimierte Größe eines Pixelblocks sich durch den Schreibvorgang verändern kann, da er schlechter oder besser komprimierbar wird. Würden die komprimierten Pixelblöcke im DRAM lückenlos aufeinander folgen, so wäre dieses Wachsen und Schrumpfen extrem problematisch. Denn würde ein Pixelblock zu groß werden, so müsste die GPU eine freie Stelle finden, die ihn aufnehmen kann. Analog müsste die GPU eine freie Stellen vermerken, wenn ein Pixelblock schrumpft. Diese Art von Speichermanagement wäre algoritmisch gesehen extrem umständlich zu verwirklichen. Deshalb bleibt der NVIDIA bei der Delta-Color-Kompression nichts anderes übrig alle Pixelblöcke mit dem Abstand der Worst-Case-Größe von 256 Byte abzuspeichern und dementsprechend Lücken zwischen den Blöcken im Speicher zu lassen.
Fazit: Muss eine GPU in eine durch Delta-Color-Kompression verkleinerte Textur auch hineinschreiben, so ist es nur schwer machbar mit der Kompression Speicherplatz zu sparen. Sofern die GPU aus einer durch Delta-Color-Kompression verkleinerten Textur nur lesen möchte, so ist es leicht möglich sie platzsparend im DRAM abzuspeichern. Dies kostet allerdings die zusätzliche Optimierung eines Inhaltsverzeichnis. Ich weiß nicht ob NVIDIA diese Optimierung eingebaut hat. Da sich das Whitepaper so liest als ob NVIDIA die Delta-Color-Kompression primär für Framebuffer-Objekte vorgesehen hat, in welche oft geschrieben wird, bezweifle ich es.
So das wars ersteinmal. Eventuell Später noch mehr
DrToxic hat es da verständlicher formuliert.
