Benchmark CS:Source: 6800 Ultra gegen X800XT PE bei Driverheaven.net

[kuj0n]

http://www.driverheaven.net/showthread.php?p=423812#post423812

Gerade bei cstrike.de gesehen da dachte ich man könnte das ja mal posten.
Kann mir jemand dieses Ergebnis mal erklären?

Bei Doom3 gab es ja auch signifikante Anzeichen warum dort die 6800er Serie schneller ist, warum hier die X800 - nur weil HL2 von ATI gesponsert wird?

Danke, kuj0n


Bitte keinen Flamethread starten!!!

[Kladderadatsch]

http://www.forum-3dcenter.org/vbulletin/showthread.php?t=163565
(immer schön in verwandte unterforen schauen;) )

[Xmas]

Dann eher dieser Thread:
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=163208

Hauptsächlich ist die X800XT schneller weil höherer Core-Takt = höhere Füllrate und höherer Speichertakt = höhere Bandbreite.

[kuj0n]

Dann eher dieser Thread:
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=163208

Hauptsächlich ist die X800XT schneller weil höherer Core-Takt = höhere Füllrate und höherer Speichertakt = höhere Bandbreite.

Ok darauf lasse ich mich ein, danke Xmas...

:heart: :biggrin:

[LovesuckZ]

Hauptsächlich ist die X800XT schneller weil höherer Core-Takt = höhere Füllrate und höherer Speichertakt = höhere Bandbreite.

Koennte HL2 aufgrund der viele Shadern so stark fillratelimitierend sein, dass das zuschalten von AA keinen so deutlichen Unterschied macht?
Im beyond3d.com forum (http://www.beyond3d.com/forum/viewtopic.php?p=351778#351778) verliert ein User nur 8 Frames auf seiner 9600XT von 2AA auf 6AA...

[deekey777]

Koennte HL2 aufgrund der viele Shadern so stark fillratelimitierend sein, dass das zuschalten von AA keinen so deutlichen Unterschied macht?
Im beyond3d.com forum (http://www.beyond3d.com/forum/viewtopic.php?p=351778#351778) verliert ein User nur 8 Frames auf seiner 9600XT von 2AA auf 6AA...

Wenn ich von 2xAA auf 6xAA gehe, verliere ich nur ~3 Frames. Aber: Wenn ich von 0xAA auf 2xAA gehe, sieht es so aus: 73 -> 29 fps. Und ich hab keine Ahnung, wieso...

[kuj0n]

Wenn ich von 2xAA auf 6xAA gehe, verliere ich nur ~3 Frames. Aber: Wenn ich von 0xAA auf 2xAA gehe, sieht es so aus: 73 -> 29 fps. Und ich hab keine Ahnung, wieso...

So ungefähr sieht das bei mir auch aus....

[MadManniMan]

So ungefähr sieht das bei mir auch aus....

Centroid Dingens vielleicht? :ratlos:

[AYAlf]

endlich zeigen sich die wirklichen staerken von ati's neustem streich. wie es ausschaut gehoert auch bei dieser kartengeneration die krone weiterhin ati. da wir alle annehmen muessen, dass die neuen spiele eher auf direct3d basieren werden. ich haette es nur nicht fuer moeglich gehalten, dass nvidia ueber 3o% langsamer ist. ein wenig mehr power haette ich der 6800 von nvidia schon zugetraut.

[Quasar]

[...] a 30% performance difference ( 74fps to 52fps ) is, to be honest, a massive dissapointment if your a Geforce 6800 Ultra user.

Dem stelle ich mal folgende These entgegen:

"30% performance difference ( 74fps to 52fps ) could reasonably be expected, if you are a Geforce 6800 Ultra user with at least one cell of gray matter differentiating you from a fanboy."

Alles unterhalb von 30% (Ultra vs. XT-PE) ist eigentlich ein Schlag ins Gesicht für ATis veraltete Technologie.

[[dzp]Viper]

Dem stelle ich mal folgende These entgegen:

"30% performance difference ( 74fps to 52fps ) could reasonably be expected, if you are a Geforce 6800 Ultra user with at least one cell of gray matter differentiating you from a fanboy."

Alles unterhalb von 30% (Ultra vs. XT-PE) ist eigentlich ein Schlag ins Gesicht für ATis veraltete Technologie.

muss ich jetzt nicht verstehen oder?

[Quasar]

520:400=1,3

Jetzt besser?

[[dzp]Viper]

520:400=1,3

Jetzt besser?

k
aber ob nun jemand die leistung so oder so erreicht, ist doch eigentlich egal (finde ich) Was Zählt ist das, was am ende rauskommt :)

[seahawk]

Das Ergebnis ist vernichtend für NV.

[egdusp]

Ist driverheaven ne FanATIker Seite?

mfg
egdusp

[Quasar]

@[dzp]Viper

Das ist richtig, aber wenn eine halbwegs ähnliche Anordnung und Anzahl von Funktionseinheiten (um nicht zu sagen 16 Pixelpipelines) vorhanden ist, muss man eben damit rechnen, daß in manchen Fällen die ganz normale Füllrate 1:1 durchschlägt und das sind eben 30% - da gibt's keine großartige Magie oder Stärken bzw. Schwächen, das ist einfach so.

[Modulor]

Das Ergebnis ist vernichtend für NV.

Das könnte man vielleicht sagen wenn sich das Verhältnis zwischen beiden Karten in 1600x1200 auch in allen andern (praxisnäheren) Auflösungen ergeben würde - und selbst dann...


Aufgrund der doch signifikanten Unterschiede :| zwischen den benchmarks von driverheaven und VR-Zone zeigt sich einmal mehr daß man kein Spiel benchen sollte bevor es draußen ist und daß man derartigen vorab benchmarks keine allzu große Aufmerksamkeit schenken sollte...

[winter]

Mir ist übrigens aufgefallen dass sich die komischen Werte von dem (für Fanboygehabe bekannten) Driverheaven.net nicht mit denen von Vr-Zone decken. In den Fällen wo AA/AF aktiviert ist erreicht die Geforce bei Driverheaven nicht annähernd die Werte von Vr-Zone. Wenn ich nicht annehmen möchte dass an den Optimierungen im AF rumgepfuscht wurde möchte ich annehmen, dass die Benchmarks ein bisschen frisiert wurden X-D
Alternativ könnte es natürlich auch ein für NV ungünstiger Renderingpfad gewesen sein.
Tatsache ist jedoch, dass die XT-PE in beiden Fällen schneller als die Ultra ist. Wobei mich ehr der Vergleich mit einer Extreme interessieren würde aber nuja... Die XT-PE gibts ja inzwischen auch nimma.

[egdusp]

Die Source Engine in HL2 benutzt ja laut Demi hauptsächlich viele kurze Shader, so dass die Shadereinheiten (zumindest bei NV4x und R4x0) nicht der limitierende Faktor sein dürften.

HL2 ist ja auf Radeon zugeschnitten, so dass jede Pipeline immer annähernd maximal ausgenutzt werden wird. Die NV4x Pipelines werden shadermäßig einfach nicht ausgenutzt. Damit möchte ich Valve keine Benachteiligung von NV unterstellen. Es war für sie einfach der Ansatz viele kurze Shader einzubauen. IMHO (und ich bin kein Experte) ist es ein beträchtlicher Aufwand viele kurze Shader so umzustricken, dass sie auf NV4x Pipelines schneller laufen. Dazu müssten sie wahrscheinlich länger (komplexer) gemacht werden, was einer Optimierung zuwidersprechen scheint.

Eher könnten Shader besser aussehen ohne Performanceverlust bei NV4x, aber die bestehenden Shader schneller zu machen, halte ich für kaum möglich.

Es ist allerdings wohl kein Problem bei zukünftigen Spielen in die Source Engine Shader einzubauen, die direkt von NV4x Pipelines profitieren. Evtl. werden wir auch MODs sehen, die HL2 schöner machen ohne Performanceverlust.

Alles Spekulation meinerseits.

mfg
egdusp

[MeLLe]

endlich zeigen sich die wirklichen staerken von ati's neustem streich. wie es ausschaut gehoert auch bei dieser kartengeneration die krone weiterhin ati. da wir alle annehmen muessen, dass die neuen spiele eher auf direct3d basieren werden. ich haette es nur nicht fuer moeglich gehalten, dass nvidia ueber 3o% langsamer ist. ein wenig mehr power haette ich der 6800 von nvidia schon zugetraut.
Die Leistung in HL2 hat nichts mit der verwendeten API zu tun.

oder anders:
x800-Karten sind in HL2 nicht deswegen "schnell", weil sie eine Stärke in DXGraphics haben. Und sie sind nicht deswegen in Doom3 "langsam", weil sie eine Schwäche in Bezug auf OpenGL haben. Es sind nur die unterschiedlichen Anforderungen der jeweiligen Grafikengine. Die eine will Fillrate, die andere Cullrate. So einfach ist das.

[Gast]

Es sind nur die unterschiedlichen Anforderungen der jeweiligen Grafikengine. Die eine will Fillrate, die andere Cullrate. So einfach ist das.

Und warum liegt die 6800GT dann soweit "hinten", obwohl sie die quasi gleiche Füllrate hat wie die X800Pro?

http://www.firingsquad.com/hardware/half-life2_vst/page4.asp

[Winter[Raven]]

Und warum liegt die 6800GT dann soweit "hinten", obwohl sie die quasi gleiche Füllrate hat wie die X800Pro?

http://www.firingsquad.com/hardware/half-life2_vst/page4.asp

Nochmal für dich Gast, es sind die MHZ ;)

[seahawk]

Quatsch die Füllrate ergibt sich aus den Pipes * den Mhz. Also dürfte die Pro die GT nicht so dominieren.
Hier sieht man einfach, dass bei einem normalen Spiel die Radeon deutlich überlegen ist. Sie bleibt weiterhin die beste Karte um DX9 Spiele schnell und in guter Qualität zu rendern.

[Gast]

']Nochmal für dich Gast, es sind die MHZ ;)

MHz wenn schon...
Auserdem sagt die Taktfrequenz eines Prozessors nichts über seine Leistungsfähigkeit aus, etwas kurzsichtig gedacht.

[Demirug]

firingsquad hat es leider versäumt die Filtereinstellungen anzugeben so das man schwer abschätzen kann wie viel Füllrate im Durchschnitt pro Pixel benötigt wurde. Diese Menge kann bei unterschiedlichen Einstellungen stark abweichen.

[LovesuckZ]

Und warum liegt die 6800GT dann soweit "hinten", obwohl sie die quasi gleiche Füllrate hat wie die X800Pro?
http://www.firingsquad.com/hardware/half-life2_vst/page4.asp

Fuer diesen Test benoetigt man Fillrate, Speicherbandbreite ist vernaechlaessigbar.
Aufgrund der AF Optmierungen spart ATi mehr als Nvidia. Deswegen sind sie 20% vorne. Dies wird sich mit den naechsten Treiber eventuell in Richtung Nvidia aendern.
Mit dem 65.65 sollten sich GT, Pro und Ultra innerhalb einer Spanne von 10% einpendeln.
Das waere dann nicht wirklich berauschend fuer ATi.

[aths]

http://www.driverheaven.net/showthread.php?p=423812#post423812

Gerade bei cstrike.de gesehen da dachte ich man könnte das ja mal posten.
Kann mir jemand dieses Ergebnis mal erklären?

Bei Doom3 gab es ja auch signifikante Anzeichen warum dort die 6800er Serie schneller ist, warum hier die X800 - nur weil HL2 von ATI gesponsert wird?Nein, weil die X800 höher taktet, während die Shader an der Füllrate hängen.

IIRC begann die Entwicklung von HL2, als die TNT2 noch modern war. Als sich später der Shader-Einsatz abzeichnete, konnte man mit DX8 ohnehin keine langen Shader nutzen. Radeon 9700 bot da schon deutlich mehr, aber auf diesem Tech-Level scheint die Shadertechnik von HL2 auch festgezurrt. Ich zweifle, dass dem NV40 da SM 3.0-Support entscheidend helfen kann.

Eher wird NV auf die Idee kommen, weiter an der Filterqualität zu sparen (und sich ATIs Filterqualität immer weiter annähern) um den Füllratenverbrauch zu senken.

[LovesuckZ]

