Diskussion zum Artikel "Der GeForce4 Ti AF-Bug"

[Leonidas]

Link zum Artikel (http://www.3dcenter.org/artikel/2002/10-01_a.php)

[Thowe]

Schöner Artikel :)

[Exxtreme]

Jupp. Zum Glück... nee, ich lass es lieber. ;)

Gruß
alex

[mapel110]

Originally posted by Thowe
Schöner Artikel :)

*anschliess*
endlich bekommt man nicht nur halbwahrheiten zu dem thema zu hören bzw zu lesen ! tolle arbeit !

[Andre]

Originally posted by mapel110


*anschliess*
endlich bekommt man nicht nur halbwahrheiten zu dem thema zu hören bzw zu lesen ! tolle arbeit !

Find ihn auch sehr gut - ich war überrascht, dass nicht sooo extrem viele Seitenhiebe verteilt wurden ;)

Nee, ernsthaft, gut lesbar und fundiert und auch im Fazit verständlich.

[Kennung Eins]

ist fein geworden, aths :)

[Radeonator]

Ganz gut der Artikel, bis auf die Tatsache das man bei 16x selbst im direkten vergleich mit dem 8x in der Praxis keine...naja ich lass das ma ;) . Kepp up the good work :D

[GUNDAM]

Ein wirklich guter Artikel;)

[Savay]

ein wirklich intressanter artikel. meine glückwünsche. dieser artikel bestätigt wiedereinmal voll und ganz warum 3DCenter meine favorisierte Harwareseite ist.

wie es das schicksal nunmal will habe ich mich selbst in den letzten 2 tagen intensiver im dem Anisotropen filter meiner GF4Ti beschäftigt.

alles natürlich im zusammenhang mit UT2003...versteht sich ja wohl von selbst ;)

nunja lange rede kurzer sinn: ich selbst bin nutzer des riva tuners und habe gestern zum ersten mal die optimierungs optionen für den AF in D3D bemerkt.
zunächst habe ich versucht die auswirkung der einzelnen stages auf die optik heraus zu arbeiten und habe dazu die "optimierten" stages auf Point Sampling gestellt! dabei ist mir aufgefallen das nur Stage0 für eine sichtbare verbesserung der optik dienlich ist, da diese die basis textur filtert. die zuständigkeiten von Stage1, 2 und 3 sind allerdings schwerer auszumachen. so scheint die 1.! MIP stufe der detail textur noch von stage0 gefiltert zu werden, da diese nicht im point sampling dargestellt wurde auch wenn stages 1-3 so eingestellt waren. welches stage für die light map etc. zuständig waren lies sich so aber leider nicht ausmachen.

insofern habe ich folgende annahme:

Stage0 = base texture
Stage1 = detail texture
Stage2 = detail Texture ?
Stage3 = ?

(anmerkung: es spielt keine rolle ob stage 1 ODER 2 auf PS steht die DT wird immer im PS dargestellt)


nun bringt eine ansiotrope filterung einer detailtextur ohnehin wenig da diese viel mehr die texturen im nah bereich um den spieler verschönern soll. AF filterung aber im grunde mehr auf mittlere distanz (und bei flachen winkeln) eine optische verbesserung herbeiführt.

per screenshot lässt sich auch sehr leicht beweisen das ein unterschied zwischen dem optimierten (entspricht Stage1-3 auf Trilinear) und normalen modus nicht auszumachen ist.

-----------------------------------------

nun habe ich auch folgende UT2k3 DEMO benchmarks mit einer reihe von settings durchgeführt. ich werde sowohl die flyby als auch die botmatch werte mit angeben, da es sich ja im grunde um das verhalten der grafikkarte dreht aber ich dennoch eine einschätzung der realen spielbarkeit des settings abgeben möchte :)

zunächst einmal die Specs des systems:
Athlon XP2000+ (normal 1800+)
GF4 Ti4400@4600
512MB DDR 2,5-2-2-1
Win2k, Det. 40.52

-optimized AF= Stages1, 2 und 3 auf trilinear ("always optimize stages" auf ON)
-default AF= alle Stages auf x faches AF


ohne FSAA, Trilinear
Flyby: 153,989
Botmatch: 53,927

diese werte sollen nur als referenz dienen. da es dank der CPU limitierung völlig unnötig ist im spiel auf FSAA zu verzichten. und der flyby wert ist eh hoch genug

--
2xFSAA, Trilinear
Flyby: 128,533
Botmatch: 53,353

2xFSAA, default 2xAF
Flyby: 91,063
Botmatch: 50,436

2xFSAA, optimized 2xAF
Flyby: 119,557
Botmatch: 53,011
--
4xFSAA, Trilinear
Flyby: 80,346
Botmatch: 47,937

4xFSAA, default 4xAF
Flyby: 56,081
Botmatch: 36,926

4xFSAA, optimized 4xAF
Flyby: 73,244
Botmatch: 45,756
--
zum schluss noch 2 hübsche schmankerl: :D

2xFSAA, optimized 4xAF
Flyby: 108,870
Botmatch: 52,116

2xFSAA, optimized 8xAF!!!!!
Flyby: 103,214
Botmatch: 51,257

---------------------

wie man erkennen kann ist dank einer optimierung der stages eine spielbarkeit selbst bei 8xAF gewährleistet. man kann die sogar soweit treiben das entgegen der behauptung im artikel eher eine höhere AF stufe als eine FSAA stufe aktivierbar ist und wir dennoch in der nähe der CPU limitierung bleiben...

insofern sollten wir denke ich das ammenmärchen des "langsamen" Anisotropen Filters der GF4 ad acta legen

mit freundlichen grüssen

Jörn Engbers


PS: falls sich jemand genötigt fühlt die werte in einer übersichtlichen Excel Tabelle oder den nachweis per screenshot über den optischen einfluss der optimierung zu bringen, so soll er sich von mir nicht daran gehindert fühlen :)

[Savay]

da habe ich doch im eifer glatt die auflsung vergessen...

1024*768

weitere fragen, anregungen oder einfach nur einen commentar auf den lippen???

mail to:

savay@w4e-ut2003.de

andernfalls bin ich evtl. im quakenet im channel #w4e oder #w4e.ut2k3 zu finden

:)

und noch viel spass mit einem blitzschnellen anisotropen filter...

BTW es ist mir bewusst das mein post keinerlein wiederlegung des im artikel angesprochenen "bugs" ist. er sollte nur die nutzbarkeit des anisotropen filters belegen.... :D leider kann ich auch keine messung der füllrate mit den genannten settings vornehmen, da sich der 3DMark bei mir nicht installieren lässt :/ was aber im grunde durch die verwendbarkeit des 8xAF in UT2003 eh unsinnig und rein theoretisch wäre ;)

[Savay]

so ich bins nochmal ;)

der Vsync war übrigends (logischerweise) aus :)

wer bilder für den optischen nachweis braucht der maile mir bitte an die oben genannte adresse.

ich habe

trilinear

8xAF optimized
4xAF optimized
2xAF optimized

und jeweils default
8xAF
4xAF
2xAF

pics in 1024*768+2xFSAA von BR-Anubis anzubieten :)

ein grosser unterschied lässt sich zischen optimiert und default nicht ausmachen. am ehesten an der lightmap aber dieses lässt sich nur auf stehendem bildschirm bzw. bei direktem vergleich zwischen default und optimized bemerken.

meiner meinung bzw meinen augen zu folge bringt AF bei den DetailTextures KEINERLEI verbesserung!
dies lässt sich auf den screens aber nicht nachweisen da sie aus einer gewissen höhe aufgenommen wurden.

aber da AF sowieso die optik auf DISTANZ und DetaileTextures nur für den NAH bereich gedacht sind ist es ja nur logisch das der einfluss einer anisotropen filterung in diesem falle minimal ist...sogar die anisoptrope filterung der Lightmaps bringt mehr :D

[Savay]

mittlerweile nervt es ich weiss ;)

aber ich habe soeben bemerkt das das "Terrain" in der UW engine gänzlich anders auf die anisotropie einstellung reagiert als die "static meshes" oder normales BSP

so ist auf terrain ein deutlicher optischer unterschied zwischen optimierten und default setting auszumachen!

das terrain in antalus verwendet scheinbar wesentlich mehr textur-layer als die "BSP" oder die "Static Meshes" in DM-Asbestos oder BR-Anubis! die kommt wohl daher das man mehrere dekolayer verwenden muss damit das "terrain" nicht zu eintönig erscheint!! wie in diesem tutorial beschrieben

Dieser umstand dürfte alle level mit terrain (also DM-Antalus oder CTF-Citadel) wesentlich ungünstiger für AF (da durch den oben genannten umstand wesentlich füllraten gebundener) machen als reine "Indoor" maps.

