Anisotroper Filter bei GCN (HD7000er und R-Serien) - Immernoch schlechter als NV-HQ?

[aufkrawall]

Das wäre halt teuer

Teuer im Vergleich zu was? :)
Texturfilterung kostet doch mittlerweile nichts mehr.

[Skysnake]

Trotzdem sollte ne GPU das machen, was sich der Entwickler dabei gedacht hat und nicht das, was nVidia für das "Beste" hält.

Mit der Einstellung kannste ziemlich viele Specs mal in die Tonne kloppen, und das willst du hoffentlich nicht.

[boxleitnerb]

Nun, im Bezug auf Spiele ist es das Beste. Da gibt es nichts zu diskutieren. Wenn dir Specs wichtig sind, dann musst du eben zu AMD greifen. Ich bin froh, dass man bei Nvidia seit 2006 einwandfreie Qualität bekommt. Aber die Leute, die das schätzen, sind wohl in der Minderheit. Ganz ehrlich? Was hier teilweise kommt klingt wie Ausflüchte. Die Leute, die das Thema AF überhaupt interessiert (abseits der puren Theorie - ich meine die, die dann auch damit spielen wollen), sind imo Enthusiasten, die maximale Qualität wollen und nicht schon wieder irgendwelche Kompromisse. Dachte ich jedenfalls.

Beim AF halte ich es nach dem Motto "fire and forget". HQ-AF eingeschaltet, alle Optimierungen aus und gut ist. Bei AMD müsste ich mich immer fragen, ob da nicht doch wieder Abstriche in irgendeinem Bereich/Spiel gemacht werden müssen. Das nervt.

[Gipsel]

Es würde sich gewiss niemand beschweren, wenn die GPU immer mit einem trilinearen Grundfilter arbeitet (auf welchen Stages, müsste man klären). Das wäre halt teuer: Bi oder bri ist prinzipiell erst mal eine "Optimierung", ein Kniff, um Texturfüllrate zu sparen. Natürlich braucht man nicht auf allen Lagen und bei einfarbigen (Schwarz-)Flächen eine volltrilineare Basis – nice 2 have wär's trotzdem.

MfG,
Raff
Texturstages gibt es schon ewig nicht mehr. ;)

In einem Shader kann der Treiber/Compiler eigentlich nicht mehr im Guten selbst erkennen, wie eine Textur gesampelt werden muß/kann/sollte. Der Programmierer legt dies fest, im Prinzip bei jedem einzelnen Texturzugriff separat. Wenn der dort dort irgendwo bi haben will, sollte er das auch bekommen.
Wie gesagt kann es durchaus sein, daß ein Algorithmus zur korrekten Funktion dies sogar benötigt. Wenn nur das reinen Texturieren betroffen wäre, könnte man das natürlich überschreiben. Aber dies ist wie gesagt nicht automatisch zu erkennen. Im Prinzip muß sich jemand den Shader anschauen und mit einer Art Profil für jeden einzelnen Shader getrennt festlegen, welche Samples Tri bzw. AF vertragen und welche nicht. Die meisten werden es natürlich vertragen, aber als Programmierer würde ich einen riesigen Hals bekommen, wenn meine Entscheidungen einfach so überschrieben werden und dann irgendwas nicht mehr so funktioniert, wie es sollte.

[mapel110]

Der Dev bekommt doch, was er anfordert. Nur halt ein bisschen mehr. ^^
Oder macht der Tri-Filter irgendwo Probleme? Davon hab ich jedenfalls noch nicht gehört.

[Gipsel]

Nein, das setze ich voraus wenn ich HQ einstelle. So wie ich das von NVIDIA gewöhnt bin, ein sauberes Bild. Die Theorie ist schön gut, das was man jedoch auf dem Bildschirm zu sehen bekommt, ist oft etwas ganz anderes. ;)
Du hast eine falsche Vorstellung davon, wozu man Texturfilterung einsetzen kann. Alles auf Tri ist nicht der korrekte Weg. Der Programmierer muß die Möglichkeit haben, das zu steuern.

[Locuza]

Trotzdem sollte ne GPU das machen, was sich der Entwickler dabei gedacht hat und nicht das, was nVidia für das "Beste" hält.

Mit der Einstellung kannste ziemlich viele Specs mal in die Tonne kloppen, und das willst du hoffentlich nicht.
Du musst aber zugeben, dass nicht jeder Entwickler denkt und nicht jede Spec zweifelsohne Sinnvoll ist.
Das ist ja auch nicht so ein Spec Breaker das nichts mehr geht oder Artefakte auf einmal sichtbar wären.
Die Möglichkeit zu haben ,alles zu verändern was möglich ist, aber als Standard immer das befolgen was die Anwendung will, ist eine liberale Lösung.

[Gipsel]

Der Dev bekommt doch, was er anfordert. Nur halt ein bisschen mehr. ^^
Oder macht der Tri-Filter irgendwo Probleme? Davon hab ich jedenfalls noch nicht gehört.
Wenn Du Texturen als LUTs einsetzt, Dir dabei irgendwas Cleveres überlegt hast (z.B. in die MipMaps verschiedene LUTs packen evtl.), dann ist das Interpolieren zwischen den MipMaps beim trilinearen Filter extrem kontraproduktiv und führt zum Versagen des Algorithmus. Hier darf man dann nur Bi filtern, wie sich der Programmierer das überlegt hat. Dies kann aber der Treiber/Compiler nicht automatisch erkennen.

[mapel110]

Wenn Du Texturen als LUTs einsetzt, Dir dabei irgendwas Cleveres überlegt hast (z.B. in die MipMaps verschiedene LUTs packen evtl.), dann ist das Interpolieren zwischen den MipMaps beim trilinearen Filter extrem kontraproduktiv und führt zum Versagen des Algorithmus. Hier darf man dann nur Bi filtern, wie sich der Programmierer das überlegt hat. Dies kann aber der Treiber/Compiler nicht automatisch erkennen.
Und wie realistisch ist das für ein kommerzielles Spiel?

Ich mein, wenn dieses Verhalten des Treibern so negativ ist, hätte nvidia diesen "Fehler" doch schon behoben, weil sich eben Devs beschert hätten.

[Tesseract]

mipmaping ist auch nichts anderes als eine textur der größe n*n und alle seine mipmap-stufen bis 1 pixel runter in eine 2n*n textur zu quetschen und diese dann entsprechend angepasst zu mappen.
ich sehe keinen grund warum man da aus verschiedenen mipmaps lesen sollte anstatt gleich aus einer größeren basistextur ohne mipmaps. schneller ist das sicher nicht, höchstens fehleranfälliger.
mipmaps sind fürs texturieren da und da ist trilinear immer besser als bilinear. für alles andere gibt es entweder compute-shader oder zumindest etwas weniger schmutzige dirty-hacks.

Wenn der dort dort irgendwo bi haben will, sollte er das auch bekommen.
hört sich in der theorie toll an, in der praxis sind aber leider viele zu blöd dafür. siehe AA in DX10+. ist zwar schön, dass DX10 viel mehr kann, aber in der praxis sehen DX9 spiele in den meisten fällen schlicht besser aus weil man die ordentlich samplen kann. für filterung gilt im prinzip das selbe.

[Gipsel]

Und wie realistisch ist das für ein kommerzielles Spiel?Warum nicht?
Da will irgendjemand mal einen super-duper neuen Beleuchtungsalgo (oder was auch immer) implementieren, bekommt ihn aber nicht ans Laufen, weil der Treiber immer Tri erzwingt. Tolle Wurst. :freak:

Shader machen nun mal nicht mehr nur ein simples Texturieren. Die Grafik wird tendenziell immer rechenintensiver und benutzt mehr und mehr ausgefeilte Modelle zur Berechnung der finalen Pixelfarben, die Du dann auf dem Monitor siehst. Damit sich die Programmierer austoben können, benötigen sie Kontrolle über das, was passiert. Laut Spec kann man sagen, wie etwas gefiltert werden soll. Kann man das nicht mehr, werden die TMUs arbeitslos. Man liest es dann im Zweifelsfall (ungefiltert) ein und interpoliert dann im Shader selbst (also in den ALUs). Oder kann man dann auch nicht mehr ungefiltert lesen?
Das ist einfach eine prinzipielle Sache.

[Gipsel]

mipmaping ist auch nichts anderes als eine textur der größe n*n und alle seine mipmap-stufen bis 1 pixel runter in eine 2n*n textur zu quetschen und diese dann entsprechend angepasst zu mappen.
ich sehe keinen grund warum man da aus verschiedenen mipmaps lesen sollte anstatt gleich aus einer größeren basistextur ohne mipmaps. schneller ist das sicher nicht, höchstens fehleranfälliger.Na klar ist das im Zweifelsfall schneller, weil man nicht die Texturkoordinaten selber im Shader ummappen muß. Man spart Instruktionen.

Wie gesagt, wenn einer solche "Hacks" benutzt, dann hat er sich hoffentlich was bei gedacht und dann sollte der Treiber auch nicht dran rumpfuschen.

Wie man dagegen in einem Spiel aus einer Textur für's reine Texturieren "aus Versehen" nur bilinear samplen kann (siehe Witcher), das verstehe ich allerdings umgedreht nicht. :rolleyes:

[Käsetoast]

So - habe mir nochmal die ATT gezogen und reingeschaut. Jemand mit Vista / 7 und entsprechend moderner Grafikkarte könnte ja mal testen, ob die "Quality with Full Trilinear" Funktion auch bei neuen Karten noch verfügbar und evtl. funktionstüchtig ist...

http://www.abload.de/img/atto5qhu.png (http://www.abload.de/image.php?img=atto5qhu.png)

[Raff]

Texturstages gibt es schon ewig nicht mehr. ;)

Könntest du das ausführen? :) Seit wann, etc.

Wie gesagt, wenn einer solche "Hacks" benutzt, dann hat er sich hoffentlich was bei gedacht und dann sollte der Treiber auch nicht dran rumpfuschen.

Im Zweifel könnte man derartige Spezialfälle mit einem "Flag" im Treiberprofil ent-trilinearisieren, oder nicht?

MfG,
Raff

[Gipsel]

Könntest du das ausführen? :) Seit wann, etc.Seit dem es (richtige) Pixelshader gibt. Texturstages gehören zur alten fixed function Pipeline und sind ab DX10 komplett verschwunden.
Im Zweifel könnte man derartige Spezialfälle mit einem "Flag" im Treiberprofil ent-trilinearisieren, oder nicht?

MfG,
Raff
Ich sagte schon, daß sich dann dafür jemand im Prinzip jeden einzelnen Shader anschauen müßte, um das festzulegen. Ist es nicht viel einfacher der Programmierer benutzt Tri/AF Sampler für reine Texturen und wenn er irgendwas Spezielleres machen will, fordert er halt die Samples ungefiltert, nur mit bi gefiltert oder auch mit dem schon erwähnten MIN_MAG_POINT_MIP_LINEAR an (das ist für das Texturieren normalerweise vollkommen sinnlos, warum gibt es das aber in der Spec?) an und bekommt es dann einfach auch so? Weil irgendein Dammel zu blöd ist, einen Sampler trilinear oder mit AF zu konfigurieren? Das kann es ja wohl nicht sein!

[Tesseract]

(das ist für das Texturieren normalerweise vollkommen sinnlos, warum gibt es das aber in der Spec?)

weil der vollständigkeit halber alle kombinationsmöglichkeiten in der spec sind. das bedeutet aber nicht, dass auch alle sinn machen müssen. du kannst auch 7xAF einstellen. zeig mir eine stelle wo 7x sinnvoller ist als 8x.

[Captain Future]

Dies kann aber der Treiber/Compiler nicht automatisch erkennen.
Auch nicht Catalyst AI?

[Gipsel]

weil der vollständigkeit halber alle kombinationsmöglichkeiten in der spec sind.Nicht ganz, daß bi-AF mit DX10 verschwunden ist, wurde ja schon mal erwähnt.

Und wenn "der Vollständigkeit halber" alle Möglichkeiten aufgeführt sind, warum sollte der Treiber dann die Möglichkeiten einschränken? Das schränkt nämlich im Zweifelsfall auch die Möglichkeiten des Programmierers ein. Das ist wie gesagt ein grundsätzlicher Punkt.

[Gipsel]

Auch nicht Catalyst AI?
Wie?

Da müßte wirklich jemand spielspezifische/shaderspezifische Profile hinterlegen. Sinnvoller ist es da wirklich, der Programmierer sagt einfach, was er will und bekommt es dann auch. Mir kann doch keiner erzählen, daß es die Programmierer von großen Spielentwicklungsstudies es nicht hinbekommen, einen Sampler mit trilinearem Filter oder AF zu konfigurieren :freak:. Dann müßten die gefeuert werden.

[Captain Future]

Wie? Indem man einfach prüft, ob die Mips wirklich Mips sind. Hat Ati doch schonmal gemacht.

[Tesseract]

Mir kann doch keiner erzählen, daß es die Programmierer von großen Spielentwicklungsstudies es nicht hinbekommen, einen Sampler mit trilinearem Filter oder AF zu konfigurieren :freak:

das problem ist ja nicht die programmierung (hoffentlich :freak:) sondern die content creation bzw. quality assurance. du hast hunderte böden und einer davon bekommt - aus welchen gründen auch immer - im editor das falsche setting und landet so unbemerkt im spiel.

[Gipsel]

Wie? Indem man einfach prüft, ob die Mips wirklich Mips sind. Hat Ati doch schonmal gemacht.
Das klappt doch auch nicht immer (zumal man Texturen im Prinzip auch aus einem Shader heraus schreiben kann, die bekommt der Treiber dann gar nicht zu sehen).