Techreport.com (http://www.techreport.com/etc/2004q3/source-engine/index.x?pg=1) hat nun auch ihre Ergebnisse online.
Hier schneiden die NV40 Karten besser ab als bei Firingsquad.

[Gil-galad]

Aufgrund der AF Optmierungen spart ATi mehr als Nvidia.

Wo bitte steht bei Driverheaven denn, ob sie die Optimierungen angelassen haben oder nicht? Und wo steht, dass sie bei NVidia die Optimierungen ausgeschaltet haben?

[LovesuckZ]

Wo bitte steht bei Driverheaven denn, ob sie die Optimierungen angelassen haben oder nicht? Und wo steht, dass sie bei NVidia die Optimierungen ausgeschaltet haben?

"Nvidia optimisations were on for the testing."

Es sollte bekannt sein, dass ATi staerker optimiert beim Einsatz von AF. Sie sparen dadurch mehr Fillrate als Nvidia und dies wirkt sich in diesen Test mehr als deutlich aus.
Nehmen wir den Gamers-depot.com (http://www.gamers-depot.com/hardware/video_cards/source/002.htm) Vergleich.
Und welch Wunder, mit ausgeschalteten Optimierungen liegt die Pro und GT auf dem selben Leistungsniveau.

[ShadowXX]

Wo bitte steht bei Driverheaven denn, ob sie die Optimierungen angelassen haben oder nicht? Und wo steht, dass sie bei NVidia die Optimierungen ausgeschaltet haben?

Wenn Sie bei beiden die Treiber auf Default gelassen haben (was zumindest bei meinem 61.77 Quality entspricht, d.h. Bri ist an, aber Stageoptimierung ist aus (zumindest sieht es bei mir so bei "default" aus)), hat ATI gleich 2 vorteile...

Stageoptimierung ist an und die LOD-Spielerei ist an....

Und nach dem letzen Computerbase-Artikel (http://www.computerbase.de/news/hardware/grafikkarten/nvidia/2004/august/forceware_6562_woher_performance/)
gehe ich sowieso davon aus, das auch bei ATI (und demnächst auch bei nV) viel mehr "Speed" über die Lod-Spielerei als über die Bri-Optimierung gewonnen wird...

Auszug aus Computerbase-Artikel
Weiter fällt auf, dass die trilineare Optimierung allein nur für einen Bruchteil des Performancegewinns zuständig ist und im Gegenteil an erster Stelle der zugewinnträchtigen Einzeloptimierungen die neu hinzugekommene „Anisotropic Sample Optimization” steht, die, so vermuten wir derzeit, ähnlich den von uns beschriebenen Reg-Einträgen R420AnisoLOD und RV350ANTHRESH arbeitet, kurz gefaßt also mit unpassender Reduktion und Steigerung der genutzen AF-Samples. Wir versuchen, das in den kommenden Tagen mit den entsprechenden Methoden genauer zu untersuchen.



Ich hätte die Test gerne mal auf beiden Karten mit allen Optimierungen aus (aka HQ bei nV und Registry-Hack bei ATI)...

[Quasar]

Eher wird NV auf die Idee kommen, weiter an der Filterqualität zu sparen (und sich ATIs Filterqualität immer weiter annähern) um den Füllratenverbrauch zu senken.

Da ham'se schon mit angefangen. Der 65.62er "bietet" auf dem nV40 auch schon eine der ATi-Reduzierung sehr ähnliche Sparmaßnahme.

[r@w]

Eher könnten Shader besser aussehen ohne Performanceverlust bei NV4x, aber die bestehenden Shader schneller zu machen, halte ich für kaum möglich.Da man das Branching in der HL2-Engine Software-seitig löste und somit für alle nur erdenklichen Fälle viele kleine Mini-Shader geschrieben hat (die dann auch noch überflüssiger weise in den VRAM speicher geladen werden), dürfte sogar exorbitantes Optimierungspotential vorliegen. Die Frage ist halt nur, ob es von Valve gewünscht ist, an dieser Stelle Optimierungen für SM3-Hardware vorzunehmen...

...vermutlich passiert dies erst, wenn auch ATI SM3-fähige Hardware am Laufen hat.
:D

Razor

[seahawk]

@ Quasar

Wie man sieht müssen sie das auch, da sie sonst untergehen. Den Kunden geht es nur um die Länge der Balken und sonst nichts. BQ ist nunmal kein Thema.

[Gil-galad]

Wenn Sie bei beiden die Treiber auf Default gelassen haben

Ich rede von Driverheaven und nicht von Tech Report.

[seahawk]

NV Optimierungen waren an - sthet im ersten Post. Damit ist abgesehen von den LOD Spielerein kein Unterschied zwischen ATI und NV.

[ShadowXX]

NV Optimierungen waren an - sthet im ersten Post. Damit ist abgesehen von den LOD Spielerein kein Unterschied zwischen ATI und NV.

Jo...aber genau diese LOD-Spielerei bringt massig "Speed"....viel mehr als Bri oder Stageoptimierung....

Davon mal ganz abgesehen, gehen die Ergebnisse der einzelnen Benches im Moment sowieso verdammt stark auseinander...IMHO kann man diese Momentan noch nicht richtig ernst nehmen...egal von welcher Seite...

(Und die 0xAA/0XAF Ergebnisse von DH sind ja nun wirklich für die Tonne und entsprechen überhaupt keinem Ergebnis einer anderen Seite...)

[r@w]

Hier sieht man einfach, dass bei einem normalen Spiel die Radeon deutlich überlegen ist. Sie bleibt weiterhin die beste Karte um DX9 Spiele schnell und in guter Qualität zu rendern.Und das machst Du jetzt genau woran fest?
Am Test einer Beta auf einer noch viel weniger vertrauenswürdigen Seite?
:confused:

Dass die ATI's hier vorne liegen sollten, ist mehr als klar.
Auch würde es wohl jeden wundern, wenn dem nicht so wäre.
Nur dürften 10, maximal 20% hier wohl eher realistisch sein, meinst Du nicht?
;-)

Razor

[SamLombardo]

Techreport.com (http://www.techreport.com/etc/2004q3/source-engine/index.x?pg=1) hat nun auch ihre Ergebnisse online.
Hier schneiden die NV40 Karten besser ab als bei Firingsquad.


Das sieht doch für NV ganz ordentlich aus.

Und diesen Satz aus der Conclusion zum Vergleich 6800GT/X800pro halte ich für ausgesprochen interessant, da diese Karten für viele sowieso interessanter sind als die ultraHigh End karten
"The GeForce 6800 GT slightly but surely outperforms the Radeon X800 Pro without aniso and AA. With 4X AA and 8X aniso, the two cards are virtually tied across all four resolutions we tested."

[Quasar]

@ Quasar

Wie man sieht müssen sie das auch, da sie sonst untergehen. Den Kunden geht es nur um die Länge der Balken und sonst nichts. BQ ist nunmal kein Thema.

Das ist leider richtig, solange die Reviewer auf nichts anderes eingehen. Sei es aus Zeitdruck, Hersteller-Sample-Druck oder aus Unkenntnis.

[ShadowXX]

Das ist leider richtig, solange die Reviewer auf nichts anderes eingehen. Sei es aus Zeitdruck, Hersteller-Sample-Druck oder aus Unkenntnis.

Leider leider hast du damit mehr als Recht...ich freue mich schon darauf, wenn uns die Grafik IHVs bei der nächsten Generation Point-Sampling als neustes vom neusten und State-Of-The-Art präsentieren werden :(

(Und AF dann sowieso im allerletzen und hintersten Treiber-Fenster und nur mit Freischaltcode einschaltbar ist...)

[DanMan]

Dann eher dieser Thread:
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=163208

Hauptsächlich ist die X800XT schneller weil höherer Core-Takt = höhere Füllrate und höherer Speichertakt = höhere Bandbreite.
Ich finde, wenn schon auf andere Threads verwiesen wird, dann sollten die neuen, doppelten auch gleich geschlossen werden.

[Quasar]

Leider leider hast du damit mehr als Recht...ich freue mich schon darauf, wenn uns die Grafik IHVs bei der nächsten Generation Point-Sampling als neustes vom neusten und State-Of-The-Art präsentieren werden :(

(Und AF dann sowieso im allerletzen und hintersten Treiber-Fenster und nur mit Freischaltcode einschaltbar ist...)


.....flimmern??? Seh' ich nicht - aber chön charf ist's!

:down: :kotz: :down:

[r@w]

Wenn Sie bei beiden die Treiber auf Default gelassen haben (was zumindest bei meinem 61.77 Quality entspricht, d.h. Bri ist an, aber Stageoptimierung ist aus (zumindest sieht es bei mir so bei "default" aus)), hat ATI gleich 2 vorteile...Falsch.
Per Default sind alle Optimierungen 'On'.

Das ist bei Dir vermutlich anders, wenn Du nur einfach 'drüber' installiert hast...

Ich hätte die Test gerne mal auf beiden Karten mit allen Optimierungen aus (aka HQ bei nV und Registry-Hack bei ATI)...Ein schöner Traum...

Razor

[deekey777]

Techreport.com (http://www.techreport.com/etc/2004q3/source-engine/index.x?pg=1) hat nun auch ihre Ergebnisse online.
Hier schneiden die NV40 Karten besser ab als bei Firingsquad.

Firing Squad:
"We turned up the detail settings to their maximums on the high-end cards, this means that model, texture, and shadow detail were all set to high, while water detail was set to reflect all objects."
TechReport:

"The dialog below shows the settings we used in testing, with the exception of the water detail problem noted above. ..."
http://www.techreport.com/etc/2004q3/source-engine/settings.gif


Unterschied gesehen?
Wasserreflexionen auf "reflect all" kosten bei mir etwa 10 Frames.


€: Wenn mich nicht alles täuscht, sollte HL2 zunächst auf der Q3 Engine enwickelt werden, was aber verworfen wurde.

[LovesuckZ]

Es scheint sich wohl wirklich heraus zukristalisieren, dass Valve sich das Recht herausnimmt, die Karten nicht nach ihren Faehigkeiten sondern nach der deviceid einzuordnen. :down:
Nun, kann es noch schlimmer kommen?

[Gast]

So langsam kristallisiert sich heraus das in einigen Benchmarks es nicht ganz "sauber" zu ging...

http://techreport.com/etc/2004q3/source-engine/index.x?pg=4
(6800GT & X800Pro gleichauf)

http://www.firingsquad.com/hardware/half-life2_vst/page4.asp
(X800Pro weit vorraus)


Ich frag mich wie bei einem fast gleichen Testsystem so dermasen die Ergebnisse sich unterscheiden können...
Beide nutzen die selbe CPU das selbe Board... vieleicht auch die selben Grafikkarten :lol:

[r@h]

Nun, kann es noch schlimmer kommen?Wart's ab!
Das ist doch erst der Anfang...
:D

Razor

[Gast]

Hm sollten die Fire-Leute nicht besser 8AF gegen 16AF benchen? (oder weiss ich etwas nicht? :) )
Und in sachen HQ ist das 8s (AA) der NV schlecht gewählt bei leuten die nur auf die Balken sehen bewirkt das ein anderes Bild...

[Gast]

Hm sollten die Fire-Leute nicht besser 8AF gegen 16AF benchen? (oder weiss ich etwas nicht? :) )
Und in sachen HQ ist das 8s (AA) der NV schlecht gewählt bei leuten die nur auf die Balken sehen bewirkt das ein anderes Bild...

^ Mein Text. und ich meine nicht Fire-Leute sondern Driverheaven!

[Jesus]

Ihr regt euch schon wieder viel zu viel auf :wink:

Genau wie bei D3 @ [H] ... das sind jetzt ein paar tests eines Spiels das es noch nichtmal gibt.

Ernst nehmen kann man das imo sowieso noch nicht. Da wird sich sicher noch einiges ändern .

[dildo4u]

http://techreport.com/etc/2004q3/source-engine/cs-4x8x-640.gif

http://techreport.com/etc/2004q3/source-engine/cs-4x8x-1024.gif
Was ich mich aber schon frage was hat Valve bei der texture kompression verhaun das die 9800pro so gehen die 9800XT abkackt und das sogar in 640*480? Schon derbe wenn man bedenkt wie viele leute eine 9800pro haben und dachten ihre karte müsste wie fürs spiel gemacht sein

[Quasar]

Daran allein kann's normalerweise nicht liegen - auch die GF6800 hat nur 128MB und verbraucht durch F@S noch mehr VRAM bei FSAA als die Radeons.

Ich denke, da ist eher ein Fehler passiert, wenn ich mir anschaue, wie nah sie bei einer R9600XT liegt, die sie eigentlich um mind. 66% (grob übern Daumen) schlagen müsste.

[IVN]

@dildo4u

That must be a failure.Look at the 9600xt scores,it also has 128MB mem. and even an 128 bit mem.con.

OR maybe r9800xt has 3DC,but we didn't know that. :D

[Gast]

hm,vielleicht hat die 9800xt besseren speicher drauf?
was die ladezeiten der texturen verkürzt?

[Gast]

hm,vielleicht hat die 9800xt besseren speicher drauf?
was die ladezeiten der texturen verkürzt?

re

oder es ist eine 9800pro mit 128bit ..?

[Quasar]

Firing Squad:
"We turned up the detail settings to their maximums on the high-end cards, this means that model, texture, and shadow detail were all set to high, while water detail was set to reflect all objects."
TechReport:

"The dialog below shows the settings we used in testing, with the exception of the water detail problem noted above. ..."
http://www.techreport.com/etc/2004q3/source-engine/settings.gif


Unterschied gesehen?
Wasserreflexionen auf "reflect all" kosten bei mir etwa 10 Frames.


€: Wenn mich nicht alles täuscht, sollte HL2 zunächst auf der Q3 Engine enwickelt werden, was aber verworfen wurde.

Der Quote von Techreport bezieht sich, wie TR auch schreibt, auf die GeForceFX-Karten, nicht auf den nV40. ;)

[Jesus]

Was ich mich aber schon frage was hat Valve bei der texture kompression verhaun das die 9800pro so gehen die 9800XT abkackt und das sogar in 640*480? Schon derbe wenn man bedenkt wie viele leute eine 9800pro haben und dachten ihre karte müsste wie fürs spiel gemacht sein

ist wohl der Speicher:

http://firingsquad.com/hardware/half-life2_vst/images/v800x4.gif

[dildo4u]

ist wohl der Speicher:

http://firingsquad.com/hardware/half-life2_vst/images/v800x4.gif


Jo aber warum bricht dann die 6800 nicht ein die hat auch nur 128mb?

[deekey777]

Der Quote von Techreport bezieht sich, wie TR auch schreibt, auf die GeForceFX-Karten, nicht auf den nV40. ;)


Jetzt hast du mich ganz verwirrt.
TR:"Second, the GeForce FX cards hit a few bumps in the road in this beta version of CS: Source. The Source engine auto-detects recommended settings for one's video card, and on any card in the GeForce FX line, it practically insists on turning off water reflectivity. As a result, we've benchmarked the GeForce FX line without water reflectivity, and we've put an asterisk next to the name of each FX card in our results, to remind you of that fact. There's no great visual difference between the water's look on the FX line and on other cards, but if the menu settings mean anything, the FX cards are doing less work."

So weit, so gut.
Laut dem Bildchen mit den Settings wurde mit "reflect world" getestet. CSS beta kennt eine weitere, dritte Stuffe "reflect world", die noch anspruchsvoller ist. DH hat mit der dritthöchster Einstellung getestet.

[seahawk]

und die 5900XT ??

[aths]

Stageoptimierung ist an und die LOD-Spielerei ist an....Diese "LOD-Spielerei" ändert nicht am LOD-Bias. Der Begriff ist imo falsch, zumindest sehr unglücklich.

[aths]

Da ham'se schon mit angefangen. Der 65.62er "bietet" auf dem nV40 auch schon eine der ATi-Reduzierung sehr ähnliche Sparmaßnahme.Ist das (via HQ-Setting) abschaltbar?

[Winter[Raven]]

Ist das (via HQ-Setting) abschaltbar?

Soweit ich gesehn habe JA :)

Ich wäre auch sehr von Nvidia entteuscht wenn die jetzt das ding immer ON hätten...

[Quasar]

Ist das (via HQ-Setting) abschaltbar?
Ja. HQ produziert dieselben Resultate, wie noch der 61.77er und der 61.34er, soweit mir bekannt.

[Quasar]

Jetzt hast du mich ganz verwirrt.
[...]
So weit, so gut.
Laut dem Bildchen mit den Settings wurde mit "reflect world" getestet. CSS beta kennt eine weitere, dritte Stuffe "reflect world", die noch anspruchsvoller ist. DH hat mit der dritthöchster Einstellung getestet.

Welche gibt es denn insgesamt dort? Reflect World und Reflect World sind doch dasselbe....

*auchverwirrtist*

[IVN]

@Quasar

No,reflect world and reflect all objects are two options,but i don't know the 3rd.

[deekey777]

@Quasar

No,reflect world and reflect all objects are two options,but i don't know the 3rd.

Water detail: No reflections, reflect world und reflect all. ;)

[Quasar]

Ah, danke. :)

[hmx]

ist wohl der Speicher:

http://firingsquad.com/hardware/half-life2_vst/images/v800x4.gif

Hmmm aber die 9800xt ist fast 30% schneller als die 9800pro 256MB. Das kann
eigendlich nicht sein...

[Adam D.]

Ich verstehe die Angaben nicht bei TechReport...Ich habe mit meiner GT 79fps bei 1280x960x32, höchste Details (Reflect All) und 4xAA + 16:1. Hab's mehrmals versucht, es kam immer etwa das selbe raus. Und ich habe "nur" einen XP 3200+ und 1GB-RAM...

http://www.picupload.net/files/20042008/1093023237.png

[deekey777]

Ich verstehe die Angaben nicht bei TechReport...Ich habe mit meiner GT 79fps bei 1280x960x32, höchste Details (Reflect All) und 4xAA + 16:1. Hab's mehrmals versucht, es kam immer etwa das selbe raus. Und ich habe "nur" einen XP 3200+ und 1GB-RAM...

http://www.picupload.net/files/20042008/1093023237.png


Hast du auch ohne AA gebencht? Nach dem heutigen Update funktioniert bei mir (9800Pro) das interne AA, nur per CP gibt es AA.

[ShadowXX]

Diese "LOD-Spielerei" ändert nicht am LOD-Bias. Der Begriff ist imo falsch, zumindest sehr unglücklich.

Ok...der Begriff ist vielleicht wirklich nicht besondern glücklich...

Es wäre nett von dir, wenn du einen passerenden (bzw. richtigen) "Kurzbegriff" dafür nennen könntest...

[Mr. Lolman]

In der Tat ists äusserst seltsam, dass die 9800pro im Vergleich zur XT so langsam ist. Gern würd ich mal taktbereinigte Benchmarks aller R3x0 Karten sehen.

[Quasar]

LOD-abhängige Sample-Spielerei... ;)
Anisotropic Sample Optimization (ASO)

[ShadowXX]

LOD-abhängige Sample-Spielerei... ;)
Anisotropic Sample Optimization (ASO)

Hmm...ASO ist zwar schön kurz, hört sich aber viel zu positiv an...nehmen wir also lieber LOD-abhängige Sample-Spielerei...

[mapel110]

http://www.xbitlabs.com/articles/video/display/counterstrike-source.html
hier fällt der Unterschied teilweise nicht so gross aus zwischen den Top-modellen.

[Quasar]

Etwas merkwürdig ist der erste Vergleich:
http://www.xbitlabs.com/images/video/counterstrike-source/stress_full_1600_pure.gif
2,5% für die ultra ggü. der GT - bei 14,2% höherer Füllrate (und allem, was da noch mit dranhängt). :|

Schwach und merkwürdig finde ich auch die schrecklichen Texturfilter bei der GFFX in "pure" Modus.

Und was macht die R9800p mit 256MB trotz deutlich niedrigerer Taktraten soviel schneller, als die 9800XT???

CS:S wird mir immer suspekter.
Gabe "Technology Partner" Newell ahoi!

[Black-Scorpion]

Und was macht die R9800p mit 256MB trotz deutlich niedrigerer Taktraten soviel schneller, als die 9800XT???
Meinst du das auf deinem Link bezogen?
Wenn ja, ist doch die 9800XT schneller.
Da hast du wohl die 9600XT mit der 9800XT verwechselt.

[dildo4u]

Meinst du das auf deinem Link bezogen?
Wenn ja, ist doch die 9800XT schneller.
Da hast du wohl die 9600XT mit der 9800XT verwechselt.

http://www.xbitlabs.com/images/video/counterstrike-source/stress_full_1280_candy.gif

[Quasar]

Meinst du das auf deinem Link bezogen?
Wenn ja, ist doch die 9800XT schneller.
Da hast du wohl die 9600XT mit der 9800XT verwechselt.
Nee, der Link bezog sich auf die GF.

Den Link zur 9800p vs. XT hab ich mir gayspart.
Aber da isser:
http://www.xbitlabs.com/articles/video/display/counterstrike-source_7.html

[reunion]

http://www.driverheaven.net/showthread.php?p=423812#post423812

Gerade bei cstrike.de gesehen da dachte ich man könnte das ja mal posten.
Kann mir jemand dieses Ergebnis mal erklären?

Bei Doom3 gab es ja auch signifikante Anzeichen warum dort die 6800er Serie schneller ist, warum hier die X800 - nur weil HL2 von ATI gesponsert wird?

Danke, kuj0n


Bitte keinen Flamethread starten!!!

Das war einfach nicht anders zu erwarten, Doom3 wurde auf NV-Karten optimiert, HL2 eben auf ATi Karten. Alles andere als ein solches Ergenis wäre mehr als überraschend gewesen...

[reunion]

Dem stelle ich mal folgende These entgegen:

"30% performance difference ( 74fps to 52fps ) could reasonably be expected, if you are a Geforce 6800 Ultra user with at least one cell of gray matter differentiating you from a fanboy."

Alles unterhalb von 30% (Ultra vs. XT-PE) ist eigentlich ein Schlag ins Gesicht für ATis veraltete Technologie.

Es wird endlich mal zeit das wir von dieser imaginären "pro-mhz" Leistung wegkommen. Als Kunde kann es mir schlicht egal sein wie eine Graka seine Leistung erreicht. Man kauft keine mhz, man kauft rechenleistung!

[LovesuckZ]

Das war einfach nicht anders zu erwarten, Doom3 wurde auf NV-Karten optimiert, HL2 eben auf ATi Karten. Alles andere als ein solches Ergenis wäre mehr als überraschend gewesen...

Hm, keine Falschaussagen, bitte :)
Doom3 ist fuer keine Hardware optimiert. Nvidia tat ein bisschen mehr, ATi vernachlaessigte diese Engine eben.
Die Source Engine ist auch fuer keine Hardware optimiert, sondern haelt sich an die Voschriften von DX(9).
Das Nvidia unter dem VST so gut mithalten kann, liegt an der Architektur. Es ist eben nicht mehr letztes Jahr, wo DX9 = ATi - Ueberlegenheit bedeutete, sondern nur noch ein Gleichstand zwischen beiden.

[deekey777]

Bei Firing Squad gibt es einen interessanten VST-Test (http://www.firingsquad.com/hardware/half_life_2_fx/) , wo die Grafikkarten gegeneinander mit verschiedenen DX-Paths verglichen werden. Die Tester waren nicht zu faul und machten Vergleichsbilder zw. den einzelnen DX-Paths.

[Kladderadatsch]

Nee, der Link bezog sich auf die GF.

Den Link zur 9800p vs. XT hab ich mir gayspart.
Aber da isser:
http://www.xbitlabs.com/articles/video/display/counterstrike-source_7.html

warum ist die 5950 ultra schneller als die 6800?!

[deekey777]

warum ist die 5950 ultra schneller als die 6800?!

While the GeForce FX graphics cards work using DirectX 8.x render path, in “eye-candy” mode they deliver nice image quality and good performance that is inline or higher compared to ATI’s RADEON 9xxx series.

[Kladderadatsch]

achso, danke :)

[Demirug]

Bei Firing Squad gibt es einen interessanten VST-Test (http://www.firingsquad.com/hardware/half_life_2_fx/) , wo die Grafikkarten gegeneinander mit verschiedenen DX-Paths verglichen werden. Die Tester waren nicht zu faul und machten Vergleichsbilder zw. den einzelnen DX-Paths.

Interesant. Dann gibt es denn 8.2 Pfad wohl nicht mehr.

[LovesuckZ]

achso, danke :)

Mehr Speicher und kuerzere Shader.

[ironMonkey]

