HL2 NV35 FP16 vs. FP32

[Demirug]

Hier mal ein Vergleichsbild. Ist exakt der gleiche Frame:

http://www.picsplace.to/044932/Shot1S.png (http://www.picsplace.to/044932/Shot1.png)

http://www.picsplace.to/044932/Shot2S.png (http://www.picsplace.to/044932/Shot2.png)


Und es ist wirklich der gleiche Frame:

http://www.picsplace.to/044932/PlayerS.png (http://www.picsplace.to/044932/Player.png)



/Note: oberes Bild: FP32, unteres Bild: FP16

[urbi]

0p71m1z3d! :>

Ist wirklich der Hammer diese Optimierungswut. Naja ohne läufts halt nicht so gut, aber ich finde es trotzdem irgendwie unfair.

Die FPS waren ergo an der Stelle auch mehr oder weniger identisch?

[Mr. Lolman]

Naja, da hat ja Valve NV gehörig in den Arsch getreten.

[Gast]

Außer der kleinen "Verschiebung" des Wassers gibt es keine Unterschiede. Gibt es vielleicht andere Shader, bei denen der Unterschied zwischen FP16 zu FP32
deutlicher zu erkennen ist?
Sieht ATI FP24 eher wie FP16 oder eher wie FP32 aus?

gast

[Lightning]

Sollen wir jetzt raten, welches Bild FP16 und welches FP32 ist? ;)
Den (kleinen) Unterschied kann man zwar erkennen, aber ich als Laie kann ehrlichgesagt nicht sagen, welches wirklich der gewünschte Effekt war.


0p71m1z3d! :>

Ist wirklich der Hammer diese Optimierungswut. Naja ohne läufts halt nicht so gut, aber ich finde es trotzdem irgendwie unfair.

Die FPS waren ergo an der Stelle auch mehr oder weniger identisch?

?
Sry, ich versteh nicht ganz, was du meinst.. Die fps dürften sich schon eindeutig unterscheiden, nach dem, was ich bis jetzt gehört habe.

[Iceman346]

Sollen wir jetzt raten, welches Bild FP16 und welches FP32 ist? ;)
Den (kleinen) Unterschied kann man zwar erkennen, aber ich als Laie kann ehrlichgesagt nicht sagen, welches wirklich der gewünschte Effekt war.


Jepp, beim hin und herschalten sieht man, dass das Wasser leicht anders aussieht. Aber welcher Shot der Richtige ist und was "besser" aussieht kann ich daran bei leibe nicht erkennen, dafür ist der Unterschied zu gering.

[Gast]

[QUOTE=Lightning]Sollen wir jetzt raten, welches Bild FP16 und welches FP32 ist? ;)

Der Zweite Screenshot ist FP32. Sieht man an dem weißem Strich am Pier. (IMHO)

Gast

[hmx]

Welches ist denn nun FP16? Der erste (wegen dem Titel: FP16 vs FP32)?

[Gast]

super gemacht Valve, ihr habts echt drauf für die gezahlten ati-$$$ einen angemessenen gegenwert zu liefern *kotz*
ich rufe hier ale FX besitzer auf das spiel zu boykottieren sonlange bis ein DX9 FP16 patch offiziel erscheint.

[Demirug]

Ich habe extra etwas mit Wasser genommen weil man wie am Pier sonst oft gar nichts sieht.

Die FPS für die Stelle habe ich nicht weil um genau den gleichen Frame zu bekommen musste ich die Shader extern auf PP zwingen. Dafür ist das Programm aus dem 3 Shot da.

[Godmode]

Ja die Bilder sind definitiv gleich, aber wie schauts mit den FPS aus?

[Mr. Lolman]

super gemacht Valve, ihr habts echt drauf für die gezahlten ati-$$$ einen angemessenen gegenwert zu liefern *kotz*
ich rufe hier ale FX besitzer auf das spiel zu boykottieren sonlange bis ein DX9 FP16 patch offiziel erscheint.

Der kommt IMO nicht. NV wird noch ein paar Treiberoptmierungen einbauen, und Demi irgendwann sein Tool releasen.

[Gast]

Mich würde es eher interessieren, ob der PF16 Pfad auch dem NV40 zu sehr guten Performancesprünge verhilft.

Gast

[Gast]

Ja die Bilder sind definitiv gleich, aber wie schauts mit den FPS aus?
Wo sind denn die Bilder gleich?
Sieh dir ganz genau das Wasser an. Schalte mal hin und her zwischen den beiden Bildern. Auf einem ist das Wasser besser. Falls Demi nicht aufklärt welches Bild nun FP16 und welches FP32 ist, werde ich es euch sagen. ;)

[Demirug]

Mich würde es eher interessieren, ob der PF16 Pfad auch dem NV40 zu sehr guten Performancesprünge verhilft.

Gast

Bei meinen bisherigen Tests eher nicht. Ich könnte dabei aber am CPU limit gewesen sein. Muss mal mit SSAA laufen lassen sobald der NV40 wieder im rechner ist.

[reunion]

Wo sind denn die Bilder gleich?
Sieh dir ganz genau das Wasser an. Schalte mal hin und her zwischen den beiden Bildern. Auf einem ist das Wasser besser. Falls Demi nicht aufklärt welches Bild nun FP16 und welches FP32 ist, werde ich es euch sagen. ;)

ACK, es gibt einen (wenn auch kleinen) Unterschied IMO sieht das erste Bild besser aus oder besser gesagt es gefällt mir besser da das Wasser "klarer" dargestellt ist.

//Edit: Hab mir die Bilder jetzt nochmal ganz genau angesehen, war wohl vorher nur einbildung kann jetzt keinen Unterschied mehr erkennen.

[Godmode]

ok dann seh ich mir die Bilder nochmal an, und versuche ob ich die bessere Version erkennen kann.

[Godmode]

hab die Bilder jetzt nochmal angesehen

sie sind zwar nicht gleich(irgendwie schauts aus wie wenns beim 2. etwas verschoben wäre) aber schlechter/besser könnte ich nicht sagen.

[Gast]

sie sind zwar nicht gleich(irgendwie schauts aus wie wenns beim 2. etwas verschoben wäre) aber schlechter/besser könnte ich nicht sagen.
Diese Verschiebung resultiert aus der geringeren Rechengenauigkeit.

@reunion

die Bilder sind nicht gleich.

[Demirug]

PS: wenn ich dazu kommen gibt es morgen noch einen Shot mit "Intelliprecision".

[reunion]

Diese Verschiebung resultiert aus der geringeren Rechengenauigkeit.


Wie das?


@reunion

die Bilder sind nicht gleich.

Welches Bild ist denn deinermeinung nach FP32?

[seahawk]

Außer die Verschiebung wird im Shader durch einen Zufallsfaktor erreicht. Ich sehe keine relevanten Unterschied in Qualität.

[Gast]

Welches Bild ist denn deinermeinung nach FP32?
Das untere.

[Demirug]

Außer die Verschiebung wird im Shader durch einen Zufallsfaktor erreicht. Ich sehe keine relevanten Unterschied in Qualität.

Nein, da ist kein Zufall im Spiel. Ich kann die beiden Bilder jederzeit wieder reproduzieren (bis ich die 2 GB Daten von der Platte werfe).

[seahawk]

Ok danke. Ich habe aber auch nie ein Verscheibung bemerkt. Für mich sind die Bilder gleich gut. Auch wenn ich nicht unbedingt pixelgleich sagen würde. Ein Verlust an BQ ist für mich nicht erkennbar.
Wie sieht dann eigentlich ein FP24 Bild im Vergleich aus ??

[LovesuckZ]

PS: wenn ich dazu kommen gibt es morgen noch einen Shot mit "Intelliprecision".

dynamische Anpassung der Genauigkeit?

[Gast]

@ reunion und seahawk

Den Unterschied kann man auf Screenshots nur sehr bedingt feststellen. In Bewegung sieht man die bessere Bildqualität. :)

[Demirug]

dynamische Anpassung der Genauigkeit?

Nein, selektives setzen von PP Flags innerhalb eines Shaders entsprechend der weiteren Verwendung der Rechenwerte.

[Gast]

Nein, selektives setzen von PP Flags innerhalb eines Shaders entsprechend der weiteren Verwendung der Rechenwerte.
Wie kann der Compiler entscheiden welche Effekte bzw. Shader pp_hints zulassen, damit die BQ nicht negativ beeinflußt wird?

[Godmode]

@ reunion und seahawk

Den Unterschied kann man auf Screenshots nur sehr bedingt feststellen. In Bewegung sieht man die bessere Bildqualität. :)

von wo weist du das?

[Lightning]

von wo weist du das?

Eben. Möglich wäre es zwar, aber das zu belegen wird nicht so einfach.

[Demirug]

Wie kann der Compiler entscheiden welche Effekte bzw. Shader pp_hints zulassen, damit die BQ nicht negativ beeinflußt wird?

PP Hints werden nicht pro Shader sondern pro Shaderanweisung gesetzt. Aufgrund der weiteren Verwendung des Ergebnisses einer Berechnung kann man recht gut abschätzen ob PP ausreicht. Es ist natürlich nicht 100% perfekt aber besser als einfach stur durchgängig alles auf FP16 zu zwingen.

[LovesuckZ]

Wie kann der Compiler entscheiden welche Effekte bzw. Shader pp_hints zulassen, damit die BQ nicht negativ beeinflußt wird?

Garnicht, denn dafür müsste er denken koennen.
Demi meinte es wohl eher so, dass er auch die Shader so "umgeschrieben hat", dass jetzt ein "wirklicher" Mixed-Mode entstanden ist mit unterschiedlichen Genauigkeiten.

[Jesus]

kann es sein das auf beiden Bildern dieser DX9 Smoother Shader Effekt fehlt bei dem das Wasser weich ins Ufer übergeht ? Diese scharfe Kante wie man sie auf beiden Bildern sieht ist mir bisher eigentlich nur im DX8 Modus aufgefallen...

[Tesseract]

im 2. bild hat der vorletze pfeiler vom steg einen hellen pixel in der spiegelung, der dort nicht hingehört. von dem her würde ich mal sagen #2 ist FP16. dagegen spricht aber der helle streifen im hintergrund.
imho sehr schwer zu sagen. das wasser ist als ganzes deutlich anders. aber ob besser oder schlechter...

[kmf]

Naja, da hat ja Valve NV gehörig in den Arsch getreten.

Nö, allen FX-Besitzern. Und dazu gehöre auch ich. :mad:

@Demi

Wäre das nicht etwas für deinen Tweaker? Wenn nicht, mit dem 3DAnalyzer Version 2.26 klappts ja auch ganz gut.

[saaya]

cool! gute arbeit demirug!

sehr interessant... hast du schon andere shader getestet?

[Gast]

ich muss sagen, dass sich sowas echt arm finde von Valve.
Wenn es darum geht Geld zu bekommen um für einen IHV Marketing und Werbung zu betreiben und für ihn zu optimieren, dann lass ich mir das noch eingehen.
Wenn es dann aber soweit führt, dass das Geld auch dazu genutzt wird bzw. dazu führt bestimmte Produkte eines IHVs bzw. die Käufer dieser Produkte absichtlich zu benachteiligen, dann finde ich geht das irgendwo zu weit.

Es hätte ATI 0,0 geschadet, wenn man hier pp_hints bei den Shadern eingesetzt hätte, wo eine höhere Qualität nicht notwendig ist. Der R3xx wäre dadurch nicht langsamer geworden und Qualität hätte er auch keinen Millimeter verloren, da er eh alles mit FP24 rendert.

Wenn nun aber Shader überhaupt keinen Nutzen aus einer größeren GEnauigkeit als FP16 ziehen, dann finde ich es einfach nur noch arm, wenn man absichtlich diese Usergruppe derartig benachteiligt.
Eine solche Vorgehensweise kann man imho ID bzw. John Carmack nicht nachsagen.
Die verlangen vielleicht nach einer bestimmten Technik, die Nvidia dann einfach in ihre Produkte eingebaut hat aber trozdem bekommt ATI einen für ihre Produkte optimalen Pfad.

Für mich ist Valve hier eindeutig zu weit gegangen. Ich habe keine FX Karte sondern eine GF68xx und mich betrifft es daher nur am Rande aber sowas finde ich einfach total mies. Vor allem muss man ja bei der moralischen Bewertung auch noch den ganzen PR Krieg von Valve mit einbeziehen.
Da gab es mal Dinge wie:
- bei Nvidia funktioniert AA nicht richtig
- Wir brauchen einen Aufwand von einem Faktor 5 um für die FXen zu optimieren. (war ne kleine Nebenentschuldigung für die Verspätung des Games)
- ATIs Produkte sind 40% schneller als die von Nvidia (das kam zum NV40/R4xx Launch)
- der fertige FX Pfad war schonmal im Einsatz und eigentlich fertig
usw....

Irgendwie stinkt alles bei diesem Game und bei Valves Methoden bis zum Himmel. Da ist doch nichts so gelaufen wie es laufen sollte.
Das ist absolut unterste Schublade und grenzt schon an Prostitution oder Söldnertum. Die verkaufen sich mit Mann, Maus und Seele.
Das ist echt arm.
Auch GF6800 Nutzer würden, wenn auch nur wenig, von pp_hints profitieren. Wird sicher nicht mehr lange dauern, bis es hier die ersten Lösungsmöglichkeiten gibt, die einfach und für jeden verständlich anzuwenden sind.

[Formica]

aber doom 3 war in ordnung oder wie... typisch

[san.salvador]

HL2 läuft aber sowohl auf ATI als auch auf Nvidia absolut zufriedenstellend, das ist doch schon viel wert.

[BUG]

HL2 läuft aber sowohl auf ATI als auch auf Nvidia absolut zufriedenstellend, das ist doch schon viel wert...aber nicht auf den FXen, jedenfals nicht, wenn man im Spiel DX9 erzwingt, default mäßig laufen die FX Karten bei HL2 nur mit DX8.1 da is die Leistung allerdings ok.

cu
BUG

[Demirug]

- nVidia darf im Treiber keine PP Flags mehr erzwingen. Der entsprechenden Abschnitt in der DX Spec der das erlaubt hätte wurde entfernt und durch einen anderen ersetzt. Deswegen steht in den Guides auch explizit das der Shadercompiler die Rechengenauigkeit nicht verändert.

- Die Source engine als solches hat eigentlich ein sehr flexibles Shadermanagement. Es ist also weniger die Engine den FXen nicht schmeckt sondern eher die Art wie sie von Valve konfiguriert wurde. Leider kann man diese Konfiguration von extern nicht so leicht ändern.

- Die PP Flags sind ja nur ein Quickhack. Ich gehe mal davon aus das an vielen Stellen ein 1.X Shader genau das gleiche Bild erzeugt hätte. Ich prüfe das allerdings noch mal nach.

- Der D3 Patch von ATI ist so ziemlich das schlammpigste Stück arbeit das ich in diesem Bereich gesehen habe.

[del_4901]

Kann es sein das der 81er HL2 Path, mehr passes verschlingt als der 90er? Ich hatte so das Gefühl das es mit dem 90er viel viel besser lief.

[Demirug]

Kann es sein das der 81er HL2 Path, mehr passes verschlingt als der 90er? Ich hatte so das Gefühl das es mit dem 90er viel viel besser lief.

Welcher Chip?

Beim testen von dem Programm mit dem ich auch die vergleichsbilder gemacht habe ist mir aufgefallen das beim 8.1 Pfad viel mit Multipass gemacht wird. Ich habe mir allerdings den 9.0 Pfad im Vergleich dazu nicht angeschaut.

[Tjell]

Imo kann die PP Flags in HL², die Demis Tool setzt, genauso NV mit einem Treiber hinbiegen (Ich bin mir relativ sicher, dass FC1.0 ohne Demis Tool auf FX Karten mittlerweile kaum schlechter rennt, als mit ihm)...Ich weiß aber jetzt schon, wenn es denn so käme, was wieder geschrien würde: "Cheat".

MbMn hat bei Doom3 einzig und allein NV schon zu einem frühen Zeitpunkt das gemacht, was ATI nachgeholt hat: Shaderreplacement. Wie kannst Du das aber mit fehlenden Setzen von _PP-Flags bei HL2 vergleichen, die keine BQ kosten, dafür aber höhere FPS bringen?

[del_4901]

Welcher Chip?

Beim testen von dem Programm mit dem ich auch die vergleichsbilder gemacht habe ist mir aufgefallen das beim 8.1 Pfad viel mit Multipass gemacht wird. Ich habe mir allerdings den 9.0 Pfad im Vergleich dazu nicht angeschaut.

also ich hab nen NV35. Der wird ja auf 81er gezwungen. Damit ich überhaupt Spielen konnte musste ich Polycount auf LOW und BilinearFiltering einstellen. Eine Vermutung von mir war, das Multipassrendering die Füllrate stark drückt.

Mit 3dAnalyze und 90er Pfad _pp Flags forced, hab ich alles auf High dazu noch 2xAA und 4xAF ... und trotzdem noch 50-90fps. Deswegen habe ich vermutet, das im 90er wenig Multipass betrieben wird.

