FXT1 Textur Kompression in DX9 ?

[egdusp]

Hi,

habe gerade in einem anderen Thread gelesen, dass FXT1 von 3dfx noch nicht in DX integriert ist, wobwohl 3dfx es schon bei der Einführung lizenzfrei gestaltet hat und es qualitativ hochwertiger ist.

Kann man mit DX9 dieses (oder andere) Komprimierungsformat erwarten?
Hat die Radeon 9x00 diese Fähigkeiten.
Ist evtl. die Texturkompression sogar frei programmierbar (ich nehme mal an, dass zumindest der P10 das kann)?

mfg
egdusp

[Xmas]

Originally posted by egdusp
Hi,

habe gerade in einem anderen Thread gelesen, dass FXT1 von 3dfx noch nicht in DX integriert ist, wobwohl 3dfx es schon bei der Einführung lizenzfrei gestaltet hat und es qualitativ hochwertiger ist.

Kann man mit DX9 dieses (oder andere) Komprimierungsformat erwarten?
Hat die Radeon 9x00 diese Fähigkeiten.
Ist evtl. die Texturkompression sogar frei programmierbar (ich nehme mal an, dass zumindest der P10 das kann)?

mfg
egdusp
Das "qualitativ hochwertiger" bezweifle ich mal. Es wird zwar versucht für jeden Pixelblock das beste Format zu finden, aber die Kompressionsrate ist insgesamt höher, was mehr Verlust beinhaltet. Außer VSA-100 ist mir auch keine Hardwareimplementation bekannt.

Frei programmierbar ist TC auch beim P10 nicht. Es ist natürlich möglich, eine Art "Texturdecodierung" in der Pixelpipeline zu machen, aber das kostet viel Performance und macht nur Sinn wenn man mehr als nur ein paar Farbwerte pro Pixel benötigt.

[zeckensack]

Originally posted by egdusp
Ist evtl. die Texturkompression sogar frei programmierbar (ich nehme mal an, dass zumindest der P10 das kann)?
Das Problem mit alten und neuen TC-Formaten (dazu kann man auch Paletted Textures zählen) ist, daß die Dekompression vor dem Zusammenfiltern erfolgen muß und entsprechend mehrfach ausgelegt werden muß.

Bsp paletted:
Ich habe eine Palette mit 256 RGB-Farben. Ums mal kurz zu halten, gebe ich mal nur 3 Paletteneinträge an
Farbe 0:= 255 0 0 rein Rot
Farbe 1:= 0 0 255 rein Blau
Farbe 2:= 0 255 0 rein Grün
Lese ich jetzt bei bilinearem Filter vier benachbarte Texel aus einer mit dieser Palette verknüpften Textur ein, dann passiert entweder das (falsch):
0 0
2 2

Filter ergibt -> 1
'Dekompression'
-> Gefiltertes Texel ist blau
oder das (richtig):
0 0
2 2

4*'Dekompression' ergibt
-> 2*Rot, 2*Grün
Filter ergibt
128 128 0
-> Gefiltertes Texel ist Dunkelgelb
Daran sollte man die Problematik erkennen können.

Da man im Pixel Shader normalerweise* keinen Zugriff auf die Daten vor der Filterung hat, kann man auch keine beliebige Dekompression programmieren.

*der NV30 wird bestimmte Texturformate (float) überhaupt nicht selbst filtern können. Jeder noch so simple Texturfilter muß hier im Pixel Shader programmiert werden. Umgekehrt kann man natürlich auch bei 'normalen' Integertexturen den Texturfilter abschalten und im Pixelshader 4 Texel holen, dekomprimieren und erst danach filtern. Es sollte aber klar sein daß eine in Hardware gegossene Einheit viel viel schneller filtern kann als der Pixel Shader.

[zeckensack]

Uff, da habe ich doch glatt das wichtigste vergessen ?-)
Originally posted by zeckensack

Das Problem mit alten und neuen TC-Formaten (dazu kann man auch Paletted Textures zählen) ist, daß die Dekompression vor dem Zusammenfiltern erfolgen muß und entsprechend mehrfach ausgelegt werden muß.