genauso heisst die das bei einer optimierung der AF stages die besten optischen resultate an den static meshes und auf BSP strukturen erzielt werden dürften.
also im umkehrschluss auf terrain kein oder nur ein geringer unterschied zu normaler trilinearer filterung zu erkennen ist :(

[Unregistered]

ich sollte mich mal registrieren :(

http://udn.epicgames.com/pub/Content/TerrainTutorial/

so das war es jetzt aber...und verzeiht mir bitte dieses gespamme...es ist schon spät ;)

[Thowe]

Originally posted by Unregistered
ich sollte mich mal registrieren :(

http://udn.epicgames.com/pub/Content/TerrainTutorial/

so das war es jetzt aber...und verzeiht mir bitte dieses gespamme...es ist schon spät ;)

Erster Satz ist immer eine gloreiche Idee :)

Zweiter Satz ist gerne verziehen, das wertet keiner als spammen.

[DATA]

Hi,

also wenn ich den Artikel richtig verstanden hab dann hatte die GF1 noch die beste TMU Architektur da sie mit dieser einen TMU gleich trilinear filtern konnte (pro Takt).

Also von der Leistung der TMU´s hier sieht es so aus wenn ich das richtig verstanden hab:

-----> schlechter ------>
GeForce1 ---> GeForce2/3 ----> GeForce4
1xtri 2xbi 1xbi

FRAGE:
Hätte also ne GeForce4 die TMU Architektur ner GeForce1 dann wäre die Karte beim trilinearen Filter (und auch AF??) schneller???? Oder hab ich da jetzt was falsch verstanden?

Weiß jemand wie viel Transistoren NV bei den TMU´s dadurch einspart? (GF1 zu GF4).

Danke

Gruß DATA

[ow]

Dass die GF2 nur bilinear pro TMU samplen halte ich fuer falsch.

Bei trilinearerm Filtern verringert sich die Leistung praktisch nicht (<10%), auch 2xAF trilinear kostet noch keine 20% Leistung gegenueber bilinear ohne AF.

[ow]

Originally posted by DATA
Hi,

also wenn ich den Artikel richtig verstanden hab dann hatte die GF1 noch die beste TMU Architektur da sie mit dieser einen TMU gleich trilinear filtern konnte (pro Takt).




Das sind unbestaetigte Spekulationen.

Die GF2 koennen IMO ebenfalls pro TMU pro Takt trilinear filtern.
Das laesst sich durch Leistungsmessungen mit verschiedenen Filtern zeigen.

[HOT]

Hmm... ich denke, dass NV sich wie bei DXT1 schlichtweg "verrechnet" hat. Man kann ja vorher das Resultat nicht wirklich betrachten und hatte dann keine Lust mehr den "Bug" zu fixen - immerhin kostet das auch ne Menge Geld.
Lustig ist allerdings, dass sich der DXT1 "Bug" durch die gesamte Geforce Linie zieht :D

Um mal zur Radeon9700 zu kommen: Meiner Meinung nach beschreitet ATIs t.AF hier den intelligenteren Weg, da NVs Implemetation einfach ZU viel Leistung frisst. Ich bin mal gespannt ob sich NV für den NV30 einen ähnlichen Algorithmus einfallen lässt, oder ob wieder ALLES t.AF
gefiltert wird ;)

[Endorphine]

Originally posted by HOT
Hmm... ich denke, dass NV sich wie bei DXT1 schlichtweg "verrechnet" hat. Man kann ja vorher das Resultat nicht wirklich betrachten und hatte dann keine Lust mehr den "Bug" zu fixen - immerhin kostet das auch ne Menge Geld.
Lustig ist allerdings, dass sich der DXT1 "Bug" durch die gesamte Geforce Linie zieht :D

Um mal zur Radeon9700 zu kommen: Meiner Meinung nach beschreitet ATIs t.AF hier den intelligenteren Weg, da NVs Implemetation einfach ZU viel Leistung frisst. Ich bin mal gespannt ob sich NV für den NV30 einen ähnlichen Algorithmus einfallen lässt, oder ob wieder ALLES t.AF
gefiltert wird ;)

Solange AF eine Option ist, die man auch komplett deaktivieren kann, ist eine Architektur, die maximale Qualität bei AF zu Lasten der Leistung ermöglicht wohl eher vorzuziehen, als eine Architektur, die - egal, wie man sie konfiguriert - Qualität der Geschwindigkeit opfert.

Ideal wäre natürlich, wie Leo schon ausdrücklich sagte, die Wahl völlig dem Anwender zu überlassen. Und das bietet derzeit weder NV noch ATI. Wie siehts da eigentlich mit Parhelia & Co aus?

[ow]

Originally posted by HOT

Um mal zur Radeon9700 zu kommen: Meiner Meinung nach beschreitet ATIs t.AF hier den intelligenteren Weg, da NVs Implemetation einfach ZU viel Leistung frisst. Ich bin mal gespannt ob sich NV für den NV30 einen ähnlichen Algorithmus einfallen lässt, oder ob wieder ALLES t.AF
gefiltert wird ;)



Dass NVs AF soviel Leisting frisst liegt wohl an der Chiparchitektur selbst aber nicht an dem AF Verfahren.

ATis Loesung, die uebrigens mit Intelligenz absolut nichts zu tun hat, kostet dafuer viel Bildqualitaet.
Wie hoch die AF-Leistung der ATi bei NVs AF Implementierung ware, darueber kann man nur spekulieren.

[ow]

Originally posted by Endorphine


Solange AF eine Option ist, die man auch komplett deaktivieren kann, ist eine Architektur, die maximale Qualität bei AF zugunsten der Leistung ermöglicht wohl eher vorzuziehen, als eine Architektur, die - egal, wie man sie konfiguriert - Qualität der Geschwindigkeit opfert.


Genau so sehe ich das auch. Fuer mich hat beste Bildqualitaet Vorrang vor allem.


Ideal wäre natürlich, wie Leo schon ausdrücklich sagte, die Wahl völlig dem Anwender zu überlassen. Und das bietet derzeit weder NV noch ATI. Wie siehts da eigentlich mit Parhelia & Co aus?


Ja, schoen waere es, den Anwender entscheiden zu lassen.

Der Parhelia kann AFAIK nur 2xAF, da kann man nix mehr einsparen durch AF-level-Reduktion.
Und sonstige Konkurrenz kenne ich nicht. Was gibt's denn noch ausser Ati. NV & Matrox?

[ow]

Ausser einer Menge Spekulationen kann ich dem Artikel nichts abgewinnen.

Jeglicher Beweis fuer die dort aufgestellten Behauptungen fehlt.

[Salvee]

Xmas Aniso-Test hat es auf die Startseite von Beyond3D geschafft.
Respekt!
(Leider haben sie seinen Nick falsch geschrieben :( )

[aths]

Originally posted by ow
Das sind unbestaetigte Spekulationen.

Die GF2 koennen IMO ebenfalls pro TMU pro Takt trilinear filtern.
Das laesst sich durch Leistungsmessungen mit verschiedenen Filtern zeigen. Setz dich am besten mal mit Xmas in Verbindung, der kann dir da ein Programm schicken mit dem diese Frage ein für alle mal zu klären ist.

[aths]

Originally posted by Endorphine
Ideal wäre natürlich, wie Leo schon ausdrücklich sagte, die Wahl völlig dem Anwender zu überlassen. Und das bietet derzeit weder NV noch ATI. Wie siehts da eigentlich mit Parhelia & Co aus? Parhelia hat im 3DMark2001 Multitexturing Fillrate-Test noch 1,65 GigaTexel Füllrate. GeForce4 Ti 4600 hat hier 0,612 GigaTexel Füllrate.

[aths]

Originally posted by ow
Ausser einer Menge Spekulationen kann ich dem Artikel nichts abgewinnen.

Jeglicher Beweis fuer die dort aufgestellten Behauptungen fehlt. Der "Beweis" ist, dass die synthetische Füllrate bei bilinearem AF bei GeForce3 taktbereinigt doppelt so hoch ist als wie bei GeForce4 Ti. Weiterhin lässt sich nachweisen, dass die synthetische AF-Füllrate der GeForce4 Ti im bi- und trilinearem Modus völlig gleich sind. Das beides sind reinste Fakten, an denen es nicht zu rütteln gibt. Das Bild mit der Pipeline ist eine Vermutung, die imo jedoch recht naheliegt. Hast du denn eine bessere anzubieten? Dann nur her damit.

[aths]

Originally posted by Salvee
Xmas Aniso-Test hat es auf die Startseite von Beyond3D geschafft.
Respekt!
(Leider haben sie seinen Nick falsch geschrieben :( ) Ohne Xmas' Test-Programm, was imo das sinnvollste ist was es zum Thema gibt, und ohne die im Forum geposteten Screenshots von Quasar, ow und anderen hätte ich einige Teile des Artikels nicht schreiben können, die ATI betreffen. Und ohne Xmas' Hinweis, dass mindestens GF3/4-TMUs nur bilinear sind (was das fehlende Puzzlestück war) hätte der Artikel auch keine Erklärung für den AF-Bug anbieten können.

[aths]

Originally posted by ow
Genau so sehe ich das auch. Fuer mich hat beste Bildqualitaet Vorrang vor allem.Dann müsste dir der 4x4 Supersampling-Modus bestimmter alter Detonator-Treiber ja sehr gut gefallen. Die nV-Optimiuerungen für AF wären sinnlos, da sie ja doch die Bildqualität leicht senken. Ich denke, das ist nicht der Fall. Für mich hat ein ausgewogenes Verhältnis von Bildqualität und Geschwindigkeit Vorrang. Dabei möchte ich in der Lage sein, das eine gegen das andere tauschen zu können. Ich würde also gerne auch vernünftige bilineare AF-Performance haben.

[ow]

Originally posted by aths
Setz dich am besten mal mit Xmas in Verbindung, der kann dir da ein Programm schicken mit dem diese Frage ein für alle mal zu klären ist.



Du kannst mir das auch hier mitteilen, was deine Tests mit dem Tool ergeben haben oder nicht?

[ow]

Originally posted by aths
Der "Beweis" ist, dass die synthetische Füllrate bei bilinearem AF bei GeForce3 taktbereinigt doppelt so hoch ist als wie bei GeForce4 Ti. Weiterhin lässt sich nachweisen, dass die synthetische AF-Füllrate der GeForce4 Ti im bi- und trilinearem Modus völlig gleich sind. Das beides sind reinste Fakten, an denen es nicht zu rütteln gibt. Das Bild mit der Pipeline ist eine Vermutung, die imo jedoch recht naheliegt. Hast du denn eine bessere anzubieten? Dann nur her damit.


aths, ich will diese Nachweise sehen!
Womit wurden die Fillrate-tests gemacht?
Und sind diese Tools auch zuverlaessig?

Mir fehlen eben diese konkreten Nachweise und Messmethoden in dem Artikel.

[aths]

Originally posted by ow
Du kannst mir das auch hier mitteilen, was deine Tests mit dem Tool ergeben haben oder nicht? Das Problem ist: Ich habe keine GeForce2.

[StefanV]

Originally posted by aths
Das Problem ist: Ich habe keine GeForce2.

Ich momentan auch nicht :)

Wenn ich eine haben sollte, dann sag ich dir bescheid, nicht Frank?? :)