[MegaManX4]

Wie hoch ist denn jetzt der Performance-Vorteil durch die FP16 Änderung?

[del_4901]

Wie hoch ist denn jetzt der Performance-Vorteil durch die FP16 Änderung?

HL2 ist spielbar geworden. :-) wenn man einen NV3x in den Händen hält.

[Mr. Lolman]

Naja, das kann man auch anders sehen. Im Gegendsatz zu einigen hier im Forum, die die Situation imo ein bissel schön reden: Ich finde HL2 sieht auf den FXen DEUTLICH schlechter aus, als auf den Atis. Nicht nur das Wasser, auch die Bumpmap Reflexionen auf Figuren und Gegenständen: All das sieht auf der FX irgendwie aus wie von Gestern (Ich hab in einem Rechner ne 9800pro, auf der ich HL2 auch spiele, hab aber auch den Vergleich auf der FX gesehen)

Ok. Ich wollt ja garnicht abstreiten, dass es tatsächlich optische Unterschiede gibt. Nur ist die oberste Priorität gute Spielbarkeit. (also ausreichende fps) Und da reichen 50% Mehrperformance durch PP nicht wirklich:
(in Anbetracht der viel besseren Spielbarkeit mit DX8.1)
http://common.ziffdavisinternet.com/util_get_image/8/0,1311,sz=1&i=85208,00.gif




Was das Handoptimieren angeht ist nVidia inzwischen gründlich die Lust vergangen. Das sind einfach zu viele Shader.

Gerade bei einem Zugpfred wie HL² glaub ich , dass die sich zumindest den Wassershader schon genauer ansehen...


Humus ist was ganz anderes da man da bewusst die Applikation verändert hat. ATI verändert aber das verhalten des Treibers. Das schlampig bezog sich nicht auf die Performances. Da kann schlampig sowieso oft schneller als sauer programmiert sein. Es geht eher darum das der Treiber massiv die OpenGL Norm durchbricht. Er hält es nämlich nicht mal für nötig zu prüfen ob die Texture überhaupt den richtigen Inhalt enthält.

Imo wird doch einfach der Specularshader gegen einen anderen ausgetauscht. Ist das bei NV nicht genauso geschehen?

Kann man nicht davon ausgehen, dass trotz der verminderten Flexibilität der Texturinhalt bei Doom3 bekannt, ist und das dementsprechend auch der Shader für diesen Spezialfall (Doom3) passt. Schlimm wärs nur, wenn ATi bei allen OpenGL spielen, die den Standardshader von Doom3 verwenden, diesen nun automatisch gegen den für D³ optmierten austauscht.

Oder ist was dich, stört, die Tatsache, dass man bei einem etwaigen D³ Mod (mit neuem Texturinhalt) dann auf Ati Karten automatisch den optmierten Shader verwendet, obwohl nichtmal gewährleistet ist, dass der noch auf den Texturinhalt passt?

Aber ehrlich gesagt: Wär die mögliche Abweichung vom gewünschten Ergebnis überhaupt im sichtbaren bereich?

Und wird von beiden IHVs nicht massiv die DX Norm durchprochen, wenn App Erkennungen aktiv sind, und dementsprechend das Filterverhalten angepasst wird?

[Mr. Lolman]

Und da reichen 50% Mehrperformance durch PP nicht wirklich:
(in Anbetracht der viel besseren Spielbarkeit mit DX8.1)


Klar, ist das spiel mit 40fps spielbar. Aber seid mal ehrlich. Wr das Geschrei nicht vie größer gewesen, wen Valve wirklich den optmierten DX9 Pfad verwendet hätte, und die Performance einer Fx5950 trotzdem noch leicht bis deutlich unter einer 9600XT liegen würde?

[del_4901]

Ok. Ich wollt ja garnicht abstreiten, dass es tatsächlich optische Unterschiede gibt. Nur ist die oberste Priorität gute Spielbarkeit. (also ausreichende fps) Und da reichen 50% Mehrperformance durch PP nicht wirklich:


Da kann ich als Besitzer eines NV35 aber nur das Gegenteil behaupten! Mit dem 90er Pfad und _pp ist es mehr als doppelt so schnell wie mit dem 81er.

[Mr. Lolman]

Da kann ich als Besitzer eines NV35 aber nur das Gegenteil behaupten! Mit dem 90er Pfad und _pp ist es mehr als doppelt so schnell wie mit dem 81er.

Komisch das Razor da was anderes rausbekommt:

Nämlich maximal +77%. Und selbst da sind die fps bei nur ~25avg.

http://www.forum-3dcenter.de/vbulletin/showthread.php?t=187549&page=2

Tut mir leid, dass kann ich ungesehen nun wirklich nicht glauben, sry ;(


/edit: Allein schon die Tatsache, dass auch ATis Performance beim DX90 Pfad verlieren, die Fxen beim Dx8.1 Pfad auch nur geringfügig langsamer sind als die ATis, während, beim Dx9 Pfad ne 9800XT 3.5x schneller ist als ne 5950Ultra, müsste die Performance durch pp min 400% höher sein, dass deine Aussage stimmt. Und das geht sich irgendwie nicht ganz aus...

[del_4901]

Klar, ist das spiel mit 40fps spielbar. Aber seid mal ehrlich. Wr das Geschrei nicht vie größer gewesen, wen Valve wirklich den optmierten DX9 Pfad verwendet hätte, und die Performance einer Fx5950 trotzdem noch leicht bis deutlich unter einer 9600XT liegen würde?

Mach dich nicht lächerlich, Mir ist es um gebnau zu sein Wurscht wieviel meine Karte langsamer ist als eine 9600. Ich will vernünftig Frames und geile Grafik, der 90er Pfad mit _pp gibt mir das! ... 50-90Frames sollten spielbar sein.
Vorher waren es 0.5-40!!!

[seahawk]

In
Hat schon jemand getestet. Die FXen verlieren damit Performance. Wenn du willst mail ich sie dir.

Aber nur die Lösung die den ATI KArten schmeckt. Es ist dirchaus wahrscheinlich, dass es eine ähnliche Annäherung auch für NV Karten gibt, die ein vergleichbare Ergebnis liefert. Ob NV diese schon nutzt oder nicht, dass kann ich nicht sagen, würde es aber vermuten.

[Tjell]

Klar, ist das spiel mit 40fps spielbar. Aber seid mal ehrlich. Wr das Geschrei nicht vie größer gewesen, wen Valve wirklich den optmierten DX9 Pfad verwendet hätte, und die Performance einer Fx5950 trotzdem noch leicht bis deutlich unter einer 9600XT liegen würde?Man hat eine DX9-Karte, die mit DX8.1 angesprochen wird, ist das optimal? Zumal mit _PP und DX9 bei besserer Optik eine mindestens gleich "hohe" Performance wie im DX8.1-Modus erreicht wird, wie hier im Forum zu lesen ist, meist sogar eine höhere.

[Godmode]

Man hat eine DX9-Karte, die mit DX8.1 angesprochen wird, ist das optimal? Zumal mit _PP und DX9 bei besserer Optik eine mindestens gleich "hohe" Performance wie im DX8.1-Modus erreicht wird, wie hier im Forum zu lesen ist, meist sogar eine höhere.

Also wenn das zutrifft, wär das echt eine Unverschämtheit von Valve. Kann das auch jemand anderer bestätigen?

[Mr. Lolman]

Zumal mit _PP und DX9 bei besserer Optik eine mindestens gleich "hohe" Performance wie im DX8.1-Modus erreicht wird, wie hier im Forum zu lesen ist, meist sogar eine höhere.

Imo Unmöglich!!!

[Mr. Lolman]

Aber nur die Lösung die den ATI KArten schmeckt. Es ist dirchaus wahrscheinlich, dass es eine ähnliche Annäherung auch für NV Karten gibt, die ein vergleichbare Ergebnis liefert. Ob NV diese schon nutzt oder nicht, dass kann ich nicht sagen, würde es aber vermuten.

...und da sind wir wieder bei dem Punkt, dass NV ihre Lösung einfach früher implementieren konnte/durfte, was dann, zu einem großen Teil, für die, für ATi, verhehrenden Benchmarkergebnisse ausschlaggebend war.

Mach dich nicht lächerlich, Mir ist es um gebnau zu sein Wurscht wieviel meine Karte langsamer ist als eine 9600. Ich will vernünftig Frames und geile Grafik, der 90er Pfad mit _pp gibt mir das! ... 50-90Frames sollten spielbar sein.
Vorher waren es 0.5-40!!!

Dir ist wurscht. Klar. Mir ists auch wurscht. Aber 10000 Fanboys würden Valve nochmehr in den Dreck ziehen als es jetzt ohnehin schon der Fall ist.
(Obwohl so eine Drecksfirma das eigentlich auch verdient hätte)

Mal abgesehen von den Leuten die sich im Nachhinein vll. ärgern dass sie 500€ für eine Karte abgedrückt haben, die dann von einem 200€ Teil verputzt wird.

[seahawk]

Was sie jetzt aber ausgegleichen haben. So gesehen behandelt DOOMIII beide Karten gleich.

HL2 hingegen benachteiligt FX Karten.

[Mr. Lolman]

Was sie jetzt aber ausgegleichen haben. So gesehen behandelt DOOMIII beide Karten gleich.

HL2 hingegen benachteiligt FX Karten.

Kommt Zeit, kommt Rat. Oder: Die Zeit heilt alle Wunden. :D

[Demirug]

Gerade bei einem Zugpfred wie HL² glaub ich , dass die sich zumindest den Wassershader schon genauer ansehen...

Es gibt nicht den Wassershader. Das sind mindestens 96 Stück.

Imo wird doch einfach der Specularshader gegen einen anderen ausgetauscht. Ist das bei NV nicht genauso geschehen?

Kann man nicht davon ausgehen, dass trotz der verminderten Flexibilität der Texturinhalt bei Doom3 bekannt, ist und das dementsprechend auch der Shader für diesen Spezialfall (Doom3) passt. Schlimm wärs nur, wenn ATi bei allen OpenGL spielen, die den Standardshader von Doom3 verwenden, diesen nun automatisch gegen den für D³ optmierten austauscht.

Oder ist was dich, stört, die Tatsache, dass man bei einem etwaigen D³ Mod (mit neuem Texturinhalt) dann auf Ati Karten automatisch den optmierten Shader verwendet, obwohl nichtmal gewährleistet ist, dass der noch auf den Texturinhalt passt?

Ja, nVidia hat den auch bearbeitet scheint aber soweit ich das überprüfen konnte den Inhalt der Textur zu berücksichtigen.

Letzteres könnte in diesem Zusammenhang zum Problem werden.

Aber ehrlich gesagt: Wär die mögliche Abweichung vom gewünschten Ergebnis überhaupt im sichtbaren bereich?

Hängt davon ab wie man die Textur verändert. Man kann es durchaus in den sichbaren Bereich bringen.

Und wird von beiden IHVs nicht massiv die DX Norm durchprochen, wenn App Erkennungen aktiv sind, und dementsprechend das Filterverhalten angepasst wird?

Filter sind bei DX mehr als lausig genormt. Da kann man viel machen bevor die Norm durchbrochen wird.

[reunion]

Man hat eine DX9-Karte, die mit DX8.1 angesprochen wird, ist das optimal? Zumal mit _PP und DX9 bei besserer Optik eine mindestens gleich "hohe" Performance wie im DX8.1-Modus erreicht wird, wie hier im Forum zu lesen ist, meist sogar eine höhere.

Sorry, but thats impossible.

Ein NV35 kann es im DX9 Modus gerademal mit einer X300SE(!) aufnehmen, im DX8.1 Modus liegt er beinahe gleichauf mit dem R350, durch reduzierung der genauigkeit auf FP16 wird man niemals einen solchen Performancesprung erreichen.

//EDIT:
http://www.anandtech.com/video/showdoc.aspx?i=2281&p=4

[Tjell]

Also wenn das zutrifft, wär das echt eine Unverschämtheit von Valve. Kann das auch jemand anderer bestätigen?Fragt die Leute, die hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=187549) Entsprechendes posten.

Wenn es einen ""Special Mix Mode for NV3x" für Nvidia-Boards" gab (wie beispielhaft bei Chip Online (http://www.chip.de/news/c_news_10904768.html?tid1=9226&tid2=0) zu lesen war), warum ist dieser entfernt worden?

[Demirug]

Imo Unmöglich!!!

Nicht zwingend. Es liegt ihm Rahmen des Wahrscheinlichen das der DX9 Modus weniger CPU limitiert ist als der DX8 Modus. Wer also bei DX8 Probleme mit seiner CPU hat bei dem könnte es an einigen Stellen mit nicht ganz so aufwendigen Shadern im DX9 Modus sogar schneller sein.

[Mr. Lolman]

Fragt die Leute, die hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=187549) Entsprechendes posten.

Das sind die gleichen Leute die mir auf meinem Sys eine Spielbarkeit von Farcry mit 1152x864 4xAA/biAF absprechen wollten, und dann behauptet haben, das FC mit Tommtis fp16 plötzlich wunderbar in 1024x768 noAA/AF max Details spielbar ist. Und das obwohl die fps ziemlich genau gleich sind.

(Ich hab FC mit 1024x768 4xAA/biAF und div. optikfördernden Tweaks gespielt, das 1152x864 Beispiel hab ich schon damals nur gebracht, weil die fps ziemlich ähnlich waren, und logischerweise eine ungetweakte config für bessere vglbarkeit sorgt :))

[Mr. Lolman]

Es gibt nicht den Wassershader. Das sind mindestens 96 Stück.

Die jagt man durch den compiler, und die jenigen die immernoch schlecht performen, kann man ja handoptmieren...


Hängt davon ab wie man die Textur verändert. Man kann es durchaus in den sichbaren Bereich bringen.

Momentan alles das aber alles theoretisch. Und wenns mal wirklich soweit kommt, muß Ati wohl oder übel nen neuen optimierten Shader nachschieben.


Filter sind bei DX mehr als lausig genormt. Da kann man viel machen bevor die Norm durchbrochen wird.

Auch Erkennungsroutinen für Filtertestprogramme einbauen, und dann dort besser filtern als es eigentlich normalerweise geschieht?

Nicht zwingend. Es liegt ihm Rahmen des Wahrscheinlichen das der DX9 Modus weniger CPU limitiert ist als der DX8 Modus. Wer also bei DX8 Probleme mit seiner CPU hat bei dem könnte es an einigen Stellen mit nicht ganz so aufwendigen Shadern im DX9 Modus sogar schneller sein.


Jetzt stellt sich nurmehr die Frage, wieweit im Falle KEINER CPU Limiterung die Dx9 Performance an die DX8 Performance kommt, und wieviel Prozent an Performance DX8 vgl zu DX9 im Falle EINER CPU Limtierung kommt.

[del_4901]

Besonders drastisch sieht man das an den "Feuer Shadern" das drückt so derb.

CPU Limitierung??? mein kleiner P4 3,2Ghz ist nicht limitiert. :-) Den kann man man immernoch kaufen.

[Demirug]

Die jagt man durch den compiler, und die jenigen die immernoch schlecht performen, kann man ja handoptmieren...

Und warum dann nicht gleich den Compiler verbessern? Am Anfang hat nVidia Shader getauscht weil sie ja gar nichts hatten um die für sie ungünstigen 2.0 Shader umzusetzten. Inzwischen ist der Compiler ganz brauchbar aber sicherlich nicht perfekt. Wenn man also erkennt das da was nicht passt verbessert man das vorhandene. Gerade weil sich die Shader ja alle ähnlich sind ist ein allgemeiner Ansatz besser als jeden von Hand anzufassen.

Auch Erkennungsroutinen für Filtertestprogramme einbauen, und dann dort besser filtern als es eigentlich normalerweise geschieht?

Die DX-Norm hat gegen sowas nichts.

[Demirug]

Besonders drastisch sieht man das an den "Feuer Shadern" das drückt so derb.

CPU Limitierung??? mein kleiner P4 3,2Ghz ist nicht limitiert. :-) Den kann man man immernoch kaufen.

Irgendwas muss da bremsen wenn DX9 plötzlich schneller als DX8.1 ist. Bei der Grafikkarte kann es höchstens noch die Bandbreite sein. Die wird durch Multipass ja auch belastet.

[del_4901]

Irgendwas muss da bremsen wenn DX9 plötzlich schneller als DX8.1 ist. Bei der Grafikkarte kann es höchstens noch die Bandbreite sein. Die wird durch Multipass ja auch belastet.
Zerhacke ich nicht pro Pass auch die Füllrate? Ich muss ja pro pass mehr Polygone füllen.

[Demirug]

Jetzt stellt sich nurmehr die Frage, wieweit im Falle KEINER CPU Limiterung die Dx9 Performance an die DX8 Performance kommt, und wieviel Prozent an Performance DX8 vgl zu DX9 im Falle EINER CPU Limtierung kommt.