Aber das sind Details. Mir geht es eher um das Fundamantale, daß der (auch der clevere) Programmierer im Zweifelsfall vom Treiber überstimmt werden soll offenbar mit der Begründung, daß Einige zu blöd wären, den Texturfilter für ihre Shader richtig zu konfigurieren. :(

edit:
das problem ist ja nicht die programmierung (hoffentlich :freak:) sondern die content creation bzw. quality assurance. du hast hunderte böden und einer davon bekommt - aus welchen gründen auch immer - im editor das falsche setting und landet so unbemerkt im spiel.
Das Samplen aller "echten" Texturen sollten über ein globales Flag, was der Nutzer im Optionsmenü des Spiels setzen kann (also z.B AF an/aus), kontrolliert werden, nicht über ein Flag im Editor. Wozu soll das denn gut sein?

[Tesseract]

Das Samplen aller "echten" Texturen sollten über ein globales Flag, was der Nutzer im Optionsmenü des Spiels setzen kann (also z.B AF an/aus), kontrolliert werden, nicht über ein Flag im Editor. Wozu soll das denn gut sein?
damit sich der vor dem editor sitzt was "cleveres überlegen kann™" wahrscheinlich. :D

wenn du davon ausgehst, dass keiner in der kette fehler macht wär die logische konsequenz btw. dass auch der user kein AF einstellen kann sondern nur wie bei metro 2033 ein ganzes set an einstellungen die artworkmäßig auch zusammen passen ändert um das spiel grob an sein system anpassen zu können. finde ich in der theorie auch gut. aber bis das in der praxis funktioniert habe ich im treiber lieber "best practice"-verhalten und für die härtefälle den holzhammer, mit dem ich dem spiel die settings im notfall reinprügeln kann - und zwar vorbei an entwickler, artists und sogar dem treiberentwickler (hallo@AMD). anders funktioniert es scheinbar nicht.

[Gipsel]

damit sich der vor dem editor sitzt was "cleveres überlegen kann™" wahrscheinlich. :DDas kann der aber prinzipiell nicht, da er nicht am Code schraubt, sondern nur am Artwork. :wink:
Das dort festzulegen wäre einfach "bad practice". Die passende Filtermethode ergibt sich mit der Verwendung im Shader. Zumal ab DX10 ja Sampler und Texturen explizit getrennt wurden. :rolleyes:

[Skysnake]

Nicht ganz, daß bi-AF mit DX10 verschwunden ist, wurde ja schon mal erwähnt.

Und wenn "der Vollständigkeit halber" alle Möglichkeiten aufgeführt sind, warum sollte der Treiber dann die Möglichkeiten einschränken? Das schränkt nämlich im Zweifelsfall auch die Möglichkeiten des Programmierers ein. Das ist wie gesagt ein grundsätzlicher Punkt.
So ist es!

Und es gibt selbst so, obwohl sich im großen und ganzen an die Specs gehalten wird schon Probleme bei OpenGL z.B. weil AMD und nVidia doch irgendwelche Extrawürste machen müssen :down:

DAS KOTZT AN. Ich Spreche da jetzt aus eigener Erfahrung. Muss im Moment ja selbst für OpenGL auf Ati und nVidia was machen. Apple macht da dann auch nochmals paar Extrawürste.....

Ist echt der Wahnsinn, wenn man Stunden an nem Problem sitzt, nur weil einer der DEPPEN meint sich nicht an die Specs zu halten.....

Bei so was bekommn ich den MEGA Hals, das ist nämlich meine Zeit, die wegen so nem Dreck verschwendet wird...

[Tesseract]

Das kann der aber prinzipiell nicht, da er nicht am Code schraubt, sondern nur am Artwork. :wink:
natürlich kann er das wenn der editor die möglichkeiten bietet. ob das bei the witcher der grund ist weiß ich nicht, aber es wär zumindest eine plausiblere erklärung als ein entwickler der fassungslos vor dem schirm sitzt und sich denkt "herp derp, was ist MIPMAP_LINEAR?!? :freak:"

Die passende Filtermethode ergibt sich mit der Verwendung im Shader.
nicht unbedingt. je nach frequenz, inhalt und einsatzzweck der texturen kann ein herabstufen oder clampen der texturqualität durchaus sinn machen um z.B. performance zu sparen.

[Gipsel]

natürlich kann er das wenn der editor die möglichkeiten bietet.Sich was Cleveres überlegen? Eher nicht (höchstens was Schönes). Sieht man ja an Witcher. :wink:
nicht unbedingt. je nach frequenz, inhalt und einsatzzweck der texturen kann ein herabstufen oder clampen der texturqualität durchaus sinn machen um z.B. performance zu sparen.
Na dann rate mal, wo man das alles machen kann. Genau, bei der Konfiguration des Samplers (http://msdn.microsoft.com/en-us/library/windows/desktop/bb172415(v=vs.85).aspx).

[Langenscheiss]

MMn läuft diese Diskussion auf einen Zwiespalt zwischen Theorie bzw. kleinen Projekten und großen AAA-Spielen in der Praxis hinaus.
In der Theorie ist der Schritt hin zu einer vollkommenen Bestimmung durch den Programmierer natürlich richtig und sinnvoll, zumal dann nicht solche zeitraubenden Probleme auftreten, wie Skysnake es beschrieben hat. Das mag dann bei kleineren Projekten auch Vorteile sowohl für den Programmierer als auch für die Nutzer haben.
In der Praxis sieht es aber speziell bei den "Big Games" so aus, dass, um ein Beispiel zu nennen, aus welchen Gründen auch immer so gut wie keiner schon über die Engine in Dx10/11 Optionen für Downsampling oder SSAA anbieten (gut, es geht um AF, aber mir geht es ums Prinzip). Wäre das der Fall, würden auch nicht die ganzen AMD User in die Röhre schauen, aber es macht halt keiner bzw. es geht aus irgendwelchen Gründen, die ich nicht kenne, nicht.
Kurz: Solange die Spieleentwickler nicht wirklich Zeit und Mühe investieren, um den hohen Qualitätsansprüchen des PC-Enthusiasten gerecht zu werden, wird man immer nach Hacks verlangen, die bestimmte Mechanismen, die rein theoretisch einen Sinn machen (allein der Programmierer hat über AA zu entscheiden), aushebeln. Wozu hat man n Sandy Bridge und ne GTX580, wenn man die Leistung damit nicht für DS z.B. in GTA4 verbraten kann, weil der Entwickler auf jegliche AA-Möglichkeiten verzichtet hat bzw. verzichten musste?

[Tesseract]

Na dann rate mal, wo man das alles machen kann. Genau, bei der Konfiguration des Samplers (http://msdn.microsoft.com/en-us/library/windows/desktop/bb172415(v=vs.85).aspx).
und was soll mit das jetzt genau sagen? klar stellt man das, je nach API und version, irgendwo ein. was denn sonst?

[Gipsel]

Ich verstehe das Problem nicht.

Mal ganz einfach. Ein Spiel verlangt z.B. nach normalen Texturen, irgendwelchen Maps/LUTs, die immer mit Pointsampling gelesen werden sollen und welche, die z.B. immer bilinear gefiltert werden sollen. Dann legt man (mindestens) drei Sampler an, einen für normale Texturen, einen für ungefilterte und einen für bilinear. Der für normale Texturen wird gemäß einer hoffentlichen vorhandenen Option im Spiel auf Tri/AF oder sonstwas gestellt (oder immer auf AF, ist in dem Zusammenhang egal), die anderen gemäß ihrer Bestimmung auf entsprechend andere Werte. In den Shadern wird dann jede Textur zusammen mit dem passenden Sampler benutzt und alle sind glücklich. Und der Typ, der die Shader strickt, der muß doch notgedrungen wissen, was welche Textur ist (und somit welcher Sampler benutzt wird), sonst kommt ja Schrott raus (sprich das Haus bekommt eine Heightmap als Farbtextur oder sowas). Die Verwendung und Funktion im Shader bestimmt den benötigten Sampler, nicht der Künstler beim Erstellen im Editor.

[Tesseract]

du wirst aber nicht "den" sampler/shader für normale texturen haben sondern viele verschiedene konfigurationen die du je nach oberfläche, material, model etc. wechselst bzw. kombinierst und da können sich nunmal fehler einschleichen.
natürlich werkeln die artists nicht am shadercode oder der engine direkt rum, aber die werden wohl flexibel genug sein um sich konfigurieren zu lassen.

[Gipsel]

du wirst aber nicht "den" sampler/shader für normale texturen haben sondern viele verschiedene konfigurationen die du je nach oberfläche, material, model etc. wechselst bzw. kombinierst und da können sich nunmal fehler einschleichen.Wenn Du das feinkörnig steuerst, ist ein generelles Festlegen auf trilinear erst recht kontraproduktiv! :wink:
Das oben war explizit als möglichst einfaches Beispiel gedacht. Entscheidend ist, daß generell die Funktion einer Textur im Shader über die Art und Weise des benötigten Filters entscheidet. Und die legt nicht der Künstler im Editor fest.

Edit:
Irgendwie sind wir doch etwas vom Thema abgekommen. ;)

[Captain Future]

Das klappt doch auch nicht immer (zumal man Texturen im Prinzip auch aus einem Shader heraus schreiben kann, die bekommt der Treiber dann gar nicht zu sehen).

Mit DX9? Soweit ich es verstehe beschränkt sichs ja auf DX9, das "Problem"

[Gipsel]

Mit DX9? Soweit ich es verstehe beschränkt sichs ja auf DX9, das "Problem"
Nun, wenn ein Spiel unter DX9 den "falschen" Filter anfordert, dann kann es das bei DX10/11 auch noch. Daß es die Kombination bi-AF nicht mehr gibt (in der Spec, die Hardware kann es natürlich trotzdem) ändert im Prinzip nichts daran. Unter DX9 ist es nur wegen der eingeschränkteren Möglichkeiten der Programmierung unkritischer, einen bestimmten Filter zu erwingen.

Und wie schon gesagt halte ich aus Prinzip nicht viel davon, wenn der benutzte Filter standardmäßig verbogen wird. Man kann meinetwegen an der Qualität des AF drehen (also HQ oder Q), aber welcher Filter benutzt wird, sollte auch (oder sogar gerade) bei DX10/11-Anwendungen meiner Meinung nach immer noch diese selbst bestimmen. Wozu kann sie es denn?

[Käsetoast]

Und wie schon gesagt halte ich aus Prinzip nicht viel davon, wenn der benutzte Filter standardmäßig verbogen wird. Man kann meinetwegen an der Qualität des AF drehen (also HQ oder Q), aber welcher Filter benutzt wird, sollte auch (oder sogar gerade) bei DX10/11-Anwendungen meiner Meinung nach immer noch diese selbst bestimmen. Wozu kann sie es denn?
Sehe ich auch so. Allerdings würde ein "Trilinear erzwingen" Schalter im Treiber (oder eine versteckte Möglichkeit dazu) sicher nicht schaden um z.B. bei einem The Witcher Hand anlegen zu können. Wer weiß - wenn genug darüber jammern setzt AMD vielleicht auch das noch um... :D

[Blaire]

Sehe ich auch so. Allerdings würde ein "Trilinear erzwingen" Schalter im Treiber (oder eine versteckte Möglichkeit dazu) sicher nicht schaden um z.B. bei einem The Witcher Hand anlegen zu können. Wer weiß - wenn genug darüber jammern setzt AMD vielleicht auch das noch um... :D

Wie bereits erwähnt, früher war das mal möglich.

[uweskw]

Könnt ihr mal mit dem theoretisieren aufhören und ein paar Vergleichsviedeos uppen?
Back to reality!!
Möchte wissen ob AMD wirklich so beschissen aussieht wie es sich hier anhört.

greetz
U.S.

[Gipsel]

Allerdings würde ein "Trilinear erzwingen" Schalter im Treiber (oder eine versteckte Möglichkeit dazu) sicher nicht schaden um z.B. bei einem The Witcher Hand anlegen zu können. Wer weiß - wenn genug darüber jammern setzt AMD vielleicht auch das noch um... :D
Wenn genügend Leute jammern, gibt es vielleicht auch einen Patch für Witcher. Immerhin habe die es ja auch verbockt. :rolleyes:

[Iruwen]

Und dann kommt das nächste Spiel und wieder ein Jahr Gejammer... eine Option tut nicht weh, ist schließlich optional.

[derguru]

wenn "2" jammern auch nicht.;)

[G 80]

Bei den Mengen wo man jammern müsste, -

- wat kein AA? hat der Programierer nicht vorgesehen.
- wat x87 Code aus der Steinzeit? Prog hat nicht andres vorgesehen.
- wat kein SLI? Prog ...
- wat kein Support für andere Controller als wichsboxpad? Prog ...
- wat keine verünftige PC/Steuerung/Inventar/Gui? Prog ....
- wat ohne Mods nicht spielbar? Prog ...


sorry aber wenn ich nur dem Programierer und dessen Vorstellung ausgeliefert wäre, dann

a. spiele ich auf einer Konsole.
b. geht mir leider das elektronische Briefpapier und Tinte aus und ich würde nichts andres machen als mich beschweren.


Ich weis es ist Gipsel persönliche Meinung, aber wenn das so bleibt bzw. ATI so vertritt wäre das _alleine_ schon für mich ein Grund warum das ATI AF schonwieder unter NV abrutscht.

Sehn wir mal anhand der Praxis nach: Standard ist beide GPU liefern auf Standard was der Prog will - schön.
Verbockts der Prog mal wieder, bleibt NV perfekt.
Kommt in einem wie auch immer konstruiertem Fall reines Tri nicht gut, stell ich im Profil bei dem Spiel wieder auf Anwendungsgesteuert.

Fassen wir zusammen: Das Ding macht was ich will, oder auch was der Prog will und egal wie der Fall gelegen ist ich bekomme gff. meinen Willen und die beste BQ.

Bei ATI muss ich auf den Prog hoffen oder ich bin verloren. :freak:


Auch unabhängig von Kepler liebäuglie ich mit einer GCN (allerdings non MGPU dann ...) aber so nicht, wenn potentiell wiedermal eine 8600 GT das bessere Bild abliefert ...


Ich weis das ich Gipsel ja ziemlich vehement wiederspreche aber gerade als (BQ)-PC Spieler, der ohnehin nur schlechte Ports zu schluckem bekommt, jetzt dem Prog. wie einer Karrote an der Schnur nachzulaufen ist ziemlich daneben.

[Knuddelbearli]

nur 99% der Spieler können sowas nicht
Kommt in einem wie auch immer konstruiertem Fall reines Tri nicht gut, stell ich im Profil bei dem Spiel wieder auf Anwendungsgesteuert.

[boxleitnerb]

nur 99% der Spieler können sowas nicht

Sie können von anwendungsgesteuert auf geforctes AF/HQ stellen aber nicht mehr zurück? Das musst du uns mal erklären :freak:

[Cyphermaster]

eine Option tut nicht weh, ist schließlich optional.Absolut meine Meinung. Im schlimmsten Fall (d.h. Grafikfehler, --> Zurücksetzen auf Standard) habe ich nichts gewonnen, aber auch nichts verloren, in allen anderen Fällen gewinne ich etwas.

[Gipsel]

Es ist prinzipiell einfacher, für eine Spieleschmiede sicherzustellen, daß ihr Game alles richtig macht, als es für den Grafikkartenhersteller ist, sicherzustellen daß alle Spiele korrekt laufen, wenn man irgendwas erzwingt (weil man dann für jeden Shader jedes Spieles ein festlegen müßte, was wie gefiltert wird, wenn man mal ein wenig weiterdenkt).

Es wird perspektivisch immer schwieriger für die GPU-Hersteller, die korrekte Ausführung sicherzustellen, wenn man irgendwas von den Anforderungen des Spiels ignoriert (einfach wegen der immer weiter fortschreitenden Programmierbarkeit und damit Flexibilität). Ein Schalter, um irgendwas zu erzwingen, hilft ja auch nichts, wenn irgendwann die Mehrzahl der Spiele damit nicht mehr funktionieren würde.
Das sieht man im Ansatz doch auch schon bei AA. Bei DX9 kann man es noch halbwegs sicher erzwingen, unter DX10/11 muß für jedes Spiel eine individuelle Einstellung (AA-Bits) getroffen werden, damit es noch geht. Und MSAA muß es auch schon unterstützen. Einfach so aufzwingen ist praktisch gar nicht möglich, wenn das Spiel das nicht vorsieht. Und es wird da ja auch nicht besser. Wenn demnächst vielleicht mal eine Engine sich irgendwas komplett Neues überlegt (einfach nur mal so in den Raum geworfen: irgendeine ausgefallene Kombination von Deferred Renderer mit Raycasting), könnte es auch passieren, daß auch bei nVidia das mit den AA-Bits komplett versagt. Die Programmierer der Engine (und nur diese!) können die Funktion sicherstellen. Sowas liegt schlicht in der Verantwortung der Studios. Wenn man nicht mal bald anfängt, die zu vernünftigen Implementationen zu zwingen, lernen die das doch sonst nie und alle werden in Zukunft darunter leiden (da die GPU-Hersteller das irgendwann eben nicht mehr per Treiber hinbiegen können). :rolleyes:

[Cyphermaster]

Das würde höchstens funktionieren, wenn AMD und nVidia das gemeinsam bewußt forcieren würden (Und sogar dann würde ich vermuten, daß die Spielehersteller den Beiden den schwarzen Peter wieder zuzuschieben versuchen würden). Tun sie aber nicht! Und so lange bleibt es ein Wettrennen, das gewonnen werden kann - auch wenn es dabei immer steiler bergauf für die Kontrahenten geht.

[Blediator16]

Irgendwie Paradox. Beim Tess. Schalter wurde riesen Trara gemacht und nun wird geweint, weil der Treiber das macht, was das Spiel anfordert?

[mapel110]

Irgendwie Paradox. Beim Tess. Schalter wurde riesen Trara gemacht und nun wird geweint, weil der Treiber das macht, was das Spiel anfordert?
nvidia
TriAF bei Witcher
immer Tessellation wie es der Dev wollte

AMD
BiAF und Augenkrebs bei Witcher
Befürchtung, dass Tessellation in Spielen durch Treiber kastriert wird.

Bei nvidia bist du als User der Gewinner, bei AMD der Loser

[Iruwen]

Den Tesselation Schalter bei AMD finde ich prinzipiell auch gut, ist nur immer die Frage was Standardsetting ist. Mehr Optionen sind aber nie schlecht.

[Ronny145]

Irgendwie Paradox. Beim Tess. Schalter wurde riesen Trara gemacht und nun wird geweint, weil der Treiber das macht, was das Spiel anfordert?


Die Bedenken galten der Default Einstellung. Gegen die optionale Option zur Absenkung ist nichts einzuwenden in meinen Augen, für schwächere Karten sogar sehr nützlich. Eine optionale Tri-AF Einstellung würde die Probleme in Spielen wie Witcher 2 oder Drakensang wahrscheinlich lösen.

[Langenscheiss]

Das sieht man im Ansatz doch auch schon bei AA. Bei DX9 kann man es noch halbwegs sicher erzwingen, unter DX10/11 muß für jedes Spiel eine individuelle Einstellung (AA-Bits) getroffen werden, damit es noch geht. Und MSAA muß es auch schon unterstützen. Einfach so aufzwingen ist praktisch gar nicht möglich, wenn das Spiel das nicht vorsieht. Und es wird da ja auch nicht besser. Wenn demnächst vielleicht mal eine Engine sich irgendwas komplett Neues überlegt (einfach nur mal so in den Raum geworfen: irgendeine ausgefallene Kombination von Deferred Renderer mit Raycasting), könnte es auch passieren, daß auch bei nVidia das mit den AA-Bits komplett versagt. Die Programmierer der Engine (und nur diese!) können die Funktion sicherstellen. Sowas liegt schlicht in der Verantwortung der Studios. Wenn man nicht mal bald anfängt, die zu vernünftigen Implementationen zu zwingen, lernen die das doch sonst nie und alle werden in Zukunft darunter leiden (da die GPU-Hersteller das irgendwann eben nicht mehr per Treiber hinbiegen können). :rolleyes:

Genau da liegt ja der Hund begraben. Bei den strikten Vorgaben durch Publisher bleibt den Entwicklern nun mal keine Zeit bzw. kein Geld mehr für PC Optimierungen. Es liegt in der Verantwortung der Studios, die maximal mögliche Qualität sicherzustellen, aber die Studios wollen oder vielmehr können diese Verantwortung nicht mehr bewältigen und einigen sich dann meist auf den kleinsten gemeinsamen Nenner, nämlich den lahmen Konsolen, wo sowas wie AA eh keinen Sinn mehr macht.
Das mit der vollen Programmierbarkeit hört sich in der Theorie gut an, aber die Praxis sieht mMn so aus, wie G80 es beschrieben hat: Am Ende des Tages kommt es darauf an, was ich persönlich als Nutzer aus meiner Hardware mit dem gegebenen Spiel machen kann. Soll ich mich dann darüber freuen, dass AMD mit ihren AA Restriktionen die Specs einhalten und dem Programmierer auch ja keine Freiheiten nehmen, oder soll ich mich freuen, dass ich mit ner NV Karte n geglättetes Bild habe und eben kein durch das Spiel aufgezwungenes Bri-AF. Ganz ehrlich, ich entscheide mich für letzteres!
Solange Grafikkarten-Treiber dem Nutzer noch irgendwie Kontrolle darüber geben können, was er mit seinem gekauften Spiel machen kann, dann soll es so sein. Ob der Programmierer es vorgesehen hat oder nicht, spielt doch keine Rolle, !solange man sich dann nicht beschwert, dass es eventuell zu Nebeneffekten kommt! Damit bin ich, um auf den eigentlichen Punkt zu kommen, natürlich auch !gegen! eine nicht kontrollierbare Forcierung von Tri-AF.

[Captain Future]

Nun, wenn ein Spiel unter DX9 den "falschen" Filter anfordert, dann kann es das bei DX10/11 auch noch. Daß es die Kombination bi-AF nicht mehr gibt (in der Spec, die Hardware kann es natürlich trotzdem) ändert im Prinzip nichts daran. Unter DX9 ist es nur wegen der eingeschränkteren Möglichkeiten der Programmierung unkritischer, einen bestimmten Filter zu erwingen.
Verhält sich der Texturfilter unter DX10/11 nicht sowieso komplett anders bei Nvidia, HQ-default for example? Haben wir denn überhaupt schon gesehen, ob das "problem" auch in DX10/11 auftritt? Meine Frage hast du auch nicht beantwortetn, sondern bist ausgewichen.

Und wie schon gesagt halte ich aus Prinzip nicht viel davon, wenn der benutzte Filter standardmäßig verbogen wird. Man kann meinetwegen an der Qualität des AF drehen (also HQ oder Q), aber welcher Filter benutzt wird, sollte auch (oder sogar gerade) bei DX10/11-Anwendungen meiner Meinung nach immer noch diese selbst bestimmen. Wozu kann sie es denn?
Wow, zwei Posts und so ein krasser Widerspruch. :eek:
Wenn genügend Leute jammern, gibt es vielleicht auch einen Patch für Witcher. Immerhin habe die es ja auch verbockt. :rolleyes:

Früher hieß es mal, aus "Performance Considerations" - und es würde ja sowieso kaum jemand sehen...

[Gipsel]

Verhält sich der Texturfilter unter DX10/11 nicht sowieso komplett anders bei Nvidia, HQ-default for example? Haben wir denn überhaupt schon gesehen, ob das "problem" auch in DX10/11 auftritt? Meine Frage hast du auch nicht beantwortetn, sondern bist ausgewichen.Wenn ich wissen würde, was Du genau als "das Problem" definierst, hätte ich vielleicht antworten können. ;)
Im Übrigen verhält sich der Filter bei HQ oder Q nicht "komplett anders". Es wird lediglich an der Qualität der Filterung etwas gedreht, der Algo bleibt prinzipiell sehr ähnlich. Die Frage bi oder tri (ohne AF) bzw. AF ja oder nein ist dagegen ein fundamentalerer Unterschied.