Bei Firing Squad gibt es einen interessanten VST-Test (http://www.firingsquad.com/hardware/half_life_2_fx/) , wo die Grafikkarten gegeneinander mit verschiedenen DX-Paths verglichen werden. Die Tester waren nicht zu faul und machten Vergleichsbilder zw. den einzelnen DX-Paths.


Veileicht kann das hier jemand erklären, bei einigen stellen sieht man ja nen unterschied bei ATI wenn man von DX 8.1 auf DX 9 wechselt, auch die Leistung bricht etwas ein, auf der NV sieht DX 9 wie DX 8.1 aus und auch die Leistung ist gleich, das bedeutet eigentlich das auf der FX Serie DX9 erst garnicht geht....................wobei das jetzt nix gegen NV sein soll, wundert mich nur etwas, auch komisch finde ich das bei 1280x1024 mit AA+AF die 6800GT komplett einbricht und "nur" noch so schnell wie eine 9800XT ist, geht der Karte der Speicher aus oder warum passiert das.....


Gruß

[MechWOLLIer]

Interesant. Dann gibt es denn 8.2 Pfad wohl nicht mehr.

Was ist denn ein 8.2 Pfad?

[Demirug]

Was ist denn ein 8.2 Pfad?

Das ist die Bezeichnung die Valve intern für einen Mixed DX8/DX9 Path verwendet hat.

In allen Fällen bei denen der 8.1 Shader (PS <= 1.4) optisch gleichwertige Ergebnisse zum DX9 Shader (PS 2.0/2.A) erzeugt hat wurde dieser benutzt. Ansonsten wurde eben der 2.0/2.A verwendet. Welcher Effekt mit welchen Shader gerendert wird war entsprechend im Sourcecode der Effekte hinterlegt. Eigentlich wurde das meiste mit den 1.X Shader gerendert. Lediglich Wasser und Glas-Effekte profitieren von 2.0 und wurden beim 8.2 Pfad entsprechend auch mit diesen 2.0/2.A Shader gerendert.

[DrumDub]

DirectX 9: mat_dxlevel 90
DirectX 8.1: mat_dxlevel 81
DirectX 8.0: mat_dxlevel 80
DirectX 7.0: mat_dxlevel 70
DirectX 6.0: mat_dxlevel 60
DirectX 5.0: mat_dxlevel 50

krass... damit kann man also die source engine noch auf ner voodoo 1/riva 128 laufen lassen... wär ja mal witzig da die performance zu messen. :freak:

[Demirug]

krass... damit kann man also die source engine noch auf ner voodoo 1/riva 128 laufen lassen... wär ja mal witzig da die performance zu messen. :freak:

Die Engine kann es nur habe ich zweifle das für den DX 5.0 Level überhaupt eine Effekt DLL vorhanden ist. Selbst beim DX 6.0 Level ist es zweifelhaft.

[Mr. Lolman]

Hm, keine Falschaussagen, bitte :)
Doom3 ist fuer keine Hardware optimiert. Nvidia tat ein bisschen mehr, ATi vernachlaessigte diese Engine eben.

Muss das schon wieder losgehen? Nur weils auf 3dC einen Artikel darüber gibt, muss das noch lang nicht korrekt sein. In dem Artikel ist mehr Spekulation als in jedem Grafikchipspreview...

[LovesuckZ]

Muss das schon wieder losgehen? Nur weils auf 3dC einen Artikel darüber gibt, muss das noch lang nicht korrekt sein.

Bis jetzt sehe ich, dass ATi mit einem Treiber mehr erreichen kann als das Shaderreplacement.
Das heißt, dass die ATi Karten nicht aufgrund der Berechnungen ausgebremst werden, sondern es sich hier um ein kombiniertes Problem auf Hard- und Software Ebene handelt.
Koenntest du meine Frage aus dem anderen Topic beantworten, ob du diesen Kampf auch gegen HL2 fuehren wuerdest, wenn die Nvidiakkarten benachteiligt werden?

[deekey777]

Veileicht kann das hier jemand erklären, bei einigen stellen sieht man ja nen unterschied bei ATI wenn man von DX 8.1 auf DX 9 wechselt, auch die Leistung bricht etwas ein, auf der NV sieht DX 9 wie DX 8.1 aus und auch die Leistung ist gleich, das bedeutet eigentlich das auf der FX Serie DX9 erst garnicht geht....................wobei das jetzt nix gegen NV sein soll, wundert mich nur etwas, auch komisch finde ich das bei 1280x1024 mit AA+AF die 6800GT komplett einbricht und "nur" noch so schnell wie eine 9800XT ist, geht der Karte der Speicher aus oder warum passiert das.....


Gruß


Vielleicht ist die Seite 3 (http://www.firingsquad.com/hardware/half_life_2_fx/page3.asp) die Antwort -> Siehe Ausschnitte mit den Wänden; vielleicht gibt es gar keine Unterschiede zw. DX8.1 und DX9.0 auf einer FX. Auch die NV40 müsste die gleiche Qualität liefern wie die 9800XT.

[aths]

Muss das schon wieder losgehen? Nur weils auf 3dC einen Artikel darüber gibt, muss das noch lang nicht korrekt sein. In dem Artikel ist mehr Spekulation als in jedem Grafikchipspreview...Schreibe einen besseren Artikel oder biete (im Thread zum bewussten Artikel) glaubwürdigere "Spekulationen" an.

Das war einfach nicht anders zu erwarten, Doom3 wurde auf NV-Karten optimiert, HL2 eben auf ATi Karten. Alles andere als ein solches Ergenis wäre mehr als überraschend gewesen...Nein. HL2 ist auf NV40 und R420 jeweils vor allem texturfüllraten-limitiert, die Radeon X800 XTPE gewinnt aufgrund ihrer Füllratenstärke und nicht, weil HL2 speziell auf Radeon-Karten optimiert sei.

[reunion]

Nein. HL2 ist auf NV40 und R420 jeweils vor allem texturfüllraten-limitiert*, die Radeon X800 XTPE gewinnt aufgrund ihrer Füllratenstärke und nicht, weil HL2 speziell auf Radeon-Karten optimiert sei.

Oh, so ein zufall das ausgerechnet die Füllrate limitiert, wo doch eine X800XT PE um 30% höher getaktet ist als eine 6800U. Da hat ATi ja wahnsinnig Glück gehabt :ulol:

[Demirug]

Oh, so ein zufall das ausgerechnet die Füllrate limitiert, wo doch eine X800XT PE um 30% höher getaktet ist als eine 6800U. Da hat ATi ja wahnsinnig Glück gehabt :ulol:

HL2 wurde primär nun mal für <= DX8 Hardware konzepiert. Da ist nicht viel mit Rechenlastigen shadern.

[Mr. Lolman]

Schreibe einen besseren Artikel oder biete (im Thread zum bewussten Artikel) glaubwürdigere "Spekulationen" an.


Das könnt ich eher dir vorschlagen. Ich schreibe keine Artikel fürs 3DC. Und wenn im dem Artikel steht, das Doom3 eh schon optimal für ATi Karten optimiert wurde, und dass ATi Karten es einfach nicht besser können, während NV ein offenes Ohr für die Wünsche des JC gehabt hat, und dementsprechend ihre HW daraufhin entwickelt hat, glaub ich das maximal so lang, wie es dauert, dass ich merke, dass mit einer 3 zeiligen Codeänderung (!= Humus letzter Patch) ATi Karten Performance gewinnen, während NV Karten Leistung verlieren, während das Spiel gleichzeitig immernoch genauso gut aussieht.

Dabei nehm ich mir nicht das Recht raus, einen besseren Artikel schreiben zu können. Wenn ein Hochschulprofessor meint 2+2=5, dann kann ich behaupten, dass das falsch ist, ohne ihm das Wasser bei seinen Qualifikationen reichen zu können.

Nochmal, man muss nicht unbedingt dein technisches Wissen vorweisen können, um zu sehen, dass in diesem Artikel div. Scheinfakten sich zu einer NV Lobeshymne zusammensetzen. Vielleicht ist es eher sogar hinderlich, soviel zu wissen, wie sich schon bei der AF Diskussion herausgestellt hat. Nach technischen Gesichtspunkten müsste auch eine Schallplatte grauenhaft klingen. Also echt zum :kotz: nicht nur verrauscht usw... Komisch dass immernoch soviel Künstler aufs Venyl schwören. Was das jetzt mit dem AF zu tun hat?

Mit dem ganzen Wissen, über LOD Optimierungen, Einsparungen in der Genauigkeit und sonstigen Filtertricksereien, kann man nurmehr zu dem Schluss kommen das ATi AF scheisse ist. Das war ja bei der 8500 noch schlimmer. Da war das AF so sehr optimiert, dass es manchmal sogar flotter war als normales trilineares Filtering. Das kann ja nur mehr scheisse aussehen. Gut in den meisten Fällen wars wohl auch so. (Flimmrig und sichtbare Mipband) In manchen Spielen war es jedoch sehr willkommen. (Mafia hab ich mit 1280x960 und 8xAF auf meiner Radeon gespielt, und ich wette das war flotter als eine GF3Ti500 in der selben Auflösung mit unoptimierten 2xAF. Gut flimmriger wars auch, aber auch gleichzeitig schärfer.
AF, ob optimiert oder nicht, find ich erst ab 4x interessant, da erst ab dieser Stufe unliebsame Mipmaps weitgenug weggeschoben sind)

Was hat das jetzt mit dem Doom3 Artikel aufsich? Genau wie beim AF magst du über technische Hintergründe (deutlich) besser informiert sein, als der Durchschnitts 3dc user. Du weisst wie Ultra Shadow funktioniert, kennst den Aufbau der Grafikchips, weisst auch dass sich ATi hinsichtlich Z/Stencil Leistung nicht viel gesh1c0rt hat. Und deswegen ists für dich nur naheliegend, warum D3 auf NV Karten so gut funktioniert. Eigentlich müssts ja sogar noch besser funktionieren, denn nach nem neuen ATi Treiber und dem Humus Patch, der auch bei App AF 6-8% bringt. hat sich der NV Vorsprung von 30 auf ~15% verkürzt (lt. Voodoojack), was dann aber in Anbetracht der ganzen hardwarebedingten NV Optimierungen, und der ganzen ATi Nichtoptimierungen fast schon wieder ein bisschen wenig ist. Stellt man sich jetzt die Frage, wie es ausgesehen hätte, wenn NUR die Humustechnik verwendet worden wäre, und wenn JC aufs App AF verzichtet hätte, kommt man zu dem Schluss, dass der Vorspung nur noch weiter schmelzen kann. (Ich glaub sogar soweit, dass letzenendes ATi vorne ist)

Hat das noch irgendwas mit einer HW Anpassung auf die Engine zu tun? Oder ists dann etwa deswegen gleich ne andere Engine, nur weil sie anders rechnet, aber trotzdem zum gleichen Ergebnis kommt? Meine Meinung ist einfach, dass man aufgrund der neugewonnen Tatsachen (ja ATi Karten könnten noch schneller, nur "durften" sie keine passenden Abkürzungen nehmen, obwohl das Ziel das Gleiche ist) nicht einfach behaupten kann, dass optimal programmiert wurde - meinetwegen solls auch eine Humuspatch für NV Karten geben, nur glaub ich, dass Doom3 zumindest auf NV KArten schon optimal rennt, wenn schon nicht auf ATi HW, denn wär das nicht so, dann hätte JC wirklich ein bisschen gepennt, da man von ihm schöne, hochperformante Engines erwartet. Ressourcenverschwendete 3D Grafik kriegen auch ein paar Fans hin (vgl. Tenebrae) - und dass NV den Vorteil der besseren HW Unterstützung hat.

Nur darum geht es mir, nämlich zu zeigen, dass Doom auch so programmiert hätte werden können, dass es genauso aussieht, und trotzdem auf beiden Karten zumindest gleichschnell läuft.
Vielleicht sollte man diese Diskussion in einem neuen Thread fortführen, damit ich nicht wieder den schwarzen Threadshredderpeter zugeschoben bekomme.

[aths]

Das könnt ich eher dir vorschlagen. Ich schreibe keine Artikel fürs 3DC.Leo veröffentlicht auch von "Gast-Autoren", siehe Demirug oder zeckensack.

Und wenn im dem Artikel steht, das Doom3 eh schon optimal für ATi Karten optimiert wurde, und dass ATi Karten es einfach nicht besser können, während NV ein offenes Ohr für die Wünsche des JC gehabt hat, und dementsprechend ihre HW daraufhin entwickelt hat, glaub ich das maximal so lang, wie es dauert, dass ich merke, dass mit einer 3 zeiligen Codeänderung (!= Humus letzter Patch) ATi Karten Performance gewinnen, während NV Karten Leistung verlieren, während das Spiel gleichzeitig immernoch genauso gut aussieht. Weshalb schneidet die Source-Engine bei der X800 besser ab? Hat ATI Valve bestochen? Oder taugt der NV40 nichts? Oder liegt es einfach daran, dass die Source-Engine bestimmte Anforderungen an die HW stellt und die X800 hier einfach mehr bietet als NV40?

Nochmal, man muss nicht unbedingt dein technisches Wissen vorweisen können, um zu sehen, dass in diesem Artikel div. Scheinfakten sich zu einer NV Lobeshymne zusammensetzen.Starker Tobak. Doch ist es nicht ganz objektiv so, dass der NV40 technisch deutlich weiter ist als R420, so dass sie dafür dann auch "Lob" ernten können?

denn nach nem neuen ATi Treiber und dem Humus Patch, der auch bei App AF 6-8% bringt. hat sich der NV Vorsprung von 30 auf ~15% verkürzt (lt. Voodoojack), was dann aber in Anbetracht der ganzen hardwarebedingten NV Optimierungen, und der ganzen ATi Nichtoptimierungen fast schon wieder ein bisschen wenig ist.Angesichts des Taktvorteils für die Radeon noch immer eine Menge. Von 25% (so stehts im Artikel) auf soweit ich sehe reichlich 15%. Taktnormalisiert bleibt eine große Lücke (da die Unterschiede im Takt recht groß sind.)

Wenn HL2 erst mal in den Regalen steht und sich zeigt, dass auch die X800-Ingame-Performance signifikant über der der 6800 liegt, rechtfertigt das natürlich einen Artikel.

Stellt man sich jetzt die Frage, wie es ausgesehen hätte, wenn NUR die Humustechnik verwendet worden wäre, und wenn JC aufs App AF verzichtet hätte, kommt man zu dem Schluss, dass der Vorspung nur noch weiter schmelzen kann. (Ich glaub sogar soweit, dass letzenendes ATi vorne ist) Das glaube ich nicht. Außerdem ist die "Humus-Technik" weniger flexibel. Und widerspricht den Optimierungsregeln -- ein bilineares Textursample zu erstellen sollte einen Takt dauern, den POW-Befehl kann man mit drei Takten veranschlagen. Man kann JC vorwerfen, nicht mal geguckt zu haben, ob ein Verstoß gegen die Optimierungsregeln, und unter Aufgabe der bisherigen Flexibilität, zu einigen % Mehrleistung auf der Radeon führen würde. Bei einem starken Dev-Support seitens ATI hätte er da vielleicht einen Tipp kriegen können. Ich nehme aber an, dass er dieses Sampling bewusst vornahm, weil man eben beliebige Wertefolgen in die Lookup-Textur stellen kann.

Zum Rest: Du bringst Vermutungen bzw. Spekulationen. Der Doom3-Artikel erscheint mir da doch plausibler. Denn er basiert auf Technik-Fakten, jedenfalls soweit sie uns bekannt sind. Und ja, natürlich hätte Doom3 so programmiert werden können dass es auf beiden Karten gleich schnell läuft. Dazu hätte aber der NV40 (vom jetzigen Niveau) her ausgebremst werden müssen. Was sagst du dazu, dass nach bisherigen Erkenntnissen Source auch nicht gleich schnell auf beiden Karten läuft?

[LovesuckZ]

Nur darum geht es mir, nämlich zu zeigen, dass Doom auch so programmiert hätte werden können, dass es genauso aussieht, und trotzdem auf beiden Karten zumindest gleichschnell läuft.


Dann muesste man die Nvidiakkarten um ca. 45% ausbremsen, um den technologischen Rueckstand von ATi ungehindert werden lassen zu koennen.
Du willst also, dass Nvidiauser der Transistorensparlaune von ATi zum Opfer fallen, weil der ATi user nicht seinen Grafikkartenhersteller fuer das Versagen verantwortlich machen kann, nein will?
Kannst du mir die Frage beantworten, ob du diese Kraft auch gegen HL2 aufbringen werdest, wenn es nicht fuer Nvidia optimiert wurde?

[seahawk]

Ein sehr schwacher Post Mr. Lolmann. Du bist hiermit auf meine persönliche ATI-Fanboyliste aufgenommen.

Wie kann man sagen JC, hätte so optimieren müssen, dass Doom3 auf Radeons und GeForce Karten gleichschnell läuft, da bedeutet ja erstmal, er hätte die NVs künstlich einbremsen müssen.

Darf ich jetzt behaupten, dass Valve auch schlecht optimiert hat, weil sonst die HL2- Engine auch auf GeForce und Radeon gleich schnell sein müßte ??

[Mr. Lolman]

Platzhalter für Antwort auf aths Post (kommt leider erst mitten in der Nacht)

[Mr. Lolman]

Ein sehr schwacher Post Mr. Lolmann. Du bist hiermit auf meine persönliche ATI-Fanboyliste aufgenommen.


Danke, man tut was man kann ;)


Wie kann man sagen JC, hätte so optimieren müssen, dass Doom3 auf Radeons und GeForce Karten gleichschnell läuft, da bedeutet ja erstmal, er hätte die NVs künstlich einbremsen müssen.

Wenn dem Standpunkt aus, kann man auch behaupten, dass momentan Ati Karten künstlich ausgebremst werden


Darf ich jetzt behaupten, dass Valve auch schlecht optimiert hat, weil sonst die HL2- Engine auch auf GeForce und Radeon gleich schnell sein müßte ??

Ja sicher darfst du das. Sehen wir zu, ob wirs herausfinden, obs auch wirklich der Fall ist...



Ausführlichere Antwort kommt frühestens um 0:00

[Mr. Lolman]

Ausführlichere Antwort kommt frühestens um 0:00

Eher sogar später, denn ich hab grad die Rohfassung meines extrem langen aths Antwortposts geshreddert, und bin jetzt mal weg für ein paar stunden...