[aths]

Originally posted by ow
aths, ich will diese Nachweise sehen!
Womit wurden die Fillrate-tests gemacht?
Und sind diese Tools auch zuverlaessig?

Mir fehlen eben diese konkreten Nachweise und Messmethoden in dem Artikel. Ich kann dir versichern, dass er nicht auf blauen Dunst aufgebaut wurde. Einige Füllraten-Tests wurden mit dem 3DMark2001 gemacht, von dessen Zuverlässigkeit man bei synthetischen Tests wohl ausgehen kann. Hinzu kamen andere Tests, wie z.B. die Gewinne bei bilinearem AF in Quake3 im Vergleich von GeForce3 und 4. Ausschlaggebend war ein Tool von Xmas, welches die These "AF-Geschwindigkeit bei GF4 Ti ist immer wie im trilinearen AF-Modus" bewies. Sein eigener Test auf GeForce3 bewies, dass der bilineare Modus (synthetisch) doppelt so schnell ist. Es gibt im ganzen Artikel keinen nicht als Vermutung deklarierten Punkt, der auf nebulöse Annahmen setzt. Dass bilineares AF auf GF4 Ti nur für trilineare Performance zu kriegen ist, während GF3 vom binilinearem Modus profitiert, kann jeder im Forum der eine dieser Karten hat nachmessen. Dein Misstrauen finde ich schade.

[ow]

Originally posted by aths
Das Problem ist: Ich habe keine GeForce2.


Also wurde diese Behauptung bzgl. der GF2 TMUs einfach so aufgestellt, ohne das zu belegen.

[ow]

Originally posted by aths
Ich kann dir versichern, dass er nicht auf blauen Dunst aufgebaut wurde. Einige Füllraten-Tests wurden mit dem 3DMark2001 gemacht, von dessen Zuverlässigkeit man bei synthetischen Tests wohl ausgehen kann.



Naja, sei dir da mal nicht so sicher. Beleg kommt heute abend.



Hinzu kamen andere Tests, wie z.B. die Gewinne bei bilinearem AF in Quake3 im Vergleich von GeForce3 und 4. Ausschlaggebend war ein Tool von Xmas, welches die These "AF-Geschwindigkeit bei GF4 Ti ist immer wie im trilinearen AF-Modus" bewies. Sein eigener Test auf GeForce3 bewies, dass der bilineare Modus (synthetisch) doppelt so schnell ist. Es gibt im ganzen Artikel keinen nicht als Vermutung deklarierten Punkt, der auf nebulöse Annahmen setzt. Dass bilineares AF auf GF4 Ti nur für trilineare Performance zu kriegen ist, während GF3 vom binilinearem Modus profitiert, kann jeder im Forum der eine dieser Karten hat nachmessen. Dein Misstrauen finde ich schade.


Dieses Xmas Tool muss ich mal probieren.:)

btw. wie erklaerst du dir den starken Einbruch der Radeons bei trilinear gegenueber bilinear, der ja weitaus hoeher ausfaellt als der Einbruch auf einer GF2/3/4?


btw2 liegt Misstrauen (wenn man das so nennen kann) in meiner Natur, nimm das nicht persoenlich. Aber ich will harte Fakten inkl. Beweise (Messmethoden) und konkrete Ergebnisse sehen.



btw3. muss zurueck an die Arbeit;(

[aths]

Originally posted by ow
Also wurde diese Behauptung bzgl. der GF2 TMUs einfach so aufgestellt, ohne das zu belegen. Als einen Beleg wertete ich die von dir im Forum geposteten Ergebnisse bei GF2 MX. Außerdem wäre eine GF2 mit je 2 trilinearen TMUs pro Pipeline extrem unausgewogen dimensioniert, so dass 2 bilinare TMUs einfach vernünftiger sind. Zumal der Artikel dargelegt hat, dass hierfür nicht allzugroße Änderungen ausgehend NV10 notwendig waren.

[aths]

Originally posted by ow
Dieses Xmas Tool muss ich mal probieren.:)Ohne unsere Foren-Programmierer wie Xmas und zeckensack, die auch ultrafernliegende Wünsche erfüllen, wäre das Diskutieren hier nur halb so schön.
Originally posted by ow
btw. wie erklaerst du dir den starken Einbruch der Radeons bei trilinear gegenueber bilinear, der ja weitaus hoeher ausfaellt als der Einbruch auf einer GF2/3/4?Redest du von iso- oder anisotroper Filterung?
Originally posted by ow
btw2 liegt Misstrauen (wenn man das so nennen kann) in meiner Natur, nimm das nicht persoenlich. Aber ich will harte Fakten inkl. Beweise (Messmethoden) und konkrete Ergebnisse sehen.Die GF2 eigentlich gar nicht Thema des Artikels. Was GeForce3 und 4 betrifft, so habe ich selbst endlos gebencht, und andere (Leo, Xmas) genervt, mir bestimmte Benchmark-Ergebnisse zu senden. Und die Bilder zur Aufbau der Pipeline enstanden in Zusammenarbeit mit Demirug.

[ow]

Originally posted by aths
Als einen Beleg wertete ich die von dir im Forum geposteten Ergebnisse bei GF2 MX. Außerdem wäre eine GF2 mit je 2 trilinearen TMUs pro Pipeline extrem unausgewogen dimensioniert, so dass 2 bilinare TMUs einfach vernünftiger sind. Zumal der Artikel dargelegt hat, dass hierfür nicht allzugroße Änderungen ausgehend NV10 notwendig waren.


Auf eine Pipe bezogen:

Wenn eine Gf2 nur 2 bilineare TMUs hat, dann muesste sie doch entweder beide TMUs fuer trilinear nutzen, oder eben 2 Takte fuer trilinear auf einer TMU brauchen (um 2x4 Texel zu verarbeiten).

Ersteres schliesse ich mal aus, weil dann doch kein trilinear UND Multitexturing moeglich waere (wie zB. beim RivaTNT, da ist die Sache ja ganz klar), oder irre ich da?

Aber beides muesste doch die Leistung um einiges senken, aber egal was ich benche, die Unterschiede zwisdchen bilinear und trilinear mit/ohne MT sind sehr gering.

[ow]

Originally posted by aths
Ohne unsere Foren-Programmierer wie Xmas und zeckensack, die auch ultrafernliegende Wünsche erfüllen, wäre das Diskutieren hier nur halb so schön.


Redest du von iso- oder anisotroper Filterung?

Die GF2 eigentlich gar nicht Thema des Artikels. Was GeForce3 und 4 betrifft, so habe ich selbst endlos gebencht, und andere (Leo, Xmas) genervt, mir bestimmte Benchmark-Ergebnisse zu senden. Und die Bilder zur Aufbau der Pipeline enstanden in Zusammenarbeit mit Demirug.



