Kyro 2/Trilinear

[zeckensack]

Ich komme mir gerade ein wenig blöd vor :|
Die Suchfunktion hat ein paar Threads ergeben, wo von 10~20% Performanceverlust bei trilinearem Filter gesprochen wurde. Nur:
Ich kriege ums Verrecken keinen trilinearen Filter aktiviert???
Bislang nur getestet in Q3A 1.32, das ist definitiv bilinear obwohl im (Q3-)Menü ausdrücklich trilinear eingestellt war.

Ich benutze diesen (http://www.powervr.com/Drivers/PowerVRKYRO_4k8_W9X_16.0051.exe) Treiber (Quelle (http://www.powervr.com/Downloads.asp)). Alles auf default.

Rest-System in der Sig, oder für die ganz faulen:
AXP1800+
KT266A
Win98SE
Videologic Vivid!XS 32MB
Alles auf Standardtakt.

[mirp]

Zufällig Texturkompression aktiviert? ;)

http://www.mitrax.net/apboard/useraction.php?action=direct_goto_post&postid=25892

[zeckensack]

Originally posted by mirp
Zufällig Texturkompression aktiviert? ;)

http://www.mitrax.net/apboard/useraction.php?action=direct_goto_post&postid=25892 Bestimmt ?-)

Der Thread hat mich jetzt leider nur noch mehr verwirrt. Bitte noch mal für die ganz doofen (ie mich):
Um trilinear gefilterte Texturen zu kriegen ...
TC im Treiber, oder in Q3A, oder in beidem, oder garnicht aktivieren?

Trilinear im Spiel ist aktiv ... im Treiber gips das ja nich (in der OpenGL-Sektion) :|

[ow]

TC in Treiber (erzwungene TC) und Spiel deaktivieren.

/edit:

btw. vergiss das mit den 10-20% Leistungsverlust, der Kyro verliert bei echtem trilinearen Filtern 50% seiner Fillrate (s.archmark;)), von AF reden wir lieber erst garnicht;).

[mirp]

Bei Quake3 'Trilinear' einstellen und dann in der Console:

/r_ext_compressed_textures 0 => weiche Übergänge
/r_ext_compressed_textures 1 => Balken

[zeckensack]

Thx, das klappt schonmal :)

Tri funzt also jetzt. Die Performance ist dabei tatsächlich auf ca 50% eingebrochen, was natürlich nicht soo prall ist.
Wie ist das denn jetzt, ich meine gelesen zu haben, daß man diesen Einbruch mit TC kompensieren kann :|
Aber wenn sich jetzt TC und trilinear gegenseitig ausschließen ... ???

[GloomY]

Originally posted by zeckensack
Thx, das klappt schonmal :)

Tri funzt also jetzt. Die Performance ist dabei tatsächlich auf ca 50% eingebrochen, was natürlich nicht soo prall ist.
Wie ist das denn jetzt, ich meine gelesen zu haben, daß man diesen Einbruch mit TC kompensieren kann :|
Aber wenn sich jetzt TC und trilinear gegenseitig ausschließen ... ??? Der Kyro verwendet irgend ein komisches Verfahren (kein echtes Trilinear), wenn er TC + Tri verwendet. Bei dem kann man dann teilweise die Mipmap-Übergänge noch sehen, wenn man genau hinguckt. Das ist also ein optimiertes Trilinear auf Kosten der Bildqualität.

Imho ist das aber nicht überall zu erkennen und daher nicht all zu tragisch.

[mapel110]

Originally posted by GloomY

Imho ist das aber nicht überall zu erkennen und daher nicht all zu tragisch.

genau, ich hatte auch immer tc an. allerdings sieht mans dann bei mohaa doch recht deutlich. verschwommene texturen :kotz:

[ow]

Originally posted by zeckensack
Thx, das klappt schonmal :)

Tri funzt also jetzt. Die Performance ist dabei tatsächlich auf ca 50% eingebrochen, was natürlich nicht soo prall ist.
Wie ist das denn jetzt, ich meine gelesen zu haben, daß man diesen Einbruch mit TC kompensieren kann :|
Aber wenn sich jetzt TC und trilinear gegenseitig ausschließen ... ???


Jein, das schlieest sich nicht aus. Der Kyro nutzt aber einen Trick.
Wenn ich mich recht erinnere und das richtig verstanden habe, dann generiert der Kyro bei TC sämtliche mipmap-level automatisch aus dem Basislevel, er liest also praktisch nur Texel aus einer Textur ein (wie bei bilinear).
Bei echtem trilinear muss er (wie alle anderen Chips auch) aus 2 unterschiedlich aufgelösten mipmaps lesen, also aus 2 Texturen.

Mit colored mipmaps sieht TC-trilinear aus wie bilinear aufgrund dieses 'Tricks'.
Normal texturiert liegt die Quali von TC-trilinear zwischen bilinar-mipmap und trilinear. Es ist (je nach Textur) noch leichtes bis mittelstarkes banding zu sehen.

