R8500 HW / SW Bug : grosse Texturen ?

[Mad-Marty]

Hi,

gibt es so etwas ?
Kann eine Graka bei nur 1er Texturauflösung höher total wegsterben ?

Ich habe wie im ATi Forum schon beschrieben das Problem habe das bei
Very High Texture detail SOF2 Performance total in den Keller rutscht

90 auf 7 .... :(

@ High läufts aber absolut flüssig

[zeckensack]

Vielleicht ist einfach nur der Texturspeicher alle ???
Die Methode, mit der ATI anisotrope Filterung löst (Ripmaps) verbrät gegenüber NV's Methode übrigens auch zusätzlichen Speicher.

[Mad-Marty]

Hi,

wenn ich Anisotropische Filterung deaktiviere macht das aber fast keinen unterschied in der perf.

Sollten 64 MB nicht eigentlich reichen wenn man ohne FSAA spielt ?


Wieso braucht das RIP-Map ähnliche Verfahren mehr Speicherplatz als nv's version ?
vermutung:
Liegt das daran das die Rip-Map Texturen vorberechnet sind und alle im ram bleiben ?
/vermutung

bye

[zeckensack]

Originally posted by Mad-Marty
Hi,

wenn ich Anisotropische Filterung deaktiviere macht das aber fast keinen unterschied in der perf.

Sollten 64 MB nicht eigentlich reichen wenn man ohne FSAA spielt ?kA
Vor ein paar Tagen schwirrte hier noch ein Benchmark von JK2 rum, da hat eine 128MB 8500LE einer 64MB 8500 Retail glatt die Hosen ausgezogen. So circa 95 fps gegen 12 fps.
Wieso braucht das RIP-Map ähnliche Verfahren mehr Speicherplatz als nv's version ?
vermutung:
Liegt das daran das die Rip-Map Texturen vorberechnet sind und alle im ram bleiben ?
/vermutung

byeVorberechnet und im Speicher behalten wird sowieso. NV benutzt für AF ganz einfach Mipmaps, die Technik gibt's mindestens schon seit Voodoo 1-Zeiten. Man spart Speicher, verbraucht dafür mehr Bandbreite.
ATI's RipMaps sparen Bandbreite, dafür verbrauchen sie Speicher

Verkomplizier:
Mipmaps sind verschiedene Auflösungsstufen der gleichen Textur. Von der maximal-Auflösung bis hinunter zu 1x1 Pixel wird die Auflösung bei jeder Stufe je Achse halbiert.

Ripmaps sind Basistextur + zwei Sätze verkleinerter Texturstufen, ein Satz je Achse.
Beispiel-Textur 256x256
Mipmap-Levels:
256x256,128x128,64x64,32x32,16x16,8x8,4x4,2x2,1x1
Mipmaps brauchen:
64kB+16kB+4kB+1kB+256B+64B+16B+4B+1B ca = 86kB

Ripmap-Levels:
256x256,256x128,256x64,256x32,256x16,256x8,256x4,256x2,256x1
128x256,64x256,32x256,16x256,8x256,4x256,2x256,1x256
Ripmaps brauchen:
64kB+2*32kB+2*16kB+2*8kB+2*4kB+2*2kB+2*1kB+2*512B ... ca = 192kB

[Mad-Marty]

wow, das ist ja krass, mehr als das doppelte.

hm... hätt ich echt nich gedacht.

hoffe doch sehr das es nicht an den 64 MB liegt, <30 fps ist INAKZEPTABEL !

[Gerhard]

Keine Ahnung warum sich das in die Welt gesetzte Gerücht so lange hält, das die Radeon Ripmapping verwendet. Die 45° unschärfe wiederlegt das auch, denn sie tritt bei der falschen Achse auf (war damals ein Denkfehler, den einige ohne Nachzudenken gleich übernommen haben). Wäre es rippmapping würde bei einem 3D-Shooter der Boden unter der Figur beim drehen nach links oder rechts einmal scharf, dann unscharf usw werden, dies ist aber nicht der Fall. Vielmehr hat die Ausrichtung der Textur auf dem Bildschirm die entsprechende Wirkung, was bei rip-mapping keine Auswirkungen auf die Schärfe hätte.
Übrigens, mit den Plutonium 71 Treibern tritt das Problem nicht mehr auf.

[Exxtreme]

Originally posted by Gerhard

Übrigens, mit den Plutonium 71 Treibern tritt das Problem nicht mehr auf.
Welches "Problem" denn? Ich glaube, ich habe da etwas nicht kapiert. ;)