Ja, wir haben schon ein paar richtig gute Leute hier=)

Ich sprach von isotroper Filterung, also einfaches bilinear gegen trilinear (4Texel vs. 8 Texel).

Wenn xmas sein Tool rausrueckt kann ich dir GF2(MX) Ergebnisse liefern.;)

[aths]

Originally posted by ow
Auf eine Pipe bezogen:

Wenn eine Gf2 nur 2 bilineare TMUs hat, dann muesste sie doch entweder beide TMUs fuer trilinear nutzen, oder eben 2 Takte fuer trilinear auf einer TMU brauchen (um 2x4 Texel zu verarbeiten).

Ersteres schliesse ich mal aus, weil dann doch kein trilinear UND Multitexturing moeglich waere (wie zB. beim RivaTNT, da ist die Sache ja ganz klar), oder irre ich da?Für derartige Optionen 2 Takte zu brauchen darf nicht mit mehreren Passes oder Loopback welches zusätzliche Texture Stages zur Verfügung stellen würde verwechselt werden. Trilineares Multitexturing würde dann in jedem Fall 2 Takte pro Pipeline brauchen (sofern es kein Pipeline Combining gibt.) Die "virtuellen" Texture Stages werden auf die Hardware abgebildet, wie das genau vor sich geht, weiß ich nicht. Jedenfalls sehe ich kein Problem, bei 2 bilinearen TMUs trilineares Multitexturing zu erzeugen. Man braucht dann halt 2 Takte. Anisotropes Filterung braucht auch jeweils mehrere Takte. Das ist für die Hardware ein wenig zusätzlicher Aufwand. 2 trilineare TMUs pro Pipe entsprechen allerdings 4 bilinearen TMUs. Das wäre wohl noch deutlich transistorfressender, als eine Art "internes Loop-Back". Zumal die Bandbreiten-Anforderungen gigantisch wären. Außerdem, GeForce3 hat mit Sicherheit nur bilineare TMUs. Damit wäre die Karte bei trilinearer Filterung rein Füllratenmäßig deutlich unter GTS-Niveau. Und von diesem Verhalten habe ich noch nie gehört.Originally posted by ow
Aber beides muesste doch die Leistung um einiges senken, aber egal was ich benche, die Unterschiede zwisdchen bilinear und trilinear mit/ohne MT sind sehr gering. Um wieviel Prozent unterscheiden sie sich? Machst du Realworld oder synthetische Benchmarks? Bei Realworld-Benchmarks sind nur geringe Unterschiede nicht verwunderlich. Wenn ich z.B. reine bilineare mit reiner trilinearen Filterung in Quake vergleiche, sind die Unterschiede auch nicht so wahnsinnig hoch.

[Leonidas]

Originally posted by ow

Wenn xmas sein Tool rausrueckt kann ich dir GF2(MX) Ergebnisse liefern.;)

http://www.beyond3d.com/misc/Anisotest/

[Xmas]

Originally posted by Leonidas


http://www.beyond3d.com/misc/Anisotest/
Das ist nicht das was hier gemeint ist. Ich habe noch einen Fillrate-Test geschrieben (extrem spartanisch, rendert einfach 2000 Quads mit 1000x1000 Pixeln), der aber nicht zum Download bestimmt ist.

ow, du hast PM.

[aths]

... Und was hat der ow da nun herausbekommen?

[ow]

Reproduzierbare aber nicht erklaerbare Werte:D

GF2MX, Det. 3082

1024x32: b1, b2, t1 etwa 8s, t2 etwa 16s
1152x32: b1, b2, t1 etwa 10s, t2 etwa 20s
1280x32: b1, b2, t1 etwa 12s, t2 etwa 22s

alle Angaben etwa +- 0,5s.


Bitte um Interpretation:D;)

[zeckensack]

Originally posted by ow
Reproduzierbare aber nicht erklaerbare Werte:D

GF2MX, Det. 3082

1024x32: b1, b2, t1 etwa 8s, t2 etwa 16s
1152x32: b1, b2, t1 etwa 10s, t2 etwa 20s
1280x32: b1, b2, t1 etwa 12s, t2 etwa 22s

alle Angaben etwa +- 0,5s.


Bitte um Interpretation:D;) Trilinear Dual-Texturing dauert doppelt solange wie Tri Single, oder Bilinear (Single/Dual). Letztere drei Kombis sind dabei gleichschnell, was aths These stützt.


@XMas:
Das Prog schreibt keine Z-Werte und nimmt nur eine winzige (100% cache-kompatible) Textur, gell? :-)

wieder @ow,
Da sind wohl Umstände am Werk, die der Gf2MX aus dem Bandbreitenlimit helfen und endlich die Füllrate messbar machen :naughty:

edit:
Ist die Viper 2 inzwischen eingetroffen?
edit2:
Ach shice, heute ist ja Feiertag ... :bonk:

[StefanV]

Originally posted by zeckensack
edit:
Ist die Viper 2 inzwischen eingetroffen?
edit2:
Ach shice, heute ist ja Feiertag ... :bonk:

Warum??
Hab das Mistding momentan drin...

Fliegt aber innerhalb der nächsten 2h raus, da als Office Karte unter WXP unbrauchbar :)

[zeckensack]

Originally posted by Stefan Payne
Warum??Weil ich sie ow gestern morgen geschickt habe???
Hab das Mistding momentan drin...

Fliegt aber innerhalb der nächsten 2h raus, da als Office Karte unter WXP unbrauchbar :) Hmmm. WinXP-Treiber gibt's ja auch nicht dafür. Unter 98 gab's im 2D-Betrieb keinerlei Probleme damit und ow nutzt AFAIK auch 98.
Also, mach ihm keine unnötige Angst :bäh:

[Unregistered]

Originally posted by zeckensack
Trilinear Dual-Texturing dauert doppelt solange wie Tri Single, oder Bilinear (Single/Dual). Letztere drei Kombis sind dabei gleichschnell, was aths These stützt.



Aeh... AFAIK ist da nix single, dual texturing, sondern b/t = bi-/trilinear und Zahl = AF Modus. Es werden immer 2 Texturen genutzt (Multitexturing)

Also bilinear ohne AF, bilinear 2xAF und trilinear ohne AF sind gleich schnell, trilinear 2xAF braucht doppelt so lange.



wieder @ow,
Da sind wohl Umstände am Werk, die der Gf2MX aus dem Bandbreitenlimit helfen und endlich die Füllrate messbar machen :naughty:

edit:
Ist die Viper 2 inzwischen eingetroffen?
edit2:
Ach shice, heute ist ja Feiertag ... :bonk:


Ich nix Ahnung:D

edit: nein
edit2: in 2 Stunden hab ich Feierabend, in LU interessiert der heutige Feiertag nicht.


-ow@work-

[zeckensack]

Originally posted by Unregistered


Aeh... AFAIK ist da nix single, dual texturing, sondern b/t = bi-/trilinear und Zahl = AF Modus. Es werden immer 2 Texturen genutzt (Multitexturing)

Also bilinear ohne AF, bilinear 2xAF und trilinear ohne AF sind gleich schnell, trilinear 2xAF braucht doppelt so lange.Ich habe das Programm ja nicht selbst, aber b1, b2 und entsprechend t1 und t2 können IMO nicht viel anderes bedeuten, als daß die Anzahl der Texturen geändert wird ;)

edit2: in 2 Stunden hab ich Feierabend, in LU interessiert der heutige Feiertag nicht.


-ow@work- Aber die 'Lieferanschrift' liegt doch in D ???
*edit* Bundesland wieder entfernt wg Privatsphäre :naughty:

[Unregistered]

der hohe füllratenwert in opengl mit optimierung schließt eigentlich ein hardwarelimit aus oder???


sollte jede pipeline wirklich nur eine tmu zur anisotropen filterung nutzen können wäre so ein ergebnis nich mal theoretisch möglich oder sehe ich da was falsch???

[ow]

Originally posted by zeckensack
Ich habe das Programm ja nicht selbst, aber b1, b2 und entsprechend t1 und t2 können IMO nicht viel anderes bedeuten, als daß die Anzahl der Texturen geändert wird ;)

Aber die 'Lieferanschrift' liegt doch in D ???
*edit* Bundesland wieder entfernt wg Privatsphäre :naughty:


a) ich habe das Prog samt Erklaerung und es ist so wie ich sagte.

Es wird immer 2-fach MT genutzt, b=bi, t=tri, Zahl = AF-level.
b2= bilinear 2xAF etc...

b) ja, ich bin Saarlaender, zur Zeit bruflich taetig in Luxemburg

[aths]

Originally posted by Unregistered
Also bilinear ohne AF, bilinear 2xAF und trilinear ohne AF sind gleich schnell, trilinear 2xAF braucht doppelt so lange.Jede Pipeline kann pro Takt 2 bilineare Texel erzeugen.