Aus praktischer Sicht dürfte es eigentlich nie Probleme geben, wenn das Spiel nur bi-AF anfordert (was nur bei < DX10 geht), daraus tri-AF zu machen. Wer AF benutzt, verläßt den Bereich, wo es kritisch darauf ankommen könnte (was wohl der Grund ist, warum MS das ab DX10 so gemacht hat). Das wäre also wahrscheinlich eine gangbare Option für das Controlpanel des Treibers.

Aber bei einem rein bilinearen Filter (oder noch wahrscheinlicher bei Pointsampling), könnte es sein, daß sich der Programmierer etwas Sinnvolles dabei gedacht hat, was man mit erzwungenem AF unter Umständen zunichte macht.
Wow, zwei Posts und so ein krasser Widerspruch. :eek:Nö, da ist keiner. Mit "verbogen" meinte ich, daß die Wahl des von der App gewünschten Filters umgebogen wird, also ein anderer Filter benutzt als eigentlich gefordert. HQ vs. Q sollte ja nur die Qualität des Filters beeinflussen (und selbst HQ ist längst nicht perfekt im Rahmen der numerischen Auflösung [dafür müßte man in den ALUs filtern], es ist nur meist unterhalb des Sichtbaren und somit für die meisten Zwecke gut genug, das spart Hardware und damit Stromverbrauch in den TMUs).
Früher hieß es mal, aus "Performance Considerations" - und es würde ja sowieso kaum jemand sehen...
Eine Option im Menü des Spiels (oder auch nur in einer Config-Datei meinetwegen) ist doch hoffentlich nicht zu viel verlangt. :rolleyes:

[Captain Future]

Wenn ich wissen würde, was Du genau als "das Problem" definierst, hätte ich vielleicht antworten können. ;)
Na das Problem über welches gerade diskutiert wird natürlich: dass Nvidia böserweise einfach triaf macht, auch wenn biaf gefordert ist.

Im Übrigen verhält sich der Filter bei HQ oder Q nicht "komplett anders". Es wird lediglich an der Qualität der Filterung etwas gedreht, der Algo bleibt prinzipiell sehr ähnlich. Die Frage bi oder tri (ohne AF) bzw. AF ja oder nein ist dagegen ein fundamentalerer Unterschied.
also bleibt "das problem" bei DX10/11 dasselbe? Hat das jemand ausprobiert? Bisher wissen wir das ja nur vom Wichter.

Nö, da ist keiner.
Oh doch! Zuerst sagst du, die Anwendung sollte schon selbst wissen, was da angefordert wird, und dann tut eine Anwendung sowas und du sagst sie hats verbockt. Entweder du vertraust nun deinen Devs oder nicht, aber mal so, mal so ist irgendwie . . . komisch?

Und ja: So ein Schalter: Tri/Bi wäre sicherlich cool.

[Käsetoast]

also bleibt "das problem" bei DX10/11 dasselbe? Hat das jemand ausprobiert? Bisher wissen wir das ja nur vom Wichter.
Bei DX10/11 wird per se eine trilineare Filterung vorgeschrieben. Dort ist das also kein Thema...

[Captain Future]

Also ist es nur bei DX9 ein Thema und dort wird mit den Texturen kaum was anderes gemacht als zu textur-ieren? Wozu dann die Aufregung?

[Skysnake]

Weil man so was einfach nicht macht.... Es geht ums Prinzip.

Weiste, ICH darf mich dann mit so was rumschlagen. Das sind nämlich nur kleine Sachen, die man dann aber vergisst zu dokumentieren, oder irgendwann mal vergessen werden in die nächste Doku zu übernehmen, und das wird auch nie wieder korrigiert, weil ist ja eh alt, und dann schleicht sich irgendwas in ne neuere Version, weil Copy-Paste von Code whot ever. usw usw usw.

Man macht es einfach nicht. Es gibt Standards, und an die hat man sich GOTT VERDAMMT NOCHMAL!!! zu halten......

Vor allem diese Einstellung; Ist doch nicht schlimm.

Die wird immer schlimmer. Heute ist x nicht schlimm, morgen X nicht und übermorgen XYZ dann auch nicht....

Ich hab auf so was echt keinen Bock, nur weil die ... sich nicht an Standards halten können, Mehrarbeit zu haben...

Kackt die Entwickler von the Witcher an und sagt ihnen wie Scheise Sie sind, denn DIE! haben es verbockt und sonst niemand. Sollen Sie halt einen Patch bringen, und wenn Sie es nicht machen oder können/wollen, dann schön für Sie, dann weiß man ja was man von der Firma zu halten hat.

[Iruwen]

Solange die Standardeinstellung korrekt ist kann es dem Entwickler egal sein und verursacht keine Mehrarbeit, das klingt ziemlich biased.

[Skysnake]

Ja, dann muss es aber auch wirklich Standard sein, UND bleiben.

Über eine Zusatzoption, dies von Hand zu machen, sagt auch niemand etwas, dann aber bitte pro Anwendung. Ansonsten gibts wieder Probleme, weil irgend ein Horst bei irgend ner Ref die Option auf default setzt -.-

[G 80]

Auf HT4U gibt es das versprochene Update: (Danke für Arbeit nebenbei an Peter Gräber, auch an Coda für die force bi und force Tri-Injectors und den Rest HT-Leute).



Update News: http://ht4u.net/news/25045_amd_radeon_hd-7970-artikel_erfaehrt_updates/


Zurück an die Teststation und Kontakt mit AMD war angesagt. Was sich zu Beginn als sehr fruchtbare Konversation gestaltete, endete mit einem Stillschweigen auf Seiten des Herstellers, weshalb wir heute unsere finalen Informationen und Gedanken zum Thema öffentlich machen.




Link zum (2ten) AF Update im Test: http://ht4u.net/reviews/2011/amd_radeon_hd_7900_southern_island_test/index9.php

Die Feststellungen in der Zusammenfassung sind wie folgt darzustellen:

Die Radeon HD 6970 zeigt eine deutliche Flimmerneigung, welche sich allerdings etwas verringert, sobald wir über unseren Patch trilineare Mipmaps forderten. Dennoch bleibt sie vorhanden.
Die Radeon HD 7970 arbeitet über diesen Patch (trilineare Mipmaps) praktisch flimmerfrei. Im Default-Zustand des Spiels oder über manuell forcierte bilineare Mipmaps bleibt das Resultat untereinander identisch: Es lässt sich eine Flimmerneigung erblicken, wenngleich abgeschwächt zur HD 6970. Im AF: Quality-Modus scheint die Radeon HD 7970 bei bilinearen Mipmaps etwas weniger zu flimmern, als im AF: HighQuality-Modus. Zurückzuführen ist dies schlicht auf den Umstand, dass AMD hier im Quality-Modus erstmals ein leicht positives LOD setzt. Das Bild zeigt sich etwas unschärfer, was eine Flimmerneigung damit minimiert.
Der GeForce GTX 580 sind alle drei Zustände Recht, wobei natürlich festzuhalten bleibt, dass es bei Default-Settings des Spieles und der manuell gesetzten Aufforderung zu bilinearen Mipmaps keine Unterschiede gibt. Dieser Umstand war für AMD interessant und wurde explizit noch einmal abgefragt, schlicht weil sich natürlich die Frage stellte, ob sich NVIDIA über den Treiber möglicherweise über die Anforderungen des Spiels hinwegsetzt. Dem ist nicht so! Im AF: Quality- wie auch AF: HighQuality-Modus lässt sich auf der NVIDIA-Karte keine Flimmerneigung feststellen.



Es gibt _tonnenweise_ Videos in allen Konfigurationen! Genug um einen eine Weile zu beschäftigen. Auch hier nochmal danke an HT die sich alleine mit der Hartnäkigkeit und dem lückenlosen Umfang über alle deutschen Seiten weltweit absetzten.

Ich mache mich mal an die Videos und schreibe dann nochmal was bzw. ggf edit.

€: Mindestens 2 Videos scheinen nicht korrekt verlinkt zu sein bzw. man kann nicht darauf zugreifen. Mal schaun wie es nach einem Tag ist, das Update ist ja noch in der Nacht gekommen ...

[aufkrawall]

Sorry, dass ich schon wieder mit Video-Codecs rumnerve, aber man kann die FRAPS YV12 Videos mit x264 ca. um bis zu 90% ohne sichtbaren Qualitätsverlust komprimieren.
Original GTX 580 forced tri HQ: 203 MB
x264: 22 MB

Original:
http://www.ld-host.de/uploads/thumbnails/1ecd8a1424f3f94b1152c6cf7d83d966.png (http://www.ld-host.de/show/1ecd8a1424f3f94b1152c6cf7d83d966.png)

x264:
http://www.ld-host.de/uploads/thumbnails/a8313ed8ba1115e8f99cbb40a9302838.png (http://www.ld-host.de/show/a8313ed8ba1115e8f99cbb40a9302838.png)

Das x264 Video ist mit dem Windows Media Player ohne irgendwelche Erweiterungen bei voller Qualität abspielbar. Ich bin mal so frech und biete es zum Download an (22 MB):
http://www.mediafire.com/?xvldjkzlx72v4a2

Was meint ihr?
Außer, dass ich nerve. ;)

Falls Interesse besteht, beschreib ich gerne was man tun muss.

[Mr. Lolman]

Der GeForce GTX 580 sind alle drei Zustände Recht, wobei natürlich festzuhalten bleibt, dass es bei Default-Settings des Spieles und der manuell gesetzten Aufforderung zu bilinearen Mipmaps keine Unterschiede gibt. Dieser Umstand war für AMD interessant und wurde explizit noch einmal abgefragt, schlicht weil sich natürlich die Frage stellte, ob sich NVIDIA über den Treiber möglicherweise über die Anforderungen des Spiels hinwegsetzt. Dem ist nicht so!

Einfach nur so, oder gibts dafür Beweise? Wenn forciertes Bi-AF keine Änderungen zu forciertem Tri-AF bringt, dann scheint es zumindest mir so, als würde das forcieren der bilinearen Mipmaps nicht ganz klappen. Vll. sollte man mal die Mipmaps einfärben. Der 3D-Analyzer kann das out-of-the-box (hab ich mal vor Jahren reinreklamiert ;-).

[Peter Gräber]

Sorry, das wurde falsch verstanden. Wir konnten keine Unterschiede zwischen Default und forciertem bi feststellen. Das sollte die Aussage bedeuten. In allen Modi ist NV aber flimmerfrei.

Welche Videos gehen nicht? Ist wegen irgendwelcher "Launch" Geschichten gerade mal wieder etwas eng und vielleicht hab ich da schlicht nur einen Link vertauscht?

EDIT: Fehler gefunden - die beiden Videos gehen jetzt.

[samm]

Erstmal herzlichen Dank für das konsequente Weiterverfolgen der Sache!
Der Punkt, den Mr. Lolman aufbringt, ist glaub ich eher, dass nVidia aufgrund dieses Ergebnisses auch einfach jede Forderung nach bilinearer Filterung ignorieren und immer trilinear filtern könnte. Sie würden sich somit eben doch über die Aufforderungen des Spiels hinwegsetzen, was die Theorie der nach wie vor falschen AF-Sample-Gewichtung seitens AMD unter DX9 bilinear entkräften könnte.

[Gipsel]

Sorry, das wurde falsch verstanden. Wir konnten keine Unterschiede zwischen Default und forciertem bi feststellen. Das sollte die Aussage bedeuten. In allen Modi ist NV aber flimmerfrei.
Die Frage ist, ob ihr einen Unterschied zwischen Default (forced-bi) und forced-tri seht, bzw. sich bei nV auf Default die bi-Bugwelle zeigt oder nicht. Sieht alles gleich aus, steht Eure Schlußflogerung auf wackligen Füßen.
Ich denke darauf wollte lolman hinaus.

[uweskw]

Sorry, das wurde falsch verstanden. Wir konnten keine Unterschiede zwischen Default und forciertem bi feststellen. Das sollte die Aussage bedeuten. In allen Modi ist NV aber flimmerfrei.

.......

Das ist ja die Frage: Könnt ihr über ein Einfärben der Bitmaps kontrolliieren ob NV wirklich bi filtert wenn ihr es anfordert?
Da bi und tri gleich aussehen ist zumindest fraglich ob die bi-Anforderung auch tatsächlich so im Treiber umgesetzt wird.

[DrFreaK666]

Das ist ja die Frage: Könnt ihr über ein Einfärben der Bitmaps kontrolliieren ob NV wirklich bi filtert wenn ihr es anfordert?
Da bi und tri gleich aussehen ist zumindest fraglich ob die bi-Anforderung auch tatsächlich so im Treiber umgesetzt wird.

Wo liest du dass bi und tri gleich aussehen??

[Coda]

Die Frage ist, ob ihr einen Unterschied zwischen Default (forced-bi) und forced-tri seht, bzw. sich bei nV auf Default die bi-Bugwelle zeigt oder nicht. Sieht alles gleich aus, steht Eure Schlußflogerung auf wackligen Füßen.
Ich denke darauf wollte lolman hinaus.
Es gibt einen Unterschied.

Ich dachte am Anfang auch, dass NVIDIA schlicht tri forciert, dem ist aber nicht so. Man sieht auf Screenshots eindeutig harte Mip-Bänder.

[Ronny145]

AMD müsste doch nur einen Tri-AF Schalter einbauen. Dann wären die Bi-AF DX9 Spiele kein Problem.

[aufkrawall]

Es gibt einen Unterschied.

Ich dachte am Anfang auch, dass NVIDIA schlicht tri forciert, dem ist aber nicht so. Man sieht auf Screenshots eindeutig harte Mip-Bänder.
Dann gehören diese theoretischen Diskussionen über sich nicht an Specs halten etc. hoffentlich endlich der Vergangenheit an. :)

Ansonsten lässt sich jetzt wohl sagen, dass Nvidia nach wie vor, mal mehr, mal weniger bessere AF als AMD hat.
Muss man jetzt aber vielleicht auch keinen riesen Wind drum machen, bei Witcher einfach SSAA an und fertig.

[Ronny145]

Muss man jetzt aber vielleicht auch keinen riesen Wind drum machen, bei Witcher einfach SSAA an und fertig.


In Witcher 2 hat nicht jede GCN Karte die Leistung für SSAA.

[aufkrawall]

In Witcher 2 hat nicht jede GCN Karte die Leistung für SSAA.
Es geht doch um Witcher 1.

[Ronny145]

Es geht doch um Witcher 1.

Es geht um Witcher 2.

[derguru]

du irrst dich.

[aufkrawall]

Es geht um Witcher 2.
Video runterladen und Aussage korrigieren. :)
Vielleicht war dir der Download ja zu groß? :D

[Screemer]

Ist wegen irgendwelcher "Launch" Geschichten gerade mal wieder etwas eng und vielleicht hab ich da schlicht nur einen Link vertauscht?t.
ich freue mich schon sehr auf euren test der 7950 :)

und danke für das umfangreiche-update. gibt es irgendwo eine möglichkeit den tri-af-patch herunter zu laden. weniger flimmern würde mich auf meiner 6950 wirklich freuen.

[uweskw]

Sorry, das wurde falsch verstanden. Wir konnten keine Unterschiede zwischen Default und forciertem bi feststellen. Das sollte die Aussage bedeuten. In allen Modi ist NV aber flimmerfrei.

.......



http://ht4u.net/reviews/2011/amd_radeon_hd_7900_southern_island_test/index9.php

