Texturkompression

[roidal]

Ich würde gerne wissen wie Texturkomprimierung ganz allgemein funktioniert.

Soweit ich das verstanden habe werden da die Texturen im VRAM komprimiert abgelegt, und bei der Verwendung direkt in der GPU dekomprimiert. Wie sehen in dem Fall die Texturen der Anwendung auf der HDD aus? Sind die auch schon komprimiert, oder werden die erst zur Laufzeit vom Grafiktreiber komprimiert?

[roidal]

Nachdem ich meine Frage ziemlich ungenau formuliert habe versuche ich das ganze etwas genauer zu erklären:

Soweit ich das verstanden habe gibt es 2 Möglichkeiten:

1.: Die Textur liegt schon komprimiert vor; der Treiber transferiert diese in den VRAM und teilt der GPU mit das es sich um eine komprimierte Textur handelt; Die GPU dekomprimiert die Textur sobald sie benötigt wird

2.: Die Textur liegt nicht komprimiert vor; der Trebier komprimiert diese vor dem transferieren; Die GPU dekomprimiert wieder die Textur wenn sie benötigt wird.

Jetzt sind zumindest einige der Kompressionsverfahren patentiert, weshalb diese nicht von den Linux Opensource Treibern unterstützt werden. Dann gibt es Probleme mit Games welche Texturkompression verwenden. (z.B. da: http://theindiestone.com/forums/index.php/topic/3168-linux-graphic-bug-oss-radeon-driver/)

Nur weiß Ich jetzt nicht warum das zu einem Problem führt. Im ersten genannten Fall muss das Kompressionsverfahren ja im Treiber nicht implementiert sein, er muss es nur in der GPU aktivieren; und im zweiten Fall könnte er die Anforderung vom Game, die Texturen zu komprimieren, einfach ignorieren. Also, wodurch genau kommt es dann zu Grafikfehlern?

[Gipsel]

Die von den GPUs unterstützten komprimierten Formate nutzen typischerweise sogenannte Blockkompression. Dies ergibt sich aus der Notwendigkeit, mit wahlfreiem Zugriff ein paar kleine Abschnitte aus der Textur zu lesen, ohne daß man dazu die komplette Textur dekomprimieren muß. Deswegen fällt jpeg und sowas raus. Wenn Du wissen willst, wie solche Blockkompressionsverfahren arbeiten, dann kannst Du z.B. bei Microsoft anfangen (http://msdn.microsoft.com/de-de/library/windows/desktop/bb694531(v=vs.85).aspx).

Typischerweise werden Texturen bereits komprimiert auf der Festplatte gespeichert. Die Entwickler wandeln die also bereits in das entsprechende Format um. Dies kann unter Umständen sehr viel Platz erfordern, weswegen einige Titel (ich glaube Rage hat es auf jeden Fall gemacht), die Texturen in einem effizienter gepacktem Format (jpeg) auf der Platte ablegen und erst beim Laden bzw. dem Texturstreaming entpacken (und gegebenenfalls in ein BC-Format komprimieren). Dies kostet aber natürlich Prozessorzeit.
Der Treiber macht da übrigens gar nichts, der kann keine unkomprimierten Texturen in ein BC-Format konvertieren.

[roidal]

Der Treiber macht da übrigens gar nichts [...]


Ok, aber in wie fern verhindern dann Patente das Opensource Treiber eben Texturkompression unterstützen?

[ENKORE]

Sicher, dass der Treiber keine Texturen komprimieren kann?

http://dri.freedesktop.org/wiki/S3TC/

[roidal]

Sicher, dass der Treiber keine Texturen komprimieren kann?

http://dri.freedesktop.org/wiki/S3TC/

Erstens mal Danke für den Hinweis! Das Game tut nun.

Jetzt würde ich mich noch freuen wenn mir jemand den technischen Hintergrund erklären kann, warum das fehlen dieser Funktion ein Problem verursacht?

Theoretisch könnte der Treiber doch, wenn die Funktion fehlt, einfach die Kompression deaktiviert lassen?

[Gipsel]

Jetzt würde ich mich noch freuen wenn mir jemand den technischen Hintergrund erklären kann, warum das fehlen dieser Funktion ein Problem verursacht?

Theoretisch könnte der Treiber doch, wenn die Funktion fehlt, einfach die Kompression deaktiviert lassen?Das ist eher keine gute Idee, da z.B. DX auch das Hin- und Herkopieren von Daten zwischen verschiedenen Texturformaten (gleicher Größe) erlaubt. Das klappt natürlich nicht, wenn man mit einem mal ein anderes Texturformat hat.
Zu Deiner ersten Frage, warum es Probleme gibt, da kann ich mich auch nur wundern. Eigentlich sollte meiner Meinung nach die Anwendung selber (notfalls mit Hilfe einer externen Bibliothek, wie das ja offenbar auch bei dem MESA-Treiber gelöst werden kann) dafür Sorge tragen. Daß dem Treiber aufzuhalsen, scheint mir nicht die klügste Arbeitsteilung zu sein.
Und wer liefert unkomprimierte Texturen aus, damit er die dann zur Laufzeit komprimiert (verlustbehaftet, kein standardisiertes Verfahren, nur das Format ist spezifiziert, man kann sich also nicht sicher sein, was damit passiert und wie es ausieht), anstatt das von Anfang an (z.B. bei der Contenterstellung) selbst zu machen (man hat Kontrolle über das Resultat) und im Notfall die gepackten Texturen zu dekomprimieren (das Ergebnis ist eindeutig und das Verfahren viel einfacher/schneller und man spart darüber hinaus Plattenplatz)?