kthxsry ;(

[Quasar]

Lolman,

du schreibst, JC hätte, könnte, sollte, dürfte und müsste. Fakt ist aber, er hat diesen Weg gewählt - vielleicht hatte er dabei sogar noch andere Gründe, als den grünen Ferrari vor seiner Haustür.

Interessant ist hierbei jedoch, daß quasi schon vor bekanntwerden der "finalen" Leistungsverhältnisse JC von ziemlich vielen Leuten mehr oder weniger als "gekauft" eingestuft wurde.
Die Frage sollte lauten: Warum?
Eine mögliche Erklärung: Diejenigen die das taten, waren es gewohnt, ihren Favoriten die längeren Benchmarkbalken ergattern zu sehen - fragten aber nicht großartig weiter, warum das so war. "ATi ruled halt einfach".

Wenn man sich jedoch, was viele ja nicht gern tun (zumindest gewinnt man in etlichen Threads hier den Eindruck), zumindest oberflächlich mit der zugrundeliegenden Technik auseinandergesetzt hätte, wäre es möglich gewesen, von den Doom3-Ergebnissen nicht so furchtbar überrascht gewesen zu sein.

Erinnern wir uns - die letzten beiden Jahre lag ATi performancetechnisch durchaus deutlich in Front - warum das so war, wurde schon etliche Male erklärt und könnte, wenn man wollte, mit ebensolchen Mitteln nochmals wiederholt werden, wie sie jetzt diejenigen benutzen, die nV "beschuldigen", ihre Hardware nur auf Doom3 optimiert zu haben.*
Ich denke jedoch, daß ist etwas zu kurz gedacht - es gab wohl etliche Gründe, warum ein nV3x nur wenig Ähnlichkeit zum R3xx hatte.
Hinzu kam für nV das Problem, daß DX9 endgültig wohl nicht so aussah, wie man das beim Design des nV3x angenommen hatte (ich will jetzt nicht schon wieder die Preisstreitereien um die XBox mit M$ als verschwörungstheoretischen Grund anführen), auch der nV35 konnte diese Manko nicht wirklich ausgleichen.

Beim nV40 gibt es diese Probleme gegenüber dem R420 kaum noch oder nur in stark verminderter Form - hinzu kommt, daß diesmal dieselbe Anzahl an Pixelprozessoren antritt.
Hier konnte sich ATi im Falle der XTPE durch puren Takt und im Falle der Pro nur noch durch Treibereien absetzen. Eliminiert man diese (läßt beide Karten ohne Optimierung oder mit etwa demselben Grad an Optimierung laufen), so ergibt sich, daß Takt für Takt, MegaPixel für MegaPixel die Karten sich gar nicht mehr so viel nehmen - mal ist die eine schneller, mal die andere - ganz "normal" eigentlich.

Wenn ich nun aber Doom3 heranziehe und einen fiktiven Wert von 50% der Rechenzeit den Schattenberechnungen zuordne, so habe ich auf einmal auf Seiten der GF einen sehr deutlichen Vorteil, was Cullraten- und Z-Fillrateleistung angeht.
5700 vs. 8400 (ich hoffe, ich habe den 50% Z-Anteil jetzt richtig reingerechnet) Mega-Irgendwasse zwischen X800 Pro und GF 6800GT.

Das ist in etwa die Größenordnung, als Vergleiche man sonst die X800 XTPE (8320) mit der X800 Pro - und, oh wunder, die GF6800 GT erreicht sogar in etwa das Performancelevel einer X800 XTPE.

Was in aller Welt ist daran noch verwunderlich oder außergewöhnlich? In UT2003 hatte die FX5800u auch kaum Probleme, ihre Füllrate auf den Boden zu bringen, weil hier schlicht ihre Stärken gefordert waren - im Gegensatz bsw. zu FC.


*Sieh's mal so: ATi sparte an Präzision und Features, um einen zweiten Pixelprozessor in die R300 einzubauen. nVidia sparte an einem (kompletten!) zweiten Pixelprozessor, um Features einzubauen und konnte innerhalb des Transistorbudgets nur noch DoubleZ-ROPs verbauen.

[tokugawa]

Das könnt ich eher dir vorschlagen. Ich schreibe keine Artikel fürs 3DC. Und wenn im dem Artikel steht, das Doom3 eh schon optimal für ATi Karten optimiert wurde, und dass ATi Karten es einfach nicht besser können, während NV ein offenes Ohr für die Wünsche des JC gehabt hat, und dementsprechend ihre HW daraufhin entwickelt hat, glaub ich das maximal so lang, wie es dauert, dass ich merke, dass mit einer 3 zeiligen Codeänderung (!= Humus letzter Patch) ATi Karten Performance gewinnen, während NV Karten Leistung verlieren, während das Spiel gleichzeitig immernoch genauso gut aussieht.

[... viel Schmafu ... ]

Hat das noch irgendwas mit einer HW Anpassung auf die Engine zu tun? Oder ists dann etwa deswegen gleich ne andere Engine, nur weil sie anders rechnet, aber trotzdem zum gleichen Ergebnis kommt? Meine Meinung ist einfach, dass man aufgrund der neugewonnen Tatsachen (ja ATi Karten könnten noch schneller, nur "durften" sie keine passenden Abkürzungen nehmen, obwohl das Ziel das Gleiche ist) nicht einfach behaupten kann, dass optimal programmiert wurde - meinetwegen solls auch eine Humuspatch für NV Karten geben, nur glaub ich, dass Doom3 zumindest auf NV KArten schon optimal rennt, wenn schon nicht auf ATi HW, denn wär das nicht so, dann hätte JC wirklich ein bisschen gepennt, da man von ihm schöne, hochperformante Engines erwartet. Ressourcenverschwendete 3D Grafik kriegen auch ein paar Fans hin (vgl. Tenebrae) - und dass NV den Vorteil der besseren HW Unterstützung hat.


Hast du schon mal ein Spiel entwickelt?

Es ist IMO schon ein starkes Stück von dir, von JC zu verlangen, dass er eine unübliche Code-Änderung macht, die wohl nur ATI-Experten selbst wissen konnten (Humus ist ja auch einer, der viel mit ATI Hardware gemacht hat).

Diesen Tweak halte ich für einen besonderen Kniff, über den man bescheid wissen muß. Steht es in einem ATI Paper? Bietet ATI einen GPU Programming Guide, so steht, dass genau sowas Speed bringt? Du kannst ruhig einmal suchen: http://www.ati.com/developer/.

Auf der anderen Seite bietet NVIDIA doch duzende Papers und Bücher an (GPU Programming Guide), die viele solcher Tipps enthalten. Von dieser Warte betrachtet hat in diesem Zusammenhang wohl NVIDIA einfach den besseren Developer Support... was im Falle ID auch nicht all zu verwunderlich ist, da NVIDIA ja speziell ID versorgt hat.

Wenn JC diese Optimierung für ATI Karten nicht gleich eingebaut hat, ist das Teilverschulden von ATI. Denn ATI hätte genau dieses Faktum auch in ihrem Developer Papers erwähnen können.

"Undokumentierte" Tweaks nicht zu verwenden ist jetzt nicht so ganz das, was man einem Entwickler vorwerfen kann. Nicht mal JC.

PS: es gibt nicht immer _einen_ Weg für etwas. Das dürftest du schon bemerkt haben. Warum er sich so entschieden hat, sollte man aber frei von irgendwelchen Verschwörungstheorien sehen. Entwickel selber mal ein Spiel. Dann kommst du auf vieles drauf, was du vorher nicht mal ansatzweise verstanden hast (und damit mein ich nicht mal das programmiertechnische selbst, sondern eher gewisse Entscheidungen).

[winter]

*Ich darf doch nochmal zusammenfassen*

ATI und Nvidia bewegten sich mit dieser Generation aus Technischer sicht in verschiedene Richtungen. Verglichen mit dem Prozessormarkt ist dabei ATI Intel und Nvidia AMD. Nvidia versucht pro Takt möglichst viel durchzurechnen und ATI versucht möglichst viele Takte pro Zeit durchzubringen, so in etwa ist das ganze. Natürlich sind beide Aussagen nicht ganz korrekt, gehen aber in die richtige Richtung. Und da beide etwa in gleichem Maße in ihre Richtungen gegangen sind, kommt dass am Ende auf etwa die selbe Durchschnittsleistung raus. Ich sage Durchschnittsleistung, denn einzelne Titel können sehr wohl von der einen oder der anderen Richtung profitieren, da mehr Takt mehr Füllrate bedeutet und mehr ProMHz Leistung zu deren Einspaarung beitragen kann (Wohl auch nicht ganz korrekt diese Aussage, bin eben doch nur ein Laie).

[Irrglaube *Wenn ich den Artikel richtig verstanden habe, gewinnt Nvidia in Doom³ dadurch, dass sie wegen des Spielprinzips (enge, verwinkelte Gänge) die Zahl der zu rendernden Pixel gut einspaaren können. Dabei kann ATI den Füllratenvorteil nicht ausspielen, da sie aufgrund des Technikrückstandes schlicht viel mehr Pixel rendern müssen die am Ende nicht zu sehen sind.*]

[Edit: Richtig]
ATI hat bei Doom³ also den Nachteil, Lichtberechnungen durchführen zu müssen, welche für die Szene später nicht relevant sind.

[Irrglaube *Dass dies bei HL² anders aussehen würde, war klar, denn dargestellt werden schlicht weitläufigere Areale mit wenig Pixel-Overhead, folglich sind sie ehr Füllratenlimitiert.*]


[Denkfehler: HL² nicht stark Füllratenlimitiert, doch Valve nutzt anscheinend keine Stencilschatten (Thx @ Coda), also kein Nachteil für ATI, Taktvorteil kann genutzt werden.]


Die Benchmarks von Driverheaven hier sind zwar schlicht unrealistisch und teilweise auch unfair (Das ungleich langsamere 8x(4xMS+2xSS) AA (Kostet auch 50% Füllrate)) gegen der hässlichere (man muss es wirklich so ausdrücken) 6x(MS) zu Benchen ist schlicht unfair), allerdings auch die wesentlich wahrscheinlicheren Resultate von XbitLabs.com bestätigen der X800XT-PE den "Sieg" in HL². Allerdings ist dort zu sehen, dass die X800pro auch hier nicht mithalten kann, da ihre Füllrate aufgrund der nur 12 vorhandenen Pipelines nicht so hoch ist (Ich weiß, das hängt heute nurnoch indirekt voneinander ab, aber trotzdem). Die XT-PE dagegen zieht problemlos davon.

[Wahrheit, Doom³ IST Füllratenlimitiert *Hypothese: Wenn Doom³ stark füllratenlimitiert wäre,*
Irrglaube, denn Nachteile seitens ATI bei Schattenberechnung *wäre die X800XT-PE leicht vorne oder zumindest gleich auf mit der 6800Ultra, und die X800Pro läge gegenüber der 6800GT noch weiter zurück, da diese dann in beiden Kategorien nicht mehr mit der Spitze mithalten könnte.*]

So sieht es aus, soweit sich die Diskussion mir gegenüber darstellt.

[Post jetzt inhaltlich einigermaßen richtiggestellt.]

[aths]

Wenn ich den Artikel richtig verstanden habe, gewinnt Nvidia in Doom³ dadurch, dass sie wegen des Spielprinzips (enge, verwinkelte Gänge) die Zahl der zu rendernden Pixel gut einspaaren können. Dabei kann ATI den Füllratenvorteil nicht ausspielen, da sie aufgrund des Technikrückstandes schlicht viel mehr Pixel rendern müssen die am Ende nicht zu sehen sind.Nein. Einige Pixel müssen zwar (aber auf beiden Architekturen!) "umsonst" mitgerendert werden (sind also nicht sichtbar.) Es geht im Artikel nur darum, wie schnell Pixel beim Schattenberechnungs-Pass weggeworfen werden können. Der Z/Stencil-Test geht nämlich sehr schnell, aber viele Pixel könnte man von vornherein gleich "wegwerfen", da man mit Hilfe bestimmter Techniken ein Test-Ergebnis schon vorher haben kann (ansonsten gehen sie halt in den Z/Stencil-Test.) Ist der Z-Buffer erst mal fertig und es geht in den rechenaufwändigen Color-Pass, werden (soweit wie möglich) auf beiden Architekturen alle Pixel rausgeworfen von denen bekannt ist, dass man sie (aufgrund von Verdeckung) ohnehin nicht sieht.

HL2 nutzt Shader-Techniken, die auf viele Texturen setzen (da gabs auch irgendwo Paper zu) und vergleichsweise wenig rechnen. Letztlich warten die arithmetischen Recheneinheiten auf die TMUs, damit diese neue Daten (Texturwerte) liefern. Da nützt es dem NV40 nicht, dass er pro Takt eine höhere arithmetische Leistung vorweisen kann. R420 kann hingegen die Taktraten-Vorteile ausspielen, und gewinnt dank höherer Textursample-Leistung.

[winter]

Ok, danke für die Richtigstellung. Passt allerdings immernoch in etwa auf die Gesammtaussage meines Beitrags X-D.
Allerdings stimmt dann auch meine Aussage über HL² nicht mehr.
Richtiger wäre es also zu sagen: Bei HL² spielen Schatten einfach nicht eine so große Rolle, deswegen hält sich der Mehraufwand bei deren Berechnung für ATI in Grenzen, so dass die Füllrate zum Tragen kommt.

Grundaussage immernoch: Intelligentere Technik gegen höhere Rohleistung bei Standardprozedere

[Coda]

Nur darum geht es mir, nämlich zu zeigen, dass Doom auch so programmiert hätte werden können, dass es genauso aussieht, und trotzdem auf beiden Karten zumindest gleichschnell läuft.
Bist du so Begriffsstutzig oder tust du nur so?
Doom 3 macht erstmal nen Z-Pass, da hat NV40 effektiv erstmal 32 Pipelines, ATi "nur" 16, beim Stencil isses das gleiche.
Wie willst du das also anstellen?

[LovesuckZ]

Hypothese: Wenn Doom³ stark füllratenlimitiert wäre, wäre die X800XT-PE leicht vorne oder zumindest gleich auf mit der 6800Ultra, und die X800Pro läge gegenüber der 6800GT noch weiter zurück, da diese dann in beiden Kategorien nicht mehr mit der Spitze mithalten könnte.


Doom3 ist "stark füllratenlimitiert", sonst muesste die X800pro deutlicher an der XTPE sein.
Man sollte aber immer auch bedenken, dass ATi unter OpenGL keine Ueberlegenheit bei den AF Optimierungen hat und so, gegenueber Nvidia, eben auch keine Fillrate einsparen koennen.

[winter]

Coda: ICH bin ein bisschen Begriffsstutzig :ugly:
Wofür MUSS Doom³ denn zuerst diesen Z-Pass ausführen, wie hängt denn das mit dem Spiel-Szenario zusammen dass man es nicht anders lösen kann? Steht vielleicht in dem Artikel, aber dann hab ichs entweder überlesen oder mangels Fachwissen nicht verstanden :ugly:

[winter]

LovesuckZ:

Das Doom³ auch ein Füllratenfresser ist, war mir klar, bei der Texturengröße und Menge, meine Aussage bezieht sich auch mehr darauf, dass HL² wahrscheinlich noch mehr Füllrate saugt, was den krassen Vorsprung von ATI dort erklärt (AF-Optimierungen alleine können das wohl nicht schaffen.)

[Coda]

Wofür MUSS Doom³ denn zuerst diesen Z-Pass ausführen, wie hängt denn das mit dem Spiel-Szenario zusammen dass man es nicht anders lösen kann? Steht vielleicht in dem Artikel, aber dann hab ichs entweder überlesen oder mangels Fachwissen nicht verstanden
Weil man dadurch auch auf ATi Füllrate spart. Allerdings nicht soviel weil Hier-Z bei ATi nicht mit allen Z-Vergleichen funktioniert

Das Doom³ auch ein Füllratenfresser ist, war mir klar, bei der Texturengröße und Menge, meine Aussage bezieht sich auch mehr darauf, dass HL² wahrscheinlich noch mehr Füllrate saugt, was den krassen Vorsprung von ATI dort erklärt (AF-Optimierungen alleine können das wohl nicht schaffen.)
HL braucht eigentlich weniger Füllrate, aber keine Stencilfüllrate. Da hat ATi keinen Nachteil und der Taktvorteil kommt voll zur Geltung.

[Quasar]

Doom3 ist "stark füllratenlimitiert", sonst muesste die X800pro deutlicher an der XTPE sein.
Wieso sollte Doom3 nicht "stark füllratenlimitiert" sein? Ob nun Z-Cull oder Pixel- oder Texelfillrate ist dabei doch erstmal sekundär - es wird wenig gerechnet.

[...] dass ATi unter OpenGL keine Ueberlegenheit bei den AF Optimierungen hat [...]
Oh, doch....

[LovesuckZ]

Oh, doch....

Auch Lust uns das zu erzaehlen? :)

[Kant]

Coda: ICH bin ein bisschen Begriffsstutzig :ugly:
Wofür MUSS Doom³ denn zuerst diesen Z-Pass ausführen, wie hängt denn das mit dem Spiel-Szenario zusammen dass man es nicht anders lösen kann? Steht vielleicht in dem Artikel, aber dann hab ichs entweder überlesen oder mangels Fachwissen nicht verstanden :ugly:

Es ist ZWINGEND wegen der Art der Schattenberechnung erforderlich. Das verwerfen von teuren Lichtberechnungen für nicht sichtbare (weil letzlich verdeckte) Flächen ist nur ein angenehmer "Nebeneffekt".

[winter]

@ coda:
Thx, Also [*weniger* <-- Schwachwitz: KEINE] StencilFüllrate für Schattenberechnungen pro Pixel, dann is klar wo der vorteil von ATI hierbei liegt

@ Quasar:
Is jetzt Klargestellt, ich korrigiere mal den Post oben.

@ Kant:
Danke für die Ergänzung

[Coda]

Thx, Also weniger StencilFüllrate für Schattenberechnungen pro Pixel, dann is klar wo der vorteil von ATI hierbei liegt
?. HL2 benützt gar keine Stencilschatten.

[winter]

Ok, wusst ich ned, hätt ja sein können, dann eben GARKEIN Verbrauch von Stencilfüllrate, noch größerer Vorteil von ATI in HL²


Soo, meine Zusammenfassung auf Seite 4 is jetzt inhaltlich in etwa auf der Höhe, wen's interessiert, einfach eine Seite zurück und durchlesen.

[Kant]

[Edit: Richtig]
ATI hat bei Doom³ also den Nachteil, Lichtberechnungen durchführen zu müssen, welche für die Szene später nicht relevant sind.

