PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Borstis Optimierungsartikel auf THG


Demirug
2004-06-04, 07:28:16
Original geschrieben von deekey777
Borsti hat seine Drohungen wahr gemacht und einen Artikel (http://www.tomshardware.com/graphic/20040603/index.html) veröffentlicht.

Da hat sich aber ein paar kleiner Fehler eingeschlichen:

You have to remember that with colored mipmaps, there are still some places that are not colored. ATI driver still optimizes those textures. This means that the delta between full filtering and optimized filtering of the X800 must be even greater than the results with colored mipmaps show.

Das stimmt so natürlich nicht. Die ungefärbten Mipmaps sind die Basislevel. Die optimierung wird aber immer für alle Levels einer Textur an oder ausgeschaltet und nicht auf Mipmap-Basis. Das Ergebniss mit gefärbten Mipmaps entspricht daher dem Ergebniss ohne Optimierung.

Several reviewers have disabled the trilinear optimization in NVIDIA's GeForce 6800, as suggested by ATI. In our X800 test NVIDIA's trilinear optimization was not disabled, so the comparable values continue to be valid and comparable.

Wenn ATI nicht noch zusätzlich am MIPMAP-LOD geschraubt hätte würde das stimmen so aber leider nicht.

It is also still unclear how far ATi's optimization goes, i.e. which is the smallest filter level and whether the optimization is limited to mipmap filtering or if there's much more going on.

Das wurde doch schon geklärt. Es sind alle Mipmaps einer Textur betroffen und der X800 hat zusätzlich noch eine Optimierung über den LOD-BIAS.

So genug kritisiert.

Steel
2004-06-04, 13:05:18
http://www.tomshardware.com/graphic/20040603/index.html

Grandioser Artikel zum Thema....

DrumDub
2004-06-04, 13:19:55
wird schon hier diskutiert: http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&postid=1876081#post1876081

Borsti
2004-06-04, 13:58:56
Original geschrieben von Demirug
Da hat sich aber ein paar kleiner Fehler eingeschlichen:



Das stimmt so natürlich nicht. Die ungefärbten Mipmaps sind die Basislevel. Die optimierung wird aber immer für alle Levels einer Textur an oder ausgeschaltet und nicht auf Mipmap-Basis. Das Ergebniss mit gefärbten Mipmaps entspricht daher dem Ergebniss ohne Optimierung.



Wenn ATI nicht noch zusätzlich am MIPMAP-LOD geschraubt hätte würde das stimmen so aber leider nicht.



Das wurde doch schon geklärt. Es sind alle Mipmaps einer Textur betroffen und der X800 hat zusätzlich noch eine Optimierung über den LOD-BIAS.

So genug kritisiert.

Es werden also alle Texturen bei eingefärbten Mipmaps vom Treiber in die gleiche Class eingeordnet? Ich mach da nochmal nen Screenshot und schaue wie das Band zwischen der Textur und der ersten eingefärbten Mipmap aussieht... aber auf der anderen Seite wäre das dann schon früher entdeckt worden.

Die Sache mit dem LOD change kam etwas zu spät für den Artikel und ginge dann auch etwas tiefer. Das hätte ich bei den anderen Optimierungen dann auch machen müssen. Ich wollte die Sache aber absichtlich Basic halten.

Was den letzten Punkt angeht, denke ich weniger an die Trilineare Optimierung. Es gäbe da ja noch ganz andere Sachen, die man über "adaptivität" machen könnte. Adaptive Z-Buffer Tiefe, adaptives AA und was weiss ich. Es spielt eher darauf an, das diese Sache erst die Spitze des Eisbergs sein _könnte_.

Ich werde ATI jedenfalls demnächst fragen, ob noch weitere adaptive Optimierungen im Treiber sind, über die sie aus Patent-Pending Gründen nicht sprechen können ;)

Lars - THG

Exxtreme
2004-06-04, 14:07:45
Original geschrieben von Borsti
Es gäbe da ja noch ganz andere Sachen, die man über "adaptivität" machen könnte. Adaptive Z-Buffer Tiefe, adaptives AA und was weiss ich. Es spielt eher darauf an, das diese Sache erst die Spitze des Eisbergs sein _könnte_.

Naja, beim adaptiven AA stimme ich zu. Aber bei adaptiver Z-Buffer-Tiefe... ich weiss nicht. Ich glaube nicht, daß das viel spart. Und ausserdem dürfte der Check, ob eine reduzierte Z-Buffer-Tiefe reicht oder nicht, viel mehr Zeit kosten als gleich mit voller Z-Buffer-Tiefe zu rechnen. Und die heutigen Chips haben eh' eine Z-Buffer-Kompression. Ich bezweifle stark ob das was bringt.

Demirug
2004-06-04, 14:17:06
Original geschrieben von Borsti
Es werden also alle Texturen bei eingefärbten Mipmaps vom Treiber in die gleiche Class eingeordnet? Ich mach da nochmal nen Screenshot und schaue wie das Band zwischen der Textur und der ersten eingefärbten Mipmap aussieht... aber auf der anderen Seite wäre das dann schon früher entdeckt worden.

Ich meinte das anders. Sobald man eine Mipmap einer Textur so färbt das sie die Schwelle überschreitet wird ganze Textur mit allen Mipmaps nicht mehr optimiert.

Was man beim einfärben noch zu sehen bekommt ist die grösste Mipmap weil diese nicht angetastet wird.

Daher ist die Optimierung komplett deaktiviert wenn man mit gefärbten Mipmaps arbeitet auch wenn nicht alle Mipmaps einer textur gefärbt sind.

Was den letzten Punkt angeht, denke ich weniger an die Trilineare Optimierung. Es gäbe da ja noch ganz andere Sachen, die man über "adaptivität" machen könnte. Adaptive Z-Buffer Tiefe, adaptives AA und was weiss ich. Es spielt eher darauf an, das diese Sache erst die Spitze des Eisbergs sein _könnte_.

Sicherlich wobei es ja durchaus auch legale Optimierungen gibt. Die adaptive Sampleanzahl beim AF gehört in diesen Bereich weil der Pixel in diesen Bereichen ja gar nicht genügend Texturfläche abdeckt um die maximale anzahl von Samples zu erreichen.