Gruß
Alex

[Gerhard]

Ups, das Problem bezog sich auf die niedrige Geschwindigkeit bei grossen Texturen (und bei mir auch nur mit JK2 getestet, ist wohl schon etwas spät). Das Filtering bleibt natürlich unverändert.

[ow]

Originally posted by Gerhard
Keine Ahnung warum sich das in die Welt gesetzte Gerücht so lange hält, das die Radeon Ripmapping verwendet


Vielleicht weil noch niemand eine bessere Erklaerung fuer die bescheidene AF Implementierung bei ATi hat? Und zB. in SeSam sieht's wirklich grauenhaft aus, wie ich mal wieder feststellen musste.

Falls du mehr weisst,dann teile uns das doch bitte mit.
Und wie ATi den korrekten Mipmap-Level bestimmt wuerde ich auch gerne wissen.

Gruss,
ow

[Mad-Marty]

Also ich finde die Methode nicht "grauenhaft",
im gegenteil, ich find sie sogar ähnlich intelligent wie das
TBR beim Kyro, also höhere Quali ohne extreme Performanceeinbußen!

Ok es ist nicht Perfekt, aber IMHO sehr gut für den geringen Perf-hit !!!

Ja ich weis das jetzt gleich von Leuten wie ow kommt das es in ganz bestimmten Situationen Nachteile hat gegenüber der NV Implementation,
aber mal ehrlich: a)schaut man beim quake spieln nicht stundenlang vor einer säule im 45° Winkel auf die Bodentextur
und b)über Quincunx regt sich auch keiner auf, und das ist WIRKLICH grauenhaft.
(Kein flame, nur ne Feststellung meinerseits !)

Aber zurück zum Thema,
wieso spinnt das bei very high texturen rum, ow ?
Welche Maße hat eigentlich eine very High Textur bei SOF2 / JK2 im schnitt ?
Denkst du da in die selbe Richtung wie Zeckensack, das der Radi der
Mem ausgeht ? Oder gibts da andre Vermutungen ?

Naja vielleicht liegts einfach nur an einem Treiberbug, dann besteht ja noch Hoffnung.


so denn ...

[zeckensack]

Öh, ich möchte anmerken, daß ich da eigentlich nur geraten habe. Und mittlerweile scheint sich das Problem ja auch durch neuere Treiber beheben zu lassen.

Daß die Radeon Ripmaps benutzt kann ich momentan auch nicht belegen. Dazu fehlt mir schlicht und ergreifend ein Tweaker, mit dem ich unter D3D Aniso erzwingen kann.

[ow]

Originally posted by Mad-Marty


Naja vielleicht liegts einfach nur an einem Treiberbug, dann besteht ja noch Hoffnung.


so denn ...


Treiberbug ist auch meine Vermutung.
Mit Texturkompression sollten alle Spiele auch noch mit 32MB RAM zurechtkommen.

[Gerhard]

Naja, wie sie intern arbeitet weis wohl nur ATI alleine, allerdings kann es eben ripmapping nicht sein, da sich die Filterung dann anderst verhalten würde. Das Hauptproblem ist meiner Meinung nach das die Mipmapübergänge etwas zu spät erfolgen, dadurch wirkt es zwar schärfer, allerdings gibt es bei feinen Texturen mit hohen kontrasten sehr hässliche Artefakte, und die Übergänge sind entsprechend gut (and den Artefakten) sichtbar. Imho erleidet die ATI Methode dadurch einen grossen Qualitätsverlust, der eigentlich garnicht auftreten dürfte. Weiters habe ich auch bei der ATI Karte vor allem unter D3d Geschwindigkeitseinbrüche bis 60% (von 100fps auf 40fps), besonderst schnell ist sie also auch nicht immer, vor allem scheint die Geschwindigkeit dann deutlich stärker zu schwanken.
Anderseits funktioniert die Aniso.filterung bei einigen Spielen sehr gut, aber eben leider nicht immer.

[Ikon]

Nun, ein Grund, dass sich das Gerücht über RIP-Mapping beim R200 hält ist wohl, dass es in aths'/Leonidas' Artikel über Texturfilter nahe gelegt wird. Es erscheint auch irgendwie logisch: die Radeon8500 filtert "nur" bilinear-anisotrop und RIP-Mapping wäre genau dabei äußerst schnell. Ich glaube nicht unbedingt, dass man RIP-Mapping beim R200 ausschließen kann, nur weil es subjektiv nicht danach aussieht - wer weiß schon wie ATI es (eventuell) implementiert hat? Da kann ATI noch so oft behaupten, dass sie kein RIP-Mapping verwenden ... ich habe noch keinen Beweis gesehen, wohl aber einige Indizien für das Gegenteil.