Nein, glaube ich nicht. Die Anzahl der berechneten "Licht"-Pixel sollte bei beiden gleich sein.
IMHO liegt der Nachteil der Rxxx darin, das Hyperz beim Schatten-Volume Pass nicht richtig greift, und damit "unnötige" Pixel zT nicht so effizient verworfen werden können. Early-Z(NV) hingegen sollte dieses Problem nicht haben.

[deekey777]

Auch Lust uns das zu erzaehlen? :)

Ich lieg bestimmt falsch:
Ab cat. 3.5 soll eine stärkere AF-Optimierung unter OpenGL hinzugekommen sein.

[winter]

Kant: Ich zähle Schattenberechnungen zu den Lichtberechnungen, denn ohne Licht, kein Schatten (Schatten ungleich dunkelheit :ugly:) und wenn HyperZ nicht greift muss ja zwangsläufig nochmal der von Aths genannte z/stencil-test das das aktuelle Pixel überprüfen. Da HyperZ von ATI ja laut deiner Aussage nicht richtig greift, muss der Test noch durchgeführt werden und der gehöhrt zu den Schattenberechnungen, welche ich zu den Lichtberechnungen zähle.

[tokugawa]

Coda: ICH bin ein bisschen Begriffsstutzig :ugly:
Wofür MUSS Doom³ denn zuerst diesen Z-Pass ausführen, wie hängt denn das mit dem Spiel-Szenario zusammen dass man es nicht anders lösen kann? Steht vielleicht in dem Artikel, aber dann hab ichs entweder überlesen oder mangels Fachwissen nicht verstanden :ugly:

Suche in Google unter "Shadow Volume Algorithm".

Aber dir zuliebe hab ich einige nette Links:

http://developer.nvidia.com/object/fast_shadow_volumes.html

http://www.cg.tuwien.ac.at/courses/Realtime/slides/09shadows_rtr2003.pdf (auf den Folien über "Shadow Volumes")

Wenn du verstanden hast, wie dieser Algorithmus die Schatten berechnet (und darstellt vor allem), dann ist es klar, wieso man einen Pass mit Z-only ausführen muß (der Begriff "Z-Pass" ist zwar korrekt, aber er ist mit dem anderen ZPass (dem Gegenteil von ZFail) verwechselbar...).

Der Algorithmus erfordert es einfach. Dies ist auch einer der Beispiele, wo man nicht einfach sagen kann "die API macht einen Effekt", sondern das ist ein Algorithmus, der sich aus den Möglichkeiten einer API zusammensetzt. Viel zu oft wird APIs eine Grafiktechnik zugeschrieben, wenn es eigentlich die Entwickler sind, die eine Technik umsetzen (und die meistens prinzipiell API-unabhängig ist).

[tokugawa]

Kant: Ich zähle Schattenberechnungen zu den Lichtberechnungen, denn ohne Licht, kein Schatten (Schatten ungleich dunkelheit :ugly:) und wenn HyperZ nicht greift muss ja zwangsläufig nochmal der von Aths genannte z/stencil-test das das aktuelle Pixel überprüfen. Da HyperZ von ATI ja laut deiner Aussage nicht richtig greift, muss der Test noch durchgeführt werden und der gehöhrt zu den Schattenberechnungen, welche ich zu den Lichtberechnungen zähle.


Computergrafisch gesehen sind Schattenberechnung und Lichtberechnung nicht dasselbe; zumindest mit der derzeitigen Rendertechnik (bei Raytracing wär das wohl anders):

Lichtberechnung = Berechnung eines einzelnen belichteten Pixels anhand eines Lightingmodells. Ob der Pixel bzw das Fragment im Schatten liegt oder nicht, hat nichts mit der Lichtberechnung zu tun - die Lichtberechnung wird auf jeden Fall durchgeführt. Besteht im Prinzip darauf, den Lichtvektor und den Normalvektor mit Hilfe einer passenden Formel zu verknüpfen (Lambiert'sche Formel, Phong Lighting, sind einige Arten davon). Früher, vor Per-Pixel lighting, wurde diese Berechnung auch nur an den Dreiecks-Eckpunkten (Vertizes) durchgeführt, und dazwischen dann nur farbinterpoliert.

Schattenberechnung = bei den exakten "Full Scene" Schattenalgorithmen (also Shadow Mapping und Shadow Volumes) ist es im Prinzip eine Art Occlusion-Testing-Algorithmus. Also eine Technik, um zu testen, ob eine Stelle der Szene bedeckt ist (relativ zur LIchtquelle) oder nicht. Schattenberechnung ist nur insofern "Lichtberechnung", als dass das Ergebnis pro Pixel lautet "ist im Licht" oder "ist nicht im Licht" (bei Soft-Shadow Algorithmen halt "ist wieviel im Licht"). Aber die Beleuchtungsberechnung ist das nicht.

Zusammenhang besteht nur insofern, als "occludete" Objekte/Fragmente/Pixel (also Shadow Receivers) abgedunkelt werden. Aber das geschieht oft im Nachhinein, nachdem der Pixel beleuchtet wurde (also die Lichtberechnung des Lichtmodells durchgeführt wurde), bzw in einem Pass mittels Blending.

[MadManniMan]

2 Sachen:

A) An die Coder

Kann mir als (lange) nicht (mehr) Progger jemand erklären, was Humus beim Patch geändert hat und inwiefern der Originalshader flexibler war?


B) @Lolman

Ist es für dich kein Argument, ein einheitliches Berechnungsmodell für alls ARB2-fähigen Chips gestellt haben zu wollen?

[Quasar]

Soweit ich es als ebenfalls nicht Progger verstanden habe, kannst du mit einer Texture quasi beliebige Werte darin abspeichern, die nichts, aber auch gar nichts miteinander zu tun haben - so zum Beispiel höchst unterschiedliche Reflexionseigenschaften von Materialien.
Mit einer Rechnung kannst du "nur" einer Funktion folgen und wenn bsw. die Reflexionseigenschaften von Alu anders sind, als die von Holz, brauchst du dafür eine neue Funktion, sprich, einen neuen Shader.

Sieht man IMO gut an HL2 und FC, die zigtausend Shader nutzen - nach eben diesem Prinzip.

(Feel free to ignore this post, if it's complete BS)

[MadManniMan]

(Feel free to ignore this post, if it's complete BS)

Hört sich eigentlich recht gut an...

Soweit ich es als ebenfalls nicht Progger verstanden habe, kannst du mit einer Texture quasi beliebige Werte darin abspeichern, die nichts, aber auch gar nichts miteinander zu tun haben - so zum Beispiel höchst unterschiedliche Reflexionseigenschaften von Materialien.
Mit einer Rechnung kannst du "nur" einer Funktion folgen und wenn bsw. die Reflexionseigenschaften von Alu anders sind, als die von Holz, brauchst du dafür eine neue Funktion, sprich, einen neuen Shader.

Verstehe.

Ergo Ausgangssituation = hier ist Rechengedöhns, da kommt *insert was Reflektierendes* ... mach das Beste/Schnellste draus!

Ergo nu = hier reflektierts so ... kann zwar nüscht anderes mehr und hat nichts mehr mit dem allgemeinen ARB2 zu tun, das den sinnigsten Mittelwert die Gesamtheit aller ARB2-fähigen Karten liefert, aber das kannste ja schnell, ge?

Naja naja... liest sich für mich so, als wäre ein R3XX/4XX zu blöde, das intern zu regeln. 1:0 für nV, sag ich mal.

Ich verstehe allerdings, daß sich andere einen eigenen Pfad gewünscht hätten - fraglich ist: wußte fir id-Engine Mutzschaft von diesem Gedöhns? I doubt that...

Sieht man IMO gut an HL2 und FC, die zigtausend Shader nutzen - nach eben diesem Prinzip.

Ey, dutzende Dutzend Shader hat FC, bei D³ warens IIRC laut Sascha ~12 :naughty:

[Quasar]

... nach eben diesem Prinzip, für jede Surface einen eigenen Shader zu benutzen und eben keine LUT zu haben.

Eventuell, aber auch nur ganz eventuell, wollte JC seine Core-Engine ein wenig übersichtlicher halten, da er sie ja noch an andere weiterverhökern will und man bis vor kurzem ja noch nicht damit rechnen konnte, auch unter OpenGL wirklich eine HLSL zu bekommen, die Effekte noch und nöcher per Tastendruck generieren kann?

[MadManniMan]

Ergo nu = hier reflektierts so ... kann zwar nüscht anderes mehr und hat nichts mehr mit dem allgemeinen ARB2 zu tun, das den sinnigsten Mittelwert die Gesamtheit aller ARB2-fähigen Karten liefert, aber das kannste ja schnell, ge?

Ey, keine Sau beschwerte sich derartig darüber, daß man nicht alles gleich für den NV3X optimiert hat, aber hier herrscht gleich Bürgerkrieg - Punkt für die nVidioten :D

[seahawk]

... nach eben diesem Prinzip, für jede Surface einen eigenen Shader zu benutzen und eben keine LUT zu haben.

Eventuell, aber auch nur ganz eventuell, wollte JC seine Core-Engine ein wenig übersichtlicher halten, da er sie ja noch an andere weiterverhökern will und man bis vor kurzem ja noch nicht damit rechnen konnte, auch unter OpenGL wirklich eine HLSL zu bekommen, die Effekte noch und nöcher per Tastendruck generieren kann?

Exakt.

[Quasar]

Ergo nu = hier reflektierts so ... kann zwar nüscht anderes mehr und hat nichts mehr mit dem allgemeinen ARB2 zu tun, das den sinnigsten Mittelwert die Gesamtheit aller ARB2-fähigen Karten liefert, aber das kannste ja schnell, ge?

Ey, keine Sau beschwerte sich derartig darüber, daß man nicht alles gleich für den NV3X optimiert hat, aber hier herrscht gleich Bürgerkrieg - Punkt für die nVidioten :D

Sorry, bei deinem Post oben konnte ich dir zwischen zweitem "Ergo" und "that" nicht so ganz folgen....
Vielleicht erstmal aufwachen?
Kannst du den nochmal bissi anders schreiben, daß ich's verstehe?

*MMM_Kaffee_reich*

[MadManniMan]

Joar, meine Madame darf dank des neuen Schuljahres wieder halb 7 aufstehen - da zieh ich gleich mit, muß ich doch bald wieder studieren tun... Vorher ging ich halb 7 ins Bett - irgendwie muß man das ja merken.

:ucoffee: *schlürf* ... :up:

...

Also nochmal auf ... äh, verständlich halt:

Ergo nu = hier reflektierts so ... kann zwar nüscht anderes mehr und hat nichts mehr mit dem allgemeinen ARB2 zu tun, das den sinnigsten Mittelwert die Gesamtheit aller ARB2-fähigen Karten liefert, aber das kannste ja schnell, ge?

Humus-Shader-Replacement -> keine Flexibilität mehr, spezielle Anpassung an 9X00/X800-Eigenheit ... Loslösen vom ARB2-Pfad, der von allen derlei fähigen Chips das Selbe abverlangt.

Naja naja... liest sich für mich so, als wäre ein R3XX/4XX zu blöde, das intern zu regeln. 1:0 für nV, sag ich mal.

Solls ATi doch in den Treiber einbauen, wenns keine optischen Unterschiede gibt. Schade für ATi und die Kartenbesitzer, daß der R420 hiermit Probleme hat und nach Replacements schreit.
Warum kommt der NV40 damit zurecht?(<- erstmal fürs Zurechkommen ein Lob von mir)

Ich verstehe allerdings, daß sich andere einen eigenen Pfad gewünscht hätten - fraglich ist: wußte fir id-Engine Mutzschaft von diesem Gedöhns? I doubt that...

Davon ausgehend, daß JC von diesem speziellem "Tweak" wußte - was ich nicht tue! - , würde ich verstehen, wenn man sich über einen Fehlenden R300/420-Pfad beschwert.


Und was ich mit dem Post danach meinte: hier wird sich darüber aufgeregt, daß JC nicht gleich andere Shader benutzte und somit nicht 1000%ig auch auf die ATi-Karten hin programmierte, andererseits wurde lauthals geschrien, wenn nV Shaderreplacements einsetzte - obwohl es ja nach der momentan vorherrschenden Meinung unfair sei, nicht jedem Chip sein eigenes Futter zu liefern :rolleyes:


...errm, so besser?

[Crushinator]

Ein sehr schwacher Post Mr. Lolmann. Du bist hiermit auf meine persönliche ATI-Fanboyliste aufgenommen. (...) Langsam fange ich an, dieses Wort (Fanboy) zu hassen. Wäre es zuviel verlangt, in Zukunft darauf zu verzichten? Zumal es sich anhand von "Meldungen" nicht allein um mein Empfinden handelt!

[seahawk]

OT : Dafür hat jemand auf das Auge gedrückt ?? Ist das nicht schon fast Zensur ?? Aber natürlich entschuldige ich mich für die Benutzung des bösen F-Wortes. ;D ;D

[Mrs. Lolman]

OT : Dafür hat jemand auf das Auge gedrückt ?? Ist das nicht schon fast Zensur ?? Aber natürlich entschuldige ich mich für die Benutzung des bösen F-Wortes. ;D ;D

Das war aber nicht ich.

[Mr. Lolman]

und ich schon garnicht (falsch eingeloggt gewesen)

[MadManniMan]

"Fanboy" ist einfach zu negativ angehaucht, auch "biased" wird sehr provokant aufgefaßt - aber wie soll man es denn formulieren?

Es würde mir sehr schwer fallen, einfach nur "Durch diesen deinen Post habe ich beschlossen, dich künftig als einen derer zu sehen, die mit einer gewissen emotionalen Grundhaltung an eigentlich technisch-trockene Dinge herangehen und daher nicht als Referenz zur Bildung einer objektiven Betrachtung herangezogen werden können." zu schreiben :crazy:

;)

[Mr. Lolman]

2 Sachen:
B) @Lolman

Ist es für dich kein Argument, ein einheitliches Berechnungsmodell für alls ARB2-fähigen Chips gestellt haben zu wollen?

Sicher ists ein Argument. Aber ich versteh momentan nur nicht, warum das originale Berechnungsmodell einheitlicher war, als der Humus Patch. Klar logisch ists, Humus hats geproggt, es ist auf Ati zugeschnitten.

Ich weiss aber nicht, ob das eine sooo aussergewöhnliche Leistung ist,. Ich hab zwar noch keine 3D Engine selbst geproggt, sondern nur so nen Arkanoidverschnitt (sollte jeder gemacht haben), aber ich versteh die Argumentation nicht, dass JC das eh alles nach besten gewissen erledigt haben, einen schönen Einheitlichen ARB2 Pfad hat, und das wir ATI User uns glücklich schätzen können, einen Humus zu haben, denn die Kniffe die er verwendet haben soll, stehen in keinen OPtimierungsguides (wirklich oder nur angeblich?), und von einem Programmiergott JC darf man das garnicht erwarten.

Ich bin immernoch der Meinung, das JC sehr wohl wusste, wie die interaction.vfp auszusehen hat, damit es ATi Karten schmeckt. Aber vielleicht entsprechen die Shader einfach nicht seinem Style. Der Mann programmiert halt Tag ein Tag aus Engines, der braucht auch keine Dev Guides, weil der schon längst dafür ein Gefühl entwickelt hat, was GraKas gefällt und was nicht. Ich mein wenn Leuite hier im Forum schon wissen, dass ATi Karten dependent Texturereads nur bis zu einem bestimmten Grad mögen, dann sollte das für JC doch ein leichtes sein, es ebenfalls herauszufinden.


Ich find Shaderreplacement ok, solang, das Ergebnis das Gleiche bleibt, kein Shader von einem Benchmark der die Geschwindigkeit besitmmter Shader misst, ausgetauscht wird. Clipping Planes für vordefinierte Kamerapfade (Timedemos, div. Benchmarks) sind jedoch ein absolutes Tabu und gehören aufgezeigt.




Klar hätte ATi das auch in den Treiber integieren können. 1:0 für NV. Aber JC hätte das auch ins Spiel integrieren können. Oder noch besser: Wie würde die Diskussion laufen, wenn JC NUR die Humus Methode verwendet HÄTTE. (Also rein hypothetisch, frag ich mich ganz idealistisch wieder einmal: "was wäre wenn". Wenn es nicht mehr erlaubt ist etwas zu hinterfragen, ohne das man gleich Verschwörungsabsichten in die Schuhe geschoben bekommt, oder sich gleich ob seiner Ansichten über GraKas rechtfertigen muss, dnn werd ich dass in Zukunft bleiben lassen.

Den irgendwie komm ich mir schon verarscht vor, wenn ich, im besten Bemühen, eine fruchtbare Diskussion zu führen, mir immer wieder vorwerfen lassen muss, ein Fanboy zu sein....

Nochmal: Ich bin mir 100%ig sicher, dass es für JC kein Unding gewesen wär, nach Humus Art zu proggen. Gut Humus kann super proggen. Aber das kann auch Demi und Zeckensack. Und einen JC will ich erst garnicht mal erwähnen.





Klar ist der ARB2 Pfad einheitlich. Aber ist er das nur, weil er der Standardpfad ist, und er von allen Karten verwendet wird? Dürfte man nicht auch sagen, der Humus Pfad wäre einheitlich, wenn er denn der Standardpfad wäre (ja schon wieder hypothetisch ;)) Oder sieht man das am Shadercode, dass das Zeuch ist, was NV nicht schmeckt. Im Übrigen braucht auch keiner mehr das mit der 3 Takte veranschlagenden Exponentialfunktion als Beispiel bringen. Der Shader rechnet längst anders. Glauben NV Fans, dass es noch eine auf NV zugeschnittene interaction.vfp geben könnte? Was sagen die Gurus zu dem Thema. Bietet die Standardlösung noch Optimierungspotential für NV Karten?

Wenn ja, muss sich JC die Frage gefallen lassen, warum er zum Nachteil aller Spieler, eine einheitliche interaction.vfp genommen hat, anstatt auf die GraKas zu optimieren. Die Antwort kann ich mir eh denke: "JC ist in einer Position, wo die Grafikhersteller auf seine Engines optmieren. Er gibt klare Vorgaben, wass die GraKas können sollen, und proggt genau nach seinen Style die Engines. WEnn NV Karten dann eher so aufgebaut sind, dass sie seinen "Style" mögen, dann ist das das Glück für NV, für ATi muss halt optimiert werden.

"Angesichts der Technik der Radeon-Chips, welche so gar nicht zu Doom 3 passt, halten wir es für schon erstaunlich, was John Carmack und id Software da noch an Performance herauskitzeln konnte.
"

Klingt eben so, als wäre D3 nach besten wissen auf ATi Karten optimiert worden.