Auf diese Frage gibt es aber keine allgemeine Antwort da sich die Lasten ja ständig verschieben.

Das die FXen in der Regel im DX8 Modus schneller sein werden als im DX9 Modus wird ja auch niemand bestreiten. Das es auch Ausnahmen gibt liegt in der Natur der Sache.

[Demirug]

Zerhacke ich nicht pro Pass auch die Füllrate? Ich muss ja pro pass mehr Polygone füllen.

Nur wenn in den Passes mehrmal die gleiche Texture eingeladen wird. Das ist ja zum Beispiel bei Farcry der Fall. In wie weit das bei HL2 zum tragen kommt müsste man sich mal anschauen.

[r@w]

Wie hoch ist denn jetzt der Performance-Vorteil durch die FP16 Änderung?50-80%

Und dass ausschließlich durch die Nutzung von fp16 statt fp32. Wenn man sich dann noch vor Augen hält, wie sich das darstellt, wenn erst einmal die Shader bzw. die Engine an sich auf die FX'en getuned werden...

...100% und weit mehr!

Razor

[del_4901]

Nur wenn in den Passes mehrmal die gleiche Texture eingeladen wird. Das ist ja zum Beispiel bei Farcry der Fall. In wie weit das bei HL2 zum tragen kommt müsste man sich mal anschauen.

Naja ich für jeden Compositing Schritt fällt ja auch noch ein Lookup an. Wenn ich mir durch einen pass das Compositing spaaren kann, fällt das schon ins Gewicht.

[r@w]