Aus diesem Grund gibt man ja auch die maximale Anzahl von Samples pro Pixel an und nicht die absolute wenn man das AF aktiviert. Eigentlich müsste man das mit der adativen Sampleanzahl gar nicht extra herausstellen weil es zum AF dazu gehört.

Ich werde ATI jedenfalls demnächst fragen, ob noch weitere adaptive Optimierungen im Treiber sind, über die sie aus Patent-Pending Gründen nicht sprechen können ;)

Lars - THG

deekey777
2004-06-04, 14:17:24
Original geschrieben von DrumDub
wird schon hier diskutiert: http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&postid=1876081#post1876081

Die Diskussion sollte in diesen Thread verschoben werden, da der andere Thread ja Borsti's Besuch bei Giga zum Thema hat und die Übersichtlichkeit etwas leidet.

deekey777
2004-06-04, 14:19:36
@Mods: Wie wär's, wenn die Diskussion um den Borsti-Artikel in einen anderen Thread verschoben werden?

Borsti
2004-06-04, 14:28:28
Original geschrieben von Demirug
Ich meinte das anders. Sobald man eine Mipmap einer Textur so färbt das sie die Schwelle überschreitet wird ganze Textur mit allen Mipmaps nicht mehr optimiert.

Was man beim einfärben noch zu sehen bekommt ist die grösste Mipmap weil diese nicht angetastet wird.

Daher ist die Optimierung komplett deaktiviert wenn man mit gefärbten Mipmaps arbeitet auch wenn nicht alle Mipmaps einer textur gefärbt sind.



Sicherlich wobei es ja durchaus auch legale Optimierungen gibt. Die adaptive Sampleanzahl beim AF gehört in diesen Bereich weil der Pixel in diesen Bereichen ja gar nicht genügend Texturfläche abdeckt um die maximale anzahl von Samples zu erreichen.

Aus diesem Grund gibt man ja auch die maximale Anzahl von Samples pro Pixel an und nicht die absolute wenn man das AF aktiviert. Eigentlich müsste man das mit der adativen Sampleanzahl gar nicht extra herausstellen weil es zum AF dazu gehört.

In Serious Sam SE brachte 16-bit Z wenn ich mich recht erinnere um die 5%. Aber mit Z und AA habe ich nur Beispiele genannt, die mir spontan einfielen. Anhaltspunkte habe ich da nicht. Bei AA grübele ich aber, ob man bei zunehmender Auflösung nicht was machen könnte. Zwischen 2x und 4x sind die Unterschiede bei 1600x1200 ja sehr gering.

Gibt es eigentlich real-life Beispiele, ausser Colored Mipmaps in denen volle trilineare Filterung nötig ist? ATI erkennt ja nicht direkt eingefärbte Mipmaps, aber solange es keine anderen Situationen gibt läuft es am Ende doch darauf hinaus die Optimierung zu verschleiern.

Ich hoffe nun NV macht nicht den Fehler, beim kommenden official driver release wieder einen Bug im Treiber zu haben wie in 61.11...

Lars - THG

Lars - THG

Gast
2004-06-04, 14:29:36
Sehr guter Artikel von Borsti und für Laien gut verständlich!
Allerdings frage ich mich wie eine Optimierung der Filterung durch die WHQL Tests durchschlüpfen kann, wenn Trilineare Filterung mathematisch definierbar ist wie im Artikel zu lesen ?! Da muss etwas schief laufen bei M$, denn entweder ist deren Test für die Katz oder die gucken weg die Leutz ! :bad1:

Demirug
2004-06-04, 14:34:43
Original geschrieben von Gast
Sehr guter Artikel von Borsti und für Laien gut verständlich!
Allerdings frage ich mich wie eine Optimierung der Filterung durch die WHQL Tests durchschlüpfen kann, wenn Trilineare Filterung mathematisch definierbar ist wie im Artikel zu lesen ?! Da muss etwas schief laufen bei M$, denn entweder ist deren Test für die Katz oder die gucken weg die Leutz ! :bad1:

Der WHQL-Test prüft mit gefärbten Mipmaps und die erkennt der Treiber ja und deaktiviert die Optimierung.

Gast
2004-06-04, 14:43:01
Original geschrieben von Demirug
Der WHQL-Test prüft mit gefärbten Mipmaps und die erkennt der Treiber ja und deaktiviert die Optimierung.

Hätte gedacht das ein so grosses Unternehmen mehrere Möglichkeiten sich bedient um die Qualität der Treiber zu testen und nicht nur eine standartisierte Methode anwendet!

Demirug
2004-06-04, 14:44:20
Original geschrieben von Borsti
In Serious Sam SE brachte 16-bit Z wenn ich mich recht erinnere um die 5%. Aber mit Z und AA habe ich nur Beispiele genannt, die mir spontan einfielen. Anhaltspunkte habe ich da nicht. Bei AA grübele ich aber, ob man bei zunehmender Auflösung nicht was machen könnte. Zwischen 2x und 4x sind die Unterschiede bei 1600x1200 ja sehr gering.

Beim AA kann man sogar adaptiv ohne Qualitätsverlust arbeiten. 3dlabs haben das mal vorgemacht. Da wurde die Anzahl der AA-Samples pro Pixel auch dynamisch bestimmt.

Gibt es eigentlich real-life Beispiele, ausser Colored Mipmaps in denen volle trilineare Filterung nötig ist? ATI erkennt ja nicht direkt eingefärbte Mipmaps, aber solange es keine anderen Situationen gibt läuft es am Ende doch darauf hinaus die Optimierung zu verschleiern.

Die Texelanalyse in meinem AF-Tester benutzt noch ein paar spezielle Texturen die als nicht optimierbar erkannt werden. Ansonsten wurde bisher aber AFAIK kein weiterer Fall gefunden.

Ich hoffe nun NV macht nicht den Fehler, beim kommenden official driver release wieder einen Bug im Treiber zu haben wie in 61.11...

Lars - THG

Lars - THG