Ikon

[Gerhard]

Hallo, man kann es einfach deshalb ausschliesen, weil rip-mapping nur wirken kann, sobald eine Textur nicht direkt horizontal oder vertikal betrachtet wird.
Und genau dieser Effekt tritt bei der ATI Karte NICHT auf. Die Textur bleibt immer gleich scharf, und es wird anisoptropisch gefiltert. Dies wäre unmöglich mit rip-mapping, deshalb kann es auch unmöglich eingesetzt werden.

Dagegen werden die Texturen unscharf sobald sich die Textur auf der Bildschirmebene dreht, unabhängig davon wie die Textur ausgerichtet ist. Dieser Effekt würde mit rip-mapping nicht auftreten.

Die Bodentexturen in einem Flugsimulator müssten bei rip-mapping beim reinen Richtungswechsel (ohne Schrägstellung, bei geradem Blick aus dem Cockpit) z.b. zuerst scharf, dann unscharf (45° zu den längs und quervorberechneten Texturen) und dann wieder scharf sein. Tatsächlich ist die Textur aber immer gleich scharf. Dagegen dürfte eine reine Drehung des Flugzeuges um die Längsachse die Schärfe nicht beeinflussen, die Ausrichtung und der Winkel zur Bodentextur bleiben ja gleich.

EDIT:
Die reine Rotation um einen Bildschirmpunkt kann die erforderlichen Mip/ripmaps gar nicht ändern. Würde man z.B. den Screenshot nachträglich in einem Zeichenprogramm drehen, so würden nicht auf einmal mehr Artefakte oder andere Filter/Ripmaps benötigt werden. Die Radeon wird jedoch genau bei dieser Drehung einmal scharf/dann unscharf.

--

Vermutung: Hier dürfte eher eine Optimierung auf den internen Texturecache die entscheidende Performancerolle spielen.

Siehe das angehängte Bild:
1. texurkante ist zur Bildschirmkante ausgerichtet und recht scharf (anisoptr. Filterung aktiv)
2. 45° auf Bildschirmebene gedreht, müsste eigentlich genauo scharf sein (bei rip-mapping), da ja quasi nur "das Sichtfenster" gedreht wurde, bei der Filterung selbst sollte es keine Änderung geben. es ist allerdings viel unschärfer.
Man könnte den Screenshot 1 in einem Zeichnprogramm um 45Grad drehen (nochmal, um sich klar zu machen das sich hierbei die erforderlichen mip/ripmaps nicht ändern), und würde ein genause scharfes, nur gedrehtes Bild erhalten.
3. müsste bei rip-mapping sehr unscharf sein, da die Texture im 45° Winkel dargestellt wird, weder die horizontale noch die vertikale Vorausberechnung greifen hier. Tatsächlich ist das Bild aber genauso scharf wie Bild 1.

Leider geht durch die jpeg Kompression ein wenig vom Schärfeeindruck verloren, aber ich glaube man kann es trotzdem erkennen.

[Mr Lolman]

Und WARUM kann RipMapping nur bei einer horizontal oder vertikal ausgerichtenten Textur wirken ? ??

[Gerhard]

Zuerst einmal noch ein kleiner Literatur link:
http://www.sgi.com/software/performer/brew/anisotropic.html

Wie man hier sieht, werden anstatt der normalen mipmaps horizontale und vertikale anisoptropisch gefiltere maps erstellt. Danach wird jeweils die Passende für die Darstellung genutzt.
Dies funktioniert natürlich bei der gezeigten Variante natürlich nur, wenn die Ausrichtug der Textur schon bekannt ist (die Filterung wird ja schon vor der Darstellung berechnet), sprich wenn (sofern wie in dem Artikel gezeigt, eben die horizontale und vertikale Filterung vorrausberechnet wird) bei einem Rechteck jeweils die vordere zwei Eckpunkte (und auch die hinteren zwei) jeweils den gleichen Abstand haben zur Bildschirmebene haben.
Eine Drehung um den Bildschirmmittelpunkt verursacht dagegen kein Problem, die Neigung der Textur und auch der jeweilige Filtergrad bleiben ja gleich.