ATI nimmt stellung zu aquamark3 bug!

[mapel110]

http://www.rivastation.com/index_e.htm
ATI talks about rendering issues in AquaMark3 discovered by Tom´s Hardware Guide). It seems that there´s a small issue with the alpha-blender of the R300 and its followers:

It took much longer than I anticipated, but we reached to a conclusion on the AM3 "explosion" issue. The initial suspicions about our alpha blenders turned out to be true. To prove this we had to run the test scene on a future HW emulator - which took all this effort.

To summarize at a high level - we have single-bit differences when alpha blending compared to ref-rast image. When accumulating several layers of alpha blend objects, some pixels may end up looking darker on R300 family than refrast. We are rendering all the layers and the deviation we have in rendering each pixel is within an acceptable tolerance level from refrast - as evidenced by the fact that we pass all the WHQL DCT tests that compare images rendered on R300 v/s refrast.

[Quasar]

Original geschrieben von mapel110
We are rendering all the layers and the deviation we have in rendering each pixel is within an acceptable tolerance level from refrast - as evidenced by the fact that we pass all the WHQL DCT tests that compare images rendered on R300 v/s refrast.

Hm, geht das jetzt auch bei ATi schon los, daß die uns erzählen wollen, was "akzeptable" Einbußen/Abweichungen von der vorgegebenen Bildqualität sind? :kotz:

Ich kauf' mir wohl doch 'ne Matrox!

[Mr. Lolman]

:kotz: :asshole:

Ja dann dreht man den Monitor etwas heller, oder spielt an den Helligkeitssettings herum. :grübel:

BTW: Wie schauts denn mit HDR auf einer Matrox aus :naughty: ?

[Quasar]

Wahrscheinlich genauso, wie ohne.

edit:
Und was ist dann mit den vielen anderen Pixeln, die dadurch zu hell werden?

[Mr. Lolman]

Original geschrieben von Quasar
Wahrscheinlich genauso, wie ohne.

edit:
Und was ist dann mit den vielen anderen Pixeln, die dadurch zu hell werden?

Weiss nicht :ratlos:

Aber ehrlich gesagt, ist mir noch nie in den Sinn gekommen, dass auf meiner ATi Blendingeffekte ein paar Prozent zu dunkel dargestellt werden könnten.

Jetzt wo ichs weiss, sollt ich vielleicht erschüttert sein, aber irgendwie...


;)

[Winter[Raven]]

Weiss nicht

Aber ehrlich gesagt, ist mir noch nie in den Sinn gekommen, dass auf meiner ATi Blendingeffekte ein paar Prozent zu dunkel dargestellt werden könnten.

Jetzt wo ichs weiss, sollt ich vielleicht erschüttert sein, aber irgendwie...

Ironie, was ?

Wenn bei Nvidia nur das kleinste Pixel nicht an seinem Platz ist wird aus NV ne Hund gemacht, aber für Ati sieht man natürlich weg ...

[HOT]

Des stimmt so net.... gewollte "bugs" sind eine sache
aber es scheint sich hier um einen hardwarefehler zu handeln...
irgendwelche nachteile muss der r300 schliesslich auch haben ;)

[zeckensack]

Original geschrieben von Quasar
Hm, geht das jetzt auch bei ATi schon los, daß die uns erzählen wollen, was "akzeptable" Einbußen/Abweichungen von der vorgegebenen Bildqualität sind? :kotz:

Ich kauf' mir wohl doch 'ne Matrox! Mal eine andere Hervorhebung:
"We are rendering all the layers and the deviation we have in rendering each pixel is within an acceptable tolerance level from refrast - as evidenced by the fact that we pass all the WHQL DCT tests that compare images rendered on R300 v/s refrast."
Uuund
"we have single-bit differences when alpha blending compared to ref-rast image. When accumulating several layers of alpha blend objects, some pixels may end up looking darker on R300 family than refrast."

:P

;)

[zeckensack]

Original geschrieben von Winter[Raven]
Ironie, was ?

Wenn bei Nvidia nur das kleinste Pixel nicht an seinem Platz ist wird aus NV ne Hund gemacht, aber für Ati sieht man natürlich weg ... Schade daß ich deinen Satz nicht so fortsetzen konnte:
... dann kommt ein ATI-Mutz daher, und gesteht einen HW-Fehler :o

Dein Satzbau war zu dieser Fortsetzung leider nicht kompatibel :-(

[Xmas]

Original geschrieben von HOT
Des stimmt so net.... gewollte "bugs" sind eine sache
aber es scheint sich hier um einen hardwarefehler zu handeln...
Ich zweifle mal ganz leicht daran dass es sich hier nicht um Absicht (nämlich um die, Transistoren zu sparen) handelt.

Interessanterweise ist laut ATI 1 * 1 = 0.996 ;)

irgendwelche nachteile muss der r300 schliesslich auch haben ;)
Dazu wird sich aths bestimmt noch äußern.

[KEINPLAN]

Original geschrieben von zeckensack
Mal eine andere Hervorhebung:
"We are rendering all the layers and the deviation we have in rendering each pixel is within an acceptable tolerance level from refrast - as evidenced by the fact that we pass all the WHQL DCT tests that compare images rendered on R300 v/s refrast."
Uuund
"we have single-bit differences when alpha blending compared to ref-rast image. When accumulating several layers of alpha blend objects, some pixels may end up looking darker on R300 family than refrast."

:P

;)
Könntest du acceptable tolerance level mal genauer erklären;)

[KEINPLAN]

Original geschrieben von Xmas
Ich zweifle mal ganz leicht daran dass es sich hier nicht um Absicht (nämlich um die, Transistoren zu sparen) handelt.

Interessanterweise ist laut ATI 1 * 1 = 0.996 ;)


Dazu wird sich aths bestimmt noch äußern. Nunja Transistor sparen, dann haben sie aber abgewogen wo sie sie sparen!
Also, mit Absicht weils am wenigsten auffällt, unterstelle ich mal einfach so.

[Xmas]

Original geschrieben von KEINPLAN
Nunja Transistor sparen, dann haben sie aber abgewogen wo sie sie sparen!
Also, mit Absicht weils am wenigsten auffällt, unterstelle ich mal einfach so.
Natürlich haben sie abgewogen wo sie sparen. Nach allem was ich bisher gesehen habe bekomme ich den Eindruck, dass man beim R300 in der Pixelpipeline jede einzelne Berechnung genauestens untersucht und auf gerade die Präzision zurechtgestutzt hat, die noch keinen "wahrnehmbaren Unterschied" nach sich zieht. Und man muss den ATI-Ingenieuren dazu gratulieren, dass ihnen dies in fast allen Fällen gelungen ist.