Ja das würde schwer noch hinten losgehen.

Demirug
2004-06-04, 14:45:46
Original geschrieben von Gast
Hätte gedacht das ein so grosses Unternehmen mehrere Möglichkeiten sich bedient um die Qualität der Treiber zu testen und nicht nur eine standartisierte Methode anwendet!

Es gibt da leider keine wirkliche Alternative für die Durchführung dieses Tests.

Gast
2004-06-04, 14:51:10
Original geschrieben von Demirug
Es gibt da leider keine wirkliche Alternative für die Durchführung dieses Tests.

Und wie will man in Zukunft dieses testen da jetzt die Einfärbung der Mipmaps bei ATI nichts mehr bringt??

Quasar
2004-06-04, 15:09:50
Für das WHQL-Zertifikat muss AFAIK gar keine trilineare Filterung vorliegen. Verbindlich getestet wird da nur Bilinear mit MipMapping.

Exxtreme
2004-06-04, 15:12:45
Original geschrieben von Gast
Und wie will man in Zukunft dieses testen da jetzt die Einfärbung der Mipmaps bei ATI nichts mehr bringt??
Man kann es mit Differenzbildern testen. Einmal ein Bild mit Bi-AF machen und einmal mit "Try-AF". X-D Dann vergleicht man beide Bilder und anhand der Unterschiede sieht man ob echtes Tri-AF oder Bri-AF eingesetzt wird.

Quasar
2004-06-04, 15:14:28
Das braucht man nur mittels Erkennung des Auslesens und Zurückschreibens vom Framebuffer über den AGP aushebeln.

Dann sieht man in Zukunft immer das auf Screenies, was man sehen soll.

Mave@Work
2004-06-04, 15:18:12
Borsti guter Artikel :up:
Wenn er auch zum ende hin etwas mehr in die tiefe hätte gehen können.

Ein Frage ? Könnte nicht eine grosse Seite wie THG ein Video in Netz stellen bei dem man Full Tri und Bri al'a
ATI in Bewegung vergleichen kann ?

Dann können die Leute wenigstens nicht mehr das argument bringen: " Mit theoretischen Testern nachgewiesen beweist gar nichts".

Und wenn man auf den Videos wirklich keinen Unterschied sieht, naja auch gut, dann weiss man wenigstens, dass
die optimierung O.K. ist.

Exxtreme
2004-06-04, 15:19:00
Original geschrieben von Quasar
Das braucht man nur mittels Erkennung des Auslesens und Zurückschreibens vom Framebuffer über den AGP aushebeln.

Dann sieht man in Zukunft immer das auf Screenies, was man sehen soll.
Wird schwierig bei Anwendungen, die bei einem bestimmten Frame einen Screenshot machen. Denn die Teile werden erst gerendert und dann in den Framebuffer geschrieben.

Quasar
2004-06-04, 15:25:43
Und?
Dann erzwingst du per Treiber einfach ein erneutes Rendern mit denselben Daten/Anweisungen nur ohne Optimierungen, sobald ein Framebuffer-Grab durch ein Tastenkommando oder ein vorher sicherlich zu erkennendes Anwendungskommando erfolgt.

Exxtreme
2004-06-04, 15:28:41
Original geschrieben von Quasar
Und?
Dann erzwingst du per Treiber einfach ein erneutes Rendern mit denselben Daten/Anweisungen nur ohne Optimierungen,
Und der Frameconter springt um eins weiter beim erneuten Rendern. :)

Demirug
2004-06-04, 15:33:21
Original geschrieben von Exxtreme
Und der Frameconter springt um eins weiter beim erneuten Rendern. :)

Nein, weil die Anwendung das gar nicht mitbekommt.

Exxtreme
2004-06-04, 15:39:27
Original geschrieben von Demirug
Nein, weil die Anwendung das gar nicht mitbekommt.
Sicher? :kratz:

Naja, wenn doch, erfordert es dann einen Heiden-Aufwand jedes Mal die Daten des vorhergehenden Frames im Speicher zu halten um das Bild nochmal zu rendern. Und eigentlich könnte es das System allgemein ausbremsen... nicht?

Demirug
2004-06-04, 15:43:02
Original geschrieben von Exxtreme
Sicher? :kratz:

Naja, wenn doch, erfordert es dann einen Heiden-Aufwand jedes Mal die Daten des vorhergehenden Frames im Speicher zu halten um das Bild nochmal zu rendern. Und eigentlich könnte es das System allgemein ausbremsen... nicht?

Nein, die gesamten Framedaten gehen ja sowieso über den AGP-Speicher. Man muss nur mit dem freigegen des Speichers warten.

Quasar
2004-06-04, 15:43:14
Du verlierst 0,5% und gewinnst 30%. Deine Wahl?

Exxtreme
2004-06-04, 15:52:01
Original geschrieben von Demirug
Nein, die gesamten Framedaten gehen ja sowieso über den AGP-Speicher. Man muss nur mit dem freigegen des Speichers warten.
Ja, OK. also gibt es keinerlei praktische Möglichkeit sowas zuverlässig zu entdecken?

Borsti
2004-06-04, 16:07:26
Original geschrieben von Mave@Work
Borsti guter Artikel :up:
Wenn er auch zum ende hin etwas mehr in die tiefe hätte gehen können.

Ein Frage ? Könnte nicht eine grosse Seite wie THG ein Video in Netz stellen bei dem man Full Tri und Bri al'a
ATI in Bewegung vergleichen kann ?

Dann können die Leute wenigstens nicht mehr das argument bringen: " Mit theoretischen Testern nachgewiesen beweist gar nichts".

Und wenn man auf den Videos wirklich keinen Unterschied sieht, naja auch gut, dann weiss man wenigstens, dass
die optimierung O.K. ist.

Das Problem bei Videos ist die Komprimierung + die benötigten hohen Auflösungen. :(

Lars - THG

christoph
2004-06-04, 16:36:35
Original geschrieben von Quasar
Für das WHQL-Zertifikat muss AFAIK gar keine trilineare Filterung vorliegen. Verbindlich getestet wird da nur Bilinear mit MipMapping.

das stimmt und auch nicht ;)
es ist natürlich so der treiber alle tests bestehen muss die in zusammenhang mit den in den caps gemeldeten fähigkeiten stehen. wenn die caps also tri filter melden muß auch der test bestanden werden.