Komisch das Razor da was anderes rausbekommt:
Nämlich maximal +77%. Und selbst da sind die fps bei nur ~25avg.
http://www.forum-3dcenter.de/vbulletin/showthread.php?t=187549&page=2
Tut mir leid, dass kann ich ungesehen nun wirklich nicht glauben, sry ;(Maximale Details, AA/AF aktiviert und selbstredend noch den 3DA im Hintergrund... ja.

Razor

[Demirug]

Naja ich für jeden Compositing Schritt fällt ja auch noch ein Lookup an. Wenn ich mir durch einen pass das Compositing spaaren kann, fällt das schon ins Gewicht.

Das Compositing machen dabei normalerweise die ROPs. Das geht nur auf die Bandbreite.

[Mr. Lolman]

Maximale Details, AA/AF aktiviert und selbstredend noch den 3DA im Hintergrund... ja.

Razor

Trotzdem reichen erst weit über 300% damit die FXen auf R3x0 Niveau kommen.

Wenn du willst kram ich mal ein paar andere erbärmliche FX Ergebnisse von Spielen hervor, wo man sich ziemlich sicher sein kann, dass kein IHV Kohle für besondere OPtimerungen abgedrückt hat...

[Demirug]

Nö, aber JC hat die GraKaentwicklung seit dem Anfang der 3dGrafikkarten massgeblich mitbestimmt. Wenns jemand ausser ATi selbst wissen konnte, dann er. Außerdem wars den Gurus vom 3DC auch ziemlich schnell klar wo das Problem liegt...

Es ist eines einen Trick zu durchschauen aber was anderes diesen zu finden. Ist wie mit dem Ei des Kolumbus.

ATI hat leider keinen schönen Tools für die Shaderentwicklung die einen auf sowas aufmerksam machen.

[Exxtreme]

ATI hat leider keinen schönen Tools für die Shaderentwicklung die einen auf sowas aufmerksam machen.
Naja, trotzdem hätte J.C. den Dev-Support anmailen und mehr Infos anfordern können. Oder er hatte die Infos, hat sie aber nicht implementiert, wie auch immer.

[Tjell]

Trotzdem reichen erst weit über 300% damit die FXen auf R3x0 Niveau kommen.

Wenn du willst kram ich mal ein paar andere erbärmliche FX Ergebnisse von Spielen hervor, wo man sich ziemlich sicher sein kann, dass kein IHV Kohle für besondere OPtimerungen abgedrückt hat...Es geht doch nicht darum, die Tatsache zu unterstreichen, daß die FX-Karten langsamer als die R3x0-Karten sind, sondern im Fall von HL2 festzustellen, warum man bereits fertig programmierte Optimierungen über Bord geworfen hat und die Engine dem User stattdessen einfach (ein langsames) DX8.1 aufs Auge drückt.

Daß es recht einfach anders geht sieht man mit dem "quick'n dirty" 3D-Analyze-Prog.

[r@w]

Geh das wieso und warum ist ja wurscht. ATi ist dafür ja ohnehin genug abgestraft worden. Wobei immernoch zu klären wäre, warum sich JC genau für diesen Weg entschieden hat. (Kennt du das interview von JC, wo er im nachhinein selbst die Realisierung des Specularlighting überdacht hatte?)Nein, kenne ich leider nicht.
Wäre nett, wenn Du mir da mal 'nen Link zukommen lassen könntest.

Nönö. Aber man hätte ja D³ (ja genauso wie man es bei HL² auch hätte machen sollen) bestmöglich für beide IHVs optimieren können. Im Entwicklerpacket, hätte man ja immernoch den flexiblen Shader verwenden können.Wenn ich das richtig sehe, dann wurde überhaupt kein IHV bevorzugt.
(wenn man mal von der Verweigerung von weiteren Alphas für ATI absieht)

Egal, mutwilliges PP setzen ist lt Demi ohnehin verboten. Also entweder Shadercompiler oder Handoptimierung. Was ja vermutlich nicht reichen wird.

Das Setzen der pp-Hints durch die Engine ist am sinnvollsten, da nur diese in Gänze 'weiß', was für eine Präzision benötigt wird. Dieses bringt unglaublich viel Performance und sollte unbedingt von Valve nachgereicht werden. Auch sollte man die Engine generell für die nVidia's vielleicht 'etwas' päßlicher einstellen...

100% Mehrperformance wären doch schon was, oder?
Und was dann noch übrig bleibt, kann nVidia ja noch 'optimieren', womit dann noch das eine oder andere Prozentpünktchen dazu kommt.

Nicht von Hand. Der Shadercompiler ist ja (angeblich) mittlerweile ziemlich ausgereift, und den Rest lässt man durch die Rechenfarmen von NV laufen. Und das was imernoch nicht gscheit rennt, kann man ja wirklich von Hand optmieren.Also doch 'von Hand'?
Nichts anderes meinte ich damit.

Aber ändert das jetzt irgendetwas an der offensichtlichen und beabsichtigten Benachteilung einer ganzen Grafikkarten-Generation durch Valve und - maßgeblich - ATI?
:confused:

Stimmt. Aber ATi hätte sich wohl genauso gefreut, wenn die 9600XT mit DX9 immernoch schneller als ne FX5950 wäre. Warum dann dieser 'Humbug'?

Meinst Du nicht, dass ATI diesen ganzen Aufwand getrieben hätte, wenn sie sich soooo sicher gewesen wären, dass ihre eigene Hardware sowieso die weltbeste ist? Sorry, aber irgenwie wirst Du mir langsam zu blauäugig...

Marketing... ;(Bitte?
:hammer:

Blöderweise gibts das immer irgendwo. Ich bin ja z.B. auch nicht über die EA/ATi Situation amused. Aber Spieleentwicklung kostet nunmal viel Geld. Da ists klar dass sich ein ISV freut, wenn er von nem IHV Kohle bekommt. Und dass die das nicht ganz uneigennützig machen ist ja (leider) auch klar.Also IMO geht das ganz, ganz weit über das hinaus, was bis dato gewesen ist.
Setzt neue Maßstäbe sozusagen...
(was Valve mit Steam ja auch gelungen ist *grmpf*)

IMO haben sich da einfach zwei gefunden, die zwar unterschiedliche Ziele verfolgen, aber doch Hand in Hand zum Wohle des anderen arbeiteten (und dies offenbar noch tun).

Razor

[Black-Scorpion]

Hey, dann sind wir uns ja mal einig!
Hätte ich ja fast nicht für möglich gehalten...
:up:

Offenbar wird dieser Fakt aber schon von einigen hier bezweifelt...
(und der Umstand, dass offenbar ATI höchstpersönlich die Shader schrieb und evtl. auch die Einstellung der Engine vornahm ;-)

Razor
Mal überlegen, dann hat ATI die HL² Gutscheine also geschenkt bekommen.
Wird dir das nicht langsam langweilig?

[del_4901]

Das Compositing machen dabei normalerweise die ROPs. Das geht nur auf die Bandbreite. Bei beiden Verfahren verliere ich AA, oder? War das nichtmal so das man AA nur über den Accumulation Buffer realisieren konnte. Bzw. macht man das AA nur im letzten Schritt und verrechnet das mit ein bischen mehr Kontrast?

Das interessiert mich nur weil ich mich selber ein bissel an verschienste Compositing Möglk. rantrauen will.

[reunion]

Demirug könntest du jetzt bitte mal erläutern welches Bild nun FP16 bzw. FP32 ist?

[Tjell]

Demirug könntest du jetzt bitte mal erläutern welches Bild nun FP16 bzw. FP32 ist?Die Qualitätsunterschiede sind mbMn auf jeden Fall zu vernachlässigen.

Eine Auflösung ist aber dennoch interessant.

[Demirug]

Demirug könntest du jetzt bitte mal erläutern welches Bild nun FP16 bzw. FP32 ist?

Ganz vergessen.

Das obere ist FP32 das untere ist FP16.

[LordDeath]

würde nvidia gegen die dx specs auch wiedersprechen, wenn die in den treibermenüs ne gut erklärte option einbauen, die in allen shadern dann fp16 genauigkeit erzwingt?

[LovesuckZ]

würde nvidia gegen die dx specs auch wiedersprechen, wenn die in den treibermenüs ne gut erklärte option einbauen, die in allen shadern dann fp16 genauigkeit erzwingt?

Ich denke schon, da CP und Treiber ein Paket sind und so durch den WHQL Test müssen.
Eventuell koennte es mit Coolbits hinhauen, da dies ja nicht regulaerer Bestandteil des Treibers ist.
Aber dazu müsste sich Nvidia erstmal übereden lassen.

[Demirug]

Ich denke schon, da CP und Treiber ein Paket sind und so durch den WHQL Test müssen.
Eventuell koennte es mit Coolbits hinhauen, da dies ja nicht regulaerer Bestandteil des Treibers ist.
Aber dazu müsste sich Nvidia erstmal übereden lassen.

Über Coolbits dürfen sie es. Es sollte sogar auf einer normalen Page kein Problem sein. Nur muss das ganze eben per Default aus sein.

nVidia wird sich dazu aber schwelich durchringen können weil sie ja selbst sagen das bei manche Anweisungen die 16 Bit eben nicht reichen.

[reunion]

Ganz vergessen.

Das obere ist FP32 das untere ist FP16.

Und diese leichte verschiebung resultiert aus der niedrigern Genauigkeit?

[Demirug]

Und diese leichte verschiebung resultiert aus der niedrigern Genauigkeit?

Wahrscheinlich. Beim Wasser kommen ja dependent Reads ins Spiel die sind gegenüber FP16 anfällig.

[seahawk]

Mal überlegen, dann hat ATI die HL² Gutscheine also geschenkt bekommen.
Wird dir das nicht langsam langweilig?

Sind diese Gutscheine nicht auch zusätzlicher Umsatz von Valve, da sie diese wohl kaum ohne Gewinn verkauft haben.

[Demirug]

Will jemand die Objekliste und die in diesem Frame benutzten PixelShader haben? Wenn genügend interesse besteht schreibe ich sie raus.

[Quasar]

/edit: Wenn sies nicht getan hätten, wär wohl die Summe unterm Scheck wohl kaum so groß ausgefallen.
Was willst du denn damit sagen? :confused:

[Mr. Lolman]

Was willst du denn damit sagen? :confused:

ATi zahlt doch nicht 7Mio$ an Valve damit dann vll NV in den Benchmarks noch vorne ist? (zumindest mit dem NV40)

[Quasar]

ATi zahlt doch nicht 7Mio$ an Valve damit dann vll NV in den Benchmarks noch vorne ist? (zumindest mit dem NV40)

Was willst du nun wieder damit sagen? :confused:

[Black-Scorpion]

Sind diese Gutscheine nicht auch zusätzlicher Umsatz von Valve, da sie diese wohl kaum ohne Gewinn verkauft haben.

Zusätzlichen Umsatz haben sie mit Sicherheit gemacht.
Ob sie damit auch Gewinn gemacht haben kann dir nur Valve sagen.

'edit' Ergänzung

[LordDeath]

Was willst du nun wieder damit sagen? :confused:

dass valve käuflich ist und ati für nen gewonnenen schwanzmark gern 7mio $ ausgibt?

[Jesus]

kann es sein das auf beiden Bildern dieser DX9 Smoother Shader Effekt fehlt bei dem das Wasser weich ins Ufer übergeht ? Diese scharfe Kante wie man sie auf beiden Bildern sieht ist mir bisher eigentlich nur im DX8 Modus aufgefallen...

? ;(

[Quasar]

? ;(
Hab ich mich auch gerade gayfrag0rt.
Rechts die Kante sieht schlimm aus.

[Demirug]

Da könnte die Spiegelung von der Mauer reinspielen. Auf jeden Fall wird die gesamte Wasserline in einem Zug gerendert und auch mit dem entsprechenden Shader.

[Mr. Lolman]

dass valve käuflich ist und ati für nen gewonnenen schwanzmark gern 7mio $ ausgibt?

Ja ist denn das so abwegig?

[Quasar]

dass valve käuflich ist und ati für nen gewonnenen schwanzmark gern 7mio $ ausgibt?
Nie....

[Jesus]

Da könnte die Spiegelung von der Mauer reinspielen. Auf jeden Fall wird die gesamte Wasserline in einem Zug gerendert und auch mit dem entsprechenden Shader.

Äh,also ist es falsch oder nicht? Denn afaik verwendet Valve extra für den DX9 Pfad einen (oder mehrere) zusätzliche Shader um einen weichen übergang vom Wasser aufs Land zu bekommen. Den gibts mit DX8 nicht.

[reunion]

Nie....

Was nie?
Geld regiert die Welt. Ich behaupte mal jeder ist käuflich wenn der Betrag hoch genug ist. Ich möchte nicht wissen wieviel von ATI/NV ausgegeben wird nur um bei irgendeinem Schwanzmark die Nase vorn zu haben. Was daran so unwarscheindlich ist würde mich mal intressieren.

//EDIT: Oder war das ironisch gemeint?

[Demirug]

Äh,also ist es falsch oder nicht? Denn afaik verwendet Valve extra für den DX9 Pfad einen (oder mehrere) zusätzliche Shader um einen weichen übergang vom Wasser aufs Land zu bekommen. Den gibts mit DX8 nicht.

So wie es scheint soll das an dieser Stelle so sein.

[IVN]

Will jemand die Objekliste und die in diesem Frame benutzten PixelShader haben? Wenn genügend interesse besteht schreibe ich sie raus.

Just do it.


*nike* ;D

[Blackbird23]

So ich hab jetzt bei meiner 5900 XT auch mal per 3DA die FP16 Shader und DX9 erzwungen. Wasser sieht natürlich klasse aus aber es gibt stellen da sehen die Shader sehr merkwürdig aus das ich der Meinung bin FP16 gibt doch erhebliche Nachteile in der BQ:

DX8.1:
http://mitglied.lycos.de/webtempacc/HL2/d2_coast_080014.jpg
DX9 ( per 3da mit Device-Erkennung als 9800 Pro und auf FP16 ) :
http://mitglied.lycos.de/webtempacc/HL2/d2_coast_080011.jpg

[IVN]

So ich hab jetzt bei meiner 5900 XT auch mal per 3DA die FP16 Shader und DX9 erzwungen. Wasser sieht natürlich klasse aus aber es gibt stellen da sehen die Shader sehr merkwürdig aus das ich der Meinung bin FP16 gibt doch erhebliche Nachteile in der BQ:

DX8.1:
http://mitglied.lycos.de/webtempacc/hl2/d2_coast_080014.jpg
DX9 ( per 3da mit Device-Erkennung als 9800 Pro und auf FP16 ) :
http://mitglied.lycos.de/webtempacc/hl2/d2_coast_080011.jpg

Your links don't work.



Edit@sorry

[Demirug]

So ich hab jetzt bei meiner 5900 XT auch mal per 3DA die FP16 Shader und DX9 erzwungen. Wasser sieht natürlich klasse aus aber es gibt stellen da sehen die Shader sehr merkwürdig aus das ich der Meinung bin FP16 gibt doch erhebliche Nachteile in der BQ:


Sieht nach einen Dependent Read Problem aus. Ich arbeite da an einer Lösung.

Hast du ein Savegame von der Stelle bzw eine Timedemo (Version 7)?

[Blackbird23]

Sieht nach einen Dependent Read Problem aus. Ich arbeite da an einer Lösung.

Hast du ein Savegame von der Stelle bzw eine Timedemo (Version 7)?
Savegame hätte ich...

[Demirug]

Savegame hätte ich...

Wenn es dir recht ist würde ich auf die zurückkommen wenn ich eine Lösung habe.

[Jesus]

So ich hab jetzt bei meiner 5900 XT auch mal per 3DA die FP16 Shader und DX9 erzwungen. Wasser sieht natürlich klasse aus aber es gibt stellen da sehen die Shader sehr merkwürdig aus das ich der Meinung bin FP16 gibt doch erhebliche Nachteile in der BQ:

DX8.1:
http://mitglied.lycos.de/webtempacc/HL2/d2_coast_080014.jpg[/IMG]
DX9 ( per 3da mit Device-Erkennung als 9800 Pro und auf FP16 ) :
http://mitglied.lycos.de/webtempacc/HL2/d2_coast_080011.jpg[/IMG]

An deiner Knarre fehlt irgendwie auch ein Glanzeffekt.

[Blackbird23]

An deiner Knarre fehlt irgendwie auch ein Glanzeffekt.
Stimmt glänzt im DX9 nicht so wie im DX8... komisch

[Blackbird23]

An deiner Knarre fehlt irgendwie auch ein Glanzeffekt.
Das mit dem Glanzeffekt kommt davon das ich im DX9 Bild etwas anders stehe habs eben nochma probiert.

[Jesus]

Danke fürs OT. :rolleyes:

[Gast]

Mal überlegen, dann hat ATI die HL² Gutscheine also geschenkt bekommen.
Wird dir das nicht langsam langweilig?So wie Valve die Gutscheine für die ATI-Karten?
OK, sind 'nur' 20 Teuronen, aba...
:D

Und nein, langweilig wird das für mich ganz sicher nicht, solange hier weiterhin so Unsinn verzapft wird!

Razor

[Dr Hake]

folgendes ist mir aufgefallen:
"gewinnt der NV40-Chip aus der Nutzung von FP16 oft mehr Leistung als der NV35-Chip, welcher wiederum von FP16 mehr profitiert als NV30-Chip. Als ganz grobe Richtwerte kann man hierbei annehmen: NV30 gewinnt 10%, NV35 20% und NV40 30%." quelle http://www.3dcenter.org/artikel/2004/11-29_b.php
Igendwie widersprechen die gemessenen 50-80% Leistungszuwachs der Theorie, oder irrt aths, oder uebersehe ich etwas? Interresant waere auch festzustellen wie sich die theoretische Betrachtung in der Praxis auf nV40 auswirkt.

[Gast]

folgendes ist mir aufgefallen:
"gewinnt der NV40-Chip aus der Nutzung von FP16 oft mehr Leistung als der NV35-Chip, welcher wiederum von FP16 mehr profitiert als NV30-Chip. Als ganz grobe Richtwerte kann man hierbei annehmen: NV30 gewinnt 10%, NV35 20% und NV40 30%." quelle http://www.3dcenter.org/artikel/2004/11-29_b.php
Igendwie widersprechen die gemessenen 50-80% Leistungszuwachs der Theorie, oder irrt aths, oder uebersehe ich etwas? Interresant waere auch festzustellen wie sich die theoretische Betrachtung in der Praxis auf nV40 auswirkt.

Mal ehrlich, aths hat doch keine Ahnung. Er programmiert weder Pixelshader noch kennt er sich damit aus. Er kennt nur die Hardware und zwar auch nur in der Theorie, daraus leitet er alles ab.

Dass das meistens falsch ist haben wir ja schon des öfteren gesehen.

[r@w]

folgendes ist mir aufgefallen:
"gewinnt der NV40-Chip aus der Nutzung von FP16 oft mehr Leistung als der NV35-Chip, welcher wiederum von FP16 mehr profitiert als NV30-Chip. Als ganz grobe Richtwerte kann man hierbei annehmen: NV30 gewinnt 10%, NV35 20% und NV40 30%." quelle http://www.3dcenter.org/artikel/2004/11-29_b.php
Igendwie widersprechen die gemessenen 50-80% Leistungszuwachs der Theorie, oder irrt aths, oder uebersehe ich etwas? Interresant waere auch festzustellen wie sich die theoretische Betrachtung in der Praxis auf nV40 auswirkt.Nun ja...
Die NV3x-Architektur hat ja bekanntlich zu wenig Register für die Zwischenspeicherung von Daten. fp32-Werte nehmen natürlich den doppelten Platz ein und so wird die Architektur mit reinen fp32-Shadern natürlich zusätzlich ausgebremst (ist beim NV35 weniger stark ausgepwägt, wie ebim NV30).

Warum jetzt allerdings der Nutzen von fp16 beim NV40 höher sein soll, entzieht sich meiner Kenntnis.
AFAIK soll die NV4x-Architektur weit weniger anfällig sein, war die extensive Nutzung von Temp-Registern angeht...

Razor

[Dr Hake]

Mal ehrlich, aths hat doch keine Ahnung. Er programmiert weder Pixelshader noch kennt er sich damit aus. Er kennt nur die Hardware und zwar auch nur in der Theorie, daraus leitet er alles ab.

Dass das meistens falsch ist haben wir ja schon des öfteren gesehen.
Pauschalisierst du hier nicht ein bisserl?

[Tjell]

So ich hab jetzt bei meiner 5900 XT auch mal per 3DA die FP16 Shader und DX9 erzwungen. Wasser sieht natürlich klasse aus aber es gibt stellen da sehen die Shader sehr merkwürdig aus das ich der Meinung bin FP16 gibt doch erhebliche Nachteile in der BQ...Ganz einfach: es darf ja auch nicht durchgehend FP16 angewandt werden, was bei dem Einsatz von 3DAnalyze natürlich schnell zu unansehnlicher Grafik führen kann, weil das Programm nicht so intelligent sein kann, zu entscheiden, wo FP16 nicht ausreicht.

FP16 müßte vom Spieleentwickler durch Setzen von _PP-Flags an Stellen angewandt werden, wo die BQ nicht leidet.

[del_4901]

FP16 müßte vom Spieleentwickler durch Setzen von _PP-Flags an Stellen angewandt werden, wo die BQ nicht leidet.

"wo der Algo numerisch stabil ist" klingt besser :ugly:

[BUG]

..habe mit dem 3DA in HL2 gerade mal FP16 (force low precision pixelshader) auf meinem NV40 ausprobiert in der TimeDemo canals_08. Sieht irgendwie total anders aus (diverse Schatten Fehler und es gibt kein hell/dunkel mehr, alles gleich hell) und die TimeDemo (canals_08) läuft in etwa genausoschnell wie ohne FP16. :|

Edit: Bilder angehängt, links mit 3DA und "low precision pixelshader", rechts ohne 3DA also ganz normal. Wenn ich im 3DA "high precision pixelshader" aktiviere sieht es ganz normal aus.

cu
BUG

[Dr Hake]

@razor
kann ein Grund sein, aber afaik (aufgrund aelterer Artikel) ist sich aths dessen bewusst, und frage mich deshalb warum weshalb er das nicht in seine Theorie miteinfliessen gelassen hat?
Kann es nicht sein dass der FP16 Modus auf nV3x aus anderen Gruenden schneller als erwartet ist (Shader nicht berechnet werden, irgendwo in diesem Thread war doch ein Screenie bei dem groessere Abweichungen waren).
Versteh mich nicht falsch, es geht mir nicht darum Fx Usern die ggue DX8.1 bessere Optik nicht zu vergoennen, sondern on evtl hier eine Ursache sein koennte warum Valve den Fx Pfad gekippt hat.

[Demirug]

Ich hatte das D³ Beispiel nur gebracht um zu zeigen, dass ein IHV mittels Treiber durchaus nette Performancezuwäche bringen kann. V.A. dann wenn das Spiel nicht gerade passend auf den jew. IHV zugeschnitten ist.
D.h. liebe NV User: Ja ich glaube, dass NV das mit ihrem Treiber wieder gut machen kann, was Valve verbockt hat.

Inzwischen glaube ich auch das nVidia da durchaus noch was über die Treiber rausholen kann. Allerdings nicht über FP16 in den Shadern. Die Source Engine erscheint mir zunehmend zu exzentrischem Verhalten zu neigen. Da werden Buffer gelöscht die seit dem letzten Löchen gar nicht verändert wurden und noch andere Dinge die unverständlich sind. Ein Treiber der solche Dinge kennt kann da durchaus Arbeit einsparen.

PS: Die Wassershader sind gar nicht die aufwendigsten. Ein Optimieren an diesen könnte daher durchaus weniger als bisher angenommen bringen.

[Gast]

Inzwischen glaube ich auch das nVidia da durchaus noch was über die Treiber rausholen kann. Allerdings nicht über FP16 in den Shadern. Die Source Engine erscheint mir zunehmend zu exzentrischem Verhalten zu neigen. Da werden Buffer gelöscht die seit dem letzten Löchen gar nicht verändert wurden und noch andere Dinge die unverständlich sind. Ein Treiber der solche Dinge kennt kann da durchaus Arbeit einsparen.

PS: Die Wassershader sind gar nicht die aufwendigsten. Ein Optimieren an diesen könnte daher durchaus weniger als bisher angenommen bringen.

Das gilt dann aber genauso für ATI ;)

[Demirug]

Das gilt dann aber genauso für ATI ;)

Natürlich aber die sind schon länger über die Eigenheiten Informiert als nVidia.

[Mr. Lolman]

Natürlich aber die sind schon länger über die Eigenheiten Informiert als nVidia.

Das glaub ich wiederum nicht. ATi wird schon drauf geachtet haben, dass die Source Engine bestmöglich auf ihren Produkten rennt (und dementsprechenden Dev. Support geleistet haben). Die Eigenheiten die sich beim näheren Betrachten der Engine auftun, sind m.E. kein Produkt von programmiertechnischer Unzulänglichkeit sondern ganz bewußt so integriert.

Wobei sich natürlich die Frage stellt ob diese Eigenheiten vordergründig ATi HW nützen, oder NV Schaden. (Ich hoffe natürlich auf Ersteres. Wundern würds mich nicht, wenn Beides der Fall wär).

[Gast]

Natürlich aber die sind schon länger über die Eigenheiten Informiert als nVidia.

Du glaubst doch nicth im Ernst dass NV sich nicht mal ne geleakte HL2 Version reingezogen hat und darauf hinoptimiert hat so gut es geht ? Genug Zeit hatten sie ja allemal dazu.

[Mr. Lolman]

Du glaubst doch nicth im Ernst dass NV sich nicht mal ne geleakte HL2 Version reingezogen hat und darauf hinoptimiert hat so gut es geht ? Genug Zeit hatten sie ja allemal dazu.

und selbst wenn, gibts in der Vollversion genug neuen Content, der NV das Genick brechen kann.

[r@w]

kann ein Grund sein, aber afaik (aufgrund aelterer Artikel) ist sich aths dessen bewusst, und frage mich deshalb warum weshalb er das nicht in seine Theorie miteinfliessen gelassen hat?Das kannst Du leider nur ihn selbst fragen...

Alledings habe ich mir abgewöhnt, alles verstehen zu wollen, was aths so zum besten gibt. Nicht, weil es unrichtig ist, sondern vielmehr, weil mein Wissen um die Materie oft nicht so 'ausgeprägt' ist.

Vielleicht äussert er sich hier ja mal dazu.

Kann es nicht sein dass der FP16 Modus auf nV3x aus anderen Gruenden schneller als erwartet ist (Shader nicht berechnet werden, irgendwo in diesem Thread war doch ein Screenie bei dem groessere Abweichungen waren).Sicher kann das sein!
Allerdings konnte ich keine großartigen Unterschiede ausmachen (habe zu Hause ja auch 'ne R9800p rum liegen ;-).

Andere berichteten davon, dass 'ihre' Probleme verschwanden, wenn der ATI-Pfad für DX9 genommen wurde, was ich mit meiner Konfiguration allerdings nicht nachvollziehen konnte.

Vielleicht liegt das aber auch an irgendwelchen 'Tweaks', die schon von anderen benutzt wurden, um den DX-Pfad zu erzwingen. Ich habe lediglich den Parameter "-dxlevel 90" benutzt und in der 'dxsupport.cfg' den Parameter "noUserClipPlanes" (oder so ;-) für meine Karte entfernt, weil sonst das Wasser unter DX9 gar nicht dargestellt wurde (darüber hat sich im übrigen auch Demirug gewundert ;-).

Versteh mich nicht falsch, es geht mir nicht darum Fx Usern die ggue DX8.1 bessere Optik nicht zu vergoennen, sondern on evtl hier eine Ursache sein koennte warum Valve den Fx Pfad gekippt hat.Ich würde mein Urteil über Valve sofort (!) revidieren, wenn es tatsächlich technische Gründe haben sollte, den schon fertigen NV3x-Pfad über Board zu werfen. Allerdings ist die Valvsche Implementierung sehr viel weiter gegangen. So wurde selbstverständlich nicht durchweg mit fp16 'gerechnet', sondern die pp-Hints wurden - wie es sich auch gehört - akzentuiert gesetzt, also nur da benutzt, wo es möglich war, ohne Fehler zu verursachen.

Die 3DA-Methode ist tatsächlich nur ein "Quaick'n'dirty"-Hack...

Razor

[r@w]

..habe mit dem 3DA in HL2 gerade mal FP16 (force low precision pixelshader) auf meinem NV40 ausprobiert in der TimeDemo canals_08. Sieht irgendwie total anders aus (diverse Schatten Fehler und es gibt kein hell/dunkel mehr, alles gleich hell) und die TimeDemo (canals_08) läuft in etwa genausoschnell wie ohne FP16. :|

Edit: Bilder angehängt, links mit 3DA und "low precision pixelshader", rechts ohne 3DA also ganz normal. Wenn ich im 3DA "high precision pixelshader" aktiviere sieht es ganz normal aus.Sieht ja reichlich merkwürdig aus...
Gibt's 'nen Link zu dem Timedemo?
Habe hier (zu Hause ;-) nur die Canals_09-Demo... von Hexus glaube ich.

Werde das dann mal zu Hause checken...

Razor

[Dr hake]

..habe mit dem 3DA in HL2 gerade mal FP16 (force low precision pixelshader) auf meinem NV40 ausprobiert in der TimeDemo canals_08. Sieht irgendwie total anders aus (diverse Schatten Fehler und es gibt kein hell/dunkel mehr, alles gleich hell) und die TimeDemo (canals_08) läuft in etwa genausoschnell wie ohne FP16. :|

cu
BUG
ok Danke, das zeigt dass Valve nicht unbedingt aus Boeswilligkeit ggue nV den Fx Pfad gekippt hat. Das Wasser allerdings koennte man trotzdem mit pp und PS2 rendern, ausser ... hier gibt es auch Probleme, die lediglich auf Demirugs Screenshot nicht auftreten, da zufaelligerweise an dieser Stelle alles richtig laeuft.

[r@w]

Das glaub ich wiederum nicht. ATi wird schon drauf geachtet haben, dass die Source Engine bestmöglich auf ihren Produkten rennt (und dementsprechenden Dev. Support geleistet haben). Die Eigenheiten die sich beim näheren Betrachten der Engine auftun, sind m.E. kein Produkt von programmiertechnischer Unzulänglichkeit sondern ganz bewußt so integriert.Sinnloses Buffer-Löschen soll "bewußt so integriert" worden sein, damit es auf ATI-Hardware optimal läuft?
Also das musst Du mir jetzt mal erklären...

Wo ich Dir natürlich recht gebe, scheint das Faktum, dass die hochflexible Source-Engine (O-Ton Demirug ;-) durchaus auf die Eigenheiten von ATI Soft- und Hardware geeicht sein könnte.

Wobei sich natürlich die Frage stellt ob diese Eigenheiten vordergründig ATi HW nützen, oder NV Schaden. (Ich hoffe natürlich auf Ersteres. Wundern würds mich nicht, wenn Beides der Fall wär).Wohl wahr...
Letzteres wäre ja schon fast als "Sabotage" einzustufen.
(was mich schlußendlich auch nicht mehr wundern würde)

Razor

[r@w]

ok Danke, das zeigt dass Valve nicht unbedingt aus Boeswilligkeit ggue nV den Fx Pfad gekippt hat. Das Wasser allerdings koennte man trotzdem mit pp und PS2 rendern, ausser ... hier gibt es auch Probleme, die lediglich auf Demirugs Screenshot nicht auftreten, da zufaelligerweise an dieser Stelle alles richtig laeuft.Oder aber der Treiber für den NV40 kommt einfach nicht mit dem 3DA klar. Schließlich wird ja empfohlen, den 2.26 zu verwenden, der zumindest erste Unterstützungen für den NV40 bot... (des Ruby Demo will ja auch nicht mehr via 3DA, lediglich die gehackte Sushi.exe für den NV40 funktioniert noch ;-).

Werde das mal heut' abend checken.

Razor

[Dr Hake]

1.Allerdings konnte ich keine großartigen Unterschiede ausmachen (habe zu Hause ja auch 'ne R9800p rum liegen ;-).
....
2. wenn es tatsächlich technische Gründe haben sollte, den schon fertigen NV3x-Pfad über Board zu werfen. Allerdings ist die Valvsche Implementierung sehr viel weiter gegangen. So wurde selbstverständlich nicht durchweg mit fp16 'gerechnet', sondern die pp-Hints wurden - wie es sich auch gehört - akzentuiert gesetzt, also nur da benutzt, wo es möglich war, ohne Fehler zu verursachen.

Razor
1. vielleicht sind sie trotzdem da, ich gehe nicht davon aus dass du das ganze Game mit beiden parallel gespielt hast, um auf Unterschiede zu achten. Evtl erscheint dir auch auf Stellen das von der Fx gerenderte korrekt (und auch visuell nicht zu beanstanden) da du den anderen Pfad in eben diesen Szenen nicht gesehen hast. Valve und nV als Firmen stuenden schoen am Pranger wenn das Resultat sich als unterschiedlich herausstellen wuerde. UU wuerde nV mal wieder Ch.. nachgesagt
2. dessen bin ich mir bewusst, allerdings stellt sich die Frage ob auch hier (bei den bewusst gesetzten pps) das Resultat den Erwartungen entsprach und nicht ploetzlich irgendwelche Bugs auftauchten..Demis Kommentar laesst ja irgendwie darauf schliessen.
Im Endeffekt glaube ich kann man Valve hoechstens dahingehend verdammen dass sie bei der Programmierung der Engine nur auf Ati geschaut haben, und sich nicht bewusst waren dass es unmoeglich ist nachtraeglich einen Fx Pfad einzubringen, anstatt schon bei der Designphase auf Fx Ansprueche einzugehen.

[aths]

folgendes ist mir aufgefallen:
"gewinnt der NV40-Chip aus der Nutzung von FP16 oft mehr Leistung als der NV35-Chip, welcher wiederum von FP16 mehr profitiert als NV30-Chip. Als ganz grobe Richtwerte kann man hierbei annehmen: NV30 gewinnt 10%, NV35 20% und NV40 30%." quelle http://www.3dcenter.org/artikel/2004/11-29_b.php
Igendwie widersprechen die gemessenen 50-80% Leistungszuwachs der Theorie, oder irrt aths, oder uebersehe ich etwas? Interresant waere auch festzustellen wie sich die theoretische Betrachtung in der Praxis auf nV40 auswirkt.Das hängt immer davon ab. Je nach Shader (und weiteren Begleitumständen) können die Zuwächse sehr drastisch, oder nur marginal ausfallen. Unter bestimmten Umständen gewinnt NV40 extrem, in anderen Situationen wieder fast gar nicht; ebenso beim NV35.

Und ja, ich programmiere keine Pixelshader, kenne aber Leute die das tun.

[Mr. Lolman]

Sinnloses Buffer-Löschen soll "bewußt so integriert" worden sein, damit es auf ATI-Hardware optimal läuft?
Also das musst Du mir jetzt mal erklären...


Mal abwarten was Demi dazu noch herausfindet. An einen designtechnischen Unfall glaub ich allerdings nicht.

Das hängt immer davon ab. Je nach Shader (und weiteren Begleitumständen) können die Zuwächse sehr drastisch, oder nur marginal ausfallen. Unter bestimmten Umständen gewinnt NV40 extrem, in anderen Situationen wieder fast gar nicht; ebenso beim NV35.


Ich dachte, das wäre eher umgekehrt. (Von NV30-NV40 hat PP einen immer geringeren Nutzen) Gibts eigentlich Benchmarks dazu, oder basiert deine Annahme nur auf einer theoretischen Überlegung?

[Dr Hake]

Das hängt immer davon ab. Je nach Shader (und weiteren Begleitumständen) können die Zuwächse sehr drastisch, oder nur marginal ausfallen. Unter bestimmten Umständen gewinnt NV40 extrem, in anderen Situationen wieder fast gar nicht; ebenso beim NV35.
.
Was ist IYO das Maximum?

[Coda]

Mr. Lolman: Mal ganz im Ernst, glaubst du wirklich das 2 mal hintereinander Buffer löschen schneller ist als einmal auf ATi Hardware?

Es gibt 2 Möglichkeiten
a) Sie waren einfach zu faul es zu checken, ob der Buffer schon gelöscht ist
b) ATi hat es eingefädelt und dafür einen Check in den Treiber eingebaut, da sie wussten das nVidia ihn nicht hat

Ich tendiere stark zu a), weil ich an die ATi-Verschwörungstheorie nicht glaube. Ich denke nur das Valve auf ATi optimiert hat und nVidia weitgehend ignoriert hat, aber nicht das sie absichtlich noch nVidia feindliche Dinge eingebaut haben.

Du kannst dich für a) oder b) entscheidene, aber auf jeden Fall zeigt es das die Source Engine nicht perfekt ist.