[Gast]

für mich ist das Cheating völlig egal ob nun in Software oder Hardware.
Wenn es Performance bringt und auf Kosten der BQ geht ist das Cheating wie es Nvidia auch betreibt.
Keinen Unterschied mache ich da. Weder beim AF noch bei dem hier beschriebenen Effekt.

[ShadowXX]

Original geschrieben von Gast
für mich ist das Cheating völlig egal ob nun in Software oder Hardware.
Wenn es Performance bringt und auf Kosten der BQ geht ist das Cheating wie es Nvidia auch betreibt.
Keinen Unterschied mache ich da. Weder beim AF noch bei dem hier beschriebenen Effekt.

Es bringt aber keinen Performancegewinn, sondern ist ein HW-Bug...die GPU macht die gleiche Arbeit, aber sie verrechnet sich halt "leicht".

Bevor einfach drauflos zu hauen, sollte man erst mal überlegen was der nette ATI Herr da überhaupt erzählt hat.

J.S.Shadow

[Quasar]

;)
Original geschrieben von zeckensack
[...]
:P
[...]
;)
:up:
Ja, kann man natürlich sehen, wie man will. Ich find's allerdings interessant, wie man so viele Transistoren sparen kann (Denn es scheinen wirklich etliche zu sein) und dabei zwar geringe, aber dennoch Abweichungen in Kauf nehmen muss.

Das ist eine ganz klare Designentscheidung und hat, IMO, nichts mit einem Bug zu tun, genauso, wie FXFlow oder die hohe Anfälligkeit der nV3x-Pipeline für unpassende (ist das Wort neutral genug?) Instruction Order.

ATi hat diese Dinge, die sich, wie schon länger bekannt, genau am RefRast entlanghangeln, oder, wie hier, ihn knapp verfehlen, bewußt in Kauf genommen, um eine hohe Leistung im Fragment-Bereich zu garantieren.

Ein grüner IHV (;)) tat dies nicht und übererfüllt in vielen Punkten die RefRast-Spezifikationen. Ebenfalls eine klare Designentscheidung (auch wenn sie mittlerweile wohl etwas schmerzen dürfte), vermutlich auch, weil man die Architektur über einen längeren Zeitraum als nur ein DX-Generation nutzen wollte, ohne sie komplett umzubasteln.


So, genug der vielen Worte, was ich sagen will, ist, daß interessanterweise ATi von vielen für "tolle" Bildqualität gelobt wird (meist nicht zu Unrecht) und zwar von denen am lautesten, denen einzelne fehlerhafte Pixel bei dem grünen IHV schon gleich ein Grund bedeuten, dem nV3x die DX9-Tauglichkeit absprechen zu wollen.

edit:
Zecki,
erinnerst du dich noch an das Beispiel, welches Demirug einst brachte, mit den um 1/256stel abweichenden Farbwerten in den Buchstaben, was IIRC dem Heruntersetzen auf FP16 entsprach? Wer (nicht du) hat da wohl am lautesten "Cheat" geschrien?

edit2:
Shadow,
Trennen sollte man das IMO aber auch nicht. Du erinnerst dich sicherlich, daß der pseudo-trilineare Filter bei UT2003 im Deto45.23 zunächst auch nur ein "Bug" war, oder? Dazu kommt diese (begrüßenswert klare) Aussage von einem ATi-Menschen, der per se schonmal nicht neutral sein kann und drittens und wichtigstens: All diese kleinen Dinge, die gespart wurden (FP24/5Bit Tri/Alpha/AA/undwassonstnochalles) haben es ATi ermöglicht, einen zweiten Pixelprozessor zu installieren, der "ohne" sicherlich nicht drin gewesen wäre. Daher die hohe Leistung, die aber eben durch Verzicht auf Qualität erkauft wird (hüben per HW, drüben per SW).

[zeckensack]

Ich find's allerdings bemerkenswert, daß hier kein großer Eiertanz veranstaltet wird, sondern eine HW-Schwäche offen zugegeben wird. Das Zugeben eigener Schwächen ist eine Fähigkeit, die nicht alle IHVs besitzen :stolz:
Noch wohler wäre mir dabei, wenn Borsti-Station mal eine vernünftige Quellenangabe machen könnte ...

Trotzdem natürlich Ack @ Quasar :flower:

[deekey777]

Naja, dieser "Bug" ist mit jedem cat3.x zu sehen. Es liegt entweder an der Hardware oder daran, dass die Aquamark3-Macher zwei linke Hände haben (99 zu 1). Und der "Entdecker" dieses Bugs sollte zuerst lernen, wie man objektive, neutrale Vergleichstests schreibt.

[Demirug]

Original geschrieben von Quasar
edit:
Zecki,
erinnerst du dich noch an das Beispiel, welches Demirug einst brachte, mit den um 1/256stel abweichenden Farbwerten in den Buchstaben, was IIRC dem Heruntersetzen auf FP16 entsprach? Wer (nicht du) hat da wohl am lautesten "Cheat" geschrien?

Eigentlich ging es darum das man vieles sogar mit FX12 rechnen kann ohne mehr als 1/256 Abweichung im Endergebniss im vergleich zu FP32 zu haben.

1/256 entspricht beim üblichen 32 Bit RGBA Framebuffer besagter "single-bit differences"

Solange man im Framebuffer nicht rechnet (Alpha-Blending) ist das auch kein Problem. Kritisch wird es eben wenn man es doch tut und der Fehler tendenziel immer in die gleiche Richtung schlägt.

[ShadowXX]

Original geschrieben von Quasar
edit2:
Shadow,
Trennen sollte man das IMO aber auch nicht. Du erinnerst dich sicherlich, daß der pseudo-trilineare Filter bei UT2003 im Deto45.23 zunächst auch nur ein "Bug" war, oder? Dazu kommt diese (begrüßenswert klare) Aussage von einem ATi-Menschen, der per se schonmal nicht neutral sein kann und drittens und wichtigstens: All diese kleinen Dinge, die gespart wurden (FP24/5Bit Tri/Alpha/AA/undwassonstnochalles) haben es ATi ermöglicht, einen zweiten Pixelprozessor zu installieren, der "ohne" sicherlich nicht drin gewesen wäre. Daher die hohe Leistung, die aber eben durch Verzicht auf Qualität erkauft wird (hüben per HW, drüben per SW).[/i]