Super Review, HT4U mausert sich so langsam aber sicher zur Gafik-Referenz!
Habt ihr auch vor euch des SSAA Themas anzunehmen? Würde mich freuen wenn das mit der gleichen Gründlichkeit passiert.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9134808&postcount=318

Greetz
U.S.

[Langenscheiss]

Jo, das ist schon sehr gründlich. Allerdings hätte man einen weiter bestehenden Hardwarefehler bei billinearer Texturfilterung in 5 Minuten ausschließen können, zumal das Problem unabhängig davon war (glaub ich jedenfalls).

[Coda]

Warum sollte das Problem davon unabhängig sein? Mit Tri ist es sauber, mit Bi nicht auf GCN. Auf Fermi ist beides sauber.

[Skysnake]

von mir auch ein Danke dafür :up:

Fragt sich nur, was AMD beim Bi macht.

Ich würde mich über ein Einfärben ECHT! Freuen. Könntet ja auch gleich einen so fumktionierts Artikel dazu schreiben, ähnlich wie PCGH es manchmal macht zu den Filtern etc.

Das wäre echt göttlich!

[Blaire]

Warum sollte das Problem davon unabhängig sein? Mit Tri ist es sauber, mit Bi nicht auf GCN. Auf Fermi ist beides sauber.

@Coda: Könnt ihr diesen Tri-AF Patch öffentlich zugänglich machen?

[Coda]

Weiß nicht wie's lizenzrechtlich aussieht, weil ich Microsoft Detours benutzt hab.

[Langenscheiss]

Warum sollte das Problem davon unabhängig sein? Mit Tri ist es sauber, mit Bi nicht auf GCN. Auf Fermi ist beides sauber.

Nun, wenn hier mit "Problem" der Hardwarebug gemeint ist, so trat dieser zumindest im AF-Tester unabhängig davon auf, ob man nun Mipmaps hinzugeschaltet hat, oder nicht, weshalb ich davon ausgehe, dass das Problem ausschließlich am AF selbst lag und nicht davon abhing, wie die Mipmaps ins Spiel kommen. Aber es kann natürlich sein, dass man für die Korrektur dieses Problems jede Kombination separat berücksichtigen musste und man bei Bi irgendwas falsch gemacht hat??? Aber das hätte man ja dann testen können, indem man speziell solch eine Testumgebung mit Bi-AF (im AF-Test mit Dx9-Pfad) geschaffen hätte.
Ist letztlich auch nicht so wichtig. Es scheint ja tatsächlich am Bi-AF zu liegen bei The Witcher, was hinsichtlich der Bewertung des Texturfilters positiv zu sehen ist.

[Mad9000]

Dann gehören diese theoretischen Diskussionen über sich nicht an Specs halten etc. hoffentlich endlich der Vergangenheit an. :)

Ansonsten lässt sich jetzt wohl sagen, dass Nvidia nach wie vor, mal mehr, mal weniger bessere AF als AMD hat.
Muss man jetzt aber vielleicht auch keinen riesen Wind drum machen, bei Witcher einfach SSAA an und fertig.


Danke für den Beitrag

[Peter Gräber]

Weiß nicht wie's lizenzrechtlich aussieht, weil ich Microsoft Detours benutzt hab.
Wie findet man das raus?

Solange das nicht geklärt ist, können wir es nicht zum Download anbieten - sorry.

Habt ihr auch vor euch des SSAA Themas anzunehmen? Würde mich freuen wenn das mit der gleichen Gründlichkeit passiert.
http://www.forum-3dcenter.org/vbulle...&postcount=318

Du meinst Default gegen Default? Ich weiß noch nicht wie wir die Zeit finden. Ich glaub ich muss mich erst einmal den hier befindlichen und den im Zulauf befindlichen Grafikkarten widmen. Ist auf jeden Fall kein simples Thema hinsichtlich der Möglichkeiten des Inspectors.

[G 80]

Welche Videos gehen nicht? Ist wegen irgendwelcher "Launch" Geschichten gerade mal wieder etwas eng und vielleicht hab ich da schlicht nur einen Link vertauscht?



Danke fürs korregieren. Tut mir leid ich hätte dazuschreiben sollen welche, aber ich war dann schon müde ....


bzw:

[...] Dem ist nicht so! Im AF: Quality- wie auch AF: HighQuality-Modus lässt sich auf der NVIDIA-Karte keine Flimmerneigung feststellen.

Von eurer Reaktionszeit, selbst bei Missverständnissen, könnte sich so mancher Support was abschneiden.


Alleine schon die Tatsache, das das 7970 HQ Tri Video auch das längste ist, gefällt mir gut und zeugt von mitdenken.





ATIs AF, generell, kann man mittlerweile als gefixt bezeichnen. Was mich umso mehr beeindruckt ist das "crap" (sollte man meinen) q und bi AF auf der 580er.
DX 9 stirbt zwar aus, aber nicht schnell genug. Er werden wohl auch 2012 mehr interessante Spiele mit 9 only als mit 10/11 erscheinen, deshalb is NVs AF weiterhin _potentiell_ besser. Darum muss man aber jetzt nicht mehr den Wind machen, das gebe ich zu, sondern vielmehr fällt es unter mehr-Möglickeiten-etwas-einzustellen-bei-NV.

Zusammenfassend: GCN oder besser Tahiti (XT, denn mehr hat man bisher ja nicht gesehn ;D) gets G 80s AF-Seal of Approval. :biggrin:


€:

Wie findet man das raus?



IdR weil man deswegen abgemahnt/verklagt wird ... :usad:

[Skysnake]

:biggrin:

Na das will was heißen ;)

Ich bin echt froh, wenn man dieses Thema dann (hoffentlich!) endgültig zu den Akten legen kann. Gibt ja noch so manche andere Baustelle, der man sich nun wittmen kann ;)

Ich plediere dafür, das ihr mal wegen den Linux Treibern und den 512MB Speichernutzung unter OpenCL genau so einen Aufstand hinlegt :ugly:

Ich wäre euch auf jeden Fall SEHR zu Dank verpflichtet :biggrin:

[Coda]

Nun, wenn hier mit "Problem" der Hardwarebug gemeint ist, so trat dieser zumindest im AF-Tester unabhängig davon auf, ob man nun Mipmaps hinzugeschaltet hat
Wat? Der AF-Tester benutzt kein Bi-AF weil D3D10. Was redest du?

[Raff]

Ich habe da auf Tahiti ebenfalls Banding gesehen (auch wenn ich meinen Augen nicht glauben konnte ;)).

MfG,
Raff

[Coda]

Das ist wenn dann aber etwas anderes, bzw. das gleiche Problem tritt mit Tri-AF sehr sehr viel verminderter zu Tage.

[Langenscheiss]

Wat? Der AF-Tester benutzt kein Bi-AF weil D3D10. Was redest du?

Ich rede nicht von deinem Tester, sondern vom alten von Demirug. Und der läuft afaik unter Dx9, und ich hab wohl 20 bis 30 Bilder, die banding + Flimmern (zumindest das Potential dazu, weil Flimmer und Standbilder geht net) ohne MipMaps zeigen (auf den alten Karten, von der HD7970 hab ich natürlich keine Bilder, nur um erneute Missverständnisse zu vermeiden)
EDIT: Was genau das Programm anfordert, kann ich natürlich nicht wissen, aber jedenfalls lassen sich Mipmaps deaktivieren, womit doch normal jeglicher Effekt, der durch den Unterschied Bi-Tri entsteht, von vorn herein wegfallen sollte.

[Coda]

Ohne Mipmaps?

Bist du sicher, dass du das meinst?

[Langenscheiss]

Ja absolut. Zumindest ist es das, was da Programm mir sagt. Alles andere steht nicht in meiner Macht. Und die Bilder sehen auch so aus, als gäbe es keine Mipmaps, also konsistent isses.

[Coda]

Und warum in aller Welt bist du der Meinung, dass eine GPU ohne Mips in der Stande sein soll ohne Flimmern zu filtern?

[Langenscheiss]

Und warum in aller Welt bist du der Meinung, dass eine GPU ohne Mips in der Stande sein soll ohne Flimmern zu filtern?

Dass es da sowieso zum Flimmern kommt, ist doch schon klar. Es geht nur speziell
um das banding, und das hat sich in Tests als auch in Spielen immer dadurch gezeigt, dass es direkt hinter der Kante stärker flimmerte (irgendwann hatte ich mal n Crysis Video hochgeladen, in dem man das sehr gut sehen konnte), sprich Flimmern und Matsch an der Kante waren zwei Symptome des gleichen Problems, die direkt zusammenhingen. Und genau dieses Flimmern meinte ich. Dass die ganze Szene ohne Mips sowieso flimmert wie blöde, ist doch klar.

Es ging doch ursprünglich nur darum, dass ich begründen wollte, warum ich meine, dass der Bug unabhängig davon ist bzw. war, ob billinear oder trillinear gefiltert wird, und das sagte ich deshalb, weil das banding selbst ohne Mipmaps auftrat, woraus ich schloss, dass das ein spezifisches Problem des AFs ist, was nicht davon abhängt, ob Bi oder Tri gefiltert wird. Aber ich sagte ja bereits, dass ich natürlich nicht weiß, ob eine Korrektur dieses Problems seitens AMD auch abhängig davon ist, ob Bi oder Tri gefiltert wird, womit sich wiederum die Geschichte in the Witcher erklären würde.

[Coda]

Es gäbe schon die Möglichkeit, dass das Problem bei Tri fast nicht zu Tage tritt weil man die Samples der anderen Mip damit vermischt, ja.

Das Ganze ist sowieso ein Trauerspiel. Warum gibt es beispielsweise keine Referenzimplementierung in Software mit der sie es bitgenau abgleichen können? Das kann doch nicht so schwer sein.

[Langenscheiss]

Es gäbe schon die Möglichkeit, dass das Problem bei Tri fast nicht zu Tage tritt weil man die Samples der anderen Mip damit vermischt, ja.

Das Ganze ist sowieso ein Trauerspiel. Warum gibt es beispielsweise keine Referenzimplementierung in Software mit der sie es bitgenau abgleichen können? Das kann doch nicht so schwer sein.

Also wenn ich dich richtig verstehe, scheint es also immer noch nicht vollkommen gefixed zu sein, oder hab ich da jetzt was falsch interpretiert?
Und Raffs vorherige Aussage macht mich auch etwas stutzig...

@Raff oder jemand anderes, der sonne Karte hat:
Jagt das Ding doch nochmal durch die Texelanalyse aus dem D3D AfTester. Da waren die Kanten immer sehr gut zu erkennen. Am besten ohne Mips mit 16xAF. Die entsprechenden Settings gibt es afair im Thread zum Cayman/Barts AF.

[Coda]

Es ist für mich in Tri "gefixt" in der Hinsicht, dass ich es als in der Praxis als sauber erachte. Das ist allerdings mein subjektiver Eindruck. Wenn man aber mit der Lupe schaut, erkennt man evtl. auch bei Tri-AF aber eine leicht höhere Flimmerneigung.

Bei Bi-AF sieht die Sache anders aus. Da sieht man in Witcher einen eindeutigen Unterschied.

Ich weiß, ich hab da früher andere Aussagen getroffen, allerdings war mir da das Bi-Problem noch nicht bekannt und das Tri-AF sah für mich sauber aus.

[Langenscheiss]

Naja, da zeigt sich mal wieder, was eine gründliche Analyse bringt. Sowas kann man nur loben.

[Coda]

Ja, jetzt habe ich aber auch für lange genug Zeit investiert. Hab gerade andere Baustellen ;)

Edit: Ach btw. den Code für die Injection-DLL gibt es hier: https://github.com/Novum/D3D9TriForcer
Falls es jemand kompilieren und selbst verteilen will gerne.

[uweskw]

Es gibt einen Unterschied.

Ich dachte am Anfang auch, dass NVIDIA schlicht tri forciert, dem ist aber nicht so. Man sieht auf Screenshots eindeutig harte Mip-Bänder.

Ich hab mir jetzt endlich die Videos herunter geladen, zumindest HQ forced bi und tri.(dauert bei meiner Verbindung doch ein bisschen länger:rolleyes:)
Auf die Gefahr hin jetzt für blind gehalten zu werden: auf dem HT4U-videos kann ich zwischen erzwungener bilinearer Filterung und trilinearer Filterung keinen relevanten Unterschied erkennen. Welche Screenshots meinst du genau. Kannst Du die Mip Bänder markieren?
Ich denke dein erster Gedanke war richtig und NVIDIA forciert schlicht die tri-lineare Filterung.

Greetz
U.S.

[Coda]

Ich habe selbst Screenshots angefertigt und angeschaut und es gibt definitiv Mip-Bänder auf Bi.

[uweskw]

...die es auf tri nicht gibt? ich dachte immer der Unterschied zwischen bi und tri-Linearer Filterung sei doch sehr deutlich sichtbar. Da habe ich mich wohl getäuscht.

[Langenscheiss]

...die es auf tri nicht gibt? ich dachte immer der Unterschied zwischen bi und tri-Linearer Filterung sei doch sehr deutlich sichtbar. Da habe ich mich wohl getäuscht.

Das ist ja das, was mich an dieser Erklärung anfangs stutzig gemacht hat, denn normalerweise sollte man bilineare Filter sehr leicht auch auf Screenshots ausmachen können. Aber die Tatsache, dass es mit dem Tri-Patch sauber aussieht, beweist ja, dass das irgendwie damit zusammenhängt.
EDIT: Außerdem kann man das bei genauerer Betrachtung der Witcher-Videos schon sehen, dass es direkt vor dem Sprung zur nächsten Mip flimmert und dahinter nicht mehr.

[uweskw]

Mir geht es darum ob NV nicht einfach tri drübersemmelt egal was angefordert wird. ICH sehe auf den HQ Videos keinen Unterschied zwischen forced bi und tri. Jedenfalls keinen den ich auf bi-Filterung zurückführen würde. Sollte bei einer solchen Szene doch leicht im Video erkennbar sein.
Wenn jemand mehr als ein "is halt so" als Beleg bringt lasse ich mich gern überzeugen.

[Langenscheiss]

Achso, dir geht es jetzt explizit um Nvidia. Sorry, das hab ich wohl falsch verstanden. Schau ich mir nochmal an.
EDIT:
Das Problem bei dem NV-Forced Tri-Video Q ist leider, dass zuviele Menschen die interessante Stelle verdecken (bei Q). Aber für mich sieht das auch so aus, als würde die Karte auf Forced-Bi und Forced-Tri das gleiche machen, sowohl bei Q als auch HQ.

[Coda]

Mir geht es darum ob NV nicht einfach tri drübersemmelt egal was angefordert wird.
Nein, tun sie nicht.

Ich habe Screenshots von identischen Kameraperspektiven verglichen und es gibt einen Unterschied zwischen Tri und Bi auf NVIDIA. Man sieht auch Bi-Bänder, wenn man genau hinsieht.

[Tesseract]

Es ist für mich in Tri "gefixt" in der Hinsicht, dass ich es als in der Praxis als sauber erachte.
wobei ich, wenn man ausschließlich tri@hq vergleicht, nvidias filter immer noch sichtbar besser finde. was die flimmerneigung angeht ist die 7970 irgendwo zwischen 6970 und 580 - stellenweise sogar näher zur 6970 als zur 580 - ohne dabei schärfer auszusehen als die 580.

[Langenscheiss]

Nein, tun sie nicht.

Ich habe Screenshots von identischen Kameraperspektiven verglichen und es gibt einen Unterschied zwischen Tri und Bi auf NVIDIA. Man sieht auch Bi-Bänder, wenn man genau hinsieht.

Könntest du die shots mal hochladen? In den Videos sehe ich keinen Unterschied.

[Coda]

Nein, hab sie nicht mehr und werde hier auch keine Zeit mehr investieren. Entweder man glaubt es mir oder man lässt es bleiben.

[Ronny145]

Zu Videos gehören sowieso immer die dazugehörigen screenshots um die Schärfe richtig beurteilen zu können.

[aufkrawall]

Übrigens stellt z.B. der VLC die Videos falsch dar.
Damit man die FRAPS-Videos richtig gucken kann, muss FRAPS installiert und dessen Dekoder aktiv sein, also nicht z.B. von ffdshow überlagert werden.
Edit: Oder man nimmt einen anderen Dekoder, der nach RGB dekodiert.
Ich wär ja für H.264, das man mit dem WMP problemlos abspielen kann. ;)

[Coda]

H.264 ist nicht verlustlos. Damit kannst du nicht argumentieren.

[aufkrawall]

H.264 ist nicht verlustlos. Damit kannst du nicht argumentieren.
x264 hat einen verlustlosen Modus.
Darum gehts mir aber gar nicht, denn man braucht keine mathematische Verlustlosigkeit, sondern nur Transparenz fürs Auge.
Und die gibt es mit hohen Bitraten auch im mathematisch verlustbehafteten Modus.
Kannst dir ja mal mein ~90% kleineres Video runterladen und vergleichen.

Außerdem sind die Original-Videos auch schon stark verlustbehaftet, da sie nicht im RGB-Modus aufgenommen wurden.
Sofern man keinen Unterscheid bei x264 sieht, who cares?

[N0Thing]

Es gibt für H.264 doch Predictive Lossless Coding, könnte man das nicht verwenden? Oder handelt es sich dabei trotz des Namens um eine verlustbehaftete Variante?

[aufkrawall]