[Mr. Lolman]

Mr. Lolman: Mal ganz im Ernst, glaubst du wirklich das 2 mal hintereinander Buffer löschen schneller ist als einmal auf ATi Hardware?


Nein. Das hab ich auch nicht geschrieben.

Aber vll. ist der Check (ob der Buffer schon gelöscht wurde) aufwändiger, als den Buffer einfach nochmal zu löschen?

[Dr Hake]

@ mr lolman
warum sollte Valve, die ja auch an der Vermarktung der Engine interessiert sind, sich ein Eigentor schiessen, und den Weiterverkauf der eigenen Engine sabotieren, indem man bewusst eine grosse Anzahl von potentiellen Endabnehmern veraergert? Das Ganze sieht eher nach einer Ati (=sponsor) freundlichen Designentscheidung aus, bei welcher man sich nicht bewusst war dass es auf den Fx nie richtig ans Laufen zu bekommen ist. Keine Firma kann es sich leisten sich einem Sponsor auf Gedeih und Verderb auszuliefern und die eigenen Kunden absichtlich in den Hintern zu treten. Das stuende im krassen Gegensatz zu saemtlichen "good marketpractices".

[Coda]

Nein, das wäre einfach ein Flag, das bei Clear gesetzt wird und beim Rendern aufgehoben wird.
Das ist simpelste Programmlogik und sicher schneller als die HW anzuweißen das Ding nochmal zu löschen.

Oder anders: Vielleicht merken die ATi Karten das ja sogar auf HW-Ebene, die nV-Karten aber nicht. Dazu wären auch sehr wenige Transistoren nötig.

Egal wie du es drehst, es macht einfach keinen Sinn, das Ding zweimal hintereinander zu löschen.

[seahawk]

Inzwischen glaube ich auch das nVidia da durchaus noch was über die Treiber rausholen kann. Allerdings nicht über FP16 in den Shadern. Die Source Engine erscheint mir zunehmend zu exzentrischem Verhalten zu neigen. Da werden Buffer gelöscht die seit dem letzten Löchen gar nicht verändert wurden und noch andere Dinge die unverständlich sind. Ein Treiber der solche Dinge kennt kann da durchaus Arbeit einsparen.

PS: Die Wassershader sind gar nicht die aufwendigsten. Ein Optimieren an diesen könnte daher durchaus weniger als bisher angenommen bringen.

Jetzt wäre die Frage ob dieses merkwürdige Verhalten ATI HArdware entgegen kommt, oder ob diese auch darunter leidet.

[Coda]

Entgegenkommen wohl nicht, es kann nur sein dass es ihr nichts ausmacht, nVidia aber schon.

[Mr. Lolman]

@ mr lolman
warum sollte Valve, die ja auch an der Vermarktung der Engine interessiert sind, sich ein Eigentor schiessen, und den Weiterverkauf der eigenen Engine sabotieren, indem man bewusst eine grosse Anzahl von potentiellen Endabnehmern veraergert? Das Ganze sieht eher nach einer Ati (=sponsor) freundlichen Designentscheidung aus, bei welcher man sich nicht bewusst war dass es auf den Fx nie richtig ans Laufen zu bekommen ist. Keine Firma kann es sich leisten sich einem Sponsor auf Gedeih und Verderb auszuliefern und die eigenen Kunden absichtlich in den Hintern zu treten. Das stuende im krassen Gegensatz zu saemtlichen "good marketpractices".

Da geb ich dir recht. Es war ja nur ne Überlegung meinerseits, dass das 2 malige Bufferlöschen kein Unfall ist. Und wenns ATi HW nix bringt, es NV HW aber schadet, kann man 1+1 zusammenzählen.
Ich mein: Demi sieht sich die Engine an, und merkt dass solche Dinge geschehen, dabei ists für einen nicht involvierten logischerweise immer schwerer den Code zu verstehen, als wenn man ihn selbst geschrieben hätte.

Was heisst: Wenn es wirklich nur ein designtechnischer Fehler wäre, hätte dieser Fehler ja den Entwicklern sofort auffallen müssen, wenn er schon für Aussenstehende ziemlich offensichtlich ist.

Oder anders: Vielleicht merken die ATi Karten das ja sogar auf HW-Ebene, die nV-Karten aber nicht. Dazu wären auch sehr wenige Transistoren nötig.

Ok, ich dachte, da stecke eine kompliziertere Programmlogik dahinter. Aber man lebt ja um zu lernen :redface:


Egal wie du es drehst, es macht einfach keinen Sinn, das Ding zweimal hintereinander zu löschen.

Wenns dazu führt, dass ATi deswegen schneller rennt als NV, hats zumindest für ATi schon Sinn gemacht. *duck*

[BUG]

Sieht ja reichlich merkwürdig aus...
Gibt's 'nen Link zu dem Timedemo?
Habe hier (zu Hause ;-) nur die Canals_09-Demo... von Hexus glaube ich.

Werde das dann mal zu Hause checken...

Razor..die gibt es u.a. hier. :)

http://images.anandtech.com/reviews/video/HalfLife2/AT_hl2_demos.zip

cu
BUG

[Gast]

Das ist der Abstand, den die X800pro zur GT im 3Dcenter.de Test hat und somit das wirkliche Leistungbild offenbart.
Oder sollte ich eine Paperkarte mit einer kaum verfuegbarwen vergleichen? dann hast du natuerlich recht, dass die 35% geringer getaktete Karte noch ca. 10% schneller.

http://www.zdnet.de/enterprise/client/0,39023248,39125640-5,00.htm
Gt hat 33% mehr pipes und die Pro ist 29% schneller
Sauber nVidia :up:

[LordDeath]

http://www.zdnet.de/enterprise/client/0,39023248,39125640-5,00.htm
Gt hat 33% mehr pipes und die Pro ist 29% schneller
Sauber nVidia :up:

durch nur ein bench darfst du keine allgemeine aussage ziehen!

[Gast]

Nein, es geht um die idiotische Aussage bei 35% weniger Takt 10% schneller

[Demirug]

Was das Löschen von Buffern angeht so spricht nVidia da in der Regel davon das es sehr schnell geht und ATI gibt beim Z-Buffer sogar an das es sozusagen in Nullzeit geht. Auch bei sonstigen Diskussionen lässt ATI immer durchblicken das man doch ruhig alle löschen kann. nVidia dagen vertritt immer die Meinung das man nur das löschen soll was gelöscht werden muss.

So ein doppeltes Löschen oder ähnliches kann sich aber relative einfach in eine Engine einschleichen. Das ich sowas dann eher sehe als andere (auch die Entwickler selbst) hängt damit zusammen das ich ein anderes Tool/Weg benutze. Ich bekomme die Sache so zu sehen wie der Treiber. Die Entwickler arbeiten aber mit dem Quellcode und werden so eher immer wieder über die gleichen Dingen einfach hinwegen.

[LovesuckZ]

http://www.zdnet.de/enterprise/client/0,39023248,39125640-5,00.htm
Gt hat 33% mehr pipes und die Pro ist 29% schneller
Sauber nVidia :up:

Seit wann kann ich in Doom3 mit Autos fahren?! :ugly:

[Dr Hake]

also kann man davon ausgehen, dass dieses Loeschen eher Zufall als Absicht ist. Laesst sich das evtl mal per patch nachtraeglich beheben?

[Dr Hake]

an die Herrren Lovesuckz, Gaeste und andere Spammer
wenn ihr nichts zum Thema FP16/32/HL zu sagen hat, geht bitte in den Kindergarten. Alles andere stoert den Diskussionsfluss und widert an.
Danke

[Demirug]

also kann man davon ausgehen, dass dieses Loeschen eher Zufall als Absicht ist. Laesst sich das evtl mal per patch nachtraeglich beheben?

An der einen Stelle vielleicht aber da passieren noch mehr lustige Sache und mache haben echt schon die Tendenz zur Unfähigkeit.

[Dr Hake]

An der einen Stelle vielleicht aber da passieren noch mehr lustige Sache und mache haben echt schon die Tendenz zur Unfähigkeit.
kann man da auf einen Artikel oae gespannt sein? ****igendwienichtmehrverwundertbinwarumdasganzeimmerwiederverschobenwurde****

[Quasar]

Warum jetzt allerdings der Nutzen von fp16 beim NV40 höher sein soll, entzieht sich meiner Kenntnis.
Weil der nV40 einige Dinge in FP16 dank seines vierfachen Split und zusätzlicher Einheiten quasi nebenbei erledigen kann, während dies in FP32 u.U. mehr als einen Takt kostet und/oder alle vier Kanäle zugleich belegt.

[Quasar]

ok Danke, das zeigt dass Valve nicht unbedingt aus Boeswilligkeit ggue nV den Fx Pfad gekippt hat.
Falscher Schluß. Das zeigt lediglich, daß durchgehendes FP16 im aktuellen Codepfad nicht zu empfehlen sein dürfte.

Bestand der FX-Pfad nur aus FP16-2.0-Shadern? AFAIK nicht.

[Quasar]

Was ist IYO das Maximum?

+70,5% habe ich bisher gesehen.

[Quasar]

http://www.zdnet.de/enterprise/client/0,39023248,39125640-5,00.htm
Gt hat 33% mehr pipes und die Pro ist 29% schneller
Sauber nVidia :up:
Der Takt der Pro ist 35,7% höher und sie ist nur 29% schneller.
^^
Man sollte Dinge nicht so eindimensional sehen...

[Quasar]

Wo ich mich hier grad so durchwühle: Wird hier eigentlich nicht moderiert?

[Dr Hake]

Falscher Schluß. Das zeigt lediglich, daß durchgehendes FP16 im aktuellen Codepfad nicht zu empfehlen sein dürfte.

Bestand der FX-Pfad nur aus FP16-2.0-Shadern? AFAIK nicht.
deshalb schrieb ich ja "nicht unbedingt". Wie Demirug so schreibt gibt es ja noch andere witzige Aspekte der Engine. Glaubst du wirklich dass Valve Ati so hoerig ist dass sie fuer 7Mio $ kurzfristigen Gewinn ihr ganzes zukuenftiges Geschaft in Frage stellen? Leckerlies fuer den Sponsor ja, den andern absichtlich boykottieren...eher nein, da genau dieser andere an 50% der potenziellen Endabnehmer liefert.

[Quasar]

deshalb schrieb ich ja "nicht unbedingt".
So, wie du es geschrieben hast, klang es, als bezöge sich das "nicht unbedingt" auf die Böswilligkeit. :)

ok Danke, das zeigt dass Valve nicht unbedingt aus Boeswilligkeit ggue nV den Fx Pfad gekippt hat.

Du hast aus den geposteten Bilder also gefolgert, daß Valve aufgrund von Bildfehlern den FX-Pfad gekippt hätte, oder?

Diese Bildfehler resultieren aber aus uniform erzwungenem FP16 - das hat m.W. nicht unbedingt etwas mit dem FX-Pfad zu tun. ;)

[Demirug]

deshalb schrieb ich ja "nicht unbedingt". Wie Demirug so schreibt gibt es ja noch andere witzige Aspekte der Engine. Glaubst du wirklich dass Valve Ati so hoerig ist dass sie fuer 7Mio $ kurzfristigen Gewinn ihr ganzes zukuenftiges Geschaft in Frage stellen? Leckerlies fuer den Sponsor ja, den andern absichtlich boykottieren...eher nein, da genau dieser andere an 50% der potenziellen Endabnehmer liefert.

Was keiner weiss macht keinen heiss. Normalerweise schaut ja keiner einer Engine dermassen auf die Finger. Ich kann das ja auch nur machen weil ich eben gerade an einem entsprechenden Tool arbeite. Ohne dieses würde ich die ganzen Sachen auch nicht sehen.

[Dr Hake]

Doch, indirekt schon, falls es sich um die fuer Performance relevanten Shader handelt. Falls pp16 keinen Geschwindigkeitszuwachs bringt, brauchst du sie nicht zu setzen, falls es einen Zuwachs bringt, aber mit Fehldarstellungen verbunden ist, darfst du sie nicht setzen. Was bleibt fuer den speziellen Pfad? Der von Demi gezeigte Wassershader waere sicher nicht zu verachten, und falls pp16 bei allen Wassershadern (nur eine Annahme, ich versuche nur das warum zu verstehen, fuer das wie fehlen mir die Kenntnisse) im ganzen Game keine Fehldarstellung verursachen wuerde, haette Valve imo den Fxen dieses Goodie spendiert.
Aus Sicht des Users ist es problemlos moeglich Szenen zu zeigen wo es funktionniert, der Publisher hingegen steh t in der Pflicht dass das Spiel ohne wenn und aber auf der jeweiligen Hardware laeuft.
Evtl kommt ja eines Tages noch ein Patch?