Dem widerspreche ich auch nicht.....

Bei nv stört mich eher die "aufgeblasene" Art...weniger wie Sie ihre Treiber optimieren...

J.S.Shadow

[Winter[Raven]]

dann kommt ein ATI-Mutz daher, und gesteht einen HW-Fehler

Eine Frage die ich mir stelle ist, ob dieser "HW-Fehler" Beabsichtlich war oder wirklich nur ein "Bug" ist.

Wäre jetzt nicht der AM da, hätten sie es wohl weiterhin vertuscht.

[Quasar]

Original geschrieben von zeckensack
Ich find's allerdings bemerkenswert, daß hier kein großer Eiertanz veranstaltet wird, sondern eine HW-Schwäche offen zugegeben wird. Das Zugeben eigener Schwächen ist eine Fähigkeit, die nicht alle IHVs besitzen :stolz:


Das stimmt allerdings und verdient ein :up:

Wobei durch die Erläuterung, daß man zur Reproduktion des Problems den HW-Emulator anwerfen musste (i.e. mit viel mehr als einem simplen Chip arbeitet), man jedem anderen die Reproduzierbarkeit z.B. mittels anti-cheat Tools per se abspricht...

[Crushinator]

Original geschrieben von Winter[Raven]
Eine Frage die ich mir stelle ist, ob dieser "HW-Fehler" Beabsichtlich war oder wirklich nur ein "Bug" ist. Wo ist da denn - nach dem was alles erzählt wurde - ein Verständnisproblem? Es handelt sich um eine Unzulänglichkeit der Hardware, welche durch die Designentscheidung Transistoren zu sparen und die sich daraus ergebenen Genauigkeitseinbußen zustande gekommen ist. Damit ist es nach "Adam Riese" eine beabsichtliche Ungenauigkeit, welche jedoch innerhalb der Toleranzvorgaben von Refrast zu sein scheint.
Wäre jetzt nicht der AM da, hätten sie es wohl weiterhin vertuscht. Naja, es wäre ja auch zu schön gewesen, wenn Ungenauigkeiten nirgendwo in der Praxis auffielen. Die Frage ist auch, ob die Welt dadurch untergeht wenn das Ergebnis von mehreren übereinander gelegten Alpha blend Objekten minimal dunkler dargestellt wird. :ratlos:

[Gast]

Grafikchips haben schon immer massig Rundungsfehler gehabt. Eine Erhoehung der Praezision vermeidet keine Rundungsfehler, sondern reduziert nur den Fehler. Jeder Hersteller definiert eigene Kriterien was/wo akzeptabel/wichtig ist. Schelle 3D-Grafik war schon immer mehr oder weniger Fake. Realistismus oder Korrektheit (was auch immer das heissen mag) fuer HW-Grafik spielt nur eine untergeordnete Rolle.

[StefanV]

Original geschrieben von Winter[Raven]
Wenn bei Nvidia nur das kleinste Pixel nicht an seinem Platz ist wird aus NV ne Hund gemacht, aber für Ati sieht man natürlich weg ...

Der Unterschied ist halt a), daß nV sich nicht hinstellt und sagt: 'Tschuldigung liegt an der Hardware, da können wir nix dran machen, ist aber eigentlich nicht soo schlimm' und b) die nV HW zu mehr in der Lage ist als die aktuellen Treiber sie lassen...


Wobei, irgendwie muss ATI die Chips ja so hinbiegen, daß sie noch einigermaßen kühl bleiben :eyes:

[Quasar]

Original geschrieben von Stefan Payne
Der Unterschied ist halt a), daß nV sich nicht hinstellt und sagt: 'Tschuldigung liegt an der Hardware, da können wir nix dran machen, ist aber eigentlich nicht soo schlimm' und b) die nV HW zu mehr in der Lage ist als die aktuellen Treiber sie lassen...


Wobei, irgendwie muss ATI die Chips ja so hinbiegen, daß sie noch einigermaßen kühl bleiben :eyes:

1. Sollen sie sich hinstellen und sagen: "'Tschuldigung, unser Chip ist präziser und rechnet alles mind. so gut wie der RefRast es vorschreibt, dafür isser langsamer."
Weißt doch selbst, wie FPS-Geil die Mehrzahl der sog. '3D-Szene' ist. Man ist keine Kompromisse bei der Genauigkeit eingegangen und wurde dafür mit schlechterer Leistung "bestraft", nun versucht man bei nVidia per Software, den hierdurch erhöhten Transistorcount und den dadurch bedingten Verzicht auf einen zweiten Pixelprozessor, einigermaßen wieder hinzubiegen. Leider gelingt dies momentan eher schlecht als recht.

2. "muss"? :lol: Die armen Kanadier.... Am Ende werden sie von GWB dazu gezwungen, was? Und "einigermaßen kühl" nennst du 60° 'warme' Bauteile die sich abseits vom Chip über die Karten verstreut finden? =)

[ShadowXX]

Original geschrieben von Quasar
1. Sollen sie sich hinstellen und sagen: "'Tschuldigung, unser Chip ist präziser und rechnet alles mind. so gut wie der RefRast es vorschreibt, dafür isser langsamer."
Weißt doch selbst, wie FPS-Geil die Mehrzahl der sog. '3D-Szene' ist. Man ist keine Kompromisse bei der Genauigkeit eingegangen und wurde dafür mit schlechterer Leistung "bestraft", nun versucht man bei nVidia per Software, den hierdurch erhöhten Transistorcount und den dadurch bedingten Verzicht auf einen zweiten Pixelprozessor, einigermaßen wieder hinzubiegen. Leider gelingt dies momentan eher schlecht als recht.


Nein...es würde reichen wenn Sie sich hinstellen und das, was du in deinem Post wiedergegeben hast, offiziell verkünden.
Dazu noch einen Schalter: Optimierungen AN/AUS

J.S.Shadow

[Demirug]

Original geschrieben von ShadowXX
Nein...es würde reichen wenn Sie sich hinstellen und das, was du in deinem Post wiedergegeben hast, offiziell verkünden.
Dazu noch einen Schalter: Optimierungen AN/AUS