Es gibt für H.264 doch Predictive Lossless Coding, könnte man das nicht verwenden? Oder handelt es sich dabei trotz des Namens um eine verlustbehaftete Variante?
x264 hat einen lossless-Modus, der ist 100% verlustlos.
Allerdings können wieder nur wenige "populäre" Player das, wenn überhaupt, richtig abspielen.
Es ist aber auch sinnlos. Lossless braucht man nur, wenn man ein Video später noch mal wieder neu enkodieren will. Das will man in dem Fall aber nicht, daher tuts auch eine verlustbehaftete, hohe Bitrate, bei der man keinen Unterschied zum Original sieht.
Edit: Netter Nebeneffekt: Der Windows Media Player, also jeder User, kann es richtig abspielen.

[Coda]

Der Lossless-Modus macht in zig Playern Probleme. Dann kann man gleich Fraps benutzen.

[aufkrawall]

Der Lossless-Modus macht in zig Playern Probleme. Dann kann man gleich Fraps benutzen.
Wie gesagt: FRAPS ist auch nicht unproblematisch.
Es vertraut nicht mal sich selbst: Das 4:2:0-Video enthält noch die volle RGB PC-Range (so ein Schwachsinn...). Deshalb muss der Dekoder es beim Abspielen nach RGB konvertieren, damit keine extremen Helligkeitsabweichungen entstehen.
Das macht etwa der VLC nicht (und wahrscheinlich außer dem FRAPS-Dekoder auch sonst kein anderer Dekoder), deshalb ist das Video mit dem viel zu hell.

Wenn man nach x264 konvertiert, kann man die RGB-Range fürs Auge verlustlos von PC nach TV umwandeln, sodass der WMP keine Probleme macht.

x264 ist der effektivste Encoder wo gibt, Transparenz ist das einzige was zählt.

[uweskw]

Nein, hab sie nicht mehr und werde hier auch keine Zeit mehr investieren. Entweder man glaubt es mir oder man lässt es bleiben.

Dann lass ich es bleiben...:freak:
Ich weiss ja dass du als AF-Gott gilst, aber auch Götter können Fehler machen, Screenshots vertauschen, falsche Datei anklicken.....

Aber für die Dummies wie mich.
Ich dachte eigentlich das es in dem Moment in dem anisotrope Filterung aktiviert wird bi oder tri-Linear keine Rolle mehr spielt.
http://www.gamestar.de/hardware/praxis/2324049/maximale_bildqualitaet_in_jedem_spiel_p4.html#

Falls das richtig ist, wen juckten dann eigentlich Fehler die nur bei bi-linearer Filterung auftreten? Gibts irgend ein BQ-Freak der Witcher ohne AF spielt?:freak:

Muste zwar tief buddeln, hab aber selbst gefunden. (2001)
http://alt.3dcenter.org/artikel/grafikfilter/index6.php

[Coda]

Ich habe aber keinen Fehler gemacht. Ich werde doch wohl bei Vergrößerung sehen können, ob es einen Unterschied zwischen zwei Bildern gibt.

Und ja, ich habe es doppelt gecheckt. NVIDIA filtert schlicht mit Bi-AF wesentlich ruhiger, deshalb sieht man den Unterschied kaum.

Muste zwar tief buddeln, hab aber selbst gefunden. (2001)
http://alt.3dcenter.org/artikel/grafikfilter/index6.php
Der Artikel ist zwar gut gemeint, aber inhaltlich an vielen Stellen ungenau.

[Peter Gräber]

Um was geht es hier überhaupt noch? Geht es darum, dass man irgendetwas herausfindet, was NVIDIA des "cheaten" bezichtigen könnte?

Uns ging es eigentlich darum und in absolut erster Linie, diese übersehene Flimmerneigung bei bilinear gefilterten Mipmaps, auch wenn deutlich gemindert, zu ergründen. Und im Ergebnis haben wir eine mögliche Erklärung dafür gefunden und dargelegt. AMD hat uns plötzlich komplett im Regen stehen lassen - was NVIDIA im Übrigen in einer solchen Situation nicht anders getan hätte - und das bestätigt uns ein wenig in unserer Vermutung, dass der Hardware-Fix nicht in allen Bereichen umgesetzt wurde. Exakt diese Vermutung haben wir AMD in der ersten Kontaktaufnahme auch geschildert.

Und jetzt müssen wir uns irgendwann auch einmal wieder um das Tagesgeschäft kümmern. Ich empfehle ggf. AMD mit diesen Informationen zu konfrontieren und dann dort ein Statement anzufordern. Schließlich liegen unsere Videos auch dort vor und schließlich können die sich aus den Videos ebenfalls Screenshots machen - wie jeder selbst auch.

[aufkrawall]

Um was geht es hier überhaupt noch? Geht es darum, dass man irgendetwas herausfindet, was NVIDIA des "cheaten" bezichtigen könnte?

An dieser Stelle noch mal Vielen Dank dafür, dass ihr diesen Verdacht entkräftet bzw. herausgefunden habt, was wirklich los ist! :)


Ich empfehle ggf. AMD mit diesen Informationen zu konfrontieren und dann dort ein Statement anzufordern. Schließlich liegen unsere Videos auch dort vor und schließlich können die sich aus den Videos ebenfalls Screenshots machen - wie jeder selbst auch.
Irgendwann ist auch mal gut, es betrifft ja schließlich nur einige wenige DX9-Spiele, deren Flimmern man auch durch SSAA tilgen kann.
Kann man doch?
Das wäre die letzte offene Frage.
Wenn es mit 8xSGSSAA immer noch flimmert, hätte man wirklich noch einen Grund zum Meckern...

[Langenscheiss]

Um was geht es hier überhaupt noch? Geht es darum, dass man irgendetwas herausfindet, was NVIDIA des "cheaten" bezichtigen könnte?

Uns ging es eigentlich darum und in absolut erster Linie, diese übersehene Flimmerneigung bei bilinear gefilterten Mipmaps, auch wenn deutlich gemindert, zu ergründen. Und im Ergebnis haben wir eine mögliche Erklärung dafür gefunden und dargelegt. AMD hat uns plötzlich komplett im Regen stehen lassen - was NVIDIA im Übrigen in einer solchen Situation nicht anders getan hätte - und das bestätigt uns ein wenig in unserer Vermutung, dass der Hardware-Fix nicht in allen Bereichen umgesetzt wurde. Exakt diese Vermutung haben wir AMD in der ersten Kontaktaufnahme auch geschildert.

Und jetzt müssen wir uns irgendwann auch einmal wieder um das Tagesgeschäft kümmern. Ich empfehle ggf. AMD mit diesen Informationen zu konfrontieren und dann dort ein Statement anzufordern. Schließlich liegen unsere Videos auch dort vor und schließlich können die sich aus den Videos ebenfalls Screenshots machen - wie jeder selbst auch.

Sorry, ich kann zwar verstehen, dass es für EUCH weiter gehen muss, weil ihr schließlich mit euren Artikeln Geld verdienen müsst und ihr neue schreiben müsst, aber wo bitte wird hier denn noch irgendwas von HT4U verlangt? Das kann uns doch nicht daran hindern, weiter drüber zu diskutieren und nach Bildern zu !fragen!, die bestimmte Dinge zeigen oder widerlegen, wenn noch Fragen offen sind. Dafür ist der Thread doch da.
Im Falle von Coda war die Antwort ja eindeutig und damit müssen wir dann auch leben und es akzeptieren (was man persönlich davon hält, ist halt ne andere Frage), aber wenn Coda hier im Forum postet, dann gehe ich zumindest davon aus, dass er das als Coda tut und nicht als Mitarbeiter von HT4U, der von uns mit "unnützen" Dingen aufgehalten wird.

[Peter Gräber]

Das kann uns doch nicht daran hindern, weiter drüber zu diskutieren und nach Bildern zu !fragen!, die bestimmte Dinge zeigen oder widerlegen, wenn noch Fragen offen sind.

Du hast ja vollkommen Recht, aber wie ich schon geschrieben habe, bist du problemlos in der Lage deine Bilder selbst zu fertigen. Die Videos liegen vor und mehr Material hat auch Axel und Leander nicht.

Ediit: Und entschuldige, dass ich mich in eine Diskussion mit meinen Gedanken einmische, die offenbar Codas und Langenscheiss vorbehalten ist. Es war ein schlichter Beitrag, der Hilfe geben sollte bei den Möglichkeiten. Ich werde mich auf andere Dinge konzentrieren.

[Langenscheiss]

Ediit: Und entschuldige, dass ich mich in eine Diskussion mit meinen Gedanken einmische, die offenbar Codas und Langenscheiss vorbehalten ist. Es war ein schlichter Beitrag, der Hilfe geben sollte bei den Möglichkeiten. Ich werde mich auf andere Dinge konzentrieren.

Sorry, aber ich hatte das so interpretiert, als würdest du die Diskussion runterspielen. Ich hätte allerdings den entsprechenden Teil deines postings hervorheben können.

Und zu dem Material: Ich bin davon ausgegangen, dass die Screenshots noch von einer anderen Szene waren, in der man das besser sieht.

[aufkrawall]

Eigentlich hätte man ja auch die 7970 mit der 5870 vergleichen müssen.
Vielleicht ist es ja weniger ein Fortschritt, sondern nur mehr wieder ein Schritt zurück auf den alten Stand?

[Langenscheiss]

Eigentlich hätte man ja auch die 7970 mit der 5870 vergleichen müssen.
Vielleicht ist es ja weniger ein Fortschritt, sondern nur mehr wieder ein Schritt zurück auf den alten Stand?

Ich habe mit ein zwei Besitzern der aktuellen Karten geredet, und die machen vielleicht ein paar Bilder mit dem alten AF-Test. Dann werde ich mir auch mal einen Vergleich zwischen Performance, Quality und High Quality anschauen, und den Filter mit der 6er (und vielleicht der 5er) Serie vergleichen. Vielleicht ergibt sich ja noch was. Schaden kann es auf jeden Fall nicht. Die Texel-Analyse gibt zwar bekanntlich falsche Sample-Raten, hat aber imo als BQ-Indikator bisher gut funktioniert. Insbesondere interessiert mich hier dann natürlich das Ergebnis ohne Mipmaps, welches allein die Arbeit vom AF zeigt.

[Ronny145]

HD7800/7900 mit unscharfen Texturen im Quality setting. Treiber-Fix im Anmarsch.

We discovered blurry textures when we reviewed the Radeon HD 7800s, so now we're performing an in-depth investigation.

Just prior to publication, AMD provided the following official statement:

"For our Southern Island product family launch we picked a set of settings that we tested in several scenarios for image quality and found that those specific settings were providing the best overall quality. When you pointed out these issues in some games around texture quality, we went back and found one specific setting that was causing the described texture blurriness. This has now been removed and the quality of textures should be as intended, with performance unchanged. These settings will be adjusted accordingly in the 12.4 April Catalyst release, later this month."
http://www.tomshardware.com/reviews/image-quality-driver-optimization-graphics,3173.html

[mironicus]

Schön, dass AMD in letzter Zeit praktisch auf alle Kritiken schnell reagiert, dass bringt positive Kritiken im Netz und entsprechend sterben die Threads über vermeintliche schlechtere Bildqualität dann auch aus. :D
Aber dankbarer muss noch den Tech-Journalisten sein, die diese Fehler überhaupt erst aufdecken. ^^

[uweskw]

THW scheinen sich ja zu machen.-.. positive Entwicklung. Sollte man im Auge behalten, die sind so groß dass sie wirklich etwas bewegen können.

greeetz
U.S.

[Knuddelbearli]

na mal hoffen das sie es nicht verschlimmbessern

[DrFreaK666]

Die Bugs kommen bestimmt absichtlich in die Treiber, damit man danach gut da steht, weil man sich schnell darum kümmert ;D

[Ronny145]

HD7800/7900 mit unscharfen Texturen im Quality setting. Treiber-Fix im Anmarsch.


http://www.tomshardware.com/reviews/image-quality-driver-optimization-graphics,3173.html


Und bei unseren Untersuchungen mit dem Catalyst 12.4 haben sich unsere Befürchtungen leider bestätigt: Die Texturschwäche ist jetzt zwar verschwunden und das Bild damit (manchmal) einen Tick schärfer, die Flimmerneigung ist aber wieder gestiegen. Ein Vergleichsvideo mit dem „3DC Filtertester“ zeigt den Effekt sehr gut, da es sich dabei um einen Extremfall handelt.
http://www.computerbase.de/artikel/grafikkarten/2012/bericht-amd-catalyst-12.4-whql/3/#abschnitt_anisotrope_filterung_wurde_geaendert

:confused:

[Raff]

Wir reden doch hier nur von einer Beseitigung des +0,1-LODs bei Quality, oder nicht? Warum wird das dann nicht explizit genannt? Sorry für die blöde Frage, ich habe das noch nicht getestet. ;)

MfG,
Raff

[Ronny145]

Wir reden doch hier nur von einer Beseitigung des +0,1-LODs bei Quality, oder nicht? Warum wird das dann nicht explizit genannt? Sorry für die blöde Frage, ich habe das noch nicht getestet. ;)

MfG,
Raff


Das müsste AMD beantworten. Einige Texturen wirken eigentlich zu unscharf für nur +0,1. Achte mal auf die Hauswand zwischen 7800 und 6900. Oder die Steintextur in Skyrim. Hier würde ich wohl ein leicht stärkeres flimmern bevorzugen.

[Käsetoast]

http://www.computerbase.de/artikel/grafikkarten/2012/bericht-amd-catalyst-12.4-whql/3/#abschnitt_anisotrope_filterung_wurde_geaendert
Das ist alles Ansichtssache. Computerbase fand den unscharfen aber weniger rauschenden Quality-Modus besser als den scharfen aber rauschanfälligeren HQ-Modus. Ich glaube PCGH hat das genau umgekehrt gesehen...

Letztendlich würde ich's als "Geschmacksfrage" formulieren - DEN optimalen AF Filter gibt es halt nicht, da man entweder der Texturschärfe oder der Rauschanfälligkeit den Vorzug geben kann. Computerbase bevorzugt halt ruhigere Bilder durch matschigere Texturen. Darüber lässt sich jetzt natürlich vortrefflich streiten... :wink:

[Raff]

Das müsste AMD beantworten. Einige Texturen wirken eigentlich zu unscharf für nur +0,1. Achte mal auf die Hauswand zwischen 7800 und 6900. Oder die Steintextur in Skyrim. Hier würe ich wohl ein leicht stärkeres flimmern bevorzugen.

Eine Anfrage an AMD ist raus und ich sehe mir das jetzt mal live an.

MfG,
Raff

[Raff]

So. Die Schärfe hat definitiv zugenommen und das Flimmern ebenfalls. Insofern gehe ich mit Computerbase d'accord. Aber: HQ ist und bleibt besser – das ist der einzige mit Nvidia vergleichbare Modus.

MfG,
Raff

[aufkrawall]

Würdest du immer noch Q für SGSSAA empfehlen?

[Raff]

Yep. 4x SGSSAA genügt, um das neue Q flimmerfrei zu keulen und Q bringt gerade mit SSAA ein paar Prozentchen. Habe einige Runden Dirt 3 mit 4x SGSSAA/16:1 Q-AF hinter mir und es ist fast tadellos – von Fieslingstexturen wie einem feinen, hell-dunklen Wellblech abgesehen.

MfG,
Raff

[Ronny145]

So. Die Schärfe hat definitiv zugenommen und das Flimmern ebenfalls. Insofern gehe ich mit Computerbase d'accord. Aber: HQ ist und bleibt besser – das ist der einzige mit Nvidia vergleichbare Modus.

MfG,
Raff


Was macht in Cat 12.4 HQ besser als Q?

[MechWOLLIer]

So. Die Schärfe hat definitiv zugenommen und das Flimmern ebenfalls. Insofern gehe ich mit Computerbase d'accord. Aber: HQ ist und bleibt besser – das ist der einzige mit Nvidia vergleichbare Modus.

MfG,
Raff

Schön, dass du unsere Beobachtungen auch bestätigen kannst!
Beim Stand vom Cat 12.4 stimme ich da mit dir da vollends überein. Beim alten Stand...gefällt mir Q echt ein wenig besser als HQ - aber wohl Geschmackssache :)

Was macht in Cat 12.4 HQ besser als Q?
Kurz und knapp: Es flimmert weniger. HQ ist auf dem gleichen Stand wie vorher geblieben.

[Ronny145]

Kurz und knapp: Es flimmert weniger. HQ ist auf dem gleichen Stand wie vorher geblieben.


Ich dachte Q wäre auf das HQ Niveau gebracht wurden. Gibt es Videos zwischen dem neuen Q und HQ?

[Raff]

Die Texturschärfe von Q ist auf HQ-Niveau gebracht worden. In etwa. Zuvor war das Texture LOD minimal positiv; eventuell hat AMD noch etwas getweakt. Das positive LOD ist noch ein Relikt aus Barts- und Cayman-Zeiten, das man dort anwendete, um die Auswirkungen der falsch verteilten Samples (resultierend in selektiver Unterfilterung) zu mildern. Jedenfalls führt das auch auf GCN dazu, dass Q wieder mehr flimmert als früher – klar, denn eingesparte Samples führen zu Flimmern und der unelegante Gegenspieler fehlt nun.

MfG,
Raff

[Ronny145]

Das positive LOD ist noch ein Relikt aus Barts- und Cayman-Zeiten, das man dort anwendete, um die Auswirkungen der falsch verteilten Samples (resultierend in selektiver Unterfilterung) zu mildern.


Liest man immer wieder. Aber: unter Quality gab es kein positives Lod mit Barts/Cayman. Ihr verwechselt das mit dem Performance Modus. Der sah, so weit ich mir erinnern kann, allerdings noch ein Tick unschärfer aus.

[Raff]

Ich habe kurz echt gegrübelt, ob ich etwas verwechsel. Du verwirrst mich. :D