[Quasar]

AFAIK beinhaltete der FX-Pfad nicht nur FP16, sondern auch die stellenweise Nutzung von DX8-Shadern. =)

[Dr Hake]

@ Demirug
bei allem Respekt fuer deine ohne Zweifel hervorragende Arbeit: das Netz ist so allumfassend geworden, und es tummeln sich viele Koenner darin herum, dass es frueher oder spaeter herauskommt. ein ISV der das nicht kapiert hat gehoert geteert und gefedert.

[Demirug]

AFAIK beinhaltete der FX-Pfad nicht nur FP16, sondern auch die stellenweise Nutzung von DX8-Shadern. =)

Es gab zwei FX Pfade. Der eine hat nur 2er Shader aber mit entsprechend gesetzten PP Flags. Der zweite war der 8.1 Pfad mit 2er Shader für die Effekte wo es wirklich eine merkliche optische Verbessung gab.

[Demirug]

@ Demirug
bei allem Respekt fuer deine ohne Zweifel hervorragende Arbeit: das Netz ist so allumfassend geworden, und es tummeln sich viele Koenner darin herum, dass es frueher oder spaeter herauskommt. ein ISV der das nicht kapiert hat gehoert geteert und gefedert.

Das Netz mag gross sein aber durchaus auch sehr langsam. Es hat auf jeden Fall sehr lange gebraucht bis es auf den FP16 Trick gekommen ist.

Zudem stellt die Gruppe welche sich für sowas interesiert keinen ausreichende Machtfaktor da um einen ISV ernsthaft zu gefärden.

[Quasar]

Es gab zwei FX Pfade. Der eine hat nur 2er Shader aber mit entsprechend gesetzten PP Flags. Der zweite war der 8.1 Pfad mit 2er Shader für die Effekte wo es wirklich eine merkliche optische Verbessung gab.
Den zweiten meine ich. :)
Welche logischen Gründe könnte es geben, diesen zu entfernen, wenn er schon vor einem Jahr die fünffache Optimierungszeit ggü. dem "normalen" Pfad verschlungen hatte?

[Crushinator]

*Doom3-Diskussion so weit wie möglich dahin (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=188278) gesplittet*

[reunion]

Den zweiten meine ich. :)
Welche logischen Gründe könnte es geben, diesen zu entfernen, wenn er schon vor einem Jahr die fünffache Optimierungszeit ggü. dem "normalen" Pfad verschlungen hatte?

Vielleicht um den Programmcode zu "straffen" :ugly:

[Quasar]

Vielleicht um den Programmcode zu "straffen" :ugly:
Möglich - wozu dann aber bsw. ein DX6-Pfad?
Vermutung: Heute nutzen mehr Gamer, die in die Zielgruppe von HL2 fallen, eine GFFX als ein DX6-Karte.

[Pirx]

Der Takt der Pro ist 35,7% höher und sie ist nur 29% schneller.
^^
Man sollte Dinge nicht so eindimensional sehen...
Du hast schon wieder den höheren Speichertakt der GT vergessen.

[Gast]

Du hast schon wieder den höheren Speichertakt der GT vergessen.
Prinzipell ACK.
HL2 ist jedoch Shader limitiert. Sieht man daran, daß selbst in 1600x1200 mit 4xAA die PRO schneller ist.
http://www.xbitlabs.com/articles/video/display/half-life_7.html

[Gast]

Du hast schon wieder den höheren Speichertakt der GT vergessen.
Mit Absicht, als abschreckendes Beispiel. Siehe meine Bemerkung zur Eindimensionalität.

Q

[Pirx]

Mit Absicht, als abschreckendes Beispiel. Siehe meine Bemerkung zur Eindimensionalität.

Q
Jaja, das war ja klar.;)

[Gast]

Jaja, das war ja klar.;)
Ebenso klar, daß subtile Hinweise nicht erkannt werden, wenn sie nicht mit einem Übermaß an blinkenden und winkenden Smileys garniert werden. ;) ;) :ulol: :devil:

Q

[r@h]

1. vielleicht sind sie trotzdem da, ich gehe nicht davon aus dass du das ganze Game mit beiden parallel gespielt hast, um auf Unterschiede zu achten. Evtl erscheint dir auch auf Stellen das von der Fx gerenderte korrekt (und auch visuell nicht zu beanstanden) da du den anderen Pfad in eben diesen Szenen nicht gesehen hast. Valve und nV als Firmen stuenden schoen am Pranger wenn das Resultat sich als unterschiedlich herausstellen wuerde. UU wuerde nV mal wieder Ch.. nachgesagtWenn ich mehr Zeit finde, werde ich mir das ganz sicher nochmal "Head-to-Head" anschaun'. Die Möglichkeiten hab' ich hier zuhause dafür (FX5200 vs. R9800p, da die ATI nicht im BX laufen will und ich meinem BX'chen weder die FX noch die 68 zumuten möchte ;-).

Bis dato konnte ich keine Unterschiede ausmachen und das bezieht sich durchaus auf identischen Scenen (dem Water Hazard-Level z.Bsp).
;)

2. dessen bin ich mir bewusst, allerdings stellt sich die Frage ob auch hier (bei den bewusst gesetzten pps) das Resultat den Erwartungen entsprach und nicht ploetzlich irgendwelche Bugs auftauchten..Demis Kommentar laesst ja irgendwie darauf schliessen.
Im Endeffekt glaube ich kann man Valve hoechstens dahingehend verdammen dass sie bei der Programmierung der Engine nur auf Ati geschaut haben, und sich nicht bewusst waren dass es unmoeglich ist nachtraeglich einen Fx Pfad einzubringen, anstatt schon bei der Designphase auf Fx Ansprueche einzugehen.Die pp-Hints können ohne Probleme auch nachträglich eingefügt werden. Die 'Erkennung' unterschiedlicher Hardware ist unter DX ein Einzeiler... zumal Valve ja soagr die VendorID (nebst DeviceID) sogar in der Registery speichert, wohl um sie dann 'InGame' zu verwenden (siehe hierzu auch unterschiedliche Hersteller/Device-'Einstellungen' in der dxsupport.cfg). Also auch das Reagieren auf unterschiedliche Hardware, wie sogar eine 'Andersbehandlung' von ATI-Hartdware (Centriod-Hack = Setzen von pp-Hints bei den vertex-Shadern), die noch immer implementiert ist und sich direkt auf die auszuführenden Shader auswirkt.

Sorry, aber die Engine wird - ähnlich der ID-Engine - schon möglichst flexibell ausgelegt sein, um es auch späteren Nutzern (Lizenznehmern) dieser zu ermöglichen, diese so zu nutzen, wie diese gedenken (siehe hierzu auch Vampires2: Bloodlines).

Nein, der eigentliche NV3x-Pfad würde absichtlich entfernt und die Engine scheint auf ATI 'geeicht' zu sein. Demirug will ja sogar einen "IntelliPrecision" (TM@Demirug ;-) schreiben, der sogar felxibel auf die Situation reagieren kann. Insofern wäre es doch für Valve sehr viel einfacher, schon vorher bewußt nur die Präzision zu nutzen, die auch gebraucht wird. Und das taten sie auch... nur tun sie es jetzt nicht mehr.

Und wenn es eine bessere Erklärung geben sollte, als dass hier ein IHV bewußt massiv benachteiligt wird, dann muss sich Valve dazu äussern. Und die Antwort müsste dann auch den Experten da draußen (wie Demirug z.Bsp.) stand halten... und dies dürfte der Grund sein, warum in dieser Hinsicht noch gar nichts von Valve gekommen ist.

Den Rest kann man sich eigentlich denken, oder?

Razor

[r@h]

Mal abwarten was Demi dazu noch herausfindet. An einen designtechnischen Unfall glaub ich allerdings nicht.Beruhigend...
:up:

Razor

[r@h]

..die gibt es u.a. hier. :)

http://images.anandtech.com/reviews/video/HalfLife2/AT_hl2_demos.zip

cu
BUGThx alot!
:up:

Den vergleich habe ich schon fertig, dazu gleich mehr...

Razor

[r@h]

Weil der nV40 einige Dinge in FP16 dank seines vierfachen Split und zusätzlicher Einheiten quasi nebenbei erledigen kann, während dies in FP32 u.U. mehr als einen Takt kostet und/oder alle vier Kanäle zugleich belegt.Ah ja... thx.
Allerdings wiederspricht dies meinen 'Messungen', nachdem der fp16-'Pfad' auf dem NV40 sogar langsamer ist, als der originale fp32-'Pfad'. Kann aber natürlich auch am 3DC liegen...

Kann jemand dazu vielleicht was sagen?

Razor

P.S.: Details gleich... ;)

[r@h]

+70,5% habe ich bisher gesehen.Bei mir waren's 76,8%...

[r@h]

@ Demirug
bei allem Respekt fuer deine ohne Zweifel hervorragende Arbeit: das Netz ist so allumfassend geworden, und es tummeln sich viele Koenner darin herum, dass es frueher oder spaeter herauskommt. ein ISV der das nicht kapiert hat gehoert geteert und gefedert.Was im Falle von Valve sogar noch auf andere 'Aspekte' auszudehnen ist.
Steam ist echt ein gewaltiger Tritt in den Arsch!
Aber das ist hier OT...

Razor

[Gast]

Ah ja... thx.
Allerdings wiederspricht dies meinen 'Messungen', nachdem der fp16-'Pfad' auf dem NV40 sogar langsamer ist, als der originale fp32-'Pfad'. Kann aber natürlich auch am 3DC liegen...

Kann jemand dazu vielleicht was sagen?

Razor

P.S.: Details gleich... ;)

Nicht "Pfad", sondern reine Pixelshaderleistung - losgelöst von Games. ;)

Q

[Demirug]

Ah ja... thx.
Allerdings wiederspricht dies meinen 'Messungen', nachdem der fp16-'Pfad' auf dem NV40 sogar langsamer ist, als der originale fp32-'Pfad'. Kann aber natürlich auch am 3DC liegen...

Kann jemand dazu vielleicht was sagen?

Razor

P.S.: Details gleich... ;)

Es könnte sein das der Shadercompiler bei kurzen Shadern mit FP16 manchmal Mist baut. Einen solchen Effekt habe ich beim NV40 schon mal beobachtet. Da hat die FP16 Variante plötzlich einen Takt mehr als die FP32 Variante gebraucht. Möglicherweise ein Problem beim Zugriff auf das Registerfile.

[r@h]

Nicht "Pfad", sondern reine Pixelshaderleistung - losgelöst von Games. ;)So habe ich es auch verstaden... ;)
Oki!

Razor

[r@h]

Es könnte sein das der Shadercompiler bei kurzen Shadern mit FP16 manchmal Mist baut. Einen solchen Effekt habe ich beim NV40 schon mal beobachtet. Da hat die FP16 Variante plötzlich einen Takt mehr als die FP32 Variante gebraucht. Möglicherweise ein Problem beim Zugriff auf das Registerfile.So etwas in der Richtung hatte ich auch im Verdacht...
Insofern wir nun tatsächlich eine RealWorld-Situation gefunden zu haben scheinen (Vorsicht ist die Mutter... ;-), wo dies tatsächlich zutrifft.

Razor

[r@h]

Soderle...

Dank dem Verweis von BUG auf die AT-Timedemos, habe ich jetzt mal versucht, seine Beobachtung nachzustellen.
(die von Blackbird konnte ich nicht nachstellen, da ich ohne Savegame die Stelle nicht wieder finden konnte ;-)

Ich beziehe mich hierbei auf den Post 124 (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=2510738&postcount=124) dieses Threads.
(der mit den heftigen Schattenfehlern beim fp16-'Pfad' ;-)

Um es gleich vorweg zu nehmen: Bei mir (!) gab es KEINE Fehler!
Aber der Reihe nach...

Ich bin wie BUG vorgegangen... so habe ich auf dem NV40 den originalen Rederpfad dem via 3DA erzwungenen gegenüber gestellt. Zusätzlich habe ich noch die Shader mit loggen lassen, um sicher zu stellen, dass der NV40 auch wirklich die pp-Hints 'vorgesetzt' bekommt.

Basis für diesen Vergleich war das Timedemo "at_canals_08" von Anand und irriger Weise musste ich feststellen, dass der erzwungene fp16-'Pfad' auf dem nv40 sogar in weniger fps resultierte, als der originale. So stellte sich das Ganze performance-seitig so dar:

- originaler DX9-Pfad: 73,81/74,14 fps
- 3DC-fp16-DX9-Pfad: 70,52/71,92 fps

Das Ganze ist reproduzierbar (deswegen hier einfach mal zwei Vergleiche) und resultiert also in einem Verlust von runden 3-4%. Merkwürdig... vielleicht fällt unseren Gurus ja was dazu ein...

Wie dem auch sei, es geht hier ja um den Bildvergleich und insofern habe ich mir die von BUG geschilderte Scene einfach mal genauer angeschaut. Und wie schon oben erwähnt war ich nicht in der Lage, Fehler auf meinem Rechner, mit meinem Equipment nachzustellen.

Interessanter weise hat man ja auch - um eben solche Fehler zu vermeiden - in anderen Foren dazu geraten, mit dem ATI-Pfad in HL2 zu gamen. Dazu wird dann der Engine eben via 3DA eine ATI-Karte 'vorgegaukelt'... ich habe weder die Fehler nachvollziehen können, ebenso wenig den dort gemessenen Performance-Zuwachs mit eben diesem. Ich selber habe lediglich die "noUserClipPlanes" für meine FX entfernt und schon gab's feinstes Wasser...

Wie dem auch sei, hier der Vergleich:

http://mitglied.lycos.de/razor3dc/hl2/6702_hl2-canals08_6800_fp16.jpg (http://mitglied.lycos.de/razor3dc/hl2/6702_hl2-canals08_6800_fp16.png) http://mitglied.lycos.de/razor3dc/hl2/6702_hl2-canals08_6800_fp32.jpg (http://mitglied.lycos.de/razor3dc/hl2/6702_hl2-canals08_6800_fp32.png)

Mit "The Compressonator" (ein ATI-Tool ;-) habe ich einen Bildvergleich durchgeführt, der die Unterschiede aufzeigt, da diese IMO mit dem bloßen Auge nicht auszumachen waren.

Da es aber keine Möglichkeit gab (oder ich habe diese nicht gefunden ;-), den Vergleich abzuspeichern, musste ich einen Screen-Shot davon anfertigen, um diesen hier posten zu können. Da ich aber oben die Originale eingefügt habe, steht es jedem Frei den Vergleich mit diesen selber nachzuvollziehen.

http://mitglied.lycos.de/razor3dc/hl2/6702_hl2-canals08_6800_vergl.jpg (http://mitglied.lycos.de/razor3dc/hl2/6702_hl2-canals08_6800_vergl.png)

Und damit die Unterschiede deutlicher werden, gibt's in dem Proggi noch die Möglichkeit, den Kontrast des Differenzbildes zu erhöhen. Das nun folgende Bildchen also dazu dient, die Unterschiede hervorzuheben.

http://mitglied.lycos.de/razor3dc/hl2/6702_hl2-canals08_6800_vergl_bright.jpg (http://mitglied.lycos.de/razor3dc/hl2/6702_hl2-canals08_6800_vergl_bright.png)

Wie ihr also sehen könnt, sind zwar Unterscheide vorhanden, nur dürften diese selbst dem geübten Auge nicht auffallen. Es gibt andere Stellen, wo ganz offensichtlich Overbright-Effekte im fp16-Pfad anders aussehen (sind schwächer), als im original, aber das habe ich ja bereits erwähnt.

Ganz offensichtlich gibt es aber keinesfalls solche Fehler, wie sie BUG dargestellt hat. Ich will damit nicht anzweifeln, dass er diese hat, nur liegt dies offenbar nicht an dem fp16-'Pfad' des 3DA, wenn ich diese nicht habe. So sollte die Ursache hierfür woanders zu finden sein.

Allerdings muss man mit dem 3DA schon ein bissel aufpassen. So gibt es tatsächlich Grafik-Korruptionen, wenn man z.Bsp. Scenen immer wieder läd, oder auch analog dazu, bestimmte Timedemos immer wieder abspielt. Plötzlich wird der Schatten pink dargestellt oder aber Schatten. Beleuchtungseffekte oder ähnliches fehlt vollständig. Beim Spielen (also dem normalen Ablauf in der Engine) ist dies allerings bei mir NIE passiert, muss also wohl 'irgendwie' mit was anderem zusammen hängen...