Demirug
2004-06-04, 16:39:54
Original geschrieben von Exxtreme
Ja, OK. also gibt es keinerlei praktische Möglichkeit sowas zuverlässig zu entdecken?

Natürlich gibt es die. Geht allerdings ein wenig ins Geld.

Exxtreme
2004-06-04, 16:40:50
Original geschrieben von christoph
es ist natürlich so der treiber alle tests bestehen muss die in zusammenhang mit den in den caps gemeldeten fähigkeiten stehen. wenn die caps also tri filter melden muß auch der test bestanden werden.
Naja, wenn der Treiber aber colorierte Mipmaps erkennt, ist der ganze WHQL-Test für'n Popo. Schade, daß MS da recht tatenlos ist in der Hinsicht. Trilinear ist genau definiert. Eigentlich dürfte der Treiber trilinear gar nicht melden. :D

Tjell
2004-06-04, 16:45:02
Der Artikel ist erste Sahne.

Endlich habe auch ich begriffen, was genau Filterung bewirkt. :D

Fazit für mich:
Optimierungen sind durchaus sinnvoll und vertretbar, solange ich noch bei genügend Leistungsüberschuß die Wahl habe, zu voller Qualität ohne Optimierung zu wechseln.

An jeden Grafikkarten-Hersteller kann also nur der Aufruf erfolgen:
Schafft mindestens einen Expertenmodus, in dem man alle Möglichkeiten selbst bestimmen kann.

Es kommt ja schließlich (noch?) niemand auf die Idee, und setzt die Farbtiefe (Bildschirmausgabe) auf längst überholte 16 Bit per Treiber zurück um Rechenaufwand zu sparen.

Gast
2004-06-04, 16:48:51
Wann gibts Artikel in deutsche Sprache?

LovesuckZ
2004-06-04, 16:50:39
Original geschrieben von Tjell
Es kommt ja schließlich (noch?) niemand auf die Idee, und setzt die Farbtiefe (Bildschirmausgabe) auf längst überholte 16 Bit per Treiber zurück um Rechenaufwand zu sparen.

Nein, aber manche Hersteller erzwingen beim AA 32 Bit *eg*

DrumDub
2004-06-04, 17:08:29
Original geschrieben von LovesuckZ
Nein, aber manche Hersteller erzwingen beim AA 32 Bit *eg*

das war mal so. ist es aber nicht mehr. ;)

Doc_Nitro
2004-06-04, 17:10:17
Mich persönlich würd mal interessieren was Ihr für ne Technische oder schulische Ausbildung habt. Könnte es sein dass die Techniker von NVidia und ATI alles Deppen und Cheater sind oder sich gewisse Leuz einfach nur profilieren wollen mit unverständlichen Ausdrücken die Sie irgendwo mal in nem Fachbuch gelesen haben??

Als aussenstehender bekomme ich langsam Zewifel an sogenannten Technikanalysen von dritter Seite, sprich nicht bei den genannten Firmen arbeiten.

Es ist ja schön wenn man Unabhängige Leuz hat die vielleicht den Durchblick haben was bei neuen Produkten geht. Ich bin jedoch der Meinung dass keiner hier genau weiss, was die bei Nvidia oder ATI in den Labors entwickeln und wie Sie die Chips mit den Treibern optimieren oder ned.

Wäre für mich das gleiche wenn ich behaupten würde heyy die von Mercedes Benz bescheissen weil die angegebene Höchstgeschwindigkeit bei Gegenwind 15 kmh tiefer iss.

Versucht mal nen Job bei denen zu kriegen, wobei ich aber denke dass dafür wohl die technische ausbildung ned reicht.

Sorry aber mir geht das ich weiss was, was die Deppen von den grossen Firmen ned gebacken kriegen sowas aufn Keks.

Und wenn die dann eine Antwort auf ne Frage geben heisst es sowieso, jaja redet Ihr nur wir wissen es besser. Was nicht heissen soll das hier zt mit harten Bandagen oder fragwürdigen Methoden gekämpft wird.

Mich als User interessiert alleine das was ich sehe, wie die das machen iss mir Schnurzpiepegal. Es gibt auch noch Seiten die bewerten ein Produkt direkt aus der Box mit Treibern und den üblichen Einstellungen ohne diesen Technikfirlefanz.

3DCenter iss eine von vielen Seiten und ned der heilige Gral des alleinigen Grafikwissens.

Keep up the Good Work aber übertreibts ned plz

Exxtreme
2004-06-04, 17:23:54
Original geschrieben von Doc_Nitro
Mich persönlich würd mal interessieren was Ihr für ne Technische oder schulische Ausbildung habt. Könnte es sein dass die Techniker von NVidia und ATI alles Deppen und Cheater sind oder sich gewisse Leuz einfach nur profilieren wollen mit unverständlichen Ausdrücken die Sie irgendwo mal in nem Fachbuch gelesen haben??

Naja, Deppen arbeiten bei ATi & NV sicherlich nicht. Ob sie cheaten... nun ja... das liegt im Auge des Betrachters.

Und was hast du gegen die Ausdrücke? Das Zeugs heisst halt so.
Original geschrieben von Doc_Nitro
Als aussenstehender bekomme ich langsam Zewifel an sogenannten Technikanalysen von dritter Seite, sprich nicht bei den genannten Firmen arbeiten.

Warum?
Original geschrieben von Doc_Nitro
Es ist ja schön wenn man Unabhängige Leuz hat die vielleicht den Durchblick haben was bei neuen Produkten geht. Ich bin jedoch der Meinung dass keiner hier genau weiss, was die bei Nvidia oder ATI in den Labors entwickeln und wie Sie die Chips mit den Treibern optimieren oder ned.