[GloomY]

Ich verstehe nicht ganz, wie der Qualitätsunterschied bei der Kyro Methode zu stande kommt.
Die Mipmaps einer x*y Textur sind doch normalerweise Texturen im Format x/2*y/2, x/4*y/4 x/16*y/16 usw. Wenn der Kyro jetzt nur eine Textur ließt (ich nehme mal an, dass das die der größeren der beidem Mipmaplevel ist), kann er doch die kleinere einfach per bilinearem runtersamplen aus der größeren Erzeugen. An welcher Stelle kommt nun der Qualitätsverlust zum Tragen? Hab' ich was übersehen? :|

[zeckensack]

Originally posted by GloomY
Ich verstehe nicht ganz, wie der Qualitätsunterschied bei der Kyro Methode zu stande kommt.
Die Mipmaps einer x*y Textur sind doch normalerweise Texturen im Format x/2*y/2, x/4*y/4 x/16*y/16 usw. Wenn der Kyro jetzt nur eine Textur ließt (ich nehme mal an, dass das die der größeren der beidem Mipmaplevel ist), kann er doch die kleinere einfach per bilinearem runtersamplen aus der größeren Erzeugen. An welcher Stelle kommt nun der Qualitätsverlust zum Tragen? Hab' ich was übersehen? :| Wenn ich ow richtig verstanden habe (thx), dann weiß ich wo das Problem liegt.
Die Mipmaperzeugung ist erstmal ein Box-Filter. Also sowas
AABBCCDD ABCD
AABBCCDD => EFGH
EEFFGGHH
EEFFGGHH

Die Optimierung des Kyro ist dann problematisch, wenn die Texturkoordinate 'ungerade' ist. Sowas
aabbccdd XXCD
aXXbccdd => XXGH
eXXfgghh
eeffgghh
Die Xe in dieser Skizze stellen ein bilineares Sample dar. Sie überstreichen im verkleinerten Mipmap auch vier Texel (ABEF). Diese gefilterten Texel in Miplevel+1 sind aber dem Kyro nicht sofort verfügbar, dafür müsste er zuerst nochmal vier bilineare Samples filtern.

Die Optimierung ist zulässig und fehlerfrei, wenn in meinem Beispiel-Level0 nur Samples mit dem gleichen Buchstaben gebraucht werden. In den anderen Fällen liegt sie mehr oder weniger stark daneben.

Q3A scheint dafür recht anfällig zu sein :(

Trotzdem nochmal thx für die Aufklärung ;)

[ow]

@zecki:

wenn du's genauer wissen willst, dann frage xmas, der hat mir das damals erklaert.

und ja, spiele mit Q3 Engine sind da wohl recht anfaellig, in JK2 ist es auf einigen Bodentexturen auch sehr gut zu beobachten.
Im (d3d-)Villagemark faellts dagegen kaum auf IIRC.

Dieser trilinear Trick ist allerdings auf TC beschraenkt, es sollte doch aber moeglich sein, auch bei unkomprimierten Texturen nur jeweils aus dem basislevel zu lesen und die mipmaps on-the-fly daraus zu generieren (vorausgesetzt, die hw kann das)??

[zeckensack]

Es sieht auch so aus, als führe der Kyro die Mipmap-Auswahl nur einmal pro Tile durch.
Dann noch die etwas komische 'fußbodenoptimierte' LOD-Bestimmung, die an den Seiten des Bildes kräftig plus gibt (also zu unscharfen Mip-Levels tendiert).

Unter 'Benchmarkbedingungen' ist es quasi unmöglich, den Kyro zu trilinearem Filter zu überreden.
I'm not impressed ... :|

edit: den Beweis muß ich vorerst schuldig bleiben, der Kyro läßt sich leider nicht mit der üblichen Methode ([ALT+]PrintScrn) zu Screenshots überreden.

[ow]

Originally posted by zeckensack
Es sieht auch so aus, als führe der Kyro die Mipmap-Auswahl nur einmal pro Tile durch.
Dann noch die etwas komische 'fußbodenoptimierte' LOD-Bestimmung, die an den Seiten des Bildes kräftig plus gibt (also zu unscharfen Mip-Levels tendiert).

Unter 'Benchmarkbedingungen' ist es quasi unmöglich, den Kyro zu trilinearem Filter zu überreden.
I'm not impressed ... :|

edit: den Beweis muß ich vorerst schuldig bleiben, der Kyro läßt sich leider nicht mit der üblichen Methode ([ALT+]PrintScrn) zu Screenshots überreden.


???

Die AF-Tester bescheinigen dem Kyro aber einwandfreies Verhalten beim trilinearen Filtern.:|

*ow*

[GloomY]

Danke für die Erklärung, Zecki =)
Originally posted by zeckensack
edit: den Beweis muß ich vorerst schuldig bleiben, der Kyro läßt sich leider nicht mit der üblichen Methode ([ALT+]PrintScrn) zu Screenshots überreden.PrintScreen alleine funzt aber immer...