Archiv verlassen und diese Seite im Standarddesign anzeigen : Tri aus einer MipMap und AF
Demirug
2003-12-27, 15:06:38
In Verbidnung mit dem Deltachrome wurde das Thema Trilinear in einem Takt ja wieder einmal aktuell. Zudem lassen Testergebnisse darauf schliessen das wenn es wirklich funktioniert es sich um eine Variante handelt welche die Texel alle aus einer Mip-Map gewinnt. Die Vorteile von Trilinear in einem Takt dürfte schnell verständlich sein spart man sich doch gegenüber einer bilinearen Filterhardware für jedes trilinaren sample einen Takt. Bricht bei einem Chip mit bilinearen TMUs als die Fillrate auf die hälfte ein wenn man trilinear anfordert zeigt sich ein Chip mit Tri-TMUs relative unbeeindruckt. Soweit so gut.
Was passiert aber nun wenn man neben dem trilinearen Filter auch noch das AF aktiviert? Die Tri TMU muss nun für jeden Level (oder auch Grad) des AF ein Trisample erzeugen und diese verrechnen. Daraus ergibt sich dann folgendes
AF max samples
No 1
2x 2
4x 4
8x 8
16x 16
Es skaliert also linear
Bei einem Chip mit Bi TMU sieht das ganze nun wie folgt aus. Zuerst müssen aus der grösseren der beiden beiteiligten Mip-Maps maximal die Anzahl von samples gewonnen werden die dem Grad des AF entsprechen. Aus der kleineren Mip-Map braucht man aber nun nur maximal die hälfte der Samples. Diese ist ja in beiden Richtungen auf die hälfte Verkleinert. Dadurch reduziert sich ja ebenfalls die Fläche welcher der Pixel auf der Texturstufe einnimmt. Daraus ergibt sich dann folgende Tabelle.
AF max MM1 max MM2 sum
No 1 1 2
2x 2 1 3
4x 4 2 6
8x 8 4 12
16x 16 8 24
Mit der Ausnahme beim wechsel von kein AD zu 2XAF skaliert auch ein solcher Chip linear.
Vergleicht man aber nun das AF mit einer bi und tri TMU:
AF tri bi Verhältniss
No 1 2 1:2
2x 2 3 2:3
4x 4 6 2:3
8x 8 12 2:3
16x 16 24 2:3
Das Ergebniss ist klar. Das aktivieren des AF reduziert das möglichen Sparpotential doch erheblich. Nun wäre wir eigentlich am Ende.
Aber man muss ja nicht mit einer Tri-TMU aufhören. Damit Tri aus einer Mipmap funktioniert muss man 16 Pixel in einem 4*4 Raster um den Samplepunkt herum berücksichtigen. Wie es das Schicksal und die Mathematik nun will müssen die beiden Sample welche man für 2xAF aus einer Mipmap braucht ebenfalls innerhalb eines solchen 4*4 Texel Rasters liegen. Es gibt natürlich Ausnahmen von dieser Regel wenn man zum Beispiel keine Mipmaps hat aber betrachten wie nur mal den Regelfall. Das zusätzliche Sample aus der kleineren Mipmap um das Tri-AF komplett zu machen kann man ja schon wie beim normalen Tri aus den 16 texel gewinnen. Da man für Tri aus einer Mip ja bereist die 16 Texel aus dem Cache auslesen und zum Filter schaffen muss ergibt sich hier keine änderung. Allerdings muss die Filterhardware zusätzlich einen Gewichtungsfaktor pro Texel erlauben. Bei Tri aus einer Mipmap kommt man mit weniger aus. Und das Rechenwerk muss natürlich so erweitert werden das es alle 16 Faktoren in einem Takt errechnen kann. Wenn man aber noch transitoren über hat diese aber nicht mehr für eine vollständige Einheit reichen scheint mir das eine Stelle zu sein wo man sie verbraten könnte. Die zu erwartende Ergebnisse sprechen für sich.
AF 2xAFtri bi Verhältniss tri Verhältniss
No 1 2 1:2 1 1:1
2x 1 3 1:3 2 1:2
4x 2 6 1:3 4 1:2
8x 4 12 1:3 8 1:2
16x 8 24 1:3 16 1:2
Doppelt so schnell wie eine bi TMU beim Einsatz des trilineare Filters und sogar 3 mal so schnell bei TRI-AF.
Danke, dass du dieses Thema angesprochen hast. Ich hatte mir auch schon mal überlegt, ob der größere Kernel für's AF nicht Sparpotenzial böte.
Xmas@home
2003-12-28, 01:10:42
Original geschrieben von Demirug
Bei einem Chip mit Bi TMU sieht das ganze nun wie folgt aus. Zuerst müssen aus der grösseren der beiden beiteiligten Mip-Maps maximal die Anzahl von samples gewonnen werden die dem Grad des AF entsprechen. Aus der kleineren Mip-Map braucht man aber nun nur maximal die hälfte der Samples. Diese ist ja in beiden Richtungen auf die hälfte Verkleinert. Dadurch reduziert sich ja ebenfalls die Fläche welcher der Pixel auf der Texturstufe einnimmt. Daraus ergibt sich dann folgende Tabelle.
In der Theorie passt das, nur wird dieser Umstand in der Praxis nicht immer ausgenutzt.
Demirug
2003-12-28, 13:03:21
Original geschrieben von Xmas@home
In der Theorie passt das, nur wird dieser Umstand in der Praxis nicht immer ausgenutzt.
Ja, natürlich. Eine 2xAFTRI TMUs ist ja auch derzeit eine rein Theoretische Sache. Aus diesem grund ging ich vom Maximum an Leistung was man mit bi-TMUs erreichen kann aus.
WOW;
wie lange werden wir noch auf solche 2xAF - TMU's warten müssen? Ich hoffe nicht ewig. Der Speedvorteil wäre theoretisch schon sehr groß, wenn auch die neuen Karten/Chips bei AF nicht mehr gar so viel Geschwindigkeit verlieren, da sie ja Füllrate "zum Wegschmeißen" haben.
Bei biAF wäre der Geschwindigkeitsvorteil doch ebenfalls ziemlich groß, oder? Entsprechend folgendem Verhältnis aus deiner letzten Tabelle :
AF 2xAFtri biAF Verhältniss
No 1 1 1:1
2x 1 2 1:2
4x 2 4 1:2
8x 4 8 1:2
16x 8 16 1:2
Oder?
Wenn ja, wäre auch hier noch ein großer Vorteil vorhanden.
<Spekulation>
Ich hoffe die letzten Kommentare von DaveBaumann zu den R420 - TMU's "R420's pipelines might be somewhat extreme." lassen sich in die Richtung "2xAF-TMU's" hin deuten. >hoff<
Die R420-TMUs werden höchstens trilinear sein. Demirug sprach in seiner Überlegung die Füllrate an, tri- bzw. AF-TMUs benötigen aber auch sehr viel mehr Bandbreite, als übliche bilineare.
AlfredENeumann
2003-12-28, 22:59:17
Original geschrieben von aths
Die R420-TMUs werden höchstens trilinear sein. Demirug sprach in seiner Überlegung die Füllrate an, tri- bzw. AF-TMUs benötigen aber auch sehr viel mehr Bandbreite, als übliche bilineare.
Schon mal was von GDDR3-RAM gehört?
Samsung liefert derzeit 800MHz (!!!)Samples aus. Also wird etwas leicht darunter verfügbar sein, oder?
Reicht doch an Bandbreite, oder etwa nicht?
Demirug
2003-12-28, 23:38:08
Was die Bandbreite angeht braucht ein 2xAFTRI Filter nicht mehr als ein TRI aus einer Mipmap Filter. wird ja beides aus dem gleichen 16 Texel Block gewonnen. Auch bei einer TRI-TMU liegt die Wahrscheinlichkeit für Cachehits ja schon recht hoch.
Original geschrieben von AlfredENeumann
Schon mal was von GDDR3-RAM gehört?
Samsung liefert derzeit 800MHz (!!!)Samples aus. Also wird etwas leicht darunter verfügbar sein, oder?
Reicht doch an Bandbreite, oder etwa nicht? Die TMUs lesen nicht direkt aus dem RAM, die kriegen ihre Daten aus dem Cache. Da braucht man enstprechend breite Pfade. Das kostet nicht wenig Transistoren, wenn das Design vernünftig taktbar sein soll, da kannste dir was einfallen lassen. Fast-TF-TMUs brauchen pro Takt vier mal so viel Bandbreite zum Textur-Cache, wie normale bilineare TMUs. Tri-2x-AF-TMUs brauchen noch mehr. Nicht alles wird anisotrop gefiltert, aber das meiste mindestens trilinear. Da hielte ich für die nächste Zeit trilineare TMUs für am sinnvollsten. Demirugs Überlegung zielte wohl vor allem darauf ab, dass man aufgrund der Lokalität des Samplings die Textur-Caches selber gar nicht mal sooo sehr vergrößern müsste. Die interne Bandbreite allerdings wird bei der aktuellen Fertigungstechnik wohl zum Problem.
Demirug
2003-12-29, 00:29:05
Original geschrieben von aths
Tri-2x-AF-TMUs brauchen noch mehr.
Die Bandbreite zum Cache ist identisch. 16 Texel/Takt. Die Filterlogik ist nur viel komplexer.
Ailuros
2003-12-29, 05:08:57
Original geschrieben von AlfredENeumann
Schon mal was von GDDR3-RAM gehört?
Samsung liefert derzeit 800MHz (!!!)Samples aus. Also wird etwas leicht darunter verfügbar sein, oder?
Reicht doch an Bandbreite, oder etwa nicht?
SAMSUNG hat generell im Moment Lieferungs-Probleme allen Bestellungen nachzukommen, wobei geschaetzt wird dass es ab Januar 2004 wieder besser sein wird.
Ich hab ernsthafte Zweifel dass R420 mit hoeher als 550-600MHz DDR2/3 ankommen wird, was aber auch genug sein sollte fuer tri-TMUs.
Original geschrieben von Gast
WOW;
wie lange werden wir noch auf solche 2xAF - TMU's warten müssen? Ich hoffe nicht ewig.
Anscheinend gibt es "AF for Free" schon :
http://www.xbitlabs.com/articles/video/display/s3-deltachrome_19.html
Sollte S3 beim Deltachrome wirklich schon "deinen", bzw einen ähnlichen Algorithmus implementiert haben, Demirug?
Wenn's stimmt Hochachtung für S3. Hätte ich denen nie im Leben zugetraut, nachdem Ati und Nvidia die Filtering-Qualität eher verschlechtern anstatt sie zu verbessern.
Das AF schaut zumindest nicht schlechter aus als bei der "Konkurrenz" :
http://www.xbitlabs.com/articles/video/display/s3-deltachrome_13.html ff
Ailuros
2004-01-02, 04:53:45
Original geschrieben von Gast
Anscheinend gibt es "AF for Free" schon :
http://www.xbitlabs.com/articles/video/display/s3-deltachrome_19.html
Sollte S3 beim Deltachrome wirklich schon "deinen", bzw einen ähnlichen Algorithmus implementiert haben, Demirug?
Wenn's stimmt Hochachtung für S3. Hätte ich denen nie im Leben zugetraut, nachdem Ati und Nvidia die Filtering-Qualität eher verschlechtern anstatt sie zu verbessern.
Das AF schaut zumindest nicht schlechter aus als bei der "Konkurrenz" :
http://www.xbitlabs.com/articles/video/display/s3-deltachrome_13.html ff
Ich hab ernsthafte Zweifel ueber die AF Resultate, also erstmal abwarten mit der "AF for free" Behauptung (hint: AF geht zur Zeit auf DC nur wenn es wenn der Applikation und nicht vom CP aufgerufen wird).
Von den Bildern abgesehen ist - mit Ausnahme der Winkel-abhaengigkeit bei ATI - die Qualitaet des DC NICHT BESSER. Selbst diese mickrigen shots zeigen moire Neben-effekte, was wohl auf die Notwendigkeit deutet einen positiveren LOD wie bei NV anzusetzen um Neben-effekten zu entgehen.
Natuerlich waere es beim Einsatz von Supersampling theoretisch egal, aber man kann dieses wohl auch nicht immer einsetzen.
Xmas@home
2004-01-02, 16:01:49
Original geschrieben von Ailuros
Von den Bildern abgesehen ist - mit Ausnahme der Winkel-abhaengigkeit bei ATI - die Qualitaet des DC NICHT BESSER. Selbst diese mickrigen shots zeigen moire Neben-effekte, was wohl auf die Notwendigkeit deutet einen positiveren LOD wie bei NV anzusetzen um Neben-effekten zu entgehen.
Positiver als bei NV, nicht wie bei NV. Wobei man eigentlich auch negativer sagen müsste ... tja, wenn der Wortsinn nicht den Zahlen entspricht.
Die LOD-Verschiebung ist jedenfalls recht eigenartig. Hat denn bisher noch keiner eine AF-Analyse beim DC mit geeigneten Tools gemacht? ;)
Ailuros
2004-01-02, 16:48:09
Hast recht, ich hab mich schlecht ausgedrueckt und auch wieder verwirrt mit dem +/- LOD Zeug. Eigentlich muesste es etwa -0.3/0.4 negativer als bei NV verschoben sein (nach Demi's Schaetzunen, die aber auch auf den shots sichtbar sind).
Positiv - ergo LOD +0.5, +1.0 usw.
Negativ - ergo LOD -0.5, -1.0 usw.
Demirug
2004-01-02, 17:11:35
Woran macht ihr den gerade das LOD Problem fest? An den eingefärbten Mip-Maps?
Falls ja dann muss das nicht zwangsläufig stimmen. Zecki hat mich da schon auf etwas aufmerksam gemacht was ich übersehen haben. Wenn man TRi aus einer Mipmap benutzt müssen die engefärbten Mipmaps so verschoben sein. Es wäre nur noch zu klären warum auch bei BIAF diese Verschiebung zu sehenist. Möglicherweise wird bei AF immer Tri gefiltert.
Xmas@home
2004-01-02, 18:47:31
Original geschrieben von Demirug
Woran macht ihr den gerade das LOD Problem fest? An den eingefärbten Mip-Maps?
Eher am Moiré, obwohl hier auch ein schlechteres Verfahren zum Einsatz kommen könnte.
robbitop
2004-01-03, 01:00:23
ergo: keiner weiß ob bei x-bit wirklich AF im Spiel war und wir dürfen auf ein brauchbares Review warten, um zu wissen ob es AF4free gibt?
zu den trilinearen TMUs des DC: sind diese denn breit genug angebunden?
Demirug
2004-01-03, 01:54:35
Original geschrieben von robbitop
zu den trilinearen TMUs des DC: sind diese denn breit genug angebunden?
An was? An den Cache sicherlich weil es sonst ja gar nicht funktionieren könnte. Was die Bandbreite zum Speicher angeht so wissen wir ja das der DC etwas schwach auf der Brust ist.
StefanV
2004-01-03, 02:16:09
Original geschrieben von robbitop
ergo: keiner weiß ob bei x-bit wirklich AF im Spiel war und wir dürfen auf ein brauchbares Review warten, um zu wissen ob es AF4free gibt?
Nö, nur darauf, daß die Karte endlich in den Handel kommt...
Für den Delta Chrome würd ich sogar die FX5800 'opfern', welche gerad in einem anderen Rechner bei Verwandten arbeitet...
PS: hat schon jemand infos, wann man den DC in D käuflich erwerben kann??
Ailuros
2004-01-03, 04:38:38
Original geschrieben von Xmas@home
Eher am Moiré, obwohl hier auch ein schlechteres Verfahren zum Einsatz kommen könnte.
Danke Xmas. :) Welches schlechteres Verfahren?
Demi,
Der moire in den screenshots vom xbit labs Review, hat mir sofort in's Auge gestochen.
Fuer diejenigen die es noch nicht bemerkt haben, bitte auf den Kreis im unteren Teil der shots konzentrieren.
***edit: (schaut sich um ob Thowe in Reichweite ist)
gibt es eigentlich nichts Neues vom Patent-watch? Ich bin zugegeben zu faul zum Suchen *hust*
stickedy
2004-01-03, 08:46:39
Original geschrieben von Stefan Payne
Nö, nur darauf, daß die Karte endlich in den Handel kommt...
Für den Delta Chrome würd ich sogar die FX5800 'opfern', welche gerad in einem anderen Rechner bei Verwandten arbeitet...
PS: hat schon jemand infos, wann man den DC in D käuflich erwerben kann??
Vermutlich Mitte bis Ende Januar! Dürfte also nicht mehr lange dauern!
Ailuros
2004-01-03, 17:33:51
Jetzt noch n OT: es wundert mich allen Ernstes was S3 ueber das vergangene Jahr angestellt hat, dass die Treiber nicht mehr ausgereift sind als sie sein koennten. Zu dem sind ja Simulatoren da....
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.