Also ganz genau weiss das wohl keiner hier, was die Firmen da alles eingebaut haben. Aber es hat IIRC hier auch niemand behauptet alles zu wissen. :)
Original geschrieben von Doc_Nitro
Wäre für mich das gleiche wenn ich behaupten würde heyy die von Mercedes Benz bescheissen weil die angegebene Höchstgeschwindigkeit bei Gegenwind 15 kmh tiefer iss.

Kaufst du ein Auto ausschliesslich aufgrund der Endgeschwindigkeit?
Original geschrieben von Doc_Nitro
Sorry aber mir geht das ich weiss was, was die Deppen von den grossen Firmen ned gebacken kriegen sowas aufn Keks.

Das sagt hier IIRC niemand, daß die Firmen nichts auf die Reihe bekommen. Im Gegenteil. Cheats so zu verstecken, daß keiner sofort drauf kommt, erfordert viel Mehraufwand. Denn schliesslich wollen die Firmen nur unser Bestes... unser Geld.

Da wird wohl knallhart kalkulliert. Lohnt sich der Aufwand, Cheats zu verstecken, sodaß man mehr Karten verkauft? Eine Investition wird nur dann getätigt wenn Rendite zu erwarten ist. Und wenn ein Hersteller aufgrund von nicht entdeckten Cheats mehr verkauft dann bringt das Rendite. So einfach ist das.
Original geschrieben von Doc_Nitro
Mich als User interessiert alleine das was ich sehe, wie die das machen iss mir Schnurzpiepegal. Es gibt auch noch Seiten die bewerten ein Produkt direkt aus der Box mit Treibern und den üblichen Einstellungen ohne diesen Technikfirlefanz.

Nun ja... wenn dich die Testweise von 3DC stört, dann besuche halt soche Seiten, die Out-of-the-box testen, wenn es dich glücklicher macht.
Original geschrieben von Doc_Nitro
3DCenter iss eine von vielen Seiten und ned der heilige Gral des alleinigen Grafikwissens.

:???:
Original geschrieben von Doc_Nitro
Keep up the Good Work aber übertreibts ned plz
:???:

ow
2004-06-04, 17:42:28
@Borsti


Der zweite Auschnitt von links der Screenshots auf Seite 3 oben zeigt doch definitv Mipmapping? Da steht aber "No Mipmapping Linear".

Gast
2004-06-04, 18:02:11
Original geschrieben von Doc_Nitro
Mich persönlich
.....
.....
Keep up the Good Work aber übertreibts ned plz

"This is indeed a "cheat" that both major vendors now do. Instead of always sampling the two adjacent mip map levels and doing a full blend between them, they have plateaus where only a single mip level is sampled, reducing the average samples from 8 to about 6.

It is actually a pretty sensible performance enhancement, with minimal visual issues. However, having drivers analyze mip map uploads to hide the cheat is an unfortunate consequence.

The colored mip map option in Q3 should have absolutely zero performance impact in the absence of performance options like this.

John Carmack"

Hat JC auch nicht viel Ahnung? Wenn nicht ER dann WER?

Hakkerstiwwel
2004-06-04, 18:29:30
Original geschrieben von Demirug

Wenn ATI nicht noch zusätzlich am MIPMAP-LOD geschraubt hätte würde das stimmen so aber leider nicht.

Das wurde doch schon geklärt. Es sind alle Mipmaps einer Textur betroffen und der X800 hat zusätzlich noch eine Optimierung über den LOD-BIAS.

So genug kritisiert.

was mich interressieren wuerde ist, kommt es effektif zu Pixelflimmern auf Grund des LOD?
Zitat eines eures Artikels :"Es gibt beim MIP-Mapping keine verbindlichen Regeln, wie groß der Bereich sein soll, bevor zur ersten verkleinerten Textur gegriffen wird. Ebensowenig, wann die nächsten Stufe zum Zuge kommen soll. Die Einstellung wird in der Regel so getroffen, dass man ein guten Kompromiss zwischen Textur-Schärfe und reduziertem Flimmern findet."
Das ganze kann eventuell Absicht sein um Arbeit zu sparen, und falls es eben zu keinem Flimmern kommt, ist es doch nicht falsch, oder? Eine zweite Moeglichkeit ist aber auch dass es keine Absicht ist, und hier die bekannte Schwaeche des Radeon bei der Bestimmung des LOD Schuld ist (Ausloeser in diesem Falle andere Texturen)

Mr. Lolman
2004-06-04, 18:45:13
Original geschrieben von ow
@Borsti


Der zweite Auschnitt von links der Screenshots auf Seite 3 oben zeigt doch definitv Mipmapping? Da steht aber "No Mipmapping Linear".

Stimmt.Den Fehler hat Borsti schon bei Giga gemacht, und der andere Typ hat sich kurz überlegt ob er widersprechen soll, hats dann aber doch nicht getan.

Logischerweise ist der Einzige Unterschied, zw. Pointsampling und bilinearem Filtering (jew. ohne Mipmapping) im Vordergrund zu suchen, und zwar nur an den Stellen wo Texel > Pixel *klugscheiss* *

*/edit: naja nicht ganz

Mr. Lolman
2004-06-04, 18:54:20
Original geschrieben von Hakkerstiwwel
was mich interressieren wuerde ist, kommt es effektif zu Pixelflimmern auf Grund des LOD?
Zitat eines eures Artikels :"Es gibt beim MIP-Mapping keine verbindlichen Regeln, wie groß der Bereich sein soll, bevor zur ersten verkleinerten Textur gegriffen wird. Ebensowenig, wann die nächsten Stufe zum Zuge kommen soll. Die Einstellung wird in der Regel so getroffen, dass man ein guten Kompromiss zwischen Textur-Schärfe und reduziertem Flimmern findet."
Das ganze kann eventuell Absicht sein um Arbeit zu sparen, und falls es eben zu keinem Flimmern kommt, ist es doch nicht falsch, oder? Eine zweite Moeglichkeit ist aber auch dass es keine Absicht ist, und hier die bekannte Schwaeche des Radeon bei der Bestimmung des LOD Schuld ist (Ausloeser in diesem Falle andere Texturen)

Es dürfte sowohl das LOD, als auch die geringere Präzision daran Schuld sein. Falsch ist es auch nicht. Nur warum ATi die LOD Anpassung vorgenommen hat, ist so eine Sache. Vermutlich um auf Standbildern / Screenshots ein schärferes Bild zu bekommen.