Damit ist eine bilineare, eine trilineare oder eine 2x bi AF Filterung möglich (jeweils werden bis zu 2 Texel gebraucht.) 2x tri AF braucht doppelt so lange (da 4 Texel notwendig.)

Hätte die GF2 trilineare TMUs, dürfte es bei 2x tri AF keinen Füllraten-Nachteil geben, der aber vorhanden ist.

[Unregistered]

ich hab ein weiteres indiz gefunden, welches schließen lässt dass der "bug" zumindest kein reines hardwarelimit ist

ich machte verschiedene füllratentests mit af(ohne optimierung) und fsaa im 3dmark.

meine graka: gf4ti4400, standardtakt
theoreische füllrate:
1100 Mpixel/s
2200 Mtexel/s

mit nur af aktiviert sanken beide werte auf ca. 560, was also eindeutig den bug beschreibt.

wenn ich allerdings fsaa dazu aktiviere, sinkt zwar die pixelfüllrate leicht weiter, allerdings die multitexturing-fillrate nicht. ok, schieben wir das ganze mal dem multisampling zu, was ja sehr wenig fillrate braucht.

nun machte ich einen letzten test mit 4xS FSAA, was ja einen 2x supersampling-anteil hat.

zu erwarten wären 2 werte von ca. 275, da die füllrate ja 2x halbiert wird.

mit der pixelfüllrate ist das auch der fall (ergebnis ca. 250 MPixel/s)

allerdings blieb die multitexturing-fillrate konstant auf 550-560 MPixel.

wieso kann die gf4 da plötzlich doch mit 2 tmu´s anisotrop filtern???

oder gibts eine andere logische erklärung???

[ow]

?

Erklär mir das mal so, dass ich das auch verstehe.

Was ist denn ein bilineares Texel?
Das Ergebnis der linearen Fiterung zweier linear gefilterter Texel?

Und wieso ist die TMU nicht trilinear, wenn sie Trilinear in einem Takt filtern kann?

Und was ist mit Multitexturing?

[Unregistered]

Abgesehen von gewissen Radeon-Vorteilen durch 16x bleibt das GeForce-Verfahren, rein von der Bildqualität her gesehen, weiterhin der strahlende Sieger.

MUHA?! Schon mal die Bildquali zwischen ner Radeon 85 und einer GF gesehen? Wer schreibt denn so einen scheissdreck???

[aths]

Originally posted by ow
Erklär mir das mal so, dass ich das auch verstehe.

Was ist denn ein bilineares Texel?Ein fertig bilinear gefiltertes Texel.
Originally posted by ow
Das Ergebnis der linearen Fiterung zweier linear gefilterter Texel?Nein :) Siehe Filter-Artikel. Texel werden in 2 Richtungen (du und dv) interpoliert, daher bi-linear.
Originally posted by ow
Und wieso ist die TMU nicht trilinear, wenn sie Trilinear in einem Takt filtern kann?Na weil es doch 2 TMUs pro Pipeline gibt.
Originally posted by ow
Und was ist mit Multitexturing? Dafür werden zwei Takte benötigt.

[aths]

Originally posted by Unregistered
Abgesehen von gewissen Radeon-Vorteilen durch 16x bleibt das GeForce-Verfahren, rein von der Bildqualität her gesehen, weiterhin der strahlende Sieger.

MUHA?! Schon mal die Bildquali zwischen ner Radeon 85 und einer GF gesehen? Wer schreibt denn so einen scheissdreck??? Ich :D

Schon mal GeForce4 AF in Aktion gesehen?

[aths]

Originally posted by Unregistered
allerdings blieb die multitexturing-fillrate konstant auf 550-560 MPixel.

wieso kann die gf4 da plötzlich doch mit 2 tmu´s anisotrop filtern???

oder gibts eine andere logische erklärung??? Ich habe korrekte Werte: 282 MT bei ST, 309,1 MT bei MT.

[ow]

Originally posted by aths
Ein fertig bilinear gefiltertes Texel.
Nein :) Siehe Filter-Artikel. Texel werden in 2 Richtungen (du und dv) interpoliert, daher bi-linear.
Na weil es doch 2 TMUs pro Pipeline gibt.
Dafür werden zwei Takte benötigt.


Könntest du die letzten 2 Punkte mal genauer erläutern?

Wieso soll man 2 Takte für MT brauchen, wenn man doch 2 TMUs hat?

[ow]

Ich hab mal ein paar VillageMark Tests auf der MX gemacht.

Auflösung ist 400x300 (um die Laufzeit akzeptabel zu halten;))


16Bit/TC ohne TC
bi 103 101
biAF 97 93
tri 98 95
triAF 74 70

32Bit/TC ohne TC
bi 86 84
biAF 81 78
tri 82 79
triAF 68 64


/edit: höchster GF2MX Score: 133fps (320x240x16, bilinear mit TC) :D

[aths]

Originally posted by ow
Könntest du die letzten 2 Punkte mal genauer erläutern?

Wieso soll man 2 Takte für MT brauchen, wenn man doch 2 TMUs hat? Weil trilinear gefiltert wird. Pro Textur ist ein trilinear gefiltertes Texel erforderlich, für welches wiederum 2 bilineare Texel erzeugt werden müssen. Hat man 2 bilineare TMUs in der Pipeline, kann man pro Takt ein trilineares Texel erzeugen. Für 2 Texturen bräuchte man dann 2 Takte.

[aths]

Originally posted by ow
[code]
16Bit/TC ohne TC
bi 103 101
biAF 97 93
tri 98 95
triAF 74 70

32Bit/TC ohne TC
bi 86 84
biAF 81 78
tri 82 79
triAF 68 64
[code]Ich denke dass diese Werte zeigen, dass GF2 nur bilineare TMUs hat. Denn der Übergang zu 2x tri AF fällt recht groß aus, ansonsten liegen die Werte recht nahe beieinander. Für 2x tri AF sind pro einzelne Textur 4 bilineare Texel erforderlich, während reines tri oder 2x bi AF mit 2 bilinearen Texeln zu rendern sind. Das könnte man mit trilinearen TMUs in einem Takt erzeugen. Der Abstand der Werte weist darauf hin, dass zwei Takte erforderlich sind.

Der reine bilineare Filter geht noch schneller, was darauf hinweist, dass Multitexturing verwendet wird. Denn rein bilinear kann die Pipeline 2xMT in einem einzigen Takt ausführen. Wären die TMUs ohnehin trilinear, dürfte der bilineare Modus praktisch keinen Vorteil bringen, wenn man mal von der Bandbreite absieht.

[Unregistered]

Ich hab ne Radi 85 und ne GF4 Ti42 und das sind welten!! Die GF4 Ti42 macht bei UT schlapp und die Radi roxx! Auch die Bildquali ist von der Radi unschlagbar...

[aths]

Originally posted by Unregistered
Ich hab ne Radi 85 und ne GF4 Ti42 und das sind welten!! Die GF4 Ti42 macht bei UT schlapp und die Radi roxx! Auch die Bildquali ist von der Radi unschlagbar... Wir (3DCenter) bringen noch einen Artikel der erklärt, wie genau man die GeForce4 Ti nun optimieren kann, um auch in UT2003 8x AF zu genießen. (Im Gegensatz zur Radeon8500 ist außerdem noch Anti-Aliasing drin.)

edit: Ich merke gerade, bei den 40.71-er Treibern nützt die ganze D3D-Optimiererei nichts :bonk: Funktioniert hier die Optimierung nicht oder ist sie schon standardmäßig aktiv? Da muss ich wohl mal Unwinder fragen.

[ow]

Originally posted by aths
Weil trilinear gefiltert wird. Pro Textur ist ein trilinear gefiltertes Texel erforderlich, für welches wiederum 2 bilineare Texel erzeugt werden müssen. Hat man 2 bilineare TMUs in der Pipeline, kann man pro Takt ein trilineares Texel erzeugen. Für 2 Texturen bräuchte man dann 2 Takte.


Müsste dann nicht die Leistung bei Trilinear+MT einbrechen?

So wie du das beschreibst stelle ich mir den TNT vor.
Da er nur bilineare TMUs hat kann er bei Multitexturing nicht trilinear filtern (deshalb nutzt er mipmap-dithering).

Und welche Grafikchips haben trilineare TMUs?

[Demirug]

OK ich hab jetzt zwei Stunden in der Patent-datenbank gewühlt und ich denke ich hab die Lösung gefunden.

Also die TMU-Filter der GF2 scheinen mit 8 RGBA Lines (32 Bit * 8 = 256 Bit) an den Texturcache angebunden zu sein. Im den Filter arbeiten 7 Einheiten welche jeweils 2 RGBA werte linear verrechnen können. angeordent in 3 Stufen. Dazu kommt dann noch eine 4 Stufe mit einer Einheit für einen Loopback.

Das heist in einem Durchlauf können bis zu 8 Texturwerte verechnet werden. Daraus ergibt sich:

Kein AF bi = 4 Werte = 1 Durchlauf
Kein AF tri = 8 Werte = 1 Durchlauf
2x AF bi = 8 Werte = 1 Durchlauf
2x AF tri = 16 Werte = 2 Durchläufe

Ich mach euch auch gerne noch ein bild davon, aber nicht mehr heute.

[aths]

Originally posted by ow
Müsste dann nicht die Leistung bei Trilinear+MT einbrechen?Einbrechen ist übertrieben, aber in der Tat sind die Ergebnisse bei trilinearer Filterung doch niedriger als bei bilinearer.

Originally posted by aths
Der reine bilineare Filter geht noch schneller, was darauf hinweist, dass Multitexturing verwendet wird. Denn rein bilinear kann die Pipeline 2xMT in einem einzigen Takt ausführen. Wären die TMUs ohnehin trilinear, dürfte der bilineare Modus praktisch keinen Vorteil bringen, wenn man mal von der Bandbreite absieht.
Originally posted by ow
So wie du das beschreibst stelle ich mir den TNT vor.
Da er nur bilineare TMUs hat kann er bei Multitexturing nicht trilinear filtern (deshalb nutzt er mipmap-dithering).Das Mapping der virtuellen Texture Stages auf die TMUs scheint hier begrenzt zu sein, da der TNT offenbar keine interne Loopback-Logik hat und nicht in der Lage ist, für einen Pass 2 Takte zu verwenden. (Das ist jetzt meine Theorie, Demirug kann da vielleicht konkreter werden.)
Originally posted by ow
Und welche Grafikchips haben trilineare TMUs? Xmas meint, GF256 hat welche. Angesichts der Dimensionierung Füllrate und Speicherbandbreite mit DDR-RAM scheint das auch sinnvoll. Radeon1 hat afaik 2 trilineare und 1 bilineare TMU. Ob das wirklich stimmt, weiß ich allerdings nicht. Ebenso habe ich keine Ahnung, ob Radeon8500 bzw. Radeon9000 bi- oder trilineare TMUs haben.

Dass GeForce2 nur bilineare TMUs hat, halte ich schon angesichts der Speicherbandbreite für nachvollziehbar.

[Demirug]

So hier noch die Zeichnung:

[ow]

Originally posted by Demirug
OK ich hab jetzt zwei Stunden in der Patent-datenbank gewühlt und ich denke ich hab die Lösung gefunden.

Also die TMU-Filter der GF2 scheinen mit 8 RGBA Lines (32 Bit * 8 = 256 Bit) an den Texturcache angebunden zu sein. Im den Filter arbeiten 7 Einheiten welche jeweils 2 RGBA werte linear verrechnen können. angeordent in 3 Stufen. Dazu kommt dann noch eine 4 Stufe mit einer Einheit für einen Loopback.

Das heist in einem Durchlauf können bis zu 8 Texturwerte verechnet werden. Daraus ergibt sich:

Kein AF bi = 4 Werte = 1 Durchlauf
Kein AF tri = 8 Werte = 1 Durchlauf
2x AF bi = 8 Werte = 1 Durchlauf
2x AF tri = 16 Werte = 2 Durchläufe

Ich mach euch auch gerne noch ein bild davon, aber nicht mehr heute.



Genau so dachte ich mir das, jede TMUs kann 8 Texel/Takt verarbeiten -> triAF = 16 Texel = 2 Takte.

Aber mir ist immer noch nicht klar, wieso dass dann ein bilineare TMU sein soll. IMO kann ein bilineare TMU nur 4Texel/Takt verarbeiten.



@aths

Radeon 1 Villagemark,
1024x32Bit mit TC, single pass (MX braucht 2 passes (2+1))

trilinear 38fps
bilinear 60fps

Wo siehst du da trilineare TMUs am Werk, wenn trotz single-pass der Leistungseinbrauch wesentlich groesser ist als bei der MX??


Die Radeon 9700 bricht auch bei trilinear auf etwa 60% des bilinear Wertes ein (http://www.forum-3dcenter.net/vbulletin/showthread.php?s=&threadid=32804).

Das stehen die GF2 aber ausgesprochen gut da, oder nicht??

[Demirug]

Originally posted by ow

Genau so dachte ich mir das, jede TMUs kann 8 Texel/Takt verarbeiten -> triAF = 16 Texel = 2 Takte.

Aber mir ist immer noch nicht klar, wieso dass dann ein bilineare TMU sein soll. IMO kann ein bilineare TMU nur 4Texel/Takt verarbeiten.


Sehe ich genauso. Hat eigentlich mal jemand bei der GF4TI den Fillrate unterschied zwischen bi und tri ohne AF gemessen?

[ow]

Originally posted by aths

Xmas meint, GF256 hat welche. Angesichts der Dimensionierung Füllrate und Speicherbandbreite mit DDR-RAM scheint das auch sinnvoll. Radeon1 hat afaik 2 trilineare und 1 bilineare TMU. Ob das wirklich stimmt, weiß ich allerdings nicht. Ebenso habe ich keine Ahnung, ob Radeon8500 bzw. Radeon9000 bi- oder trilineare TMUs haben.

Dass GeForce2 nur bilineare TMUs hat, halte ich schon angesichts der Speicherbandbreite für nachvollziehbar.


Fuer mich ist das nicht nachvollziehbar.

Du meinst also, der Gf256 kann tri 2xAF ohne jeden Leistungsverlust?
Fuer mich unvorstelbbar.

IMO wurden die TMUs von der Gf1 zur Gf2 nicht geaendert sondern nur verdoppelt.

[aths]

Originally posted by ow
Du meinst also, der Gf256 kann tri 2xAF ohne jeden Leistungsverlust?
Fuer mich unvorstelbbar.Da sie nur eine TMU pro Pipe hat, natürlich nicht.

[aths]

Originally posted by Demirug
So hier noch die Zeichnung: Gilt diese pro Pipeline oder pro TMU? Gilt die Zeichnung für NV15 oder NV10 oder für beide?

[Demirug]

Zu erst mal ist die Zeichnung natürlich nur spekulation :)

Aufgrund der Messergebnisse des Fillratetests (Xmas) von oben müsste der NV15 über einen solchen Filter pro TMU verfügen. Ob der NV10 den gleichen Filter hat kann ich aufgrund fehlender Vergleichszahlen nicht sagen. Ich hätte aber eine GF1 zum testen zur hand bin nur zu faul jetzt selbst ein Testprogramm zu schreiben.

Edit: ich sehe gerade das die Messungen ja auf einer MX gemacht wurden. das heist dann natürlich das die Filter des NV11 so aufgebaut sein müssen. Haben wir von dem Test auch ergebnisse von anderen Chips?

[PCGH_Thilo]

Originally posted by aths
Wir (3DCenter) bringen noch einen Artikel der erklärt, wie genau man die GeForce4 Ti nun optimieren kann, um auch in UT2003 8x AF zu genießen. (Im Gegensatz zur Radeon8500 ist außerdem noch Anti-Aliasing drin.)

edit: Ich merke gerade, bei den 40.71-er Treibern nützt die ganze D3D-Optimiererei nichts :bonk: Funktioniert hier die Optimierung nicht oder ist sie schon standardmäßig aktiv? Da muss ich wohl mal Unwinder fragen.

hab die 30.82 gestern mal gegen die 40.71 in ut durchgenudelt (ti-4200 mit 64 mb, win9x).
ergebnis: bei aktivem 4:1 af schon 25% (!) schneller mit dem 40.71. die werte kann ich leider nicht posten, da ich momentan on the road bin. aber die optimierungen scheinen schon im treiber drin zu sein. screenshotsbeweise stehen noch aus. bei warcraft 3 übrigens keine performanceverbesserung bei aktivem af, aber da sind auch nicht ganz so viele texturen zu filtern wie bei ut2003 ;-)

[Unregistered]

Originally posted by aths
Da sie nur eine TMU pro Pipe hat, natürlich nicht.


Ja, aber die 2. TMU der Gf2 wird doch fuer Multitexturing gebraucht und nicht zum AF-Filtern?

AFAIK nutzt der Gf1 Pipeline-combining fuer MT (wie der TNT/TNT2 auch).

Und fuer die TNT weiss man, dass sie in MT-Konfiguration (1Pipe mit 2TMUs) kein trilineares Filtern beherrschen (und wie du schon sagtest auch keine 2Takte dafuer nutzen koennen), also nur bilineare TMUs haben.



Mal anders gefragt: wenn die Gf2 nur bilineare TMUs haette, was sind denn dann die TMUs eines TNT/TNT2??

[StefanV]

Originally posted by Unregistered
Mal anders gefragt: wenn die Gf2 nur bilineare TMUs haette, was sind denn dann die TMUs eines TNT/TNT2??

'logischerweise' auch Bilineare TMUs, da man im Laufe der Entwicklung lieber auf 'vorhandenes' zurückgreift, als irgendwas 'neu zu erfinden...



Originally posted by Unregistered

