Archiv verlassen und diese Seite im Standarddesign anzeigen : NV betrügt
avalanche
2005-07-19, 20:13:27
Ich hatte ja versprochen das Performance Diagramm des G70 AFs zu posten.
Zum Vergleich auch noch das vom NV40 und R420. Jeweils maximale über das Panel/CCC erreichbare Qualität.Gibt's zu den (/solchen) Diagrammen irgendwo 'ne Erklärung? Ich weiß gerade nicht, wie ich die zu interpretieren habe.
Jetzt fehlt nur noch eine Interpretation, die ich verstehe. :)
BlackArchon
2005-07-19, 20:15:13
Kannst du das bitte interpretieren? Ich kann mir da leider überhaupt gar nichts daraus entnehmen. ;(
Demirug
2005-07-19, 20:33:22
Von Links nach rechts steigt das Texel zu Pixel Verhältniss an. Die ersten 100 Pixel sind nicht so wichtig. Dann haben wir genau das Verhältniss 1 zu 1. Nach jeweils 100 Pixel verdoppelt sich das Verhältniss. Also 2:2, 4:1, 8:1 usw. Dazwischen wird jeweils linear skaliert.
Die Farbigenen Linie zeigen die Mipmap übergänge an. Unten 0% oben 100%.
Die weiße Linie ist die Performance Kurve. Oben entspricht der maximalen erreichten Füllrate unten wäre 0. Dazwischen wird linear skaliert.
Man sieht auf dem Diagramm also wie hoch die Pixelfüllrate bei gefilterten Texturen bei bestimmten Texel zu Pixel verhältnissen auf einer 0 Grad Linie ist. Damit kann man zum einen Chipgenerationen vergleichen aber auch merkwürdigkeiten sehen. Die R420er Linie hat zum Beispiel im hinteren Bereich diese Auffälligen Hügel die ich mir gerade nicht erklären kann.
Mit den buten Linien kann man Abweichungen beim Trilinearen Filter sehen. Das ATI aber gefärbte Mipmaps erkennt funktioniert das dort leider nicht richtig. Soll heisen dort wird immer das maximal erreichbare an Qualität angezeigt oder die Linien verschwinden ganz
zeckensack
2005-07-19, 20:45:59
Die R420er Linie hat zum Beispiel im hinteren Bereich diese Auffälligen Hügel die ich mir gerade nicht erklären kann.Dort passen die genutzten Mipmaps mehr oder weniger komplett in den Texturcache. Im Grenzbereich hängt es von der Reihenfolge der Abarbeitung ab, wie viel gethrasht wird (was dann die Hügel ergibt). Irgendwann passt's dann komplett in den Cache (waagerechte Linie bei den letzten drei Mips).
reunion
2005-07-19, 20:46:00
Um mal wieder zum Thema zu kommen.
Ich hatte ja versprochen das Performance Diagramm des G70 AFs zu posten.
Zum Vergleich auch noch das vom NV40 und R420. Jeweils maximale über das Panel/CCC erreichbare Qualität.
Darf man fragen, in welcher Reihenfolge die Pics gepostet sind?
zeckensack
2005-07-19, 20:46:58
Darf man fragen, in welcher Reihenfolge die Pics gepostet sind?IMO von links nach rechts:
G70, NV40, R420
IMO von links nach rechts:
G70, NV40, R420
Eher von oben nach unten. ;)
Aber Reihenfolge stimmt. :)
avalanche
2005-07-19, 20:50:01
Müsste die Füllrate nicht proportional zum Texel-Pixel-Verhältnis abnehmen? Womit kann man so schicke Diagramme machen?
Damit ich alles richtig verstehe: Das Probem ist, dass der G70 bei bestimmten Texel-Pixel-Verhältnissen relativ zur maximalen Füllrate mehr Füllrate hat, als der NV40. Irgendwie stell ich mich gerade blöd an. Das, was ich dem Diagramm so entnehmen kann ist, dass ab einem bestimmten Verhältnis der G70 mehr Füllrate (relativ zur maximalen Füllrate) hat, als der NV40. Nicht, dass das nur bei einigen wenigen bestimmten Verhältnissen so wäre. (Wäre natürlich genau so möglich, dass ich Eingangs das Problem falsch verstanden habe und nun das Problem richtig "sehe".)
Demirug
2005-07-19, 20:52:27
IMO von links nach rechts:
G70, NV40, R420
Links nach rechts?
du meinst von oben nach unten oder ist das Browserabhängig?
reunion
2005-07-19, 20:54:25
IMO von links nach rechts:
G70, NV40, R420
Danke.
Zwischen NV40 und G70 scheint es ja exentielle Unterschiede zu geben.
Wenn die Linie springt, bedeutet das, dass sich der Füllratenverbrauch schlagart ändern, was auf eine "Optimierung" schließen lässt, oder?
Demirug
2005-07-19, 20:58:30
Müsste die Füllrate nicht proportional zum Texel-Pixel-Verhältnis abnehmen? Womit kann man so schicke Diagramme machen?
Damit ich alles richtig verstehe: Das Probem ist, dass der G70 bei bestimmten Texel-Pixel-Verhältnissen relativ zur maximalen Füllrate mehr Füllrate hat, als der NV40. Irgendwie stell ich mich gerade blöd an. Das, was ich dem Diagramm so entnehmen kann ist, dass ab einem bestimmten Verhältnis der G70 mehr Füllrate (relativ zur maximalen Füllrate) hat, als der NV40. Nicht, dass das nur bei einigen wenigen bestimmten Verhältnissen so wäre. (Wäre natürlich genau so möglich, dass ich Eingangs das Problem falsch verstanden habe und nun das Problem richtig "sehe".)
Die Füllarte muß sprunghaft ab und zunehmen wenn der AF Level gewechselt wird bzw. der Tri Filter ein und ausgeschaltet wird.
Das Programm ist ein Spezialbenchmark von mir den ich um zu vermeiden das er durch APP Erkennung ausgehebelt wird derzeit nicht öffentlich mache.
Das Problem des G70 ist dort nicht erkennbar. Die Diagramme zeigen nur das nVidia beim G70 etwas verändert hat weil die Kurve anders verläuft. Das war sozusagen das erste Indiz das sie etwas geändert haben und das es zusätzliche Performances bringt. Eine zweite Zahlenkolene die ich aber erst noch aufbereiten muss zeigt nun aber das immer noch die gleiche Anzahl von Texel beim G70 wie schon beim NV40 verrechnet werden. Es ist also keine Unterfilterung durch Auslassen von Texel. Jetzt alles bei HQ. Quality ist noch eine andere Story.
Demirug
2005-07-19, 21:02:23
Danke.
Zwischen NV40 und G70 scheint es ja exentielle Unterschiede zu geben.
Wenn die Linie springt, bedeutet das, dass sich der Füllratenverbrauch schlagart ändern, was auf eine "Optimierung" schließen lässt, oder?
Die Leistungssprünge können auch durchaus völlig OK sein. Zum Beispiel sind diese Stellen einmal pro Mipmap bei denen es kurz hochgeht die Stellen bei denen die zweite Mipmap nicht gebraucht wird und der Chip völlig legal Bi Filtern kann.
avalanche
2005-07-19, 21:05:01
Die Füllarte muß sprunghaft ab und zunehmen wenn der AF Level gewechselt wird bzw. der Tri Filter ein und ausgeschaltet wird.Ist klar, der AF-Level geht ja nicht "fließend" mit dem Texel-Pixel-Verhältnis mit.Das Programm ist ein Spezialbenchmark von mir den ich um zu vermeiden das er durch APP Erkennung ausgehebelt wird derzeit nicht öffentlich mache.Versteh ich.Das Problem des G70 ist dort nicht erkennbar. Die Diagramme zeigen nur das nVidia beim G70 etwas verändert hat weil die Kurve anders verläuft. Das war sozusagen das erste Indiz das sie etwas geändert haben und das es zusätzliche Performances bringt.Gut, ich hatte schon Selbstzweifel :)Eine zweite Zahlenkolene die ich aber erst noch aufbereiten muss zeigt nun aber das immer noch die gleiche Anzahl von Texel beim G70 wie schon beim NV40 verrechnet werden. Es ist also keine Unterfilterung durch Auslassen von Texel.Ich bin gespannt.
Gibt es überhaupt irgendwo eine Publikation oder Formel wie AF zu funtkionieren hat? Ich finde im Netz nämlich rein gar nichts dazu.
hm interpretiere ich dass dann richtig dass der nv40 eher am anfang etwas spart, während der r420 im hinteren teil des bildes mehr spart? und filtert der G70 am "bösesten"?
kann man darauf wirklich rückschlüsse auf die tatsächliche qualität schließen?
z.b. hat imo die GF4 mit AF immer die hälfte der füllrate verloren wenn AF aktive war, auch wenn keine texturverzerrung vorhanden war. das würde ja dann in einem besonders "braven" diagramm resultieren ohne dass man davon wirklich profitiert.
btw.: warum sind die farbige linien bei ATI gepunktet während es bei NV quasi durchgehende linien gibt?
Demirug
2005-07-19, 21:10:20
Gibt es überhaupt irgendwo eine Publikation oder Formel wie AF zu funtkionieren hat? Ich finde im Netz nämlich rein gar nichts dazu.
Nein, deswegen dürfen da ja auch nVidia und ATI daran drehen und es immer noch AF nennen. Es gibt mindestens 3 verschiedene Verfahren die in der Theorie diskutiert worden sind.
Die Füllarte muß sprunghaft ab und zunehmen wenn der AF Level gewechselt wird bzw. der Tri Filter ein und ausgeschaltet wird.
warum ist eigentlich die kurve bei ATI fast stetig während es bei NV deutliche sprünge gibt?
Demirug
2005-07-19, 21:17:14
hm interpretiere ich dass dann richtig dass der nv40 eher am anfang etwas spart, während der r420 im hinteren teil des bildes mehr spart? und filtert der G70 am "bösesten"?
Die Kurven sagen nur etwas über die Performances aber nichts über die Qualität aus. Zeckensack vermuteted und ich bin gewillt da zuzustimmen das die R420 Kurve stark durch die Speicherbandbrite gebrägt ist.
kann man darauf wirklich rückschlüsse auf die tatsächliche qualität schließen?
Wie schon gesagt nein. Aber diese Kurven helfen die Stellen zu finden an denen man genauerere Untersuchngen anstellen sollte.
z.b. hat imo die GF4 mit AF immer die hälfte der füllrate verloren wenn AF aktive war, auch wenn keine texturverzerrung vorhanden war. das würde ja dann in einem besonders "braven" diagramm resultieren ohne dass man davon wirklich profitiert.
Das war das AF Rechenwerk der GF4. Das war einfach zu schwach um in einem Takt zu berechnen ob man überhaupt AF braucht.
btw.: warum sind die farbige linien bei ATI gepunktet während es bei NV quasi durchgehende linien gibt?
Das kommt von der kleineren Genauigkeit des Trilinearen Filters bei ATI.
Nein, deswegen dürfen da ja auch nVidia und ATI daran drehen und es immer noch AF nennen. Es gibt mindestens 3 verschiedene Verfahren die in der Theorie diskutiert worden sind.Bisher werden doch auf einer Linie bis zu 16 trilineare Samples genommen, hab ich das richtig verstanden?
Demirug
2005-07-19, 21:20:15
warum ist eigentlich die kurve bei ATI fast stetig während es bei NV deutliche sprünge gibt?
Wie gesagt bei ATI überdeckt wohl die Speicherbandbreite einiges. Zudem hat nVidia mit 6xAF eine zusätzliche Filterstufe. Die Diagramme sind übrigens mit 8xAF. Das habe ich vergessen zu schreiben.
Hauwech
2005-07-19, 21:21:22
hm interpretiere ich dass dann richtig dass der nv40 eher am anfang etwas spart, während der r420 im hinteren teil des bildes mehr spart? und filtert der G70 am "bösesten"?
kann man darauf wirklich rückschlüsse auf die tatsächliche qualität schließen?
z.b. hat imo die GF4 mit AF immer die hälfte der füllrate verloren wenn AF aktive war, auch wenn keine texturverzerrung vorhanden war. das würde ja dann in einem besonders "braven" diagramm resultieren ohne dass man davon wirklich profitiert.
btw.: warum sind die farbige linien bei ATI gepunktet während es bei NV quasi durchgehende linien gibt?
Ich glaube das war ein Hardware-Bug bei 4xAF bei der GF4Ti.
edit: Hum, ich glaube Demis Antwort kommt dem naeher als meine. Hatte ich noch so in Erinnerung. :frown:
zeckensack
2005-07-19, 21:21:57
warum ist eigentlich die kurve bei ATI fast stetig während es bei NV deutliche sprünge gibt?Weil ATI die LOD-Fraction nur mit 5 Bit Präzision ermittelt. Es gibt demzufolge 32 Stufen bei der Überblendung zwischen zwei Mipmaps (die Überblendung braucht man "nur" für's trilineare Filtern).
NVIDIA hat laut dieser Kurve mindestens sieben Bit, was sich mit der Theorie deckt (laut aths waren es bei der Geforce 4Ti schon acht).
edit: ährm ... ich hatte jetzt gedacht du meinst die farbigen Kurven, nicht die weiße Kurve. Ich bitte um Aufklärung =)
Demirug
2005-07-19, 21:22:00
Bisher werden noch auf einer Linie bis zu 16 trilineare Samples genommen, hab ich das richtig verstanden?
Normalerweise nimmt man auf den Mipmaps BI Samples und verrechnet diese um dann am Ende die Werte der beiden Mipmaps zu verrechnen. Dadurch kann man auf beiden Mipmaps unterschiedliches AF Stufen nutzen.
Zudem hat nVidia mit 6xAF eine zusätzliche Filterstufe.Und 12x :)
Normalerweise nimmt man auf den Mipmaps BI Samples und verrechnet diese um dann am Ende die Werte der beiden Mipmaps zu verrechnen. Dadurch kann man auf beiden Mipmaps unterschiedliches AF Stufen nutzen.Kann AF nicht auch mehr als 2 Mipmaps betreffen?
Links nach rechts?
du meinst von oben nach unten oder ist das Browserabhängig?
Ja, das ist browserabhängig. Opera zeigts von links nach rechts an.
z.b. hat imo die GF4 mit AF immer die hälfte der füllrate verloren wenn AF aktive war, auch wenn keine texturverzerrung vorhanden war. das würde ja dann in einem besonders "braven" diagramm resultieren ohne dass man davon wirklich profitiert.
Nur bei bilinearem AF. Ansonsten spricht das AF von NV2x aber schon bei minimaler Verzerrung an, ca. bei 1,0004:1. Man bekommt also mit Ausnahme von genau platzierten Quads für HUD und Postfilter praktisch immer mindestens 2xAF.
Kann AF nicht auch mehr als 2 Mipmaps betreffen?
So wie es heute implementiert ist, nicht. Obwohl es in speziellen Extremfällen sogar Sinn hätte.
Demirug
2005-07-19, 21:35:50
Und 12x :)
Ja, bei 8xAF kommt man aber dort nicht hin.
Kann AF nicht auch mehr als 2 Mipmaps betreffen?
Trilineare AF nutzt nur zwei Mipmaps. Vielleicht kommt mal jemand auf die Idee 3 Mipmaps zu benutzten.
MadManniMan
2005-07-19, 21:39:45
Und 12x :)
Ich dachte auch 10* und 14*?
Hm ich dachte die länge der "line of anisotropy" wird von der Pixel->Screen Projektion bestimmt. Oder ist 16x immer "kurz genug" um nur 2 MIPs zu berühren?
Hm ich dachte die länge der "line of anisotropy" wird von der Pixel->Screen Projektion bestimmt. Oder ist 16x immer "kurz genug" um nur 2 MIPs zu berühren?
Es gibt nur einen LOD-Wert, der bestimmt, welche beiden Mipmaps verwendet werden (und der Nachkommateil ist der Faktor für die lineare Interpolation). Die Line of Anisotropy bestimmt, wo auf diesen Mipmaps gesampelt wird.
Wie gesagt bei ATI überdeckt wohl die Speicherbandbreite einiges. Zudem hat nVidia mit 6xAF eine zusätzliche Filterstufe. Die Diagramme sind übrigens mit 8xAF. Das habe ich vergessen zu schreiben.
Demi,
du bist dir schon im Bilde das die 6xAF von nvidia ein recht merkürdiger Modus ist. Mal überlegen, wurde der nicht vor Jahren von nv als Gegenmittel zu 9700 AF Settings entwickelt?! Um Nummern-Mässig besser da zu stehen!!!??
Kleine Randmemo:
Ich finde es erstaunlich wie du die Lücken im G70 durch technische Diskussionen in ein harmloses Plauderstündchen umwandelst.
Sorry, aber das brannte mir auf der Seele :) Nich böse sein
Demirug
2005-07-19, 21:46:36
Hm ich dachte die länge der "line of anisotropy" wird von der Pixel->Screen Projektion bestimmt. Oder ist 16x immer "kurz genug" um nur 2 MIPs zu berühren?
Das hat nichts mit der Länge zu tun. Man kann die Informtionen immer aus jeder Mipmap holen. Je größer die Mipmap ist desto mehr Texel braucht man aus dieser um die Linie komplett abzudecken.Man könnte also auch anstelle von zwei direkt aufeinader folgenden Mipmaps eine dazwischen auslassen. Was schon wieder eine Böse Optimierung wäre. Hoffentlich habe ich jetzt niemanden auf eine Idee gebracht.
edit: ährm ... ich hatte jetzt gedacht du meinst die farbigen Kurven, nicht die weiße Kurve. Ich bitte um Aufklärung =)
ich hab die weißen kurven gemeint, dass mit farbigen hat ja demirug mittlerweile mit dem ungenaueren tri-filter erklärt.
btw.: könnte man das nicht eigentlich auch als "hardware-cheat" bezeichnen, da man ja dadurch mehr pixel "legal" rein bilinear filtern kann?
Demirug
2005-07-19, 21:55:51
Demi,
du bist dir schon im Bilde das die 6xAF von nvidia ein recht merkürdiger Modus ist. Mal überlegen, wurde der nicht vor Jahren von nv als Gegenmittel zu 9700 AF Settings entwickelt?! Um Nummern-Mässig besser da zu stehen!!!??
Warum sollte das ein merkwürdiger Modus sein? Das 6xAF ist primär ein Zwischenmodus der dann benutzt wird wenn beim Übergang von 4xAF zu 8xAF man noch gar kein 8xAF braucht. Im Prinzip könnte man sogar auch noch 5xAF und 7xAF einfügen. Dises werden aber wohl nicht benutzt weil die AF Logik so ausgelegt ist das sie 2 Takte pro AF Level braucht.
Kleine Randmemo:
Ich finde es erstaunlich wie du die Lücken im G70 durch technische Diskussionen in ein harmloses Plauderstündchen umwandelst.
Sorry, aber das brannte mir auf der Seele :) Nich böse sein
Welche Lücken? Es gibt ein Flimmerproblem das ich im Auftrag und Zusammen mit der PCGH untersuche. Von dort habe ich die Erlaubniss bekommen Zwischenergebnisse dieser Untersuchungen auch Online zu veröffentlichen. Da hier IMHO intresse Bestand habe ich das was ich bereits in ansprechenden Form gebracht habe eben mal gepostet.
Demirug
2005-07-19, 21:58:52
ich hab die weißen kurven gemeint, dass mit farbigen hat ja demirug mittlerweile mit dem ungenaueren tri-filter erklärt.
btw.: könnte man das nicht eigentlich auch als "hardware-cheat" bezeichnen, da man ja dadurch mehr pixel "legal" rein bilinear filtern kann?
5 Bits sind die Mindestforderung von DX. Wer hier mehr hat ist selber schuld. Der Refrast rendernt auch nur mit 5 Bits.
btw. was mir noch aufgefallen ist: bei ATI sind die farbigen linien perfekt dreieckig, während sie bei nvidia leicht gebogen sind, hat das auch einen (sinnvollen) grund.
Mr. Lolman
2005-07-19, 22:04:07
brilinear!
Ich wage mal nen Schuss ins Blaue und behaupte dass bei nVIDIA die LOD-Bestimmung auch genauer ist und deshalb die Linien gebogen sind.
brilinear!Nein. Dann wären ja Teile davon länger waagrecht ganz unten bzw. oben und die Flanken steiler.
Quasar
2005-07-19, 22:12:39
du bist dir schon im Bilde das die 6xAF von nvidia ein recht merkürdiger Modus ist. Mal überlegen, wurde der nicht vor Jahren von nv als Gegenmittel zu 9700 AF Settings entwickelt?! Um Nummern-Mässig besser da zu stehen!!!??
Wie kommst du darauf? Vor der 9700 gab es die GF4 und die Radeon 8500. Beide konnten bereits 8xAF. 6 ist doch kleiner als acht, oder?
Tjell
2005-07-19, 22:25:46
Beitrag entfernt, falscher Alarm.
btw. was mir noch aufgefallen ist: bei ATI sind die farbigen linien perfekt dreieckig, während sie bei nvidia leicht gebogen sind, hat das auch einen (sinnvollen) grund.
http://www.digit-life.com/articles2/gffx/nv40-rx800-3.html
ATI verwendet eine vereinfachte LOD-Berechnung mit rho statt lambda als LOD.
Es ist schon lustig. Gibt's eigentlich irgendwas wo ATi nicht gespart hat wenn man es nicht sofort sieht? (soll jetzt kein Vorwurf sein)
mapel110
2005-07-20, 00:22:48
Es ist schon lustig. Gibt's eigentlich irgendwas wo ATi nicht gespart hat? (soll kein Vorwurf sein)
Sie boten vor nvidia 16x AF an. :ugly:
Argh ihr seid einfach zu schnell... oder ich sollte nicht soviel editieren :D
zeckensack
2005-07-20, 01:14:08
http://www.digit-life.com/articles2/gffx/nv40-rx800-3.html
ATI verwendet eine vereinfachte LOD-Berechnung mit rho statt lambda als LOD.Äh ...
Lambda ist doch nur der Zweierlogarithmus aus Rho. Und den braucht man sowieso, um die richtige(n) Mipmap(s) zu wählen. Wie soll man das denn weglassen können?
Grob nähern ist wohl möglich, aber einfach nicht ausrechnen ... ich kapier nicht wie das funktionieren soll, und auch nicht wie sich das mit den Beobachtungen deckt.
edit: nm. Ich hab's begriffen ... krass!
edit2:
Das würde bedeuten ATI könnte den LOD (Rho) als FX11.5 berechnen. Die Mipmapauswahl wäre dann das höchste gesetzte Bit vor dem Komma, und für die LOD-Fraction können direkt die Nachkommastellen fünf folgenden Bits benutzt werden. Uiuiui ...
avalanche
2005-07-20, 02:43:56
[...]LOD-Fraction[...]Ich weiß nicht, wie aus ausufernd das wird... Wenn sich das einigermaßen korrekt kurz erklären lässt: Was ist eine "Fraction"?
Der Nachkomma-Anteil. Im Gegensatz zur Mantisse ;)
turboschlumpf
2005-07-20, 06:19:10
Auch die [Anm.: GF3 und GF4] können kein quasi-perfektes 8x AF.woher kommt es, dass das af bei 8x plötzlich so "komisch" aussieht?
http://www.digit-life.com/articles2/gffx/nv40-rx800-3.html
ATI verwendet eine vereinfachte LOD-Berechnung mit rho statt lambda als LOD.hm, bis jetzt dachte ich, die formel die nvidia seit neuestem verwendet sei genauer, ähnelt das ergebnis doch mehr einem kreis als das bisher verwendete verfahren. liege ich damit jetzt falsch und es handelt sich nur um eine weitere "optimierung"?
Demirug
2005-07-20, 06:21:58
edit: nm. Ich hab's begriffen ... krass!
edit2:
Das würde bedeuten ATI könnte den LOD (Rho) als FX11.5 berechnen. Die Mipmapauswahl wäre dann das höchste gesetzte Bit vor dem Komma, und für die LOD-Fraction können direkt die Nachkommastellen benutzt werden. Uiuiui ...
Genau dieses Verfahren wird in einem Papier das ich zu dem Thema mal gelesen haben als kostengündtig implementierbar beschrieben. IIRC berechnet auch der Refrast (zumindestens bei DX7) so den LOD.
woher kommt es, dass das af bei 8x plötzlich so "komisch" aussieht?Vielleicht Präzisionsprobleme bei einer Wurzel-Rechnung? Ich weiß es nicht.
hm, bis jetzt dachte ich, die formel die nvidia seit neuestem verwendet sei genauer, ähnelt das ergebnis doch mehr einem kreis als das bisher verwendete verfahren. liege ich damit jetzt falsch und es handelt sich nur um eine weitere "optimierung"?Das darf man sehen, wie man will. Lt. OpenGL-Spec sei der Kreis besser, und ich bin inzwischen geneigt, mich dem anzuschließen. Allerdings spart man hier gegenüber dem traditionellem LOD etwas Füllrate. Das könnte für NV den Anstoß gegeben haben, die schwierigere Formel umzusetzen – wobei der Kreis ja noch nicht perfekt umgesetzt wurde.
avalanche
2005-07-20, 11:51:14
Der Nachkomma-Anteil. Im Gegensatz zur Mantisse ;)War schon spät gestern... Genau dieses Verfahren wird in einem Papier das ich zu dem Thema mal gelesen haben als kostengündtig implementierbar beschrieben. IIRC berechnet auch der Refrast (zumindestens bei DX7) so den LOD.Ich hab mir den verlinkten Artikel mal durchgelesen... Seh ich das richtig, dass "normalerweise" Rho zur Mipmap-Auswahl benutzt wird und Lamba für die "LOD-Fraction"?
EDIT: Ich sah's falsch, sorry...Lambda's integer part identifies which MIP levels should be used to select colour valuesRho wird dann wohl nur genutzt, um über den Logarithmus an Lambda zu kommen.
Daneben hab ich die 1. Gleichung mit diesem "max()" garnicht verstanden. Ich hab auch nix bei Wikipedia o.ä. gefunden, was mir die Rechnung erklärt. Außerdem wird irgendwie nirgends gesagt was "u" und "v" in der Gleichung sind. Ein "Erklärungslink" für max() und 'ne kurze Ansage, wofür "u" und "v" stehen, wär klasse.
EDIT 2: Ich glaub ich hab geblickt, was mir das "max" sagen soll ;)
Demirug
2005-07-20, 12:17:59
Dort werden unterschiedliche Verfahren zur LOD Berechnung beschrieben: http://www.sussex.ac.uk/Units/vlsi/mipmap.pdf
StefanV
2005-07-20, 13:22:20
Es ist schon lustig. Gibt's eigentlich irgendwas wo ATi nicht gespart hat wenn man es nicht sofort sieht? (soll jetzt kein Vorwurf sein)
Nope, ATi versucht immer so wenig an Transistoren wie möglich rauszuhauen.
Das ist auch der Grund, warum ein Rage 128 selbst ohne Kühler kaum warm wird, während die Konkurenz Chips mit Kühler schon recht warm werden :devil:
Das ganze haben sie immer so gemacht und werden sie auch immer weiter so machen...
Das andere extrem ist nV, die teilweise sinnlos Transistoren raushauen, für Dinge, die man eigentlich nicht (mehr) braucht...
Seraf
2005-07-20, 13:35:00
Nope, ATi versucht immer so wenig an Transistoren wie möglich rauszuhauen.
Das ist auch der Grund, warum ein Rage 128 selbst ohne Kühler kaum warm wird, während die Konkurenz Chips mit Kühler schon recht warm werden :devil:
Das ganze haben sie immer so gemacht und werden sie auch immer weiter so machen...
Das andere extrem ist nV, die teilweise sinnlos Transistoren raushauen, für Dinge, die man eigentlich nicht (mehr) braucht...
Was braucht man denn nicht mehr :|
Oder meintest du noch nicht?
PingpiN
2005-07-20, 14:55:05
Was ist nun ?Hat Nvidia beschissen oder nicht ? :smile:
Wenn ja bitte fett gedruckt schreiben. :rolleyes:
Jesus
2005-07-20, 15:04:48
Ja.
Das andere extrem ist nV, die teilweise sinnlos Transistoren raushauen, für Dinge, die man eigentlich nicht (mehr) braucht...Wer ist "man"?
Die müssen ja schön doof sein, zu große Chips zu bauen, wenn man die entsprechenden Features eigentlich nicht (mehr) braucht. Hatte "man" eigentlich Pixelshader 1.4 oder TruForm gebraucht? Warum hatte ATI da plötzlich die Transistoren für? Warum verabschiedete sich NV im NV40 z. B. vom CxU8V8-Texturformat?
Beide Firmen versuchen natürlich, mit so wenig Transistoren wie möglich auszukommen, und beide versuchen gleichzeitig, die Entwicklung voranzutreiben. Mal der eine mehr, mal weniger.
Ja.Immerhin – sie erfüllen ja die Specs. Nach diesem Kriterium haben sie beim AF nicht beschissen. Allerdings kümmern mich die DX-Specs nicht, wenn ich die Qualität bewerte. Und was ich bislang vom G70 gesehen habe, ist inakzeptabel. "16x AF" bietet nach meiner neuen, strengeren Definition aber auch der NV40 nicht. Der R420 oder R300 auch nicht.
Ob der S3 Deltachrome echtes 16x AF bietet, müsste mal von Demirugs neuem AF-Tester gecheckt werden.
Immerhin – sie erfüllen ja die Specs.
Was schreiben die Specs für AF überhaupt vor?
Also was wäre das Minimum damit es noch als 16xAF durchgeht?
StefanV
2005-07-20, 15:29:21
Was schreiben die Specs für AF überhaupt vor?
Also was wäre das Minimum damit es noch als 16xAF durchgeht?
Hm, die Spec schreibt nix vor, von daher :rolleyes:
StefanV
2005-07-20, 15:30:36
Was braucht man denn nicht mehr :|
Oder meintest du noch nicht?
Schau dir mal die nV30 an, die noch die Recheneinheiten der nV25 mit auf den Weg bekommen hat bzw sowas ähnliches...
Mit der nV35 wurden diese 'FX12' Einheiten Sinnvollerweise entsorgt...
Demirug
2005-07-20, 15:32:27
Schau dir mal die nV30 an, die noch die Recheneinheiten der nV25 mit auf den Weg bekommen hat bzw sowas ähnliches...
Mit der nV35 wurden diese 'FX12' Einheiten Sinnvollerweise entsorgt...
Wurden sie nicht. Erst beim NV40 wurden die Regcombiner vollständig entfernt.
mapel110
2005-07-20, 15:38:46
Gehts jetzt hier doch nur um AF(und dem dazugehörigen Bri)?! Irgendwer meinte doch, dass es gerade nicht nur um AF geht, sondern dass die Quali auch gerade ohne AF schlechter wäre.
Finde allerdings das Posting nicht mehr wieder, wo jemand das gesagt hat.
Seraf
2005-07-20, 15:42:08
Schau dir mal die nV30 an, die noch die Recheneinheiten der nV25 mit auf den Weg bekommen hat bzw sowas ähnliches...
Mit der nV35 wurden diese 'FX12' Einheiten Sinnvollerweise entsorgt...
Aha. Und die 8500 hatte noch eine HW T&L Einheit und die 9000 nicht mehr :rolleyes:
Nv ist davon ausgegangen das die FX12 Einheit in Dx nutzbar sein wird.
Natürlich wieder einseitiges blablabla was du da schreibst...
Es ist teilweiße korrekt was Payne sagt. Die FX12-ALUs wurden bei NV35 entfernt. Bei NV40+ wird anscheinend alles mit mindestens FP16 gerechnet und gespeichert.
Aha. Und die 8500 hatte noch eine HW T&L Einheit und die 9000 nicht mehr Nein. Aber beim R300 (also 9500+) wurden diese entsorgt und durch den Vertexshader ersetzt.
Seraf
2005-07-20, 15:53:16
Es ist teilweiße korrekt was Payne sagt. Die FX12-ALUs wurden bei NV35 entfernt. Bei NV40+ wird anscheinend alles mit mindestens FP16 gerechnet und gespeichert.
Nein. Aber beim R300 (also 9500+) wurden diese entsorgt und durch den Vertexshader ersetzt.
Ehem...
Zum Glück hab ich mir den Link schon gesucht damit mir niemand vorwerfen kann das ich haltloses Geschwafel von mir lasse!!
Radeon9000 Review
http://www.3dcenter.org/artikel/r9700_preview/index4.php
Dafür wurde die 3D-Architektur von 4x2 auf 4x1 Rendering-Pipelines mal Textureneinheiten verflacht. Ebenso flog die DirectX7 T&L-Einheit raus, DirectX7 T&L Berechnungen werden von der Radeon 9000 nun mittels des VertexShader 1.1 vorgenommen. Jener scheint nach ersten Tests aber die DirectX7 T&L Berechnungen nicht so schnell lösen zu können wie die extra DirectX7 T&L Einheit der Radeon 8500. Durch diese Umstrukturierung leidet im übrigen auch die TruForm-Performance, bei welcher nun die Tesselation (Zerlegung in neue Dreiecke) nur noch von der Software vorgenommen wird. Letztlich blieb dieses Feature für die Checkliste der Radeon 9000 zwar erhalten, ist aber sehr langsam geworden.
Oh. Das war mir neu, srykthx :redface:
Was ist nun ?Hat Nvidia beschissen oder nicht ? :smile:
Wenn ja bitte fett gedruckt schreiben. :rolleyes:
Und wenn nein, nicht? ;)
Es steht wohl fest dass der anisotrope Filter nicht das tut was er soll. Warum das so ist, ob Bug oder Absicht, ist noch nicht einwandfrei geklärt. Wenn Demirugs Messung stimmt, dass weiterhin alle Texel verwendet, aber nicht korrekt Gewichtet werden, ist von einem Bug auszugehen. Sollte man das "Betrug" nennen? In jedem Fall muss man aber vor dem AF des G70 warnen.
hat sich nun was beim 77.79 geändert?
hat das scho wer selver getestet?
wäre ma interessant zu hören
Jesus
2005-07-20, 17:26:42
Gehts jetzt hier doch nur um AF(und dem dazugehörigen Bri)?! Irgendwer meinte doch, dass es gerade nicht nur um AF geht, sondern dass die Quali auch gerade ohne AF schlechter wäre.
Finde allerdings das Posting nicht mehr wieder, wo jemand das gesagt hat.
Ich glaube das war Lolman :rolleyes:
Mr. Lolman
2005-07-20, 17:48:33
Ich glaube das war Lolman :rolleyes:
Ja AFAIK ist das auch so.
Gehts jetzt hier doch nur um AF(und dem dazugehörigen Bri)?! Irgendwer meinte doch, dass es gerade nicht nur um AF geht, sondern dass die Quali auch gerade ohne AF schlechter wäre.
Finde allerdings das Posting nicht mehr wieder, wo jemand das gesagt hat.
ich wüsste nicht was man ohne AF (außer bri) noch großartig einsparen kann. und bri wird bei deaktivierung der entsprechenden optimierung nicht verwendet.
unterfilterung würde in dem fall ja nichts bringen da jede tmu pro takt 4 texel verarbeiten kann.
Gaestle,
ich versuche in meinen Artikeln an Stellen, wo ich eingefahrenes Fehlwissen vermute, in ein oder zwei Sätzen diesem zu begegnen. So wies ich immer wieder darauf hin, dass aktiviertes 16x AF auf keinen Fall bedeutet, alles 16x anisotrop zu filtern, sondern AF adapativ realisiert wird und der tatsächlich angewendete Grad der Anisotropie vom Verzerrungsgrad der Texturen abhängt. AF ist ja auch keine "Tiefenschärfe", sondern bietet Schärfe bei verzerrter Texturdarstellung. Einfach gesagt, weil sowohl MIP-Mapping als auch iostrope Filterung für ein 1:1 u:v-Verhältnis gedacht sind. Mit AF kann man auch bei anderen Verhältnissen sowohl das Nyquist-Shannon-Theorem einhalten als auch Texturdetails anzeigen.
Leider bringt das (die Extra-Erwähnung in Artikeln) nicht viel – so überraschte mich vor einigen Wochen jemand, der meine Artikel eigentlich gelesen haben sollte mit der Vorstellung, bei aktiviertem 16x AF müssten auf jeden Fall 16 Samples genommen werden.
Lange Rede, kurzer Sinn. Wer die Materie verstehen lernen will, muss die Bereitschaft mitsich bringen, sich damit auseinanderzusetzen. Er muss sich Fachbegriffe ergoogeln können, bei Wiki nachschlagen – oder er kann im Forum fragen. Das kann jedoch nicht so gehen: "So, nun erklärt mir mal alles" sondern es muss ein genaues Verständnisproblem formuliert werden.
Mr. Lolman z. B. hatte sich Gedanken um bilineare Texturfilterung gemacht, allerdings vom falschen Ende er. Damit kam er zu wunderlichen Schlüssen. Darüber möchte ich mich nicht lustig machen – er denkt über die Sache nach, und das tun die allerwenigsten, die hier in Dingen Texturqualität mitdiskutieren. Jeder macht dabei Fehler, und wer was zu lachen haben will, braucht nur mal in meinen alten Artikeln zu lesen.
Zur Texturfilterung würde ich liebend gerne einen neuen Artikel schreiben. Das Thema ist interessant. Davon halten mich zwei Dinge ab: Erstens kostet das unheimlich viel Zeit. Zweitens versteht den Artikel kaum jemand. Denn wenn ich zur LOD-Formel komme muss ich voraussetzen, dass der Leser weiß, was der Logarithmus ist. Außerdem muss er in der Binärdarstellung von Zahlen fit sein.
Natürlich könnte man, wenn man sich wirklich viel Zeit nimmt und die Mühe macht, all sowas auch für Otto Normalverbraucher (jedoch nicht für den DAU) verständlich schreiben. Doch wer lohnt einem die Mühe?
Was schreiben die Specs für AF überhaupt vor?
Also was wäre das Minimum damit es noch als 16xAF durchgeht?Der WHQL-Test hat auch Filtertests. Die taugen zwar nichts, aber solange die Chip-Treiber-Kombination diesen Test besteht kann man sich brüsten, die DX9-Forderungen einzuhalten.
Schau dir mal die nV30 an, die noch die Recheneinheiten der nV25 mit auf den Weg bekommen hat bzw sowas ähnliches...
Mit der nV35 wurden diese 'FX12' Einheiten Sinnvollerweise entsorgt...Die wurden nicht entsorgt, der NV35 hat auch Register Combiner.
Das ist auch sinnvoll, denn die CineFX-Architektur ist nur dann schnell, wenn die (sehr hohe) FX12-Rechenkraft mitgenutzt werden kann.
Es ist teilweiße korrekt was Payne sagt. Die FX12-ALUs wurden bei NV35 entfernt. Nö. Der NV35 kann in der FPU entweder mit FP32, FP16 (da springt glaube ich ein MAD mehr raus) oder mit 2x FX12 rechnen.
ich wüsste nicht was man ohne AF (außer bri) noch großartig einsparen kann. und bri wird bei deaktivierung der entsprechenden optimierung nicht verwendet.
unterfilterung würde in dem fall ja nichts bringen da jede tmu pro takt 4 texel verarbeiten kann.Jemand könnte auf die Idee kommen, nur 3 Texel zu nutzen. Im N64-Grafikkern wird das z. B. so gemacht.
avalanche
2005-07-20, 18:54:56
Zur Texturfilterung würde ich liebend gerne einen neuen Artikel schreiben. Das Thema ist interessant. Davon halten mich zwei Dinge ab: Erstens kostet das unheimlich viel Zeit. Zweitens versteht den Artikel kaum jemand. Denn wenn ich zur LOD-Formel komme muss ich voraussetzen, dass der Leser weiß, was der Logarithmus ist. Außerdem muss er in der Binärdarstellung von Zahlen fit sein.Schreib ihn! Ich beiß mich gerade durch das von Demirug verlinkte PDF durch. Mehr als interessant - auch wenn ich ziemlich viel Zeit vorm Wörterbuch verbringe ;)
Ein 3DC-Artikel dazu wäre für mich persönlich extrem toll. Ich weiß natürlich nicht, wie das die anderen sehen und wie ich die die Mühe (ent?)lohnen soll, aber mein Interesse und Dank hättest du.
Nicky
2005-07-20, 18:57:30
Und wenn nein, nicht? ;)
Es steht wohl fest dass der anisotrope Filter nicht das tut was er soll. Warum das so ist, ob Bug oder Absicht, ist noch nicht einwandfrei geklärt. Wenn Demirugs Messung stimmt, dass weiterhin alle Texel verwendet, aber nicht korrekt Gewichtet werden, ist von einem Bug auszugehen. Sollte man das "Betrug" nennen? In jedem Fall muss man aber vor dem AF des G70 warnen.
Streng genommen mogelt nV nicht, allerdings benutzen sie ein Verfahren das (wie Ati es auch stellenweise tut) Praezision fuer Speed opfert. Falls es sich wirklich um einen HWBug handelt sehe ich fuer die G70 Filter schwarz, da ein Fix ueber Treiber ueberproportional Speed kosten duerfte.
Jemand könnte auf die Idee kommen, nur 3 Texel zu nutzen. Im N64-Grafikkern wird das z. B. so gemacht.
klar, aber das würde bei heutigen TMUs doch nix bringen oder? denen ist doch egal ob sie nun 3 oder 4 texel verrechnen.
Falls es sich wirklich um einen HWBug handelt sehe ich fuer die G70 Filter schwarz, da ein Fix ueber Treiber ueberproportional Speed kosten duerfte.
zumindest nicht mehr als beim NV40, und die rohleistung ist doch stark genug gestiegen um dieses manko auszubügeln.
Streng genommen mogelt nV nicht, allerdings benutzen sie ein Verfahren das (wie Ati es auch stellenweise tut) Praezision fuer Speed opfert.
Ich sehe nicht ganz, wo dieses Verfahren (nicht der Bug) Präzision opfert. Wenn es das Verfahren ist was ich meine.
zeckensack
2005-07-20, 19:51:21
Ich weiß nicht, wie aus ausufernd das wird... Wenn sich das einigermaßen korrekt kurz erklären lässt: Was ist eine "Fraction"?Der Rest bei Division durch 1. Auch bekannt als "die Stellen nach dem Komma". Sry ;(
Themenbezogenes Beispiel:
Lambda (der "LOD") wird (wie auch immer) ausgerechnet. Sagen wir mal es käme 3,375 raus. Die "LOD-Fraction" wäre dann 0,375.
Beim trilinearem Filter wird diese "LOD-Fraction" als Überblendgewicht zwischen zwei Mipmaps (in diesem Fall die Mipmap #3 und die Mipmap #4, weil 3<3,375<4) genutzt.
Trilineares Sample:=Bilineares Sample aus Mipmap #3 * (1-0,375) + Bilineares Sample aus Mipmap #4 * 0,375
Bei den Mipmaps fängt man btw bei 0 an zu zählen. Eine Mipmap mit größerer Hausnummern ist auf beiden Achsen um Faktor zwei größer als ihr Nachfolger mit der nächstkleineren Hausnummer.
Der Nachkomma-Anteil. Im Gegensatz zur Mantisse ;)Nö, doch nicht. Ganz enormer Brainfart meinerseits :redface:
Es sind zwar laut OpenGL-Formel die Nachkommastellen des Zweierlogarithmus von Rho, aber beim ATI-Trick ist es dann doch wieder eine Mantisse.
Rho:=5,6569
Lambda(Rho):=log(Rho)/log(2) ~=2,5
Klassisch: LOD-Fraction:=Lambda(Rho)%1=0,5
ATI: LOD-Fraction:=(Rho-4)/4~=0,414
klar, aber das würde bei heutigen TMUs doch nix bringen oder? denen ist doch egal ob sie nun 3 oder 4 texel verrechnen.Ja – aber 3-er TMUs kosten weniger Transistoren und brauchen weniger Bandbreite.
Bandbreite? Durch den Texture-Cache wird sich da kaum was ändern.
Ja – aber 3-er TMUs kosten weniger Transistoren und brauchen weniger Bandbreite.
also bei bilinearem filter doch eigentlich die hitrate im texturcache recht hoch sein, dass da kaum ein texel mehrmals übertragen werden muss.
btw.: ist die idee wirklich so blöd? man könnte doch texturen nehmen in denen jede 2. zeile um ein halbes texel verschoben ist, dann hätte man doch ein schönes dreieck aus dem man filtern kann? (ok am texturrand hätte das zeug wahrscheinlich probleme)
also bei bilinearem filter doch eigentlich die hitrate im texturcache recht hoch sein, dass da kaum ein texel mehrmals übertragen werden muss.Man rechnet trotzdem pro Bi-Sample ein neues Sample, was noch nicht im Cache ist. (Tatsächlich wird es natürlich im Cache sein, ich rede von Durchschnittswerten.) Je weniger Texel man braucht, umso weniger lädt man nach.
btw.: ist die idee wirklich so blöd? man könnte doch texturen nehmen in denen jede 2. zeile um ein halbes texel verschoben ist, dann hätte man doch ein schönes dreieck aus dem man filtern kann? (ok am texturrand hätte das zeug wahrscheinlich probleme)Das habe ich jetzt nicht verstanden ...
Das habe ich jetzt nicht verstanden ...
naja, normalerweise wird ja quadratisch 2x2 texel aus der textur gesampelt für ein bilineares samples.
[img=http://img65.imageshack.us/img65/8518/4samples9cw.gif] (http://www.imageshack.us)
ich dachte mir man könnte jede 2. zeile der textur um 1/2 texel verschieben, so wie hier gezeichnet:
[img=http://img65.imageshack.us/img65/3166/3samples0bo.gif] (http://www.imageshack.us)
man könnte dann doch die eingezeichneten 3 samples auswählen und verrechnen (für das nächste pixel wird das sample-dreieck auf den kopf gestellt)
eigentlich müsste das ergebnis doch garnicht so schlecht sein oder?
noch mal die bilder, die links scheinen ja nicht zu funktionieren:
3-samples:
http://img65.imageshack.us/img65/3166/3samples0bo.gif[/]
4-samples "standard":
[img]http://img65.imageshack.us/img65/8518/4samples9cw.gif
ps: sorry für die schlampigen zeichnungen, ich wollte mir aber nicht mehr mühe geben ;)
Es ist teilweiße korrekt was Payne sagt. Die FX12-ALUs wurden bei NV35 entfernt. Bei NV40+ wird anscheinend alles mit mindestens FP16 gerechnet und gespeichert.
Nein. Aber beim R300 (also 9500+) wurden diese entsorgt und durch den Vertexshader ersetzt.
Hi
Auch bei der 9000er wurde Truform per Vertexshader realisiert.
Gruss Labberlippe
Hi
Ups sorry hatte erst danach gesehen, das ja seraf schon es verlinkt hat.
Ich wusste es von meiner damaligen 9000er.
Gruss Labberlippe
Quasar
2005-07-20, 22:16:53
Nein, TruForm wurde per Hardware nur von der R8500 (und mit anderem Bios als 9100) unterstützt. Alles, was danach kam, rechnete TruForm in der CPU.
noch mal die bilder, die links scheinen ja nicht zu funktionieren:
3-samples:
http://img65.imageshack.us/img65/3166/3samples0bo.gif[/]
4-samples "standard":
[img]http://img65.imageshack.us/img65/8518/4samples9cw.gif
ps: sorry für die schlampigen zeichnungen, ich wollte mir aber nicht mehr mühe geben ;)Ich verstehe noch immer nicht, was du machen willst. Texturen sind in einem normalen quadratischen Raster gespeichert, nicht in einem "Bürgersteig-Raster". Man könnte, so realisiert im N64-Grafikkern, auf die Idee kommen, beim bilinearen Filtering das am weitesten entfernte Texel wegzulassen. Wenn man das LOD anpasst, flimmert es nicht mal (bzw. nicht besonders heftig) – die Grafik würde also entweder unschärfer, oder überscharf und flimmerig (da Unterfilterung.)
Wer ist "man"?
Die müssen ja schön doof sein, zu große Chips zu bauen, wenn man die entsprechenden Features eigentlich nicht (mehr) braucht. Hatte "man" eigentlich Pixelshader 1.4 oder TruForm gebraucht? Warum hatte ATI da plötzlich die Transistoren für? Warum verabschiedete sich NV im NV40 z. B. vom CxU8V8-Texturformat?
Beide Firmen versuchen natürlich, mit so wenig Transistoren wie möglich auszukommen, und beide versuchen gleichzeitig, die Entwicklung voranzutreiben. Mal der eine mehr, mal weniger.
Hallo,
ein Beispiel:
Im Entry-Level gibt es von ATI die X300, die aus 75Mio Transis. besteht, nv Answer ist eine 6200,er mit 146Mio Transis. Die auch noch einen aktiven Lüfter braucht! Deine These ist hier Richtig! NV verliert!
Eine auf NV44 basierend 6200 hat nur 75Mio Transistoren.
Die 143Mio. 6200er sind defekte 6600er und "Abfallentsorgung" kann nicht unrentabel sein ;)
Die auch noch einen aktiven Lüfter braucht!Auch falsch. NV44 Versionen (meistens TurboCache Kärtchen) brauchen keinen aktiven Lüfter.
zeckensack
2005-07-21, 07:30:16
Ich verstehe noch immer nicht, was du machen willst. Texturen sind in einem normalen quadratischen Raster gespeichert, nicht in einem "Bürgersteig-Raster".Die Idee läuft darauf hinaus, genau das zu ändern.
Die Idee läuft darauf hinaus, genau das zu ändern.
Also wenn es Leistung bringt und richtig funktioniert, ja bitte. Ansonsten, egal ob Bug oder Vorsatz, nein danke.
Bei Vorsatz kann man eh nichts machen ausser nicht kaufen. Wenn es ein Bug ist, kann man zumindest darauf hoffen, dass es per Treiber gefixt bzw umgangen werden kann. Andernfalls gilt auch hier, nicht kaufen. Mit dem 77.72 ist es ja beim NV40 besser geworden, da bleibt zumindest die Hoffnung bestehen dass das gleiche auch beim G70 gilt. :/
Gaestle
2005-07-21, 10:09:51
Gaestle,
Natürlich könnte man, wenn man sich wirklich viel Zeit nimmt und die Mühe macht, all sowas auch für Otto Normalverbraucher (jedoch nicht für den DAU) verständlich schreiben. Doch wer lohnt einem die Mühe?
Ich möchte es kurz halten, weil inzwischen ist's ja wieder OT.
Ich verstehe absolut was Du meinst. Zeckensacks Argumentation ging ja genau in die gleiche Richtung.
Andereseits stehe ich auf dem Standpunkt, dass die Masse der Käufer Menschen sind, die wenige oder keinen Plan von der Materie haben. Wenn man an der Optimierungswut was ändern will, muss man IMHO dafür sorgen, dass genau diese Leute ihr Kaufverhalten überdenken und auch die Redakteure von 08/15 Blättern wie PC-Welt und Konsorten, die aber den wohl größten Impact beim (Nichtfach-) Publikum haben, müssen erreicht und überzeugt werden, dass die die Problematik auch in ihren Artikeln breit ansprechen. Erst wenn es dort ebnfalls kritisch ausgebreitet wird, wird VIELLEICHT ein Umdenken bei den Herstellern passieren.
Nur glaube ich, dass viele dieser Redakteure einen ähnlichen technischen Wissensstand haben, wie z.B. ich, und mit dem ist es nicht so weit her. Deswegen denke ich, dass man versuchen sollte, mit gut verständlichen Artikeln sowohl innerhalb der eigenen Möglichkeiten "die Masse" aber auch eben diese Redakteure zu erreichen, die einen großen Impact haben (die dann ihrerseits die echte Masse erreichen). Da diese (zumindest ihrem Output nach zu urteilen) nicht sehr weit weg vom DAU zu sein scheinen, müssten meines Erachtens auch die Artikel DAU-verträglich sein.
Anyway. Die Diskussion scheint (hier) vorbei zu sein, die vorhandenen Standpunkte sind wohl dargelegt. Prinzipiell im Auge behalten würde ich dieses Thema aber schon ganz gern.
Grüße
Ice =A=
2005-07-21, 10:21:15
Ähm, auf die Gefahr hin, mich unbeliebt zu machen:
Kann jemand mal bitte eine kurze Zusammenfassung dieses Threads geben? Das Thema interessiert mich sehr, aber 43 Seiten, da les ich ja morgen noch... :)
zeckensack
2005-07-21, 10:30:02
Gaestle,
Richtig anschaulich und leicht verständlich wird's, wenn es um die Texturqualität wird, leider erst im bewegten Bild, und das ist in Printmedien nur mittels Video-Beilage (und damit nicht mehr direkt im Artikel) möglich. Die Webmaster wiederum scheuen mehrheitlich die Bandbreitenkosten.
Die animierten GIFs von Mr. Lolman (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=146879&highlight=tenebrae) fand ich da schon sehr ansprechend. Das sollte schnellstmöglich Nachahmer finden :)
Der Leser ist spätestens dann gearscht, wenn er selbst Mängel feststellt (was auch "DAUs" ab und an gelingt, wenn diese Mängel nur groß genug sind) nachdem er sich ein neues teures Spielzeug geleistet hat. Davor kriegt er nur Standbilder zu sehen. Und da tendiert die Masse dazu, das "schärfere" Standbild für das bessere zu halten.
Selbst wenn sie's eigentlich besser wissen sollten ... Beispiel (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=3278721#post3278721). IMO völlig unglaublich (man beachte hierbei das Thread-Thema!) aber trotzdem wahr, und garnicht alt.
Das ist jetzt weniger allgemein meine Erwartung von vernünftigem Technik-Journalismus, sondern speziell mein Anliegen in Bezug auf die momentan stattfindende Texturfilterverarsche.
Jedes Review das eine Aussage über die Bildqualität machen möchte soll gefälligst bewegte Bilder mitliefern!
zeckensack
2005-07-21, 10:35:56
Also wenn es Leistung bringt und richtig funktioniert, ja bitte. Ansonsten, egal ob Bug oder Vorsatz, nein danke.Um's kurz zu machen: das ist keine "Optimierung", die du wirklich haben möchtest.
Mir ist auch keine Hardware bekannt, die das so macht. Das ganze war ein Gedankenexperiment, wie man einen (sehr dreisten) Trick der N64-Texturfilter ein klein wenig verbessern könnte.
Bei Vorsatz kann man eh nichts machen ausser nicht kaufen. Wenn es ein Bug ist, kann man zumindest darauf hoffen, dass es per Treiber gefixt bzw umgangen werden kann. Andernfalls gilt auch hier, nicht kaufen.Ja. Hoffentlich weiß man schon vorher Bescheid. So langsam fange ich an, das Fernabsatzgesetz sinnvoll zu finden.Mit dem 77.72 ist es ja beim NV40 besser geworden, da bleibt zumindest die Hoffnung bestehen dass das gleiche auch beim G70 gilt. :/Echt? Habe ich noch garnicht probiert.
Betrifft das nur die Treiberstandards, oder ist auch HQ ohne "Optimierungen" schöner geworden?
Bzw noch viel wichtiger: nur ganz besonders *hust* gut unterstützte Spiele wie zB UT2k4, oder generell?
Garnicht beachten, ich war nur kurz verwirrt :ugly:
Quad-U
2005-07-21, 10:50:45
Zur Texturfilterung würde ich liebend gerne einen neuen Artikel schreiben. Das Thema ist interessant. Davon halten mich zwei Dinge ab: Erstens kostet das unheimlich viel Zeit. Zweitens versteht den Artikel kaum jemand. Denn wenn ich zur LOD-Formel komme muss ich voraussetzen, dass der Leser weiß, was der Logarithmus ist. Außerdem muss er in der Binärdarstellung von Zahlen fit sein.
Natürlich könnte man, wenn man sich wirklich viel Zeit nimmt und die Mühe macht, all sowas auch für Otto Normalverbraucher (jedoch nicht für den DAU) verständlich schreiben. Doch wer lohnt einem die Mühe?Bitte schreib' ihn auf alle Fälle! Es gibt im Netz sooo wenig zum Thema in deutscher Sprache. Der Artikel ist ja auch in zwei Jahren noch abrufbar, da verstehen ihn dann vielleicht auch die, welche heute noch DAUs sind. Für Leute mit mehr Verstand und wenig Zeit (z.B. ich) wäre ein so ein Artikel wie Balsam auf die durch oberflächliches, un-/halbwahres Geschreibsel geschundene Seele!
Nur glaube ich, dass viele dieser Redakteure einen ähnlichen technischen Wissensstand haben, wie z.B. ich, und mit dem ist es nicht so weit her. Deswegen denke ich, dass man versuchen sollte, mit gut verständlichen Artikeln sowohl innerhalb der eigenen Möglichkeiten "die Masse" aber auch eben diese Redakteure zu erreichen, die einen großen Impact haben (die dann ihrerseits die echte Masse erreichen). Da diese (zumindest ihrem Output nach zu urteilen) nicht sehr weit weg vom DAU zu sein scheinen, müssten meines Erachtens auch die Artikel DAU-verträglich sein.Es ist schon ein Graus, dass gerade einige Fachredaktuere zu arrogant (oder zu dumm?) sind, sich in die Materie einzuarbeiten!
Vielleicht kann der Artikel ja zunächst recht Insider-mäßig sein. Wenn die Gedanken auf diese Art aber erst einmal sortiert sind, kann er ja einen zweiten, kurzen Artikel als Ergänzung schreiben, der es den DAUs u.U. näher bringen kann.
Hauwech
2005-07-21, 11:34:59
Um's kurz zu machen: das ist keine "Optimierung", die du wirklich haben möchtest.
Mir ist auch keine Hardware bekannt, die das so macht. Das ganze war ein Gedankenexperiment, wie man einen (sehr dreisten) Trick der N64-Texturfilter ein klein wenig verbessern könnte.
Ja. Hoffentlich weiß man schon vorher Bescheid. So langsam fange ich an, das Fernabsatzgesetz sinnvoll zu finden.Echt? Habe ich noch garnicht probiert.
Betrifft das nur die Treiberstandards, oder ist auch HQ ohne "Optimierungen" schöner geworden?
Bzw noch viel wichtiger: nur ganz besonders *hust* gut unterstützte Spiele wie zB UT2k4, oder generell?
Also wenn das wirklich keine "Optimierung" ist die man haben moechte, dann hoffe ich mal ganz stark, dass das wirklich nur ein Bug ist.
Mit dem 77.72 keine Ahnung, ich habe kein NV40. Wenn ich nicht ganz doof bin, hat das zumindest Mr. Lolman in diesem Thread gesagt (Posting #613). Demnach haben Coda und reunion festgestellt, dass es in HQ mit dem 77.72 anscheinend weniger flimmert.
Im Nvidia Forum oben im Sticky wird das Flimmern mit dem 77.76 zwar kaum angesprochen aber gefixt scheint es noch nicht zu sein. Dafuer ist jetzt der beruechtigte Overlaybug weg. ;)
Mr. Lolman
2005-07-21, 12:56:32
Weil mir grad ganz fad ist, gibts neue animierte gifs (von den z.T. schon bekannten Q3a Videos). Optimierungen waren bei NV deaktiviert, bei ATi @ default, Treiber: Cat. 5.6 und 77.62.
ATi 9500@pro, 640x480 4xAA/16xAF, 30MB 7zip (http://rapidshare.de/files/2641777/ati_4xAA_16xAF.7z.html)___ 6800 GT, 640x480 4xAA/16xAF, HQ, 30MB 7zip (http://rapidshare.de/files/2643138/nv_4xAA_16xAF_HQ.7z.html)____ 6800GT, 640x480 4xAA/16xAF, Q, 30MB 7zip (http://rapidshare.de/files/2642240/nv_4xAA_16xAF.7z.html)______
http://img306.imageshack.us/img306/8826/ati0hz.gif http://img306.imageshack.us/img306/6320/nv3yc.gif http://img334.imageshack.us/img334/6652/nvq3sc.gif
zeckensack
2005-07-21, 12:56:43
Also wenn das wirklich keine "Optimierung" ist die man haben moechte, dann hoffe ich mal ganz stark, dass das wirklich nur ein Bug ist.Ährm ... das zitierte hatte mit NV40/G70/wasauchimmerfürPC garnichts zu tun. Es ging um's N64, einen dort eingebauten Texturfilter-Cheat, und die Frage ob man das nicht hätte besser machen können.
Mit dem 77.72 keine Ahnung, ich habe kein NV40. Wenn ich nicht ganz doof bin, hat das zumindest Mr. Lolman in diesem Thread gesagt (Posting #613). Demnach haben Coda und reunion festgestellt, dass es in HQ mit dem 77.72 anscheinend weniger flimmert.Vergiss es :redface:
Ich Dussel habe mich verlesen, bzw FW77.72 mit FW77.76 verwechselt. FW77.72 habe ich schon ausgiebig selbst benutzt.
reunion
2005-07-21, 13:08:08
Eine auf NV44 basierend 6200 hat nur 75Mio Transistoren.
Die 143Mio. 6200er sind defekte 6600er und "Abfallentsorgung" kann nicht unrentabel sein ;)
Hm, ein Quad weniger reduziert die Transistorenanzahl um 68mio?
Wie das?
Hm, ein Quad weniger reduziert die Transistorenanzahl um 68mio?
Wie das?
Indem gleich noch zwei ROPs komplett entsorgt, die beiden verbliebenen um ihre Z-/Stencil-Optimierung und die Fähigkeit zu FP16-Blending beschnitten werden, das zweite Pixelquad entfernt wird, die Texturfilter kein FP16-Filtering mehr können, SLi entfernt wird und zusätzlich so ziemlich sämtliche Kompressionen entfernt werden, die FSAA erst (schön und) schnell machen.
reunion
2005-07-21, 13:29:02
Indem gleich noch zwei ROPs komplett entsorgt, die beiden verbliebenen um ihre Z-/Stencil-Optimierung und die Fähigkeit zu FP16-Blending beschnitten werden, das zweite Pixelquad entfernt wird, die Texturfilter kein FP16-Filtering mehr können, SLi entfernt wird und zusätzlich so ziemlich sämtliche Kompressionen entfernt werden, die FSAA erst (schön und) schnell machen.
Danke.
Trotzdem ziemlich wenig, wenn man bedenkt, dass eine X300 genau so viele in anspruch nimmt.
Ja, wobei ich mich auf knackig-genau 75M für die 6200 nicht festlegen wollen würde. Immerhin hat sie ja auch noch einen Vertexshaderkanal mehr als die X300.
Jesus
2005-07-21, 13:38:04
Weil mir grad ganz fad ist, gibts neue animierte gifs (von den z.T. schon bekannten Q3a Videos). Optimierungen waren bei NV deaktiviert, bei ATi @ default, Treiber: Cat. 5.6 und 77.62....
... kann nix downloaden. :(
deekey777
2005-07-21, 13:40:53
Weil mir grad ganz fad ist, gibts neue animierte gifs (von den z.T. schon bekannten Q3a Videos). Optimierungen waren bei NV deaktiviert, bei ATi @ default, Treiber: Cat. 5.6 und 77.62.
ATi 9500@pro, 640x480 4xAA/16xAF, 30MB 7zip (http://rapidshare.de/files/2641777/...A_16xAF.7z.html)___ 6800 GT, 640x480 4xAA/16xAF, HQ, 30MB 7zip (http://rapidshare.de/files/2643138/...6xAF_HQ.7z.html)____ 6800GT, 640x480 4xAA/16xAF, Q, 30MB 7zip (http://rapidshare.de/files/2642240/...A_16xAF.7z.html)______
http://img306.imageshack.us/img306/8826/ati0hz.gif http://img306.imageshack.us/img306/6320/nv3yc.gif http://img334.imageshack.us/img334/6652/nvq3sc.gif
Ist das fließende Lava? ;(
Das ist ja furchtbar.
Mr. Lolman
2005-07-21, 13:44:11
... kann nix downloaden. :(
Jetzt sollts gehen...
HajottV
2005-07-21, 14:01:12
Weil mir grad ganz fad ist, gibts neue animierte gifs (von den z.T. schon bekannten Q3a Videos). Optimierungen waren bei NV deaktiviert, bei ATi @ default, Treiber: Cat. 5.6 und 77.62.
Danke! Das ist doch mal ein echter Augenöffner! :up:
Joerg
Mr. Lolman
2005-07-21, 14:04:02
Ist das fließende Lava? ;(
Das ist ja furchtbar.
Nö das is Texturflimmern von der Textur aus Kais Texturefix, das so richtig schön sichtbar ist, wenn man geduckt mit timescale 0.1 und 25fps in q3dm15 vowärtsläuft. (gif: 20 Bilder @ 16.67 fps) Angenommen man läuft mit 125 fps durch die Gegend bekommt man jedes 2 Bild vom gif zu Gesicht, nur 15x schneller X-D
BTW:
6800GT 640x480, 4xAA/16xAF, 77.62 HQ__________6800GT 640x480, 4xAA/16xAF, 77.76 HQ__________6800GT, 640x480 4xAA/16xAF, 77.76 default______
http://img306.imageshack.us/img306/6320/nv3yc.gif http://img345.imageshack.us/img345/5710/hq77769ic.gif http://img345.imageshack.us/img345/8628/default77761jd.gif
Die Formatiererei ist fast mühseliger als das gif-basteln
:rolleyes:
Seraf
2005-07-21, 14:09:20
Nö das is Texturflimmern von der Textur aus Kais Texturefix, das so richtig schön sichtbar ist, wenn man geduckt mit timescale 0.1 und 25fps in q3dm15 vowärtsläuft. (gif: 20 Bilder @ 16.67 fps) Angenommen man läuft mit 125 fps durch die Gegend bekommt man jedes 2 Bild vom gif zu Gesicht, nur 15x schneller X-D
BTW:
6800GT 640x480, 4xAA/16xAF, 77.62 HQ__________6800GT 640x480, 4xAA/16xAF, 77.76 HQ__________6800GT, 640x480 4xAA/16xAF, 77.76 default______
http://img306.imageshack.us/img306/6320/nv3yc.gif http://img345.imageshack.us/img345/5710/hq77769ic.gif http://img345.imageshack.us/img345/8628/default77761jd.gif
Die Formatiererei ist fast mühseliger als das gif-basteln
:rolleyes:
Igitt!
Bilinearer Filter!
Oder ist das Brilinear? Sieht mir dafür aber fast zu ausgeprägt aus.
Für default Einstellunegn auf jedem Fall zum kotzen.
Im Hintergrund sieht die Rüstung und Health ganz anders aus.
Mr. Lolman
2005-07-21, 14:14:36
Das is v.A. NVs Mipfilter Optimierung. Default ist sie beim 77.76 zwar nicht aktiv, aber sobald man mal die AA/AF Einstellungen ändert, schaltet sie sich ein...
biAF kann aber viel besser aussehen (R300 4xAA/16xbiAF):
http://img79.exs.cx/img79/5682/q3a51bi7mj.th.jpg (http://img79.exs.cx/my.php?loc=img79&image=q3a51bi7mj.jpg)
Im Hintergrund sieht die Rüstung und Health ganz anders aus.
Das liegt daran, dass sich die Dinger drehen und die Aufnahmen nicht 100% gleichzeitig beginnen. Kann man zwar noch optimieren, aber dann wirds wirklich fitzelig. Die Bewegung jedoch, ist jedesmal die Selbe.
Die Idee läuft darauf hinaus, genau das zu ändern.... und wenn man im 90° gedreht ausliest, hat man immer 1 Texel pur und dann die Mischfarbe zweier Texel alternierend? Da sage ich "nein, danke".
Wenn man an der Optimierungswut was ändern will, muss man IMHO dafür sorgen, dass genau diese Leute ihr Kaufverhalten überdenken und auch die Redakteure von 08/15 Blättern wie PC-Welt und Konsorten, die aber den wohl größten Impact beim (Nichtfach-) Publikum haben, müssen erreicht und überzeugt werden, dass die die Problematik auch in ihren Artikeln breit ansprechen. Erst wenn es dort ebnfalls kritisch ausgebreitet wird, wird VIELLEICHT ein Umdenken bei den Herstellern passieren.
Nur glaube ich, dass viele dieser Redakteure einen ähnlichen technischen Wissensstand haben, wie z.B. ich, und mit dem ist es nicht so weit her. Deswegen denke ich, dass man versuchen sollte, mit gut verständlichen Artikeln sowohl innerhalb der eigenen Möglichkeiten "die Masse" aber auch eben diese Redakteure zu erreichen, die einen großen Impact haben (die dann ihrerseits die echte Masse erreichen). Da diese (zumindest ihrem Output nach zu urteilen) nicht sehr weit weg vom DAU zu sein scheinen, müssten meines Erachtens auch die Artikel DAU-verträglich sein.Der normale Leser muss nur wissen, dass das G70-AF auch auf HQ flimmer-anfällig ist.
Das is v.A. NVs Mipfilter Optimierung. Default ist sie beim 77.76 zwar nicht aktiv, aber sobald man mal die AA/AF Einstellungen ändert, schaltet sie sich ein...
biAF kann aber viel besser aussehen (R300 4xAA/16xbiAF):
http://img79.exs.cx/img79/5682/q3a51bi7mj.th.jpg (http://img79.exs.cx/my.php?loc=img79&image=q3a51bi7mj.jpg)Das ist schlechteres bi-AF, da man das MIP-Band nicht so gut sieht. Korrekte bilineare Filterung muss bei solchen Texturen ein deutliches MIP-Band zeigen.
Mr. Lolman
2005-07-21, 14:20:07
Das ist schlechteres bi-AF, da man das MIP-Band nicht so gut sieht. Korrekte bilineare Filterung muss bei solchen Texturen ein deutliches MIP-Band zeigen.
Es sieht besser aus und irritiert nicht so. Außerdem nennt es ATi Performance AF, und verstößt somit nicht gegen irgendwelche (bi)AF Regeln...
Jesus
2005-07-21, 14:20:11
Das ist schlechteres bi-AF, da man das MIP-Band nicht so gut sieht. Korrekte bilineare Filterung muss bei solchen Texturen ein deutliches MIP-Band zeigen.
ROFL, so kann mans natürlich auch ausdrücken. :biggrin:
Demirug
2005-07-21, 14:22:25
Nö das is Texturflimmern von der Textur aus Kais Texturefix, das so richtig schön sichtbar ist, wenn man geduckt mit timescale 0.1 und 25fps in q3dm15 vowärtsläuft. (gif: 20 Bilder @ 16.67 fps) Angenommen man läuft mit 125 fps durch die Gegend bekommt man jedes 2 Bild vom gif zu Gesicht, nur 15x schneller X-D
Hast du zufällig die Textur die für den Boden benutzt wird auch als einzelne Datei? Ich frage mich nämlich wo die ganzen weißen Pixel in der Fläche herkommen?
Mr. Lolman
2005-07-21, 14:23:22
Hast du zufällig die Textur die für den Boden benutzt wird auch als einzelne Datei? Ich frage mich nämlich wo die ganzen weißen Pixel in der Fläche herkommen?
Ich suchs dir raus :)
Mr. Lolman
2005-07-21, 14:30:26
http://img290.imageshack.us/img290/7344/metalbridge028eh.jpg (http://www.imageshack.us)
Es sieht besser aus und irritiert nicht so. Außerdem nennt es ATi Performance AF, und verstößt somit nicht gegen irgendwelche (bi)AF Regeln...
Allerdings wird das Mip-Band nur unter bestimmten Bedingungen "unterdrückt/gedithert". Häufig genug bekommt man auch Mip-Banding zu sehen. "Performance AF" ist es natürlich nur, wenn es im Treiber eingestellt wird.
Bei der Textur ist es kein Wunder, dass auch HQ noch flimmert.
Demirug
2005-07-21, 14:35:40
Danke, diese Texture muß flimmern. Muß später mal den Schärfegrad ausrechnen lassen. Der wird sehr hoch sein.
Mr. Lolman
2005-07-21, 14:38:40
Stimmt zwar, aber anhand von solchen Texturen lassen sich halt wunderbar die Qualitätsunterschiede beim AF sichtbar machen.
zeckensack
2005-07-21, 14:42:09
Nö das is Texturflimmern von der Textur aus Kais Texturefix, das so richtig schön sichtbar ist, wenn man geduckt mit timescale 0.1 und 25fps in q3dm15 vowärtsläuft. (gif: 20 Bilder @ 16.67 fps) Angenommen man läuft mit 125 fps durch die Gegend bekommt man jedes 2 Bild vom gif zu Gesicht, nur 15x schneller X-D
BTW:
6800GT 640x480, 4xAA/16xAF, 77.62 HQ__________6800GT 640x480, 4xAA/16xAF, 77.76 HQ__________6800GT, 640x480 4xAA/16xAF, 77.76 default______
http://img306.imageshack.us/img306/6320/nv3yc.gif http://img345.imageshack.us/img345/5710/hq77769ic.gif http://img345.imageshack.us/img345/8628/default77761jd.gif
Die Formatiererei ist fast mühseliger als das gif-basteln
:rolleyes: Dh Q ist mit FW77.76 noch schlechter geworden!? :crazy2:
Oder hattest du da selbst (aus Versehen) einmal Bilinear und einmal Trilinear eingestellt? :|
Mr. Lolman
2005-07-21, 14:45:26
Dh Q ist mit FW77.76 noch schlechter geworden!? :crazy2:
Sagen wir "default" ist schlechter geworden. (war beim 76.62 Q ohne Optimierungen und mit dem 77.76 ists Q mit allen Optimierungen). Q ohne Optimierungen hab ich mir (noch) nicht näher angesehen
ShadowXX
2005-07-21, 14:58:09
Sagen wir "default" ist schlechter geworden. (war beim 76.62 Q ohne Optimierungen und mit dem 77.76 ists Q mit allen Optimierungen). Q ohne Optimierungen hab ich mir (noch) nicht näher angesehen
Du solltest aber vielleicht doch besser gleiches mit gleichem Vergleichen.
Bei mir war z.B. beim Einspielen des 77.76 als Default bei Q nur BriFiltering eingeschaltet.
Mr. Lolman
2005-07-21, 15:18:37
Bei mir war z.B. beim Einspielen des 77.76 als Default bei Q nur BriFiltering eingeschaltet.
Auch wenn du wieder default (Restore) wählst?
6800GT, 640x480 4xAA/16xAF, 77.62 Q __________ 6800GT, 640x480 4xAA/16xAF, 77.76 Q __________ 6800GT, 640x480 4xAA/16xAF, 77.76 Q, default Textures
http://img334.imageshack.us/img334/6652/nvq3sc.gif http://img323.imageshack.us/img323/1176/q77764hy.gif http://img290.imageshack.us/img290/2217/q77764ac.gif
Danke.
Trotzdem ziemlich wenig, wenn man bedenkt, dass eine X300 genau so viele in anspruch nimmt.Bei der 6200 wurden ja auch die ROPs arg gekürzt (kein FP-Blending). Außerdem sind es nur 2 statt 4 wie bei der X300.
ShadowXX
2005-07-21, 15:40:43
Auch wenn du wieder default (Restore) wählst?
Müsst ich mal ausprobieren....
Allerdings war vor dem Einspielen die Einstellung auf HQ mit allem aus + Clamp.
Hatte also mit den Einstellungen nach dem einspielen, Q + Bri und kein Clamp, nicht viel zu tun.
Aber ich werde es heute Abend mal ausprobieren, was passiert wenn ich den Restore-Button drücke.
Stimmt zwar, aber anhand von solchen Texturen lassen sich halt wunderbar die Qualitätsunterschiede beim AF sichtbar machen.
Mit einer Textur, die bewußt und nachträglich überschärft wurde? (in diesem Falle von Kai - wo is der eigentlich abgeblieben)
Ich glaube, bei sowas kommt ein möglichst ungenauer Texturfilter gerade zupass, um auftretendes Flimmern zu unterdrücken.
Schau doch mal in Far Cry im Research-Level bei dieser sich bewegenden Maschine - da sind schöne Flimmer-Speculars am Boden auf dem Nirosta per Game-default. :)
Mr. Lolman
2005-07-21, 16:09:03
Mit einer Textur, die bewußt und nachträglich überschärft wurde? (in diesem Falle von Kai - wo is der eigentlich abgeblieben)
Ich glaube, bei sowas kommt ein möglichst ungenauer Texturfilter gerade zupass, um auftretendes Flimmern zu unterdrücken.
Schau doch mal in Far Cry im Research-Level bei dieser sich bewegenden Maschine - da sind schöne Flimmer-Speculars am Boden auf dem Nirosta per Game-default. :)
Deswegen hab ich im letzten Vergleich auch Nv Q mit Standard Textures mitreingenommen. Flimmert genauso...
Mit einer Textur, die bewußt und nachträglich überschärft wurde? (in diesem Falle von Kai - wo is der eigentlich abgeblieben)
Genau. Und Kai ist in Frankreich.
Ich glaube, bei sowas kommt ein möglichst ungenauer Texturfilter gerade zupass, um auftretendes Flimmern zu unterdrücken.
Aha, ein Texturfilte rist also zwangsläufig ungenau, wenn es nicht flimmert?
Schau doch mal in Far Cry im Research-Level bei dieser sich bewegenden Maschine - da sind schöne Flimmer-Speculars am Boden auf dem Nirosta per Game-default. :)
Was hat das mit AF zu tun? Specular Lights werden nicht gefiltert.
Demirug
2005-07-21, 17:13:36
Was hat das mit AF zu tun? Specular Lights werden nicht gefiltert.
Aber die Bump und falls verwendet die Specular Decal Map dafür.
Mit einer Textur, die bewußt und nachträglich überschärft wurde? (in diesem Falle von Kai - wo is der eigentlich abgeblieben)
Ich glaube, bei sowas kommt ein möglichst ungenauer Texturfilter gerade zupass, um auftretendes Flimmern zu unterdrücken.
Schau doch mal in Far Cry im Research-Level bei dieser sich bewegenden Maschine - da sind schöne Flimmer-Speculars am Boden auf dem Nirosta per Game-default. :)
So ist das, Flimmern ist mitnichten immer der Hardware/Treiber anzulasten. Bei Max Payne 2 gibts in den Optionen einen Schärferegler für die Texturen, da bekommt man es garantiert zum Flimmern.
BTW: Kai weilt beruflich in Frankreich. Wenn ich mich nicht irre, arbeitet er dort für Blizzard.
Piffan
2005-07-21, 17:21:31
So ist das, Flimmern ist mitnichten immer der Hardware/Treiber anzulasten. Bei Max Payne 2 gibts in den Optionen einen Schärferegler für die Texturen, da bekommt man es garantiert zum Flimmern.
BTW: Kai weilt beruflich in Frankreich. Wenn ich mich nicht irre, arbeitet er dort für Blizzard.
KÄKSE!
Aber die Bump und falls verwendet die Specular Decal Map dafür.
Und was hat man davon? Am Ende flimmert es doch, wenn es geshadert wurde.
Demirug
2005-07-21, 17:42:51
Und was hat man davon? Am Ende flimmert es doch, wenn es geshadert wurde.
Ich verstehe die Frage nicht.
Ich wollte nur darauf hinweisen das auch beim Specular Light Texturen noch im Spiel sind.
Die Formatiererei ist fast mühseliger als das gif-basteln
Mach dir nicht die Mühe mit den Unterstrichen... es passt mit unterschiedlichen Browsern und Schriften sowieso nicht. ;)
Sehe ich das richtig dass 77.76 default wesentlich schlechter als 77.76 Q ist?
Mr. Lolman
2005-07-21, 18:27:13
Mach dir nicht die Mühe mit den Unterstrichen... es passt mit unterschiedlichen Browsern und Schriften sowieso nicht. ;)
Mist. Ich hätts mir eigentlich denken können. :rolleyes:
Sehe ich das richtig dass 77.76 default wesentlich schlechter als 77.76 Q ist?
Ja. Zumindest bei mir: 77.76 default = Qualität + alle Optimierungen
http://img290.imageshack.us/img290/7344/metalbridge028eh.jpg (http://www.imageshack.us)
dass das ding flimmert ist aber echt kein wunder, da gibt es ja schon heftigstes flimmern wenn ich im browser scrolle ;)
Stimmt zwar, aber anhand von solchen Texturen lassen sich halt wunderbar die Qualitätsunterschiede beim AF sichtbar machen.
nicht zwangsläufig. ein standardmäßig zu unscharf filterndes AF (z.b. durch pos LOD etc.) würde in diesem fall besser aussehen, obwohl es bei "normalen" texturen schlechter aussieht.
Ja. Zumindest bei mir: 77.76 default = Qualität + alle Optimierungen
bei mir nicht, standardmäßig ist bei mir Q+Tri Opt+Sample Opt eingestellt.
die mip-optimierung ist (wie auch bei allen anderen treibern) deaktiviert.
Mr. Lolman
2005-07-21, 19:21:40
dass das ding flimmert ist aber echt kein wunder, da gibt es ja schon heftigstes flimmern wenn ich im browser scrolle ;)
Durch Lightmaps wird die Schärfe aber eh deutlich abgeschwächt. Außerdem flimmerts ja auch mit Standardtextures.
nicht zwangsläufig. ein standardmäßig zu unscharf filterndes AF (z.b. durch pos LOD etc.) würde in diesem fall besser aussehen, obwohl es bei "normalen" texturen schlechter aussieht.
Nein, dann dann würde es nur unschärfer werden. Außerdem versteh ich nicht, was man da schön reden will. ATi AF und NV HQ sind ca. gleich scharf und flimmern auch gleich stark. Und ob das jetzt ne flimmrige Textur oder ein hoch frequenter Shader ist, ist ja auch wurscht...
bei mir nicht, standardmäßig ist bei mir Q+Tri Opt+Sample Opt eingestellt.
die mip-optimierung ist (wie auch bei allen anderen treibern) deaktiviert.
Dann stell mal AA/AF auf irgendeinen Wert (zB 4xAA/16xAF) und schau ob die Mip-Optimierung immernoch deaktiviert ist.
Quasar
2005-07-21, 19:50:20
Genau. Und Kai ist in Frankreich.
Ah, gut zu hören, daß ihm nix passiert ist.
Aha, ein Texturfilte rist also zwangsläufig ungenau, wenn es nicht flimmert?
Nein, das habe ich nicht gesagt. Ich sagte, daß ich glaube, daß bei sowas ein möglichst ungenauer Texturfilter gerade zupass kommt, um auftretendes Flimmern zu unterdrücken.
Dein Schlußfolgerung hieraus ist dieselbe, als wenn ich sage, daß Wasser flüssig sei und du infolgedessen nun alle Flüssigkeiten für Wasser hältst.
Quasar
2005-07-21, 19:51:21
Ja. Zumindest bei mir: 77.76 default = Qualität + alle Optimierungen
Das ist bei mir auch so.
Allerdings stelle ich die Optimierungen direkt nach dem Umschalten auf Erweiterte Optionen und VSync off ab.
Demirug
2005-07-21, 20:12:30
Durch Lightmaps wird die Schärfe aber eh deutlich abgeschwächt. Außerdem flimmerts ja auch mit Standardtextures.
Lightmaps können auch noch zusätzliche flimmerkanten erzeugen.
Nein, dann dann würde es nur unschärfer werden. Außerdem versteh ich nicht, was man da schön reden will. ATi AF und NV HQ sind ca. gleich scharf und flimmern auch gleich stark. Und ob das jetzt ne flimmrige Textur oder ein hoch frequenter Shader ist, ist ja auch wurscht...
Was ist das eigentlich für ein dunkler Fleck im Hintergrund auf dem Boden? Der ist bei nV irgendwie deutlicher zu sehen als bei ATI.
Dann stell mal AA/AF auf irgendeinen Wert (zB 4xAA/16xAF) und schau ob die Mip-Optimierung immernoch deaktiviert ist.
stimmt, da hat sich wohl ein bug ins CP eingeschlichen, da ich AF wenn möglich über die anwendung oder über aTuner steuere ist es mir bis jetzt nicht aufgefallen.
ATi AF und NV HQ sind ca. gleich scharf und flimmern auch gleich stark. Und ob das jetzt ne flimmrige Textur oder ein hoch frequenter Shader ist, ist ja auch wurscht...
imo ist NV´s HQ auf diesen shots (subjektiv) etwas besser (das flimmern beginnt etwas später als bei ATI), dicht gefolgt von der qualität von ATI. Q bei nvidia steht außer diskussion da bekommt man ja selbst auf diesen mini-bildern augenschmerzen, wie das in vollbild aussieht will ich garnicht wissen.
Was ist das eigentlich für ein dunkler Fleck im Hintergrund auf dem Boden? Der ist bei nV irgendwie deutlicher zu sehen als bei ATI.
Das scheint mir so ein Jump-Pad zu sein.
Was ist das eigentlich für ein dunkler Fleck im Hintergrund auf dem Boden? Der ist bei nV irgendwie deutlicher zu sehen als bei ATI.Die Textur der Jumppads ist animiert, deshalb ist das verschieden auf den Screenshots.
Noch nie Quake 3 gespielt?
Demirug
2005-07-21, 21:02:36
Die Textur der Jumppads ist animiert, deshalb ist das verschieden auf den Screenshots.
Noch nie Quake 3 gespielt?
Bei FPS bekomme ich Motion sickness also lasse ich das.
Mr. Lolman
2005-07-24, 18:02:15
Und, gibts schon irgendwelche Pläne für NV HQ vs ATi Benchmarks (auch mit NV40)?
Oder sollte man jetzt schon mit der Jammerei abgeschlossen haben und sich ein weiteres Mal der Willkür der IHVS fügen?
Demirug
2005-07-24, 18:22:29
Und, gibts schon irgendwelche Pläne für NV HQ vs ATi Benchmarks (auch mit NV40)?
Dann aber bitte bei ATI mit AI Off.
Ich sehe nur das Problem das wenn das dann Schule macht die maximal erreichbare Qualität noch stärker abgesenkt wird.
Mr. Lolman
2005-07-24, 18:29:56
Dann aber bitte bei ATI mit AI Off.
Ich sehe nur das Problem das wenn das dann Schule macht die maximal erreichbare Qualität noch stärker abgesenkt wird.
Gerne, sofern sich ein BQ Unterschied zw. AI on und off feststellen lässt. Ansonsten sollte man ruhig mit AI on benchen. Und wenn NV die Qualität tatsächlich noch weiter absenken sollte, kann man ja auch ATi Treibereinstellungen auf höhere Leistung umstellen.
Demirug
2005-07-24, 18:38:42
Gerne, sofern sich ein BQ Unterschied zw. AI on und off feststellen lässt. Ansonsten sollte man ruhig mit AI on benchen.
Ab wann haben wir denn einen BQ Unterschied? Ich vermissen eben nach wie vor den objektiven Massstab. Was für eine subjektive Sache natürlich schwer ist.
Und wenn NV die Qualität tatsächlich noch weiter absenken sollte, kann man ja auch ATi Treibereinstellungen auf höhere Leistung umstellen.
Jetzt stelle ATI aber bitte nicht als unschuldig hin.
Razor
2005-07-24, 18:41:59
Danke, diese Texture muß flimmern. Muß später mal den Schärfegrad ausrechnen lassen. Der wird sehr hoch sein.Seh' ich auch so...
Kein Dev würde den Consumern so etwas antun.
Stimmt zwar, aber anhand von solchen Texturen lassen sich halt wunderbar die Qualitätsunterschiede beim AF sichtbar machen.Blödsinn...
Vermutlich hast Du lange nach einer solchen Textur gesucht, um überhaupt einen Unterschied auszumachen.
Sagen wir "default" ist schlechter geworden. (war beim 76.62 Q ohne Optimierungen und mit dem 77.76 ists Q mit allen Optimierungen). Q ohne Optimierungen hab ich mir (noch) nicht näher angesehenUnd?
Was ist dabei heraus gekommen?
Nichts?
Ohhh...
Sorry, aber dieserart Polemik kann ich mir beim besten Willen nicht verkneifen.
Razor
P.S.: Würdest Du das Gleiche an real exisitierenden Scenarien 'beweisen', wäre ich vielleicht geneigt, Dir ein wenig Objektivität zuzusprechen... so aber sind Deine Bewweise gespickt mit subjektiven Ansichten und an den Haaren herbei gezogenen 'Beweisen'.
Jesus
2005-07-24, 18:42:59
Seh' ich auch so...
Kein Dev würde den Consumern so etwas antun.
Blödsinn...
Vermutlich hast Du lange nach einer solchen Textur gesucht, um überhaupt einen Unterschied auszumachen.
Razor
Könntest du bitte aufhören uralte Sachen zu quoten die schon längst geklärt sind?
Razor
2005-07-24, 18:45:49
Könntest du bitte aufhören uralte Sachen zu quoten die schon längst geklärt sind?Uralt?
Liegt nur 2-3 Seiten zurück.
Und was soll darin bitte 'geklärt' sein?
Hat Lolman seine eigenen 'Feststellungen' zurecht gerückt?
Hmmm...
Razor
P.S.: Und es nicht einmal älter als 3 Tage...
Was also willst Du eigentlich, Jesus?
Jesus
2005-07-24, 18:51:31
Uralt?
Liegt nur 2-3 Seiten zurück.
Und was soll darin bitte 'geklärt' sein?
Hat Lolman seine eigenen 'Feststellungen' zurecht gerückt?
Hmmm...
Razor
P.S.: Und es nicht einmal älter als 3 Tage...
Was also willst Du eigentlich, Jesus?
Wenn du weiter gelesen hättest wüsstest du das es auch mit Standardtexturen flimmert. Die Stelle die du zitierst hast bezieht sich aber auf der "geschärften" die Lolman vorher verwendet hat.
Razor
2005-07-24, 18:55:32
Wenn du weiter gelesen hättest wüsstest du das es auch mit Standardtexturen flimmert. Die Stelle die du zitierst hast bezieht sich aber auf der "geschärften" die Lolman vorher verwendet hat.Und wo ist das Beipiel mit den Standard-Texturen?
Und wo sind überhaupt RealWorld-'Beweise'?
Sorry, aber das ist - wie ich schon oben schrieb - an den Haaren herbei gezogen.
Oder beschwert er sich tatsächlich, dass sich die (veränderbare) Default-Quali bei ihm verschlechtert hat?
Kann ja wohl nicht sein ernst sein...
Razor
MadManniMan
2005-07-24, 19:00:59
Und wo ist das Beipiel mit den Standard-Texturen?
Und wo sind überhaupt RealWorld-'Beweise'?
In einem Post von Lolman vor ein paar Seiten:
http://img290.imageshack.us/img290/2217/q77764ac.gif
Nicht richtig lesen, aber Hauptsache erstmal rumbrüllen, nicht wahr?
:up:
Mr. Lolman
2005-07-24, 21:30:13
Blödsinn...
Vermutlich hast Du lange nach einer solchen Textur gesucht, um überhaupt einen Unterschied auszumachen.
Nein, garnicht. Ich hab ursprünglich nach ner Textur gesucht, wo man Flimmern an nem Standbild (zumindest andeutungshalber) sichtbar machen kann, und was leicht reproduzierbar ist (die begrenzte Leistungsfähigkeit der Vergleichssystem spielt natürlich auch ein bisschen mit)
Ich hab auch kein Bock da stundenlang herumzutesten (Q3a ist schnell gestartet ;)), außerdem gibts von mir auch Farcry Screenshots die zeigen dass NVs Q mit deaktivierten Optierungen vgl zu ATi default eindeutig schlechter ist (treiberdefault sowieso). Und Zeckensack erkennt auch eine bisher unfaire Benchtaktik. Willst du dem etwa auch die Kompetenz absprechen?
BTW: Vll. mach ich auch von der BF2 Demo oder von irgend nem anderen Spiel animierte gifs. Kannst ja was vorschlagen.
Blaire
2005-07-24, 21:50:50
Sagen wir "default" ist schlechter geworden. (war beim 76.62 Q ohne Optimierungen und mit dem 77.76 ists Q mit allen Optimierungen). Q ohne Optimierungen hab ich mir (noch) nicht näher angesehen
Nope das stimmt so nicht. Die Einstellungen default sind wie beim 77.72 auch absolut identisch. Auch bei Restore Defaults.
MfG
Botcruscher
2005-07-24, 22:05:25
In einem Post von Lolman vor ein paar Seiten:
http://img290.imageshack.us/img290/2217/q77764ac.gif
Nicht richtig lesen, aber Hauptsache erstmal rumbrüllen, nicht wahr?
:up:
Scheiße das sieht ja noch bösser aus als das Video was es hier mal gab. Wie ist nun eigentlich der aktuellle Stand?
Seh' ich auch so...
Kein Dev würde den Consumern so etwas antun.Dann ist id Software also kein Dev? ;)
Seraf
2005-07-24, 23:19:28
Dann ist id Software also kein Dev? ;)
Du erwartest doch keine einsichtige Antwort.
Razor wird abstreiten das ID ein Dev ist und das Q3DM15 eine offizielle Map von Quake 3 ist. :lol:
ging es nicht um die textur, die hier aus kais texturefix für q3 gepostet wurde? kai ist doch in dem sinne kein dev.
Wenn ich mich richtig entsinne ist die Textur in den GIFs auf jedenfall die orginale.
MadManniMan
2005-07-24, 23:35:32
@Gast: Ursprünglich ging es um Kais Textur - aber wie man sieht, ist die Originaltextur nicht wirklich besser.
Du erwartest doch keine einsichtige Antwort.
Razor wird abstreiten das ID ein Dev ist und das Q3DM15 eine offizielle Map von Quake 3 ist. :lol:
Falsch, Razor wird entweder ein ganz anderes Subthema anschlagen, oder hier gar nichts mehr sagen - er ist viel zu Stolz, sowas zuzugeben.
Hat quasi was von meiner Exfreundin. Nur daß ich Razor mehr mag :| Aber das hat hier jetzt nichts zu suchen...
die, die einzeln hier gepostet wurde und auf die demirug das antwortete, was razor zitierte, ist lt. lolman aus kais texturefix. das gif mit der originaltextur reichte lolman später nach.
@Gast: Ursprünglich ging es um Kais Textur - aber wie man sieht, ist die Originaltextur nicht wirklich besser.
ich finde sie schon 'wirklich besser'.
[spoiler=2.2MB Gifs, 77.62 Q vs 77.76 Q vs. 77.76 Q mit standard Textures]
6800GT, 640x480 4xAA/16xAF, 77.76 Q __________ 6800GT, 640x480 4xAA/16xAF, 77.76 Q, default Textures
http://img323.imageshack.us/img323/1176/q77764hy.gif http://img290.imageshack.us/img290/2217/q77764ac.gif[spoiler]
MadManniMan
2005-07-24, 23:46:20
Gast, nimms mir nicht übel, aber das ist subjektives Empfinden - das Flimmern wird durch die starkkontrastigen Texturen des Texturefixes nur deutlicher und ist mit den normalen Texturen genauso da.
/Edit: Und selbst wenn mir keiner zustimmen mag - das Flimmern mit den Originaltexturen ist absolut unerträglich!
richtig, subjektives empfinden. aber das wirst du mir sicherlich auch zugestehen, nach deinem eröffnenden "nicht wirklich besser", oder?
btw, dieses "nicht wirklich" klingt nach einem grauslichen, pseudo-modernen, übersetzen anglizismus "not really".
MadManniMan
2005-07-25, 00:17:11
richtig, subjektives empfinden. aber das wirst du mir sicherlich auch zugestehen, nach deinem eröffnenden "nicht wirklich besser", oder?
Durchaus! Nur: ich möchte keine Cornflakes essen, die um den Faktor 5 weniger nach Scheiße schmecken, nur weil die Vorgänger noch schlimmer waren ;)
btw, dieses "nicht wirklich" klingt nach einem grauslichen, pseudo-modernen, übersetzen anglizismus "not really".
Indeed, davon könnte man ausgehen :D Ist in diesem Fall aber nicht so: ich als gebürtiger Vorharzer wurde an diesen Terminus bereits im zarten Alter von 5 Jahren rangeführt - und das war immerhin noch vor der Wende ;)
HotSalsa
2005-07-25, 06:47:17
Nur nochmal zur Info:
Hatte die PCGH Redaktion schon vor ner Woche über diesen Thread hier informiert und um umfassende Aufklärung im Heft gebeten inkl. großer Vergleichsscreenshots.
Die E-mail ging einmal an die Redaktion und einmal an Thilo direkt.
Da er sich hier schon dazu geäußert hat und Demi auch dran arbeitet hat es wohl etwas bewirkt.
Der Kram hier muss unbedingt in die Fachpresse um sowas in Zukunft zu vermeiden.
Meinetwegen können nV und ATI soviele Optimierungen einbauen bis das ganze Bild nur noch Matsch ist - wichtig ist ich will darüber als Kunde informiert werden und ich will es abschalten können.
Jeder User sollte selber die Option haben sich über den Treiber die Quali einzustellen die er möchte wobei dann HQ natürlich auch wirklich HQ sein muss!
Bin gespannt was dazu in der nächsten PCGH zu lesen sein wird.
Gruß aus HH
HotSalsa
Mark3Dfx
2005-07-25, 08:54:22
Ich bin auch gepannt auf die nächste oder übernächste PCGH.
HajottV
2005-07-25, 09:02:28
Nicht richtig lesen, aber Hauptsache erstmal rumbrüllen, nicht wahr?
Danke, der Spruch kommt in mein best-of. :biggrin:
Gruß
Jörg
Komisch finde ich das bei so vielen tests praktisch niemand was bemerckt und darüber berichtet hat. Der einzige test der qualitäts unterschiede beim AF bemerckt hat war auf hardware.fr leider sind diese nicht weiter darauf eingegangen.
Eigentlich wäre es doch wichtig genau solche probleme von den testern aufzudecken das ist im endeffeckt doch der ganze sinn eines grafikkarten tests dass der kunde weiss was er zu erwarten hat.
Klar kann man nvidia die schuld geben aber genau so enttäuscht bin ich von all den testern die das problem nicht bemerckt haben oder ignoriert haben.
Für mich ist das wieder einmal ein beweis dass heutige grafikkarten tests ungenügend sind um eine kauffentscheidung zu treffen da passieren einfach zu viele fehler.
richtig, subjektives empfinden. aber das wirst du mir sicherlich auch zugestehen, nach deinem eröffnenden "nicht wirklich besser", oder?
btw, dieses "nicht wirklich" klingt nach einem grauslichen, pseudo-modernen, übersetzen anglizismus "not really".Ja. Die deutsche Ensprechung ist "eigentlich nicht" und nicht "nicht wirklich".
Komisch finde ich das bei so vielen tests praktisch niemand was bemerckt und darüber berichtet hat. Der einzige test der qualitäts unterschiede beim AF bemerckt hat war auf hardware.fr leider sind diese nicht weiter darauf eingegangen.
Eigentlich wäre es doch wichtig genau solche probleme von den testern aufzudecken das ist im endeffeckt doch der ganze sinn eines grafikkarten tests dass der kunde weiss was er zu erwarten hat.
Klar kann man nvidia die schuld geben aber genau so enttäuscht bin ich von all den testern die das problem nicht bemerckt haben oder ignoriert haben.
Für mich ist das wieder einmal ein beweis dass heutige grafikkarten tests ungenügend sind um eine kauffentscheidung zu treffen da passieren einfach zu viele fehler.Wenn ich das anmerken darf: "Merken" mit einem k, nicht mit ck.
Hardware.fr scheint wirklich die einzige Seite weltweit zu sein, die das gleich im Artikel zum Launch erwähnt haben. Schon vorher habe ich über Tridam (dem Autoren) immer mit Respekt geredet, dieser Respekt ist natürlich noch gestiegen.
Ich habs mir noch gedacht ohne ck war mir aber nicht sicher habs darum so belassen :)
@Gast: Ursprünglich ging es um Kais Textur - aber wie man sieht, ist die Originaltextur nicht wirklich besser.Nun, doch.
Kais Textur-"Fix", ist, bei aller Liebe, kein "Fix", sondern Effekthascherei. Mehr Schärfe und damit mehr Aliasing. Gleiches gilt für seine Arbeit an Doom3. Kai hat sich hier bestimmt viel Arbeit gemacht, aber mehr "gute" Texturschärfe gibt es eben nicht, in dem man (in erster Näherung) nur mal einen Schärfefilter drüberlaufen lässt. ("Gute" Texturschärfe meint hier, nicht flimmrige. "Böse" Texturen flimmern ja.) Schon ID Software hat sich bei der bewussten Bodentextur ziemlich weit vorgewagt. Die Texturfilter werden an ihre Grenzen gebracht.
Demirug hat irgendwo mal eingeworfen, dass die Einstellung des Monitors entscheidend mit zum wahrnehmbaren Flimmern beiträgt. Je länger ich darüber nachdenke, desto mehr gebe ich ihm Recht. Denn bei optimaler Einstellung und sRGB-korrektem Filtering bleibt ja die Flächenhelligkeit der Textur erhalten. Einzelne Pixeln flackern weiterhin, aber es wäre weniger schlimm.
Je stärker der Kontrast benachbarter Texel, desto größer die Auswirkung von nicht sRGB-korrekter Filterung. Schon deshalb rate ich von Schärfefiltern auf die Textur ab.
Man denke sich mal eine Textur als Bild. Nun verschiebt man die Textur auf beiden Achsen um 1/2 Pixel. Dann fließen in jedes Pixel die Informationen der 4 umgebenden Texel ein. Damit gehen starke lokale Kontraste natürlich verloren – in Bewegung ergibt das Flimmern.
http://dudv.de/files/3dcf/org.png http://dudv.de/files/3dcf/offs.png
Ungefähr so sieht es aus, wenn man die Textur aus dem "Fix" mit der Abtastung mit dem 0,5-Offset vergleicht.
http://dudv.de/files/3dcf/org.png http://dudv.de/files/3dcf/offs_sRGB.png
Würde korrekt für sRGB gerechnet, sähe es etwa so aus. Die Flächenhelligkeit bliebe erhalten, aber der Unterschied von "scharf" zu "unscharf" ist natürlich weiterhin auffällig.
Wir folgern: Die gezeigte Textur ist schlecht geeignet. Was kann man nun tun? Man könnte generell nur um Faktor 2 (pro Achse) vergrößerte Texturen nutzen, und in im Faktor 2 (pro Achse) erhöhter Auflösung rendern. Das Detail pro cm² bleibe erhalten, das Flimmern wäre praktisch weg. Das kostet dermaßen Leistung, dass das impraktikabel ist. Also sollte man beim Artwork zusehen, nur "guten" Texturinhalt zu verwenden, und Schärfegrad vs. Flimmeranfälligkeit sorgfältig gegeneinander abzuwägen.
Mr. Lolman
2005-07-25, 14:08:36
Nun, doch.
Naja: http://www.forum-3dcenter.de/vbulletin/showthread.php?p=3295938#post3295938
Naja: http://www.forum-3dcenter.de/vbulletin/showthread.php?p=3295938#post3295938Was sagt der Link jetzt? Dass Unterfilterung in Flimmern resultiert?
Mr. Lolman
2005-07-25, 14:24:29
Was sagt der Link jetzt? Dass Unterfilterung in Flimmern resultiert?
Nein, sondern dass die Originaltextur (die Rechte) nicht viel besser ist.
Nein, sondern dass die Originaltextur (die Rechte) nicht viel besser ist.Ich sehe beim Link nur Vergleiche mit Q, also mit Unterfilterung. Wenn man Texturen auf "Bösartigkeit" vergleicht, bitte mit korrekter Filterung.
MadManniMan
2005-07-25, 15:29:23
Ich sehe beim Link nur Vergleiche mit Q, also mit Unterfilterung. Wenn man Texturen auf "Bösartigkeit" vergleicht, bitte mit korrekter Filterung.
Es geht doch aber gerade um die Problematik der Defaulteinstellung - ich werd trotzdem in HQ zocken.
Mr. Lolman
2005-07-25, 15:41:04
Ich sehe beim Link nur Vergleiche mit Q, also mit Unterfilterung. Wenn man Texturen auf "Bösartigkeit" vergleicht, bitte mit korrekter Filterung.
:rolleyes:
Man sieht doch im Vergleich mit Q, dass die zusätzliche Texturschärfe (von Kais Fix) nur minimalst an der Flimmeranfälligkeit beteiligt ist, aber HQ mit default Textures soll ja auch kein Geheimnis bleiben, deswegen:
Links: 640x480 4xAA/16xAF, 77.76 HQ, default Textures
Rechts: 640x480 4xAA/16xAF, 77.76 HQ, Kais Texturefix
http://img322.imageshack.us/img322/1481/hq7776default4rr.gif http://img345.imageshack.us/img345/5710/hq77769ic.gif
/edit: Fuck jetzt hab ich mir unabsichtlich meine Q3.cfg zerstört und deswegen stimmt der Vergleich nicht mehr. Der Linke Screenshot ist ein bisschen zu hell. Egal. Q3a ist ja eh viel zu alt und die gewählte Vergleichsszene viel zu willkürlich, deswegen schlag ich vor, dass ihr einfach ein Spiel aus folgender Liste auswählt und ich bastle dann neue Gifs (andere Spieledemos gehen natürlich auch, Liste zeigt nur die aktuell installierten Spiele)
Battlefield 2 Demo
Black & White
Boiling Point
Call of Duty
Dethkarz
Doom1
Doom2
DOOMIII
DRIV3R
Far Cry
fifa2005
FlatOut
Forsaken Demo
GothicII
GTA San Andreas
GTA2
GTAViceCity
Half - Life2
HdR Die Rückkehr des Königs
Hitman
jDoom
Keen
Kingpin
Kreed Techdemo
LFS S2 Demo Alpha_L
Mafia
Manhunt
Max Payne
Max Payne 2
MDK2 Demo
Medal of Honor Allied Assault
Midtown Madness 2
Morrowind
Motocross Madness 2
MotoGP2
Need for Speed Underground 2
Need For Speed V
Operation Flashpoint
Painkiller
Pariah Singleplayer Demo
Postal2
Quake
Quake III Arena
Quake2
Ralli Sport Challenge
Red Faction
Return to Castle Wolfenstein
Serious Sam
Serious Sam 2
Soldier of Fortune II
Splinter Cell
Star Wars Jedi Knight Jedi Academy Demo
Star Wars JK II Jedi Outcast
Stunts
TmSunriseDemoMag
Tony Hawks 2
Tron 2.0 Demo
UltimaIX
Undying
UnrealTournament
UT2004
Virtua Tennis
World Championship Snooker 2004
WWE RAW
XIII Demo
/edit:
Es geht doch aber gerade um die Problematik der Defaulteinstellung - ich werd trotzdem in HQ zocken.
Recht hast du :up:
Je stärker der Kontrast benachbarter Texel, desto größer die Auswirkung von nicht sRGB-korrekter Filterung. Schon deshalb rate ich von Schärfefiltern auf die Textur ab.
Man denke sich mal eine Textur als Bild. Nun verschiebt man die Textur auf beiden Achsen um 1/2 Pixel. Dann fließen in jedes Pixel die Informationen der 4 umgebenden Texel ein. Damit gehen starke lokale Kontraste natürlich verloren – in Bewegung ergibt das Flimmern.
http://dudv.de/files/3dcf/org.png http://dudv.de/files/3dcf/offs.png
Ungefähr so sieht es aus, wenn man die Textur aus dem "Fix" mit der Abtastung mit dem 0,5-Offset vergleicht.
http://dudv.de/files/3dcf/org.png http://dudv.de/files/3dcf/offs_sRGB.png
Würde korrekt für sRGB gerechnet, sähe es etwa so aus. Die Flächenhelligkeit bliebe erhalten, aber der Unterschied von "scharf" zu "unscharf" ist natürlich weiterhin auffällig.
ehrlich gesagt finde ich das "korrekte" bild deutlich zu hell, während das "falsche" ein wenig zu dunkel aber deutlich näher am origninal ist.
wurde manhunt nicht beschlagnahmt? böses spiel für dt. foren. ;)
ehrlich gesagt finde ich das "korrekte" bild deutlich zu hell, während das "falsche" ein wenig zu dunkel aber deutlich näher am origninal ist.
Tja, das ist eben der Unterschied zwischen Theorie und Praxis.
Es geht doch aber gerade um die Problematik der Defaulteinstellung - ich werd trotzdem in HQ zocken.Die Default-Einstellung ist mir Wurst, wenn sie nichts taugt. Die derzeitige NV40-Q-Einstellung taugt nichts. Wenn ich Texturen auf Flimmeranfälligkeit vergleiche, wähle ich doch keinen kaputten anisotropen Filter.
Wer AF einstellen kann (geht für Q3 ja nur via Treiber) kann auch HQ aktivieren. Deshalb: Q ignorieren und NV40-Karten in HQ benchen. Ist zwar ggü. der Radeon unfair, die z. B. nur brilinear filtert, aber ich würde eh nicht auf die Idee kommen, NV40 vs. Radeon zu benchen.
:rolleyes:
Man sieht doch im Vergleich mit Q, dass die zusätzliche Texturschärfe (von Kais Fix) nur minimalst an der Flimmeranfälligkeit beteiligt ist, aber HQ mit default Textures soll ja auch kein Geheimnis bleiben, deswegen:Bei Kais "Fix" sehe ich, dass es in Bewegung flimmern muss (habe hier nur ein Standbild?), beim Original sehe ich ein "Schwimmen" in der Textur.
ehrlich gesagt finde ich das "korrekte" bild deutlich zu hell, während das "falsche" ein wenig zu dunkel aber deutlich näher am origninal ist.Dann ist dein Monitor falsch eingestellt, du solltest den Gamma-Wert runterregeln :) Das fälschlicherweise linear gerechnete Bild (oben) sollte deutlich dunkler sein.
Tja, das ist eben der Unterschied zwischen Theorie und Praxis.In der Praxis sollte der Monitor sRGB-Inhalte korrekt anzeigen. Ist das nicht der Fall, bringt sRGB-korrekte Filterung natürlich kein besseres Ergebnis. Das Beispiel für sRGB-korrekte Filterung ist auch nur eine Näherung, und ich habe mich dabei auch noch vertan (denn 1/2,2 ist ja 0,45 und nicht 0,54. Sorry.) Werde gleich mal ein etwas besseres Bild uppen. edit: Das Bild wurde ersetzt.
Mr. Lolman
2005-07-25, 17:08:26
Dann ist dein Monitor falsch eingestellt, du solltest den Gamma-Wert runterregeln :)
Imo reichts auch die Augen etwas zusammenzuzwinkern.
Imo reichts auch die Augen etwas zusammenzuzwinkern.Damit sinkt die Flächenhelligkeit ja nicht, und das scheint beim Gast das Problem zu sein. In dem man weiter wegguckt oder die Augenlider zusammenkneift, erkennt man natürlich die Flächenhelligkeit besser. Das rechts unten sollte immer noch (minimal) zu dunkel sein, aber um korrekt zu rechnen müsste ich ne eigene Anwendung schreiben, dazu habe ich derzeit keine Zeit.
Mr. Lolman
2005-07-25, 17:15:44
Bei Kais "Fix" sehe ich, dass es in Bewegung flimmern muss (habe hier nur ein Standbild?), beim Original sehe ich ein "Schwimmen" in der Textur.
Imo ist das Flimmern in seiner Intensität gleich stark. Man merkt auch, dass es auf der rechten Bildseite nur einen kleinen Bereich gibt, der kaum flimmert. (auf halber Höhe zw. dem "Mach" und der (rechts) oberen Begrenzung des Bodens. Dieser Bereich ist bei der Standardtextur genausogroß wie bei Kais geschärfter.
Mr. Lolman
2005-07-25, 17:18:02
Damit sinkt die Flächenhelligkeit ja nicht, und das scheint beim Gast das Problem zu sein. In dem man weiter wegguckt oder die Augenlider zusammenkneift, erkennt man natürlich die Flächenhelligkeit besser. Das rechts unten sollte immer noch (minimal) zu dunkel sein, aber um korrekt zu rechnen müsste ich ne eigene Anwendung schreiben, dazu habe ich derzeit keine Zeit.
Am ersten Blick kams mir auch deutlich zu hell vor. Wobei ich der Meinung bin, dass es insgesamt nicht zu dunkel ist sondern wirklich minimal zu hell.
Imo ist das Flimmern in seiner Intensität gleich stark. Man merkt auch, dass es auf der rechten Bildseite nur einen kleinen Bereich gibt, der kaum flimmert. (auf halber Höhe zw. dem "Mach" und der (rechts) oberen Begrenzung des Bodens. Dieser Bereich ist bei der Standardtextur genausogroß wie bei Kais geschärfter.
Das sehe ich ehrlich gesagt etwas anders.
Mr. Lolman
2005-07-25, 17:45:45
Das sehe ich ehrlich gesagt etwas anders.
Wie denn?
Mr. Lolman
2005-07-25, 18:10:10
Wer AF einstellen kann (geht für Q3 ja nur via Treiber) kann auch HQ aktivieren. Deshalb: Q ignorieren und NV40-Karten in HQ benchen. Ist zwar ggü. der Radeon unfair, die z. B. nur brilinear filtert, aber ich würde eh nicht auf die Idee kommen, NV40 vs. Radeon zu benchen.
Kann man ATis Brilinearität nicht auf Screenshots sichtbar machen?
Seraf
2005-07-25, 18:19:06
Kann man ATis Brilinearität nicht auf Screenshots sichtbar machen?
Differenzmethode.
Du vergleichst einen R350 Screenshot mit dem einer neuen ATI Karte.
http://www.computerbase.de/artikel/hardware/grafikkarten/2004/bericht_versteckspiele_atis_texturfilter/4/
In der Praxis sollte der Monitor sRGB-Inhalte korrekt anzeigen. Ist das nicht der Fall, bringt sRGB-korrekte Filterung natürlich kein besseres Ergebnis. Das Beispiel für sRGB-korrekte Filterung ist auch nur eine Näherung, und ich habe mich dabei auch noch vertan (denn 1/2,2 ist ja 0,45 und nicht 0,54. Sorry.) Werde gleich mal ein etwas besseres Bild uppen. edit: Das Bild wurde ersetzt.
ok, mit dem neuen bild ist das ganze schon wesentlich besser.
ich hab jetzt mal den display-wizard von nvidia gestartet und durchgeführt, herausgekommen ist ein gamma von 0,88, kann das überhaupt stimmen, irgendwie reden alle immer von werten >1?
In einem Post von Lolman vor ein paar Seiten:
http://img290.imageshack.us/img290/2217/q77764ac.gif
Nicht richtig lesen, aber Hauptsache erstmal rumbrüllen, nicht wahr?
:up:
Könnte jemand das mit einer 7800GTX @HQ machen?
Ist doch das Thema?
ok, mit dem neuen bild ist das ganze schon wesentlich besser.
ich hab jetzt mal den display-wizard von nvidia gestartet und durchgeführt, herausgekommen ist ein gamma von 0,88, kann das überhaupt stimmen, irgendwie reden alle immer von werten >1?Das hängt von der Monitor-Einstellung ab. Mein Monitor hat bei der Gamma 1,0-Korrektur im Treiber (fast) genau eine Gamma 2,2-Kennlinie, folgt also dem sRGB-Standard.
Wie denn?
Ich finde das Flimmern mit der geschärften Textur noch etwas schlimmer.
MadManniMan
2005-07-26, 04:04:59
Ich finde das Flimmern mit der geschärften Textur noch etwas schlimmer.
Schon richtig, da hier höhere Kontrastwechsel stattfinden, empfindet mans wohl ohne besondere Aufmerksamkeit - und die schenken wir dem gerade - als noch schlimmer.
Der Grad der ... hm ... "Bewegung" :uflower: innerhalb der Bodentextur ist jedoch bei beiden Varianten gleich :|
Kann ich mal fragen wie die gezeigten animierten gifs genau erstellt worden sind und wie repräsentativ diese sind von was man auf dem vollbild monitor sieht?
Mr. Lolman
2005-07-26, 15:20:04
Kann ich mal fragen wie die gezeigten animierten gifs genau erstellt worden sind und wie repräsentativ diese sind von was man auf dem vollbild monitor sieht?
Quake3: max Details, 640x480, 4xAA/16xAF, timescale 0.1, devmap q3dm15: Ducken -> Fraps Aufnahme starten (25fps) -> 1-2sec. vorwärts laufen
=======================================================
VirtualdubMod: Starten, avi laden, alle frames ohne Bewegung löschen -> Alle Frames >20 löschen -> abspeichern.
=======================================================
Adobe Imageready: Avi laden. Canvas Size: 310/340 Pixel
x x x
0 x x
x x x
-> Canvas Size: 288/192 Pixel
x x x
x x x
x x 0
-> Framedelay auf 0.06 setzen.
-> als optimiertes gif abspeichern. Die kleine Bereichswahl hat einzig und allein den Grund das 8bit-Dithering für die gif Datei minimal zu halten.
=======================================================
20frames in 640x480 (2.9MB) (http://s40.yousendit.com/d.aspx?id=1F2VO1KG8K36K0YASB3KDOQKJT)
-> als optimiertes gif abspeichern. Die kleine Bereichswahl hat einzig und allein den Grund das 8bit-Dithering für die gif Datei minimal zu halten.
=======================================================
20frames in 640x480 (2.9MB) (http://s40.yousendit.com/d.aspx?id=1F2VO1KG8K36K0YASB3KDOQKJT)Man sieht in den Wolken ziemlich gut die Ditherung. Die sieht man auf dem Boden nicht, weil das durch die Textur versteckt wird – klar ist aber, dass die Ditherung auch dort vorhanden ist. Bei aller Liebe – GIFs halte ich für schlecht geeignet. Man braucht schon die volle Farbauflösung.
Mr. Lolman
2005-07-26, 16:14:38
Man sieht in den Wolken ziemlich gut die Ditherung. Die sieht man auf dem Boden nicht, weil das durch die Textur versteckt wird – klar ist aber, dass die Ditherung auch dort vorhanden ist. Bei aller Liebe – GIFs halte ich für schlecht geeignet. Man braucht schon die volle Farbauflösung.
Du hast absolut recht. Andererseits versprech ich dir, dass du mit freiem Auge keinen Unterschied (zw. 32bit und 8bit) in den einzelnen Gif Auschnitten erkennen wirst. Das is ja der Mist bei Gif-vergleichen, dass man nur Szenen nehmen kann, in denen die Farbanzahl gering genug ist...
Du hast absolut recht. Andererseits versprech ich dir, dass du mit freiem Auge keinen Unterschied (zw. 32bit und 8bit) in den einzelnen Gif Auschnitten erkennen wirst.Wie meinst du das? Ich kann in jedem Einzelbild das Dithering sehen.
Wenn schon Vergleiche, dann bitte mit einem verlustfreien 24-Bit-Farben-Video-Codec. Wenn's geht, auch in voller Bildschirmauflösung (z. B. 1024x768.) Und mit voller Framerate. Sonst wird das Erlebnis am Monitor nicht korrekt wiedergegeben.
Ich überlege allerdings, ob man nicht einen BodenTextur-Slider schreiben könnte, oder besser noch einen sechseckigen Tunnel, den man mit einer eigenen Textur laden kann. Andererseits könnten Xmas und Demirug dafür auch einfach ihre Tester anpassen, mit einstellbarer Texturbewegungsgeschwindigkeit. Dann sieht man auch schön das Flimmern, je nach Textur und so genannter "Optimierung".
Ich hab das mal probiert mit meiner karte. Ich hab leider dieses adobe programm nicht aber ich kann ja auch die avi's vergleichen.
Mr. Lolman
2005-07-26, 17:47:35
Wie meinst du das? Ich kann in jedem Einzelbild das Dithering sehen.
Ich mein die kleinen 288x192 Fitzelausschnitte.
Wenn schon Vergleiche, dann bitte mit einem verlustfreien 24-Bit-Farben-Video-Codec. Wenn's geht, auch in voller Bildschirmauflösung (z. B. 1024x768.) Und mit voller Framerate. Sonst wird das Erlebnis am Monitor nicht korrekt wiedergegeben.
Die Videos gibts bereits. 3x30MB 7zip Files (unkomprimiert 3x100MB) Die hab ich schon lang, bevor ich die gifs gebastelt hab, auf rapidshare hochgeladen gehabt.
/edit. Aber nur in 640x480. Ich hab nix, was ne höhere Auflösung capturen könnte.
/edit2: Die volle Framerate kann man auch vergessen. Ich kenn nix was 100fps bei 1024x768 capturen könnte. Außerdem wären die Files dann ernom groß...
Mr. Lolman
2005-07-26, 17:49:31
Ich hab das mal probiert mit meiner karte. Ich hab leider dieses adobe programm nicht aber ich kann ja auch die avi's vergleichen.
Das Video müsst ~9MB groß sein. Du könntest es ja mal wo hochladen (http://domino.lx.ro/)
Ich hab ja nur ne x800pro , ich wollt nur mal sehen ob es einen unterschied gibt zwischen AI off und low.
Was ich sagen muss is das mit timescale 0.1 sieht man das flimmern doch extrem während man mit normalen geschwindigkeit es kaum wahrnimmt oder doch nur sehr leicht wenn man sich darauf konzentriert.
Was die vids anbelangt könnte man dann auch mit xvid mit 100% qualität komprimieren dann hat nur noch ~1MB und kann immernoch gut vergleichen da nach meinen augen kaum qualität verloren geht
Ich mein die kleinen 288x192 Fitzelausschnitte.
Das verringert das Problem, welches dennoch bestehen bleibt. Du kannst ja mal das Malprogramm deiner Wahl durchzählen lassen, wie viele einzigartige Farben das 288x192 Pixel große Bild enthält. Wahrscheinlich deutlich mehr als 256.
Die Videos gibts bereits. 3x30MB 7zip Files (unkomprimiert 3x100MB) Die hab ich schon lang, bevor ich die gifs gebastelt hab, auf rapidshare hochgeladen gehabt.
/edit. Aber nur in 640x480. Ich hab nix, was ne höhere Auflösung capturen könnte.
/edit2: Die volle Framerate kann man auch vergessen. Ich kenn nix was 100fps bei 1024x768 capturen könnte. Außerdem wären die Files dann ernom groß...Solche Videos sind besser als nichts, das ist klar. Doch diese Videos geben nicht die ganze Wahrheit wieder. Wobei ich ja Kais so genanntem Texture-"Fix" kritisch gegenüber stehe. Man sollte mit "gutartigen" Texturen testen, oder gleich reine Synthies machen. Da steht aber auch immer die Frage im Raum ab wann es flimmert.
Ich will es natürlich möglichst ruhig – und trotzdem detailreich. Um beides möglichst gleichzeitig zu schaffen, braucht man Texturfilter die viel Arbeit pro Texel verrichten. Man braucht keine Bemühungen, das letzte Fitzelchen Geschwindigkeit rauszuholen und dabei die Bildqualität zu vernachlässigen. Ich finde noch immer keine Worte, um NVs absoluten Blödsinn – schlimm genug, dass sie den ATI-Winkel-Stil imitiert haben – in geeigneter Weise darzustellen.
Natürlich hat die aktuelle Situation ein bisschen vom Radeon 9700-Launch. Jubel über die Geschwindigkeit bei 8x und 16x AF. Kaum jemand achtete auf vergleichbare Qualität. Jetzt jubeln alle über die Geschwindigkeit der 7800 GTX, und über das AF liest man im Web beinahe nichts. When will they ever learn?
Ich hab' zum Thema Flimmern auch noch etwas aktuelles: Die MotoGP 3 Demo (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=236907&highlight=motogp). Der Asphalt und auch die Grastextur flimmern aus nächster Nähe extrem, selbst bei High Quality -- nicht mal 16xSS kann das ganz wegbekommen. Nun frage ich mich, ob das am von mir momentan (ja, immer noch) genutzten Treiber liegt, der mittlerweile steinalt ist und offensichtlich keinen Clamp-Schalter besitzt: ForceWare 70.41.
Könnte das mal jemand mit einem neuen Treiber und 6800 ausprobieren? :)
Die 9700-Shots von Spasstiger sehen zumindest sauber aus ... aber auch nicht sinderlich scharf ...
MfG,
Raff
Demirug
2005-07-26, 21:06:32
Ich will es natürlich möglichst ruhig – und trotzdem detailreich. Um beides möglichst gleichzeitig zu schaffen, braucht man Texturfilter die viel Arbeit pro Texel verrichten. Man braucht keine Bemühungen, das letzte Fitzelchen Geschwindigkeit rauszuholen und dabei die Bildqualität zu vernachlässigen. Ich finde noch immer keine Worte, um NVs absoluten Blödsinn – schlimm genug, dass sie den ATI-Winkel-Stil imitiert haben – in geeigneter Weise darzustellen.
Es ist immer ein Kampf zwischen der Bildschärfe eines Frames und der temporalen Schwingung im Bild bzw der ersten Ableitung davon.
Natürlich hat die aktuelle Situation ein bisschen vom Radeon 9700-Launch. Jubel über die Geschwindigkeit bei 8x und 16x AF. Kaum jemand achtete auf vergleichbare Qualität. Jetzt jubeln alle über die Geschwindigkeit der 7800 GTX, und über das AF liest man im Web beinahe nichts. When will they ever learn?
Nicht solange man die Bildqualität nicht mit einem Benchmark messen kann und am Ende einen Wert für einen Balken bekommt. Aber selbst dann bekommt man die Komponenten welche die Bildqualität im bewegten Bild bestimmen nur schwer in einen einzigen Wert. Denn um die temporale Schwingung zu dämpfen muss man zwingend Bildschärfe in einem Frame opfern.
Aber selbst dann sind die Schärfe und Swingungwerte nur vergleichbar wenn man jeweils die gleiche Sequenz (mit allen Frames) prüft. Nimmt man unterschiedliche Spiele oder Demos ist es nicht mehr vergleichbar.
Blaire
2005-07-26, 21:35:28
Ich hab' zum Thema Flimmern auch noch etwas aktuelles: Die MotoGP 3 Demo (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=236907&highlight=motogp). Der Asphalt und auch die Grastextur flimmern aus nächster Nähe extrem, selbst bei High Quality -- nicht mal 16xSS kann das ganz wegbekommen. Nun frage ich mich, ob das am von mir momentan (ja, immer noch) genutzten Treiber liegt, der mittlerweile steinalt ist und offensichtlich keinen Clamp-Schalter besitzt: ForceWare 70.41.
Könnte das mal jemand mit einem neuen Treiber und 6800 ausprobieren? :)
Die 9700-Shots von Spasstiger sehen zumindest sauber aus ... aber auch nicht sinderlich scharf ...
MfG,
Raff
Sehe nix von flimmern. Wo genau? Den "Blur"mist hab ich ausgestellt viel zu übertrieben , ansonsten rennt das Game wie Butter 1600x1200 8xSSAA/TRSSAA 16xAF konstant 60 fps.
Es gibt auch einen Texturschärferegler im Menü sehr vorbildlich so kann jeder seinen Geschmack anpassen, ich habs aber bisher auf default Settings belassen.
Edit: Sogar 16xAA ist problemlos möglich und die FPS fällt nie unter die 60 fps Marke. Von Flimmern seh ich garnix.
Alles klar, dann liegt es ausschließlich daran, dass ich die Schärfe ganz nach rechts gestellt habe. Der Clamp sollte doch dafür sorgen, dass es nicht unter 0 geht, oder? Und da der nicht da ist ... Blur habe ich übrigens auch aus -- lieber AA statt übertriebener Unschärfe.
Könntest du mal mit maximaler Schärfe testen?
MfG,
Raff
Könnte das mal jemand mit einem neuen Treiber und 6800 ausprobieren? :)Ich kann nur mit einer 6600 dienen.
Die 9700-Shots von Spasstiger sehen zumindest sauber aus ... aber auch nicht sinderlich scharf ...Du willst es immer so "scharf" haben *zusammenzuck*.
(Der letzte Satz ist halb im Spaß gemeint.)
Könntest du mal mit maximaler Schärfe testen?Das ist wohl nur son LOD-Bias-Regler wie in Max Payne. Will sagen, das muss dann flimmern.
Hrhr, ja, will ich. Aber im Sinne von GF4-AF ...
MfG,
Raff
P.S.: Die 6600 tut's auch. :tongue:
Es ist immer ein Kampf zwischen der Bildschärfe eines Frames und der temporalen Schwingung im Bild bzw der ersten Ableitung davon.
Nicht solange man die Bildqualität nicht mit einem Benchmark messen kann und am Ende einen Wert für einen Balken bekommt. Aber selbst dann bekommt man die Komponenten welche die Bildqualität im bewegten Bild bestimmen nur schwer in einen einzigen Wert. Denn um die temporale Schwingung zu dämpfen muss man zwingend Bildschärfe in einem Frame opfern.
Aber selbst dann sind die Schärfe und Swingungwerte nur vergleichbar wenn man jeweils die gleiche Sequenz (mit allen Frames) prüft. Nimmt man unterschiedliche Spiele oder Demos ist es nicht mehr vergleichbar.Genau. Und wie wir wissen ist das Problem eines Filtermarks das hässliche Wort "Applikationserkennung". Dennoch kann ich dich nur ermuntern, so einen Mark zu schreiben. Wir brauchen eine allgemein anerkannte* Messmethode.
* Von den Reviewern, nicht zwingend von den IHVs.
Blaire
2005-07-26, 22:11:10
Jo, auch mit Schärferegler voll aufgedreht sehe ich kein Flimmern und ich hab wirklich drauf geachtet.
Hab aber auch mit 1600x1200 16xAA (TRSSAA und GC)/16xAF HQ getestet.
http://img150.imageshack.us/img150/9513/motogpdemo20050726220705455nc.jpg
Alles klar, dann liegt es ausschließlich daran, dass ich die Schärfe ganz nach rechts gestellt habe.
das war schon bei den beiden älteren motogp demos so. selber schalter, selbe wirkung.
Demirug
2005-07-26, 22:16:28
Genau. Und wie wir wissen ist das Problem eines Filtermarks das hässliche Wort "Applikationserkennung". Dennoch kann ich dich nur ermuntern, so einen Mark zu schreiben. Wir brauchen eine allgemein anerkannte* Messmethode.
* Von den Reviewern, nicht zwingend von den IHVs.
Ich will eigentlich sogar das der Treiber die "Applikation" erkennt. Als UT, BF2 oder als das Spiel das jeweils den Content für den Test geliefert hat Bei jedem Synth wird ein IHV sowieso die Praxsisrelevanz abstreiten.
PS: OT: Hast du kein Bild von Asuka auf dem sie etwas freundlicher schaut?
Jesus
2005-07-26, 22:18:15
Jo, auch mit Schärferegler voll aufgedreht sehe ich kein Flimmern und ich hab wirklich drauf geachtet.
Hab aber auch mit 1600x1200 16xAA (TRSSAA und GC)/16xAF HQ getestet.
http://img150.imageshack.us/img150/9513/motogpdemo20050726220705455nc.jpg
Flimmer bei mir definitiv in 1280 mit allem High was High geht (und scharf). Etwa ab der Mitte des Bildes. (Die zweit-schärfste Einstellung flimmert allerdings nicht mehr). (AI=default)
Blaire
2005-07-26, 22:26:07
Flimmer bei mir definitiv in 1280 mit allem High was High geht (und scharf). Etwa ab der Mitte des Bildes. (Die zweit-schärfste Einstellung flimmert allerdings nicht mehr). (AI=default)
Bei mir nix. Das einzigste was mir nicht gefällt ist das zerhackte Vsync. Kann auch gerne ein FRAPS Video machen, falls gewünscht. Leider hab ich keinen Webspace. Wenn jemand weiß wo man kostenlos Videos hochladen kann, bin ich dabei.
jojo4u
2005-07-26, 22:29:17
Bei aller Liebe – GIFs halte ich für schlecht geeignet. Man braucht schon die volle Farbauflösung.
Zu MNG als Alternative siehe auch:
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=236782
Ich will eigentlich sogar das der Treiber die "Applikation" erkennt. Als UT, BF2 oder als das Spiel das jeweils den Content für den Test geliefert hat Bei jedem Synth wird ein IHV sowieso die Praxsisrelevanz abstreiten.Den Content darfst du halt nicht einfach verwenden, wenn du es veröffentlichen willst :(
Demirug
2005-07-26, 22:56:04
Den Content darfst du halt nicht einfach verwenden, wenn du es veröffentlichen willst :(
Aber das Programm um sich selbst aus dem Content einen generischen Benchmark zu erzeugen schon.
D.h. das Program startet z.B. UT2004 loggt die spezifische Init-Sequenz und dann einen Frame um den dann auf die Bildqualität zu untersuchen?
Demirug
2005-07-26, 23:06:55
D.h. das Program startet z.B. UT2004 loggt die spezifische Init-Sequenz und dann einen Frame um den dann auf die Bildqualität zu untersuchen?
Eine Frame reicht nicht wenn man Temporale Filtereffekte untersuchen will. Da muss man schon ein paar mehr haben.
Ich will eigentlich sogar das der Treiber die "Applikation" erkennt. Als UT, BF2 oder als das Spiel das jeweils den Content für den Test geliefert hat Bei jedem Synth wird ein IHV sowieso die Praxsisrelevanz abstreiten.Wenn du das schaffst ... Respekt.
Bei einem Nicht-Synthie sehe ich allerdings ein Problem: Wer definiert, wie das "wahre" Bild auszusehen hat? Dann auch die räumlichen Probleme: Differenzvergleiche taugen imo nicht viel – was ist, wenn zwar die richtigen Texel genommen werden, nur immer einige wenige Pixel versetzt?
Dann die ewigen Ausreden der IHVs: Das Bild sehe vielleicht anders aus, aber es sehe nicht schlechter aus. Ich denke, auf das was der IHV dazu sagt, muss man nicht viel geben. Hauptsache, die Reviewer berücksichtigen messbare Filterqualität.
PS: OT: Hast du kein Bild von Asuka auf dem sie etwas freundlicher schaut?Da hat sie doch noch vergleichsweise gute Laune.
Wenn du das schaffst ... Respekt.Hm, wenn die Treiber nur an der Befehlssequenz merken was es für ein Spiel ist wird es nicht so problematisch sein.
Aber wie die App-Detection genau funktioniert ist mir eh sehr schleierhaft.
Demirug
2005-07-27, 07:42:42
Bei einem Nicht-Synthie sehe ich allerdings ein Problem: Wer definiert, wie das "wahre" Bild auszusehen hat? Dann auch die räumlichen Probleme: Differenzvergleiche taugen imo nicht viel – was ist, wenn zwar die richtigen Texel genommen werden, nur immer einige wenige Pixel versetzt?
Es gibt kein "wahres" Bild was auch das große Problem beim IQM (Image Quality Measurement) ist. Dort nutzt man nämlich gerne Double-ended Lösungen die den SOLL und IST Zustand vergleichen. Für einen Vergleich von Videocodecs hat sich das auch bewährt da man dort die Signalstrecke so aufbauen kann das man am Ende zwei Bilder (deswegen Double ended) zum vergleichen hat. Für die Messung bei gerenderten Bildern kommt das allerdings nicht in Frage weil hier eine Single-ended Problematik vorliegt. Die Referenz fehlt einfach.
Beim Single-ended IQM erfasst man daher zuerst einmal nur Kenngrößen des Datenstroms. Da wir unkomprimierte RGB Bilder haben brauchen wir uns um Datenraten keinen Gedanken zu machen. Es spielt also nur der Bildinhalt eine Rolle. Es ist nun relative einfach Basiskenngrößen wie die Bildschärfe, Bildunruhe sowie die Veränderungskonstanz zu ermitteln. Sowohl für die Farbkanäle wie auch für die Luminezenz. All diese Werte sind jedoch stark von der dargestellten Szene abhängig. So ist in der Regel die Bildunruhe bei einem schnellen Rennspiel viel höher als bei einem Rollenspiel. Eine Betrachtung der Kenngrößen unabhängig von der Szene ist also nutzlos. Aus diesem Grund braucht man auch bei Single ended Lösungen ein zweites Signal. Entweder die Zielwerte für die Kenngrößen oder einen zweiten Satz der Kenngrößen einer alternativen Methode um die gleiche Sequenz zu erzeugen und darzustellen. Zielwerte fallen hier wieder aus weil es keine Referenz gibt. Bleibt nur noch der relative Vergleich alternativer Lösungen. Da die Kenngrößen aus einer Informationskompression von relativen Werten entstehen sind leichte Unterschiede solange sie über das gesamte Bild gleichförmig sind egal.
Ein solcher Vergleich erfordert jedoch das an einer Stelle der Bilderzeugung alle Lösungen mit den gleichen Ausgangsdaten versorgt werden. Der letzte Punkt an dem das erreicht werden kann ist die Datenübergabe an den Treiber. Aus Gründen der Vereinfachung sollte man beim Vergleich von 3D Lösungen allerdings noch eine Ebene höher ansetzten und das Interface der API als gemeinsamen Punkt festlegen. Das macht es jedoch unbedingt erforderlich alle temporalen Effekte des Spiels das als Basis dient zu eliminieren um sicher zu stellen das alle Bilderzeugungslösungen die exakt gleiche Datengrundlage erhalten. Da man diese Verhalten bei nicht jedem Spiel erzwingen kann muss eine universelle Lösung einen Datenstrom aufzeichnen und bei Bedarf wiedergeben können.
Problematisch ist dabei das die Bilderzeugungslösungen bei ihrer Arbeit die Quelle des Datenstroms berücksichtigen können. Hier muss also zusätzlich versucht werden die Eigenschaften der originalen Datenquelle zu emulieren.
doom1
2005-07-27, 09:42:27
Was ist den hiermit??
Bei HL² sackschnell mit SLIAA16 (bin ich gersde am zoggen)aber.......
http://techreport.com/etc/2005q3/sli-aa/index.x?pg=1
MarcWessels
2005-07-28, 23:20:04
Jens Neuschäfer von nVidia ist gerade bei GIGA und die tollen "Journalisten" labern nur begeistert was von immer besserer und realistischerer Grafik auf der "schnellsten Graka der Welt" blah blah... :|
Wie wär's, wenn sie die Gelegenheit beim Schopfe packten und den nVidia-Fritzen fragen, inwieweit die Unterfilterung denn die Grafikqualität und Realitätsnähe verbessert? :|
Nö, stattdessen labern sie was vom tollen AA und AF (ohne natürlich zu fragen, warum es winkelabhängig ist, wo doch die Karte soooooo schnell ist) und kriechen dem Herrn Neuschäfer in den Hintern. :rolleyes:
Jens Neuschäfer von nVidia ist gerade bei GIGA und die tollen "Journalisten" labern nur begeistert was von immer besserer und realistischerer Grafik auf der "schnellsten Graka der Welt" blah blah... :|
Wie wär's, wenn sie die Gelegenheit beim Schopfe packten und den nVidia-Fritzen fragen, inwieweit die Unterfilterung denn die Grafikqualität und Realitätsnähe verbessern? :|
Nö, stattdessen labern sie was vom tollen AA und AF (ohne natürlich zu fragen, warum es winkelabhängig ist, wo doch die Karte soooooo schnell ist) und kriechen dem Herrn Neuschäfer in den Hintern. :rolleyes:
zustimm,ich kenne die wahrheit aber die grosse masse hat keine und glaubt sowas :(
Jens Neuschäfer von nVidia ist gerade bei GIGA und die tollen "Journalisten" labern nur begeistert was von immer besserer und realistischerer Grafik auf der "schnellsten Graka der Welt" blah blah... :|
Wie wär's, wenn sie die Gelegenheit beim Schopfe packten und den nVidia-Fritzen fragen, inwieweit die Unterfilterung denn die Grafikqualität und Realitätsnähe verbessern? :|
Nö, stattdessen labern sie was vom tollen AA und AF (ohne natürlich zu fragen, warum es winkelabhängig ist, wo doch die Karte soooooo schnell ist) und kriechen dem Herrn Neuschäfer in den Hintern. :rolleyes:
Ich glaube kaum das die GIGA jungs eine ahnung von der momentan etwas fragwürdigen qualität des AF der gf7800GTX haben.
Und auch wenn sie den nvidia mann darüber fragen würden , der wüsste wahrscheinlich nicht einmal was die meinen.
Mark3Dfx
2005-07-29, 04:38:28
PR Termin
Das sagt alles
Hallo,
ich habe noch nie bessere Stand-Up Komiker im TV gesehen ;) Ich hoffe für eine bessere Qualität bei R520 machen die 3D-Webseiten mal endlich Druck!
Das Thema wird von fast allen mit Samthandschuhen angepackt, was spricht endlich gegen eine News hier? CB hält sich auch zurück! Ich sehe diese Diskussion nur in Foren.
Aus diesem Grund habe ich ein These aufgestellt, die sich zwar zuerst UNREAL anhört, aber bevor ich in Würselen mit ULTRA-KILL auftauche, hier meine These.
Hardcore-Gamer haben die dumme Angewohnheit täglich von 2D (zB. Foren-Seiten) und 3D (Games) ständig hin und her zu wechselen und das ist der Auslöser für einen BUG im Gehirn. Unser Gehirn ist überfordert und um dieses uns MITZUTEILEN FLIMMERT es uns was vor. Die ganzen Bildfehler beruhen auf einem visuellen SUPERGAU! ;)
Deshalb mein Rat, täglich 6 Stunden vor die Flimmerkiste und ATHS, LEO und andere sollten sich langsam Gedanken darüber machen, wie Sie uns täglich auch hier im Forum unsere FLIMMER-RATION verabreichen könnten. Hier und da ein bissel winkelabhängiges AF und wir alle sind wieder GLÜCKLICH!
Das Resultat würde schon nach wenigen Tagen eintreten, unser aller BRAIN realisiert dann dieses Flimmern nicht mehr. Ah wäre das schön!
.....und für die die es nicht sofort sehen habe ich nur eine Feststellung, zu wenig Forum schadet nicht nur dem WISSENS-STAND sondern auch dem WINKEL im KOPF :) :) :)
Mr. Lolman
2005-07-29, 11:06:35
Ich glaube kaum das die GIGA jungs eine ahnung von der momentan etwas fragwürdigen qualität des AF der gf7800GTX haben.
Und auch wenn sie den nvidia mann darüber fragen würden , der wüsste wahrscheinlich nicht einmal was die meinen.
Könnte anders sein, wenn 3DC diese News lautstärker verkündet hat, Computerbase auch darüber berichtet hätte und sich das bis P3d durchgeschlagen hätte. :mad:
/edit: Denn Post hätt ich mir sparen können, wenn ich mir vorher den Gastbeitrag durchgelesen hätte.
Gaestle
2005-07-29, 11:07:56
Es gibt kein "wahres" Bild was auch das große Problem beim IQM (Image Quality Measurement) ist. [...]
Wäre es möglich, eine solche Referenz z.B. via Softwarerenderer oder so zu erzeugen, und dann diese Referenz mit dem Hardware-Bild zu vergleichen?
Ich habe zwar hier gelesen, dass es keine festgeschriebene Vorgehensweise zum Berechnen von AF gibt, allerdings scheint es ja auch eine Methode zu geben, die hier als relativ optimal eingestuft wird. DIese könnte man doch z.B. als Referenz nehmen, oder nicht?
Man könnte doch evtl. auch aus dem Referenz-Bild auch die Mip-Map übergänge etc. pp. bestimmen, und dann beim Hardware-Bild nicht nur Farbabweichungen ermitteln, sondern evtl. auch andere Sachen, wie eben z.B. Differenzen bei den Mip-Map-Übergängen.
Oder ist das alles quatsch?
Grüße
Mr. Lolman
2005-07-29, 11:13:46
Theoretisch ginge es mit einem linearen Filter und massig (>128x) SSAA. Nur braucht das dementsprechend enorme Rechenleistung.
Gaestle
2005-07-29, 11:25:52
Theoretisch ginge es mit einem linearen Filter und massig (>128x) SSAA. Nur braucht das dementsprechend enorme Rechenleistung.
War das eine Antwort auf mich? Wenn ja, verstehe ich Sie nicht, vor allem den Part mit dem >128SSAA. wenn ich 4xMSAA bilder vegleichen will, wieso muss da zum Vergleich >128 SSAA herhalten ??? :|
Grüße
Mr. Lolman
2005-07-29, 11:30:15
Mit SSAA ensteht eine Überabtastung bei den Texturen. Ist der SSAA Grad hochgenug, hat man neben perfekt geglätteten Kanten auch perfektes Referenz AF...
Gaestle
2005-07-29, 11:39:27
Mit SSAA ensteht eine Überabtastung bei den Texturen. Ist der SSAA Grad hochgenug, hat man neben perfekt geglätteten Kanten auch perfektes Referenz AF...
Okay, dass wäre dann also der Vergleich zur nahezu perfekten bzw. absoluten Referenz.
Mich würden aber Referenzen im Sinne der abgefragten Modi interessieren, also wenn ich z.B. 4xMSAA und 8xAF betrachte, wie müsste die Referenz zu diesem Modus aussehen. Wenn ich 8xSSAA / 16xAF betrachte, wie müsste dann die eben dafür gültige Referenz aussehen. Verstehst Du, was ich meine?
Grüße
Mr. Lolman
2005-07-29, 11:44:05
Okay, dass wäre dann also der Vergleich zur nahezu perfekten bzw. absoluten Referenz.
Mich würden aber Referenzen im Sinne der abgefragten Modi interessieren, also wenn ich z.B. 4xMSAA und 8xAF betrachte, wie müsste die Referenz zu diesem Modus aussehen. Wenn ich 8xSSAA / 16xAF betrachte, wie müsste dann die eben dafür gültige Referenz aussehen. Verstehst Du, was ich meine?
Grüße
Das Problem ist imo, dass nirgends das Referenz AF definiert wird. Dementsprechend kann jeder filtern wies im gerade gefällt. Wenn 16xAF das Maximum der erreichbaren AF Quailtät stellt, müsste man eben dieses gegen dass perfekte SSAA "AF" testen. AA müsste man dann wieder gesondert vergleichen.
Gaestle
2005-07-29, 11:53:01
Wenn 16xAF das Maximum der erreichbaren AF Quailtät stellt, müsste man eben dieses gegen dass perfekte SSAA "AF" testen. AA müsste man dann wieder gesondert vergleichen.
Naja, das wäre IMHO unfair. Weil beim 16xAF sagt ja niemand, dass es das Ende der Fahnenstange ist (was aber Dein - quasi perfektes - AF wohl tendenziell wäre), vielleicht gibt's in einiger Zeit auch noch 32xAF oder 64xAF in HW (wie ausgerupft die Blüten dann auch aussehen mögen). Deswegen würde ich schon versuchen ein äquivalentes Level zu vergleichen.
Das Problem ist imo, dass nirgends das Referenz AF definiert wird. Dementsprechend kann jeder filtern wies im gerade gefällt.
Ich weiß. Allerdings kann ich mich dunkel an einen Thread im Forum erinnern, wo einige Member (irgendwo OT) offensichtlich relativ einhellig der Meinung waren, dass ein bestimmtes Verfahren zur AF-Berechnung wünschenswert (weil von den Ergebnissen her sehr ansprechend - für den gewählten AF-Grad) wäre. Dieses "Agreement"-AF-Verfahren würde ich als Referenz (natürlich mit den äquivalenten AF-Graden, wie das HW-Bild, mit dem ich's vergleichen will) nehmen.
Grüße
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.