Ich versichere, dass ich versucht habe, möglichst alle Fehlerquellen auszuschließen. Deswegen auch das Mitloggen der Shader, das Verifizieren der hier getätigten Aussagen an anderen Stellen in dem Timedemo und die Überprüfung derer durch Wiederholung... etcpp.

Was sagt ihr also zu meinem Vergleich?
Bin ja mal gespannt, was euch dazu einfällt.

Razor

P.S.: ich habe bei den Vergleichen absichtlich nicht dazu geschreiben, was jetzt fp16 ist und was nicht... :)

[TobiWahnKenobi]

mich würde mal interessieren, wie sich andere spiele mit der HL2 engine verhalten. ich habe mir vampire2 gegönnt. das sollte eigentlich die HL2 engine nutzen. jedenfalls sieht's dort eher aus, als wäre ich in einer DX9 welt unterwegs
(wg. dem wasser und der spiegelungen denke ich das mal)..

spielbar ist es eigentlich (zumindest mit meiner karte); ein DX8 mode lässt sich nirgends auswählen. auch scheinen die konsolenbefehle andere zu sein..

geht euch das zu sehr offtoppic?

greets
tobi

ps. auf eine abhilfe seitens NV brauchen wir aus meiner sicht nicht mehr zu hoffen, weil mit steigenden NV4x marktanteilen, sicher wieder die support-abteilung für die FX eingespart wird.

[BUG]

@Razor
..also ich habe gerade alles mögliche durchprobiert, bei mir geht es mit FP16 einfach nicht richtig, ich bekomme immer das gleiche (fehlerhafte) Bild wenn ich mit dem 3DA FP16 "force". Ich habe auch die Shader.log anlegen lassen und die PP-Flags sind auch alle gesetzt, habe sogar mal den ATI Pfad probiert --> selber Fehler. Ich nutze den FW 67.02 und den 3DA v2.34. :confused:

..wenn ich mit dem 3DA "force high precision pixel shader" auswäle funktioniert es ohne Bildfehler (sieht ganz normal aus, ist aber bei mir in der TimeDemo etwas langsamer als ohne 3DA), also ich habe echt keine Ahnung woran es liegen könnte, aber vieleicht ist ja auch mein "stembefreites" HL2 schuld. :|

[Edit]

P.S.: ich habe bei den Vergleichen absichtlich nicht dazu geschreiben, was jetzt fp16 ist und was nicht.....man kann es eraten wenn man auf das Bild klickt, da steht oben der name des Bildes inkl FP1x und FP3x. :tongue:

cu
BUG

[Demirug]

Razor, Bug:

Razore welche 3da Version hast du den benutzt? Vielleicht wurde da ja was an dem code zum erzwingen der PP Hints verändert.

Mir ist nämlich bei meinen eigenen Versuchen auch etwas aufgefallen:

Wenn ich die PP Hints nicht nur an die Anweisungen setzten sondern auch an den Inputregistern (Texturekoordinaten, ...) dann bekomme ich ebenfalls stellenweise schwarze/dunkle Flächen.

[Gast]

P.S.: ich habe bei den Vergleichen absichtlich nicht dazu geschreiben, was jetzt fp16 ist und was nicht... :)

Offensichtlich. Links FP16. REchts FP32.

Dein geübtes Auge macht mir schön langsam Angst (nicht zuletzt wegen deinem AA Statement). Der Unterschied ist imo offensichtlich.


Ausserdem sieht mans im Bildtitel ;)

[Lolman]

Das vorige Post geht (wie wahrscheinlich unschwer zu erkennen), auf meine Kappe.

[BUG]

..habe meine shader.log mit FP16 inkl ein paar Bilder (ingame Settings / 3DA Einstellungen) mal angehängt Demi. :)

klick (http://home.arcor.de/xbugx/Download/HL2/shaders_fp16.out.zip)

cu
BUG

[Jesus]

wie könnt ihr überhaupt HL2 mit 3da starten ? bei mir macht er das garnicht...

Edit: Hab dieselbe Versoin wie bug

[IVN]

wie könnt ihr überhaupt HL2 mit 3da starten ? bei mir macht er das garnicht...

Use the version 3Da 2.26.

[saaya]

sehr nice razor! danke! =)

also ich seh mit blossem auge einen unterschied und den sieht auch garantiert jeder mit blossem auge! besonders wenn man es spielt und sich nicht nur einen eingefrorenen shot ankuckt.

und zwar die lampe im hintergrund.

eindeutiger unterschied... und es kommt mir auch so vor dass die lampe vorbe rechts ein wenig dunkler ist.

aber ist wirlich kaum ein unterschied...

[BUG]

..also ich seh mit blossem auge einen unterschied und den sieht auch garantiert jeder mit blossem auge! besonders wenn man es spielt und sich nicht nur einen eingefrorenen shot ankuckt...also ich glaube wenn man spielt sieht man keinen Unterschied, ganz einfach weil man in dem Moment kein Vergleichsbild hat. ;) ...desweiteren sieht man imho die einzelnen feinen Unterschiede in einem bewegten Bild nicht so deutlich. Im großen und ganzen ist FP16 wenn es durchweg fehlerfrei funktioniert eine tolle sache für Geforce FX User, jedenfals ne nummer besser als dieser DX8.1 Pfad. :)

Edit: ..ja an der Lampe sieht man es recht "deutlich", im Spiel beim vorbeilaufen würde es aber imho nicht auffallen, die Rohre an der Decke sehen auch etwas anders aus. :)

cu
BUG

[Mr. Lolman]

und zwar die lampe im hintergrund.


aber ist wirlich kaum ein unterschied...

Was ist mit den Rohren? IMO der offensichtlichste Unterschied....

[Demirug]

..habe meine shader.log mit FP16 inkl ein paar Bilder (ingame Settings / 3DA Einstellungen) mal angehängt Demi. :)

klick (http://home.arcor.de/xbugx/Download/HL2/shaders_fp16.out.zip)

cu
BUG

Ja, da sind PP Hints an den DCLs. Damit hatte ich auch Bildfehler.

[Jesus]

Was ist mit den Rohren? IMO der offensichtlichste Unterschied....

nicht zu vergessen die wunderbaren Artefakte die die Taschenlampe mit FP16 Erzeugt:

http://nemesis.rushers.net/artefuckte.png

[BUG]

Ja, da sind PP Hints an den DCLs. Damit hatte ich auch Bildfehler...die DCLs dürfen wohl kein PP abbekommen?! ..was ist oder macht DCL eigentlich? ..ist das der Grund wieso es bei mir so "merkwürdig aussieht"?

cu
BUG

[Demirug]

Habe noch was lustiges gefunden.

Die Engine bringt es doch fertig zuerst das schreiben in den Z-Buffer abzuschalten. Danach werden alle 4 Farbkanäle (RGB und Alpha) deaktivieren. Da es keinen Stencilbuffer gibt darf der Chip jetzt nichts mehr in die Buffer schreiben. Das hält die Engine aber nicht davon ab fleisig noch ein paar Dinge rendern zu lassen. Immerhin ist sie dabei aber so nett und selektiert einen Pixelshader (V 1.1) welcher nur weiße Pixel schreibt und einen Vertexshader (V 1.1) welcher nur die Position bestimmt. Allerdings mit einer Anweisung mehr als notwendig. Ich hoffe mal die Treiber sind schlau genug und sortieren diese Objekte aus bevor sie zum Chip gehen.

[Demirug]

..die DCLs dürfen wohl kein PP abbekommen?! ..was ist oder macht DCL eigentlich? ..ist das der Grund wieso es bei mir so "merkwürdig aussieht"?

cu
BUG

DCL ist der Shaderbefehl mit dem ein Eingangsregister DeCLariert wird. Man sagt dem Chip damit das man eben diese Register im Shader benutzen will. Man kann an diese Register auch PP anhängen. Nun scheint es so das nVidia beim NV40 in diesem Fall das Register auf den FP16 Wertbereich begrenzt. IIRC hat man das früher beim NV3X nicht gemacht. Da in diesen Registern auch Texturekoordinaten übergegeben werden kann das nun dazu führen das diese falsch sind und zum Beispiel auf einen falschen Bereich der Lightmap verweisen.

[LordDeath]

also erst meinte man ja, dass half life 2 sauber geproggt wäre und daher auch auf alter hardware super laufen würde. wenn ich mir jetzt demirugs beispiele ansehe, wo irgendwie kein sinn in dem steckt, was das spiel da macht, dann frag ich mich, wie so ne analyse mit anderen games wie z.B. unreal 2 aussehen würde :D

[Jesus]

also erst meinte man ja, dass half life 2 sauber geproggt wäre und daher auch auf alter hardware super laufen würde. wenn ich mir jetzt demirugs beispiele ansehe, wo irgendwie kein sinn in dem steckt, was das spiel da macht, dann frag ich mich, wie so ne analyse mit anderen games wie z.B. unreal 2 aussehen würde :D

Naja es ist wohl nichts perfekt programmiert. Das liegt daran dass immer mehrere Leute an einer Sache dran sind, und der eine oft nicht genau weiss was der andere tut. Dadurch entsteht in der Regel so ein Mist ;) Manchmal probiert man Sachen und entfernt sie hinterher wieder, und manchmal bleiben dann auch solche "Leichen" drin ...

[r@h]

..also ich habe gerade alles mögliche durchprobiert, bei mir geht es mit FP16 einfach nicht richtig, ich bekomme immer das gleiche (fehlerhafte) Bild wenn ich mit dem 3DA FP16 "force". Ich habe auch die Shader.log anlegen lassen und die PP-Flags sind auch alle gesetzt, habe sogar mal den ATI Pfad probiert --> selber Fehler. Ich nutze den FW 67.02 und den 3DA v2.34. :confused:

..wenn ich mit dem 3DA "force high precision pixel shader" auswäle funktioniert es ohne Bildfehler (sieht ganz normal aus, ist aber bei mir in der TimeDemo etwas langsamer als ohne 3DA), also ich habe echt keine Ahnung woran es liegen könnte, aber vieleicht ist ja auch mein "stembefreites" HL2 schuld. :|Vielleicht ist DAS des Rätsels Lösung?
Nicht das "steambefreite" HL2 (ist bei mir genauso), sondern vielleicht 3DA 2.34?
:confused:

Eigentlich benutze ich ausschließlich 2.26 (auch jetzt für HL2), da 2.34 schon bei anderen Gelegenheiten bei mir rum muckte... und nun auch der NV40-fix für ATI-Demos Geschichte ist... macht die neueste Version somit ziemlich nutzlos.

Versuchs einfach mal mit der 2.26!
Die kommst Du u.a. hier: http://www.3dfxzone.it/dir/tools/emutnl.htm

..man kann es eraten wenn man auf das Bild klickt, da steht oben der name des Bildes inkl FP1x und FP3x. :tongue:Bei den Vergleichen meinte ich...
Aber eigentlich ist es ganz leicht, die fp16-Seite heraus zu fischen!
:D

Razor

[r@h]

Razore welche 3da Version hast du den benutzt? Vielleicht wurde da ja was an dem code zum erzwingen der PP Hints verändert.

Mir ist nämlich bei meinen eigenen Versuchen auch etwas aufgefallen:

Wenn ich die PP Hints nicht nur an die Anweisungen setzten sondern auch an den Inputregistern (Texturekoordinaten, ...) dann bekomme ich ebenfalls stellenweise schwarze/dunkle Flächen.Wie gesagt, 2.26...
Und keine Ahnung, ob der 2.34 was anderes macht... interessiert mich eigentlich auch nicht.
(aus den zuvor genannten Gründen)

Aber gut, dass wir dieses 'Detail' noch hervor gefischt haben.
Könnte das "Selbertesten" doch erheblich vereinfachen...
;)

Razor

[r@h]

Das vorige Post geht (wie wahrscheinlich unschwer zu erkennen), auf meine Kappe.War klar...
Aber gut, dass Du die 'Einfachheit' dieses Tests selber erkannt hast.
Auch an den Bildern selbst ist der Unterschied eigentlich sofort ersichtlich... wenn man weiß, worauf man achten muss.

Nur... ist der Unterschied (das Licht an der Wand) tatsächlich relevant?
Ich darf es Dir beantworten: nein!
Beim Spielen schon gar nicht...

Razor

[r@h]

sehr nice razor! danke! =)

also ich seh mit blossem auge einen unterschied und den sieht auch garantiert jeder mit blossem auge! besonders wenn man es spielt und sich nicht nur einen eingefrorenen shot ankuckt.

und zwar die lampe im hintergrund.

eindeutiger unterschied... und es kommt mir auch so vor dass die lampe vorbe rechts ein wenig dunkler ist.

aber ist wirlich kaum ein unterschied...100 Punkte für den Kandidaten!
War aber wirklich nicht schwer, oder?
;)

Ja, Beleuchtungseffekte und auch Overbright-Effekte sind nicht ganz so ausgeprägt. Dies ist allerdings ob der opulenten Gesamtoptik zu verschmerzen... erst recht, wenn man vorher mit einer Diashow oder dem DX8.1-Pfad leben musste.

Bildfehler gab es keine... aber vielleicht haben wir ja jetzt auch des Rätsels Lösung.

Razor

[Mr. Lolman]

War klar...
Aber gut, dass Du die 'Einfachheit' dieses Tests selber erkannt hast.
Auch an den Bildern selbst ist der Unterschied eigentlich sofort ersichtlich... wenn man weiß, worauf man achten muss.

Nur... ist der Unterschied (das Licht an der Wand) tatsächlich relevant?
Ich darf es Dir beantworten: nein!
Beim Spielen schon gar nicht...

Razor


Ich hab eigentlich immer die Rohre gemeint, wenn ich von offentsichtlichen Unterschieden gesprochen hab.

[Jesus]

der Unterschied (das Licht an der Wand) tatsächlich relevant?
Ich darf es Dir beantworten: nein!
Beim Spielen schon gar nicht...

Razor

Klar, wie gesagt, wir brauchen kein SM3.0 weil sieht ja eh fast genauso aus wie mit SM2.0. Daher brauchen wir aber auch kein SM2.0 (oder in dem Fall FP32) weils auch genauso aussieht mit SM 1.x ... eigentlich brauchen wir überhaupt keine Shader :| .

Einerseits wird hier immer von Perfektion gesprochen, super genaues FP32 als muss für SM3 proklamiert und AF natürlich nur ohne Optimierungen und Winkelabhängigkeit brauchbar (sowie mit hoher bitgenauigkeit, zumindest höherer als bei ATI ;) ) andererseits werden dann solche Sachen als "braucht man nicht, sieht man eh kaum etc" hingenommen, auch wenns sogar sehr deutlich auffällt (imo).

Entscheidet euch mal.

[r@h]

Was ist mit den Rohren? IMO der offensichtlichste Unterschied....Du vergißt, dass die Lichtquelle im fp16-Shot nun nicht mehr so hell ist.
Ergo dürfen dann auch die Rohre nicht mehr so 'hell' sein...
;)

nicht zu vergessen die wunderbaren Artefakte die die Taschenlampe mit FP16 Erzeugt:Wo siehst Du denn da bitte Artefakte?
:confused:

Razor

[Noah]

Klar, wie gesagt, wir brauchen kein SM3.0 weil sieht ja eh fast genauso aus wie mit SM2.0. Daher brauchen wir aber auch kein SM2.0 (oder in dem Fall FP32) weils auch genauso aussieht mit SM 1.x ... eigentlich brauchen wir überhaupt keine Shader :| .

Einerseits wird hier immer von Perfektion gesprochen, super genaues FP32 als muss für SM3 proklamiert und AF natürlich nur ohne Optimierungen und Winkelabhängigkeit brauchbar (sowie mit hoher bitgenauigkeit, zumindest höherer als bei ATI ;) ) andererseits werden dann solche Sachen als "braucht man nicht, sieht man eh kaum etc" hingenommen, auch wenns sogar sehr deutlich auffällt (imo).

Entscheidet euch mal.
Meinst du wirklich, dass man seine Meinung über ein umfassendes Thema einfach mal pauschalisiert und auf alles andere anwendet, ob nun sinnvoll oder nicht? Fanboys machen das vielleicht.

[BUG]

Klar, wie gesagt, wir brauchen kein SM3.0 weil sieht ja eh fast genauso aus wie mit SM2.0. Daher brauchen wir aber auch kein SM2.0 (oder in dem Fall FP32) weils auch genauso aussieht mit SM 1.x ... eigentlich brauchen wir überhaupt keine Shader :| .

Einerseits wird hier immer von Perfektion gesprochen, super genaues FP32 als muss für SM3 proklamiert und AF natürlich nur ohne Optimierungen und Winkelabhängigkeit brauchbar (sowie mit hoher bitgenauigkeit, zumindest höherer als bei ATI ;) ) andererseits werden dann solche Sachen als "braucht man nicht, sieht man eh kaum etc" hingenommen, auch wenns sogar sehr deutlich auffällt (imo).