"Wir wagen nach derzeitigem Kenntnisstand zu bezweifeln, dass ATI die derzeit klaffende Performance-Lücke mit neuen Treibern schließen kann"

Klingt genauso. Ist aber falsch. Von 4.7 auf 4.9beta + Humus Patch schrumpft der Vorsprung von 30% auf 15%. Dass es an der Schattentechnik selbst liegt, wag ich zu bezweifeln, denn bei Thief ist, ATi z.T: deutlich vorne. Da solltes doch genauso viel Early Z Occlussion geben. Es ist ja eigentlich auch lächerlich wegen der 15% so einen Aufstand zu machen. Ich will ja auch nur wissen, ob es so widersinnig ist, anzunehmen, dass der ganze Artikel seine Gültigkeit verliert, wenn Doom kein App.AF kennte, und der ARB2 Pfad auf Perssons Mistbeet gewachsen wäre. (Achtung: Hypothese :))

[Mr. Lolman]

"Fanboy" ist einfach zu negativ angehaucht, auch "biased" wird sehr provokant aufgefaßt - aber wie soll man es denn formulieren?
;)

Am besten mit einer PM. Ich werds registrieren. Es tut mir auch leid, bei ein paar Leuten nun unten durch zu sein, aber so ist das halt, wenn man Fragen stellt.

Wenn jetzt jemand angefangt hätte einen Auszug des Humus Patchs zu posten, und mir genau erklärt hätte, warum man diesen Code als Normalsterblicher nie soo proggen würde und könnte, und warum es so widersinnig wäre, anzunehmen, was gewesen wär, wenn NUR der Humuscode existieren würde, dann wär die Diskussion wohl besser verlaufen, als bis jetzt,
wos nur heisst, ich schreddere Thread, bin ein Fanboy, bau Verschwörungstheorien auf, usw...

Leutens, ich wundere mich nur, WARUM?
Und ein bisschen wundern wird man sich wohl noch dürfen...


Sry, Leutens ich werd wohl erst wieder morgen Zeit für Antworten haben. *neuenMonitorkaufdannvortellugsgesprächhabundamabendzumMusekonzertgeh*

[Quasar]

Benutzt Thief3 Z-Fail? Wieviele Lichtquellen werden pro Objekt berücksichtigt? Warum nutzen Programmierer des letzten Jahres kaum den 2.A+pp-Pfad? Auch einseitige Bevorzugung? Schmecken nV-Karten DR denn besser oder können sie einfach nur mehr davon? Brechen sie nicht auch in der Performance ein, wenn zuviele DR genutzt werden? Würde der Humus-Tweak auch so vielzitiert sein, wenn Herr Persson nicht "Control-Panel"-AF genutzt hätte und anstelle von 40% nur 4% geschrien hätte? Hat JC überhaupt versucht, mit CP-AF sein Game auszuprobieren oder hat er sich auf die Vorgabe: Application-controlled bedeutet auch wirklich application controlled verlassen?

;)

[Radeonator]

@Lolmann : Die allgemeinheit wundert es nur, das du nur bei ATi derart in die Bresche springst. Umgekehrt alles negativierst was an Optimierungen aus der nV Ecke kommt (bin schon auf HL2 gespannt... )
Ich frage auch nur und werde mich ja auch wundern dürfen ?

Es geht darum, das ein Flexibler Pfad in einen staren Pfad geändert wurde. Wenn man an einen Pfad "anbaut" ist das immer noch was anderes, als ihn auf diese Weise zu optimieren...

btw. Ums gleich vorweg zu nehmen, habe eine DC S8 und eine R300 zu hause...wenn ihr versteht was ich meine ;)

[aths]

MMM, mit einer Funktion kann man eben nur den Funktionswert berechnen. Viele Funktionen sind parametrisierbar, so dass sie sich anpassen lassen. Eine Textur kann aber (in gewissen Grenzen was die Genauigkeit angeht) beliebige Funktionen speichern, auch solche, die sich mathematisch nur sehr aufwändig annähern lassen.

Allerdings ist es wohl, nach etwas nachdenken, nicht sooo wichtig, den spekularen Lichtanteil unbedingt mit einer superflexiblem Funktion zu holen. In der Regel stellt man einen Exponenten ein, fertig.

Was ich nicht ganz verstehe ist, wo bei der Radeon der Speedup herkommt. Erinnern wir uns, dass die TEX-Einheit unabhängig von den arithmetischen ALUs arbeiten kann. Mit TEX ein bilineares Sample zu holen kostet "effektiv" einen Takt. Gleichzeitig kann noch gerechnet werden (unabhängig ob TEX was zu tun hat, oder nicht.) Billiger geht es eigentlich nicht. Wenn allerdings vorher Texturen mit hohen AF-Graden gesampelt werden kann es schon sein, dass an dieser Stelle auf die TMU gewartet werden müsste, was man jetzt einfach mit der Ersetzung durch Arithmetik umgeht. Allerdings dürfte das nur vergleichsweise wenig Pixel betreffen. Außerdem beschleunigt es GeForce ja eben nicht. (Ok, die sortieren vermutlich auch die Instruktionen anders.)

[MadManniMan]

Somit stellt sich wiederum die Frage: warum hat JC das so gemacht? Wollte er für andere Engines und/oder Mods alles nach Baukastenprinzip offen lassen? Oder war dies die einzige, nun, eher beste Lösung für das Mittel der Gesamtheit ARB2 Fähiger Chips?

[LovesuckZ]

Klingt genauso. Ist aber falsch. Von 4.7 auf 4.9beta + Humus Patch schrumpft der Vorsprung von 30% auf 15%.

Nicht 15%, sondern 50%.
Ich bitte darauf hinzuweisen, dass eine XTPE einen 30% Coretakt hat, den der X800pro fehlt.
Oder anders: Ein NV40 kann unter Doom3 50% Mehrleistung als der r420 umsetzen.

Es ist ja eigentlich auch lächerlich wegen der 15% so einen Aufstand zu machen.

50%, oder ohne Betatreiber und Shaderreplacement 70%.

Ich will ja auch nur wissen, ob es so widersinnig ist, anzunehmen, dass der ganze Artikel seine Gültigkeit verliert, wenn Doom kein App.AF kennte, und der ARB2 Pfad auf Perssons Mistbeet gewachsen wäre. (Achtung: Hypothese :))

Es ist eben nicht so.
Aber kannst du auch die Frage beantworten, wie id Doom3 haette programmieren sollen, dass der NV40 und R420 auf dem selben Leistungsniveau waere ohne Engineentscheidungen (verschiedenen Genauigkeiten, diese Schattenberechnung, Utrashadow) nicht benutzen zu koennen?

[MadManniMan]

LS, es ist doch aber müßig, taktrelativiert zu denken. Der R420 verträgt nunmal höhere Frequenzen - wichtig ist, was hinten rauskommt.
Schließlich müßte man sonst allgemein einen deutlichsten Sieg für den NV40 konstatieren, da der Mehrtakt der XT-PE erst den relativen Gleichstand zustande bringt.

[Xmas]

Was ich nicht ganz verstehe ist, wo bei der Radeon der Speedup herkommt. Erinnern wir uns, dass die TEX-Einheit unabhängig von den arithmetischen ALUs arbeiten kann. Mit TEX ein bilineares Sample zu holen kostet "effektiv" einen Takt. Gleichzeitig kann noch gerechnet werden (unabhängig ob TEX was zu tun hat, oder nicht.) Billiger geht es eigentlich nicht.
Sofern die Texel im Cache sind. Bei stark variierenden Normalen ist das nicht unbedingt der Fall, da geht dann die Performance in die Knie. Selbiges gilt auch für Normalisieren per Cubemap.

[LovesuckZ]

LS, es ist doch aber müßig, taktrelativiert zu denken. Der R420 verträgt nunmal höhere Frequenzen - wichtig ist, was hinten rauskommt.

Was machst du mit der X800pro?
Diese wird hier die ganze Zeit außen vorgelassen, als ob sie nicht gaebe.

Schließlich müßte man sonst allgemein einen deutlichsten Sieg für den NV40 konstatieren, da der Mehrtakt der XT-PE erst den relativen Gleichstand zustande bringt.

So ist es doch, wie man hier (http://www.computerbase.de/artikel/hardware/grafikkarten/inno3d_geforce_6800_gt_ultra/12/#doom_3) sehen kann.

[MadManniMan]

Was machst du mit der X800pro?
Diese wird hier die ganze Zeit außen vorgelassen, als ob sie nicht gaebe.

Bei dieser - wie auch bei all den anderen Karten - ist es wichtig, die Anzahl und Taktung der Pipes nie zu vergessen.
Andererseits jedoch sind die Karten so auf dem Markt, wie sie sind. Thats it.

[LovesuckZ]

Bei dieser - wie auch bei all den anderen Karten - ist es wichtig, die Anzahl und Taktung der Pipes nie zu vergessen.


Du sagst doch selbst: "wichtig ist, was hinten rauskommt."
Es ist daher nicht gerade richtig, immer noch von der XTPE zu reden, wenn die X800Pro wahrscheinlich sich oefters verkauft hat.
Wenn Mr.Lolman den Vorsprung mit 15% tituliert, dann fehlt die Betrachtung der anderen Karte.

[MadManniMan]

Das ist wiederum richtig :)

Im Endeffekt darf man dann aber auch nur über X800 Pro und 6800 reden - alles andere ist kaum zu bekommen ;)

Also entweder über alle Karten, oder aber über die Verfügbaren, ok so? :)

[LovesuckZ]

Im Endeffekt darf man dann aber auch nur über X800 Pro und 6800 reden - alles andere ist kaum zu bekommen ;)


Die schlaegt die X800pro auch ;)
Es geht ja nicht darum, wieviel kaufbar sei, sondern ob man solch eine Karte aus der Betrachtung ausschließen darf.
Und das wird von Mr.Lolman gemacht, wenn er sagt, der Vorsprung waere nur noch "laecherliche" 15%.

[FPSn00b]

@Mr. Lolman
[...]Bietet die Standardlösung noch Optimierungspotential für NV Karten?[...]
Was sonst könnte der Grund dafür sein, daß nVidia nach Carmack Shader per Treiber bei Doom3 ersetzen soll? - Außer natürlich wenn diese qualitätsreduzierend wären, wobei etwas in dieser Richtung AFAIK noch nicht aufgefallen ist.
BTW Würde mich sowieso mal interessieren, wieviel Prozent nVidias Shader-Modifikationen bringen, bzw. wie schnell im Vergleich zu den ATI-Karten Doom3 ohne sie noch laufen würde...

[Quasar]

Welche Shadermodifikationen meinst du? Die im nV40 ggü. dem nV30? Sicherlich einiges.
Aber auch der nV30 ist noch sehr konkurrenzfähig zum R300.

[aths]

Sofern die Texel im Cache sind. Bei stark variierenden Normalen ist das nicht unbedingt der Fall, da geht dann die Performance in die Knie. Selbiges gilt auch für Normalisieren per Cubemap.Der Texturcache der 5900 ist afaik deutlich kleiner als bei der 9800 (9700) wobei die 5900 iirc durch den Humus-Patch eher verliert, während 9800 tendenziell gewinnt.

[FPSn00b]

@Quasar
Welche Shadermodifikationen meinst du?
Sorry, habe versucht "Shaderreplacements" zu vermeiden, und "Shader-Ersetzung" hört sich irgendwie mistig an. -Und weil die Shader wohl durch sehr ähnliche ersetzt werden, dachte ich mir "Shader-Modifikationen" wäre angemessen. :)

[Demirug]

aths, der Speed ist eigentlich relative einfach zu erklären.

Nehmen wir mal den Originalshader:

DP3 specular, fragment.texcoord[6],fragment.texcoord[6];
RSQ specular, specular.x;
MUL specular, specular.x, fragment.texcoord[6];
TEX light, fragment.texcoord[0], texture[0], CUBE;
MAD light, light, scaleTwo, subOne;
TEX localNormal, fragment.texcoord[1], texture[1], 2D;
MOV localNormal.x, localNormal.a;
MAD localNormal, localNormal, scaleTwo, subOne;
DP3 light, light, localNormal;
TXP R1, fragment.texcoord[3], texture[3], 2D;
MUL light, light, R1;
TXP R1, fragment.texcoord[2], texture[2], 2D;
MUL light, light, R1;
TEX R1, fragment.texcoord[4], texture[4], 2D;
MUL color, R1, program.env[0];
DP3 specular, specular, localNormal;
TEX R1, specular, texture[6], 2D;
MUL R1, R1, program.env[1];
TEX R2, fragment.texcoord[5], texture[5], 2D;
ADD R2, R2, R2;
MAD color, R1, R2, color;
MUL color, light, color;
MUL result.color, color, fragment.color;

Das bringt natürlich noch nichts also umsortieren in den Radeon Style

TEX light, fragment.texcoord[0], texture[0], CUBE;
TEX localNormal, fragment.texcoord[1], texture[1], 2D;
TXP R1, fragment.texcoord[3], texture[3], 2D;
TXP R1, fragment.texcoord[2], texture[2], 2D;
TEX R1, fragment.texcoord[4], texture[4], 2D;
TEX R2, fragment.texcoord[5], texture[5], 2D;

DP3 specular, fragment.texcoord[6],fragment.texcoord[6];
RSQ specular, specular.x;
MUL specular, specular.x, fragment.texcoord[6];
MAD light, light, scaleTwo, subOne;
MOV localNormal.x, localNormal.a;
MAD localNormal, localNormal, scaleTwo, subOne;
DP3 light, light, localNormal;
MUL light, light, R1;
MUL light, light, R1;
MUL color, R1, program.env[0];
DP3 specular, specular, localNormal;
MUL R1, R1, program.env[1];
ADD R2, R2, R2;

Phase

TEX R1, specular, texture[6], 2D;
MAD color, R1, R2, color;
MUL color, light, color;
MUL result.color, color, fragment.color;

Daraus ergibt sich

Phase1: 6T + 13A
Phase2: 1T + 3A

Bei den 13A von Phase 1 ist mindestens 1 Skalar und eine Mini-ALU Operation dabei als <= 11 Takte.

T Ops haben nun die Tendenz im Mittel mehr als einen Takt zu brauchen vorallem wenn hochwertige Filter zum Einsatz kommen. Bei etwa zwei Takten pro T-Op wird Phase1 Fillrate limitiert. Da sich bei Phase2 beim App-AF aber nichts ändert bleibt sie Rechenlimitiert (3 Takte). Wir kommen also auf Texturetakte(Phase1) + 3 Takte(Phase2)

Jetzt nehmen wir mal den Humus Tweak:

DP3 specular, fragment.texcoord[6],fragment.texcoord[6];
RSQ specular, specular.x;
MUL specular, specular.x, fragment.texcoord[6];
TEX light, fragment.texcoord[0], texture[0], CUBE;
MAD light, light, scaleTwo, subOne;
TEX localNormal, fragment.texcoord[1], texture[1], 2D;
MOV localNormal.x, localNormal.a;
MAD localNormal, localNormal, scaleTwo, subOne;
DP3 light, light, localNormal;
TXP R1, fragment.texcoord[3], texture[3], 2D;
MUL light, light, R1;
TXP R1, fragment.texcoord[2], texture[2], 2D;
MUL light, light, R1;
TEX R1, fragment.texcoord[4], texture[4], 2D;
MUL color, R1, program.env[0];
DP3 specular, specular, localNormal;
MAD R1.x, specular, ....
MUL R1.x,R1.x,R1.x
MUL R1, R1.x, program.env[1];
TEX R2, fragment.texcoord[5], texture[5], 2D;
ADD R2, R2, R2;
MAD color, R1, R2, color;
MUL color, light, color;
MUL result.color, color, fragment.color;

Wieder umsortieren

TEX light, fragment.texcoord[0], texture[0], CUBE;
TEX localNormal, fragment.texcoord[1], texture[1], 2D;
TXP R1, fragment.texcoord[3], texture[3], 2D;
TXP R1, fragment.texcoord[2], texture[2], 2D;
TEX R1, fragment.texcoord[4], texture[4], 2D;
TEX R2, fragment.texcoord[5], texture[5], 2D;

DP3 specular, fragment.texcoord[6],fragment.texcoord[6];
RSQ specular, specular.x;
MUL specular, specular.x, fragment.texcoord[6];
MAD light, light, scaleTwo, subOne;
MOV localNormal.x, localNormal.a;
MAD localNormal, localNormal, scaleTwo, subOne;
DP3 light, light, localNormal;
MUL light, light, R1;
MUL light, light, R1;
MUL color, R1, program.env[0];
DP3 specular, specular, localNormal;
MAD R1.x, specular, ....
MUL R1.x,R1.x,R1.x
MUL R1, R1.x, program.env[1];
ADD R2, R2, R2;
MAD color, R1, R2, color;
MUL color, light, color;
MUL result.color, color, fragment.color;

Da war es nur noch eine Phase mit 6T + 18A. Bei den A Ops haben wir zusätzlich jetzt noch 2 Skalarops mehr also sollte der Shader <= 14 Takte haben. Bei etwas mehr als 2 Takte pro T-Op wird er Füllraten limitiert und braucht dann Texturetakte. Gegenüber dem Originalshader werden also 3 Takte gespart. Das Wegfallen des Dependent-Reads wirkt sich ebenfalls vorteilhaft aus.

Wie man sieht eigentlich ganz einfach.


Welches ist aber nun der aus Entwicklersicht richtige Shader für D3. Wenn man nur einen einzigen Shader benutzten kann/will ist die Antwort ganz einfach:

Der Shader bei dem, unter verwendung der minimalsten vorgesehenden Filterqualität, die schwächste Karte den grössten FPS Wert hat.

Das man sich nicht unbedingt mit einem Shader für alle Karten/Settings zufrieden geben sollte ist dann wieder ein anderes Thema.

[Quasar]

@Quasar

Sorry, habe versucht "Shaderreplacements" zu vermeiden, und "Shader-Ersetzung" hört sich irgendwie mistig an. -Und weil die Shader wohl durch sehr ähnliche ersetzt werden, dachte ich mir "Shader-Modifikationen" wäre angemessen. :)

Welche Original-Shader werden durch welche Alternativen ersetzt?

[FPSn00b]

@Quasar
Welche Original-Shader werden durch welche Alternativen ersetzt?
Doom3-Original-Shader durch nVidia-optimierte, genaueres weiß ich nicht - würde aber gerne. :)