Ja, aber die 2. TMU der Gf2 wird doch fuer Multitexturing gebraucht und nicht zum AF-Filtern?


naja, wenn man 2 Bilineare TMUs hat, dann muß man sie entweder 'zusammenfassen' oder man legt zusätzliche Wartezyklen ein, wenn man etwas Trilinear gefiltert haben möchte....

[ow]

Dann versuch doch mal, die von mir gemessenen Werte damit in Einklang zu bringen.

IMO haben sich die TMUs vom TNT zum Gf1 von bilinear (4Texel/clk) auf trilinear (8Texel/clk) geaendert.

[Xmas]

Originally posted by zeckensack
@XMas:
Das Prog schreibt keine Z-Werte und nimmt nur eine winzige (100% cache-kompatible) Textur, gell? :-)
Das hat dir der Teufel gesagt! ;)
Genau so isses, aber Multitexturing mit zwei Texturen (Modulate, nicht Replace, sonst könnte der Treiber da noch "cheaten")

[Xmas]

Originally posted by Demirug
So hier noch die Zeichnung:
OK, das sind dann ganz klar trilineare TMUs.


Mein Programm malt 2000 1000x1000 Pixel große doppelt texturierte Quads in ein Fenster (deswegen sind auch nur ows Ergebnisse bei 1280x1024 "richtig", weil mehr als 1000 Zeilen). Also 4 GTexel. Der Anisotropie-Grad ist dabei >8, damit die AF-Einstellung auch einen Unterschied macht.

Für meine GF3Ti200 ergibt sich dabei:
b1: ~3s
b2: ~6s
t1: ~6s
t2: ~11s

175MHz und 4 Pipelines mit je 2 TMUs ergeben 700 MPixel und 1400 MTexel.
4000 / 1400 = 2,86
Das lässt darauf schließen dass die GF3 nur 2 bilineare Samples pro Takt erzeugen kann.

Nehme ich jetzt allerdings ows Ergebnisse:
b1: ~12s
b2: ~12s
t1: ~12s
t2: ~22s

175MHz und 2 Pipelines mit je 2 TMUs ergeben 350 MPixel und 700 MTexel.
4000 / 700 = 5,71
Das kommt jetzt aber nirgends vor! b1 sollte ~6s dauern, nicht ~11s. Es sieht eher so aus als hätte die MX eine trilineare TMU.

[ow]

Originally posted by Xmas

Nehme ich jetzt allerdings ows Ergebnisse:
b1: ~12s
b2: ~12s
t1: ~12s
t2: ~22s

175MHz und 2 Pipelines mit je 2 TMUs ergeben 350 MPixel und 700 MTexel.
4000 / 700 = 5,71
Das kommt jetzt aber nirgends vor! b1 sollte ~6s dauern, nicht ~11s. Es sieht eher so aus als hätte die MX eine trilineare TMU.



Aber mit einer trilinearen TMU kann ich doch kein single pass Multitexturing durchfuehren? Oder liesse sich dass mit 2 Taktzyklen pro Pass erreichen?


Kannst du dein Prog mal auf 16Bit umstellen (du hast gesagt es fordert 32Bit an)?

Bei 32Bit reduziert sich die Fillrate der TNT/GF2MX ohnehin auf etwas ueber 60% des 16Bit Wertes (MT wie ST).

Ich messe etwa 320/610 bei 16Bit im 3DMark und 170/330 bei 32Bit im 3DMark (Werte jetzt aus dem Gedaechtnis 'geschaetzt').


Dann stimmen die ermittelten Zeiten doch in etwa?

[Xmas]

Originally posted by ow
Aber mit einer trilinearen TMU kann ich doch kein single pass Multitexturing durchfuehren? Oder liesse sich dass mit 2 Taktzyklen pro Pass erreichen?

Loopback oder Pipeline Combining. Ist aber eh nur eine Theorie.



Kannst du dein Prog mal auf 16Bit umstellen (du hast gesagt es fordert 32Bit an)?

Bei 32Bit reduziert sich die Fillrate der TNT/GF2MX ohnehin auf etwas ueber 60% des 16Bit Wertes (MT wie ST).

Ich messe etwa 320/610 bei 16Bit im 3DMark und 170/330 bei 32Bit im 3DMark (Werte jetzt aus dem Gedaechtnis 'geschaetzt').


Dann stimmen die ermittelten Zeiten doch in etwa?
Du hast Post.

[ow]

Originally posted by Xmas

Du hast Post.


Ok, dann mach ich jetzt Feierabend und fahre nach Hause.:D

In etwa 80 min. bin ich wieder hier.

[Demirug]

Xmas,

1.Frage:

übergibts du die 2000 Quad am Stück oder eins nach dem anderen?

Edit: vergiss es. wir machen ja Fillratetest da dürfte das keine Rolle spielen

[aths]

Originally posted by Xmas
Das kommt jetzt aber nirgends vor! b1 sollte ~6s dauern, nicht ~11s. Es sieht eher so aus als hätte die MX eine trilineare TMU. Oder 2 bilineare, die kein MT können :rolleyes: Ich warte mal auf die 16-Bit-Füllrate *gespannt sei*.

ow, die 80 Minuten sind um!

[ow]

Ja, ist ja ok.

Ich hab die Staus und 8 Baustellen auf dem Heimweg nicht mitgerechnet.


Exakt identisches Ergebnis unter 16Bit, 1280.
Etwa 11-12s für b1, b2, t1 und 22-23s für t2.


Das erstaunt mich doch sehr.
In keinem Fillrate-Test liefert die MX unter 16 und 32Bit gleiche Werte.



xmas: sicher das die 16Bit Version des Progs funzt?

[aths]

Originally posted by ow
Das erstaunt mich doch sehr.
In keinem Fillrate-Test liefert die MX unter 16 und 32Bit gleiche Werte.Xmas' Tool ist soweit ich das sehe praktisch Bandbreiten-Unabhängig. Wenn ich das weiterhin richtig sehe (anhand Xmas' Füllratenrechnung für die MX) widerlegt der Test auch, dass die MX über 2 trilineare TMUs pro Pipeline verfügt.

[StefanV]

Ich hoffe, daß ich bald im Besitz einer (Chaintech) GF2 PRO sein werde, dann kann ich damit tests machen.

Mit einer GF1 DDR kann ichs leider nicht mehr, die ist letztens abgeraucht...

Hätte aber noch 'ne Savaga 4, Savage 2000, G400, und 'diverse Voodoos' anzubieten :)

Sobald ich die GF2 PRO hab, werd ich diesen Thread wieder ausgraben :)

[Demirug]

So mal wieder ein paar neue (alte) Zahlen

3dmark2000 Fillrate test

Pixel 16 Bit 292
Pixel 32 Bit 149

man könnte jetzt denken das der 50% Verlust durch das Speicherinterface kommt. Das kann aber eigentlich nicht sein, denn

Texel 16 Bit 575
Texel 32 Bit 300

Für mich sieht das eher so aus als würde die MX entweder 2*16 Bit oder einmal 32bit in den Framebuffer schreiben können

[ow]

Originally posted by Demirug

Für mich sieht das eher so aus als würde die MX entweder 2*16 Bit oder einmal 32bit in den Framebuffer schreiben können


Das betrifft dann alle Chips vom TNT bis zur GF2.

Mit dem Unterschied , dass der TNT kein MT mit trilinear kann. Die Gfs schon.


Wie sind denn jetzt da die TMUs?

[Demirug]

ow, ich hätte da schon ein paar Ideen. wobei man natürlich aber erst mal klären müsste wo der 16/32 Bit engpass genau liegt. Was mich wundert ist das man bei 16 bit die gleichen ergenisse wie bei 32 bit hat wenn man das Tool von Xmas benutzt. Bei den 3dmark2000 fillrate Tests aber die halbierung bei wechsel von 16 zu 32 bit erkennen kann.

Das wirft die Frage auf welche Art von Texturen Xmas benutzt.

[aths]

Originally posted by Demirug
So mal wieder ein paar neue (alte) Zahlen

3dmark2000 Fillrate test

Pixel 16 Bit 292
Pixel 32 Bit 149

man könnte jetzt denken das der 50% Verlust durch das Speicherinterface kommt. Das kann aber eigentlich nicht sein, denn

Texel 16 Bit 575
Texel 32 Bit 300

Für mich sieht das eher so aus als würde die MX entweder 2*16 Bit oder einmal 32bit in den Framebuffer schreiben können Wie auch immer. Im 32-Bit-Modus scheint GF2 (zumindest die MX) in der Tat ihre angebliche Füllrate prinzipiell nicht mal zu 50% ausnutzen zu können. Ich finde es schon erstaunlich, dass hier die Farbtiefe offenbar doch auf die Füllrate geht. nVidias Leistungsangaben ("Texels per Second") sind dann imo völlig irreführend, da sie nur für 16 Bit gelten.

[ow]

Ja, das ist richtig aths.


Aber hier geht es doch primär darum, welche Arten von TMUs in welchen Chips sitzen.