Dennoch: Bei Q ist (bzw. war) das AF minimal positiv. Bei Performance ist's noch schlimmer. Ich zitiere mal die PCGH 03/2012 (http://shop.computec.de/pcgameshardware/heftbestellung/monatsausgaben/pc-games-hardware-magazin-03-2012.html) (Seite 48, Artikel "HD 7000 Praxis"):

http://666kb.com/i/c3b08a6j2u35l7h8h.jpg

Um das fortzuführen noch etwas mehr aus dem gleichen Artikel:

http://666kb.com/i/c3b08goop2suyzx1d.jpg

MfG,
Raff

[Ronny145]

Das leicht positive Lod unter Quality auf der HD700 hat keiner angezweifelt. Mir ging es um das Relikt aus alten Zeiten. Das ist/war eher Absicht, denn wie gesagt hat AMD damals für Barts/Cayman nur den Performance Modus blurriger gestaltet.

[Raff]

Ah, ja, da war was. :)

MfG,
Raff

[Coda]

um die Auswirkungen der falsch verteilten Samples (resultierend in selektiver Unterfilterung) zu mildern.
Sie waren nicht falsch verteilt. Das Problem war irgendwas beim Zusammenrechnen.

[Ronny145]

Laut PCGH 08/2012 brachte das neue Quality AF im Catalyst 12.4 etwas mehr Leistung bei mehr flimmern und weniger Unschärfe.

@aufkrawall

noch im Besitz der HD7970? Mich würde interessieren, ob sich das AF im 12.6 und neuer nochmals verändert hat. Besonders das Quality AF. HQ wird sicher unangetastet bleiben. Wäre ein 720p Schienenvideo mit Quality möglich?

[Raff]

Wer den modernen Worstcase sehen möchte, schmeißt mal Rage mit Ingame-Nachschärfung an. Der Boden flimmert auf einer HD 7000 auch mit HQ, außerdem ist Banding zu sehen – das Spiel fordert nur Bi-AF-Grütze an, die selbst mit der besten Einstellung im Spiel nicht weggeht. Immerhin hilft SGSSAA ohne Unschärfe gegen das Flimmern, aber das Banding bleibt. Aber mit SGSSAA gibt's dann andere Grafikfehler ... :ugly: Eine Geforce filtert sauber, wird aber mit SGSSAA deutlich matschiger.

Das ist der einzige Fall, wo mir das HD-7000-AF derzeit negativ ins Auge sticht.

MfG,
Raff

[Skysnake]

Wenn das Game nur Bi-AF anfordert, haelt sich nVidia dann auch daran? Oder verwenden die wieder Tri-AF wie unter Risen glaub ich wars.

[Blaire]

Wenn das Game nur Bi-AF anfordert, haelt sich nVidia dann auch daran? Oder verwenden die wieder Tri-AF wie unter Risen glaub ich wars.

Klar, warum sollte das nicht so sein? Aufkrawall hat es auch erst kürzlich am Beispiel HL2 überprüft: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=540796&highlight=Trilinear
Banding war schon immer eher Problem auf Ati (jetzt AMD)-Karten, während NV meist sauber filterte. Auch damals beim Launch der HD7970 brauchte es wohl erst einen Hack von Coda (Hardtecs4u-Review), bevor man die Karten dazu "überreden" konnte, trilinear zu filtern.

[Gipsel]

Banding war schon immer eher Problem auf Ati (jetzt AMD)-Karten, während NV meist sauber filterte. Auch damals beim Launch der HD7970 brauchte es wohl erst einen Hack von Coda (Hardtecs4u-Review), bevor man die Karten dazu "überreden" konnte, trilinear zu filtern.Banding ist mit Bi-AF immer ein Problem, auch wenn sauber gefiltert wird. ;)

Aber ich habe irgendwie im Hinterkopf, daß es bei Bi-AF eventuell noch ein Problem auf AMD-Karten gibt. Also nicht, daß es Bi ist (das muß so, wenn die Engine das so will), sondern daß dann nicht ganz sauber gefiltert wird. Tri-AF ist sauber, weswegen der Tri-Hack dann sowohl Banding beseitigt (was man auf nV mit Bi-AF auch sieht) als auch korrekt filtert.

[Coda]

Es gibt noch ein Problem mit Bi-AF und AMD, ja. Das hab ich zum Launch detailiert untersucht mit den Leuten von HT4U.

Allerdings kann man Bi-AF sowieso nur vor D3D10 anfordern, deshalb sehe ich das als geringes Problem an.

[aufkrawall]

Wenn Rage nur bi anfordern würde, müsste es doch auch auf NV, trotz besserer Filterung, Banding geben.

[Raff]

Es gibt noch ein Problem mit Bi-AF und AMD, ja. Das hab ich zum Launch detailiert untersucht mit den Leuten von HT4U.

Allerdings kann man Bi-AF sowieso nur vor D3D10 anfordern, deshalb sehe ich das als geringes Problem an.

Würde der Treiber bei HQ einfach immer nur Tri-AF liefern, wäre das gegessen.

MfG,
Raff

[Skysnake]

Naja, das Spiel fordert aber was anderes an....

Eigentlich sollten die Entwickler am Besten wissen, was Sie machen. Ich bin absolut kein Freund davon, denen ins Handwerk zu pfuschen....

Und sei es nur deswegen, das man mit dem Finger auf Sie zeigt und sagt:Ihr habt SCHEISE gebaut!

Das diszipliniert die Entwickler.

Die Treibereingriffe der GPU-Hersteller sind daher ein SEHR zweischneidiges Schwert...

[Raff]

Mir konnte immer noch niemand erklären, warum es sinnvoll sein kann, bi stratt tri anzufordern. Könnt ihr das? :)

MfG,
Raff

[fondness]

Mir konnte immer noch niemand erklären, warum es sinnvoll sein kann, bi stratt tri anzufordern. Könnt ihr das? :)

MfG,
Raff

Man hat die doppelte Texelrate zu Verfügung.

[Gipsel]

Mir konnte immer noch niemand erklären, warum es sinnvoll sein kann, bi stratt tri anzufordern. Könnt ihr das? :)
Oder man macht irgendwas Abgefahrenes und will nicht, daß verschiedene MipMaps ineinander geblendet werden (weil da z.B. unterschiedliche Sachen drin liegen, warum oder aus welchem Grund auch immer).

[aufkrawall]

Wenn Rage nur bi anfordern würde, müsste es doch auch auf NV, trotz besserer Filterung, Banding geben.
*bump*
Beim alten Serious Sam war mit mit GCN afair auch Banding aufgefallen, obwohl ich im Spiel tri eingestellt hatte.

[Raff]

Man hat die doppelte Texelrate zu Verfügung.

War nicht auf die Leistung bezogen, sondern ...

Oder man macht irgendwas Abgefahrenes und will nicht, daß verschiedene MipMaps ineinander geblendet werden (weil da z.B. unterschiedliche Sachen drin liegen, warum oder aus welchem Grund auch immer).

... auf sowas, das wohl nur Entwickler wissen können. Scheint ja nicht so viel zu geben. :D

*bump*
Beim alten Serious Sam war mit mit GCN afair auch Banding aufgefallen, obwohl ich im Spiel tri eingestellt hatte.

First oder Second Encounter? Ich kenne das nur mit SGSSAA und HQ-Config, aber da hatte ich nie Banding.

MfG,
Raff

[Peter Gräber]

Es liegt an der Stelle offenbar tatsächlich an der Konsolenportierung - so zumindest der Eindruck von Coda und mir, gezeigt im HD 7970 Launch. An der Ecke hat AMD zwar den Fehler gekannt, aus irgendwelchen Gründen ihn nicht gefixt. Man hat wohl unterstellt, dass es zu selten auftritt. Zu einer exakten Bestätigung unserer Videos und Vermutungen hat sich AMD dann nicht mehr hinreißen lassen.

Im Resultat ist das natürlich undankbar wenn es auftritt. Ich gehe aber mal davon aus, dass wir spätestens mit der Einführung der neuen Konsolen vermutlich nichts mehr davon sehen werden - allenfalls in weiterhin schlechten Umsetzungen.

[aufkrawall]

First oder Second Encounter? Ich kenne das nur mit SGSSAA und HQ-Config, aber da hatte ich nie Banding.

Second. Kannst in der Config die Gräser komplett abstellen, dann hast du im Technologytestlevel praktisch ne D3D8 & OpenGL Filter-Testapp.
Mit SGSSAA war das Banding auch verschwunden. Es sollte ohne SGSSAA bei ausgewählter trilinearer Filterung aber auch nicht vorhanden sein.
Ist lange her, bräuchte mal nen Radeon-Testrechner...

[Match-Maker]

In GTR 2 flimmern selbst mit 16:1 HQ-AF, 4xSGSSAA + SMAA und LoD -0,5 einige Texturen relativ stark.

[Raff]

Dann hat das Spiel einfach 'nen Drecks-Content. Sowas kommt vor, praktischerweise selten.

MfG,
Raff

[Match-Maker]

Ja, das hab ich mir auch schon gedacht. Da kann man echt kaum was machen.

[Raff]

8x SGSSAA und LOD 0.0 mal probiert? :D

MfG,
Raff

[Match-Maker]

Jagut, das könnte helfen. Mal ausprobieren, wobei die Fps mit 8xSGSSAA wahrscheinlich in einigen Situationen etwas zu gering sein werden.

[aufkrawall]

Dann hat das Spiel einfach 'nen Drecks-Content. Sowas kommt vor, praktischerweise selten.

MfG,
Raff
Hab mir gerade mal die Demo gezogen, die Grastextur ist wirklich recht übel. Zu übel, vermutlich fordert die App schon selber negatives LOD-Bias an.
Vielleicht addiert sich das mit dem Treiber-Bias? Einfach letzteres niedriger einstellen.

[Raff]

Das lässt sich doch recht einfach mithilfe des Clamp-Schalters überprüfen. :)

MSAA mit 16x AF ohne Clamp: vermutlich starkes Flimmern
MSAA mit 16x AF und Clamp: vermindertes Flimmern?

MfG,
Raff

[aufkrawall]

Der Clamp-Schalter ist seit Fermi leider nicht mehr funktionsfähig.

Na ja, ich würde es einfach mit 32xSSAA ohne zusätzliches LOD-Bias spielen. :tongue:

[Raff]

Huh? Bei meinen letzten Tests schien der sauber zu funktionieren. Der greift nur bei aktivem AF, sonst nicht.

MfG,
Raff

[aufkrawall]

Huh? Bei meinen letzten Tests schien der sauber zu funktionieren. Der greift nur bei aktivem AF, sonst nicht.

MfG,
Raff
Geht hier nicht:
http://abload.de/thumb/clampc0ufi.jpg (http://abload.de/image.php?img=clampc0ufi.jpg)

Auch mit D3D1x nicht.

Edit: Steht übrigens auch in den Release-Notes.

[Gipsel]

AF "High Qualität" auf Nvidia Niveau?Du kannst sicher erläutern, was sich da bei Tri-AF (bestmögliches AF, unter DX10/11 gibt es gar nichts anderes mehr) für Unterschiede zeigen, richtig? :rolleyes:

[Duplex]

Du kannst sicher erläutern, was sich da bei Tri-AF (bestmögliches AF, unter DX10/11 gibt es gar nichts anderes mehr) für Unterschiede zeigen, richtig? :rolleyes:
Die Leute mit der grünen Brille sehen bei der Qualität permanent einen Unterschied :D:D
Nein im ernst, es gibt genügend Leute die behaupten und wissen das Nvidias AF HQ besser als AMDs aussieht!
Gefällt dir nicht?

[Ronny145]

Du kannst sicher erläutern, was sich da bei Tri-AF (bestmögliches AF, unter DX10/11 gibt es gar nichts anderes mehr) für Unterschiede zeigen, richtig? :rolleyes:


GCN flimmert deutlich mehr.

[aufkrawall]

Du kannst sicher erläutern, was sich da bei Tri-AF (bestmögliches AF, unter DX10/11 gibt es gar nichts anderes mehr) für Unterschiede zeigen, richtig? :rolleyes:
Es flimmert immer noch sichtbar mehr, etwa mit der Ground2-Textur aus dem Filtertester, und zumindest unter DX9 gibt es immer noch Fälle von Banding:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9895641&postcount=26
Man kann jetzt rätselraten, ob letzteres unter DX1x nicht auftritt. Eigentlich fordert unter DX9 so ziemlich jede App tri an. Entweder ist dann wirklich noch was an der Filterung schlecht, oder der Treiber baut kolossalen Mist.

Natürlich ist es nicht in jeder Situation sichtbar schlechter, im Zeitalter von massenhaften ekligen Flimmershadern vielleicht auch etwas relativiert.
Ich will trotzdem keine Abstriche machen und auch bei alten Spielen mich nicht mit so einem Mist rumärgern müssen.

@Duplex: Hä, wieso sprichst du mich damit an?
AMD hat DS im Treiber gekillt und SGSSAA-Enhance für DX11 nur arg widerwillig eingeführt. Man wird sich kaum die Mühe machen, bei Mantle weiter gegen den Willen der App-Entwickler rumzuhacken.

[Gipsel]

Um den OT-AF-Kram abzuschließen, iIn den von mir genannten Situationen flimmert da gar nichts. Nur bei bi-AF (was es unter DX10/11 nicht mehr gibt) sieht man überhaupt irgendwelche wesentlichen Unterschiede (also nicht nur die praktisch kaum wahrnehmbare, minimale Winkelabhängigkeit von nV). Und das gibt es nur, wenn die App das anfordert.

Und jeder, der da noch weitergehenden Diskussionsbedarf hat, kann gerne einen der AF-Threads wiederbeleben, wo das nun schon mehrfach zu Tode diskutiert wurde.

[aufkrawall]

Um den OT-AF-Kram abzuschließen, in den von mir genannten Situationen flimmert da gar nichts. Nur bei bi-AF (was es unter DX10/11 nicht mehr gibt) sieht man überhaupt irgendwelche wesentlichen Unterschiede (also nicht nur die praktisch kaum wahrnehmbare, minimale Winkelabhängigkeit von nV). Und das gibt es nur, wenn die App das anfordert.

Stell dir vor, Ronny und ich sprachen vom D3D10 Filtertester...

[Skysnake]

AF "High Qualität" auf Nvidia Niveau?

Ist es jetzt schon. Die Filterqualität ist absolut auf gleichem lvl angekommen. Sie ist nur nicht 100% identisch. Das hat aber nichts mit besser/schlechter zu tun, sondern einfach nur mit anders.
Die Leute mit der grünen Brille sehen bei der Qualität permanent einen Unterschied :D:D
Nein im ernst, es gibt genügend Leute die behaupten und wissen das Nvidias AF HQ besser als AMDs aussieht!
Gefällt dir nicht?
JA und das ist einfach bullshit. Es ist einfach nur "anders".

Es flimmert immer noch sichtbar mehr, etwa mit der Ground2-Textur aus dem Filtertester, und zumindest unter DX9 gibt es immer noch Fälle von Banding:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9895641&postcount=26
Man kann jetzt rätselraten, ob letzteres unter DX1x nicht auftritt. Eigentlich fordert unter DX9 so ziemlich jede App tri an. Entweder ist dann wirklich noch was an der Filterung schlecht, oder der Treiber baut kolossalen Mist.

Weil AMD da wo Bi-AF angefordert wird auch Bi-AF liefert und nicht einfach Tri-AF...

[Coda]

Weil AMD da wo Bi-AF angefordert wird auch Bi-AF liefert und nicht einfach Tri-AF...
Ich muss das jetzt trotzdem noch richtigstellen:

Das tut auch NVidia nicht. Das Bi-AF sieht nur wesentlich ruhiger aus, deshalb sieht man die Übergänge viel weniger. Ich dachte ursprünglich dass es einfach Tri-AF ist, dem ist aber nicht so.

Übrigens gibt es mit D3D10 und später sowieso kein Bi-AF mehr.

Vielleicht haben sie entzwischen ja aber auch noch diesen Bug gefunden. Irgendwie macht Tahiti da immer noch was beim Zusammenrechnen falsch. Mag auch eine Optimierung sein, wer weiß das schon.

[aufkrawall]

Ich muss das jetzt trotzdem noch richtigstellen:

Zeitverschwendung, diesen Mythos kriegst du nicht mehr raus :redface: :
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=540796

Jetzt sag ich hier aber auch nichts mehr zu AF etc. :rolleyes:

[Ronny145]

Stell dir vor, Ronny und ich sprachen vom D3D10 Filtertester...


Ich sprach auch von HL2. Wenn von einem Catalyst zum nächsten das Flimmern ansteigt, hat das nichts mit bi-AF zu tun. AMD hat das AF in Richtung mehr Flimmern "optimiert", weil es Blur Probleme an Texturen gab. Die ganzen launch Videos mit fast annähernd der Nvidia Bildruhe haben seit langer Zeit keine Gültigkeit mehr. In HL2 flimmert es deutlich stärker, natürlich auch im Filtertester. Das wissen die wenigsten.

[DarknessFalls]

In HL2 flimmert es deutlich stärker, natürlich auch im Filtertester. Das wissen die wenigsten.

...möglicherweise weil HL2 inzwischen sieben Jahre alt ist? Vielleicht auch, weil dieses "Problem" abseits von HL2 und irgendwelchen Filtertestern gar nicht auffällt?

[OBrian]

Die alten Evergreens betrifft das aber nicht, oder? Deswegen habe ich wohl einen Unterschied gesehen, als ich meine 5850 probeweise gegen eine 7870 getauscht hatte (in einem DX9-Spiel, Arma2). Mich deswegen als Nvidia-Fanboy hinzustellen, wäre unfair, meine letzte NV war eine Geforce 2 GTS, und einfach sinngemäß zu behaupten, das wäre nicht so und ich würde Scheiße erzählen, schmerzt etwas und hilft mir auch nicht, ich finde das Bild trotzdem flimmeriger. Ein Grund, warum ich die 7870 wieder weggeschickt habe.