Entscheidet euch mal...das stimmt schon, aber wir "könnten" auf FP32 wechseln wenn uns FP16 zu "ungenau" ist oder Grafik Fehler verursacht :tongue:, beim Winkelabhängigen AF gibt es leider keinen "Schalter" und genau das is der Punkt weshalb sich hier einige so drüber aufgeregt haben. Ich bin mir sicher, das 90% von den Leuten die das Winkelabhängige AF nicht "besonders" mögen diese nutzen würden weil die unterschiede meist nahezu zu vernachlässigen sind und man den zusätzlichen Speed ggf gut gebrauchen kann oder duch höhre Auflösung oder mehr Details eintauschen kann. :) ..aber egal, das wird hier OT. ;)

@Razor
...oki ich probier mal den alten 3DA. :)

cu
BUG

[Skusi]

Hast du nicht ganz unrecht, Jesus.
Ich persönlich würde es gut finden, wenn man grundsätzlich dem Spieler die Wahl läßt, welchen Pfad er verwendet.

[r@h]

Klar, wie gesagt, wir brauchen kein SM3.0 weil sieht ja eh fast genauso aus wie mit SM2.0. Daher brauchen wir aber auch kein SM2.0 (oder in dem Fall FP32) weils auch genauso aussieht mit SM 1.x ... eigentlich brauchen wir überhaupt keine Shader :| .Red' keinen Stuß.
Du weißt, dass ich dies auf die FX-User bezog.
Und für die heißts: DX9 oder DX8.1!

Im übrigen würde mich mal interessieren, ob es einen Unterschied zwischen fp24 und fp32 gibt.
Werde ich morgen vielleicht direkt mal ausprobieren...

Ich würde mich glatt in die Ecke schmeißen, wenn solche Effekte auf den Radeons 'anders' aussehen würden.
Cheat oder was?
:D

Einerseits wird hier immer von Perfektion gesprochen, super genaues FP32 als muss für SM3 proklamiert und AF natürlich nur ohne Optimierungen und Winkelabhängigkeit brauchbar (sowie mit hoher bitgenauigkeit, zumindest höherer als bei ATI ;) ) andererseits werden dann solche Sachen als "braucht man nicht, sieht man eh kaum etc" hingenommen, auch wenns sogar sehr deutlich auffällt (imo).Na... ich hoffe zumindest, dass Du es - zumindest jetzt - verstanden hast.

Razor

P.S.: Shit... morgen ist Family-Treff angesagt... wird also nichts.
(und für mich tierisch langweilig *grmpf*)

[r@h]

Hast du nicht ganz unrecht, Jesus.
Ich persönlich würde es gut finden, wenn man grundsätzlich dem Spieler die Wahl läßt, welchen Pfad er verwendet.Das ist ja genau DAS Problem, was hier diskutiert wird.
Valve läßt den Spielern keine Wahl...

Und der fp16-'Pfad' könnte dazu geeignet sein, wieder eine Wahl zu haben.
Jesus meint ja, dass die Unterscheide zu erheblich sind...

Dann lieber DX8.1!
:down:

Razor

[r@h]

[QUOTE=BUG...oki ich probier mal den alten 3DA. :)[/QUOTE]:up:

[r@h]

...oki ich probier mal den alten 3DA. :):up:

So isses besser... ;)

Razor

[Jesus]

Wo siehst Du denn da bitte Artefakte?
:confused:

Razor

Nein, ich werds nicht extra für dich noch zoomen ... ;)
(braucht man auch nicht, ist mit blossem Auge sichtbar)

[r@h]

Nein, ich werds nicht extra für dich noch zoomen ... ;)
(braucht man auch nicht, ist mit blossem Auge sichtbar)Nö, ist es nicht.
Und nicht einmal ATI's Differenziator hat was gefunden.
;D

Razor

[LovesuckZ]

Klar, wie gesagt, wir brauchen kein SM3.0 weil sieht ja eh fast genauso aus wie mit SM2.0. Daher brauchen wir aber auch kein SM2.0 (oder in dem Fall FP32) weils auch genauso aussieht mit SM 1.x ... eigentlich brauchen wir überhaupt keine Shader :| .

Wenn der Einsatz von 128bit keinen Unterschied zu 8bit macht, warum also Rechenleistung und Speicgerplatz verschwenden?
Daher, stimmte ich dir zu.

Einerseits wird hier immer von Perfektion gesprochen, super genaues FP32 als muss für SM3 proklamiert und AF natürlich nur ohne Optimierungen und Winkelabhängigkeit brauchbar (sowie mit hoher bitgenauigkeit, zumindest höherer als bei ATI ;) ) andererseits werden dann solche Sachen als "braucht man nicht, sieht man eh kaum etc" hingenommen, auch wenns sogar sehr deutlich auffällt (imo).


Wenn mein Ergebnis zwischen 0 - 255 betraegt, wozu sollte ich a) mehr Rechenleistung aufbringen und b) Platz für 64Millionen Moeglichkeiten schaffen?
Aber, was ist, wenn das Ergebnis mal nicht in den, durch die hardware, vordenifierten Bereich passt?

[Jesus]

Nö, ist es nicht.
Und nicht einmal ATI's Differenziator hat was gefunden.
;D

Razor

Zum Glück ist bald Weihnachten, dann kannst du dir nen neuen Monitor schenken lassen ;)

FP 16:
http://nemesis.rushers.net/fp16.png

FP 32:
http://nemesis.rushers.net/fp32.png

[Skusi]

Das ist ja genau DAS Problem, was hier diskutiert wird.
Valve läßt den Spielern keine Wahl...

Und der fp16-'Pfad' könnte dazu geeignet sein, wieder eine Wahl zu haben.
Jesus meint ja, dass die Unterscheide zu erheblich sind...

Dann lieber DX8.1!
:down:

Razor

1. ist mir das klar
2. hätte ich auch schreiben können, daß ich das von Valve voll sch.... finde, daß sie den FP16 Pfad wieder rausgenommen haben. Tue ich aber nicht, da ich mich an einer gewissen Hetzjagt nicht beteiligen will. ;)

Grundsätzlich ist es doch von V. sehr löblich div. Renderpfade für ihr Spiel anzubieten.Schade, aber hier kaum zu ergründen, haben sie den FP16 Pfad wieder raugenommen, obwohl er für eine Anzahl User Vorteile hat.
FP16 stellt aber eine Reduzierung der Genauigkeit dar. Und das war das, was Jesus mit seinem Post wohl meinte. Einige, die sonst bei jedem/jeder Cheating/Optimierung sich hier im Forum kritisch äußern, finden auf einmal FP16(obwohl man deutliche BQ Unterschiede zu FP24 sehen kann.) vollkommen in Ordnung.
Und meine Meinung ist, daß ich zwar immer die von meiner GraKa größtmöglich darstellbare Quali haben möchte, aber bei Bedarf auch auf schnellere,ungenauere Rendermodi umschalten kann.

[BUG]

Vielleicht ist DAS des Rätsels Lösung?

Versuchs einfach mal mit der 2.26!
Die kommst Du u.a. hier: http://www.3dfxzone.it/dir/tools/emutnl.htm

Razor..das wars. :up: ..mit dem 3DA 2.26 gibt es keine Fehler mehr mit FP16, die PP Hints an den DCLs sind auch nicht mehr vorhanden in der shader.log. :)

:uidea:

cu
BUG

[IVN]

Zum Glück ist bald Weihnachten, dann kannst du dir nen neuen Monitor schenken lassen ;)

FP 16:
http://nemesis.rushers.net/fp16.png

FP 32:
http://nemesis.rushers.net/fp32.png


It would be very nice to see those pictures in the same size.This what you show here looks like an enlargement artefact and surely not like FP32-16 one.

[Jesus]

It would be very nice to see those pictures in the same size.This what you show here looks like an enlargement artefact and surely not like FP32-16 one.

Beide 400%, sieht man aber auch bereits mit blossem auge auf den unvergrösserten Bildern (also ich sehs :rolleyes: )

[IVN]

Beide 400%, sieht man aber auch bereits mit blossem auge auf den unvergrösserten Bildern (also ich sehs :rolleyes: )

Is it possible to see it at 100% ?

[Jesus]

Is it possible to see it at 100% ?

nicht zu vergessen die wunderbaren Artefakte die die Taschenlampe mit FP16 Erzeugt:

http://nemesis.rushers.net/artefuckte.png

Das original ist 2 Seiten vorher ;)

/Edit: sieht fast so aus wie die Schatten bei NV und FC,naja nicht ganz so schlimm ;)

[Coda]

Man sollte dabei auch beachten, dass man nicht für alles FP16 verwenden muss.

[Jesus]

Man sollte dabei auch beachten, dass man nicht für alles FP16 verwenden muss.

oder darf ;)

[LovesuckZ]

FP16 stellt aber eine Reduzierung der Genauigkeit dar.

Es zaehlt das Endergebnis und nicht die zur Verfuegung gestellte Genaugkeit.
Wenn du kein unterschied zwischen 8bit und 128bit erkennst, ist dann 8bit "eine Reduzierung der Genauigkeit"? ;)

[IVN]

Das original ist 2 Seiten vorher ;)

/Edit: sieht fast so aus wie die Schatten bei NV und FC,naja nicht ganz so schlimm ;)

Hmm,hard to see,but it is there.I doubt that i would see it while playing the game.If FP16 really brings 70% + performance i could live with this failure.

[Skusi]

Es zaehlt das Endergebnis und nicht die zur Verfuegung gestellte Genaugkeit.
Wenn du kein unterschied zwischen 8bit und 128bit erkennst, ist dann 8bit "eine Reduzierung der Genauigkeit"? ;)

Ja.

[LovesuckZ]

Ja.

Inwiefern?

[r@h]

It would be very nice to see those pictures in the same size.This what you show here looks like an enlargement artefact and surely not like FP32-16 one.No, he's right.
But you wouldn't see it while you are gaming...

Of course, if you enlarge it more and more, you will see a difference.
I would wonder if not.

See them in an 4x enlargement:

http://mitglied.lycos.de/razor3dc/hl2/6702_hl2-canals08_6800_vergl2.png

Yeah, the difference is obviously intolerablly!
:D

Razor

[Mr. Lolman]

If FP16 really brings 70% + performance i could live with this failure.

Das ist nur der Idealfall. In ner bestimmten Demo/Auflösung/BQ Einstellung. Aber ich gehe davon aus, dass für FX Karten mit einem artefaktfreien DX9 Pfad und auf HL² optimierte Treiber ~50% Mehrleistung drinnen sind. Blöderweise wär damit ne FX5950 tw. gerade mal nur auf 9600 - 9600pro Niveau...

/BTW: razors Benchmarks entstanden doch auf ner FX, oder?

[r@h]

Beide 400%, sieht man aber auch bereits mit blossem auge auf den unvergrösserten Bildern (also ich sehs :rolleyes: )Vielleicht in einem Abstand von 4cm zum Bildschirm!
:hammer:

Nein, beim Spielen auf normalen Displays im normalen Abstand sieht man es keinesfalls...

Razor

[r@h]

Das ist nur der Idealfall. In ner bestimmten Demo/Auflösung/BQ Einstellung. Aber ich gehe davon aus, dass für FX Karten mit einem artefaktfreien DX9 Pfad und auf HL² optimierte Treiber ~50% Mehrleistung drinnen sind. Ich gah' mal so von der doppelten Performance aus...
Und wenn man sogar noch diese ganzen Ungereimtheiten entfernt, mit denen sich die Treiber bei dieser Engine so auseinander setzen müssen, dann vielleicht sogar noch mehr.

Ich vermute allerdings, dass da bei ATI nicht mehr allzuviel heraus zu holen ist, schließlich hatten sie ja lange genug Zeit zu 'üben', oder? Es sei denn, sie halten derzeit absichtlich noch Leistung zurück...
:D

Razor

[Jesus]

Vielleicht in einem Abstand von 4cm zum Bildschirm!
:hammer:

Nein, beim Spielen auf normalen Displays im normalen Abstand sieht man es keinesfalls...

Razor

Ne sorry, es ist mir sofort aufgefallen, ohne zu Zoomen und dass obwohl ich ne 1280er Auflösung fahre, das Bild war bei mir also noch kleiner ;)

Und in Bewegung siehts sicher auch ganz toll aus, eine sich fortpflanzende Artefakt-Schnecke :biggrin: Ich glaube in Bewegung sieht mans noch beser als auf dem Bild, vielleicht nicht auf den ersten Blick (und schon gar nicht wenn man nichts anderes kennt) aber sehen wird mans.

[Mr. Lolman]

Ich gah' mal so von der doppelten Performance aus...
Und wenn man sogar noch diese ganzen Ungereimtheiten entfernt, mit denen sich die Treiber bei dieser Engine so auseinander setzen müssen, dann vielleicht sogar noch mehr.


Imo sind 100% wohl das in Einzelfällen zu erwartende Maximum was man mittels Treiberoptimierung noch gut machen könnte. Aber das ist schon eher sehr optimistisch. Vll. wagts Demi ja, ne kleine Schätzung abzugeben? :)


Ich vermute allerdings, dass da bei ATI nicht mehr allzuviel heraus zu holen ist, schließlich hatten sie ja lange genug Zeit zu 'üben', oder? Es sei denn, sie halten derzeit absichtlich noch Leistung zurück...
:D

Razor

Seh ich genauso. Allerdings glaub ich nicht, dass (bei den HighEnd Modellen) schon jemals absichtlich irgendwo Leistung zurückgehalten wurde*

*außer wahrscheinlich tw. beim auslaufenden Highendmodellen, um den eigenen Nachfolger etwas pushen zu können. (bspw. Cat3.2)

[Skusi]

Inwiefern?

Insofern, daß 8Bit ungenauer als 128Bit sind.
Ob ich das erkenne, ist eine subkjektive Wahrnehmung.
Wenn ich mit 128Bit rechne und mein Auge die feinere Auflösung nicht erkennt, ist das Ergebniss trotzdem Genauer.
Für mich selbst (hab keine FX) ist es ja sogar Ok, wenn eine etwas schlechtere BQ (die trotzdem sehr gut aussieht) besser läuft.
Grundsätzlich ist es doch eh sehr subjektiv, wann eine BQ so schlecht ist, daß man sie nicht ertragen kann. Darum bin ich ja auch dafür, dem User alle auf seiner Hardware möglichen Rendermodi zur Verfügung zu stellen.

[IVN]

No, he's right.
But you wouldn't see it while you are gaming...

Of course, if you enlarge it more and more, you will see a difference.
I would wonder if not.

See them in an 4x enlargement:

http://mitglied.lycos.de/razor3dc/hl2/6702_hl2-canals08_6800_vergl2.png

Yeah, the difference is obviously intolerablly!
:D

Razor

Read my last posting.

[r@h]

Imo sind 100% wohl das in Einzelfällen zu erwartende Maximum was man mittels Treiberoptimierung noch gut machen könnte. Aber das ist schon eher sehr optimistisch. Vll. wagts Demi ja, ne kleine Schätzung abzugeben? :)Ausschließlich per Treiber?
Niemals!

Da müsste Valve schon mit ran...

Seh ich genauso. Allerdings glaub ich nicht, dass (bei den HighEnd Modellen) schon jemals absichtlich irgendwo Leistung zurückgehalten wurde*

*außer wahrscheinlich tw. beim auslaufenden Highendmodellen, um den eigenen Nachfolger etwas pushen zu können. (bspw. Cat3.2) Jo... oder der Abstand ist so groß, dass beim 'Näherkommen' des Konkurrenten, ein Treiber wahre Wunder bringen könnte... selbiges gilt im übrigen auch für eine evetuell wenig 'neue' Architektur... aber das hast Du ja im Prinzip auch gesagt.

Ein Schelm, wer dabei böses denkt...
;)

Razor

[r@h]

Read my last posting.Now I've read it...
So you can follow my opinion?

It's my point of view... of course.
And for the NV4x not only the IQ decreases, the performace follows right away.

Razor

[Quasar]

Entscheidet euch mal.
Euch? Kann sich nicht jeder für sich selbst entscheiden?

[LovesuckZ]

Insofern, daß 8Bit ungenauer als 128Bit sind.

Das stimmt natuerlich, aber es geht doch eher darum, dass Jesus sich beschwaere, dass es Menschen gibt, die FP32 loben, aber gleichzeitig, bei einem gleichem Ergebnis (bzw. sehr deutlich aehnlichen) die vewendung einer geringeren genauigkeiten (kannst auch Shadermodell einsetzen) beführworten.

Ob ich das erkenne, ist eine subkjektive Wahrnehmung.

Bei mathematisch gleichen Ergebnissen sollte ist es objektiv eindeutig.
Subjektiv gesehen müsste man von Annaeherungen (wie zum beispiel weniger Kommastellen) stellen reden.

Wenn ich mit 128Bit rechne und mein Auge die feinere Auflösung nicht erkennt, ist das Ergebniss trotzdem Genauer.

Aber auch nur, wenn das Resultat von der hoheren Genauigkeit profitiert.
Reicht schon 8bit aus für ein 100% Ergebnis, bringt alles darueber keine Besserung jeglicher Art mehr.