(S. z.B. hier (http://www.beyond3d.com/forum/viewtopic.php?t=15443), aber auch in anderen Threads dort wurde es IIRC kurz angesprochen, unter anderem im Humus+40%-Thread.)

[Quasar]

@Quasar

Doom3-Original-Shader durch nVidia-optimierte, genaueres weiß ich nicht - würde aber gerne. :)

(S. z.B. hier (http://www.beyond3d.com/forum/viewtopic.php?t=15443), aber auch in anderen Threads dort wurde es IIRC kurz angesprochen, unter anderem im Humus+40%-Thread.)
Ach so - aber primär ist erstmal Shader-Replacement fällig - egal, ob man was (genaues) weiß, oder nicht.

Mich würde viel eher mal interessieren, ob all diese Vorher-Nachher-Vergleich mit oder ohne Treiber-AF zustande gekommen sind.

[Jesus]

Ach so - aber primär ist erstmal Shader-Replacement fällig - egal, ob man was (genaues) weiß, oder nicht.

Mich würde viel eher mal interessieren, ob all diese Vorher-Nachher-Vergleich mit oder ohne Treiber-AF zustande gekommen sind.

wie wärs wenns mal jemand testen würde ? so in der art wie´s der typ in dem b3d artikel gemacht hat ( paar instruktionen vertauschen - 4 fps weniger ).

[Quasar]

Ja, das wäre ganz toll. Aber bitte mit vollständiger Angabe der Rahmenbedingungen....

[seahawk]

Exakt und man muss sicher sein, dass die Änderungen nicht gegen Optimierungsregeln verstoßen, die vorher eingehalten wurden. So, dass der Sahdercompiler durch die Änderungen nicht in seiner Arbeit behindert wird.

[Jesus]

Exakt und man muss sicher sein, dass die Änderungen nicht gegen Optimierungsregeln verstoßen, die vorher eingehalten wurden. So, dass der Sahdercompiler durch die Änderungen nicht in seiner Arbeit behindert wird.

das wird aber kaum funktionieren, es sei denn man weiss ( weiss man ? ) wie der Compiler optimiert bzw. reagiert. Zumindest für beide gleichzeitig wird das schwierig werden.

mach mal jemand ;)

[seahawk]

das wird aber kaum funktionieren, es sei denn man weiss ( weiss man ? ) wie der Compiler optimiert bzw. reagiert. Zumindest für beide gleichzeitig wird das schwierig werden.

mach mal jemand ;)

Deswegen kann man es ja auch nicht so einfach machen. Es kann eigentlich nur jemand machen, der die Optimierungsregeln für NV und ATI kennt. Man müßte den Shader nämlich syntaktisch ändern, ohne seine Funktion und Compilierbarkeit zu verändern.

Was würde eigentlich die User hier sagen, wenn jemand einen Tweak schreiben würde, der die vielen kleien HL2 Shader zu größeren zusammenfaßt um evtl. die Performance auf NV Karten zu verbessern ??

[MadManniMan]

Was würde eigentlich die User hier sagen, wenn jemand einen Tweak schreiben würde, der die vielen kleien HL2 Shader zu größeren zusammenfaßt um evtl. die Performance auf NV Karten zu verbessern ??

Ich wäre natürlich dafür.

Wenn es denn tatsächlich etwas bringt, wäre es imho angesichts des Humus-Tweaks nur fair.

Aber erstmal ist es wohl eher von Interesse, "DX9" auch für den NV3X bereitzustellen. Weitere Überlegungen zur Source-Engine von mir hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=165390).

[Demirug]

Deswegen kann man es ja auch nicht so einfach machen. Was würde eigentlich die User hier sagen, wenn jemand einen Tweak schreiben würde, der die vielen kleien HL2 Shader zu größeren zusammenfaßt um evtl. die Performance auf NV Karten zu verbessern ??

Ich weiss ja nicht ob sich da bei HL2 inzwischen was geändert hat. Aber AFAIK ist da nichts mit zusammenfassen. Zusammenfassen setzt vorraus das ein Pixel im Multipass verfahren gerendert wird. Das ist aber bei HL2 eigentlich nicht der Fall. Die mehrheitlich kurzen Shader sind alles was ein Pixel bekommt. Könnte natürlich sein das sich da noch was geändert hat aber so richtig glauben mag ich daran nun auch nicht.

[MadManniMan]

Ich weiss ja nicht ob sich da bei HL2 inzwischen was geändert hat. Aber AFAIK ist da nichts mit zusammenfassen. Zusammenfassen setzt vorraus das ein Pixel im Multipass verfahren gerendert wird. Das ist aber bei HL2 eigentlich nicht der Fall. Die mehrheitlich kurzen Shader sind alles was ein Pixel bekommt. Könnte natürlich sein das sich da noch was geändert hat aber so richtig glauben mag ich daran nun auch nicht.

Wenn ich seahawk richtig verstanden habe, meinte er, daß vielleicht ähnliche Materialshader durch einzelne, flexibel zu speisende ersetzt werden sollten - dürfte aber ziemlich aufwendig werden... ich kann mir vorstellen, daß der umgekehrte Weg(ausgehend vom Humustweak) komplizierter einzuschlagen ist.

[Jesus]

Deswegen kann man es ja auch nicht so einfach machen. Es kann eigentlich nur jemand machen, der die Optimierungsregeln für NV und ATI kennt. Man müßte den Shader nämlich syntaktisch ändern, ohne seine Funktion und Compilierbarkeit zu verändern.

Was würde eigentlich die User hier sagen, wenn jemand einen Tweak schreiben würde, der die vielen kleien HL2 Shader zu größeren zusammenfaßt um evtl. die Performance auf NV Karten zu verbessern ??

andererseits würde dass natürlich bedeuteten falls sich durch so einfache änderungen an einer Karte was ändert, das entweder der Compiler der KArte an diesen Shader angepasst wurde ( was vorraussetzt dass sie den Sourcecode schon lange hatten ) oder dass der Shader an den Compiler angepasst wurde.

Falls sich dann allerdings nur bei einer Karte etwas ändert ( + / - ) dann würde das bedeuteten dass diese Optimierung nur für diese Karte greift. ( Das würde das böse Wort Shaderreplacement durch das etwas weniger böse Shaderoptimierung ersetzen ;)

Da wir aber nur einen Shader für alles haben dürfte es eigentlich keine Optimierung für irgendeine Karte geben, es sei denn beide Compiler sind identisch, oder es wurde bewusst für eine Karte optimiert.

[Quasar]

Topic:
Benchmark CS:Source: 6800 Ultra gegen X800XT PE bei Driverheaven.net

Für Doom3 doch bitte einen eigenen Thread eröffnen - gelle?

[Mr. Lolman]

Deswegen kann man es ja auch nicht so einfach machen. Was würde eigentlich die User hier sagen, wenn jemand einen Tweak schreiben würde, der die vielen kleien HL2 Shader zu größeren zusammenfaßt um evtl. die Performance auf NV Karten zu verbessern ??

Ob das so funktioniert?

Zumindest die NV3x Karten mögen lieber mehrere kurze Shader, als einen langen. (Wenn man die Rubydemo als Vergleichsparameter heranzieht)
Ich bild mir auch ein, dass NV40 Karten mit dem Colourlesstweak schneller laufen, als nur mit der gehackten dll. Das müsste man halt nachprüfen...

[Mr. Lolman]

Topic:
Benchmark CS:Source: 6800 Ultra gegen X800XT PE bei Driverheaven.net

Für Doom3 doch bitte einen eigenen Thread eröffnen - gelle?


Wem sagst du das jetzt? Denjenigen die fleissig mit OT gepostet haben, nur Jesus, oder mir?

[Demirug]

Ob das so funktioniert?

Zumindest die NV3x Karten mögen lieber mehrere kurze Shader, als einen langen. (Wenn man die Rubydemo als Vergleichsparameter heranzieht)
Ich bild mir auch ein, dass NV40 Karten mit dem Colourlesstweak schneller laufen, als nur mit der gehackten dll. Das müsste man halt nachprüfen...

Der Tweak ist IIRC auch nicht ganz identisch mit den ursprünglichen Shader.

Bei gleicher Funktionalität ist ein langer Shader in der Regel besser als viele kleine. Vorallem weil bei den kleinen häuftiger Sachen doppelt gerechnet werden müssen.

Die Rubydemo ist da aber sowieso ein schlechter Massstab weil die Shader dort für einen ATI Chip (2.b) optimiert sind. Bei 2.B nutzt der Compiler sehr viele Temps was den FXen ja überhaupt nicht gefällt. Der Treiber kompensiert dieses Problem aber von Version zu Version besser.

[Demirug]

Von dort: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=165476

Ist seit letztem Jahr bekannt und wurde/wird, vorwiegend von ATi usern, auch gefordert.
Und ja, wenn ein Spieleprogrammierer meint, er koenne fuer die Spieler entscheiden, dann sollte man ihn mit nicht kaufen bestrafen.
Das geht eindeutig zu weit. Es ist die Sache des Kaeufer zu entscheiden, wie er das gamen moechte!

Gehört ja wohl inzwischen zum guten Ton die Caps zu ignorieren und nach der Geräte Kennung zu gehen.

Tja dann muss ich wohl auch für HL2 einen Pfad aktivierer schreiben wenn sich valve nicht doch noch eines besseren besinnt.

[winter]

Mal zu was anderem: Wieso wird die Geforce4 eigentlich auf DirectX 8.0 (PS1.1) limitiert? Hat Nvidia da bei der Werbung geschlampt und DirectX 8.1 fordert PS1.4, oder warum sonst wird der vorhandene PS1.3 der GF4 ignoriert? Ich hatte ja immerhin auch lange ne GF4, darum würds mich schon interessieren. Es dürfte doch keinen riesigen Geschwindigkeitsunterschied zwischen PS1.3 und 1.1 geben 0_o

[LovesuckZ]

Wenn Valve nur PS1.1 und PS1.4 verwendet, dann ist es klar, dass die GF4 in den normalen DX8 Pfad gezwungen wird.

[Formica]

ich denk mal nvidia hat valve gebeten das ihre chips nur 8.1 darstellen dürfen, weil sie selber gesehen haben wie nvidia bei 9.0 untergeht ? wäre doch möglich

[IVN]

@winter

I don't know if my memory is still fresh,but an GF4 TI has only PS 1.1.

[Formica]

@winter

I don't know if my memory is still fresh,but an GF4 TI has only PS 1.1.
stimmt, die 8500er ati konnte schon 1,4 glaub ich

[Black-Scorpion]

Afaik kann die GF4 kein DX8.1.

[LovesuckZ]

Afaik kann die GF4 kein DX8.1.

PS1.3 gehoeren ebenfalls unter DX8.1.

[LovesuckZ]

ich denk mal nvidia hat valve gebeten das ihre chips nur 8.1 darstellen dürfen, weil sie selber gesehen haben wie nvidia bei 9.0 untergeht ? wäre doch möglich

Nein, dass waere marketingtechnisch Bullshit. Viele Kunden wuerden sich verarscht vorkommen und dann zu einer Konkurenzkarte greifen.

[Demirug]

ich denk mal nvidia hat valve gebeten das ihre chips nur 8.1 darstellen dürfen, weil sie selber gesehen haben wie nvidia bei 9.0 untergeht ? wäre doch möglich

Dann hätten sie sich aber selbst ins Knie geschossen weil sie öffentlich gegen das ignorieren der von den Caps gemeldeten Features zugunsten einer Gerätekennungsabfrage gewettert haben.

[Black-Scorpion]

PS1.3 gehoeren ebenfalls unter DX8.1.
Sorry, mein Fehler.
Hätte wohl PS1.4 schreiben sollen.

[Jesus]

Nein, dass waere marketingtechnisch Bullshit. Viele Kunden wuerden sich verarscht vorkommen und dann zu einer Konkurenzkarte greifen.

wieso, was ähnliches haben sie doch bei FC von 1.0 auf 1.1 auch gemacht ..

[Demirug]

wieso, was ähnliches haben sie doch bei FC von 1.0 auf 1.1 auch gemacht ..

Um dann öffentlich allen Entwicklern zu sagen das man sowas nicht machen soll und Crytek (ohne den Namen zu nennen) zum Buhmann zu machen?

[Quasar]

Man könnte jetzt OT diskutieren, ob es da einen qualitativen Unterschied gibt, einfach kaputte DX9-Shader zu bekommen oder DX9 explizit auswählen zu können, das dann aber nicht zu bekommen. ;)

[Jesus]

Um dann öffentlich allen Entwicklern zu sagen das man sowas nicht machen soll und Crytek (ohne den Namen zu nennen) zum Buhmann zu machen?

ich glaube kaum das Crytek von selbst auf die Idee kam und die Qualität für die FXen reduziert hat um die Balkenlänge ( deutlich ) zu erhöhen.

[Quasar]

Topic:
Benchmark CS:Source: 6800 Ultra gegen X800XT PE bei Driverheaven.net

Für Far Cry doch bitte einen eigenen Thread eröffnen - gelle?

[Jesus]

irgendwie fehlt dir unter "Insane Member" das Wörtchen "Moderator" damit diese Worte eine Wirkung auf mich hätten :wink:

[seahawk]

Eigentlich beweist das nur das die FXen keine wirklichen DX9 Karten sind. Die Leistung ist einfach nicht da. Ich finde es richtig, dass Valve so handelt, dann erkennt der Kunde direkt ganz klar, wa er von einer Grafikkarte wirklich erwarten kann.

Ob die NV4Xen überhaupt wirklich DX9 rendern ??

[mapel110]

irgendwie fehlt dir unter "Insane Member" das Wörtchen "Moderator" damit diese Worte eine Wirkung auf mich hätten :wink:

ich unterstütze hiermit ganz offiziell Quasars statement. stay on topic please.

und Seahawk, was du da ablässt, kann man sehrwohl als flame auffassen. Sei hiermit ermahnt.

[deekey777]

Eigentlich beweist das nur das die FXen keine wirklichen DX9 Karten sind. Die Leistung ist einfach nicht da. Ich finde es richtig, dass Valve so handelt, dann erkennt der Kunde direkt ganz klar, wa er von einer Grafikkarte wirklich erwarten kann.

Ob die NV4Xen überhaupt wirklich DX9 rendern ??

Dann sollte man sich auch die Frage stellen, was es mit dem DX8.2 aka Mixed Mode letztes Jahr sein sollte.
Andererseits ist PS 1.4 keineswegs "veraltet", sondern kaum richtig unterstützt (mit eye candies und so) wie in Halo oder MP2. Rein objektiv ist -dxlevel 81 eine tolle Sache - einen grossen Unterschied gibt es im VST nicht (bis auf paralax mapping aka offset mapping aka displacement mapping). :biggrin:

[Demirug]

Eigentlich beweist das nur das die FXen keine wirklichen DX9 Karten sind. Die Leistung ist einfach nicht da. Ich finde es richtig, dass Valve so handelt, dann erkennt der Kunde direkt ganz klar, wa er von einer Grafikkarte wirklich erwarten kann.

Bevormundung ist also OK?

Dann stellen wir mal dennächst an ein paar Strassen Schilder auf das bestimmte Automarken dort nicht mehr fahren dürfen.

[Jesus]

ich unterstütze hiermit ganz offiziell Quasars statement. stay on topic please.


ok, ich hab zwar nicht angefangen mit OT, aber da du mich persönlich ansprichst fühle ich mich jetzt einfach mal stellvertretend für alle anderen ( inkl. Quasar ) ermahnt :rolleyes: .

[Formica]

Bevormundung ist also OK?

Dann stellen wir mal dennächst an ein paar Strassen Schilder auf das bestimmte Automarken dort nicht mehr fahren dürfen.
naja wenn bekannt ist das in dieser strasse besonders viele autos dieser marke geklaut werden.. ist es doch nur nett...

[dildo4u]

Eigentlich beweist das nur das die FXen keine wirklichen DX9 Karten sind. Die Leistung ist einfach nicht da. Ich finde es richtig, dass Valve so handelt, dann erkennt der Kunde direkt ganz klar, wa er von einer Grafikkarte wirklich erwarten kann.

Ob die NV4Xen überhaupt wirklich DX9 rendern ??
Ich denk schon das die NV40 echtes DX9 rendert wie sonst kann das bild auf na 6800 besser aussehen als auf na X800XT?

X800XT

http://www.firingsquad.com/hardware/half-life2_vst/images/01.png

http://www.firingsquad.com/media/article_image.asp?fs_article_id=1532&pic_id=01


6800Ultra
http://www.firingsquad.com/hardware/half-life2_vst/images/02.png


http://www.firingsquad.com/media/article_image.asp?fs_article_id=1532&pic_id=02

[Jesus]

Ich denk schon das die NV40 echtes DX9 rendert wie sonst kann das bild auf na 6800 besser aussehen als auf na X800XT?

X800XT
http://www.firingsquad.com/media/hirez.asp?file=/hardware/half-life2_vst/images/01.png

6800Ultra
http://www.firingsquad.com/hardware/half-life2_vst/images/02.png

war wohl eher ironisch gemeint ...


aber wo steht da dass es auf der 6800 besser aussieht ? ( und warum ? ) :eek:

[dildo4u]

war wohl eher ironisch gemeint ...


aber wo steht da dass es auf der 6800 besser aussieht ? ( und warum ? ) :eek:
Guck dir mal im hinter grund die kacheln an rechts oben

oder das rote fenster im vorder grund

[Jesus]

Guck dir mal im hinter grund die kacheln an rechts oben

glaub nicht dass man die bilder vergleichen kann, die dinger drehen sich und das licht ändert sich auch glaub ich. Ausserdem sinds zwei unterschiedliche Winkel.

[dildo4u]

glaub nicht dass man die bilder vergleichen kann, die dinger drehen sich und das licht ändert sich auch glaub ich. Ausserdem sinds zwei unterschiedliche Winkel.
Is dein standpunkt aber zumindest die wand sollte gleich aussehen

[ironMonkey]

Is dein standpunkt aber zumindest die wand sollte gleich aussehen

Das ist zu verschieden um da wirklich genau sagen zu können Bild X ist schärfer.



Gruß

[dildo4u]

Das ist zu verschieden um da wirklich genau sagen zu können Bild X ist schärfer.



Gruß
naja jetzt ia aber auch mal gut man muss auch mal was eingestehen können ati muss ja schließlich genug mherleistung im vergleich zum NV40 bringen um die D00M3 Benches halbwegs vergessen zu machen das game ist ja schließlich powerd by ati man kann einfach mal zugeben das es schlechter aussieht auch wenns nicht auf der karte der eigenen wahl am besten aussieht wenns so auf der NV40 aussehen würde würde ich mich auch ärgern