Ich hoffe ja auf eine Verbesserung dieser Situation, wenn neue Karten eingeführt werden, schließlich kann ich nicht ewig auf meiner 5850 hocken bleiben und ein "Upgrade" auf zwei 5870 plus neues NT erscheint mir wenig sinnig.

Oder muß man sich einfach dran gewöhnen? Ich meine, vor zwanzig Jahren gings ja auch ohne diesen neumodischen Kram, und man kann ja nicht immer nur Fortschritte erwarten, manchmal gibt es eben auch Rückschritte. Hoffentlich werden meine Augen bald schlechter, dann muß ich das eh nicht mehr so genau sehen.

[Gipsel]

Die alten Evergreens betrifft das aber nicht, oder?Die betrifft was nicht? Die hatten (bzw. haben ihn natürlich immer noch) einen Bug im AF-Filter, der die einzelnen Samples mit falschen Gewichten verrechnet hat.

[OBrian]

ich bezog mich auf den Beitrag von Ronny145 zwei Posts drüber.

und deswegen flimmern die nicht so?

[aufkrawall]

...möglicherweise weil HL2 inzwischen sieben Jahre alt ist? Vielleicht auch, weil dieses "Problem" abseits von HL2 und irgendwelchen Filtertestern gar nicht auffällt?
Das hat bestimmt nichts mit HL2, sondern mit den verwendeten Texturen zu tun.

@Ronny: HQ war doch schon immer flimmerig bei GCN, oder meinst du, es ist noch schlimmer geworden?
Bei Q wurd ja das positive LOD-Bias "gefixt", sollte also in etwa wie HQ + bri-Banding sein.

[Angiesan]

Doch es fällt im Direkten Vergleich sehr wohl auf, es ist so das AMD AF auch... ne falsch gerade auf HQ zum Teil deutlich mehr flimmert. Dafür bleibt es etwas länger scharf, als ob man da am LOD geschraubt hätte etweder bei NV oder AMD.
Schaut euch mal FC3 und Crysis an da sieht man das recht gut.

Das Ergebnis von NV und AMD unterscheidet sich da deutlich ob jetzt der eine oder andere optimiert hat kann ich nicht sagen, fakt ist NV AF flimmert hier weniger ist aber auch nicht so scharf gerade in der Distanz das Ergebnis ist auf NV einfach angenehmer.
Es ist wirklich seltsam und es gibt auch die ein oder andere Anwendung wo ich absolut keinen Unterschied erkennen kann und solcher gerade mit Gitterboden wo AMD zum Teil weniger bzw keine Moir -Effekte produziert im Gegensatz zu NV . Das findet man aber recht selten in aktuellen Spielen.
Das Gefängnis - Level von Remember me hat so ein paar Bodenflächen wo man diese Unterschiede erkennen kann Crysis 3 wo es diese Böden auch gibt im ersten Level zeigt z.B. keine Unterschiede.

Mein Fazit das NV HQ AF ist fast immer optimal vom Ergebnis das AMD hängt deutlich stärker an der Anwendung, kann gleichwertig, besser aber auch mal deutlich schlechter sein.Ich für meinen Teil empfinde das Q AF bei AMD oft angenehmer wie das HQ AF.
Wer jetzt am Ende da was optimiert ist mir eigentlich egal das Ergebnis zählt für mich und da ist NV oft noch einen Tick angenehmer.

[Gipsel]

Das tut auch NVidia nicht. Das Bi-AF sieht nur wesentlich ruhiger aus, deshalb sieht man die Übergänge viel weniger.Ich glaube wir hatten das ja schonmal kurz angesprochen, aber unabhängig von AMDs bi-AF-Schwäche könnte man vielleicht insofern auch etwas optimieren, in dem man nicht äquidistant entlang der Line of anisotropy sampelt, insbesondere an den MipMap-übergängen. Da könnte man (bei der Grenze zwischen 8x und 16x wird es schwierig was zu sehen, aber bei den niedrigen Stufen könnte es sichtbar sein) einen ewas ruhigeren Bildeindruck an den Mip-Übergängen erzielen, auch wenn filtertechnisch beides okay wäre. Und man muß auch nicht unbedingt die Tapanzahl sofort verdoppeln, sondern könnte die auch nach Bedarf langsam hochfahren (z.B. 4x, 6x, 8x, 10x, 12x, 14x, 16x). Das macht den Filter etwas komplizierter, kostet aber vermutlich keine Qualität bzw. verringert sogar eventuell minimal die sichtbaren Übergänge und bringt sogar noch eine höhere Performance (weniger taps im Mittel, das würde auch zur Performanceskalierung bei nV passen).

[Tesseract]

JA und das ist einfach bullshit. Es ist einfach nur "anders".

in allen fällen, die ich bisher gesehen habe, ist nvidias filterung subjektiv näher am resultat, das man durch supersampling erreichen würde und das sehe ich definitiv als "besser" an.
der unterschied ist zwar so gering, dass ich das im gegensatz zu früher nicht mehr als wesentlichen aspekt in einer kaufentscheidung heranziehen würde aber subjektiv finde ich definitiv codas referenz > intel ~ nvidia > amd.

[aufkrawall]

Das Gefängnis - Level von Remember me hat so ein paar Bodenflächen wo man diese Unterschiede erkennen kann.
War das mit SGSSAA?

[Gipsel]

gerade mit Gitterboden wo AMD zum Teil weniger bzw keine Moir -Effekte produziert im Gegensatz zu NV . Das findet man aber recht selten in aktuellen Spielen.AMD macht offenbar irgendwas Obskures, um solche Moirees stärker zu unterdrücken (das geht meiner Meinung nach nicht allein mit dem Filter). Das hat man auch schon bei den Evergreens bzw. NIs gesehen. Bei diesen "Discworld"-Shots wurden ja die Übergänge extrem stark rausgekitzelt, aber das einfarbige Grau in der Mitte (statt Moiree bei nV) war zumindest dort prinzipiell das besser (sogar perfekt) gefilterte Ergebnis (aber der Bug verursachte eben die auffälligen Übergänge, evtl. auch im Zusammenspiel mit den manuell gesetzten [und falsch bzw. gar nicht gefilterten] MipMaps).

[Skysnake]

in allen fällen, die ich bisher gesehen habe, ist nvidias filterung subjektiv näher am resultat, das man durch supersampling erreichen würde und das sehe ich definitiv als "besser" an.
der unterschied ist zwar so gering, dass ich das im gegensatz zu früher nicht mehr als wesentlichen aspekt in einer kaufentscheidung heranziehen würde aber subjektiv finde ich definitiv codas referenz > intel > nvidia > amd.
Das ist aber immer NUR eine subjektive Gewichtung, in welcher Reihenfolge die GPU-Implementierungen kommen.

Für mich ist z.B. das Flimmern weniger "schlimm" als das bluren. Das manche Sachen halt einfach flimmern ist für nich normal. Das ist halt einfach die unzulänglichkeit in der Grafikdarstellung. Bluren empfinde ich dagegen immer als pfui bäh!

Ich kann aber auch verstehen, das jemand das flimmern störender findet. Das ist halt "Geschmackssache"

[Tesseract]

Das ist aber immer NUR eine subjektive Gewichtung, in welcher Reihenfolge die GPU-Implementierungen kommen.

da wär ich mir nicht so sicher da sich die implementierungen definitiv grundlegender unterscheiden als meistens behauptet wird. gerade mit hochfrequenteren texturen kommen unterschiedlichste effekte zum vorschein die das nahelegen. intel ist am besten beim blenden der mip-stufen, codas implementierung ist die mit abstand beste auf der nativen texturgröße, amd ist am besten bei extrem flachen texturen usw.
da steckt wohl mehr dahinter als nur eine simple sample-gewichtung - oder einige gewichtungen haben definitiv gravierendere schwächen als andere.

ich konnte btw. bisher auch keinen größeren blur bei nvidia ausmachen. amds bild ist kontrastreicher da die farben mehr rumspringen aber der detailgrad scheint der selbe zu sein.

[aufkrawall]

ich konnte btw. bisher auch keinen größeren blur bei nvidia ausmachen. amds bild ist kontrastreicher da die farben mehr rumspringen aber der detailgrad scheint der selbe zu sein.
So sieht es wohl aus. Mit dem gefixten neg. LOD-Bias bei NV wäre man ähnlich flimmerig wie AMD, dabei aber detailreicher.

[Skysnake]

da wär ich mir nicht so sicher da sich die implementierungen definitiv grundlegender unterscheiden als meistens behauptet wird. gerade mit hochfrequenteren texturen kommen unterschiedlichste effekte zum vorschein die das nahelegen. intel ist am besten beim blenden der mip-stufen, codas implementierung ist die mit abstand beste auf der nativen texturgröße, amd ist am besten bei extrem flachen texturen usw.
da steckt wohl mehr dahinter als nur eine simple sample-gewichtung.

ich konnte btw. bisher auch keinen größeren blur bei nvidia ausmachen. amds bild ist kontrastreicher da die farben mehr rumspringen aber der detailgrad scheint der selbe zu sein - oder einige gewichtungen haben definitiv gravierendere schwächen als andere.
Eben, es ist "anders". Ich würde mir aber nicht anmaßen wollen, zu entscheiden, was "besser" ist. Es ist einfach nur anders, mit unterschiedlichen Gewichtungen.

Man kann halt nicht wirklich die Eierlegendewollmilchsau haben :rolleyes:

[aufkrawall]

Und ich dachte, du spielst gar nicht.

[Tesseract]

Eben, es ist "anders". Ich würde mir aber nicht anmaßen wollen, zu entscheiden, was "besser" ist. Es ist einfach nur anders, mit unterschiedlichen Gewichtungen.

ich habe mich nicht besonders intensiv damit beschäftigt weil der unterschied nicht all zu groß ist aber was sich unterscheidet kann man prinzipiell vergleichen und anhand verschiedener kriterien bewerten. deine apologetik ist da eher fehl am platz.

[Skysnake]

Du kannst aber nicht alles haben mit normalen AF Mittelen. Entweder es blurt etwas mehr, oder man hat etwas mehr flimmern. Moire-Effekte kommen auch noch dazu.

Es gibt soooo viele Spezial/Worstcase-Fälle, wenn du bock hast, kannste jede Technick schlecht aussehen lassen... Du musst nur wissen wie.

[Tesseract]

Du kannst aber nicht alles haben mit normalen AF Mittelen.

es geht nicht darum alles zu haben, es geht darum einen guten kompromiss aus vor- und nachteilen zu haben. das ist bei fast jedem algorithmus im echtzeit-rendering so. nur weil in diesem fall die unterschiedlichen implementierungen an bestimmten herstellern hängen bedeutet das nicht, dass keine diskussion darüber erlaubt/erwünscht ist.

[OBrian]

Das ist aber immer NUR eine subjektive Gewichtung, in welcher Reihenfolge die GPU-Implementierungen kommen.

Für mich ist z.B. das Flimmern weniger "schlimm" als das bluren. Das manche Sachen halt einfach flimmern ist für nich normal. Das ist halt einfach die unzulänglichkeit in der Grafikdarstellung. Bluren empfinde ich dagegen immer als pfui bäh!

Ich kann aber auch verstehen, das jemand das flimmern störender findet. Das ist halt "Geschmackssache"Für mich ist Flimmern unangenehmer, weil es unrealistischer aussieht. Matsch könnte ich noch als "Bodennebel" oder schlechte Augen oder sowas interpretieren, aber wenn es flimmert, sieht es einfach zu künstlich und nach Computergrafik aus.

Wäre also gut, wenn man diese Einstellung je nach persönlichem Empfinden verstellen könnte. Immerhin geht es ja wohl um eine Balance, die einen unechten Kompromiß zwischen zwei Übeln darstellt und daher nie richtig gut sein kann. Ich befürchte nur, mit dem Trend, die Einstellungen immer mehr auf die Engine abzuwälzen, wird sowas immer weiter vernachlässigt. Selbst wenn die Engine es könnte, investieren die Gameentwickler dann keine Ressourcen, um das auch tatsächlich einstellbar zu machen (wobei mir schon eine Config-Datei reichen würde).

Alles immer mit SSAA zu behandeln, hilft zwar, aber ist mit Kanonen auf Spatzen geschossen, SSAA wird man sich nie "einfach so" leisten können, gerade wo jetzt auch noch die 4K-Ära anfängt. Es muß auch ohne SSAA ein gutes Ergebnis geben können.

[Angiesan]

War das mit SGSSAA?

Ich meine, ja war mit in game SSAA ich habe das auf dem NV Rechner jetzt nicht installiert nur auf dem AMD damals aber noch mit GTX 780 gegengetestet.
Die AMD ist halt immer noch die HD 7950. Frag mich jetzt nicht was für ein Treiber das war :-)

[Iruwen]

Für mich ist Flimmern unangenehmer, weil es unrealistischer aussieht. Matsch könnte ich noch als "Bodennebel" oder schlechte Augen oder sowas interpretieren, aber wenn es flimmert, sieht es einfach zu künstlich und nach Computergrafik aus.

dito, Unschärfe kommt "in echt" halt auch viel häufiger vor als so auffälliges Flimmern, da reagier ich empfindlicher drauf. Als -4 Dioptrien Blindfisch erst recht :D

[Skysnake]

Für mich ist Flimmern unangenehmer, weil es unrealistischer aussieht. Matsch könnte ich noch als "Bodennebel" oder schlechte Augen oder sowas interpretieren, aber wenn es flimmert, sieht es einfach zu künstlich und nach Computergrafik aus.

Aber GENAU das ist Sie doch auch ;)
Computergrafik eben :tongue:

Für mich gehört das irgendwo einfach zu PC-Grafik dazu, genau wie die "Bugwelle" vom Filtering. Das passiert halt, wobei ich die "Bugwelle" durchaus als unschön empfinden kann. Kommt halt immer darauf an, wie fesselnd ein Game ist. Im Normalfall hab ich gar nicht die Zeit auf so was groß zu achten.


Wäre also gut, wenn man diese Einstellung je nach persönlichem Empfinden verstellen könnte. Immerhin geht es ja wohl um eine Balance, die einen unechten Kompromiß zwischen zwei Übeln darstellt und daher nie richtig gut sein kann. Ich befürchte nur, mit dem Trend, die Einstellungen immer mehr auf die Engine abzuwälzen, wird sowas immer weiter vernachlässigt. Selbst wenn die Engine es könnte, investieren die Gameentwickler dann keine Ressourcen, um das auch tatsächlich einstellbar zu machen (wobei mir schon eine Config-Datei reichen würde).

Das wirste aber wohl nie haben, weil es eben nicht nur Software ist.


Alles immer mit SSAA zu behandeln, hilft zwar, aber ist mit Kanonen auf Spatzen geschossen, SSAA wird man sich nie "einfach so" leisten können, gerade wo jetzt auch noch die 4K-Ära anfängt. Es muß auch ohne SSAA ein gutes Ergebnis geben können.
Ja definitiv!

Deswegen sollte/muss man sich halt auch mit gewissen Punkten abfinden. Die Alternativen sind einfach keine echte Option.

[Iruwen]

Man muss sich aber nicht damit abfinden wenn es eine billige Möglichkeit gibt es zu vermeiden (und einer nur zu blöd dazu ist). Für mich gehört das nicht dazu, und sowas wie eine Bugwelle fällt mir sofort auf und ist ein echter Immersions-Breaker.

[Coda]

Meine Implementierung ist übrigens nicht Gamma korrekt. Ich glaube das erklärt das Restflimmern.

Muss ich irgendwann mal ändern.

[StefanV]

Naja, wer mal wirklich was flimmern sehen möchte, kann ja mal Final Fantasy X-II rauskramen und sich die 'Stille Ebene' anschauen...

Bei X ist das natürlich auch der Fall, nur dauerts beim ersten Versuch 'nen bisserl länger, bis man dort is. Beim 2. Teil ist das relativ am Anfang...

[Coda]

Doll, hat total Relevanz für dieses Thema.

[Skysnake]

Sollte es nicht eigentlich eh "immer" etwas flimmern, so lange man standard IEEE FP Multiplikationen nutzt?

Da wird ja im Standardverfahren nicht immer gleich gerundet. Zumindest meine ich das so verstanden zu haben, als ich mich mal mit den Unterschieden bei den einzelnen IEEE FP-Versionen eingelesen habe.

[Skysnake]

Das würdest Du nicht sehen.

Das Linestitching beim Zeichnen eines Wireframes über nen solid object in OpenGL hat ja aber genau den Grund. Rundungsdifferenzen.

Ich würde das sooo pauschal daher nicht von der Hand wischen. Lass mich aber gern vom Gegenteil überzeugen. Bin in dem Bereich jetzt nicht voll drin. ;)

[aths]

Ich hab in den Filter-Tester mal kurz Gamma-Correction eingebaut: Das bisschen Rest-Flimmern scheint leider doch relativ unbeeindruckt davon zu sein.Bei welcher Textur denn?

[Coda]

Bei den üblichen Verdächtigen.

[aths]

Welche denn konkret zum Beispiel?

[Coda]

Alle die dabei sind?

[Ronny145]

Die Grastextur flimmert mehr als ground1. Wo gibt es denn die Gamma korrigierte Version oder muss ich das erst kompilieren?

[Tesseract]

hm... entry point CreateFile2 not found in KERNEL32.dll.
irgend was ist da kaputt.

[Coda]

Ich hab's mit VC++ 2013 kompiliert und der Scheiß setzt per Default offenbar Windows 8 voraus X-D

[Ronny145]

