Archiv verlassen und diese Seite im Standarddesign anzeigen : AGP-Speed, Leistung, AF... (Split aus: Shaderemulation)
Original geschrieben von Quasar
Aquanox ist einer des wenigen Spiele, die wirklich von AGP8X profitieren.
Und das nicht bei hohen FSAA/AF-Leveln, sondern in erbärmlichen 640x480, selbst auf einer GF4Ti ist ein deutlicher Unterschied messbar - 188 vs. 158fps.
How come? Warum sollte ein Spiel mit hohem AF-Level mit 8x AGP irgendwie schneller laufen?? Imo ist AF vom AGP-Speed praktisch völlig unabhängig.
Quasar
2003-08-03, 10:03:42
Original geschrieben von aths
Warum sollte ein Spiel mit hohem AF-Level mit 8x AGP irgendwie schneller laufen?? Imo ist AF vom AGP-Speed praktisch völlig unabhängig.
Ich schrieb das, weil von vielen immer versucht wird, AGP-Unterschiede in absoluten Overkill-Settings zu produzieren.
Original geschrieben von Quasar
Ich schrieb das, weil von vielen immer versucht wird, AGP-Unterschiede in absoluten Overkill-Settings zu produzieren. Kann damit trotzdem wenig zu tun haben :) Es wird auch immer wieder der Fehler gemacht, Speicherbandbreite mit AF in Verbindung zu bringen (jüngst wieder auf THG gelesen.) AF kostet Füllrate, und Füllrate braucht dann wieder Speicherbandbreite, ok. Aber mehr Speicherbandbreite bringt fürs AF praktisch gar nichts, so die Karte ohne AF schon genügend Bandbreite für die Füllrate hat.
Quasar
2003-08-03, 10:20:30
Prinzipiell ja, aber das ist ein wenig OT...
Ich kann mir z.B. auch vorstellen, dass gewisse Chips af-vorgefilterte Texturen erstmal im Graka-RAM zwischenspeichern.
Original geschrieben von Quasar
Ich kann mir z.B. auch vorstellen, dass gewisse Chips af-vorgefilterte Texturen erstmal im Graka-RAM zwischenspeichern. Mir ist kein Chip bekannt, der Texturen AF-"vorfiltert" (also RIP-Mapping durchführt.)
StefanV
2003-08-03, 12:51:56
Original geschrieben von Quasar
Ich kann mir z.B. auch vorstellen, dass gewisse Chips af-vorgefilterte Texturen erstmal im Graka-RAM zwischenspeichern.
Hm, warum sollte man das machen?? :grübel:
Original geschrieben von Stefan Payne
Hm, warum sollte man das machen?? :grübel:
Um Texelfillrate zu sparen?
Original geschrieben von ow
Um Texelfillrate zu sparen? Zu welchen Kosten? Schlechtere AF-Qualität und die Beschränkung auf 90°-Winkel, sowie der hohe Texturspeicherverbrauch. Lohnt offensichtlich nicht, sonst würde es vermutlich schon gemacht. RIP-Mapping wäre imo in das gleiche Fach wie "Trilinear MIP-Map-Dithering" einzuordnen: Sehr schnell, und bessere Qualität als ganz ohne, erreicht aber nicht die Qualität der "echten" Methode.
aths:
ich habe nur den einzigen mir gerade eingefallenen Vorteil genannt.
über Nutzen und Qualität von Rip-mapping habe ich nichts gesagt.;) imo ist rip-mapping unbrauchbar zur BQ-Verbesserung.
Original geschrieben von ow
über Nutzen und Qualität von Rip-mapping habe ich nichts gesagt.;) imo ist rip-mapping unbrauchbar zur BQ-Verbesserung. Es ist besser als reines TF.
Original geschrieben von ow
ich habe nur den einzigen mir gerade eingefallenen Vorteil genannt.Was im Kontext imo :spam: war ;D :kicher:, da Quasar einen tatsächlich messbaren Effekt hinterfragt, was dann ja bedeutete, dass seine Vermutung mit AF-vorgefilterten Texturen in der Praxis umgesetzt würden, was offensichtlich nicht der Fall ist.
Bevor dieses Posting wegen Spam getrasht wird :sulkoff:, ich sehe nach wie vor keinen Zusammenhang zwischen AF-Level und AGP-Speed. Wenn AF so viel Füllrate kostet, dass die Framerate sinkt (was ja meist der Fall sein sollte) dann müsste AF eigentlich die AGP-Bandbreite senken.
Demirug
2003-08-03, 15:43:46
aths, du kannst doch nicht einfach jede Form von Brainstorming zum Spam erklären. ;)
Aber zurück zum Thema. Eine Sekunde ist eigentlich ein viel zu grosser Zeitraum um das ganze zu beobachten. Aber wir können ja jede Situation auf eine Sekunde normaliseren.
Gehen wir mal davon aus das wir Partikeleffekte rendern wollen. In der Regel braucht man dafür pro Partikel 4 Eckpunkte + 4 Indexwerte oder 6 Eckpunkte. Da die 4 Eckpunkte das bessere Verfahren sind kommen wir also auf eine Datenmenge von 4*3*4 + 4*2 = 56 Byte pro Partikel. Eine GF4TI sollte die notwendigen Transformationen in 8 Takten pro Partikel erledigen. Bei 250 MHZ könnte man also 31.25 MPartikel/s berechne. Dafür müsste man dann ca 1,63 MB/s über den AGP schaufeln. AGP 4x schafft das nicht AGP 8x dagegen schon.
Ergo: Beim Rendern von Partikeln kann AGP 4x bei einer GF4TI zur Bremse werden. Bei einer 9700 reicht eigentlich AGB 8x auch schon nicht mehr.
Quasar
2003-08-03, 15:47:05
Original geschrieben von aths
[...] da Quasar einen tatsächlich messbaren Effekt hinterfragt, was dann ja bedeutete, dass seine Vermutung mit AF-vorgefilterten Texturen in der Praxis umgesetzt würden, was offensichtlich nicht der Fall ist.
Dann will ich dir mal erklären, warum ich diese Vermutung hege.
Als Beispiel eine R9800, die über ausreichend Bandbreite verfügt.
Comanche4 in 1600 : 58 fps
1600x1200, 6xAA, 0xAF : 28fps
1600x1200, 6xAA, 16xtriAF(rTool): 12fps
1600x1200, 6xAA, 16xbiAF (rTool): 12fps
Comanche4 in 1600x1200 : 58 fps
1600x1200, 4xAA, 0xAF : 43,6
1600x1200, 4xAA, 8xBiAF (rTool) : 30
1600x1200, 4xaa, 8xTriAF (rTool): 30
1600x1200, 4xAA, 16xBiAF (rTool): 26
1600x1200, 4xAA, 16xTriAF(rTool): 26
Wie anders, außer mit dem extrem verknappenden Grafikspeicher erklärst du diese Unterschiede bzw. diese eben nicht vorhandenen Unterschiede?
Zwischen Bi-AF und Tri-AF (insbesondere, da es per rTool erzwungen wurde) sollte doch, so die Renderleistung, bzw. Texelfetchrate limitiert, ein deutlich messbarer Unterschied bestehen, insbesondere, wenn AF an sich schon zu so einem starken Einbruch führt.
Quasar, aus deiner Tabelle werde ich nicht recht schlau.
Quasar
2003-08-04, 09:21:14
Es tut mir leid, wenn ich unzureichend präzise formuliert haben sollte.
Was genau verstehst du nicht?
Original geschrieben von Quasar
Was genau verstehst du nicht? Na... alles. So eine Tabelle mit relativen Bezügen finde ich schwer zu lesen. Ich hätte lieber die fps in einer Wertetabelle als Funktion von MSAA, AF und dem AGP-Modus dargestellt.
Quasar
2003-08-04, 12:12:35
"Relative Bezüge"? Ich fürchte, ich kann nicht ganz folgen.
Der AGP-Modus (nicht "APG", wie im Topic btw) tat hier erstmal nichts zur Sache.
edit:
Ich habe die Aufzählung (keine Tabelle) mal in eine etwas andere Form gebracht, die genau dasselbe ausdrückt, wie zuvor.
Vielleicht liegt dir diese absolute Form ja mehr als die konsekutive.
edit2:
Vielleicht trägt es zum besseren Verständnis bei, wenn ich sage, daß es mir erst einmal um die Platzierung von vorgefilterten Texturen o.ä. im lokalen Grafikram geht, um daraus dann ableiten zu können (was bis hierhin aber noch nicht berücksichtigt ist), ob es evtl. möglich wäre, dass bei hohen AF-Leveln durch verknappendes lokales RAM die Nachladegeschwindigkeit durch AGP8X doch begünstigt wird, wie "einige Webseiten" es formulieren, was du so strikt ablehnst.
micki
2003-08-04, 12:28:52
Original geschrieben von Demirug
aths, du kannst doch nicht einfach jede Form von Brainstorming zum Spam erklären. ;)
Aber zurück zum Thema. Eine Sekunde ist eigentlich ein viel zu grosser Zeitraum um das ganze zu beobachten. Aber wir können ja jede Situation auf eine Sekunde normaliseren.
Gehen wir mal davon aus das wir Partikeleffekte rendern wollen. In der Regel braucht man dafür pro Partikel 4 Eckpunkte + 4 Indexwerte oder 6 Eckpunkte. Da die 4 Eckpunkte das bessere Verfahren sind kommen wir also auf eine Datenmenge von 4*3*4 + 4*2 = 56 Byte pro Partikel. Eine GF4TI sollte die notwendigen Transformationen in 8 Takten pro Partikel erledigen. Bei 250 MHZ könnte man also 31.25 MPartikel/s berechne. Dafür müsste man dann ca 1,63 MB/s über den AGP schaufeln. AGP 4x schafft das nicht AGP 8x dagegen schon.
Ergo: Beim Rendern von Partikeln kann AGP 4x bei einer GF4TI zur Bremse werden. Bei einer 9700 reicht eigentlich AGB 8x auch schon nicht mehr.
*hust* emm, wenn ich da mal was einwerfen darf.
1,63GB/s meintest du, oder?
und
indexbuffer muss doch eigentlich nicht transferiert werden, da der sich doch nicht ändern sollte, oder?
und
es wäre doch möglich pointsprites zu rendern, weil das nicht anders ausschauen sollte als deine masse an vierecken. si no?
und falls man vierecke nutzen möchte, dann eher um zumindestens eine textur darauf zu packen oder sowas, z.B. für Rauch, sonst wären quads nicht nötig.
naja, was ich damit eigentlich so sagen möchte ist, dass der wert bei "simplen" partikeln bei 12bytes/partikel liegen könnte. bei "komplexen" auch mal bei 128byte/partikel sein würde.
man könnte zwar mehrere vertexstream durchschicken, doch dann gibt es einen overhead durch den wiederum die 32MVertices/s fast halbiert werden soweit ich mal gelesen hatte.
bei 12bytes/s mit 31.25M Polys wären das 375. MB, für beide versionen von AGP noch erträglich.
bei 128byte/s mit 31.25M polys wären das 4GB und da könnte ich mir vorstellen dass das auf die gesammtframerate entscheident einfluss nimmt, ob man AGP4 oder 8 hat...
naja, flamed mich jetzt nicht zu sehr wegen dem klugscheissen :D
MfG
micki
Demirug
2003-08-04, 12:39:15
Original geschrieben von micki
*hust* emm, wenn ich da mal was einwerfen darf.
1,63GB/s meintest du, oder?
und
indexbuffer muss doch eigentlich nicht transferiert werden, da der sich doch nicht ändern sollte, oder?
und
es wäre doch möglich pointsprites zu rendern, weil das nicht anders ausschauen sollte als deine masse an vierecken. si no?
und falls man vierecke nutzen möchte, dann eher um zumindestens eine textur darauf zu packen oder sowas, z.B. für Rauch, sonst wären quads nicht nötig.
naja, was ich damit eigentlich so sagen möchte ist, dass der wert bei "simplen" partikeln bei 12bytes/partikel liegen könnte. bei "komplexen" auch mal bei 128byte/partikel sein würde.
man könnte zwar mehrere vertexstream durchschicken, doch dann gibt es einen overhead durch den wiederum die 32MVertices/s fast halbiert werden soweit ich mal gelesen hatte.
bei 12bytes/s mit 31.25M Polys wären das 375. MB, für beide versionen von AGP noch erträglich.
bei 128byte/s mit 31.25M polys wären das 4GB und da könnte ich mir vorstellen dass das auf die gesammtframerate entscheident einfluss nimmt, ob man AGP4 oder 8 hat...
naja, flamed mich jetzt nicht zu sehr wegen dem klugscheissen :D
MfG
micki
Ja klar muss GB sein.
Mit dem Indexbuffer ist das so eine Sache. Da neigen die Treiber gerne mal dazu diese im AGP-Speicher zu lassen.
Ich ging schon von einer Texture aus deswegen ja auch die Quads.
Alles in alle suchte ich ja sowieso nur noch einer Erklärung wie das beobachtete Verhalten entstanden sein könnte.
micki
2003-08-04, 12:54:16
du schriebst: 4*3*4
vertices4*
coordinates3*
sizeof(float);
wenn du für texturcoordinates noch pro vertex 8bytes dazuzählst, würde das einiges mehr werden... denk ich mir.
dazu frag ich mich: falls man die vertices mit der cpu bearbeited, dann würde man das ja mit der cpu machen, würde nicht das der limitierende faktor sein? der bus ist ja sehr viel enger als zwischen graka und mem mittels AGP und falls man nichts mit der cpu bearbeiten würde, dann müßten die daten schlauerweise :D ja im graka mem liegen.
oder?
MFG
micki
Demirug
2003-08-04, 13:02:51
Original geschrieben von micki
du schriebst: 4*3*4
vertices4*
coordinates3*
sizeof(float);
wenn du für texturcoordinates noch pro vertex 8bytes dazuzählst, würde das einiges mehr werden... denk ich mir.
dazu frag ich mich: falls man die vertices mit der cpu bearbeited, dann würde man das ja mit der cpu machen, würde nicht das der limitierende faktor sein? der bus ist ja sehr viel enger als zwischen graka und mem mittels AGP und falls man nichts mit der cpu bearbeiten würde, dann müßten die daten schlauerweise :D ja im graka mem liegen.
oder?
MFG
micki
Es war wohl einfach zu heiss als ich das Teil geschrieben habe.
Wenn ich die CPU auch eine Sekunden lang nur die Partikel aktualisieren lasse würde die da durchaus bremsen. Ich habe das ganze ja auf eine Sekunden normalisiert damit bekannte Zahlenbereiche heraus kommen.
Aber es ist ja eher so das die CPU die Partikel aktualisiert und in den AGP-Bereich schreibt und die Grafikkarte sich das ganze später mal abholt. Und genau in dem Moment würde dann der unterschied AGP 4x zu 8x zum tragen kommen. Wenn natürlich der restliche Frame auch so CPU-Lastige Effekte hat ist das alles aber sowieso egal.
Quasar
2003-08-06, 15:55:27
Original geschrieben von aths
Na... alles. So eine Tabelle mit relativen Bezügen finde ich schwer zu lesen. Ich hätte lieber die fps in einer Wertetabelle als Funktion von MSAA, AF und dem AGP-Modus dargestellt.
aths,
Hast du nun eine Erklärung anzubieten? Ich habe extra für dich die Tabelle noch einmal überarbeitet und hoffe, daß du sie nun verstehst.
Nö, eine Erklärung habe ich leider nicht anzubieten (außer natürlich, dass höhere AA-Stufen logischerweise die Geschwindigkeit senken.) Aber den Tipp, statt 0x AF lieber "1x AF" oder zur Not "No AF" oder so zu nehmen. 0x AF ist ähnlich wie 0x AA nicht sehr sinnig :)
Quasar
2003-08-06, 21:37:28
Original geschrieben von aths
Nö, eine Erklärung habe ich leider nicht anzubieten (außer natürlich, dass höhere AA-Stufen logischerweise die Geschwindigkeit senken.) Aber den Tipp, statt 0x AF lieber "1x AF" oder zur Not "No AF" oder so zu nehmen. 0x AF ist ähnlich wie 0x AA nicht sehr sinnig :)
Die AA-Stufe ist in beiden Fällen gleich geblieben, kann also auf die AF-Benchmarks keine Auswirkung gehabt haben.
Da du ausser Bemerkungen über die Sinnhaftigkeit von 0xAF und 0xAA* keine Erklärung anzubieten hast, würde es mich interessieren, ob du weiterhin an: [...] da Quasar einen tatsächlich messbaren Effekt hinterfragt, was dann ja bedeutete, dass seine Vermutung mit AF-vorgefilterten Texturen in der Praxis umgesetzt würden, was offensichtlich nicht der Fall ist.
in der Form festhalten willst.
Morgen werde ich mal schauen, wie sich eine 64MB-R300 und eine GeForceFX dahingehend verhalten. IIRC fängt erstere schon viel früher und heftiger an, mit den FPS in den Keller zu gehen und letztere bewältigt die Anforderungen wesentlich gleichmäßiger.
* Womit du auch noch vollkommen unrecht hast, da "0xAA" ausgesprochen Nullfache Aliasing-Gegenmaßnahmen, also eben _kein_ Anti-Aliasing bedeuten.
Original geschrieben von Quasar
* Womit du auch noch vollkommen unrecht hast, da "0xAA" ausgesprochen Nullfache Aliasing-Gegenmaßnahmen, also eben _kein_ Anti-Aliasing bedeuten. Die AA-Stufe gibt an, wieviele Samples pro Pixel verarbeitet werden. Kein AA heißt, 1 Sample pro Pixel. Ganz ähnlich ists bei AF. Man spricht ja auch analog nicht von 0x Vergrößerung, wenn eine Optik nicht vergrößert. "0x AA" enstand, in dem "No" bzw. "Kein" mit "0" 'übersetzt' wurde. Allerdings heißt es ja nicht "No times AA" oder "Keinfach AA", sondern "No AA". Durch das "x" ändert sich der Bezug, so dass "0" nicht mehr hinhaut.
Original geschrieben von Quasar
in der Form festhalten willst.Aber natürlich. Ich glaube nicht, dass RIP-Mapping eingesetzt wird. Zumal der Verbrauch an Textur-Speicher dann gigantisch würde.
Quasar
2003-08-06, 22:19:27
Original geschrieben von aths
Die AA-Stufe gibt an, wieviele Samples pro Pixel verarbeitet werden. Kein AA heißt, 1 Sample pro Pixel. Ganz ähnlich ists bei AF.
Das magst du so verstehen, aber es gibt noch andere Meinungen neben deiner. Aber wir kommen vom Thema ab, und das wollen wir doch nicht, oder?
Original geschrieben von aths
Aber natürlich. Ich glaube nicht, dass RIP-Mapping eingesetzt wird. Zumal der Verbrauch an Textur-Speicher dann gigantisch würde.
Ok, du glaubst also nicht an Rip-Mapping. Wie, wenn nicht mit ständigem Nachladen über den AGP, welches, wie ich stark annehme, auch die FPS einbrechen liesse, erklärst du dann den absolut uncharakteristisch starken Einbruch einer R9800, die sich selbst in reinen Füllratentests von 16xTriAF nicht so ausbremsen läßt, bei beschriebenen Settings?
Oder glaubst du rein aus Prinzip nicht, dass die Radeon Rip-Mapping betreibt?
Original geschrieben von Quasar
Das magst du so verstehen, aber es gibt noch andere Meinungen neben deiner. Aber wir kommen vom Thema ab, und das wollen wir doch nicht, oder?Ich habe eine hoffentlich logische Begründung angegeben, warum man "No AA" imo nicht mit "0x AA" bezeichnen sollte.
Original geschrieben von Quasar
Ok, du glaubst also nicht an Rip-Mapping. Wie, wenn nicht mit ständigem Nachladen über den AGP, welches, wie ich stark annehme, auch die FPS einbrechen liesse, erklärst du dann den absolut uncharakteristisch starken Einbruch einer R9800, die sich selbst in reinen Füllratentests von 16xTriAF nicht so ausbremsen läßt, bei beschriebenen Settings?
Oder glaubst du rein aus Prinzip nicht, dass die Radeon Rip-Mapping betreibt? Warum soll ich immer alles vorkauen? ATI hat mal in einem Chat gesagt (zu R200-Zeiten) dass die Radeon "richtiges" AF machen würde und kein RIP-Mapping. Wenn wir das mal etwas weiter denken: RIP-Mapping hat wegen der vorgefilterten Texturen natürlich nicht die volle AF-Qualität. Im direkten Vergleich fällt dort, wo AF in vollem Maße appliziert wird, gegenüber GeForce aber kein Qualitätsnachteil auf. Und um 45°-Winkel ebenfalls mit AF zu versorgen, reicht normales RIP-Mapping ohnehin nicht aus.
Original geschrieben von aths
Aber natürlich. Ich glaube nicht, dass RIP-Mapping eingesetzt wird. Zumal der Verbrauch an Textur-Speicher dann gigantisch würde.
Etwa das dreifache.
Original geschrieben von Quasar
Wie anders, außer mit dem extrem verknappenden Grafikspeicher erklärst du diese Unterschiede bzw. diese eben nicht vorhandenen Unterschiede?
Zwischen Bi-AF und Tri-AF (insbesondere, da es per rTool erzwungen wurde) sollte doch, so die Renderleistung, bzw. Texelfetchrate limitiert, ein deutlich messbarer Unterschied bestehen, insbesondere, wenn AF an sich schon zu so einem starken Einbruch führt.
Überlege doch mal, wo es denn überhaupt einen Unterschied zwischen Bilinear und Trilinear gibt, und wie du darauf durch hohe Auflösung und AF Einfluss nimmst ;)
Quasar
2003-08-07, 14:01:55
@aths:
Ja, du hast eine Begründung genannt, die aber nicht allgemeiner Konsens ist. Trotzdem versuchst du, alle, die sich nicht deiner Meinung anschliessen, als "die Unerleuchteten" hinzustellen, die anscheinend nichtmal die einfachsten Angaben hinterfragen.
Wie du gesehen hast, habe ich eine ebenso logische Begründung erbracht, warum man "0xAA" (i.e. keine Aliasing-Gegenmaßnahmen, wo wir nämlich mal auf die Bedeutung von "AA" kommen, die du aber nicht sehen willst) genausogut und genausorichtig verwenden kann.
Wenn du weiter darüber diskutieren willst, mache bitte einen eigenen Thread dafür auf und ziehe diesen nicht komplett ins OT. Danke.
Zum On-Topic-Teil deines Postings:
Ok, du verläßt dich also auf die völlig unvoreingenommenen Aussagen der ATi-Mitarbeite.... Dein gutes Recht.
@Xmas:
"Etwa das dreifache."
--> Würde ja gut ins Bild passen.
²Überlege doch mal, wo es denn überhaupt einen Unterschied zwischen Bilinear und Trilinear gibt, und wie du darauf durch hohe Auflösung und AF Einfluss nimmst"
Füllrate, richtig?
Original geschrieben von Quasar
²Überlege doch mal, wo es denn überhaupt einen Unterschied zwischen Bilinear und Trilinear gibt, und wie du darauf durch hohe Auflösung und AF Einfluss nimmst"
Füllrate, richtig?
Ich meinte tatsächlich "wo im Bild". Dir fällt doch sicher auch auf, dass der eingefärbte Bereich im AF-Tester bei hohem AF immer kleiner wird, oder?
Quasar
2003-08-07, 19:06:23
Ach so, "weit hinten" meinst du....
Original geschrieben von Quasar
Ach so, "weit hinten" meinst du....
Ja, womit bei immer weniger Pixeln der Unterschied zwischen Bilinear und Trilinear überhaupt existiert.
Original geschrieben von Quasar
@aths:
Ja, du hast eine Begründung genannt, die aber nicht allgemeiner Konsens ist. Trotzdem versuchst du, alle, die sich nicht deiner Meinung anschliessen, als "die Unerleuchteten" hinzustellen, die anscheinend nichtmal die einfachsten Angaben hinterfragen.
Wie du gesehen hast, habe ich eine ebenso logische Begründung erbracht, warum man "0xAA" (i.e. keine Aliasing-Gegenmaßnahmen, wo wir nämlich mal auf die Bedeutung von "AA" kommen, die du aber nicht sehen willst) genausogut und genausorichtig verwenden kann.
Wenn du weiter darüber diskutieren willst, mache bitte einen eigenen Thread dafür auf und ziehe diesen nicht komplett ins OT. Danke.Das _ist_ mein eigener Thread :D *Streit such* Wie schon gesagt, wenn du "Keine Maßnahmen" mit "0" umschreiben willst, wäre das "x" deplaziert. Berücksichtigt man die Entwicklung mit höheren Zahlen vor dem x, und will zu "Kein" zurück rechnen, gelangt man zur 1. Wenn du das wirklich nicht parallel diskutieren möchtest, mache ich dazu noch einen extra-Thread auf...
Original geschrieben von Quasar
Zum On-Topic-Teil deines Postings:
Ok, du verläßt dich also auf die völlig unvoreingenommenen Aussagen der ATi-Mitarbeite.... Dein gutes Recht.Ich denke mir, dass ein ATI-Mitarbeiter, der sich zum AF-Verfahren äußert, mehr über den R200-Chip weiß, als, sorry, du (oder, sorry, ich.)
Original geschrieben von Quasar
@Xmas:
"Etwa das dreifache."
--> Würde ja gut ins Bild passen.Xmas' Angabe bezieht sich auf das bekannte RIP-Mapping, welches nur 90°-Winkel filtert. R300 filtert auch 45° maximal mit vollem Level. Außerdem habe ich doch geschrieben, dass sich RIP-Mapping nachweisen ließe, weil die Filterqualität auch bei 90° nicht so gut wie beim echten AF ist.
Und ich weiß nicht mehr, ob die Idee von zeckensack, nggalai oder von wem kam, RIP-Mapping hat weiterhin den Nachteil, um 45° gedrehte Texturen, die aber flach "im 90°-Winkel" zu sehen sind, nicht mit AF versorgen zu können. Das kann aber schon der R200.
Quasar
2003-08-07, 19:56:24
Original geschrieben von aths
Ich denke mir, dass ein ATI-Mitarbeiter mehr über den R200-Chip weiß, als, sorry, du (oder, sorry, ich.)
Das bezweifle ich nicht. Nur wird er bereit sein,umfangreich sein Wissen zu teilen? Das hingegen bezweifle ich aufs äußerste...
Original geschrieben von aths
Xmas' Angabe bezieht sich auf das bekannte RIP-Mapping, welches nur 90°-Winkel filtert. R300 filtert auch 45° maximal mit vollem Level. Außerdem habe ich doch geschrieben, dass sich RIP-Mapping nachweisen ließe, weil die Filterqualität auch beo 90° nicht so gut wie beim echten AF ist.
Und ich weiß nicht mehr, ob die Idee von zeckensack, nggalai oder von wem kam, RIP-Mapping hat weiterhin den Nachteil, um 45° gedrehte Texturen, die aber flach "im 90°-Winkel" zu sehen sind, nicht mit AF versorgen zu können. Das kann aber schon der R200.
Nur zur Erinnerung, den Begriff des RIP-Mapping hast du ins Spiel gebracht, ich sprach lediglich von anisotrop-vorgefilterten Texturen, die der R300 evtl. im lokalem RAM ablegt.
Nichtsdestoweniger sind ja durchaus auch Mischformen vorstellbar und zur Qualität: schau dir mal Leos Screenshots auf der R300/R350 in UT2003 an. Wer weiß, vielleicht hat ATi ja etwas hübsches neues da erfunden...
@Xmas:
C4 hat eine enorme Sichweite... und auch sonst lassen sich deutliche Unterschiede zwischen Bi- und Trilinearem AF nachweisen, deswegen sehe ich nicht so ganz die Relevanz, weswegen die relativ geringe Zahl von 16fach anisotrop behandelten Pixeln hier stärker wiegen sollte, als gewöhnlich.
Original geschrieben von Quasar
Nur zur Erinnerung, den Begriff des RIP-Mapping hast du ins Spiel gebracht, ich sprach lediglich von anisotrop-vorgefilterten Texturen, die der R300 evtl. im lokalem RAM ablegt.
Das kommt aber auf dasselbe raus, ob man es nun RIP-Mapping nennt oder nicht.
Nichtsdestoweniger sind ja durchaus auch Mischformen vorstellbar und zur Qualität: schau dir mal Leos Screenshots auf der R300/R350 in UT2003 an. Wer weiß, vielleicht hat ATi ja etwas hübsches neues da erfunden...
Zumindest im AF-Tester würde man auch Mischformen erkennen, da die Texturrotation nicht hundertprozentig "stufenfrei" wäre.
@Xmas:
C4 hat eine enorme Sichweite... und auch sonst lassen sich deutliche Unterschiede zwischen Bi- und Trilinearem AF nachweisen, deswegen sehe ich nicht so ganz die Relevanz, weswegen die relativ geringe Zahl von 16fach anisotrop behandelten Pixeln hier stärker wiegen sollte, als gewöhnlich.
Nichtsdestotrotz reduzieren AF und eine hohe Auflösung den Unterschied zwischen Bilinear und Trilinear ganz gewaltig. Denn dann kommt häufig nur der erste Mip-Level zum Einsatz, es wird also gar nicht trilinear gefiltert.
Im übrigen gibt es noch einen weiteren möglichen Grund, dass trilineares AF in einigen Fällen bei ATI kaum mehr Leistung braucht als bilineares. Nämlich dass nicht (nur) trilineare Samples genommen werden, sondern unabhängige bilineare aus zwei verschiedenen Mip-Leveln.
Quasar
2003-08-07, 20:56:25
Original geschrieben von Xmas
Das kommt aber auf dasselbe raus, ob man es nun RIP-Mapping nennt oder nicht.[/SIZE]
Naja, was wenn einige (vielleicht die paar zuletzt gefilterten) Texturen, die zuvor korrekt gefiltert wurden (im Rahmen der Hardware) zwischenspeicher und bei Bedarf und wenn der Winkel stimmt, direkt wieder darauf zugreifen kann?
Original geschrieben von Xmas
Zumindest im AF-Tester würde man auch Mischformen erkennen, da die Texturrotation nicht hundertprozentig "stufenfrei" wäre.
[/SIZE]
Ist sie doch nicht... oder was genau meinst du mit stufenfrei?
Original geschrieben von Xmas
Nichtsdestotrotz reduzieren AF und eine hohe Auflösung den Unterschied zwischen Bilinear und Trilinear ganz gewaltig. Denn dann kommt häufig nur der erste Mip-Level zum Einsatz, es wird also gar nicht trilinear gefiltert.
Im übrigen gibt es noch einen weiteren möglichen Grund, dass trilineares AF in einigen Fällen bei ATI kaum mehr Leistung braucht als bilineares. Nämlich dass nicht (nur) trilineare Samples genommen werden, sondern unabhängige bilineare aus zwei verschiedenen Mip-Leveln. [/SIZE]
Im Villagemark macht der Unterschied mehr als 25% aus (43 zu 54fps), im Templemark 144,3 zu 130,3.
Original geschrieben von Quasar
Naja, was wenn einige (vielleicht die paar zuletzt gefilterten) Texturen, die zuvor korrekt gefiltert wurden (im Rahmen der Hardware) zwischenspeicher und bei Bedarf und wenn der Winkel stimmt, direkt wieder darauf zugreifen kann?Wie soll das gehen? Mit Render to Texture eine AF-vorgefilterte Textur zwischenspeichern? Wie soll diese vorgefilterte Textur appliziert werden? Mit Point Sampling oder noch mal bilinear nachgefiltert? Es genügen schon kleine Abweichungen im Verzerrungs-Grad, bzw. Verschiebungen des Polygons um Pixelbruchteile, um die vorgefilterten Daten praktisch wertlos werden zu lassen, weil sie zu ungenau sind. Man müsste dann in Bewegung Frameweise ein tolles AF-Ergebnis sehen, welches in den nächsten Frames deutlich schlechter sein würde.
Quasar
2003-08-07, 21:17:58
Wenn ich wüßte, wie das gehen soll, würde ich für viel Geld bei einem GPU-Hersteller als Designer arbeiten, schätze ich.
Ich halte also mal fest, daß du auch keine handfesten Fakten hast, um deine These zu stützen, oder?
Original geschrieben von Quasar
Wenn ich wüßte, wie das gehen soll, würde ich für viel Geld bei einem GPU-Hersteller als Designer arbeiten, schätze ich.
Ich halte also mal fest, daß du auch keine handfesten Fakten hast, um deine These zu stützen, oder? Antwort kommt per PM.
Original geschrieben von Quasar
Naja, was wenn einige (vielleicht die paar zuletzt gefilterten) Texturen, die zuvor korrekt gefiltert wurden (im Rahmen der Hardware) zwischenspeicher und bei Bedarf und wenn der Winkel stimmt, direkt wieder darauf zugreifen kann?
Es werden keine Texturen gefiltert, sondern Texel. Und das in jedem Frame mit anderen Gewichtungen. Zwischenspeichern macht dann Sinn wenn man das Ergebnis einer bestimmten Berechnung immer wieder braucht. Das ist hier nicht der Fall.
Ist sie doch nicht... oder was genau meinst du mit stufenfrei?
Ich meine die Texturrotation, und wie sich dabei die Mipmap-Grenzen verhalten.
Im Villagemark macht der Unterschied mehr als 25% aus (43 zu 54fps), im Templemark 144,3 zu 130,3.
Es kommt sehr stark auf die verwendeten Texturen/Texturkoordinaten an.
Quasar
2003-08-07, 21:58:22
originally received from aths via PN
.
Text der PN auf Wunsch von aths, der nicht mit der "Veröffentlichung" seiner privaten Nachricht einverstanden war, unter Protest gelöscht.
Sorry, aber wenn du so gestresst bist, solltest du mal eine Pause einlegen, anstatt immer zu versuchen, deine Ansicht durchzuboxen, auch wenn es eben "nur" deine Ansicht ist, die nicht belegt ist.
Ist es so schwer für dich, mal zu schreiben "Dies und das ist meine Meinung nach so", anstatt "Dies und das ist so. Punkt."?
Ich fragte nach einem extremem Einbruch bei 16xAF der sich so in keinem synthethischen Tester reproduzieren lässt und der komischerweise nicht durch Senken des AF-Anspruches auf bilineares AF beheben läßt.
Solange es da nicht zu etwas mehr als Spekulationen kommt, ist für mich jede Theorie so gut wie jede andere, denn im Gegensatz zu dir schliesse ich andere Theorien nicht kategorisch und a priori aus.
Im Gegensatz zu...naja lassen wir das. Jedenfalls bin ich durchaus in der Lage, einzusehen, wenn ich mich, wie du es formulierst, vergaloppiert habe. Allerdings nicht, oder nur selten auf der Grundlage, wenn jemand anderes versucht, mir seine Ansicht als absolute Wahrheit zu verkaufen.
²Warum AF die erforderliche AGP-Bandbreite nicht erhöhen sollte, sondern wenn überhaupt, dann senken, wurde dargelegt. Warum nimmst du nicht mal darauf bezug sondern reitest nur auf deiner Tabelle herum? "
-->> Mal davon abgesehen, daß ich das niemals behauptet habe (siehe Anfang des Threads), sondern du mir das offenbar in den Mund legen wolltest, habe ich dazu eine mögliche Erklärung gegeben, die bei dir offenbar auf wenig Gegenliebe gestossen ist. Nun gut, sei's drum.
Eine neue Theorie habe ich im Übrigen auch, sogar deren zwei:
Ich habe nochmals nachgetestet und dabei kamen mir folgende Gedanken:
a) Pixelshader-Wasser wird durch AF, IIRC, nicht besonders behandelt, da dort nicht unbedingt eine Textur gefiltert werden muss, oder? Große Teile des C4-Benches bestehen aus einer Aussicht auf eine weite Wasserfläche, zusammen mit Xmas' Theorie würde das evtl. einen nicht vorhandenen Einbruch erklären können.
b) Die nicht vorhandene Unterscheidung aus Leistungssicht zwischen bilinearem und trilinearem AF bei C4 zieht sich auch ohne FSAA durch alle Auflösungen hin. Und dass selbst in 640x480 der lokale RAM zu gering sein sollte, um alle Texturen, seien sie nun vorgefiltert oder nicht, aufzunehmen, kann ich beim besten Willen auch nicht glauben.
Danke, Quasar. Es ist afaik allgemein üblich, vor der Veröffentlichung einer PM nach dem Einverständnis zu fragen.
Wenn ich das richtig verstanden habe, wird bei generell erzwungendem AF auch eine für PS verwendete Textur A gefiltert. (Demirug bestätigt es gerade :))
Warum bencht du nicht auch mit 1x, 2x, 4x AF, um die Entwicklung besser verfolgen zu können?
Quasar
2003-08-07, 22:46:57
Unter Protest lösche ich den Text!!
Weitere PMs von dir, die mit Themen zu tun haben, die man genausogut in den für alle zugänglichen Threads erörtern kann, werde ich ignorieren.
Ich weiß zwar nicht, warum du deinen Text nicht öffentlich vertreten kannst oder willst, aber wenn du mir etwas zu sagen hast was mit dem Thema zu tun hat, tue das bitte hier im Thread. Danke.
Aquaschaf
2003-08-07, 23:02:01
Das ging doch jetzt sicher nicht darum, dass die PM keiner sehen sollte, sondern eher ums Prinzip ;)
Demirug
2003-08-07, 23:03:11
Ganz dumme Frage. Mipmaps haben die Texturen aber schon und man erkennt einen optischen unterschied zwischen bi und tri? Diesen Effekt das es zwischen bi und tri keinen unterschied gibt kenne ich eigentlich nur wenn man keine Mipmaps hat.
Original geschrieben von Demirug
Ganz dumme Frage. Mipmaps haben die Texturen aber schon und man erkennt einen optischen unterschied zwischen bi und tri? Diesen Effekt das es zwischen bi und tri keinen unterschied gibt kenne ich eigentlich nur wenn man keine Mipmaps hat. Bei hohen AF-Stufen werden "vorne" praktisch keine MIP-Maps verwendet :) (Oder habe ich dich jetzt falsch verstanden?)
Demirug
2003-08-08, 00:18:22
Original geschrieben von aths
Bei hohen AF-Stufen werden "vorne" praktisch keine MIP-Maps verwendet :) (Oder habe ich dich jetzt falsch verstanden?)
Ja scheinbar. Ich meinte ob die verwendeten Texturen überhaupt mit Mipmaps in die Grafikkarte geladen wurden oder ob es da am Ende nur die Basistexture gibt.
Quasar
2003-08-08, 00:33:53
Das wäre schonmal eine einleuchtende Erklärung. Leider ist der Bewegungsablauf im Benchmark recht hektisch und eine absolut identische und geeignete Screenshot-Position läßt sich kaum erreichen.
Original geschrieben von Demirug
Ja scheinbar. Ich meinte ob die verwendeten Texturen überhaupt mit Mipmaps in die Grafikkarte geladen wurden oder ob es da am Ende nur die Basistexture gibt. Woher soll ich das wissen :kicher: ich habe das Spiel nicht...
Demirug
2003-08-08, 07:20:04
Original geschrieben von aths
Woher soll ich das wissen :kicher: ich habe das Spiel nicht...
Das war ja auch eine Frage an die Allgemeinheit.
zeckensack
2003-08-08, 12:58:46
Original geschrieben von aths
Bei hohen AF-Stufen werden "vorne" praktisch keine MIP-Maps verwendet :) (Oder habe ich dich jetzt falsch verstanden?) Auch.
Aber: wenn keine Mipmaps geladen werden, sondern nur eine Basistextur, dann gibt es nie einen Unterschied zwischen Bilinear und Trilinear.
(das erfordert unter GL ein 'LOD-Clamp' auf Stufe 0, ansonsten wird die Textur nicht appliziert => alles ist weiß; kA bzgl D3D)
Autoritätsargument (http://home.t-online.de/home/zsack/glide_wrapper/readme.htm#usage):
Up one notch on the quality scale, and we get to "force trilinear", which can eliminate banding artifacts. It won't force mipmapping though, ie if an application only supplies base textures and not the complete mipmap sets, trilinear filtering won't make any difference whatsoever.
Aber eine Sache an der Theorie ist faul:
Hat man kein Mipmapping, dann bekommt man starkes shimmering. Das sollte aufgefallen sein, deswegen glaube ich es nicht.
Demirug
2003-08-08, 13:52:06
Original geschrieben von zeckensack
Auch.
Aber: wenn keine Mipmaps geladen werden, sondern nur eine Basistextur, dann gibt es nie einen Unterschied zwischen Bilinear und Trilinear.
(das erfordert unter GL ein 'LOD-Clamp' auf Stufe 0, ansonsten wird die Textur nicht appliziert => alles ist weiß; kA bzgl D3D)
D3D ist da Pflegeleicht. Einen Textur kennt die Anzahl der Mipmaps die sie hat und sorgt aleine dafür das da nix verkehrt läuft.
Aber eine Sache an der Theorie ist faul:
Hat man kein Mipmapping, dann bekommt man starkes shimmering. Das sollte aufgefallen sein, deswegen glaube ich es nicht.
Ja ich weiss aber das ist das einzige womit ich mir auf die schnelle dieses verhalten erklären kann.
Quasar
2003-08-08, 14:12:15
Comanche4 zeigt bis auf das Pixelshader-Wasser kein Shimmering. Im Gegenteil, die Texturen sehen sogar "natürlicher" aus, als bei den meisten anderen Games.
MadManniMan
2003-08-08, 14:56:21
Höchstinteressant das alles. Aus technischer, wie aus zwischenmenschlicher Sicht. Höchstinteressant ?-)
StefanV
2003-08-08, 15:05:24
Original geschrieben von Quasar
Unter Protest lösche ich den Text!!
Weitere PMs von dir, die mit Themen zu tun haben, die man genausogut in den für alle zugänglichen Threads erörtern kann, werde ich ignorieren.
Ich weiß zwar nicht, warum du deinen Text nicht öffentlich vertreten kannst oder willst, aber wenn du mir etwas zu sagen hast was mit dem Thema zu tun hat, tue das bitte hier im Thread. Danke.
Quasar, mal ein Vergleich:
Wie würdest du reagieren bzw wie würde es dir gefallen, wenn du jemanden etwas vertraulich mitteils (was ja PM mehr oder minder ist), dein gegenüber das aber lauthals ausplaudert, ohne dich vorher gefragt zu haben??
siehe auch hier:
Original geschrieben von aths
Es ist afaik allgemein üblich, vor der Veröffentlichung einer PM nach dem Einverständnis zu fragen.
Entprechende Teile markiert...
Ergo:
Es stört aths, daß du eine PM von ihm veröffentlich hast, ohne vorher zu fragen...
PS: ich hab noch nie Logs aus ICQ Chats mit diversen 'Bekannten' gepostet, hab auch niemals die entsprechenden Namen der ICQ/Forums Teilnehmer genannt...
Außer einmal, da hab ich aber Gohan vorher gefragt, ob ich seinen Namen verwenden darf (sonst hätte ich nur 'ein bekannter ausm ICQ konnte es nachvollziehen' o.Ä. geschrieben)...
BlueI
2003-08-08, 15:10:51
Könnte mal bitte einer von den anwesenden Mods das Thema korrigieren? APG-Speed sieht einfach :krank: aus.
Bitte! :massa:
zeckensack
2003-08-08, 15:35:06
Aber gern :o
Quasar
2003-08-08, 17:28:26
Original geschrieben von Stefan Payne
Quasar, mal ein Vergleich:
Wie würdest du reagieren bzw wie würde es dir gefallen, wenn du jemanden etwas vertraulich mitteils (was ja PM mehr oder minder ist), dein gegenüber das aber lauthals ausplaudert, ohne dich vorher gefragt zu haben??
siehe auch hier:
Entprechende Teile markiert...
Ergo:
Es stört aths, daß du eine PM von ihm veröffentlich hast, ohne vorher zu fragen...
PS: ich hab noch nie Logs aus ICQ Chats mit diversen 'Bekannten' gepostet, hab auch niemals die entsprechenden Namen der ICQ/Forums Teilnehmer genannt...
Außer einmal, da hab ich aber Gohan vorher gefragt, ob ich seinen Namen verwenden darf (sonst hätte ich nur 'ein bekannter ausm ICQ konnte es nachvollziehen' o.Ä. geschrieben)...
OT (und könnte gern hiermit beendet oder ausgelagert werden!):
Stefan Payne,
Ich bin mir dessen sehr wohl bewusst.
Wenn die Mitteilung etwas wirklich privates enthalten hätte, hätte ich sie selbstverständlich nicht hier gepostet.
Der Text bezog sich rein auf diesen Thread und es war keine Aussage darin, die nicht genausogut hier veröffentlich sein könnte.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.