Demis Aussage lässt ausserdem darauf schliessen, das ATi den Workload verringert, in dem sie einen höheren LOD Wert verwenden. Jedoch ist genau das Gegenteil der Fall. Ausserdem schrieb Demi selbst, dass die LOD Verschiebung nur äusserst geringe Einflüsse auf die Performance hat.

Nur versteh ich nicht ganz warum man sich jetzt am ATi LOD aufhängt. Der LOD - Wert dürfte wohl kaum zu hoch gewählt sein. (=unscharfe Texturen), und für die, die ihn zu niedrig empfinden, gibts ja die Slider im Control Panel.



/edit: Zieh' dir mal das Tenebrae Mod, (für Quake1) und die dazugehörigen Hirestexturen. Hier kann man schön erkennen (z.B. In der Haupthalle am Portal für die 3. Episode) , wo ATis Präzision am Ende ist, und welchen ATifakten noch mit einem höherem LOD Wert beizukommen ist. (^= 'Mipmap Detailebene' im ATi Control Panel)

Demirug
2004-06-04, 19:31:42
Original geschrieben von Mr. Lolman
Es dürfte sowohl das LOD, als auch die geringere Präzision daran Schuld sein. Falsch ist es auch nicht. Nur warum ATi die LOD Anpassung vorgenommen hat, ist so eine Sache. Vermutlich um auf Standbildern / Screenshots ein schärferes Bild zu bekommen.

Demis Aussage lässt ausserdem darauf schliessen, das ATi den Workload verringert, in dem sie einen höheren LOD Wert verwenden. Jedoch ist genau das Gegenteil der Fall. Ausserdem schrieb Demi selbst, dass die LOD Verschiebung nur äusserst geringe Einflüsse auf die Performance hat.

Nur versteh ich nicht ganz warum man sich jetzt am ATi LOD aufhängt. Der LOD - Wert dürfte wohl kaum zu hoch gewählt sein. (=unscharfe Texturen), und für die, die ihn zu niedrig empfinden, gibts ja die Slider im Control Panel.


Fangen wir mal unten an.

Mit dem Slider bekommst du das nicht wieder weg. ATI verstellt nicht den LOD-BIAS sondern benutzt eine andere LOD-Formel. Als Besonderheit wirkt diese aber nicht in den Bereichen wo aufgrund des Winkels sowieso maximal 2xAF gefiltert wird. Dort kommt mehr oder minder noch die alte Formel zum Einsatz.

Wo habe ich geschrieben das es nicht viel bringt? In den Messreihen habe ich teilweise heftige Fillrategewinne durch diese Sache gesehen.

Nun zum kompliziertesten Teil. Die Sache hat mich ebenfalls erst mal schwer durcheinader gebracht. Man geht ja allgemein davon aus das ein negativer LOD-BIAS dazu führt das mehr Fillrate gebraucht wird weil ja später auf die nächste Mipmap gewechselt wird. In Verbindung mit AF gibt es aber noch einen zweiten Effekt. Das AF ist ja adaptiv was die Texelanzahl angeht. Durch die Verschiebung beim LOD wird dadurch nicht nur später auf die nächste Mipmap gewechselt sondern auch später auf díe nächst höhere Anzahl von Texels. Daher gibt es Bereiche in denen eine 9800 schon mit 16 Texel zu werke geht (4xBIAF) ein X800 aber noch bei 8 Texel (2xBIAF) ist. Das ganze wiederholt sich dann beim überganng von 4xAF auf 6xAF und allen weiteren wieder. Nur beim wechsel der Mipmap bliebt der X800 noch auf MaxAF an stellen wo die 9800 schon wieder bei MinAF ist. Gerade bei hohem MaxAF fallen nun aber viel mehr Pixel in die Zonen mit dem Sampleanzahl wechsel als in Zonen mit Mipmap wechsel. Das ist das Geheimniss warum der R420 durch die LOD-Spielerei schneller wird.

Borsti
2004-06-04, 19:32:45
Original geschrieben von ow
@Borsti


Der zweite Auschnitt von links der Screenshots auf Seite 3 oben zeigt doch definitv Mipmapping? Da steht aber "No Mipmapping Linear".

Die Screenshots aus denen ich die Ausschnitte genommen habe sind alle aus 1024x768! Das habe ich vergessen am Anfang zu schreiben. Also den Artikel bzw. die PNGs am besten mit der Auslösung anschaun.

Ich kann nich garantieren was die Q3 Engine da genau macht, aber das ist eigentlich Linear ohne Mipmapping. Sieht auf dem Shot zwar besser aus als Bilinear (teilweise), flimmert aber arg.

Ich werds aber nochmal nachkontrollieren

Lars - THG

ShadowXX
2004-06-04, 20:11:51
Guter Artikel Borsti...damit hat auch endlich ein Kumpel von mir die Unterschiede der verschiedenen Filterungen verstanden...

(Mein gerede war ihm immer zu technisch...)

Melbourne, FL
2004-06-04, 20:20:48
Original geschrieben von Exxtreme
Ja, OK. also gibt es keinerlei praktische Möglichkeit sowas zuverlässig zu entdecken?

Koennte man das Bild nicht am DVI abgreifen? Da braeuchte man zwar extra-Hardware aber der Treiber duerfte sowas nicht merken...

Alexander

Exxtreme
2004-06-04, 20:29:10
Original geschrieben von Alexander
Koennte man das Bild nicht am DVI abgreifen? Da braeuchte man zwar extra-Hardware aber der Treiber duerfte sowas nicht merken...

Alexander
Nein, denn das Bild am DVI ist schon komplett berechnet.

Demirug
2004-06-04, 20:30:20
Original geschrieben von Exxtreme
Nein, denn das Bild am DVI ist schon komplett berechnet.

Und? Genau dieses Bild will man doch haben. Ist ja das gleiche was auf dem Monitor erscheint.