J.S.Shadow

nV befürchtet da wohl aber das viele mit Optimierung AUS vergleichen würde.

[Gast]

Quasar, du glaubst doch nicht wirklich, dass NV (oder ATI oder ...) "mindestesns so praezise rechnet wie der Refrast es vorschreibt"? Zudem, der Refrast schreibt gar nichts vor.

[Riptor]

Original geschrieben von Winter[Raven] Ironie, was ? Wenn bei Nvidia nur das kleinste Pixel nicht an seinem Platz ist wird aus NV ne Hund gemacht, aber für Ati sieht man natürlich weg ...

Muss jetzt wieder eine Hetzkampagne gestartet werden? ;D

Frage: In welchen SPIELEN kann man diesen "Effekt" wiederholen bzw. nachstellen?! Würd mich mal interessieren, wie sich das auswirkt, in 3D Murks 03 werden in der ersten Demo mit den Flugzeugen die Rauchschwaden etwas "heller" dargestellt, hatte das erst gerstern wieder in nem Screenshot-Vergleich in nem R9800XT/FX5950 Review gesehen... Leider weiß ich nicht mehr wo, aber auch hier wäre es wieder mal nen synthetischer Benchmark...

[Winter[Raven]]

Frage: In welchen SPIELEN kann man diesen "Effekt" wiederholen bzw. nachstellen?! Würd mich mal interessieren, wie sich das auswirkt, in 3D Murks 03 werden in der ersten Demo mit den Flugzeugen die Rauchschwaden etwas "heller" dargestellt, hatte das erst gerstern wieder in nem Screenshot-Vergleich in nem R9800XT/FX5950 Review gesehen... Leider weiß ich nicht mehr wo, aber auch hier wäre es wieder mal nen synthetischer Benchmark...

Hehe

Also wenn Ati den Rauch "ETWAS" Heller rendert ist es natürlich unwichtig, völlig egal. Aber wenn bei NV die Feuereffekte "ETWAS" aders Rendert wird NV verteufelt ?

Welch eine Ironie des Lebens.

Ja, man kann das auslegen wie man will. Im Enfeffekt ist keiner von beiden besser als der andere.

[ShadowXX]

Original geschrieben von Demirug
nV befürchtet da wohl aber das viele mit Optimierung AUS vergleichen würde.

Könnte passieren...aber zumindest könnte man dann beide Varianten gegenüberstellen und der Anwender könnte selbst entscheiden, was für Ihn besser wäre.

Ich glaube ausserdem das selbst das blindeste Online-Mag beide Modi testen würde.

Sähe dann so aus:

Radeon 120 FPS
FX 125 FPS
FX (*) 100 FPS

* ohne Optimierungen

(alles Fantasiezahlen ohne Bezug auf ein bestimmtes Game)

Natürlich müssten die Testern dann den Unterschied zwischen Optimiert/Unoptimiert erleutern....der kann ja auch sehr gering sein.

Danach kann sich der geneigte Käufer entscheiden.
Es wäre dem Käufer gegenüber fair und würde meine Meinung von nV Grundlegend steigern.

Ich mag es übrigens auch nicht, dass es bei ATI noch immer keinen "Full Tri"-Schalter im CP gibt. Ist auch Kundenverar***e.

Aber heutzutage wollen die Käufer wohl hinters Licht geführt werden....passiert auch bei uns dauernd.Der Support kommt mit einem völlig unsinnigen Feature das mit ins Programm eingebaut werden soll, nur weils gerade "In" ist.

Gruß,
J.S.Shadow

[LovesuckZ]

Original geschrieben von ShadowXX
Sähe dann so aus:
Radeon 120 FPS
FX 125 FPS
FX (*) 100 FPS
* ohne Optimierungen


Und Radeon (*)?
Oder werde ATi eine Ausnahmestellung zu geteielt, dass sie nie optimieren (umgangssprachlich auch CHEAT genannt)?

[aths]

Original geschrieben von ShadowXX
Es bringt aber keinen Performancegewinn, sondern ist ein HW-Bug...die GPU macht die gleiche Arbeit, aber sie verrechnet sich halt "leicht".Das ist kein Bug, sondern eine Vereinfachung der MUL-Einheit zugunsten des Transistor-Counts und zulasten der Genauigkeit. Wenn man ATIs Statement liest, kann man imo genau das herauslesen. Insofern sollte man NVidias Bemühungen neu durchdenken, wenn sie leichte Ungenauigkeiten inkauf nehmen um FP16 statt FP32 verwenden zu können. Das Problem ist, NV kann's genau, aber einsatzfähig ist es nur dann, wenn die Framerate keine Rolle spielt. ATI bringt die Leistung, aber kann Hardwareseitig nicht so genau rechnen, wie man sich wünschen würde — übrigens ist das nicht der einzige Bereich, wo sie sparen.

Immerhin, ATIs Statement ist trotz Marketing-Schliff ehrlich. Sowas würde ich mir auch mal von Nvidia wünschen.

[Riptor]

Original geschrieben von Winter[Raven] Also wenn Ati den Rauch "ETWAS" Heller rendert ist es natürlich unwichtig, völlig egal. Aber wenn bei NV die Feuereffekte "ETWAS" aders Rendert wird NV verteufelt ?Welch eine Ironie des Lebens. Ja, man kann das auslegen wie man will. Im Enfeffekt ist keiner von beiden besser als der andere.

Ähem, ich glaube nicht, dass wir hier einen Stellungskrieg wollen und wenn jetzt manche hier meinen, alle ATI-Fans würden sich vereinigen, um einem das Leben schwer zu machen, dann ist das nicht unser Problem hier. IMO geht es in diesem Thread NICHT um das Thema, ob nVidia verteufelt wird oder nicht und auch ist es IMO nicht sehr sinnvoll, jetzt mit der Keule zu schwenken, um Diskussions-Stoff zu verprügeln, nur damit man mal wieder dem "Konkurrenz-Produkt-Käufer" eine ausgewischt wird, oder? ;)

@ ShadowXX: Ich glaube, das Problem ist, dass das Thema sehr komplex ist, und eigentlich nur eine Minderheit darüber bescheid weiß, was "Optimierungen" sind, wie sie funktionieren und was man "darf" und was nicht, wobei wir hier wieder bei dem Thema "Auslegungssache" wären. Ziemlich schwer anzupacken, damit man dieses Thema in einem neutralen Licht zeigen kann... :gruebel:

[Quasar]

Original geschrieben von Gast
Quasar, du glaubst doch nicht wirklich, dass NV (oder ATI oder ...) "mindestesns so praezise rechnet wie der Refrast es vorschreibt"? Zudem, der Refrast schreibt gar nichts vor.

Was ich glaube, spielt keine Rolle. Der (DX9-)RefRast rechnet AFAIK mit FP24, Mindestanforderung für 2.0-Shader, wenn kein pp_hint gesetzt ist, was die Anforderung auf FP16 senken würde.

[Gil-galad]

Original geschrieben von LovesuckZ
Und Radeon (*)?
Oder werde ATi eine Ausnahmestellung zu geteielt, dass sie nie optimieren (umgangssprachlich auch CHEAT genannt)?

Welche "Cheats" hat man denn bisher bei ATi gefunden? (außer kein trilineares Filtering)

Die Frage die sich mir noch stellt: Wo sieht man wirklich einen Unterschied zwischen RefRast und ATi-"Qualität"? Wäre nett, wenn jemand Bilder posten könnte.

[LovesuckZ]

Original geschrieben von AiS|Gil-galad
Welche "Cheats" hat man denn bisher bei ATi gefunden? (außer kein trilineares Filtering)

3Dmark2001/3, Aquamark3, winkelabhaengiges AF etc.
Und ja, bei nvidia sieht es nicht anders aus.

[Quasar]

Original geschrieben von AiS|Gil-galad
Welche "Cheats" hat man denn bisher bei ATi gefunden? (außer kein trilineares Filtering)

Meinst du jetzt Treiber-'Applikationsspezifische Optimierungen' oder diejenigen, die fest in Hardware gegossen wurden?

[Gast]

Original geschrieben von Winter[Raven]
Hehe

Also wenn Ati den Rauch "ETWAS" Heller rendert ist es natürlich unwichtig, völlig egal. Aber wenn bei NV die Feuereffekte "ETWAS" aders Rendert wird NV verteufelt ?

Welch eine Ironie des Lebens.

Ja, man kann das auslegen wie man will. Im Enfeffekt ist keiner von beiden besser als der andere.

doch ATI ist besser, da die vielleicht einmal cheaten und nvidia muss IMMER cheaten, ein kleiner aber doch grosser unterschied :P

[Gast]

Original geschrieben von LovesuckZ
3Dmark2001/3, Aquamark3, winkelabhaengiges AF etc.
Und ja, bei nvidia sieht es nicht anders aus.

das af ist hw limitiert, aber ok dann ist das AA von nvidia ein riesen cheat, da das 4xAA aussieht wie das 1xAA von ATI *g*

[Gil-galad]

Original geschrieben von LovesuckZ
3Dmark2001/3, Aquamark3, winkelabhaengiges AF etc.
Und ja, bei nvidia sieht es nicht anders aus.

3D Mark 2001? Wo da?

3D Mark 2003? Der "Cheat" wurde schon vor langer Zeit aus den Treibern entfernt. Also irrelevant.

Aquamark3? Wo da (bis auf geringere Genauigkeit)?

Winkelanhängiges AF ist kein Cheat. NVidia nutzt auch winkelabhängiges AF, nur nicht so stark wie ATi. IMO mehr eine Optimierung als ein Cheat.

[Gil-galad]

Original geschrieben von Quasar
Meinst du jetzt Treiber-'Applikationsspezifische Optimierungen' oder diejenigen, die fest in Hardware gegossen wurden?

Natürlich die Treiber-'Applikationsspezifischen Optimierungen'.

Zum Thema Optimierungen in Hardware: Welche siehst Du da? Das mit einer geringeren Präzision ist klar und winkelabhängiges AF würde ich auch noch verstehen. Aber gibts da noch mehr?

[aths]

Original geschrieben von LovesuckZ
3Dmark2001/3, Aquamark3, winkelabhaengiges AF etc.
Auch Nvidias AF ist winkelabhängig, sofern mehr als 2° benutzt wird. Das ist hier und da kein Cheat, sondern eine gewollte Vereinfachung der Berechnungslogik für die AF-Samples.

[Gast]

AiS|Gil-galad *zustimm*

[Quasar]

Ich glaube, daß im 3DMark2001 von ATi noch immer recht heftig im Nature-Bench optimiert wird.

nVidia hat's in den 45.23 IIRC rausgenommen*, der Nature ist ziemlich eingebrochen.

*wahrscheinlich, weil er nur noch wenig Beachtung findet und man sich so brüsten kann, einen cheatfreien Benchmark zu haben ;)

edit:
Hab' eben grade einen schönen "Cheat" in X² gefunden. nVidia's Blending zeigt da mitunter ein recht heftiges Banding (auch schon mit den 44.03 Treibern und auf GF4/FX). Die Radeon (R300+) haben da den hübscheren Verlauf.

[LovesuckZ]

Original geschrieben von AiS|Gil-galad
3D Mark 2001? Wo da?

Siehe digit-life.com Bericht.

3D Mark 2003? Der "Cheat" wurde schon vor langer Zeit aus den Treibern entfernt. Also irrelevant.

Das selbe tat Nvidia beim 3DMark2001, erst nachdem sie entdeckt wurden sind, wie ATi. Dies ist für mich nicht irrelevant.

Aquamark3? Wo da (bis auf geringere Genauigkeit)?

Exakt, das ist ein Cheat. Eine geringere Genauigkeit als angefordert, aber wir koennen diese Vorgehen bei Nvidia auch "geringe Genauigkeit" nennen und uns jeden weiteren Kommentar dazu ersparen!

Winkelanhängiges AF ist kein Cheat. NVidia nutzt auch winkelabhängiges AF, nur nicht so stark wie NVidia. IMO mehr eine Optimierung als ein Cheat.


Nvidia's AF filtert wie der Refrast. Dies verlange ich auch von ATi. Daher ist die Winkelabhaengigkeit ein Cheat, denn ansonsten koennten wir jegliche Vergleiche durch und mit dem refrast vergessen und Cheatvorwürfe gleich sein lassen.

[Gast]

Original geschrieben von Quasar
Ich glaube, daß im 3DMark2001 von ATi noch immer recht heftig im Nature-Bench optimiert wird.