Und da weiss ich immer noch nicht, ob es denn Chips mit trilinearen TMUs gibt, wenn die der GF2 nur bilinear sein sollten.

[Demirug]

Trift auch bei der GF2 GTS zu. Die GF1 zeigt aber wieder ein anderes Verhalten. Dort halbiert sich beim umschalten auf 32 bit zwar die Pixelfillrate aber die Texelfillrate bleibt fast gleich. Anscheinend kommt da ein nettes NVIDIA patent in modifizierter form zum tragen. Ich will damit sagen das im 32 Bit modus aus dem 4*1 ein 2*2 chip wird (das gleiche passiert wohl auch beim MT)

[aths]

Originally posted by Demirug
Trift auch bei der GF2 GTS zu. Die GF1 zeigt aber wieder ein anderes Verhalten. Dort halbiert sich beim umschalten auf 32 bit zwar die Pixelfillrate aber die Texelfillrate bleibt fast gleich. Anscheinend kommt da ein nettes NVIDIA patent in modifizierter form zum tragen. Ich will damit sagen das im 32 Bit modus aus dem 4*1 ein 2*2 chip wird (das gleiche passiert wohl auch beim MT) Jopp, bei MT wird afaik Pipeline Combining gemacht. Was ist nun aber bei 32 Bit *und* MT? Dann müsste es Pipeline Combining mit Loop-Back sein.

[Demirug]

Ich habe meine Meinung zu der GF2 Pipeline geändert und ein neues Bild gezeichnet. Das ganze ist leider etwas kompliziert geworden.

Die Grundidee ist das die RegisterCombinder der GF2 nur in der Lage sind 16 Bit Farbwerte zu verechnen. Um mit 32 Bit farbe zu arbeiten müssen also 2 Pipelines zusammengebunden werden. Die TMUs dagegen scheinen grundsätzlich für 32 bit operationen ausgelegt zu sein und pro 16Bit Pipeline stehen davon zwei Bi TMUs zur Verfügung.

Daraus ergibt sich das man im 32 bit modus pro Pipeline 4 Bi TMUs zur Verfügung hat. Da die RegisterCombinder aber nur für 2 TMUs ausgelegt sind würden zwei TMUs ungenutzt bleiben. Das hat NVIDIA aber scheinbar nicht gefallen und deshalb hat man mit ein bischen zusätzlicher Logic (eine Linear Blend Einheit) aus jeweis 2 Bi-TMUs eine Tri-TMU gemacht. Daraus ergibt sich das man im 32 Bit Modus bei der GF2 trilienar oder 2xAF ohne Taktverlust im Verhältniss zum bilienaren Filtern bekommt. das Tri 2xAF bedeutet im 32 Bitmodus eine halbierung der Maximalen Fillrate.


bits 16 32

bi 4 2
tri 2 2
bi 2xAF 2 2
tri 2xAF 1 1

[diedl]

ich habe gerade mal 3DMark99 wieder benutzt, und dabei
entdeckt das er einen Test für Bi,tri und aniso hat.
Die Werte werden dabei in % angegeben.
Wobei Bilinear 100% entspricht.
Kann leider nur mit den Werten einer Radeon 8K5 LE dienen.
Auflösung 1280x1024 32 bit

Point Sample Texture Filtering Speed 104%
Bilinear Texture Speed 100%
Trilinear Texture Speed 83,9 %
Anisotropic Texture Speed 85,3%

1280x1024x16
Point 101,5%
Bilinear 100%
Trilinear 86,9%
Anisotropic 88%


640x480x32
point 107,5%
bilinear 100%
trilinar 73,9%
aniso 79,6%

640x480x16
point 105,1%
bilinear 100%
trilinear 75,4%
aniso 81,4


mfg diedl

[aths]

Originally posted by Demirug
das Tri 2xAF bedeutet im 32 Bitmodus eine halbierung der Maximalen Fillrate.Imo viertelt sie sich. Trilinear und 2x bi AF entsprechen (ebenso wie bilinear) in 32 Bit der halben Füllrate, und trilinear 2x AF ist noch mal nur halb so schnell. Oder meinst du mit "maximaler" Füllrate bereits die (halbierte) 32-Bit-Füllrate?

[Demirug]

Originally posted by aths
Imo viertelt sie sich. Trilinear und 2x bi AF entsprechen (ebenso wie bilinear) in 32 Bit der halben Füllrate, und trilinear 2x AF ist noch mal nur halb so schnell. Oder meinst du mit "maximaler" Füllrate bereits die (halbierte) 32-Bit-Füllrate?

Ja genauso hatte ich das gemeint. Sieht man ja in der Tabelle welche die max. Anzahl der gefilterten Texel pro Takt angibt (bei der GTS mal 2).

[aths]

Originally posted by Demirug
Ja genauso hatte ich das gemeint. Sieht man ja in der Tabelle welche die max. Anzahl der gefilterten Texel pro Takt angibt (bei der GTS mal 2). Gut, dann braucht der Artikel also nicht geändert werden, außer vielleicht bis auf die Tatsache dass GF256 wohl nur im 32-Bit-Modus trilineare TMUs hat.

edit: Ups. NV10 scheint die Texelfüllrate im 32-Bit-Modus ausnutzen zu können, aber nur wenn Multitexturing zum Einsatz kommt. Das verwirrt mich etwas. Offenbar gibts bei GF256 bei 32 Bit grundsätzlich eine 2x2-Architektur, welche jedoch ansonsten bei 32 Bit keine zusätzlichen Füllraten-Einbußen mit sich bringt.

[Demirug]

aths, wenn ich mir die NV10 zahlen so ansehe stimme ich dir zu. wobei ich mir aber noch nicht ganz sicher über den Aufbau der Pipes bin

[ow]

Hab hier mal ein paar Villagemark-Werte von der Kyro1 in 640x480x32:


bi 197
tri 116
biAF 61
TriAF 30


Irgendwelche Spekulationen zum Aufbau der TMUs?:D

[Quasar]

Dasselbe nochmal in 1024x32 für die R300.

Bi : 273 Tri : 176
2xbiAF: 174 2xtriAF: 121

Ich tippe weiterhin auf Bi-TMUs...

[aths]

Originally posted by ow
Hab hier mal ein paar Villagemark-Werte von der Kyro1 in 640x480x32:


bi 197
tri 116
biAF 61
TriAF 30


Irgendwelche Spekulationen zum Aufbau der TMUs?:D 2x1 bilinear.

[aths]

Originally posted by Quasar
Dasselbe nochmal in 1024x32 für die R300.

Bi : 273 Tri : 176
2xbiAF: 174 2xtriAF: 121

Ich tippe weiterhin auf Bi-TMUs... Xmas könnte dir ein Programm schicken, welches diese Frage entgültig klärt. (Die Zahlen legen ja jetzt schon nahe, dass es bilineare TMUs sind, aber wozu raten wenn man es auch absichern kann.)

[ow]

Originally posted by aths
2x1 bilinear.


Warum bricht die Fillrate bei aktivem AF auf ein Viertel ihres Wertes ohne AF ein (~220MTex ST/MT ohne AF, ~55Mtex mit AF)?

Und muss der Kyro sein Loopback bemühen, um trilinear zu filtern, oder kann das auch in 2 Takten ohne LB geschehen?

Auf der MX sind biAF und tri gleichschnell (jeweils 8 Texel), auf dem Kyro ist tri doppelt so schnell wie biAF, wieso das, wenn beide nur bi-TMUs haben?

[aths]

Originally posted by ow
Warum bricht die Fillrate bei aktivem AF auf ein Viertel ihres Wertes ohne AF ein (~220MTex ST/MT ohne AF, ~55Mtex mit AF)?

Und muss der Kyro sein Loopback bemühen, um trilinear zu filtern, oder kann das auch in 2 Takten ohne LB geschehen?

Auf der MX sind biAF und tri gleichschnell (jeweils 8 Texel), auf dem Kyro ist tri doppelt so schnell wie biAF, wieso das, wenn beide nur bi-TMUs haben? Ich denke mal, dass zur trilinearen Filterung internes Loopback genutzt wird. Zum AF werden offenbar 4 Takte benötigt. Warum und wieso? Dazu kann ich wirklich nix sagen, die Kyro-Architektur ist mir weitgehend unbekannt.

[ow]

Leider kommt die Kyro mit Xmas Tool nicht zurecht (oder umgekehrt:D), es gibt AFAIR nach jeweils 2-3s ein schwarzes Fenster mit seltsamen Muster am rechten Rand, egal was ich einstelle.

1xloopback fuer trilinear (2Takte) und 3xloopback fuer AF (4Takte)koennte aber gut sein.

[StefanV]

Originally posted by Stefan Payne
Sobald ich die GF2 PRO hab, werd ich diesen Thread wieder ausgraben :)

So, drohung wahr gemacht *eg*

Die GF2 PRO ist angekommen und eingebaut...