Soll heißen:
Je mehr die Userschaft nach 'guten' Texturfiltern schreit, desto dünner wird die Luft für Texturkompression.
S3TC wird man wohl aufgrund der vorhandenen Software beibehalten, kompliziertere Methoden werden aber wohl nicht mehr kommen. Der Logikaufwand für FXT1 ist sowieso schon enorm im Vergleich zu S3TC (unterschiedlich große Blöcke, verschiedene Dekompressionsmethoden die sich von einem Block zum nächsten abwechseln können).
Wünscht der Kunde trilineare Filterung in einem Takt, dann muß ich diese Logik pro TMU achtfach auf den Chip bauen.

Ich denke die Transistoren sind woanders besser aufgehoben ;)

Ergo würde es mich nicht wundern, wenn DX9 in der Hinsicht nichts neues vorgibt.
Und so isses ja auch, laut Demirug :)

[aths]

Originally posted by zeckensack
Der Logikaufwand für FXT1 ist sowieso schon enorm im Vergleich zu S3TC (unterschiedlich große Blöcke, verschiedene Dekompressionsmethoden die sich von einem Block zum nächsten abwechseln können).Ich nehme stark an, dass bei den "unterschiedlichen" Blockgrößen getrickst wird: 8x4-Blöcke sind Standard, die u.U. jeweils noch mal in 2 4x4 Blöcke unterteilt werden.

[zeckensack]

*split*

Die Debatte die ich hiermit verursacht habeOriginally posted by zeckensack
*der NV30 wird bestimmte Texturformate (float) überhaupt nicht selbst filtern können. Jeder noch so simple Texturfilter muß hier im Pixel Shader programmiert werden. findet sich jetzt hier:
http://www.forum-3dcenter.net/vbulletin/showthread.php?threadid=36186

[tb]

Originally posted by egdusp
Hi,

habe gerade in einem anderen Thread gelesen, dass FXT1 von 3dfx noch nicht in DX integriert ist, wobwohl 3dfx es schon bei der Einführung lizenzfrei gestaltet hat und es qualitativ hochwertiger ist.

Kann man mit DX9 dieses (oder andere) Komprimierungsformat erwarten?
Hat die Radeon 9x00 diese Fähigkeiten.
Ist evtl. die Texturkompression sogar frei programmierbar (ich nehme mal an, dass zumindest der P10 das kann)?

mfg
egdusp

Laut DX9 beta 3 - nein.

Gruß,
Thomas

[vogel]

Wieso sollte FXTC in DX9 enthalten sein? Ausser 3dfx (RIP) unterstuetzt es ja niemand.

Treiberprogrammierer koennen uebrigens Formate die nicht explizit aufgefuehrt sind ueber sogenannte FOURC CC codes unterstuetzen.

-- Daniel, Epic Games Inc.

[Unregistered]

Originally posted by vogel
Wieso sollte FXTC in DX9 enthalten sein? Ausser 3dfx (RIP) unterstuetzt es ja niemand.

In DX ist vieles enthalten, was von niemandem unterstützt wird. Bikubische Texturfilter, Pixel und Vertex Shader 3.0 oder polynomielle Flächen als Beispiel.

Es ist an der Zeit, bei der Texturkompression Fortschritte zu erzielen. FXT1 wäre ein Fortschritt. Die Beispielbilder von Digit-Life sind leider mit einem fehlerbehafteten FXT1-Plugin entstanden, weshalb hier ein falscher Eindruck über die Qualität von FXT1 entsteht. FXT1 ist bei Game-Texturen der S3<couch>TC klar überlegen.

[Pitchfork]

Originally posted by Unregistered


In DX ist vieles enthalten, was von niemandem unterstützt wird. Bikubische Texturfilter, Pixel und Vertex Shader 3.0 oder polynomielle Flächen als Beispiel.

Es ist an der Zeit, bei der Texturkompression Fortschritte zu erzielen. FXT1 wäre ein Fortschritt. Die Beispielbilder von Digit-Life sind leider mit einem fehlerbehafteten FXT1-Plugin entstanden, weshalb hier ein falscher Eindruck über die Qualität von FXT1 entsteht. FXT1 ist bei Game-Texturen der S3<couch>TC klar überlegen.