nVidia hat's in den 45.23 IIRC rausgenommen*, der Nature ist ziemlich eingebrochen.

*wahrscheinlich, weil er nur noch wenig Beachtung findet und man sich so brüsten kann, einen cheatfreien Benchmark zu haben ;)

Jaja du glaubst... belege, beweise, quellen für eine bestätigung oder behalte bitte dein glauben für dich :)

[Crazy_Bon]

Ich möchte nochmals an alle erinnern, welche Schwierigkeiten Nvidia hatte, auf GF1 bis einschliesslich GF4-Karten die DXT1-Texturen korrekt anzuzeigen.
Man hat auch hardwareseitig ungenauer gerechnet für ein bisschen mehr Performance und dies als Bug im Chipdesign deklariert.
Allerdings brauchte es bis zur GeForceFX um diesen Bug auszumerzen, viel zu lange und meine Spielfreude wurde durch miserable Texturen getrübt. :(

[Quasar]

Original geschrieben von AiS|Gil-galad
Natürlich die Treiber-'Applikationsspezifischen Optimierungen'.

Zum Thema Optimierungen in Hardware: Welche siehst Du da? Das mit einer geringeren Präzision ist klar und winkelabhängiges AF würde ich auch noch verstehen. Aber gibts da noch mehr?

Nu ja, was bisher so alles hier zur Sprache gekommen ist:

- kein TruForm mehr in HW (gut, das war eh' freiwillig drin im R200)
- 5Bit-Trilinear LOD
- LOD-Bestimmung allgemein (siehe lolmans URU-Shot)
- Diese Alpha-Blending Geschichte
- AF rel. stark optimiert

Ob man es nun Cheat oder Designentscheidung nennt, ist mir eigentlich wurscht. Die Folge davon ist erhöhte Geschwindigkeit zulasten der Genauigkeit, der eine macht's in HW, der andere in Software, wobei ich sagen muss, daß die meisten Optimierungen von ATi weniger auffällig sind, als die von nVidia (bis auf mein Steckenpferd 'AF'.

[aths]

Original geschrieben von AiS|Gil-galad Welche siehst Du da? Das mit einer geringeren Präzision ist klar und winkelabhängiges AF würde ich auch noch verstehen. Aber gibts da noch mehr? Ja.

[Quasar]

Original geschrieben von Gast
Jaja du glaubst... belege, beweise, quellen für eine bestätigung oder behalte bitte dein glauben für dich :)

'jaja' heisst.... naja, du weißt schon was.
Da ich momentan keine Radeon in einem meiner beiden Rechner habe, kann ich keinen 3DMark-Nature Bench mit/ohne Anti-Detection fahren, trotzdem werde ich meinen 'Glauben' nicht für mich behalten. Dir verbietet ja schließlich auch keiner den Mund, gell?

Es gab da mal ein paar Screenshots von XBit-Labs, wo u.a. der Nature-Bench gegen den RefRast verglichen wurde und es doch durchaus gewichtige Abweichungen gab.
Die komplizierten Sinus-Berechnungen (ah... jetzt dämmert mir, warum nV den Cheat deaktiviert hat) für die Animation der Blätter sollen von beiden ein wenig 'angenähert' worden sein, anstelle sie korrekt auszurechnen.
Es gab sowohl bei nVidia als auch bei ATi ein paar Treiber mit gehörigen Sprüngen in der 3DMark2001-Performance... warum wohl?

[Gil-galad]

Original geschrieben von Quasar
- kein TruForm mehr in HW (gut, das war eh' freiwillig drin im R200)
- 5Bit-Trilinear LOD
- LOD-Bestimmung allgemein (siehe lolmans URU-Shot)
- Diese Alpha-Blending Geschichte
- AF rel. stark optimiert

Das Truform nicht mehr in HW ist, ist ja ATis Entscheidung. Dadurch spart man sicherlich einige Transistoren. Außerdem ist Truform nicht Teil einer DX Spezifikation. Also kann ATi damit ja machen, was sie wollen ;)

Zu den anderen Sachen: Danke für die Aufzählung.


Ob man es nun Cheat oder Designentscheidung nennt, ist mir eigentlich wurscht. Die Folge davon ist erhöhte Geschwindigkeit zulasten der Genauigkeit, der eine macht's in HW, der andere in Software, wobei ich sagen muss, daß die meisten Optimierungen von ATi weniger auffällig sind, als die von nVidia (bis auf mein Steckenpferd 'AF'.

Eine Sache sollte man natürlich bedenken: Solange die Bildqualität bei geringerer Genauigkeit nicht leidet, solange kann man eigentlich daran auch nichts aussetzen. Ich persönlich seh nicht wirklich einen Unterschied, zwischen "normaler" Genauigkeit und ATis "geringerer" Genauigkeit. ATi bewegt sich da sicher auf einem schmalen Grat, aber anscheinend auf der sichereren Seite ;)

[Quasar]

Original geschrieben von AiS|Gil-galad
Das Truform nicht mehr in HW ist, ist ja ATis Entscheidung. Dadurch spart man sicherlich einige Transistoren. Außerdem ist Truform nicht Teil einer DX Spezifikation. Also kann ATi damit ja machen, was sie wollen ;)
Jo, sehe ich genauso, auch wenn sie damit TruForm wohl den Todesstoß geben.

Original geschrieben von AiS|Gil-galad
Eine Sache sollte man natürlich bedenken: Solange die Bildqualität bei geringerer Genauigkeit nicht leidet, solange kann man eigentlich daran auch nichts aussetzen. Ich persönlich seh nicht wirklich einen Unterschied, zwischen "normaler" Genauigkeit und ATis "geringerer" Genauigkeit. ATi bewegt sich da sicher auf einem schmalen Grat, aber anscheinend auf der sichereren Seite ;)
Nu ja, die 5Bit-Tri-Geschichte ist noch genau RefRast-konform, die Alpha-Blending-Sache weicht ja offenbar ab. Da beginnt IMO schon wieder die Zone, in der man drüber diskutieren kann, was noch zulässig ist, und was nicht.

[aths]