Exxtreme
2004-06-04, 20:36:25
Original geschrieben von Demirug
Und? Genau dieses Bild will man doch haben. Ist ja das gleiche was auf dem Monitor erscheint.
So ist das gemeint. :bonk: Sorry, hatte gerade einen Aussetzer. X-D
Ja, damit könnte es funktionieren.

Borsti
2004-06-04, 20:38:11
Original geschrieben von Alexander
Koennte man das Bild nicht am DVI abgreifen? Da braeuchte man zwar extra-Hardware aber der Treiber duerfte sowas nicht merken...

Alexander

Da gibt es edle Geräte für... aber ich finde den Link nicht mehr :(

Lars - THG

Borsti
2004-06-04, 20:39:54
Halt.. da isses

http://www.unigraf.fi/index.php?page=13

Hakkerstiwwel
2004-06-04, 21:04:36
Original geschrieben von Demirug
Fangen wir mal unten an.


Nun zum kompliziertesten Teil. Die Sache hat mich ebenfalls erst mal schwer durcheinader gebracht. Man geht ja allgemein davon aus das ein negativer LOD-BIAS dazu führt das mehr Fillrate gebraucht wird weil ja später auf die nächste Mipmap gewechselt wird. In Verbindung mit AF gibt es aber noch einen zweiten Effekt. Das AF ist ja adaptiv was die Texelanzahl angeht. Durch die Verschiebung beim LOD wird dadurch nicht nur später auf die nächste Mipmap gewechselt sondern auch später auf díe nächst höhere Anzahl von Texels. Daher gibt es Bereiche in denen eine 9800 schon mit 16 Texel zu werke geht (4xBIAF) ein X800 aber noch bei 8 Texel (2xBIAF) ist. Das ganze wiederholt sich dann beim überganng von 4xAF auf 6xAF und allen weiteren wieder. Nur beim wechsel der Mipmap bliebt der X800 noch auf MaxAF an stellen wo die 9800 schon wieder bei MinAF ist. Gerade bei hohem MaxAF fallen nun aber viel mehr Pixel in die Zonen mit dem Sampleanzahl wechsel als in Zonen mit Mipmap wechsel. Das ist das Geheimniss warum der R420 durch die LOD-Spielerei schneller wird.

Schön und gut, das erklärt was das Drehen am LOD bringt. Die Frage aber ob es einen negativen Einfluss auf die IQ hat (Pixelflimmern, Texturaliasing) bleibt unbeantwortet, ebenso wie meine diesbezügliche Frage ob sich die GPU nicht einfach verhaspelt.

Mr. Lolman
2004-06-04, 21:11:21
Original geschrieben von Hakkerstiwwel
Schön und gut, das erklärt was das Drehen am LOD bringt. Die Frage aber ob es einen negativen Einfluss auf die IQ hat (Pixelflimmern, Texturaliasing) bleibt unbeantwortet, ebenso wie meine diesbezügliche Frage ob sich die GPU nicht einfach verhaspelt.


Ein wenig Geduld noch... (kanns aber nur für R3x0 demonstrieren)

Hakkerstiwwel
2004-06-04, 21:27:00
Original geschrieben von Mr. Lolman
Ein wenig Geduld noch... (kanns aber nur für R3x0 demonstrieren)

da der R3x0 den adaptiven Modus aber nicht beherrscht, und das LOD (anscheinend) nicht verstellt, weiss ich nicht wie du es demonstrieren willst **gespanntsein**

DanMan
2004-06-04, 21:31:12
Steht einges an Unwahrheiten drin. Bin nur im Moment zu faul sie herauszuschreiben. (Jaja, sieht wie ein billiger Flame aus, isses aber nicht).

Insgesamt gesehen aber eigentlich ne runde Sache.

Quasar
2004-06-04, 21:33:13
Original geschrieben von Hakkerstiwwel
da der R3x0 den adaptiven Modus aber nicht beherrscht, und das LOD (anscheinend) nicht verstellt, weiss ich nicht wie du es demonstrieren willst **gespanntsein**

Ich glaube, er will nur das LOD-Problem darstellen.

Mr. Lolman
2004-06-04, 21:35:38
Original geschrieben von Hakkerstiwwel
da der R3x0 den adaptiven Modus aber nicht beherrscht, und das LOD (anscheinend) nicht verstellt, weiss ich nicht wie du es demonstrieren willst **gespanntsein**

Eine Ingamestelle an denen Ati LOD Ungenauigkeit schon auf R3x0 zu, selbst auf Screenshots, sichtbaren Artefakten führt, denen nichteinmal mit, auf 2. niedrigster Stufe eingestelltem, 'Mipmap Detail' beizukommen ist. *



Wie eine R420 hier aussieht wär natürlich äusserst interessant, zumal ja ATi der Meinung ist, dass die ganzen tollen Optimierungsmassnahmen sogar zu einer BQ Verbesserung führen sollen. :freak:




/edit:

Mal so als Vorgeschmack:

http://img32.photobucket.com/albums/v95/franz/?action=view&current=quake00011.jpg

(Man ahnt schon, dass diese Artefakte nicht ausschliesslich vom verschobenen LOD kommen)




@Borsti:

Pointfiltering:
http://img32.photobucket.com/albums/v95/franz/shot0009.jpg

Bilineares Filtering:
http://img32.photobucket.com/albums/v95/franz/shot0010.jpg

Demirug
2004-06-04, 21:55:44
Original geschrieben von Hakkerstiwwel
Schön und gut, das erklärt was das Drehen am LOD bringt. Die Frage aber ob es einen negativen Einfluss auf die IQ hat (Pixelflimmern, Texturaliasing) bleibt unbeantwortet, ebenso wie meine diesbezügliche Frage ob sich die GPU nicht einfach verhaspelt.

Nein, die GPU verhaspelt sich da nicht. Der R420 kann nämlich wenn er will den LOD auch wie der R3XX berechnen. Das ist volle absicht und von ATI auch so gewünscht weil es den FPS-Einbruch beim AF kleiner macht.

Wie stark es flimmert hängt im wesentlichen vom Texturinhalt ab. Je höher der Texturkontrast des grösser die Gefahr das es flimmert.

Hakkerstiwwel
2004-06-04, 22:50:43
Original geschrieben von Demirug
1.Nein, die GPU verhaspelt sich da nicht. Der R420 kann nämlich wenn er will den LOD auch wie der R3XX berechnen. Das ist volle absicht und von ATI auch so gewünscht weil es den FPS-Einbruch beim AF kleiner macht.

2.Wie stark es flimmert hängt im wesentlichen vom Texturinhalt ab. Je höher der Texturkontrast des grösser die Gefahr das es flimmert.

1. ok
2. die Theorie hab ich schon verstanden. Die konkrete Frage ist flimmert es in freier Wildbahn (habe noch in keinem Review einen Hinweis darauf gefunden), oder flimmert es nicht. Falls nein (ergo kein negativer Einfluss auf IQ) ist es ein non-event.(Aths zufolge gibt es keine strenge Regel für die LOD Bestimmung)

zeckensack
2004-06-04, 23:09:18
Original geschrieben von Hakkerstiwwel
2. die Theorie hab ich schon verstanden. Die konkrete Frage ist flimmert es in freier Wildbahn (habe noch in keinem Review einen Hinweis darauf gefunden), oder flimmert es nicht.Freie Wildbahn (http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=1869556#post1869556).
Falls nein (ergo kein negativer Einfluss auf IQ) ist es ein non-event.(Aths zufolge gibt es keine strenge Regel für die LOD Bestimmung)Ich glaube kaum, dass aths das gesagt hat.

Mr. Lolman
2004-06-05, 00:14:48
So, aber jetzt: http://www.forum-3dcenter.de/vbulletin/showthread.php?s=&threadid=146879

Hakkerstiwwel
2004-06-05, 00:40:36
Original geschrieben von zeckensack

Ich glaube kaum, dass aths das gesagt hat.

http://www.3dcenter.de/artikel/grafikfilter/index3.php

"Es gibt beim MIP-Mapping keine verbindlichen Regeln, wie groß der Bereich sein soll, bevor zur ersten verkleinerten Textur gegriffen wird. Ebensowenig, wann die nächsten Stufe zum Zuge kommen soll. Die Einstellung wird in der Regel so getroffen, dass man ein guten Kompromiss zwischen Textur-Schärfe und reduziertem Flimmern findet."

Danke für den link

aths
2004-06-05, 11:16:06
Original geschrieben von Hakkerstiwwel
http://www.3dcenter.de/artikel/grafikfilter/index3.php

"Es gibt beim MIP-Mapping keine verbindlichen Regeln, wie groß der Bereich sein soll, bevor zur ersten verkleinerten Textur gegriffen wird. Ebensowenig, wann die nächsten Stufe zum Zuge kommen soll. Die Einstellung wird in der Regel so getroffen, dass man ein guten Kompromiss zwischen Textur-Schärfe und reduziertem Flimmern findet."

Danke für den link Je älter der Artikel, desto weniger ernst nehmen, bitte. Um den besten Kompromiss aus Schärfe und Nicht-Flimmern zu finden, gibt es definierte Regeln. Vor einigen Tagen konnte ich sogar endlich herleiten, warum die BF/TF-Blume genau so, und nicht anders aussieht, mit der "Einschnürung" bei 45°.

aths
2004-06-05, 11:53:13
Original geschrieben von Borsti
Ich kann nich garantieren was die Q3 Engine da genau macht, aber das ist eigentlich Linear ohne Mipmapping. Wie soll das gehen? Linear könnte höchstens Pointsampling mit MIP-Mapping sein.

Markchen
2004-06-06, 13:22:55
@Borsti

Schöner Artikel :)

OT:
Schönen Gruß von Ela (Manuela Gergen) aus IGB. Während der Sendung bei Giga sagte Sie zu mir: "Eh den kenn ich doch". Ich:"Klar kennst Du den" ;D

Dann hat sie mich überzeugt OMG

Hehe die Welt ist klein !

PS: Ist jetzt meine Frau. :D . Vielleicht lern ich Dich ja mal auf'm Stadtfest kennen.

Edit: War früher immer bei Holger und Schörkel.

Borsti
2004-06-06, 21:43:34
Original geschrieben von Markchen
@Borsti

Schöner Artikel :)