[Jesus]

naja jetzt ia aber auch mal gut man muss auch mal was eingestehen können ati muss ja schließlich genug mherleistung im vergleich zum NV40 bringen um die D00M3 Benches halbwegs vergessen zu machen das game ist ja schließlich powerd by ati man kann einfach mal zugeben das es schlechter aussieht auch wenns nicht auf der karte der eigenen wahl am besten aussieht wenns so auf der NV40 aussehen würde würde ich mich auch ärgern

lol was soll das geflame denn jetzt ? Irgendwie bist du der erste ( und einzige ) der "festgestellt" hat dass HL2 auf ner 6800 besser aussieht, komisch nich ? :wink:

[dildo4u]

lol was soll das geflame denn jetzt ? Irgendwie bist du der erste ( und einzige ) der "festgestellt" hat dass HL2 auf ner 6800 besser aussieht, komisch nich ? :wink:
Ich hab das nicht festgestellt sondern die website und nur die hat im gegensatz zu dir beide karten und kann das nachprüfen wenn ichs hab steuere ich 6800 bilder bei

[Jesus]

Ich hab das nicht festgestellt sondern die website und nur die hat im gegensatz zu dir beide karten und kann das nachprüfen wenn ichs hab steuere ich 6800 bilder bei

hm muss ich wohl überlesen haben...

[dildo4u]

hm muss ich wohl überlesen haben...
Ok die ham die bilder gemacht mir reicht das aber is ja auch egal bei den hohen fps zahlen die die ati erreicht fällt das eh nicht auf *g* wie gesagt zum glück muss ich hier ja niemanden von irgendetwas überzeugen hier kann sich jeder durch die bilder seine eigene meinung bilden

[IVN]

@dildo4u

You are comparing two different pictures. :|

[dildo4u]

@dildo4u

You are comparing two different pictures. :|
Yeah there are very different :rolleyes: im not sure if it really is the same Game (sorry for my bad Eng)

[seahawk]

ich unterstütze hiermit ganz offiziell Quasars statement. stay on topic please.

und Seahawk, was du da ablässt, kann man sehrwohl als flame auffassen. Sei hiermit ermahnt.


Das war Sarkasmus. Weil hier gleich wieder unterstellt wird, dass NV der Böse sein muss, während Valve und ATI nichts Böses tun können. Die Therorie, dass NV Valve gebeten hat die Fxen nur DX rendern zu lassen war mir so unsinnig, das konnte ich nicht mehr aushalten.

[ironMonkey]

naja jetzt ia aber auch mal gut man muss auch mal was eingestehen können ati muss ja schließlich genug mherleistung im vergleich zum NV40 bringen um die D00M3 Benches halbwegs vergessen zu machen das game ist ja schließlich powerd by ati man kann einfach mal zugeben das es schlechter aussieht auch wenns nicht auf der karte der eigenen wahl am besten aussieht wenns so auf der NV40 aussehen würde würde ich mich auch ärgern


Ok, war ja klar das sowas kommt...........


Wenn es auf einer NV40 Karte besser ausschaut dann hab ich da nix dagegen, es ist ja nur ein Spiel, aber wenigstens sollten die Bilder aus dem gleichen Winkel und der selben Entfernung sein, damit man das auch wirklich vergleichen kann.



Gruß

[IVN]

@dildo4u

Well,dildo you really have bad eyes. :D

[dildo4u]

Ok, war ja klar das sowas kommt...........


Wenn es auf einer NV40 Karte besser ausschaut dann hab ich da nix dagegen, es ist ja nur ein Spiel, aber wenigstens sollten die Bilder aus dem gleichen Winkel und der selben Entfernung sein, damit man das auch wirklich vergleichen kann.



Gruß

Für manche ist es das spiel überhaupt und der winkel sollte dennoch nicht ausmachen das die wand matschiger aussieht so unterschiedlich ist die entfernung zur wand auch nicht aber wie gesagt jeder kann es sehen wie er will

[IVN]

@dildo4u

As i see you like to compare apples with oranges.

[ironMonkey]

Stimmt was kann den schon ein paar ° stärkerer Winkel schon ausmachen........

Du hast ne GT, mach doch mal aus der Sicht der ATI einen Screenshot, dann wissen wir es genau.



Gruß

[dildo4u]

Stimmt was kann den schon ein paar ° stärkerer Winkel schon ausmachen........

Du hast ne GT, mach doch mal aus der Sicht der ATI einen Screenshot, dann wissen wir es genau.



Gruß
Wie gesagt wenn ichs hab mach ich pix aber dafür kauf ich mir nix extra CS:Z nur um an den benchmark zu kommen so lange müssen wir uns whol mit vergleich pix von websiten zufrieden geben

[Gast]

Eigentlich beweist das nur das die FXen keine wirklichen DX9 Karten sind. Die Leistung ist einfach nicht da. Ich finde es richtig, dass Valve so handelt, dann erkennt der Kunde direkt ganz klar, wa er von einer Grafikkarte wirklich erwarten kann.

Ob die NV4Xen überhaupt wirklich DX9 rendern ??

Is nicht dein ernst oder? Damit begibst du dich auf das Niveau deiner Sig, vieleicht nimmst du die auch als bare Münze...

Was ist wenn jmd einen Shader nach SM2.0 bastelt, der auf keiner Karte in annehmbarer Geschwindikeit läuft, sind dann alle Karten keine "wirklichen" DX9 Karten?
Ich würd mir diese Argumentation nochmal überlegen...

[MadManniMan]

@letzter Gast:

Bei seahawk ist der Sarkasmus meist wirklich, wirklich sehr gut zwischen den Zeilen versteckt und auch wenn man ihn schon so lange posten sieht, wie ich, muß man schon gut hinlesen ;)

@dildo:

Sorry, aber einen wirklichen Unterschied kann ich auf den Bildern nicht feststellen - deshalb konstatiere ich mal einen qualitativen Gleichstand zwischen NV40 und R3XX.

[dildo4u]

@MadMan ähm hast du ein crt oder ein tft ich finde schon das es einen unterschied gibt vor allem an der wand die NV40 hat meiner meinung nach mher furchen in der wand es wirkt ein wenig plastischer

[MadManniMan]

@MadMan ähm hast du ein crt oder ein tft ich finde schon das es einen unterschied gibt vor allem an der wand die NV40 hat meiner meinung nach mher furchen in der wand es wirkt ein wenig plastischer

Zuhause hab ich 2 TFTs und einen CRT - aber hier bei meiner Freundin nur einen nicht mehr gaaaanz taufrischen 17" CRT ... kann schon sein, daß da was dran ist - Übermorgen bin ich wieder @Home(...alone *heul* Honey, du wirst mir fehlen! ;( ), wenn du mich irgendwie dran erinnertest, würd ich mich freuen und nochmal nachsehen.

[WEGA]

wenn ichs hab steuere ich 6800 bilder bei

und ich x800 bilder O_o

[Mr. Lolman]

@MadMan ähm hast du ein crt oder ein tft ich finde schon das es einen unterschied gibt vor allem an der wand die NV40 hat meiner meinung nach mher furchen in der wand es wirkt ein wenig plastischer


Ich hab jetzt nen 19" TFT. *fg*

Und ich seh den Unterschied. Ists aber nicht eher ein Unterschied, den man durch sich unterscheidende LOD Werte erklären könnte?

Anfangs dachte ich auch dass das NV Bild von ner ATi wäre, und umgekehrt. IMO ist da nichts, weswegen man sich Gedanken machen müsste. (Allerhöchstens, ob man im Spiel das TextureLOD verstellen können wird, oder nicht)

[dildo4u]

Ich hab jetzt nen 19" TFT. *fg*

Und ich seh den Unterschied. Ists aber nicht eher ein Unterschied, den man durch sich unterscheidende LOD Werte erklären könnte?

Anfangs dachte ich auch dass das NV Bild von ner ATi wäre, und umgekehrt. IMO ist da nichts, weswegen man sich Gedanken machen müsste. (Allerhöchstens, ob man im Spiel das TextureLOD verstellen können wird, oder nicht)
Jo das ist halt die frage wenns kein lod schalter wie bei MaxPayne 2 gibt muss man als ati user whol damit leben ausser natürlich man nutzt tools aber benchmark mäßig vergleichen lässt sich das dann auch nicht

[Mr. Lolman]

Jo das ist halt die frage wenns kein lod schalter wie bei MaxPayne 2 gibt muss man als ati user whol damit leben ausser natürlich man nutzt tools aber benchmark mäßig vergleichen lässt sich das dann auch nicht

Ich will ja nicht schon wieder Aussagen tätigen, die man mir als Fanboy gehabe auslegen könnte. Aber es ist nunmal so, dass ich anfangs beide Bilder verwechselt hab, da das NV Bild so überscharf wirkt, wie man es normalerweise eher von ATi Karten gewohnt ist. Es sieht halt so aus, als würds in Bewegung ein bisschen flimmern.

Ich hab halt auch schon länger keinen vernünftigen BQ Vergleichstest gesehen*, an dem man festmachen könnte, woher die BQ unterschiede kommen. IIRC hat ja NV ATis LOD Optimierung auch übernommen. Vielleicht sind sie einfach nur ein bisschen übers Ziel hinausgeschossen. ATis brilinearer Filter arbeitet ja auch "sanfter", wenngleich man ihn halt nicht deaktvieren kann. Ich würde mich anhand die beiden Bilder jedoch hüten irgendeinem IHV "die bessere BQ" zuzuschreiben, da dass eher nach einem Treibersetting bedingten Unterschied aussieht, der mit der nächsten Treiberversion schon wieder weg sein könnte.



*würd ich aber wirklich gerne. Am besten alle Modi, von HP zu HQ, mit den jew. fps Unterschieden. Dann wüsste man auch gleich, ob bei NV auch endlich die High Performance Modi etwas taugen. Denn bisher fuhr man ja besser, einfach bei HQ einen niedrigerenA F Grad zu nehmen (propagierte aths zumindest immer), aber das ist ja schon wieder enorm OT, eigentlich....

[Xmas]

Ich finde die Wand rechts bei der 6800 leicht schärfer, die Wand links (rechts vom farbigen Glas) bei der X800. Aber ein echter Vergleich ist das bei unterschiedlichen Blickwinkeln nicht.

[LovesuckZ]

*würd ich aber wirklich gerne. Am besten alle Modi, von HP zu HQ, mit den jew. fps Unterschieden. Dann wüsste man auch gleich, ob bei NV auch endlich die High Performance Modi etwas taugen. Denn bisher fuhr man ja besser, einfach bei HQ einen niedrigerenA F Grad zu nehmen (propagierte aths zumindest immer), aber das ist ja schon wieder enorm OT, eigentlich....

Wenn HP etwas "taugen" sollte, dann sollte man gleich "Performance" oder "Quality" nehmen.
Denn es heißt "High performance", da hat "Bildqualitaet" nichts verloren.

[Mr. Lolman]

Wenn HP etwas "taugen" sollte, dann sollte man gleich "Performance" oder "Quality" nehmen.
Denn es heißt "High performance", da hat "Bildqualitaet" nichts verloren.


Stimmt eigentlich. Nur bei Ati ists halt so, dass man bei Performance (ist der schnellste Modus, so wie HP bei NV), zwar nur reines bi-AF hat, dafür ists halt schön (über)scharf. Wenn jetzt ein Spiel aufgrund des Texturcontents nicht (unbedingt) mehr als bi-AF braucht, hat man halt schnelles scharfes (bi)AF. Natürlich muss man Anmerken, dass dessen Nutzbarkeit durch Bump-/Specularmaps immer geringer wird.

Bei den alten NV Modi (auf den FXen) wars dafür so, dass die Performance Modi zwar schneller, dafür aber auch bei hohen AF Stufen unscharf waren. Somit hat aths ganz recht, wenn er meint, dass man idF besser in einen niedrigen AF Modus bei HQ wechselt.Wär mal sehr interessant, wie die Performance Modi auf NV Karten jetzt aussehen. Denn momentan sind die NV40 Geschosse zwar verdammt flott, aber das war meine Radeon 9700pro vor 2 Jahren auch. Jetzt (eigentlich schon länger, aber man merkts immer stärker) bin ich ganz froh einen schnellen Performance AF Modus zu aben, der nicht sinnfrei ist, weil man die BQ auch mit niedrigerem tri-AF erreichen könnte.

2xtriAF ist mir halt zu wenig. Wenn die Texturen nicht zum Großeil scharfkontrastig sind, spiel ich eigentlich lieber mit 4xbiAF (Farcry, Xpand Rally Demo)
Bei Spielen mit hochfrequentem Inhalt ist triAF natürlich ein muss. (Doom3 z.B., da verzicht ich auch aufs AA, damit ichs in der nativen Auflösung meines TFTs -1280- noch spielen kann.)

[mbee]

Hab' ich was an den Augen?
Was soll an dem zweiten Bild (davon abgesehen, dass die Shots eh zeitlich versetzt sind) besser sein?

[MikBach]

Hab' ich was an den Augen?
Was soll an dem zweiten Bild (davon abgesehen, dass die Shots eh zeitlich versetzt sind) besser sein?
Nein, du hast sicherlich nichts an den Augen. Da die BQ sehr subjektiv ist, darfst du dich nicht über solche Aussagen wundern. Jeder sieht es halt bisschen anders.

[winter]

Mbee: Das kann man nur mit einem perfekt scharfen Monitor (und das sind nuneinmal die meisten TFTs) erkennen, also ist der Unterschied praktisch irrelevant. Allerdings kostet er Nvidia zwangsweise etwas Performance gegenüber ATI, was ein Nachteil zumindest in Benchmarks sein dürfte.

Der Nvidia High-Performance Modus aktiviert übrigens nur die Sample-Optimisations, nicht aber den "brilinearen" Filter (Der inzwischen allerdings ehr wie ein Bilinearer Filter aussieht, die Übergänge haben fast keine Breite mehr). Jedenfalls ist das bei mir so.

[ironMonkey]

Ich hab nen mittelklasse CRT und erkenne auch die Unterschiede, alzu klein sind die nicht, besonderst an dem roten Etwas sind die Unterschiede etwas größer, die Wand sieht bei NV schärfer/näher am User aus und genau hier ist das Problem, die Bilder wurden aus unterschiedlichen Positionen gemacht.........Problem ist auch das sich das rote Etwas ja immer verändert.......an sich kann man sich keine blödere Stelle aussuchen um einen Vergleich zu machen.



Gruß

[mbee]

Mbee: Das kann man nur mit einem perfekt scharfen Monitor (und das sind nuneinmal die meisten TFTs) erkennen, also ist der Unterschied praktisch irrelevant. Allerdings kostet er Nvidia zwangsweise etwas Performance gegenüber ATI, was ein Nachteil zumindest in Benchmarks sein dürfte.

Der Nvidia High-Performance Modus aktiviert übrigens nur die Sample-Optimisations, nicht aber den "brilinearen" Filter (Der inzwischen allerdings ehr wie ein Bilinearer Filter aussieht, die Übergänge haben fast keine Breite mehr). Jedenfalls ist das bei mir so.

Öhh, ich habe hier einen NEC 2080UX+ TFT (1600x1200), der wohl scharf genug sein dürfte und Brillenträger bin ich auch nicht :biggrin:

Gut, das ganze ist wirklich sehr subjetiv, vor allem, da die shots aus verschiedenen Bildwinkeln aufgenommen sind.
Man könnte auch diesem Vergleich glauben schenken:
http://www.pcper.com/article.php?aid=67&type=expert&pid=4

Da meint der Autor, es würde auf ATI-Karten leicht besser aussehen. Naja, mich juckt das eh nicht. Die "Unterschiede" sind IMHO mehr als marginal.

[Quasar]

Für einen BQ-Vergleich braucht man schon wirklich identische Winkel - gerade durch das viele BM ändert ein leicht andere Blickwinkel schon deutlich mehr als früher.

[deekey777]

Firing Squad einen weiteren Artikel (http://www.firingsquad.com/hardware/geforce_fx_half-life2/) zum Thema FX&DX9 in Half-Life 2/VST bzw. CSS. Diesmal wurde mit dem -dxlevel 90* Befehl getestet, womit mit Gewissheit auch DX9.0 in CSS/VST bekommt.


* Rechtsklick auf CSS -> Properties -> Launch Options und den Befehl eingeben.

[r@h]

Firing Squad einen weiteren Artikel (http://www.firingsquad.com/hardware/geforce_fx_half-life2/) zum Thema FX&DX9 in Half-Life 2/VST bzw. CSS. Diesmal wurde mit dem -dxlevel 90* Befehl getestet, womit mit Gewissheit auch DX9.0 in CSS/VST bekommt.Nicht so ganz...
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=2195277&postcount=45

Razor

[deekey777]

Nicht so ganz...
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=2195277&postcount=45

Razor


Hast du auch "normal" versucht, -dxlevel 80/81/90 einzugeben?

Ich hab kurz nach dem CSS beta Release mit den Befehlen (9800Pro) rumgespielt - ohne Probleme.

[r@h]

Hast du auch "normal" versucht, -dxlevel 80/81/90 einzugeben?Jo... klar.

Ich hab kurz nach dem CSS beta Release mit den Befehlen (9800Pro) rumgespielt - ohne Probleme.Nun ja, wäre ich der einzige gewesen, der diese 'Probleme' hat, wäre ich ja zumindest nachdenklich geworden... aber schau' Dir doch einfach nochmal den von Dir verlinkten Artikel (http://www.firingsquad.com/hardware/geforce_fx_half-life2/) an...
:D

http://www.firingsquad.com/hardware/geforce_fx_half-life2/images/12-s.png (http://www.firingsquad.com/hardware/geforce_fx_half-life2/images/12.png)
Where did the water go?

Razor

[Demirug]

Da ich jetzt auch CS:S habe kann ich bestätigen

KEIN WASSER MIT DX9

[deekey777]

Jo... klar.

Nun ja, wäre ich der einzige gewesen, der diese 'Probleme' hat, wäre ich ja zumindest nachdenklich geworden...
Razor


Ich war so gespannt auf die Ergebnisse, dass ich auf die Screenshots bzw. Text gar nicht geschaut hatte. :redface:

[r@h]

Ich war so gespannt auf die Ergebnisse, dass ich auf die Screenshots bzw. Text gar nicht geschaut hatte. :redface:Bei mir war es eher anders herum.
Die 'Ergebnisse' dieser beta-Engine gingen mir reichlich am Ar... vorbei, aber die Bildvergleiche interessierten mich brennend.

Razor