Original geschrieben von AiS|Gil-galad Ich persönlich seh nicht wirklich einen Unterschied, zwischen "normaler" Genauigkeit und ATis "geringerer" Genauigkeit. ATi bewegt sich da sicher auf einem schmalen Grat, aber anscheinend auf der sichereren Seite ;) Wenn Leo mal hinnemacht http://www.aths.net/files/smilies/devil.gif, könnte es heute noch einen neuen Artikel geben. Eins kann ich jetzt schon versprechen: You will see http://www.aths.net/files/smilies/bescheuert.gif

[Gil-galad]

Original geschrieben von aths
Wenn Leo mal hinnemacht http://www.aths.net/files/smilies/devil.gif, könnte es heute noch einen neuen Artikel geben. Eins kann ich jetzt schon versprechen: You will see http://www.aths.net/files/smilies/bescheuert.gif

Dann bin ich ja mal gespannt ;)

[Riptor]

/me: --> www.3dcenter.de <-- F5. Wart. F5. Wart. F5. Wart. F5. Wart. F5. Wart. F5. Wart.

[Gil-galad]

Original geschrieben von LovesuckZ
Nvidia's AF filtert wie der Refrast. Dies verlange ich auch von ATi. Daher ist die Winkelabhaengigkeit ein Cheat, denn ansonsten koennten wir jegliche Vergleiche durch und mit dem refrast vergessen und Cheatvorwürfe gleich sein lassen.

Original geschrieben von aths
Auch Nvidias AF ist winkelabhängig, sofern mehr als 2° benutzt wird. Das ist hier und da kein Cheat, sondern eine gewollte Vereinfachung der Berechnungslogik für die AF-Samples.

[ow]

Original geschrieben von LovesuckZ


Nvidia's AF filtert wie der Refrast.

Nö. NVs AF ist besser als das des Refrast.
Einfach mal Refrast und GF mit Demis AF-Tester vergleichen.

[Mr. Lolman]

Original geschrieben von Quasar
- 5Bit-Trilinear LOD


macht der Refrast auch.


- LOD-Bestimmung allgemein (siehe lolmans URU-Shot)


Ist beim bi-AF eher von Vorteil, da eine Art Dithering zustande kommt, welches das Mipmapbanding etwas "verschleiert".



- AF rel. stark optimiert