OT:
Schönen Gruß von Ela (Manuela Gergen) aus IGB. Während der Sendung bei Giga sagte Sie zu mir: "Eh den kenn ich doch". Ich:"Klar kennst Du den" ;D

Dann hat sie mich überzeugt OMG

Hehe die Welt ist klein !

PS: Ist jetzt meine Frau. :D . Vielleicht lern ich Dich ja mal auf'm Stadtfest kennen.

Edit: War früher immer bei Holger und Schörkel.

Dankefein! :) Ganz liebe Grüße zurück!!! Mit dem Stadtfest in IGB wirds aber nicht klappen. Lebe ja schon seit ein paar Jahren bei M. Müsste mal meinen Bruder besuchen, dann könnt ich die ganzen Nasen aus der Clique mal wieder sehen und die Stadt unsicher machen ;)

Lars

Markchen
2004-06-07, 22:50:16
Grüße zurück, vielleicht treffen wir uns ja mal irgendwann :)

Gast
2004-06-08, 12:24:03
/Spassmodeon

Bei dem Bild würd ich mich aber net traun dich zu treffen...

Wer weiss ob man mich nachher jemals wieder sehen tut..

/Spassmodeoff

Markchen
2004-06-08, 13:12:15
:asshole:

Mave@Work
2004-06-10, 08:57:00
Original geschrieben von Borsti
Das Problem bei Videos ist die Komprimierung + die benötigten hohen Auflösungen. :(

Lars - THG

Na und ? Muss ja nun wirklich nicht lang sein. 5 sec reichen völlig um banding zu sehen. Das müssten in DVD
qualität bei 1240*1024 etwa 3-5 MB sein.
Das sollte doch machbar sein.

deekey777
2004-06-17, 11:49:28
Endlich ist der Artikel auch auf Deutsch: ATI optimiert Texturfilterung: Mehrwert oder Betrug? (http://www.de.tomshardware.com/graphic/20040616/index.html)