Du verkennst, wie DX weiterentwickelt wird. Es gibt eine Runde von IHVs und Microsoft, die sich zusammensetzen und wissen(!), wie die Hardware der nächsten Jahre aussehen wird. Im großen Überblick wissen diese Leute schon, was DX10 Hardware leistet. Im Detail kennen sie alle Features bis Ende nächsten Jahres. Und auf diese Features hin wird DX ausgerichtet, manche Features fallen unter den Tisch, wenn sie zu problembehaftet sind, manche kommen erst später, aber die Hauptlinie wird durch die Hardware vorgegeben.
Wenn also MS keine bessere Kompression anbietet, dann weil kein einziger IHV innerhalb des nächsten Jahres dort Fortschritte machen wird. Punkt. Jetzt kannst du gerne den IHV deines Beliebens pitchen, er möge doch in bessere Kompression investieren und vielleicht haben sie auch 2004 entsprechendes. Vorher wohl nicht.

Pitchfork

[Unregistered]

Originally posted by Pitchfork
Du verkennst, wie DX weiterentwickelt wird. Es gibt eine Runde von IHVs und Microsoft, die sich zusammensetzen und wissen(!), wie die Hardware der nächsten Jahre aussehen wird.

:)

Wieso sind dann seit Jahren (seit DX6?) bikubische Texturfilter in DX, obwohl das niemand unterstützt? Ist etwa doch nicht "das Wissen über kommende Hardware" einzig und allein ausschlaggebend für die Weiterentwicklung von DirectX?

Du vergisst folgendes: Microsoft hat eine eigene Forschungsabteilung für 3D Grafik mit einige Top-Wissenschaftler. MS entwickelt auch selbst Features, die in DirectX integriert werden. Die werden oft nur nicht so an die grosse Glocke gehängt.

Zurück zum Thema: Wenn Microsoft nicht wieder in die Lizenzzahlungsfalle (EMBM=$$$ an Bitboys, S3TC=$$$ an S3, Vertex/Pixelshader=$$$ an Nvidia) fallen will, täten sie gut daran, entweder eine eigene, bessere Texturkomprimierungstechologie zu forcieren oder eben auf OpenSource-Technik wie FXT1 zurückzugreifen.

[Quasar]