..., wobei ich sagen muss, daß die meisten Optimierungen von ATi weniger auffällig sind, als die von nVidia (bis auf mein Steckenpferd 'AF'.

Naja, so tolle ist das NV AF ja auch nicht mehr mit den >50er Detos...

Original geschrieben von ow
Nö. NVs AF ist besser als das des Refrast.
Einfach mal Refrast und GF mit Demis AF-Tester vergleichen.

Trotz dessen, das eine pseudotrinlinearer Filter zum Einsatz kommt?

[Quasar]

Original geschrieben von Mr. Lolman
macht der Refrast auch.
Ist beim bi-AF eher von Vorteil, da eine Art Dithering zustande kommt, welches das Mipmapbanding etwas "verschleiert".
Naja, so tolle ist das NV AF ja auch nicht mehr mit den >50er Detos...


1. Das sagte ich doch selbst.
2. Eine Ausrede läßt sich immer finden ("'Brilinear' ist toll, weil das Zumischen des zweiten, unschärferen Mip-Levels erst ein wenig weiter hinten beginnt").
3. War unklar formuliert. Sorry, so meinte ich es auch.

[Mr. Lolman]

Original geschrieben von Quasar
1. Das sagte ich doch selbst.
2. Eine Ausrede läßt sich immer finden ("'Brilinear' ist toll, weil das Zumischen des zweiten, unschärferen Mip-Levels erst ein wenig weiter hinten beginnt").
3. War unklar formuliert. Sorry, so meinte ich es auch.

2. Eher nicht. Allein schon theoretisch sollte es klar sein, da beim bilinearem AF, mit dem Störfaktor der Bilinearität des AFs, eine geringe Ungenauigkeit*, (seis jetzt Brilinear, Dithering, oder einfach ein Rechenfehler im Algorithmis) eine optische Verbesserung bewirken können wenn man davon ausgeht, dass die Texturen beim bi-AF sh1ce aussehen, was ja nur tw. der FAll st.


("'Brilinear' ist toll, weil das Zumischen des zweiten, unschärferen Mip-Levels erst ein wenig weiter hinten beginnt").

Genau das ist nämlich ein Problem des "bilinearen" AF.

Wenn man auf einem halbwegs vernünftigen Monitor die Uru AF Screenshots miteinander vergleicht, weiss man was ich ich meine..

Auch die Bodentexturen in bei den von LS verlinkten MP2 Screenshot im NV Forum, sehen tw. etwas verwaschen aus.






*Ungenauigkeit vom Stnadpunkt der bilinearität aus betrachtet.



Original geschrieben von PaulClean
hier gibts was neues, falls es euch interessiert:

http://grafik-selection.at/ (http://diebspiel.de/index.php?id=1730)

geiles zeugs...:O

Wegen dem sh1ce sollte man dich bannen.

[Quasar]

Da ich leider nur den Monitor aus meiner Sig habe (der andere ist noch kümmerlicher), werde ich wohl damit leben müssen, diesen Makel nicht wahrnehmen zu können.

Dafür löst mein Monitor Helligkeitsunterschiede recht gut auf. :naughty:

[kmf]

Keine Panik, Leute...

Mein Moni ist nun schon fast 7 Jahre alt. Also ich merke nix von dem, was ihr da schreibt. Solange das Teil noch funktioniert soll mir der Bug irgendwo vorbeigehen.
Ich meine damit, wenn es wirklich wichtig wäre, würde ich auch lauthals meinen Senf auch dazugeben. Wer in Gottes Namen, von euch hat überhaupt irgendwann mal was davon verspürt? Jetzt, wo der angebliche Bug bekannt ist, mault ein jeder - nee, es gibt auch Ausnahmen. Aber es ist schon lustig, in der jetzigen langweiligen Zeit, zieht man sich gerne an jedem Strohhalm hoch. Letzte Woche war es der 3MdMark-Thread von Mapel110, diese Woche ist nun dieser Thread.
Ati was hast du uns mit deinem Eingeständnis nur angetan?

OK, ich gebs zu, ich gehöre zu denen die nichts von Bildqualität bei irgendwelchen Winkelabhängigkeiten und irgendwelcher FPs, seis nun 16 oder 32 richtig verstehen und nachvollziehen können. Vielleicht liegts auch nur an meinem Intellekt.

Ich sag mir, die Hauptsache ist doch, das Game, das ich gerade zocke, schaut einigermaßen gut aus. Die Mehrheit hier, mich eingeschlossen, kann eh mit der ganzen dahintersteckenden Theorie nix anfangen. Die paar Spezialisten, die es hier gibt, mal ausgenommen. Wer hier mitreden will, muß sehr viel Fleiß und Zeit investieren, um diese äußerst komplizierte Materie zu verstehen und richtig interpretieren zu können. Ich habe die nicht.

Und was in Mapels Thread steht, wird sich hier zum x.ten Mal wiederholen. Gähn...

So, ich hab heute was besseres zu tun, ich geh jetzt mit meiner besseren Hälfte ins Kino und danach zum Tanzen.

Man liest sich!

[zeckensack]

Original geschrieben von Quasar
Was ich glaube, spielt keine Rolle. Der (DX9-)RefRast rechnet AFAIK mit FP24, Mindestanforderung für 2.0-Shader, wenn kein pp_hint gesetzt ist, was die Anforderung auf FP16 senken würde. Ich weiß es wirklich nicht genau, aber es würde mich doch schwer wundern, wenn der Refrast mit FP24 rechnet (statt FP32).
Grund: FP32 ist auf marktüblichen Prozessoren HW-beschleunigt :naughty:

32 bit floats können CPUs eben direkt benutzen. Bei FP24 wäre das ein riesen Aufwand, der Refrast nochmal deutlich verlangsamen würde. Ich wüßte nicht warum ?(

[Quasar]

Ich versuche gerade, die Suche zu nutzen um die Quelle zu finden, aber das Forum bzw. sein aktueller Zustand macht es nicht gerade leicht.

IIRC gab es ein 'Gespräch' zwischen dem gesperrten Razor und Demi, wobei letzterer ausführte, daß der RefRast eh nicht auf Geschwindigkeit ausgelegt sei.

edit:
Ich kann den Beleg nicht finden, also nehme ich vorerst meine Behauptung bezgl. des FP24 beim RefRast zurück.

[Demirug]

Original geschrieben von zeckensack
Ich weiß es wirklich nicht genau, aber es würde mich doch schwer wundern, wenn der Refrast mit FP24 rechnet (statt FP32).
Grund: FP32 ist auf marktüblichen Prozessoren HW-beschleunigt :naughty:

32 bit floats können CPUs eben direkt benutzen. Bei FP24 wäre das ein riesen Aufwand, der Refrast nochmal deutlich verlangsamen würde. Ich wüßte nicht warum ?(

Der Wertebereich des Refrast für 1.X Shader entspricht zumindestens FP32. Den Rest müsste man einmal ausprobieren. Den Quellcode des Refrast bekommt man ja leider nicht so einfach.

[ow]

Original geschrieben von Demirug
Den Quellcode des Refrast bekommt man ja leider nicht so einfach.

Ist der kein Teil des DDK mehr oder gibt´s keine DDKs mehr?

[Demirug]

Original geschrieben von ow
Ist der kein Teil des DDK mehr oder gibt´s keine DDKs mehr?

Ja der Refrast Quellcode gehört zum DDK aber das bekommen nur noch wenige auserwählte komplett. Als normal sterblicher bekommt man bestenfalls noch die API Dokumentation.

[Gast]

Bitte nagelt mich nicht darauf fest, aber der Refrast arbeitet meines Wissens vorzugsweise in FP32 (auch z.B. fuer 8 bit Farben durch vorherige Konvertierung wenns sein muss). HW macht das natuerlich nicht.

Der WHQL DCT ist ohnehin fragwuerdig, da er einfach fuer Tausende von simplen Testszenen die Bilder des Refrast mit den Bildern der HW vergleicht. Abweichende Farbwerte (egal ob 1 oder 8 Bit Unterschied) an derselben Position oder identische Farbwerte an einer Nachbarposition gelten als Fehler. Je nach Testszene sind mehr oder weniger willkuerlich Toleranzgrenzen festgesetzt, um den Test zu bestehen, zB. 85% oder 95% korrekt. Insbesondere bei dependent texture read ist das Verfahren ziemlicher Unsinn (IMHO).

[Gast]

Nachtrag: HW, die z.B. genauer oder einfach nur anders arbeitet, wird ebenfalls mit einem Falschpixel/bild bestraft.

[bla]

Original geschrieben von kmf
Keine Panik, Leute...

Mein Moni ist nun schon fast 7 Jahre alt. Also ich merke nix von dem, was ihr da schreibt. Solange das Teil noch funktioniert soll mir der Bug irgendwo vorbeigehen.
Ich meine damit, wenn es wirklich wichtig wäre, würde ich auch lauthals meinen Senf auch dazugeben. Wer in Gottes Namen, von euch hat überhaupt irgendwann mal was davon verspürt? Jetzt, wo der angebliche Bug bekannt ist, mault ein jeder - nee, es gibt auch Ausnahmen. Aber es ist schon lustig, in der jetzigen langweiligen Zeit, zieht man sich gerne an jedem Strohhalm hoch. Letzte Woche war es der 3MdMark-Thread von Mapel110, diese Woche ist nun dieser Thread.
Ati was hast du uns mit deinem Eingeständnis nur angetan?

OK, ich gebs zu, ich gehöre zu denen die nichts von Bildqualität bei irgendwelchen Winkelabhängigkeiten und irgendwelcher FPs, seis nun 16 oder 32 richtig verstehen und nachvollziehen können. Vielleicht liegts auch nur an meinem Intellekt.

Ich sag mir, die Hauptsache ist doch, das Game, das ich gerade zocke, schaut einigermaßen gut aus. Die Mehrheit hier, mich eingeschlossen, kann eh mit der ganzen dahintersteckenden Theorie nix anfangen. Die paar Spezialisten, die es hier gibt, mal ausgenommen. Wer hier mitreden will, muß sehr viel Fleiß und Zeit investieren, um diese äußerst komplizierte Materie zu verstehen und richtig interpretieren zu können. Ich habe die nicht.

Und was in Mapels Thread steht, wird sich hier zum x.ten Mal wiederholen. Gähn...

So, ich hab heute was besseres zu tun, ich geh jetzt mit meiner besseren Hälfte ins Kino und danach zum Tanzen.

Man liest sich!


endlich bringts mal einer aufm punkt!
der sinnvollste post in diesem thread!