Prozedureinsprungpunkt nicht gefunden.

[Coda]

Hab das Setup aktualisiert, sollte jetzt wieder ab Vista gehen. Selber Link.

[aths]

Alle die dabei sind?
Mit dieser Art macht es natürlich keinen Spaß, Input zu geben. Du wirfst gerne selbstgefällig ein paar Brocken hin, so als seine alle total erpicht darauf, sich in Coda-Exegese zu üben.

[Coda]

Ich hab gesagt, dass ich keinen Unterschied sehe bei allen Texturen die dabei sind. Was willst du noch von mir hören?

[Ronny145]

Bezüglich aktueller AMD Stand, hier vom Filtertester und Catalyst 13.10. Q-AF Video von AMD habe ich mir mal gespart, recht gleichwertig oder etwas schlechter als HQ.

660 Ti HQ 16xAF= http://s1.directupload.net/images/131009/5vwl56aw.png
660 Ti Q 16xAF= http://s1.directupload.net/images/131009/8uxt5yib.png

HD7950 HQ 16xAF= http://s1.directupload.net/images/131009/olr79g4h.png
HD7950 Q 16xAF= http://s1.directupload.net/images/131009/krx4g77o.png


http://www.file-upload.net/download-8158075/Filtertester.7z.html

[boxleitnerb]

Das sieht ja echt übel auf. Ich hatte auch mal ne AMD drin neulich und kommte damit etwas spielen, sowas hab ich dabei aber nicht gesehen. Ist das eher ein "akademisches" Problem oder tritt das auch in bestimmten Spielen auf? Gerade die drei getrennten Flimmerbereiche sind ja absolut fürchterlich, das hätte ich sicher gemerkt.

[Schaffe89]

AMD HQ vs. Nvidia HQ, sry ich sehe da nicht wirklich einen Unterschied, außer dass das Bild bei AMD schärfer ist und das bei Nvidia so wirkt als wenn ein Post Processing Filter drinn wäre ( Achtung Übertreibung).

Ihr sehr wie immer bei AMD die Probleme und verschließt euch von den potenziellen Problemen bei Nvidia.
Nix neues aus der Fanboyecke.:P;D

[boxleitnerb]

AMD HQ vs. Nvidia HQ, sry ich sehe da nicht wirklich einen Unterschied, außer dass das Bild bei AMD schärfer ist und das bei Nvidia so wirkt als wenn ein Post Processing Filter drinn wäre ( Achtung Übertreibung).

Ihr sehr wie immer bei AMD die Probleme und verschließt euch von den potenziellen Problemen bei Nvidia.
Nix neues aus der Fanboyecke.:P;D

Du solltest doch langsam mal kapiert haben, dass man Videos anschauen muss, um das zu beurteilen. Bevor du also rummeckerst, den Link, den Ronny nicht umsonst gepostet hat, mal öffnen, Video runterladen und dann kannst du wiederkommen und was Sinnvolles zur Diskussion beitragen.

[aufkrawall]

Man, sieht das "sauber" aus. :freak:
AMD kommt zwar auf ein wenig mehr AF, das lässt sich bei dem Geflimmer aber easy durch NVs sauberes LOD-Bias erreichen, ohne solche Flimmerstreifen.
Hier (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9895641&postcount=26) sieht man das Problem wohl auch Real World mit SGSSAA (ohne SGSSAA müsste es sonst ja auch Banding geben).

[boxleitnerb]

Ich sehe da nur Text, keine Videos ;)

[Raff]

Das sieht ja echt übel auf. Ich hatte auch mal ne AMD drin neulich und kommte damit etwas spielen, sowas hab ich dabei aber nicht gesehen. Ist das eher ein "akademisches" Problem oder tritt das auch in bestimmten Spielen auf? Gerade die drei getrennten Flimmerbereiche sind ja absolut fürchterlich, das hätte ich sicher gemerkt.

AFAIK ist's akademisch, solange man HQ-AF nutzt. Q ist doof, darüber brauchen wir nicht zu diskutieren.

MfG,
Raff

[aufkrawall]

Ich sehe da nur Text, keine Videos ;)
Könnte ja jemand mit einer Radeon beisteuern.

Was soll an dieser Textur akademisch sein?

[boxleitnerb]

AFAIK ist's akademisch, solange man HQ-AF nutzt. Q ist doof, darüber brauchen wir nicht zu diskutieren.

MfG,
Raff

Das Video ist mit HQ, nicht Q...

[Raff]

Ich rede von Spielen. ;) Dort ist HQ nie derart hässlich. Natürlich ist's möglich, dass auch ein Spiel mal so aussieht, wenn es den gleichen Content und die gleichen Wünsche an den Filter beisteuert.

MfG,
Raff

[aufkrawall]

Kann mir gut vorstellen, dass z.B. bei diversen Skyrim-Modtexturen es ähnlich flimmern könnte.

[Raff]

Vorstellen kann man sich viel. :D Ich denke, dass die neue Spielegeneration mit ihren feineren Texturen bald gute, neue Filtertester mit reichlich Praxisbezug abgeben wird ... :) Warten wir zunächst auf auf Battlefield 4 (SP), CoD Ghosts und Watch Dogs.

MfG,
Raff

[aths]

Ich hab gesagt, dass ich keinen Unterschied sehe bei allen Texturen die dabei sind. Was willst du noch von mir hören?
Wie die Texturen aussehen? Ein texelweises Schachbrettmuster wäre ja prinzipiell nicht ordentlich filterbar.


Bezüglich aktueller AMD Stand, hier vom Filtertester und Catalyst 13.10. Q-AF Video von AMD habe ich mir mal gespart, recht gleichwertig oder etwas schlechter als HQ.

660 Ti HQ 16xAF= http://s1.directupload.net/images/131009/5vwl56aw.png
660 Ti Q 16xAF= http://s1.directupload.net/images/131009/8uxt5yib.png

HD7950 HQ 16xAF= http://s1.directupload.net/images/131009/olr79g4h.png
HD7950 Q 16xAF= http://s1.directupload.net/images/131009/krx4g77o.png


http://www.file-upload.net/download-8158075/Filtertester.7z.html
Omg, bereits Q von Nvidia hat ein deutliches Flimmerband. HQ ist grenzwertig, aber akzeptabel.

[Tesseract]

Bezüglich aktueller AMD Stand, hier vom Filtertester und Catalyst 13.10. Q-AF Video von AMD habe ich mir mal gespart, recht gleichwertig oder etwas schlechter als HQ.

660 Ti HQ 16xAF= http://s1.directupload.net/images/131009/5vwl56aw.png
660 Ti Q 16xAF= http://s1.directupload.net/images/131009/8uxt5yib.png

HD7950 HQ 16xAF= http://s1.directupload.net/images/131009/olr79g4h.png
HD7950 Q 16xAF= http://s1.directupload.net/images/131009/krx4g77o.png


http://www.file-upload.net/download-8158075/Filtertester.7z.html

was ist denn da kaputt? das sieht ja fast wieder aus wie das 5xxx-AF. bei der checker-textur ist sogar eine harte banding-kante drin.
ich bilde mir ein das war schon mal besser - kann es sein, dass da was bei einem treiberupdate passiert ist? das ist jedenfalls absolut widerlich.

AMD HQ vs. Nvidia HQ, sry ich sehe da nicht wirklich einen Unterschied, außer dass das Bild bei AMD schärfer ist und das bei Nvidia so wirkt als wenn ein Post Processing Filter drinn wäre ( Achtung Übertreibung).

Ihr sehr wie immer bei AMD die Probleme und verschließt euch von den potenziellen Problemen bei Nvidia.
Nix neues aus der Fanboyecke.:P;D

das sieht weder bei nvidia, noch bei intel, noch bei der referenzimplementierung so aus und wie man sich dieses geflimmer schönreden kann ist mir ein absolutes rätsel. :confused:


btw. coda: kannst du, wenn dir mal langweilig ist, eine option einbauen mit der man das renderdevice umstellen kann?

[Mr. Lolman]

was ist denn da kaputt? das sieht ja fast wieder aus wie das 5xxx-AF. bei der checker-textur ist sogar eine harte banding-kante drin.
ich bilde mir ein das war schon mal besser - kann es sein, dass da was bei einem treiberupdate passiert ist? das ist jedenfalls absolut widerlich.

Hm, so dermaßen beschisssen war nichtmal das 5xxx AF. Im Gegenteil, bis auf die Bandinggschicht, wars eigtl. ganz ok, gerade vom Flimmerfaktor her...

[aufkrawall]

btw. coda: kannst du, wenn dir mal langweilig ist, eine option einbauen mit der man das renderdevice umstellen kann?
Und SG & OGSSAA, wenn du gerade schon dabei wärst. :redface:

[Mr. Lolman]

Hab mir grad den Flimmertester auf der 4870 angesehen: Flimmert in der gleichen Bewegung auf der 4870 ähnlich stark. Evtl. minimal schwächer. Je nach Geschwindigkeit ist das Flimmern stärker oder schwächer. Bis Y -0.05 wirds stärker, danach wieder schwächer (zeitliches Aliasing). Und das ist wohl auch der Grund, warums sonst nirgends auffällt: Man braucht eine anfällige Textur (was immer weniger der Fall ist, weil die Strukturen immer häufiger über Shader gemacht werden. Aktuelle Diffusemaps sind meistens ziemlich kontrastlos), man braucht eine anfällige Vergrößerung für XY und dann noch die passende Geschwindigkeit. Bei bspw. -0.15 (was immernoch eine recht langsame Bewegung ist, flimmerts um Eckhäuser weniger)

[Ronny145]

ich bilde mir ein das war schon mal besser - kann es sein, dass da was bei einem treiberupdate passiert ist? das ist jedenfalls absolut widerlich.



Es gab ein (oder mehrere) Treiberupdates in Richtung mehr flimmern und mehr Schärfe. Davor gab es Blur Probleme an einigen Texturen. HL2 ist zwar jetzt schön scharf, wenn man aber mal genau hinschaut im Screenshot und mit Nvidia vergleicht, sieht man einen harten Übergänge im vorderen Bereich auf Höhe der ersten Pflanze. Dass das an der Stelle in Bewegung sichtbar mehr bandet und flimmert, ist kein Wunder.


660 Ti HQ 16xAF= http://s14.directupload.net/images/131009/j8qqzi6g.png
660 Ti Q 16xAF= http://s1.directupload.net/images/131009/irwvrhzr.png
660 Ti Q+Trilineare Optimierung Aus= http://s7.directupload.net/images/131009/ex6d9ucx.png

HD7950 HQ 16xAF= http://s14.directupload.net/images/131009/d5s853go.png

http://www.file-upload.net/download-8158660/HL2.7z.html


Bei Nvidia mit Q+Trilineare Optimierung Aus erscheint es mir noch ruhiger als mit HQ wo diese Optimierung automatisch aus sein sollte. Ist mir beim testen aufgefallen.

[aufkrawall]

Bei Nvidia mit Q+Trilineare Optimierung Aus erscheint es mir noch ruhiger als mit HQ wo diese Optimierung automatisch aus sein sollte. Ist mir beim testen aufgefallen.
Tatsächlich, der Unterschied ist deutlich. Nice find.

[Schaffe89]

Du solltest doch langsam mal kapiert haben, dass man Videos anschauen muss, um das zu beurteilen.

Ich hab mich echt lange mit dem Blödsinn beschäftigt und wenn du mal Spielen würdest, anstatt immer den Filtertester anzuschauen würdest du sehen, das auch bei Nvidia je nach Content und Einstellungen subjektiv schlechtere Ergebnisse zu Tage treten, denn der AMD Filter ist lediglich "anders" aber nicht schlechter.

Der 3D Filtertester ist nicht die Referenz, noch HL2 ist Referenz. Man benötigt erstmal anfälligen Content und wenn es den nicht gibt, dann ist mir mehr Schärfe lieber.
Die Neverending Story geht wohl wieder in eine neue Runde.

Solange es nicht wieder derart flimmert wie bei der HD6k ist mir das Thema recht egal und schon gar nicht interessieren irgendwelche Ausnahmefälle.

Omg, bereits Q von Nvidia hat ein deutliches Flimmerband. HQ ist grenzwertig, aber akzeptabel.

.

Ist das Ironie?

Kann mir gut vorstellen, dass z.B. bei diversen Skyrim-Modtexturen es ähnlich flimmern könnte.

Bei Skyrim flimmert sowieso alles, kann man selbst mit SGSSAA kaum ruhig bekommen.

[aufkrawall]

Ich hab mich echt lange mit dem Blödsinn beschäftigt und wenn du mal Spielen würdest, anstatt immer den Filtertester anzuschauen würdest du sehen, das auch bei Nvidia je nach Content und Einstellungen subjektiv schlechtere Ergebnisse zu Tage treten, denn der AMD Filter ist lediglich "anders" aber nicht schlechter.

AMD ist lediglich bei Moires besser, überall sonst mitunter deutlich schlechter.
Da gibts nicht schönzureden. Ronny kann ja noch mal ein NV Q mit deaktivierter tril. Optimierung machen, da sieht AMD alt gegen aus.


Der 3D Filtertester ist nicht die Referenz, noch HL2 ist Referenz. Man benötigt erstmal anfälligen Content und wenn es den nicht gibt, dann ist mir mehr Schärfe lieber.

Was machen der Filtertester oder HL2 denn anders, damit sie nicht Beispiele sein dürfen?
HL2 sieht mit HQ auf Radeons zum deutlich schlechter als auf NV aus, zumindest mit neueren Treibern.


Solange es nicht wieder derart flimmert wie bei der HD6k ist mir das Thema recht egal und schon gar nicht interessieren irgendwelche Ausnahmefälle.

Es scheint wieder stark Richtung NI zu gehen.


Bei Skyrim flimmert sowieso alles, kann man selbst mit SGSSAA kaum ruhig bekommen.
Was soll denn da flimmern? Das Spiel hat kaum Flimmershader. Wenn da was flimmert, sind es Texturen oder vielleicht noch Schatten. Auf NV flimmert da mit SGSSAA quasi gar nichts mehr.

[captain_drink]

Bei Nvidia mit Q+Trilineare Optimierung Aus erscheint es mir noch ruhiger als mit HQ wo diese Optimierung automatisch aus sein sollte. Ist mir beim testen aufgefallen.

"Trilineare Optimierung aus" sollte sich in Kombination mit HQ doch über den Inspector forcieren lassen können, oder?

Der These, man könne von Filtertests nicht auf Spiele schließen, muss ich aus meiner Erfahrung übrigens widersprechen. Wenn man weiß, worauf man achten muss, zeigen sich die Symptome genauso in aktuellen Spielen. Das können auch kleine Flächen oder Linien sein, in Bewegung flimmert es dort auffällig. Texturen, die anfällig für Moiré-Effekte sind, gibt es sogar zuhauf. Mit meiner GTX 670 kann ich mitunter sehen, wie ab dem Übergang von MipMap 0 zu 1 Moiré auftritt. Bei den Schatten der Zäune (!) in GTA 4 kann ich sogar farblich unterschiedlich abgestufte MipMaps erkennen, in einem Level von Call of Juarez: Bound In Blood gab es Ähnliches zu sehen. Vgl.: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9901379#post9901379

[aufkrawall]

"Trilineare Optimierung aus" sollte sich in Kombination mit HQ doch über den Inspector forcieren lassen können, oder?

Die Option hat für HQ keine Auswirkung.

[aths]

Ich werde irgendwann in den nächsten Wochen noch mal Max Payne und Max Payne 2 spielen, hab einfach Bock drauf, und alles an AA/AF reinwerfen was die Graka hergibt. Wenn ich etwas nicht will in Max Payne, ist das Banding und Flimmern.

Ich erinnere mich an das Max-Payne-2-Durchspielen mit einer Radeon 9600 (passivgekühlt.) Man was hab ich die Graka gemocht: Preiswert, lautlos. Da konnte ich brilineare Artefakte in Max Payne 2 noch verschmerzen. Bin dann wegen Texturfilterung doch wieder zu Nvidia gewechselt (FX 5900) und bekam Hautausschlag und Pusteln, als der Treiber anfing, rumzuspinnen: http://alt.3dcenter.org/artikel/versteckte_optimierungen/ Dazu der treiberseitig eingeführte Zwang zur brilinearen Filterung.

[aufkrawall]

Dann denk dran, dass mit SGSSAA das LOD für D3D9 und älter noch wie bei bei AMD kaputt ist. Musst du mit manuellen Werten anpassen, wobei das bei 32xSSAA aber wohl eh keine Rolle mehr spielen wird.

Diese Flimmerstreifen mit NV HQ sind übrigens schon mit 2xSGSSAA komplett weg. Man hat da also keinen Nachteil, wenn man das saubere LOD-Bias von HQ nutzen will.

[Raff]

Ich werde irgendwann in den nächsten Wochen noch mal Max Payne und Max Payne 2 spielen, hab einfach Bock drauf, und alles an AA/AF reinwerfen was die Graka hergibt. Wenn ich etwas nicht will in Max Payne, ist das Banding und Flimmern.

Problem: Das Spiel mag ab Werk keine 16:9-Auflösungen, alles wird gestreckt. Ich habe Max Payne 2 auf meinem 30-Zöller in letztendlich in 2.048x1.536 mit 32xS + SGSSAA (-> 32x SSAA) gespielt. Eine Grafikkarte vom Kaliber GTX 470 oder 560 erreicht da nur noch ~30 Fps. :ulol: Möglicherweise gibt's aber auch einen Widescreen-Fix (etwa im WSGF). Wobei's auf der HD 5870 mit 8x SGSSAA + Narrow-tent-Filter auch extrem geil aussah und dabei noch schön flüssig war. :naughty:

MfG,
Raff