Polynomielle Flächen werden von der GeForce3 unterstützt (auf der GF4 nehme ich an, ebenfalls, leider krieg' ich das Patch-Script dort nicht zum Laufen). PS und VS 3.0 könnten schon von der nächsten Generation (Frühjahr 2003) an high-end Karten unterstützt werden und ausserdem möchte man sich bei MS sicher nicht von OpenGL 2.0 die Butter vom Brot nehmen lassen....

(Bikubische Irgendwasse waren mal im nV1 enthalten, aber ich glaube, das waren keine Texturfilter, sondern Flächen)...

[Xmas]

Originally posted by Quasar
(Bikubische Irgendwasse waren mal im nV1 enthalten, aber ich glaube, das waren keine Texturfilter, sondern Flächen)...
NV1 hat als Grundprimitive nur biquadratische Flächen (Quads) unterstützt, keine Dreiecke. Das wurde aber von DX nie unterstützt, was ein Grund für den Misserfolg war.

Biquadratische oder bikubische Texturfilter sind jetzt eh per PS programmierbar.

[Quasar]

schade eigentlich....aber irgendsowas wr's halt. ;)

[Unregistered]

Originally posted by Xmas
Biquadratische oder bikubische Texturfilter sind jetzt eh per PS programmierbar.

Ja, aber DirectX unterstützte das Feature jahrelang, ohne dass offiziell irgendwelche Hardware mit Unterstützung geplant war.

[Unregistered]

Originally posted by Quasar
Polynomielle Flächen werden von der GeForce3 unterstützt (auf der GF4 nehme ich an, ebenfalls, leider krieg' ich das Patch-Script dort nicht zum Laufen).

Nein, sie werden nicht unterstützt.

[aths]

Originally posted by Unregistered
Nein, sie werden nicht unterstützt. Mit dem richtigen PatchScript schon (habs bei mir mit dem DX8.1 SDK getestet.)

[Unregistered]

Originally posted by aths
Mit dem richtigen PatchScript schon (habs bei mir mit dem DX8.1 SDK getestet.)

Nein, das Feature wird werksseitig nicht unterstützt, sei es wegen technischen Problemen, nicht fehlerfreier Hardware oder zwecks Politik/Kundenverarsche.

Es geht hier nicht darum, was irgendwie durch inoffizielle Treiberhacks hingeboten werden kann. Du kannst auch nicht davon ausgehen, dass das Feature richtig funktioniert, nur weil das Beispiel im DX8.1 SDK damit funktioniert.

[Quasar]

Nimm 'nen beliebigen, prä-20.80-Detonator, der die GF3 unterstützt und voila, RT-Patches und P-Flächen.

Das war auch der Grund, warum der 2.1-Aquamark auf neueren Detos nicht mehr lief -> RT-Patches bei GF§ automatisch aktiviert....

[Pitchfork]

Originally posted by Unregistered
Wieso sind dann seit Jahren (seit DX6?) bikubische Texturfilter in DX, obwohl das niemand unterstützt? Ist etwa doch nicht "das Wissen über kommende Hardware" einzig und allein ausschlaggebend für die Weiterentwicklung von DirectX?

Du vergisst folgendes: Microsoft hat eine eigene Forschungsabteilung für 3D Grafik mit einige Top-Wissenschaftler. MS entwickelt auch selbst Features, die in DirectX integriert werden. Die werden oft nur nicht so an die grosse Glocke gehängt.


Die bikubischen Filter sind wohl eher "Leichen", genauso wie die Phongbeleuchtungsflags oder BatchBlt Funktionsaufrufe in DDraw. Sind aus der Frühzeit von DX und vielleicht war mal irgendwo ne Hardware in der Planung, die das unterstützte und es ist untergegangen, was weiß ich. An Flags sollte man sich sowieso nicht allzu sehr orientieren, die hat man mal schnell im Code drin ohne sie wirklich zu unterstützen, aber bevor man sie ausbaut und sich irgendwas ändert.....

Ich sag ja nicht, daß MS nicht selber forscht, aber MS versteht sich in Sachen DX Graphics in ALLERERSTER Linie als Hardware API. Sie legen Wert auf eine saubere Struktur, komische Features werden eher mal liegengelassen (z.B. Clipplanes auf Kosten der Textureunits, jau). MS hat ebenso wie die IHVs eine klare Vision, wo die Entwicklung hardwareseitig hinläuft, aber MS kann und wird nur das in die API, was voraussichtlich im Lebenszyklus dieser DX Version auch erscheinen wird.

Wie gesagt, ich erwarte vor DX10 (ca. 2004) keine anderen Texturefilter, vielleicht irre ich mich ja.

Aber meine Erfahrung zeigt mir auch, daß MS zwar nach aussen hin sehr präsent ist, aber Hardwarefeatures muß man bei NV und ATI und co. einfordern. Punkt.

[Unregistered]

Originally posted by Quasar
RT-Patches und P-Flächen.

Das ist dasselbe. :)


Das war auch der Grund, warum der 2.1-Aquamark auf neueren Detos nicht mehr lief -> RT-Patches bei GF§ automatisch aktiviert....

Die krass-Engine nutzt gar keine RT-Patches. [ich weiss, auf der Nvidia-Seite steht was anderes].

[Quasar]

Originally posted by Unregistered
Das ist dasselbe. :)

Gut, da war ich mir nicht so sicher. Hab' Mathe mit 7 Punkten beendet...


Die krass-Engine nutzt gar keine RT-Patches. [ich weiss, auf der Nvidia-Seite steht was anderes].

Ich weiss, aber das hat einer der Entwickler mir gegenüber mal geäußert...

Wie dem auch sei,in den Detos vor dem 20.80er war RT-Patch-Support für die GF3 enthalten. Probier's aus ;)

[aths]

Originally posted by Unregistered
Nein, das Feature wird werksseitig nicht unterstützt, sei es wegen technischen Problemen, nicht fehlerfreier Hardware oder zwecks Politik/Kundenverarsche.

Es geht hier nicht darum, was irgendwie durch inoffizielle Treiberhacks hingeboten werden kann. Du kannst auch nicht davon ausgehen, dass das Feature richtig funktioniert, nur weil das Beispiel im DX8.1 SDK damit funktioniert. Auch die entsprechenden Demos im nVidia-Browser funktionieren mit dem Patch, ebenso die entsprechenden Cg-Demos. Das PatchScript ändert nur wenige Bytes, und legt nur eine deaktivierte bzw. nicht angemeldete Funktion frei.

[Ikon]

/me wagt sich gar nicht vorzustellen, wie aufwendig es wäre, bikubische Texturfilter in Hardware zu implementieren. Ausserdem würde unser guter, alter anisotroper Filter ja dann fast arbeitslos.

EDIT: Da fällt mir gleich noch was härteres ein: ein bi-/trikubisch-anisotroper Filter -> IMHO der Alptraum jedes Grafikchip-Entwicklers - der Rechenaufwand wäre mehr als extrem.