CS:S VST - NV3x vs. R350 [Archiv]

r@h

2004-08-29, 10:28:22

Hiho liebe Leutz,

habe gerade was seeeeehhhhhrrrr Interessantes zu diesem "Stress Test" von Valve heraus gefunden!
Man möge mir verzeihen, wenn dieses Thema schon anderweitig diktutiert wird...

Mir war halt langweilig, weil der neue FW 65.73 WHQL so gar keinen Grund zur Kritik lieferte und alles lief, wie es sollte und so habe ich nochmal spaßeshalber in den 'Zugaben' der R9800 gewühlt und doch tatsächlich ein sog. "HL2 Voucher" heraus gefischt. Nu jo, dachte ich mir, melde ich mich doch mal bei Valve's Steam an (vorsichtshalber mit einem geghosteten System ;-) und zieh mir dieses CS:S-Zeugs nebst VST und probier damit mal ein bissel rum.

Ja, es war wirklich außerordentlich interessant...
:D

Und da es ja doch wohl ganz erhebliche Unterschiede zwischen ATI und nVidia geben soll (die FX'en nicht im DX9-Pfad laufen) habe ich zusätzlich das gute alte 3DA (V2.34) heraus gekramt und mit meiner R9800p gegen gecheckt. 3DA hat es tatsächlich geschafft, der CS:S-Engine mit der FX5900 eine R9800p 'vorzugaukeln'... aber das nur am Rande.

Habe dann mal ein bissel gebencht und das ist dabei heraus gekommen:
(diese Werte dienen nicht als Vergleich zu anderen Systemen, sondern lediglich internen Zwecken und sollen niemanden 'ermutigen' seine eigenen Werte diesen gegenüber zu stellen!)

no AA/AF 2xAA/4xAF Diff

FX5900 88,99 fps 71,06 fps - 20,1%
FX5900@R9800p 38,51 fps 32,66 fps - 15,2%

Diff - 56,7% - 54,0%Jo, nett...
Somit ist klar, warum Valve die FX'en nicht auf dem R300-Pfad laufen läßt!
(satte 55% Performance-Verlust sind echt nicht schlecht ;-)
:D

Das reichte mir aber noch nicht...

So habe ich dann mal wieder dieses äusserst nützliche Tool 3DA hinzu gezogen und mal die Shader auslesen lassen.
Und DAS war nun wirklich äusserst überraschend!
(links NV3x, rechts R350)

http://mitglied.lycos.de/razor3dc/pics/vst_shader_nv3x_r350.png

Bumm!

Ganze 47 PS1.x-Shader haben heftige 505 PS1.x/PS2.0-Shader abgelöst?
Über 1400 Vertex-Shader der Version 2.0 bei ATI?
Was soll das?
:confused:

Der BQ-Unterschied ist dabei zudem absolut zu vernachlässigen...

Vielleicht fällt unseren Gurus ja was dazu ein, aber ich vermute doch wirklich stark, dass die niedrige Performance der FX'en im R300-Pfad weniger was mit schlechter Pixel-Shader-Performance (wie ja sonst immer postuliert) zu tun hat.

Mal schaun', was Euch dazu so einfällt...

Razor

P.S.: sollten die gleichen Fakten schon woanders diskutiert werden, bitte diesen Post dorthin verschieben...
Thx@Mods!

Demirug

2004-08-29, 10:49:32

Das passt alles so schon.

Der DX8 und DX9 Pfad der Source-Engine arbeiten was das Shadermanagment angeht doch sehr unterschiedlich. Dies führt zu den grossen Unterschieden in der Anzahl.

Die meisten der 2.0 Shader im DX9 Pfad sollten dabei relative kurz sein und damit genau zu der Gruppe von Shadern gehören welche die NV3X Chips nun überhaupt nicht mögen. Die fehlenden PP Flags verschärfen die Lage natürlich noch.

r@h

2004-08-29, 11:08:54

Danke Demirug für Deine Antwort...

Aber wie ist dann der geringe qualitative Unterschied des DX8.1-Pfades zum DX9-Pfad zu erklären?
Wie ist es zu erklären dass man mit 47 PS1.x und 705 VS1.1 Shadern nahezu die gleiche Optik erreicht, wie mit 505 PS1.x/PS2.0 und 1733 VS1.1/VS2.0 Shadern?

Das selbst NV40-Karten schwer an diesem Wust von Shadern zu knabbern haben, verwundert mich nun überhaupt nicht mehr... überhaupt würde mich mal interessieren, ob X800 & 6800 nun die gleichen Shader vorgesetzt bekommen oder ob diese dann auch different sind.

Wer's selbst mal probieren möchte, legt sich eine Batch-Datei zur HL2.exe an, welche auch gleich die Parameter für den Steam-Start mit aufruft. Diese Batch-Datei dann einfach mit dem 3DA starten und vorher die Ausgabe der "shader.out" aktivieren.

Alternativ könnte man mir auch mal die Vendor- und Device-ID solcher Karten nennen, da ich wette, dass diese Pfade ebenfalls auf einer stinknormalen FX laufen werden.

Thx in advance.

Mir kommt das Ganze wirklich mehr als 'spanisch' vor!

Razor

Demirug

2004-08-29, 11:20:51

Die Menge an Shadern ist sekundär was die Performance angeht.

Das der DX9 Pfad mehr Shader als der DX8.1 Pfad hat liegt an der höheren Spezialisierung der DX9 Shader. Beim DX9 Pfad hat man für jede mögliche Effekt Variante einen eigenen Shader. Beim DX8 Pfad hat man nur eine begrenzte Anzahl von Shader und wenn man eine Variante braucht die es nicht in nativer Form gibt wird eben die genommen die dem ganzen am nächsten kommt und die überflüssigen Teile des Shaders so mit Werten versorgt das sie sich neutral im Bezug auf das Ergebniss verhalten.

NV40:
VendorId = 0x000010DE
DeviceId = 0x00000040

R420:
VendorId = 0x00001002
DeviceId = 0x00004a50

r@h

2004-08-29, 15:15:18

Die Menge an Shadern ist sekundär was die Performance angeht. OK...

Das der DX9 Pfad mehr Shader als der DX8.1 Pfad hat liegt an der höheren Spezialisierung der DX9 Shader. Beim DX9 Pfad hat man für jede mögliche Effekt Variante einen eigenen Shader. Beim DX8 Pfad hat man nur eine begrenzte Anzahl von Shader und wenn man eine Variante braucht die es nicht in nativer Form gibt wird eben die genommen die dem ganzen am nächsten kommt und die überflüssigen Teile des Shaders so mit Werten versorgt das sie sich neutral im Bezug auf das Ergebniss verhalten.Hmmm...
Also dann bin ich wirklich mal gespannt, wo da tatsächlich ein Unterschied zu sehen ist... vor allem, ob sich der Aufwand dann auch gelohnt hat.

NV40:
VendorId = 0x000010DE
DeviceId = 0x00000040

R420:
VendorId = 0x00001002
DeviceId = 0x00004a50Jo, danke.
Auf die Device-ID der nVidia hätt' ich auch selber kommen können...
:D

Habe also nun die 6800GT (ID 0x45/69) und X800 (ID 0x4a50/19034) genommen und verglichen.
Und 'irgendwie' hatte ich das Gefühl, dass die FX mit den ATI-Shadern besser zurecht kam, als mit denen der 6800...

Die Anzahl der Shader ist überall gleich:
(links NV3x, rechts R350/R420/NV40)

http://mitglied.lycos.de/razor3dc/pics/vst_shader_nv3x_r350.png

Was mich aber wunderte, war, dass das Shader-File für die GT ein winziges bisserl kleiner war, als das für die X800...
...3.033kB zu 3.034kB um genau zu sein.

Und das war dann der Unterschied:

http://mitglied.lycos.de/razor3dc/pics/vst_shader_nv40_r420_diff.png

'dcl' kann doch wohl mit 'declare' übersetzt werden... und wenn ich das richtig interpretiere, dann könnte 'dcl_pp' evtl. 'declare partial precision' bedeuten... was aber nicht richtig sein kann, da hier dann die Seiten vertauscht würden.

Schließlich können doch die ATI's 'eh nichts mit den pp-hints anfangen, die nVidia's aber schon.
Gibt es irgend einen vernünftigen Grund, warum ausgerechnet hier ein Unterschied bei den IHVs gemacht wird?
:confused:

Razor

Demirug

2004-08-29, 15:28:40

Hmmm...
Also dann bin ich wirklich mal gespannt, wo da tatsächlich ein Unterschied zu sehen ist... vor allem, ob sich der Aufwand dann auch gelohnt hat.

Unterschiede sollte es nur beim Wasser und beim Glas geben. Der Aufwand ist relative weil die Vielzahl der Shader aus wenigen HLSL Shader erzeugt wurde.

Habe also nun die 6800GT (ID 0x45/69) und X800 (ID 0x4a50/19034) genommen und verglichen.
Und 'irgendwie' hatte ich das Gefühl, dass die FX mit den ATI-Shadern besser zurecht kam, als mit denen der 6800...

Die Anzahl der Shader ist überall gleich:
(links NV3x, rechts R350/R420/NV40)

http://mitglied.lycos.de/razor3dc/pics/vst_shader_nv3x_r350.png

Was mich aber wunderte, war, dass das Shader-File für die GT ein winziges bisserl kleiner war, als das für die X800...
...3.033kB zu 3.034kB um genau zu sein.

Und das war dann der Unterschied:

http://mitglied.lycos.de/razor3dc/pics/vst_shader_nv40_r420_diff.png

'dcl' kann doch wohl mit 'declare' übersetzt werden... und wenn ich das richtig interpretiere, dann könnte 'dcl_pp' evtl. 'declare partial precision' bedeuten... was aber nicht richtig sein kann, da hier dann die Seiten vertauscht würden.

Schließlich können doch die ATI's 'eh nichts mit den pp-hints anfangen, die nVidia's aber schon.
Gibt es irgend einen vernünftigen Grund, warum ausgerechnet hier ein Unterschied bei den IHVs gemacht wird?
:confused:

Razor

Ja dcl_pp bedeutet declare partial precision allerdings nur für das register das dann folgt. t sind Texturekoordinaten. Bei einer Radeon hat das _pp allerdings wenn man den gerüchten glaubt noch eine andere Auswirkung. Damit kann man angeblich das Centroid sampling aktivieren. Auf einer FX sollte das aber keinen unterschied machen weil diese das _pp bei den Texturekoordinaten ignoriert.

Jesus

2004-08-29, 15:33:29

Quasar

2004-08-29, 15:37:11

Hast du da mal einen passenden Link - wo die Winkel und Perspektiven auch identisch sind?

Demirug

2004-08-29, 15:39:27

den unterschied bei centroid sampling müsste man doch eigentlich sehen oder ? viell. sehen deshalb die texturen auf ATI ( x800 ) Karten etwas anders ( teilw. detailierter / schärfer ) als ( bei manchen reviewer seiten sichtbar ) NV - shots.

Centriod Sampling wirkt sich nur am Polygonenrand und niemals über die gesamte Fläche aus.

r@h

2004-08-29, 15:43:42

den unterschied bei centroid sampling müsste man doch eigentlich sehen oder ? viell. sehen deshalb die texturen auf ATI ( x800 ) Karten etwas anders ( teilw. detailierter / schärfer ) als ( bei manchen reviewer seiten sichtbar ) NV - shots.Da "centroid sampling" wohl von meiner FX nicht unterstützt werden dürfte, sollte ich auch keinen Unterschied ausmachen können... es sei denn... eine R9800p (eine 'echte' ;-) könnte dies darstellen...
...weiß da jemand was genaueres, denn den Aufwand möcht' ich erst betreiben, wenn sich's auch lohnt.

Bei 'nem Kollegen sah' es vorhin auf jeden Fall nicht so aus, als ob es da einen Unterschied geben würde.

Razor

P.S.: ich müsste die 9800p in meinem Hauptsystem benutzen, was wiederum bedeuten würde, vorher eine Datensicherung zu machen. Hmmm... mal schaun'.

r@h

2004-08-29, 15:51:33

Unterschiede sollte es nur beim Wasser und beim Glas geben. Der Aufwand ist relative weil die Vielzahl der Shader aus wenigen HLSL Shader erzeugt wurde.Würde das auch für SM3-Shader gelten?

Ja dcl_pp bedeutet declare partial precision allerdings nur für das register das dann folgt. t sind Texturekoordinaten. Bei einer Radeon hat das _pp allerdings wenn man den gerüchten glaubt noch eine andere Auswirkung. Damit kann man angeblich das Centroid sampling aktivieren. Auf einer FX sollte das aber keinen unterschied machen weil diese das _pp bei den Texturekoordinaten ignoriert.Ah ja... dann wäre das ja geklärt.

Nur wundert mich dann, dass der NV40 nicht exakt das Gleiche vorgesetzt bekommt, wie die ATI's auch. Schließlich hast Du ja gerade selbst gesagt, dass ein NV40 diese spezielle Form der Declare-Anweisungen irgnorieren würde...

...warum also unterschiedliche Pfade für R350/420 und NV40?
Bis auf diesen (kleinen?) Unterschied sind die Shader doch absolut identisch.
:confused:

Was im übrigen auch heißt, dass es keine speziellen Pfade für unterschiedliche Grafikchips gibt (vonm '_pp' bei den Declares mal abgesehen ;-). Was wiederum heißen würde, dass die Shader zu 100% auf ATI-Hardware hin 'optimiert' wurden... schließlich ist die 'Zuwendung' von ATI ja Fakt.

Also irgendwie wird mir das Ganze immer 'spanischer'...

Razor

Demirug

2004-08-29, 16:01:01

Würde das auch für SM3-Shader gelten?

Im Prinzip ja. Da die Shader recht kurz sind wird man da mit PS 3.0 auch keine grossen Vorteile erziehen können. In wie fern dynamische oder statische Branchen was bringt ist eine Sache die man testen müsste.

Ah ja... dann wäre das ja geklärt.

Nur wundert mich dann, dass der NV40 nicht exakt das Gleiche vorgesetzt bekommt, wie die ATI's auch. Schließlich hast Du ja gerade selbst gesagt, dass ein NV40 diese spezielle Form der Declare-Anweisungen irgnorieren würde...

...warum also unterschiedliche Pfade für R350/420 und NV40?
Bis auf diesen (kleinen?) Unterschied sind die Shader doch absolut identisch.
:confused:

Was im übrigen auch heißt, dass es keine speziellen Pfade für unterschiedliche Grafikchips gibt (vonm '_pp' bei den Declares mal abgesehen ;-). Was wiederum heißen würde, dass die Shader zu 100% auf ATI-Hardware hin 'optimiert' wurden... schließlich ist die 'Zuwendung' von ATI ja Fakt.

Also irgendwie wird mir das Ganze immer 'spanischer'...

Razor

Ist doch ganz einfach. Es gibt nur einen DX9 Pfad welcher das 2.0 Profil des HLSL Compiler nutzt. Die _pp für die Texturekoordinaten bei den Radeons fügt man eben nachträglich noch ein.

Und ja das ganze ist nach den "alten" Guidelines von ATI programmiert unter absoluter ignoranz der entsprechenden nVidia Unterlagen.

LovesuckZ

2004-08-29, 16:08:34

Bringt die Verwendung von unterschiedlichen Genauigkeiten einen Geschwindigkeitsgewinn auf den FX/NV40 Karten, immerhin scheint bei HL2 die Fuellrate zu limitieren.

r@h

2004-08-29, 16:23:43

Im Prinzip ja. Da die Shader recht kurz sind wird man da mit PS 3.0 auch keine grossen Vorteile erziehen können. In wie fern dynamische oder statische Branchen was bringt ist eine Sache die man testen müsste.Das verstehe ich jetzt nun nicht...

Du sagst, dass der Aufwand für diese tausende von Shadern (im Output) deswegen ganz einfach sei, weil ja nur ein paar wenige Shader unter HLSL zugrunde lägen.

Und da der Vorteil vom SM3-Shadern ja wohl u.a. darin liegt, sehr viel komplexere Shader zu bilden und damit diese Flut an Eventualitäts-Shadern einzudämmen, indem man durch statisches und dynamisches branchen alle Eventualitäten in einem einzigen Shader berücksichtigt und somit zudem noch die CPU entlastet (die dann ja nicht mehr für die Auswahl der Shader zuständig ist)... müsste der Einsatz von SM3 doch sogar gewaltige Vorteile bedeuten.

Allerdings nicht im Sinne eines Reverse-Engenerings, sondern im Sinne eines einfachen Neuübersetzens der HLSL-Shader auf SM3... und wo wir schon dabei sind, auch gleich auf 2.A und 2.B... oder würde das 2.B-Target für ATI keine Vorteile bringen? Offenbar ja wohl nicht...

Ist halt nur die Frage, wie man 'prüfen' soll, wenn Valve nicht prüfen will (oder 'darf' ;-)...

Ist doch ganz einfach. Es gibt nur einen DX9 Pfad welcher das 2.0 Profil des HLSL Compiler nutzt. Die _pp für die Texturekoordinaten bei den Radeons fügt man eben nachträglich noch ein.

Und ja das ganze ist nach den "alten" Guidelines von ATI programmiert unter absoluter ignoranz der entsprechenden nVidia Unterlagen.Genau das habe ich bereits vermutet...

Valve jagt das Zeug ohne Rücksicht auf Verluste durch den Compiler mit SM2-Target und fügt dann auf den ohnehin ATI-optimierten Code für ATI diese 'kleinen' pp-Hints hinzu und bildet dafür sogar einen eigenen Pfad, obwohl das eigentlich gar nicht notwendig wäre.

Und da soll man dann nicht ins Stirnrunzeln kommen?
Hmmm...

Razor

Demirug

2004-08-29, 16:31:43

Das verstehe ich jetzt nun nicht...

Du sagst, dass der Aufwand für diese tausende von Shadern (im Output) deswegen ganz einfach sei, weil ja nur ein paar wenige Shader unter HLSL zugrunde lägen.

Und da der Vorteil vom SM3-Shadern ja wohl u.a. darin liegt, sehr viel komplexere Shader zu bilden und damit diese Flut an Eventualitäts-Shadern einzudämmen, indem man durch statisches und dynamisches branchen alle Eventualitäten in einem einzigen Shader berücksichtigt und somit zudem noch die CPU entlastet (die dann ja nicht mehr für die Auswahl der Shader zuständig ist)... müsste der Einsatz von SM3 doch sogar gewaltige Vorteile bedeuten.

Allerdings nicht im Sinne eines Reverse-Engenerings, sondern im Sinne eines einfachen Neuübersetzens der HLSL-Shader auf SM3... und wo wir schon dabei sind, auch gleich auf 2.A und 2.B... oder würde das 2.B-Target für ATI keine Vorteile bringen? Offenbar ja wohl nicht...

Ist halt nur die Frage, wie man 'prüfen' soll, wenn Valve nicht prüfen will (oder 'darf' ;-)...

Theoretisch bringt SM3 Vorteile. Wie viel davon in der Praxsis übrig bleibt muss man aber eben prüfen. Nur lässt sich das nicht einfach durch neuübersetzten erreichen weil dann ja wieder die gleiche Menge an Shader heraus kommen würde.

Die Verwendung von 2.A könnte für die FXen von Vorteil sein. So muss es jetzt der Treiber übernehmen aus den ATI like 2.0 Shader was verträgliches zu machen.

2.B bringt aber für die X800 nichts weil man ja keine langen Shader hat die man bisher splitten musste. Wobei das jetzt unter Vorbehalt ist bis ich einen Blick auf den finale Renderablauf von HL2 werfen kann.

Jesus

2004-08-29, 16:41:11

Und ja das ganze ist nach den "alten" Guidelines von ATI programmiert unter absoluter ignoranz der entsprechenden nVidia Unterlagen.

das heisst aber doch eigentlich nur möglichst kurze Shader zu verwenden, und möglichst das niedrigste SM wo´s gerade noch geht, oder ? also wohl R3xx optimiert das ganze ?

Demirug

2004-08-29, 16:45:18

das heisst aber doch eigentlich nur möglichst kurze Shader zu verwenden, und möglichst das niedrigste SM wo´s gerade noch geht, oder ?

Von kurzen Shadern steht bei nVidia nichts. Das mit dem Shadermodel steht bei nVidia drin und seit neustem auch bei ATI.

also wohl R3xx optimiert das ganze ?

Ja, auf jeden Fall.

reunion

2004-08-29, 16:59:46

Genau das habe ich bereits vermutet...

Valve jagt das Zeug ohne Rücksicht auf Verluste durch den Compiler mit SM2-Target und fügt dann auf den ohnehin ATI-optimierten Code für ATI diese 'kleinen' pp-Hints hinzu und bildet dafür sogar einen eigenen Pfad, obwohl das eigentlich gar nicht notwendig wäre.

Und da soll man dann nicht ins Stirnrunzeln kommen?
Hmmm...

Razor

Was hast du erwartet nachdem ATi Valve beinahe die gesamten Entwicklungskosten gezahlt hat?

r@h

2004-08-29, 17:24:08

Theoretisch bringt SM3 Vorteile. Wie viel davon in der Praxsis übrig bleibt muss man aber eben prüfen. Nur lässt sich das nicht einfach durch neuübersetzten erreichen weil dann ja wieder die gleiche Menge an Shader heraus kommen würde.

Die Verwendung von 2.A könnte für die FXen von Vorteil sein. So muss es jetzt der Treiber übernehmen aus den ATI like 2.0 Shader was verträgliches zu machen.

2.B bringt aber für die X800 nichts weil man ja keine langen Shader hat die man bisher splitten musste. Wobei das jetzt unter Vorbehalt ist bis ich einen Blick auf den finale Renderablauf von HL2 werfen kann.Hmmm... OK.
Bin dann mal wirklich gespannt darauf, was Du zu dieser Engine wirst sagen können, wenn Du das finale Produkt in den Fingern hattest.

Aber wieso sollen die gleiche Menge an Shadern heraus kommen, wenn ein 'paar' HLSL-Shader mit SM3 compiliert werden? Sollten da nicht wesentlich weniger Shader zustande kommen, als beim SM2-Target? Schließlich sollte doch der Compiler erkennen, dass das originale branchen der HLSL-Shader nun direkt im Compilat abgebildet werden kann... oder stehe ich da irgendwie auf dem Schlauch? Hmmm...

Und wenn Valve also nichts tut, dann hoffen wir mal darauf, dass nVidia ähnlich 'kreativ' wird, wie beim ATI-optimierten Murks03... da hat's schlußendlich ja auch mit der Performance (neben vergleichbarer Quali ;-) hingehauen.

Wäre es denn für Valve (technisch !) so schwierig, weitere Render-Targets zu integrieren?
Schließlich unterstützen sie je auch beim 'Standard' SM2-Pfad schon 2 unterschiedliche Ziele...

Razor

r@h

2004-08-29, 17:32:32

den unterschied bei centroid sampling müsste man doch eigentlich sehen oder ? viell. sehen deshalb die texturen auf ATI ( x800 ) Karten etwas anders ( teilw. detailierter / schärfer ) als ( bei manchen (http://www.pcper.com/article.php?aid=67&type=expert&pid=4) reviewer seiten sichtbar ) NV - shots.Nun ja... da scheint beim NV40-Test aber irgendwas daneben gagangen zu sein, meinst Du nicht?
:confused:

Habe selber mal einen Shot gemacht (sogar in der für mich eher unüblichen 1600'er-Auflösung, aber 'nur' in 2xAA/4°AF.
Auch erscheint mit die nVidia-Darstellung detailreicher und das trotz geringeren AF-Levels...

Der Unterschied dürfte hier sehr deutlich zu sehen sein...
...das 'Fehlerbild' der Tester Deines Links allerdings nicht.

Insofern ich leider noch nichts von diesem 'centroid sampling' in Aktion sehen durfte.
(weder auf ATI- noch auf nVidia-Hardware ;-)

http://mitglied.lycos.de/razor3dc/pics/vst_sample1_vergl_256.png (http://mitglied.lycos.de/razor3dc/pics/vst_sample1_vergl.png)
(die unterschiedliche 'Weite' möge man mir bitte verzeihen ;-)

'Nice', isn't it?
:ugly:

Razor

Demirug

2004-08-29, 17:32:39

Aber wieso sollen die gleiche Menge an Shadern heraus kommen, wenn ein 'paar' HLSL-Shader mit SM3 compiliert werden? Sollten da nicht wesentlich weniger Shader zustande kommen, als beim SM2-Target? Schließlich sollte doch der Compiler erkennen, dass das originale branchen der HLSL-Shader nun direkt im Compilat abgebildet werden kann... oder stehe ich da irgendwie auf dem Schlauch? Hmmm...

Nicht der Compiler erzeugt die vielen Shadern. Der erzeugt pro Aufruf immer nur einen Shader. Valve hat aber ein Script das den Compiler für jeden mögliche Variante einmal aufruft. Wenn man also nur einfach das Zielprofil ändert erzeugt dieses Script nach wie vor die gleiche Anzahl von Compileraufrufen und damit auch die gleiche Anzahl shader.

Und wenn Valve also nichts tut, dann hoffen wir mal darauf, dass nVidia ähnlich 'kreativ' wird, wie beim ATI-optimierten Murks03... da hat's schlußendlich ja auch mit der Performance (neben vergleichbarer Quali ;-) hingehauen.

Das wird für nVidia nicht ganz einfach wenn sie sich nicht wieder einen Cheat vorwurf gefallen lassen wollen. Aber es gibt ja nicht nur Humus der Programme patchen kann.

Wäre es denn für Valve (technisch !) so schwierig, weitere Render-Targets zu integrieren?
Schließlich unterstützen sie je auch beim 'Standard' SM2-Pfad schon 2 unterschiedliche Ziele...

Razor

Nein es wäre eigentlich nicht so schwierig und es gab ja auch mal ein Set mit 2.A Shadern und den besagten 8.2 Pfad nur sind die wohl inzwischen verschwunden.

r@h

2004-08-29, 17:43:11

Nicht der Compiler erzeugt die vielen Shadern. Der erzeugt pro Aufruf immer nur einen Shader. Valve hat aber ein Script das den Compiler für jeden mögliche Variante einmal aufruft. Wenn man also nur einfach das Zielprofil ändert erzeugt dieses Script nach wie vor die gleiche Anzahl von Compileraufrufen und damit auch die gleiche Anzahl shader.Ähmmm... Hä?
:ugly:

Ist so etwas üblich?
Verzeih' mir bitte meine Unwissenheit...

Das wird für nVidia nicht ganz einfach wenn sie sich nicht wieder einen Cheat vorwurf gefallen lassen wollen. Aber es gibt ja nicht nur Humus der Programme patchen kann.Na dann mal ran da, Demirug!
Los, los, los...

Na ja... nicht ganz ernst gemeint... aber durchaus vorstellbar, gell?
;-)

Und ja, einen Cheat-Vorwurf könnte es geben, wenn da nicht Humus gewesen wäre, der als ATI-Mitarbeiter schon 'interveniert' hat. Insofern sollte nun auch nVidia das Gleiche machen 'dürfen' und dann sogar ganz offiziell verkünden, dass sie die Shader mit voller Absicht ersetzt haben... wenn das legal sein sollte... aber warum nicht, wenn man es ganz offiziell bekannt gibt und die Vergleichbarkeit (die ja 'eh nicht gegeben ist) damit eliminiert?

Nein es wäre eigentlich nicht so schwierig und es gab ja auch mal ein Set mit 2.A Shadern und den besagten 8.2 Pfad nur sind die wohl inzwischen verschwunden.Woran das wohl liegen mag...

Sie kommen ja so schon äusserst nahe an die maxmiale Quali heran - und das mit ganz 'gewöhnlichen' und auch noch wenigen PS1.x-Shadern. So könnte es also gut sein, dass... aber wenn Valve nicht will...

Razor

P.S.: was sagst Du zu meinem Vergleich? Ein Post vor dem Deinigen... zeigt der in etwa den Unterschied zwischen PS1.x und PS1.x/PS2.0-Mix? Und kann man auf dem ATI-Shot tatsächlich CentroidSampling 'bewundern'? Hmmm...

IVN

2004-08-29, 17:44:22

@Demirug

But,could it be possible to speed up nv40 by changeing the order of shaders,so they would be more friendly to the nv40 pipeline and all those unites in it.

r@h

2004-08-29, 17:49:36

@Demirug

But,could it be possible to speed up nv40 by changeing the order of shaders,so they would be more friendly to the nv40 pipeline and all those unites in it.I'm not Demirug, but...

The shaders have to be recompiled under the render-targets PS2.A (NV3x, NV4x) and PS3.0 (NV4x) to do so.
And Demirug already answered this question: yes, it would be possible easily...
(think of the fact, that there was a PS2.A-Path already ;-)

Razor

Demirug

2004-08-29, 17:56:13

Ähmmm... Hä?
:ugly:

Ist so etwas üblich?
Verzeih' mir bitte meine Unwissenheit...

Ja, das ist im Moment nicht unüblich. Ist aber nur ein Zwischenschritt.

Na dann mal ran da, Demirug!
Los, los, los...

We

Na ja... nicht ganz ernst gemeint... aber durchaus vorstellbar, gell?
;-)

Wenn Valve sich weigert ordentliche arbeit zu machen ...

Und ja, einen Cheat-Vorwurf könnte es geben, wenn da nicht Humus gewesen wäre, der als ATI-Mitarbeiter schon 'interveniert' hat. Insofern sollte nun auch nVidia das Gleiche machen 'dürfen' und dann sogar ganz offiziell verkünden, dass sie die Shader mit voller Absicht ersetzt haben... wenn das legal sein sollte... aber warum nicht, wenn man es ganz offiziell bekannt gibt und die Vergleichbarkeit (die ja 'eh nicht gegeben ist) damit eliminiert?

Du kennst ja die Fanboys beider Lager.

Woran das wohl liegen mag...

Sie kommen ja so schon äusserst nahe an die maxmiale Quali heran - und das mit ganz 'gewöhnlichen' und auch noch wenigen PS1.x-Shadern. So könnte es also gut sein, dass... aber wenn Valve nicht will...

Razor

Die Masse der 2.0 Shader ist ja auch Funktional identisch mit den 1.1 Shader.

P.S.: was sagst Du zu meinem Vergleich? Ein Post vor dem Deinigen... zeigt der in etwa den Unterschied zwischen PS1.x und PS1.x/PS2.0-Mix? Und kann man auf dem ATI-Shot tatsächlich CentroidSampling 'bewundern'? Hmmm...

Damit man CentroidSampling sieht muss man erst mal eine Stelle finden wo man es brauchen kann.

Jesus

2004-08-29, 18:04:48

'Nice', isn't it?
:ugly:

Razor

lass mich raten, der obere shot hat einen niedrigeren gamma wert ? :rolleyes:

r@h

2004-08-29, 18:05:47

Ja, das ist im Moment nicht unüblich. Ist aber nur ein Zwischenschritt.Oh ha...
Klingt reichlich... sagen wir... verwirrend.

Wenn Valve sich weigert ordentliche arbeit zu machen ...*ganzbreitgrins*
:up:

Du kennst ja die Fanboys beider Lager.Oh ja... zur genüge.

Die Masse der 2.0 Shader ist ja auch Funktional identisch mit den 1.1 Shader.Und damit verstößt Valve dann ja sogar gegen die (neueren ;-) Guidelines von ATI.
Einen gewissen Vorteil hat es ja offenbar, so zu verfahren...

Damit man CentroidSampling sieht muss man erst mal eine Stelle finden wo man es brauchen kann.Solch eine Stelle würde mich wirklich interessieren.
Kennst Du den VST? Gibt das Demo dafür etwas her?

Na ja, auf jeden Fall wird das Ganze sicher noch sehr viel spannender, wenn HL2 erst einmal das Licht der Welt erblickt, gell?
:D

Razor

IVN

2004-08-29, 18:06:51

Jesus

2004-08-29, 18:09:29

Solch eine Stelle würde mich wirklich interessieren.
Kennst Du den VST? Gibt das Demo dafür etwas her?

müsste dann wohl irgendein Gitter sein wo eine (durchsichtige ) Detail texture statt zusätzlicher polygone verwendet wird, die durch normales FSAA nicht geglättet wird.

r@h

2004-08-29, 18:09:31

lass mich raten, der obere shot hat einen niedrigeren gamma wert ? :rolleyes:Öhm... nö... oder doch?
Kann ich nicht sagen, da der eine Teil von dem von Dir verlinkten 'Test' ist, der andere von mir.
Und das also auf völlig unterschiedlichen Systemen und Grafikkarten...

Der Unterschied hat aber auch rein gar nichts mit irgendwelchen Genuigkeiten zu tun...
...schau' einfach mal genauer hin!

Razor

P.S.: http://www.forum-3dcenter.org/vbulletin/showpost.php?p=2191506&postcount=20

Demirug

2004-08-29, 18:09:51

No i didn't mean that.You know that an nv40 pipeline(PS part) has many unites.But you can't use them all.Some calculations are blocking not only one unit. Is it possible to reorder the calculations, the way an nv40 would like them??To use the dual-issue whan ever is possible.

Das ist ein Job für den Treiber und der macht das von Version zu Version besser.

Nur ist bei den kurzen Shadern kaum was zu optimieren.

r@h

2004-08-29, 18:11:10

müsste dann wohl irgendein Gitter sein wo eine (durchsichtige ) Detail texture statt zusätzlicher polygone verwendet wird, die durch normales FSAA nicht geglättet wird.Keine Ahnung, wie so etwas aussehen müsste... deswegen würde es mich ja so interessieren...

Razor

Demirug

2004-08-29, 18:12:33

Solch eine Stelle würde mich wirklich interessieren.
Kennst Du den VST? Gibt das Demo dafür etwas her?

Na ja, auf jeden Fall wird das Ganze sicher noch sehr viel spannender, wenn HL2 erst einmal das Licht der Welt erblickt, gell?
:D

Razor

Ich habe den VST leider nicht deswegen weis ich auch nicht in wie fern es dort stellen gibt wo man etwas sehen könnte. Aber selbst wenn das ist eine sehr komplexe Sache weil es dort um feinste Winkelgrade geht.

Quasar

2004-08-29, 18:14:58

müsste dann wohl irgendein Gitter sein wo eine (durchsichtige ) Detail texture statt zusätzlicher polygone verwendet wird, die durch normales FSAA nicht geglättet wird.

Alpha-Testing?

r@h

2004-08-29, 18:23:12

@ r@h

No i didn't mean that.You know that an nv40 pipeline(PS part) has many unites.But you can't use them all.Some calculations are blocking not only one unit. Is it possible to reorder the calculations, the way an nv40 would like them??To use the dual-issue whan ever is possible.I think, that the main difference between the ATI and the nVidia architecture is the length of the pixel 'pipelines'. ATI has short ones, nVidias are in opposite very long.

The shaders of the cs:s beta engine aure completely ATI-optimized (shader target 2.0) and in addition also forced to be very short. This ist not that good for the nVidia architecture and also very difficult to optimize for the complex shader-engines...

We will see, what the future brings.

Razor

r@h

2004-08-29, 18:24:55

Ich habe den VST leider nicht deswegen weis ich auch nicht in wie fern es dort stellen gibt wo man etwas sehen könnte. Aber selbst wenn das ist eine sehr komplexe Sache weil es dort um feinste Winkelgrade geht.Schade...

Wäre heute nicht die Langeweile mit mir durchgegangen, wüsste ich ebenfalls nur vom Hörensagen, wie sich dieser VST anfühlt...
;-)

Razor

r@h

2004-08-29, 18:26:50

Alpha-Testing?Daran dachte ich auch zuerst, als ich "Gitter" + "nicht geglättet" gelesen habe (ich denke, dass er mit 'normal' eben MultiSampling meinte). Was das jetzt mit CentroidSampling zu tun haben könnte, war mir nun auch nicht gerade zugänglich...

Razor

Jesus

2004-08-29, 18:43:44

oh stimmt, da war ich auf dem Flaschen dampfer :)

Centroid sampling ist nur dazu da um Artefakte ( die entstehen wenn das Pixelzentrum eines Pixels grösstenteils ausserhalb eines Polygons liegt ) zu vermeiden. Dann wirds wohl unscharf an den Kanten...

Aquaschaf

2004-08-29, 21:15:11

AFAIK wird es an den Kanten nicht unscharf, es gibt einfach Bildfehler.

Tomcat70

2004-08-30, 00:40:01

Was hast du erwartet nachdem ATi Valve beinahe die gesamten Entwicklungskosten gezahlt hat?

OT: naja, die beinahe die gesamten ist wohl reichlich übertrieben.

laut valve sind die entwicklungskosten >40 mio us$.

was ati wirklich gezahlt hat weiss keiner ausser ati und valve genau.

laut gerüchten soll der deal mit den hl2 gutscheinen angeblich um die 6 mio us$ umsatz für valve gebracht haben.

r@w

2004-08-30, 15:05:28

OT: naja, die beinahe die gesamten ist wohl reichlich übertrieben.

laut valve sind die entwicklungskosten >40 mio us$.

was ati wirklich gezahlt hat weiss keiner ausser ati und valve genau.

laut gerüchten soll der deal mit den hl2 gutscheinen angeblich um die 6 mio us$ umsatz für valve gebracht haben.Ich habe da was von runden 8mio läuten hören...
Gibt's zu den ">40mio" irgendwo etwas Offizielles?
:confused:

Razor

Xmas

2004-08-30, 15:36:03

Da der werte Herr MikBach erneut einen Ton an den Tag legt, der mit diesem Forum nicht kompatibel ist, gibt es einen Punkt.

Den entsprechenden Diskussionsarm hab ich herausgeschnitten, tut mir leid um ein brauchbares Posting, das sonst ohne Zusammenhang wäre.

Nur vorsorglich für alle:
Eine Diskussion über die Verwarnung hat hier nichts zu suchen.
Da sie OT und störend für die Diskussion sind, können wir solche Diskussionen hier nicht dulden.
Dir oder auch euch bleibt aber natürlich die Möglichkeit, sich an den entsprechenden Mod selber durch eine PN zu wenden, bzw. einen Beschwerde-Thread im “3DCenter & 3DCenter Forum“ zu eröffnen.

Aber bitte hier nicht mehr!
Siehe dazu auch:
Regeln und Richtlinien für die Moderation (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=147046)

Tomcat70

2004-08-30, 15:46:35

Ich habe da was von runden 8mio läuten hören...
Gibt's zu den ">40mio" irgendwo etwas Offizielles?
:confused:

Razor

OT:

6 mio:
http://www.megagames.com/news/html/pc/atibuysh-l2bundlingrightsforusd6million.shtml
40 mio:
http://www.maxitmag.co.uk/magtalk.php?articleID=4

r@h

2004-08-30, 18:22:49

OT:

6 mio:
http://www.megagames.com/news/html/pc/atibuysh-l2bundlingrightsforusd6million.shtml
40 mio:
http://www.maxitmag.co.uk/magtalk.php?articleID=4Thx4Links!
Die 40mio stammen also Gabe persönlich...

Crazy
:ugly:

Razor

r@h

2004-08-30, 18:35:15

Und ich habe noch einen Nachtrag zu meinem einleitenden Post!

Wie ich heute gelesen habe, ist es nun doch möglich, einen DX-Level im VST (und CS:S beta "dust") festzulegen...
...oder doch nicht?

Habe das mal gegen gecheckt und was dabei raus kam, fand ich doch äusserst verwunderlich!

Habe mir also flugs eine weitere hl2.bat gebaut, inder der zusätzliche Parameter "-dxlevel 90" enthalten war und den VST durchlaufen lassen... und was musste ich sehen?

Kein Wasser!

Und mir schwante böses...

Also schnell den 3DA heraus gekramt und nochmals mit diesem als Basis durchlaufen lassen (nur die Option 'shader.out' aktiviert). Immer noch kein Wasser (was mich jetzt auch gewundert hätte ;-). Nun habe ich mal die erzeugte shader.out mit der der simulierten 6800GT verglichen... KEIN Unterschied!

Hmmm...

Zur Kontrolle nochmal schnell den 3DA und 'maskierter' DeviceID laufen lassen... Wasser war wieder da!
Hmmmmmmmmm.........

Wie ist das denn nun bitte zu erlären?

Starte ich die Engine als FX5900 und dem DX9-Shaderset, dann ist das Wasser futsch.
Starte ich diese hingegen als 6800GT gibt's Wasser...
...wie kann das sein?
:confused:

Die Performance verhält sich übrigens analog
- 6800GT (mit Wasser) = 37fps
- FX5900 (ohne Wasser) = 43fps

Insofern das Wasser auch nicht 'unsichtbar' oder ähnliches ist...
;-)

Irgendwas muss da in der Engine passeren, wenn eine FX 'erkannt' wird.
Dieses 'etwas' beeinflußt aber offenbar nicht die an die Engine übergebenen Shader...

Hat dazu evtl. jemand eine Meinung?
Demirug?

Razor

Jesus

2004-08-30, 18:45:41

Demirug

2004-08-30, 18:45:42

Razor, das könnten unter Umständen noch ein Überbleibsel des 8.2 Pfads sein. Vielleicht will die Engine auf den FXen einen Wassershader benutzten den es nicht mehr gibt und deswegen wird gar nicht gerendert.

Das der richtige Shader im Set vorhanden ist muss nicht unbedingt was bedeuten weil es nicht ganz offensichtlich ist wann die Engine Shader einspielt.

r@h

2004-08-30, 18:49:36

hm, vielleicht liegts am Treiber ? oder Service Pack 2 ? Firingsquad verwendet SP 1 bei ihren Tests.

Oder vielleicht funktioniert das Shaderreplacement ja nicht mehr korrekt unter gewissen Umständen ? ;D ( j/k )Ich gebe Dir einen guten Rat:
Lese meinen Post bitte nochmal gaaaaaanz langsam durch!

Razor

Jesus

2004-08-30, 18:56:26

Ich gebe Dir einen guten Rat:
Lese meinen Post bitte nochmal gaaaaaanz langsam durch!

Razor

hm hab ich, da steht aber nicht welches SP du verwendest ... im übrigen scheint FS dieses Problem ja nicht gehabt zu haben, sonst hätten sie kaum Bilder der FX mit Wasser und DX9 Pfad posten können. :wink:

Edit: Stimmt ist "transparent" , hab ich übersehen :)
Naja, viell. ist es ja doch einfach nur ein Treiberbug ...

Gast

2004-08-30, 18:57:03

Da der werte Herr MikBach erneut einen Ton an den Tag legt, der mit diesem Forum nicht kompatibel ist, gibt es einen Punkt.

[/url]

http://www.forum-3dcenter.de/vbulletin/showpost.php?p=2192760&postcount=231

könntest du hier gerade weitermachen?

r@h

2004-08-30, 19:00:37

Wow, Demirug, das war jetzt aber mal schnell regiert...
Thx!

Razor, das könnten unter Umständen noch ein Überbleibsel des 8.2 Pfads sein. Vielleicht will die Engine auf den FXen einen Wassershader benutzten den es nicht mehr gibt und deswegen wird gar nicht gerendert.

Das der richtige Shader im Set vorhanden ist muss nicht unbedingt was bedeuten weil es nicht ganz offensichtlich ist wann die Engine Shader einspielt.Hmmm...
Wie gesagt, das übergebene ShaderSet ist absolut identisch.
(selbst die Reihenfolge ist gleich)

Auch soll der Parameter (nach Aussage von Valve) dafür sorgen, dass zwingend der DX9-Pfad benutzt wird, was ja auch der Fall sein dürfte (wenn meine Analyse hier korrekt ist). Was mich aber wundert, ist die Tatsache, dass sich die Engine selber offenbar 'irgendwie' anders verhält, wenn mit einer FX gestartet wird. Anders wäre das ja wohl nicht zu erklären... oder vielleicht doch?

Du meinst also dass bei den FX'en ein nicht mehr vorhandener Shader adressiert wird?
Also trotz erzwungenem DX9-'Pfad' ein spezieller Pfad für die FX'en aktiv ist?

Das aber wiederum würde doch bedeuten, dass (zumindest in dieser Beta-Engine) die FX'en noch immer anders behandelt werden, als der Rest der DX9-Family... zumal die unterschiedlichen Vertex-Shader Deklarationen für die ATI's ja ebenfalls darauf hindeuten, dass da noch so einige Pfade mehr 'bereitgestellt' wurden...

...zumindest aber wäre diese Erklärung einleuchtend.

Also irgendwas hat Valve hier ganz schon verhauen.
Und um es in Deinen Worten auszudrücken: Ich hoffe, dass sie in der HL2-Final vernünftige Arbeit leisten...
(auch wenn ich daran irgendwie nicht so recht glauben mag)

Razor

Demirug

2004-08-30, 19:07:51

Razor, es gab mal zwei DX9 Pfade. Einen mit Shaderprofil 2.0 und einen mit Shaderprofil 2.A. Inzwischen ist es aber nur noch einer.

r@h

2004-08-30, 19:18:37

hm hab ich, da steht aber nicht welches SP du verwendest ... im übrigen scheint FS dieses Problem ja nicht gehabt zu haben, sonst hätten sie kaum Bilder der FX mit Wasser und DX9 Pfad posten können. :wink:Ich will Dir ja wirklich nicht zu nahe treten... aber:
http://www.firingsquad.com/media/article_image.asp?fs_article_id=1540&pic_id=12

Edit: Stimmt ist "transparent" , hab ich übersehen :)
Naja, viell. ist es ja doch einfach nur ein Treiberbug ...Nein, es ist nicht transparent, sondern es ist nicht vorhanden!
Siehe hierzu bitte auch meine fps-Vergleiche...

Und das muss schon ein merkwürdiger Treiber-Bug sein, der es (mit ein und derselben Grafikkarte und ein und demselben Treiber) einmal korrekt und einmal nicht korrekt darstellt... reproduzierbar wohlgemerkt.

Demirug wird da schon 100%'ig korrekt liegen: definitiv ein Engine-Bug.
(und der scheint lange nicht der einzige zu sein)

Razor

r@h

2004-08-30, 19:33:56

Razor, es gab mal zwei DX9 Pfade. Einen mit Shaderprofil 2.0 und einen mit Shaderprofil 2.A. Inzwischen ist es aber nur noch einer.Du meinst also, es sein könnte, dass der erzwungene DX9-Level dafür sorgt, dass - wenn sich eine FX meldet - der PS2.A-Pfad gewählt wird und nicht der PS2.0-Pfad (bzw. der 'modifizierte' PS2.0-Pfad für die ATI's)?

Das wäre doch mal wirklich eine einleuchtende Erklärung...
...wenn auch ein heftiger Bug.

Gibt es eigentlich irgend eine Erklärung seitens Valve, warum der PS2.A-Pfad nicht mehr Bestandteil der Engine ist?
Bzw. er scheint ja vorhanden zu sein... nur fehlen die zugehörigen Shader offenbar.

Also irgendwie wird das Ganze immer merkwürdiger...
Vielleicht sollte man nicht zuviel in diese Beta-Engine hinein interpretieren... obwohll HL2 ja heute eigentlich 'Gold' gehen sollte.

Kann es sein, dass sie immer (noch lange) nicht fertig mit der Engine sind?
Sieht irgendwie danach aus, als ob das Teil mit der heißen Nadel gestrickt wurde...

Razor

Jesus

2004-08-30, 19:42:30

r@h

2004-08-30, 20:00:44

ehm, wie sollen alte "leere" 2.A Shader verwendet werden wenn, wie du schreibst der output deines Tests identische Shader bei 6800 und FX Kennung gibt ? Dann müsstest du doch den "leeren" Shader auch dort sehen oder ?"Wie Sie sehen, sehen Sie nix!"
:D

Ich denke, dass ich Demirug da schon richtig verstanden habe...

Alternativ hätten eben mehr (!) Shader in die API (die Grafikkarte) geladen werden müssen, um die 2.A-Shader-Aufrufe nicht ins Leere laufen zu lassen. Schließlich werden die Shader ja erst zur Laufzeit über die Engine 'ausgewählt'. Und wenn ein Shader nicht da ist, kann er auch nicht appliziert werden... that's it.

Und wie gesagt, das 'reine' 2.0-Shaderset wird ja korrekt dargestellt und Demirugs Ansatz, dass bei der FX ein anderes (zum Teil nicht mehr exisitierendes) Shaderset ausgewählt wird, ist so ziemlich der einzige Ansatz, der das visuelle Ergebnis erklären könnte.

Scheint eben noch reichlich Beta zu sein, die Engine...

Razor

reunion

2004-08-30, 20:07:45

Scheint eben noch reichlich Beta zu sein, die Engine...

Razor

Also auf ATi-Karten läufz problemlos :D

r@h

2004-08-30, 20:12:09

Also auf ATi-Karten läufz problemlos :DTjo...
Woran das wohl liegen mag?
:|

Razor

Jesus

2004-08-30, 20:12:38

"Wie Sie sehen, sehen Sie nix!"
:D

Ich denke, dass ich Demirug da schon richtig verstanden habe...

Alternativ hätten eben mehr (!) Shader in die API (die Grafikkarte) geladen werden müssen, um die 2.A-Shader-Aufrufe nicht ins Leere laufen zu lassen. Schließlich werden die Shader ja erst zur Laufzeit über die Engine 'ausgewählt'. Und wenn ein Shader nicht da ist, kann er auch nicht appliziert werden... that's it.

Und wie gesagt, das 'reine' 2.0-Shaderset wird ja korrekt dargestellt und Demirugs Ansatz, dass bei der FX ein anderes (zum Teil nicht mehr exisitierendes) Shaderset ausgewählt wird, ist so ziemlich der einzige Ansatz, der das visuelle Ergebnis erklären könnte.

Scheint eben noch reichlich Beta zu sein, die Engine...

Razor

naja aber wenn gleichzeitig alle 2.0 Shader geladen werden ( weil sie ja identisch sind zur 6800 variante ) und noch zusätzliche 2.0a Shader erwartet werden die aber aufgrund einer Änderung an der Engine nicht geladen werden weil sie womöglich nicht mehr da sind, dann wäre das ziemlicher bullshit, denn dann hätte man wohl einige ungenutzte (2.0 ) Shader umsonst geladen...

r@h

2004-08-30, 20:20:12

<snip>
denn dann hätte man wohl einige ungenutzte (2.0 ) Shader umsonst geladen...So ist es...

Eben noch reichlich 'ineffizient' und buggy, die Engine.
Zumindest auf nVidia-Karten!
:D

Razor

Jesus

2004-08-30, 20:21:35

nagut, aber andererseits ist dieser debug switch auch nicht der normale weg das spiel zu starten ;)

Demirug

2004-08-30, 20:27:29

@Razor: Welcher Treiber und welche Taktrate hat den deine 5900? Ich komme nur auf 35 (ohne Wasser)

r@h

2004-08-30, 20:57:34

nagut, aber andererseits ist dieser debug switch auch nicht der normale weg das spiel zu starten ;)Weswegen ja auch Valve höchstpersönlich auf diesen 'Switch' hingewiesen hat...
...oh mann.

Razor

r@h

2004-08-30, 20:57:41

@Razor: Welcher Treiber und welche Taktrate hat den deine 5900? Ich komme nur auf 35 (ohne Wasser)Treiber sind die 65.73 WHQL ("Quality" mit TriOpt und ohne die AnisoOpts). Der Takt meiner FX5900 liegt bei 475/950, die fest ins Bios gebrannt sind... neben exorbitant geringen Latenzen, aber originalen Volts (self-modded bios ;-).

Hab' ja die MSI FX5900-VTD128 mit 'Sonnenkühler'...

Razor

P.S.: viel interessanter ist die Tatsache, dass die R9800p als FX5900 'getarnt', die Wasser-Shader ebenfalls nicht darzustellen vermag... was aber wiederum logisch ist, da diese ja gar nicht in der Lage wäre, die 2.A-Shader überhaupt darzustellen, wenn es sie denn gäbe. Hmmm...

Demirug

2004-08-30, 21:22:11

In den 43 MB Shaderfiles sind keine 2.A Shader dabei. Und die passende Effekt DLL fehlt ja auch.

PS: Inzwischen habe ich 52 FPS im DX9 Pfad (immer noch ohne Wasser).

IVN

2004-08-30, 21:46:07

In den 43 MB Shaderfiles sind keine 2.A Shader dabei. Und die passende Effekt DLL fehlt ja auch.

PS: Inzwischen habe ich 52 FPS im DX9 Pfad (immer noch ohne Wasser).

Don't tell me,you are makeing a patch for VST. :)

You are really a tireless guy. =)

Quasar

2004-08-30, 21:59:29

Da hat Valve wohl leider Sch**sse gebaut.
Denn eigentlich sollte eine QuadroFX2000 keine Begrenzung des DX-Levels erfahren (wurde wohl vergessen...).
Ich bekomme auch DX9-Shader, aber kein Wasser.

Schade, Valve.

Demirug

2004-08-30, 22:04:08

Don't tell me,you are makeing a patch for VST. :)

You are really a tireless guy. =)

Eigentlich ist es ein Plugin für alle Source Engine Spiele. Im Moment habe ich aber nur eines der Standard Plugins des Tweakers benutzt. Da ist noch gar nichts spezifisches für Source drin.

IVN

2004-08-30, 22:13:14

@Demirug

What did you do to improve the speed on your FX??

Demirug

2004-08-30, 22:25:31

@Demirug

What did you do to improve the speed on your FX??

Die Shader auf FP16 gezwungen.

Bevor jemand fragt: Bei Durchlauf sind mir keine Artefakte aufgefallen die dadurch entstanden sind. Ich habe jetzt aber keine Pixelgenaue vergleiche gemacht. Ist auch nicht so einfach da identische Frames zu bekommen.

Quasar

2004-08-30, 22:26:39

Weswegen ja auch Valve höchstpersönlich auf diesen 'Switch' hingewiesen hat...
...oh mann.

Razor

Man kläre mich auf, plz.... ;)
Ein Debug-Switch??

r@h

2004-08-31, 06:48:32

In den 43 MB Shaderfiles sind keine 2.A Shader dabei. Und die passende Effekt DLL fehlt ja auch.

PS: Inzwischen habe ich 52 FPS im DX9 Pfad (immer noch ohne Wasser).Ähm... erst einmal ein mega- :up::up:
Und...

Haben will!
(Du weißt, wie gerne ich 'herumspiele' ;-)

Bin ja echt mal gespannt, was Du da so alles entdecken wirst!

Razor

r@h

2004-08-31, 06:52:52

Man kläre mich auf, plz.... ;)
Ein Debug-Switch??Nö... der "DX-Level-Force-Switch"...
In dem Starter von Steam als Parameter setzen (= *igitt* ;-)
Oder eben einen Batch zum Starten der cs:s beta engine schreiben und diesen hinten dran hängen.

Ergo:
"-dxlevel <lvl>"

Wobei <lvl> eben 70/80/81 oder 90 sein kann...
Kann man in dem Artikel (http://www.firingsquad.com/hardware/geforce_fx_half-life2/) von FiringSquad nachlesen.

Razor

Demirug

2004-08-31, 07:34:07

Ähm... erst einmal ein mega- :up::up:
Und...

Haben will!
(Du weißt, wie gerne ich 'herumspiele' ;-)

Bin ja echt mal gespannt, was Du da so alles entdecken wirst!

Razor

Inzwischen habe ich auch Wasser. Mit NV40 FakeID. Dort sind es dann 26 zu 36 FPS.

Mit dem rausrücken ist das so eine Sache weil das ganze Teil eines kommerziellen Packets ist. Die Plugins die ich hier benutzt haben kommen wahrscheinlich zwar in die freie Version aber das ist alles noch im Fluss.

Viel zu entdecken gibt es da nicht mehr. Ausser das für 5-10% der vorhandenen 2.0 Shader auch ein 1.X Shader gereicht hätte. Allerdings ist die Tatsache das es durchweg 2.0 Shader im DX9 Pfad sind bis zu einem gewissen Mass verständlich. Das man allerdings auf die Benutzung des 2.A Profiles und den Einsatz von PP Flags verzichtet hat ist dagegen eigentlich ein Schlag ins Gesicht aller FX Besitzer. Vorallem da man ja noch grossartig erzählt hat wie viel Aufwand man extra für die FXen betrieben hätte.

Mal schauen ob man das Ergebniss ohne Einfluss auf die optische Qualität noch etwas steigern kann.

PS: Ich habe aus Versehen mein FP16 Ergebniss an Valve geschickt. Mal schauen ob es in der Statistik auftaucht. :D

Demirug

2004-08-31, 07:37:08

Nö... der "DX-Level-Force-Switch"...
In dem Starter von Steam als Parameter setzen (= *igitt* ;-)
Oder eben einen Batch zum Starten der cs:s beta engine schreiben und diesen hinten dran hängen.

Ergo:
"-dxlevel <lvl>"

Wobei <lvl> eben 70/80/81 oder 90 sein kann...
Kann man in dem Artikel (http://www.firingsquad.com/hardware/geforce_fx_half-life2/) von FiringSquad nachlesen.

Razor

Ich glaube Quasar wollte wissen wie die Batch Datei aussehen muss.

MikBach

2004-08-31, 08:17:07

Ich verstehe nicht!
Warum muss ich das hier lesen?
Will Valve uns hier verarschen?
Das kann doch nicht sein, dass angebliche Weltklasseprogrammierer nicht auf ein paar Grakas optimieren können. Behaupten von sich, dass sie eine Superengine haben, bei der Shaderprogrammierung langt es aber vorne und hinten nicht?
Da kommt (wieder) Demi und zeigts wie es gemacht wird.
Das kann man genauso von ID und Humus bei Doom3 behaupten.
Ich glaube einige Firmen sind sich nicht dessen bewusst, dass solch eine Vorgehensweise in Vertrauensverlusst resultieren kann.
Man kommt sich einfach nur verarscht vor.
Na ja, vielleicht macht Valve da noch was, wenn sie bemerken, dass einige User ihre Unfähigkeit/Absicht kritisieren.
Ich kann ja verstehen, wenn kleinere Firmen es nicht auf die Reihe kriegen vernünftig zu optimieren, aber gerade von Valve und ID sollte man doch mehr erwarten können.
Dass es auch anders geht beweist CryTek mit FarCry eindrucksvoll. Es waren zwar nicht alle "Features" von Anfang an vorhanden, man bemüht sich aber sichtlich so viel zu optimieren, wie nur möglich.

Just my 2Cents

Frolic

2004-08-31, 09:18:48

@Demirug...ich bewundere ja wirklich dein enormes fachwissen in bezug auf 3d-engines. ich wollte von dir gerne mal wissen ob du damit auch beruflich zu tun hast oder ob du selber schon mal eine 3d-engine entwickelt hast. :)
und wenn ich fragen darf, wie bist du zu so einem wissen gekommen?!

@razor: wieso registrierst du dich eigentlich nicht? du zeugst auch von sehr viel kenntnis und könntest andere user sehr gut unterstützen oder uns mit deinen superlativen statistiken mehr nahrung geben :D

sry für diesen schleim, aber ich finde so etwas halt bewundertswert.

Quasar

2004-08-31, 09:40:58

Razor hat einen Account, er nutzt ihn nicht.

dead

2004-08-31, 10:46:19

[...]
Also irgendwas hat Valve hier ganz schon verhauen.
[...]

Razor

Ja, ich habe mir den ganzen thread durchgelesen,
trotzdem, um nichts falsch zu verstehen:
Jungfräulich gestartet bekommt eine FX nur dx8 angeboten (mit Wasser?)
Als FX mit erzwungenem dx9: kein Wasser
Als GF6x / R3xx mit dx9 gips Wasser - performance?!
Allerdings auf FX > 5800 immer noch brauchbare performance unter dx9?!

Wie sind die optischen Unterschiede dx8/9 (nur aufs Wasser bezogen, generell sind sie ja wohl vernachlässigbar)?

MadManniMan

2004-08-31, 12:15:28

Man kann also konstatieren, daß es eigentlich fast lächerlich ist, sich über die paar Prozentchen des Humus-/Demitweaks aufzuregen, in Anbetracht der Situation für NV3X-Nutzer.

Demirug

2004-08-31, 12:27:33

Ja, ich habe mir den ganzen thread durchgelesen,
trotzdem, um nichts falsch zu verstehen:

Jungfräulich gestartet bekommt eine FX nur dx8 angeboten (mit Wasser?)

Ja, wobei es streng genommen DX 8.1 ist da auch 1.4 Shader zum Einsatz kommen.

Als FX mit erzwungenem dx9: kein Wasser

Ja

Als GF6x / R3xx mit dx9 gips Wasser - performance?!

Ja und die FPS gehen nach unten.

Allerdings auf FX > 5800 immer noch brauchbare performance unter dx9?!

So wie der DX9 Pfad im Moment aussieht würde ich nicht unbedingt von brauchbar sprechen.

Wie sind die optischen Unterschiede dx8/9 (nur aufs Wasser bezogen, generell sind sie ja wohl vernachlässigbar)?

Also auf den ersten Blick sieht es nicht wirklich so anders aus. Ich muss mir das aber nochmal genauer anschauen um hinter das geheimniss zu kommen.

Was die Performance angeht so hatte ich mit einer FX5900 bei 1024 mit HQ Filter:

Original Shader:

DX9 (ohne Wasser): 35 FPS
DX9 (mit Wasser; im NV40 Modus der Engine): 26 FPS

Shader auf FP16 gezwungen:

DX9 (ohne Wasser): 52 FPS
DX9 (mit Wasser; im NV40 Modus der Engine): 36 FPS

Mit einen besseren Shaderversionmanagment wäre wohl durchaus noch mehr drin. Aber das erfordert noch etwas mehr Forschung meinerseitz. Ich habe das Ding erst seit gestern abend.

LovesuckZ

2004-08-31, 12:30:57

Original Shader:
DX9 (ohne Wasser): 35 FPS
DX9 (mit Wasser; im NV40 Modus der Engine): 26 FPS
Shader auf FP16 gezwungen:
DX9 (ohne Wasser): 52 FPS
DX9 (mit Wasser; im NV40 Modus der Engine): 36 FPS

Der Leistungssprung ist ziemlich hoch.
Koennte FP16 auf dem NV40 weitaus mehr als 50% zusaetzliche Leistung bringen (NRM_pp usw.)?

Demirug

2004-08-31, 12:31:19

@Demirug...ich bewundere ja wirklich dein enormes fachwissen in bezug auf 3d-engines. ich wollte von dir gerne mal wissen ob du damit auch beruflich zu tun hast oder ob du selber schon mal eine 3d-engine entwickelt hast. :)
und wenn ich fragen darf, wie bist du zu so einem wissen gekommen?!

Ja, ich habe damit auch beruflich zu tun wobei im Moment mehr auf der Entwicklungstool Seite als auf der Engine Seite.

Woher mein Wissen kommt genau kommt kann ich auch nicht sagen. Ich habe eben einfach alles was mir zu dem Thema in die Hände gefallen ist gelesen.

Demirug

2004-08-31, 12:38:15

Der Leistungssprung ist ziemlich hoch.
Koennte FP16 auf dem NV40 weitaus mehr als 50% zusaetzliche Leistung bringen (NRM_pp usw.)?

So viele NRMs habe ich jetzt nicht gesehen. Ist daher schwer abzuschätzen was FP16 dem NV40 bringt.

dead

2004-08-31, 18:07:11

Besten Dank Demirug.

Ist zwar etwas OT, aber als derjenige, der sowohl Grafikkartenherstller als auch Spielehersteller bezahlen muss geht mir diese Entwicklung gewaltig gegen den Strich.
Nebenbei, um wieder etwas die Kunve richtung OT zu bekommen, die Engines auf denen die Spiele (D3 + HL2) laufen sind ja ausdrücklich fürs Lizenzgeschäft geschrieben. Dann eine derart deutliche Bevorzugung für eine bestimmte Hardware einzubauen kann eigentlich nicht im Sinne des Lizenznehmers sein.
Da andererseits das Fixen dieser 'Engineprobleme' für die darauf entwickelten Spiele augenscheinlich nicht allzu aufwendig ist, kommen mir da irgendwie Zweifel...
Ich will gar nicht wissen in welche Richtung sich das noch entwickelt. Das Potential ist erschreckend.

Demirug

2004-08-31, 18:30:02

dead, wer weiss schon wie lange das schon so geht?

Hat sich in der Vergangenheit jemand darüber wirklich Gedanken gemacht? Wurden jemals entsprechende Unterschungen angestellt?

dead

2004-08-31, 18:58:46

Da gilt, in gewisser Weise, 'was ich (der Kunde) nicht weiss, macht mich nicht heiss'...
Allerdings ist die derzeitige Marktkonstellation neu.
Zwei große GrakaHersteller auf Augenhöhe, zudem noch mit dem Geld was heutzutage im Spiel ist. (auf dem Spiel steht :D )
imo sollten sich die Hersteller über die Negativeffekte iher derzeitigen Marketingstrategien gedanken machen.

Wie lange ist die allgemeine Bereitschaft noch da ?300,- + auszugeben um bestenfalls 50% der verfügbaren Spiele spielen zu können.
Besonders schlimm bei dx-Spielen. Wo ein unterstützter dx-level doch entsprechende Kompatibilität gearantieren sollte...
(8ung! Absichtlich übertrieben!)
ok, aber jetzt tatsächlich weit OT.

Gast

2004-08-31, 19:04:22

Besonders schlimm bei dx-Spielen. Wo ein unterstützter dx-level doch entsprechende Kompatibilität gearantieren sollte...

...was er ja auch tut.
Nur sagt das nichts über die dabei erbrachte Performance aus.

Quasar

2004-08-31, 19:10:30

...was er ja auch tut.
Nur sagt das nichts über die dabei erbrachte Performance aus.
Leider nicht. Valves Wasserschader bsw. erzeugt auf einem nV30GL kein sichtbares Wasser.

dead

2004-08-31, 19:17:06

...was er ja auch tut.
Nur sagt das nichts über die dabei erbrachte Performance aus.

Bitte nicht aus dem Kontext reissen!
'Ich habe ein dx wassauchimmer Spiel, und will auch die Effekte!'

Jesus

2004-08-31, 19:23:48

naja ich würde jetzt erstmal abwarten was das finale Spiel macht ;)

schliesslich ist das noch nichtmal draussen, und CS:S ist auch nur beta die laufend verändert wird.

r@h

2004-09-01, 06:50:34

Inzwischen habe ich auch Wasser. Mit NV40 FakeID. Dort sind es dann 26 zu 36 FPS.Na ja... immerhin 'etwas', gell?
;)

Mit dem rausrücken ist das so eine Sache weil das ganze Teil eines kommerziellen Packets ist. Die Plugins die ich hier benutzt haben kommen wahrscheinlich zwar in die freie Version aber das ist alles noch im Fluss.War ja auch nicht so ganz ernst gemeint...
Wenn Du also noch einen vertrauenswürdigen Beta-Tester brauchst?

Ich glaube Quasar wollte wissen wie die Batch Datei aussehen muss.Ahso...

<exe> -steam -game cstrike -dxlevel 90 -console

Die Console kann schon manchmal ganz nützlich sein... ;)
Und klar, damit das Game (die Engine ;-) so gestartet werden kann, brauchts einen gültigen Zugang zu Steam und man muss auch eingeloggt sein (das Steam-Tool muss nicht unbedingt laufen)... eine iNet-Verbindung brauchts selbstredend auch.

Razor

r@h

2004-09-01, 06:57:36

Ja, ich habe mir den ganzen thread durchgelesen,
trotzdem, um nichts falsch zu verstehen:
Jungfräulich gestartet bekommt eine FX nur dx8 angeboten (mit Wasser?)
Als FX mit erzwungenem dx9: kein Wasser
Als GF6x / R3xx mit dx9 gips Wasser - performance?!
Allerdings auf FX > 5800 immer noch brauchbare performance unter dx9?!

Wie sind die optischen Unterschiede dx8/9 (nur aufs Wasser bezogen, generell sind sie ja wohl vernachlässigbar)?Ad1: ja, nur DX8(.1) und nicht ganz so 'hübsches' Wasser
Ad2: ja, als FX mit DX9 kein Wasser
Ad3: ja, als gf6/r3/R4 mit DX9 gibt's Wasser (und geringere Performance)
Ad4: nein, auch mit FX miese Perfromance (daran arbeitet Demirug ja gerade ;-)

Nein, der optische Unterschied ist schon recht deutlich.
Schau Dir einfach mal meinen Vergleich an (FX mit DXx vs. FX als gf6/r3/4 mit DX9)...

Zur not vll einfach Gamma ein wenig erhöhen und mal intensiv die Wasserspeigelungen in Augenschein nehmen.

Razor

r@h

2004-09-01, 07:03:09

Man kann also konstatieren, daß es eigentlich fast lächerlich ist, sich über die paar Prozentchen des Humus-/Demitweaks aufzuregen, in Anbetracht der Situation für NV3X-Nutzer.Man kann konstatieren, dass ATI unter D3 ein wenig an seinen Treibern arbeiten sollte... Valve hingegen ganz erheblichen Nachholbedarf hat und nicht nur auf ATI hätte optimieren sollen... entgegen ihren eigenen Aussagen, dass sie einen erheblichen Teil der Entwicklung auf die Optimierung für nVidia-Hardware verwendet haben, wovon jetzt rein gar nichts mehr zu sehen ist... wenn man allerdings davon absieht, dass der 'alte' PS2.A Pfad ja wohl doch noch 'irgendwie' drin ist... nur eben nicht offiziell und schon gar nicht vollständig (da die optimierten Teile fehlen)... was auch nur durch ein Bug in der Engine offenbar geworden ist.

Razor

MikBach

2004-09-01, 10:48:49

Man kann konstatieren, dass ATI unter D3 ein wenig an seinen Treibern arbeiten sollte... Valve hingegen ganz erheblichen Nachholbedarf hat und nicht nur auf ATI hätte optimieren sollen...
Razor
ID hat auch nur für NV optimiert.
Siehe z.B. das Posting von Lolman:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=2167995&postcount=46

Da kann ich nur zustimmen. ID hätte besser auf ATI optimieren sollen, dann wäre aber NV benachteilgt gewesen, wenn man nur einen Pfad verwenden wollte. Da hat ID doch lieber voll auf Nvidia optimiert und ATI aussen vor gelassen. Etwas anderes habe ich aber ehrlich gesagt nicht von ID erwartet.

Zu Valve muss man noch beachten, dass die vielleicht nach dem Codeklau noch nicht richtig fertig sind, der Veröffentlichungstermin jedoch drängt.

Demirug

2004-09-01, 12:00:22

r@h

2004-09-01, 12:16:34

ID hat auch nur für NV optimiert.
Siehe z.B. das Posting von Lolman:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=2167995&postcount=46

Da kann ich nur zustimmen. ID hätte besser auf ATI optimieren sollen, dann wäre aber NV benachteilgt gewesen, wenn man nur einen Pfad verwenden wollte. Da hat ID doch lieber voll auf Nvidia optimiert und ATI aussen vor gelassen. Etwas anderes habe ich aber ehrlich gesagt nicht von ID erwartet. Erzähl nicht so einen blödsinn...

ATI hat Treiber-Probleme gehabt, die mit einem neuen Beta-Treiber schon nachweislich gefixt sind.
Der Humus-Tewak optimiert speiziell auf eine Hardware hin... ATI, wenn Dir der Name seines Arbeitgebers etwas sagt.
Dass die nVidia-Karten mit einem so einseitig optimierten Pfad nicht sonderlich gut zurecht kommen, haben wir ja nun mehrfach schon an anderer Stelle gesehen (wie zuletzt an der cs:s beta Engine).

ID hat einfach nach ARB2 geproggt und eine sehr extensive Schattentechnik implementiert, die den ATI's offenbar nicht wirklich gut bekommt, dafür den nVidia's ebenso offenbar keinerlei Probleme bereitet. Dann kommt noch hinzu, dass durch diesen Humus-Tewak gerade mal 6-8% Leistung heraus gekommen sind, was immer der Fall sein dürfte, wenn man auf eine speizielle Hardware hin optimiert.

Zudem ist es hier noch völlig OT.
Sorry, dass ich diesen Sachverhalt erwähnte...

Zu Valve muss man noch beachten, dass die vielleicht nach dem Codeklau noch nicht richtig fertig sind, der Veröffentlichungstermin jedoch drängt.Valve ist schon seit Ewigkeiten "noch nicht fertig". Bedenke, dass sie schließlich schon Mitte letzten Jahres damit 'fertig' sein wollte (erinnerst Du Dich an das Bundle für die ATI's ;-). Zuletzt wollten sie Monatg "ganz bestimmt" damit Gold sein... und sind es immer noch nicht.

Ganz zu schweigen von den schon jetzt entdeckten Bugs in der Grafik-Engine und des exklusiv vorhandenen ATI-Pfades. Sorry, aber für mich hört sich das nicht gerade nach einem 'fertigen' Game an...

Und was soll bitte der CodeKlau (wenn es denn einer war) mit der Grafik-Engine zu tun haben?
Ich könnte je noch verstehen, dass sie was an der Game-Engine tun mussten, um z.Bsp. das Cheaten zu verhindern, aber das sollte es dann auch schon gewesen sein. Was also sollen diese immer wieder eintretenden Verzögerungen? Gabe macht sich langsam mit seinen 'Ankündigungen' wirklich lächerlich.

Razor

P.S.: aber erhlich gesagt, habe ich von Dir auch nichts anderes erwartet... ;)

deekey777

2004-09-01, 12:35:37

Heute gab's ja ein Update der CSS beta - einiges wurde geändert. Gibt's jetzt Wasser?

Demirug

2004-09-01, 16:59:22

Heute gab's ja ein Update der CSS beta - einiges wurde geändert. Gibt's jetzt Wasser?

Nein.

Jesus

2004-09-01, 17:05:22

ID hat einfach nach ARB2 geproggt und eine sehr extensive Schattentechnik implementiert, die den ATI's offenbar nicht wirklich gut bekommt, dafür den nVidia's ebenso offenbar keinerlei Probleme bereitet.

ist zwar OT, aber dafür gibt es keine Beweise. Im Gegenteil, lt Tombmans Benchmarks ( in Tombmans d3 Benchmark thread ) verlieren beide Hersteller bei aktivierten Schatten etwa gleich viel Performance...

IVN

2004-09-01, 17:11:11

@Demirug

Could you show as 2 shots for comparision ?One with FP16 and the 2nd with FP32.

MikBach

2004-09-01, 18:15:38

Erzähl nicht so einen blödsinn...

ATI hat Treiber-Probleme gehabt, die mit einem neuen Beta-Treiber schon nachweislich gefixt sind.
Der Humus-Tewak optimiert speiziell auf eine Hardware hin... ATI, wenn Dir der Name seines Arbeitgebers etwas sagt.
Dass die nVidia-Karten mit einem so einseitig optimierten Pfad nicht sonderlich gut zurecht kommen, haben wir ja nun mehrfach schon an anderer Stelle gesehen (wie zuletzt an der cs:s beta Engine).
Hä?
Deine Argumentation ist aber nicht sehr stimmig. ;)
Der Humus(ich weiss, dass es ein ATI-Mitarbeiter ist)-Tweak bringt bei einer 9800PRO ca. 30% mit AF.
Wenn das wenig ist, dann weiss ich nicht mehr.
Was soll das jetzt mit CS:S(DX) zu tun haben?
ID hätte einen Mittelweg finden können, dann hätte zwar Nvidia bisschen eingebüsst, ATI profitieret, und beide wären nicht so weit auseinander. ID wollte das nicht und hat sich einen Dreck um ATI gekümmert. Hauptsache Nvidia bekommt volle Power. ;)
BTW Warum erzählt JC denn so ein Scheiss, dass er aus allen Karten das optimum rausholt? Soll er doch einfach sagen: Ich stehe Nvidia sehr nahe, die bieten mir einen besseren Support, deswegen optimiere ich für sie mehr, und gut ist.

ID hat einfach nach ARB2 geproggt und eine sehr extensive Schattentechnik implementiert, die den ATI's offenbar nicht wirklich gut bekommt, dafür den nVidia's ebenso offenbar keinerlei Probleme bereitet. Dann kommt noch hinzu, dass durch diesen Humus-Tewak gerade mal 6-8% Leistung heraus gekommen sind, was immer der Fall sein dürfte, wenn man auf eine speizielle Hardware hin optimiert.
Ja, alles klar, als ob Humus den Pfad verändert hätte. Seine Tweaks beziehen sich auf den ARB2-Pfad, also was soll diese Argumentation hier?
Thief3 und DX2 haben auch eine super Schattentechnik(vielleicht sogar besser als D3), und? ATI ist schneller.
Du wolltest wohl sagen, dass JC extra eine Programmierung der Schatten auf eine Weise vorgenommen hat, welche den ATIs das Genick bricht? ;)

Zu Valve kann mich ich erst äussern, wenn das Produkt auf dem Markt ist, sonst ist es Spekulation.

Razor

P.S.: aber erhlich gesagt, habe ich von Dir auch nichts anderes erwartet... ;)
Ich von Dir auch nicht. ;)

Gast

2004-09-01, 18:21:09

ist zwar OT, aber dafür gibt es keine Beweise. Im Gegenteil, lt Tombmans Benchmarks ( in Tombmans d3 Benchmark thread ) verlieren beide Hersteller bei aktivierten Schatten etwa gleich viel Performance...

...was wiederum garnichts aussagt, es sei denn du legst jetzt hier in allen Einzelheiten dar, was die D3 engine mit und ohne schatten genau berechnet.

Gast

2004-09-01, 18:23:00

Hä?
Deine Argumentation ist aber nicht sehr stimmig. ;)
Der Humus(ich weiss, dass es ein ATI-Mitarbeiter ist)-Tweak bringt bei einer 9800PRO ca. 30% mit AF.

Wie lange dauert es denn noch, bis du endlich mal verstanden hast, was bei dem Tweak passiert?
Ach ja, auf meiner 9500Pro bringt des Tweak etwa 0,3fps mehr. Wahrlich eine Glanzleistung!

MikBach

2004-09-01, 18:25:38

Wie lange dauert es denn noch, bis du endlich mal verstanden hast, was bei dem Tweak passiert?
Ach ja, auf meiner 9500Pro bringt des Tweak etwa 0,3fps mehr. Wahrlich eine Glanzleistung!
Mit AF?

Mr. Lolman

2004-09-01, 18:32:50

dead, wer weiss schon wie lange das schon so geht?

Hat sich in der Vergangenheit jemand darüber wirklich Gedanken gemacht? Wurden jemals entsprechende Unterschungen angestellt?

Fragte ich mich schon öfters...
Damals hiess es noch, dass man garnicht die Möglichkeit hätte auf einen bestimmten IHV hin zu optimieren. (Waren AFAIK auch deine Worte)

Erzähl nicht so einen blödsinn...

Ists wirklich Mikbach, der Blödsinn erzählt?

ATI hat Treiber-Probleme gehabt, die mit einem neuen Beta-Treiber schon nachweislich gefixt sind.
Der Humus-Tewak optimiert speiziell auf eine Hardware hin... ATI, wenn Dir der Name seines Arbeitgebers etwas sagt.
Dass die nVidia-Karten mit einem so einseitig optimierten Pfad nicht sonderlich gut zurecht kommen, haben wir ja nun mehrfach schon an anderer Stelle gesehen (wie zuletzt an der cs:s beta Engine).

Hm, könnte man nicht genauso damit argumentieren, dass NV Treiberprobleme hat? Oder sinds gar HW Probleme, die dafür verantwortlich sind, das NV Karten mit einseitig optimierten Pfaden nicht zurecht kommen. Bei der Source Engine hat man einen eigenen ATi Pfad entdeckt. Na und? Bei Doom3 heisst der Pfad halt nicht NV Pfad, sondern ARB2. Der Humuspfad ist genauso ein ARB2 Pfad, nur dass der dann vgl. mit dem originalem, halt wirklich auf ATI optimiert wurde...

ID hat einfach nach ARB2 geproggt und eine sehr extensive Schattentechnik implementiert, die den ATI's offenbar nicht wirklich gut bekommt, dafür den nVidia's ebenso offenbar keinerlei Probleme bereitet. Dann kommt noch hinzu, dass durch diesen Humus-Tewak gerade mal 6-8% Leistung heraus gekommen sind, was immer der Fall sein dürfte, wenn man auf eine speizielle Hardware hin optimiert.

Gäbe es kein App-, sondern nur CP AF (wär auch nicht so aussergewöhnlich) wären es schon 40%...

An der Schattentechnik liegts nunmal nicht. Nur an der Shadertechnik. Denn die Schatten ändern sich nicht bei dem Humus Pfad, und ich wage zu behaupten, dass ein einseitig optimierter ATi Pfad, trotz der für ATi scheinbar unbekömmlichen Schattentechnik in Verbindung mit CP AF, ATi Katren vorne sein lassen würde. Aber das ist eh schon längst gegessen.

Zudem ist es hier noch völlig OT.
Sorry, dass ich diesen Sachverhalt erwähnte...

Stimmt, wirklich völlig OT. Aber gut das wir darüber gesprochen haben :-)

Valve ist schon seit Ewigkeiten "noch nicht fertig". Bedenke, dass sie schließlich schon Mitte letzten Jahres damit 'fertig' sein wollte (erinnerst Du Dich an das Bundle für die ATI's ;-). Zuletzt wollten sie Monatg "ganz bestimmt" damit Gold sein... und sind es immer noch nicht.

Diese ewige Herumgschastelei mit Veröffentlichungsterminen die man nicht einhalten kann, geht mir auch enorm am Nerv. Ist aber wirtschaftlich sicher erklärbar. (Allein wenn man sich den Aufwand fürs Leveldesign ansieht) Kein Publisher wird gerne mal von Hausaus 5-6 Jahre lang Kohle in ein Spiel investieren, was noch nichteinmal die sicherheit eines Kassenschlagers bringt. Da schaut man halt, dass in 2-3 Jahren was zum herzeigen da ist, damit die Investoren wieder beruhigen, setzt den Veröffentlichungstermin innerhalb der nächsten 9 monate, auch wenn man ganz genau weiss, dass sich das nie asugeht. Da kommt ja so ein Codeklau dann nur recht ;)

Ganz zu schweigen von den schon jetzt entdeckten Bugs in der Grafik-Engine und des exklusiv vorhandenen ATI-Pfades. Sorry, aber für mich hört sich das nicht gerade nach einem 'fertigen' Game an...

Demirug wird schon richten. Und wenn nicht, dann der nächste NV Treiber. ;)

Und was soll bitte der CodeKlau (wenn es denn einer war) mit der Grafik-Engine zu tun haben?
Ich könnte je noch verstehen, dass sie was an der Game-Engine tun mussten, um z.Bsp. das Cheaten zu verhindern, aber das sollte es dann auch schon gewesen sein. Was also sollen diese immer wieder eintretenden Verzögerungen? Gabe macht sich langsam mit seinen 'Ankündigungen' wirklich lächerlich.

Razor

Grad wenn man den Sourcecode der Grafikengine hat, kann man imo super cheaten. Wenn man die ganzen Adressierungsbereiche kennt, ists nurmehr halbsowild, neuen (z.B.durchsichtigen) Content mittels Cheattool miteinzubringen. Zwar schafft man das auch ohne Sourcecode, aber ohne dem dürfts nichtso einfach sein, div. Sicherheitsmechanismen auszuhebeln, die Cheaten eigentlich unterbinden sollten. Und die können sich m.E. durchaus auch in der Grafikengine befinden...

P.S.: aber erhlich gesagt, habe ich von Dir auch nichts anderes erwartet... ;)

unnötiger Flame.... ;)

Ich versteh zwar auch nicht ganz, was Valve da abzieht...

...ABER, solang den GraKas wirklich nur manche Shader nicht schmecken, (ATi bei Doom, NV bei HL2) ists ja eh kein Problem. Die Sachen, wo sich die Treiberprogger nicht mehr rübertrauen (man kann ja nicht gleich alle HL2 Shader gegen IHV optimierte austauschen), erledigt eh die Community. Schlimm wirds, wenn die Engine grundsätzlich so aufgebaut ist, dass sie einem IHV nicht bekommt. (aber das ist ja angeblich ohnehin nicht möglich)

Habs zwar schonmal geschrieben, und auch schon in dem Thread gelesen, aber möcht' nochmal konstatieren, dass mir als Spieler, diese Entwicklung überhaupt nicht gefällt. Denn bei einseitigen Optimierungen bleibt halt auf der anderen Seite immer für irgendjemanden Leistung auf der Strecke, und bezahlen, darf das der spieler, der sich eine neue HW kauft, weil die alte nur mehr Ruckelgrafik bringt.

Bsp: Doom3. Original mit Catalyst 4.7 war so "flott", dass ichs in 1024, High Detail mit 4xbi AF gespielt hab. 2xAA hatte ich auch an, was aber stellenweise richtig langsam wurde...
Mit dem Humustweak und 4.9beta hab ich die selben Settings, 4x Fulltri AF, 2xAA und noch mehr Frames. (ca. soviel wie vorher mit 1024 2xAA, 4xbi und Medium Details)
D.H. vorher war das spiel an der Grenze des Ertragbaren, jetzt rennts ganz gut. und das ganz ohne neue HW (mittlerweile spiel ichs eh in 1280x1024)

Andererseits könnte man wieder damit argumentieren, dass bei solch einseitigen Optimierungen (Source Engine =>ATI) viel geld fliesst, was für die Spieleentwicklung verwendet werden kann => besseres Spiel. Die Community biegt durch Tweaks/Tools die Ungerechtigkeiten wieder gerade, und beide Seiten haben dann ein tolles und auch schnelles Spiel. Im Idealfall.

Dass ich mich nicht so sehr auf HL2 versteife, wie manch anderer, mag auch den Grund haben, dass ich HL1 nicht sonderlich toll fand. (War wohl das erste spiel welches trotz guter Qualitäten eindeutig zuviel gehyppt wurde. Hätt ich zuvor nie was von HL1 gehört, hätts mir wahrscheinlich sogar gefallen. so war halt die Erwartungshaltung einfach zu hoch. Doom3 hat meine enormen Erwartungshaltungen gerade noch erfüllen können, und dementsprechend find ichs genial (abgesehen von der ARB2/Humus Sache)

Mr. Lolman

2004-09-01, 18:40:56

Wie lange dauert es denn noch, bis du endlich mal verstanden hast, was bei dem Tweak passiert?
Ach ja, auf meiner 9500Pro bringt des Tweak etwa 0,3fps mehr. Wahrlich eine Glanzleistung!

Nicht flamen, vielleicht limitiert ja die Speicherbandbreite beim aktiven Humustweak (glaub ich aber eigentlich kaum ,und kanns sogar nachpüfen *auch9500prohab*) Jedenfalls bringt der Tweak bei meiner 9700pro mit originalen Spielsettings, ohne ControlPanel AF 6-8%. (bei 1024/1280 High Quality mit und ohne AA) Hochgerechnet auf deine 9500pro, hättest du entweder nur 3.75fps, oder einfach Settings gewählt, bei denen die CPU oder was anderes limitiert...

Wenn man AF im control Panel wählt, können durchaus +35% rausschauen, und das schon auf R300 Karten. Bei R420 ist sicher noch ein bisschen mehr drinnen!!

Andererseits könnte man es auch diversen NV Fanboys nachmachen und sagor auf die 0.3fps stolz sein, denn bei aktivierten Ultrashadow sinds auch nicht viel mehr, und trotzdem geht allen dabei einer ab ;D

Aber lassen wir das jetzt, denn es ist wirklich völlig OT...

Gast

2004-09-01, 18:48:54

Mit AF?

Beides!

MikBach

2004-09-01, 18:50:03

Beides!
Hä, was Beides?
Nenn mal deine Einstellungen. ;)

Gast

2004-09-01, 18:51:13

Wenn man AF im control Panel wählt, können durchaus +35% rausschauen, und das schon auf R300 Karten. Bei R420 ist sicher noch ein bisschen mehr drinnen!!

Wenn du mal verstanden hast, was der Tweak macht dann reden wir weiter.
Ansonsten gilt für dich: Nicht flamen!

MikBach

2004-09-01, 18:58:26

Wenn du mal verstanden hast, was der Tweak macht dann reden wir weiter.
Ansonsten gilt für dich: Nicht flamen!
Lol. Bist du der gleiche Gast den ich gebeten habe die Einstellungen zu posten?
Los, los, mach es! Dann sage ich dir was du falsch machst.
Die Gäste kommen ja wie Pilze nach dem Regen. ;D

Demirug

2004-09-01, 19:01:19

Mr. Lolman, bei DX8 war es auch schwer möglich für einen IHV zu optimieren. Aber blödsinn machen konnte man schon immer wenn man wollte.

Mr. Lolman

2004-09-01, 19:03:15

Wenn du mal verstanden hast, was der Tweak macht dann reden wir weiter.
Ansonsten gilt für dich: Nicht flamen!
Erklärs du mir bitte. Verstanden hab ich nämlich anscheinend nicht, denn wenn wirklich nur der AF Bug damit umgangen wär, dann sag mir bitte warum ATi Karten beim switchen auf fulltri kaum Performance verlieren, NV Karten aber trotzdem eingehen (sowohl mit Humus- als auch ohne Humustweak)*
Bin gespannt ob du das besser kannst als aths, oder Demirug.

BTW: "Flamen" richtet sich immer gegen eine Person (Definition von Flame), dementprechend sind deine Aussagen eher als Flame einzustufen als meine. Aber das ist nicht Gegenstand der Diskussion, genausowenig wie D3. Aber den Humustweak hätt ich schon noch gerne von dir erklärt.

*mal unbeachtet dessen, dass Doom so programmiert wurde, dass man kein AF auf allen TS benötigt...

Demirug

2004-09-01, 19:27:34

MikBach

2004-09-01, 19:35:36

Um mal wieder auf das Thema (CS:S) zurück zu kommen.

Mit der neuen Version von heute ist mein NV35 im DX9 Pfad (mit Wasser) mit 8xAF (in Game) plötzlich so schnell wie die alte Version mit den Defaul setings (0xAF).

Ohne AF bin ich jetzt bei 32 (FP) bzw 48 (PP).

Aha, also hatte ich Recht, Valve war noch nicht ganz fertig. Das Thema von Razor dürfte damit ein Ende gefunden haben. ;)

@ Demi
Weisst Du, ob Valve PP einbauen will? Bringt es keine optischen Nachteile?
Danke. :)

tokugawa

2004-09-01, 19:37:02

Hä?
Ja, alles klar, als ob Humus den Pfad verändert hätte. Seine Tweaks beziehen sich auf den ARB2-Pfad, also was soll diese Argumentation hier?
Thief3 und DX2 haben auch eine super Schattentechnik(vielleicht sogar besser als D3), und? ATI ist schneller.

Das zeigt wie wenig du eigentlich von Grafikalgorithmen verstehst.

Prinzipiell haben Thief 3 und Deus Ex 2 dieselbe Schattentechnik (Shadow Volumes), aber soweit ich weiß, mittels Z-Pass/Depth-Pass Technik. Die Z-Fail/Depth-Fail Technik (auch Carmack's Reverse genannt - na, klingelt's?) ist allerdings bekannt dafür, dass sie robuster ist (Z-Pass wird ziemlich unbequem, wenn der Eye-Point sich innerhalb eines Schattenvolumens befindet). Aus dem Analyseartikel von Doom 3 bezüglich NV40 auf 3DCenter wissen wir aber, dass gerade Z-Fail gut zur NV40 passt.

Du wolltest wohl sagen, dass JC extra eine Programmierung der Schatten auf eine Weise vorgenommen hat, welche den ATIs das Genick bricht? ;)

Ja. Genau das steht im Artikel. NV40s Early Z passt besser zu Carmack's Reverse als ATI's HierZ.

Zu Valve kann mich ich erst äussern, wenn das Produkt auf dem Markt ist, sonst ist es Spekulation.

Ich von Dir auch nicht. ;)

Der Humus-Tweak ist, soweit ich es verstanden habe, unflexibler als der Originalshader. Also wenn man's genau nimmt, funktional nicht ident mit dem Originalshader. Warum sollte JC sowas programmieren, wenn er mehr Flexibilität als Hintergedanken hatte? Wenn er überhaupt die Shader gemacht hat. Shader (vor allem Pixelshader) sind ja jetzt nicht unbedingt die Kernkomponenten einer Engine, da gibt's ganz andere Dinge die wichtiger sind. Bloß weil der Humustweak im Speziallfall "Doom 3" funktioniert, heißt das nicht, dass es jetzt ein Tweak ist, der 1:1 dasselbe bietet wie das Original.

Außerdem arbeitet Humus bei ATI, ist also ziemlicher Experte in ATI Sachen (seine Homepage zeigt ja auch beeindruckende Demos, die etwas ATI-lastig sind). Du bist anscheinend kein Entwickler, wenn du die irrwitzige Idee hast, dass Entwickler jede erdenkliche Hardware "in und auswendig" kennen müssen. Vermutlich hat JC - oder wer auch immer den Shader programmiert hat - eben mehr Erfahrung mit Standard-ARB2 und NVIDIA-Hardware. Ich wage es mal zu behaupten, dass nur wirkliche ATI-Experten den Tweak hätten machen können. D.h. es ist für ARB2-Experten (für einen solchen halte ich JC), nicht unbedingt eine Wissenslücke. Und du kannst nicht im Ernst erwarten, dass ein Entwickler, der sowas nicht weiß (und es steht auch nirgends wirklich), so lange rumprobiert, bis er auf den Tweak kommt.

Lern programmieren und entwickeln, bitte.

MikBach

2004-09-01, 19:43:18

@ tokugawa

Die Techniken sind mir durchaus bekannt, darum geht es hier aber nicht.
Es geht um den Willen auf Beide Firmen zu optimieren, was JC versäumt hat, oder es so mit Absicht getan hat.
Das Thema ist eh schon gegesen, du kommst bisschen spät mit deinem Posting. ;)
Trotzdem danke für deine Erklärung, habe ich aber auch schon so gewusst. :)

Demirug

2004-09-01, 19:49:56

Aha, also hatte ich Recht, Valve war noch nicht ganz fertig. Das Thema von Razor dürfte damit ein Ende gefunden haben. ;)

@ Demi
Weisst Du, ob Valve PP einbauen will? Bringt es keine optischen Nachteile?
Danke. :)

Shadertechnisch hat sich nichts verändert. Es sieht eher so aus als hätte die alte Version MaxAF erzwungen. Und fertig sind sie immer noch nicht. Die neue Version läuft nämlich nicht mehr bei mir wenn Steam auf Deutsch steht.

Trotzdem hat Valve das Ding veröffentlicht und es wurde ja auch schon fleisig damit gebencht. Aus diesem Grund ist es also IMHO schon wichtig das man weiss welche Macken diese Beta noch hat um die Benchs einzuordnen.

Ich habe es ja schon einmal gesagt. Die NV3X Shader (mit PP) waren beim Shader Day noch vorhanden. Jetzt sind sie nicht mehr da. Ich würde mir keine alzu grossen Hoffnungen machen das sie wieder auftauchen.

LovesuckZ

2004-09-01, 19:57:30

Erklärs du mir bitte. Verstanden hab ich nämlich anscheinend nicht, denn wenn wirklich nur der AF Bug damit umgangen wär, dann sag mir bitte warum ATi Karten beim switchen auf fulltri kaum Performance verlieren, NV Karten aber trotzdem eingehen (sowohl mit Humus- als auch ohne Humustweak)*

http://www.techreport.com/etc/2004q3/ati-doom3/index.x?pg=7

tokugawa

2004-09-01, 20:07:13

@ tokugawa

Die Techniken sind mir durchaus bekannt, darum geht es hier aber nicht.

Ach so, gut dass du in der Zwischenzeit recherchiert hast. Dein Posting ganz oben zeigte nämlich Anzeichen von Unkenntnis bezüglich der Gemeinsamkeiten und Unterschiede der DX2 und Doom 3 Schattentechnik.

Es geht um den Willen auf Beide Firmen zu optimieren, was JC versäumt hat, oder es so mit Absicht getan hat.

JC hat meiner Ansicht nach (meiner Entwickler-Ansicht nach) auf ARB2 "optimiert". Also so programmiert, wie es nach ARB2 am besten ist.

Weiters hat er einige offiziell zugängliche Implementierungs-Empfehlungen befolgt.

Was der Humus Tweak macht, steht in keinem Paper (sollte es in einem stehen, bitte Link. Ich hab's nicht gefunden). Soll JC jetzt Prophet sein, und Tweaks einbauen, die er nicht wissen kann? Entwickler sind keine Götter und können nicht immer alles wissen. JC ist trotzdem ein guter Entwickler. Ich will ihn weder overhypen (was einige tun), noch underhypen (was ebenfalls einige tun). Obwohl es ja nicht unbedingt JC selbst war, der diesen speziellen Shader programmiert hat. Ich wüsst gern wieso alle immer davon ausgehen, dass JC sich um jeden Sch* der Doom 3 Engine gekümmert hat. Gerade der vom Humus-Tweak modifizierte Shader ist ja nicht wirklich so zentral, Engine-technisch gesehen.

Aus eigener Erfahrung weiß ich, dass als Entwickler - selbst wenn man aktuelle Karten beider Hersteller besitzt - das Programmieren für beide Karten öfters ein Schmerz im Hintern ist. Und zwar unter OpenGL ganz ganz ganz besonders. Das Nichtwissen seitens id software über den in den Humus-Tweak eingesetzten Sachen ist IMO sehr verzeihlich.

Ob das, was Valve tut bzw tun wird, verzeihlich ist aus Entwicklersicht, wird sich ja noch zeigen. Hier wage ich keine Prognose (vielleicht tauchen die PP Shader ja noch auf :) ).

Das Thema ist eh schon gegesen, du kommst bisschen spät mit deinem Posting. ;)
Trotzdem danke für deine Erklärung, habe ich aber auch schon so gewusst. :)

Hatte nicht den Eindruck nach Lesen deines Postings :) aber vermutlich hast du in der Zwischenzeit nachrecherchiert.

MikBach

2004-09-01, 20:09:48

Shadertechnisch hat sich nichts verändert. Es sieht eher so aus als hätte die alte Version MaxAF erzwungen. Und fertig sind sie immer noch nicht. Die neue Version läuft nämlich nicht mehr bei mir wenn Steam auf Deutsch steht.
Das mit Steam kann ich verstehen. Das war laut Valve auch das grösste Problem nach dem Codeklau.

Trotzdem hat Valve das Ding veröffentlicht und es wurde ja auch schon fleisig damit gebencht. Aus diesem Grund ist es also IMHO schon wichtig das man weiss welche Macken diese Beta noch hat um die Benchs einzuordnen.
Korrekt. Ich denke das haben sie mit Absicht gemacht, wie JC bei Doom3. Klar, wenn ATI 6 oder 8 MIllionen(weiss jetzt nicht mehr genau) springen lässt, dann wollen sie auch was sehen. Genauso wie bei NV und Doom3. Ist doch nur logisch. :)

Ich habe es ja schon einmal gesagt. Die NV3X Shader (mit PP) waren beim Shader Day noch vorhanden. Jetzt sind sie nicht mehr da. Ich würde mir keine alzu grossen Hoffnungen machen das sie wieder auftauchen.
Na ja, ich würde die Hoffnung nicht aufgeben, es sei denn es trifft das zu, was ich schon geschrieben habe(Sponsoring). Nett wäre das aber nicht, wie bei Doom3. :)

Mr. Lolman

2004-09-01, 20:15:57

*doppelpost*

Mr. Lolman

2004-09-01, 20:16:47

http://www.techreport.com/etc/2004q3/ati-doom3/index.x?pg=7

Die Benchmarks sind falsch. Denn bilinear sollte nie langsamer sein als Gamedefault. Das ist es aber wenn mans direkt in der Console umstellt und kein vid_restart macht. Sonst aber nicht. Wer weiss wie die Scores der anderen Benchmarks zustande gekommen sind, auf jeden Fall ist das Crap...

LovesuckZ

2004-09-01, 20:20:03

Die Benchmarks ind falsch. Denn bilinear sollte nie langsamer sein als Gamedefault.

Oh, hast du dann Benchmarks, die deine Behauptung stuetzen?

Mr. Lolman

2004-09-01, 20:22:47

Oh, hast du dann Benchmarks, die deine Behauptung stuetzen?

Nicht von NV Karten. Und den neuen ATi Treiber, wo das AF Problem behoben isst, hab ich nicht. Dass bi-AF nie langsamer sein sollte, als gamedfault ist eigentlich logisch, aber dafür könnt auch Benchmarks liefern, wenn du willst...

Gast

2004-09-01, 20:22:47

Korrekt. Ich denke das haben sie mit Absicht gemacht, wie JC bei Doom3. Klar, wenn ATI 6 oder 8 MIllionen(weiss jetzt nicht mehr genau) springen lässt, dann wollen sie auch was sehen. Genauso wie bei NV und Doom3. Ist doch nur logisch. :)

Könntest du statt haltloser Unterstellungen auch mal fachlich argumentieren sofern du denn tokugawas Ausführungen zu Carmack´s reverse verstanden hast?

Quasar

2004-09-01, 20:28:54

Die Benchmarks sind falsch. Denn bilinear sollte nie langsamer sein als Gamedefault. Das ist es aber wenn mans direkt in der Console umstellt und kein vid_restart macht. Sonst aber nicht. Wer weiss wie die Scores der anderen Benchmarks zustande gekommen sind, auf jeden Fall ist das Crap...

Hast du den Text dazu auch gelesen?

MikBach

2004-09-01, 20:30:05

Könntest du statt haltloser Unterstellungen auch mal fachlich argumentieren sofern du denn tokugawas Ausführungen zu Carmack´s reverse verstanden hast?
Könntest du auch fachlich dokumentieren sofern du Humus´ Tweak verstanden hast?

Jesus

2004-09-01, 20:41:33

Oh, hast du dann Benchmarks, die deine Behauptung stuetzen?

aber gerne ( OT - ALARM :biggrin: )

D3, 1152 x 864 , High Details , demo1, APP AF ( = 8x ingame ): 39,4 fps

D3, 1152 x 864 , High Details , demo1, CP 8x bi AF: 40,6 fps

(beides 2. Durchgang, inkl. humus)

Mr. Lolman

2004-09-01, 20:45:17

Hast du den Text dazu auch gelesen?

Ok, die Benchmarks sind nicht falsch. Aber irreführend (v.A. wenn man den Text nur überfliegt :redface: )

Gut damit ist ATis AF Bug beseitigt. Das ändert aber trotzem nichts an der Tatsache, dass sich JC auch überhaupt nicht ums AF scheren hätte können, und die Shader nach Humus' Art proggen hätte können. ABER IST JA EGAL JETZT, weil viel zu OT...

Sry, für meine überstürzten Mutmassungen bez. der Richtigkeit der Benchmarks...

Mr. Lolman

2004-09-01, 20:47:17

Um mal wieder auf das Thema (CS:S) zurück zu kommen.

Mit der neuen Version von heute ist mein NV35 im DX9 Pfad (mit Wasser) mit 8xAF (in Game) plötzlich so schnell wie die alte Version mit den Defaul setings (0xAF).

Ohne AF bin ich jetzt bei 32 (FP) bzw 48 (PP).

Leider habe ich mit der alten Version keine Benchs mit AF gemacht.

Wieviel fps fehlen denn noch zum R350?

Demirug

2004-09-01, 21:37:34

Wieviel fps fehlen denn noch zum R350?

Immer noch eine ganze Menge. Im DX9 Pfad wird ein R350 auch nur schwer von einem NV35 zu schlagen sein.

Gast

2004-09-01, 21:43:03

Ok, die Benchmarks sind nicht falsch. Aber irreführend (v.A. wenn man den Text nur überfliegt :redface: )

Gut damit ist ATis AF Bug beseitigt. Das ändert aber trotzem nichts an der Tatsache, dass sich JC auch überhaupt nicht ums AF scheren hätte können, und die Shader nach Humus' Art proggen hätte können.

Normalerweise sollte man es ausschlisslich der Applikation überlassen wie gefiltert (oder auch antialiased) wird.

MikBach

2004-09-01, 21:49:13

Normalerweise sollte man es ausschlisslich der Applikation überlassen wie gefiltert (oder auch antialiased) wird.
Wenn die Applikation von einem Trottel programmiert wurde, der es nicht auf die Reihe kriegt, ist das CP besser. :)

edit: Man sollte also erstmal beide Versionen versuchen, um festzustellen, ob der Programmierer ein Trottel ist oder nicht. Sollte das CP besser funken, ist der Progger ein Trottel. :)

MadMan2k

2004-09-01, 22:30:48

MikBach

2004-09-01, 22:46:50

was heisst besser? schneller = besser?
IMHO bist du etwas voreilig mit deinem Urteil, denn der Gast hat durchaus Recht - das Optimum wäre, wenn die Applikation das AA/AF regeln würde, denn dann könnte sie bestimmen, welche Stages Bi, welche Tri und welche überhaupt AF benötigen und man könnte Atis/NVs Stage-"Optimierungen" eindeutig als Cheat brandmarken.
Leider bauen nur die wenigsten Progger eine solche Steuerung ein...
Nein, ich meine die gleiche BQ. Wenn das CP alle Stages filtert und ist dabei noch schneller, dann ist der Progger für den Arsch. Der muss dann was falsch gemacht haben.
Es ist aber sinnvoll es von der APP zu machen, wenn die Performance deutlich besser als im CP ist. Ist das nicht der Fall, sollte der Progger noch mal in die Schule gehen und nachlernen.

tokugawa

2004-09-02, 02:09:49

Das mit Steam kann ich verstehen. Das war laut Valve auch das grösste Problem nach dem Codeklau.

Korrekt. Ich denke das haben sie mit Absicht gemacht, wie JC bei Doom3. Klar, wenn ATI 6 oder 8 MIllionen(weiss jetzt nicht mehr genau) springen lässt, dann wollen sie auch was sehen. Genauso wie bei NV und Doom3. Ist doch nur logisch. :)

Na ja, ich würde die Hoffnung nicht aufgeben, es sei denn es trifft das zu, was ich schon geschrieben habe(Sponsoring). Nett wäre das aber nicht, wie bei Doom3. :)

Übrigens, "Carmack's Reverse" ist eine Technik die schon vor dem NV-ID Software Deal bekannt war.

Und, du hast mir noch immer nicht gezeigt, wo die im Humus Tweak angewandte Methode dokumentiert ist. Zeig mir Papers oder Dokumentationen, in denen beschrieben ist, dass sowas auf ATI Karten Performance bringt. Denn wieso nimmst du an, die Entwickler von ID Software wüssten mehr als andere OpenGL-Programmierer (ich wüsste es z.B. auch nicht, und viele andere, die ich kenne, ebenfalls nicht). Und nein, Entwickler kriegen keine "geheimen Dokumente" wo Geheimtricks zum Tweaken beschrieben werden. Entwickler programmieren und testen, basierend auf den ihnen zugänglichen Informationen (bis auf Bücher sind das meistens Dokumentationen die jeder - auch du und ich - lesen können. Bücher kann auch jeder kaufen). Der im Humus-Tweak angewandte Tweak ist halt ID Software entgangen. Das ist nichts verwerfliches und hat IMO nichts mit dem ID-NV Deal zu tun (bzw ist das reine Spekulation. Du solltest nicht davon sprechen als wäre das bereits bewiesene Tatsache - das ist es nicht. Nur aus deinem begrenzten Horizont - also ohne dem weiteren Horizont eines Entwicklers/Programmierers - könntest du sowas unreflektiert als Tatsache behaupten).

John Carmack hat nicht all zu sehr auf NV getweakt, sondern hat generell danach optimiert, nach den Informationen, die allgemein publik zur Verfügung stehen (wie gesagt, auch Entwickler haben keine supergeheimen Dokumente mit "geheimen Tuning-Tipps". Im Allgemeinen stehen John Carmack die selben Informationen zur Verfügung wie jedem von uns). Dass Humus, ein ATI-Mitarbeiter, dann einen alternativen Weg findet, der Performance rausholt, ist kein Beweis, dass JC "zu wenig" auf ATI optimiert hätte, sondern zeigt eher, dass Humus wirklich was von ATI-Karten versteht.

Was ich nicht verstehe ist, dass wenn Doom 3 auf ATI Karten schneller gewesen wäre, hätten viele geschrien "Hah, NV sucks, ihr eigenes gesponsortes Spiel ist schneller auf Konkurrenzhardware". Jetzt wo Doom 3 auf NV schneller ist, ist es natürlich ein Fall von "Hah, NV hat ID bestochen, übermäßig auf NV zu optimieren". Kann man nicht akzeptieren, dass Doom 3 einfach schneller ist auf NV40, und sonst nichts? Ich mein, wenn der ID-NV-Deal so ein Riesenausmaß gehabt haben soll, wieso zieht dann nicht die FX auch davon? Ich mein, wenn schon übermäßig optimieren aufgrund von Sponsoring, wieso nicht auch für die FX?

Meine These ist, dass Doom 3's Engine einfach technisch auf NV40 schneller läuft. Aufgrund dessen, dass der NV40 besonders gewisse Techniken in Doom 3 mag. Und nein, diese Techniken in Doom 3 wurden nicht aufgrund des Sponsoring entwickelt, denn diese Sachen (ZFail und so) gab es schon vorher.

tokugawa

2004-09-02, 02:13:17

Nein, ich meine die gleiche BQ. Wenn das CP alle Stages filtert und ist dabei noch schneller, dann ist der Progger für den Arsch. Der muss dann was falsch gemacht haben.
Es ist aber sinnvoll es von der APP zu machen, wenn die Performance deutlich besser als im CP ist. Ist das nicht der Fall, sollte der Progger noch mal in die Schule gehen und nachlernen.

Wenn man über's Control Panel alles Stages filtert, und dieser Fall schneller wäre als wenn man Application-controlled nur selektiv Stages (je nachdem wie man's braucht), filtert, dann würde das verdammt nach Filter-Trick riechen.

Sag mir bitte software-technisch einen Fall, wo sowas vorkommen sollte. Wenn CP das Maximum darstellt, kann man das Maximum schwer übertreffen, mathematisch. Außer das Maximum ist "fake", also wird getrickst.

Die Software bleibt ja gleich. Der Unterschied liegt nur darin, dass statt der minimal-benötigten Filterung man immer die maximale Filterung benötigt. IMO wäre der beschriebene Fall zur Mehrheit dem Treiber anzulasten.

tokugawa

2004-09-02, 02:18:13

Wenn die Applikation von einem Trottel programmiert wurde, der es nicht auf die Reihe kriegt, ist das CP besser. :)

edit: Man sollte also erstmal beide Versionen versuchen, um festzustellen, ob der Programmierer ein Trottel ist oder nicht. Sollte das CP besser funken, ist der Progger ein Trottel. :)

Du hast nie programmiert, richtig?

Die Applikation fordert pro Stage nur den Filter-Level an.

Die Applikation sagt dem Treiber etwa, "gib mir trilinear filter auf stage 0 und 1 bilinear auf allen anderen Stages, und auf stage 0 AF Level 4" oder "gib mir auf stage 3 nur einen nearest filter".

Du scheinst zu glauben, dass die AF-Application-Control irgendwie speziell programmiert werden müsste, aber der Programmierer tut nichts anderes als (fine-grained, per stage) die AF-Levels anzufordern.

Wie bitte kann es da sein, dass CP-controlled Filtering schneller ist als App-Controlled? Im Worst Case sind sie ja gleich. Eine Ausnahme ist, wenn das CP-Controlled Filtering das ganze Cheating aktiviert. In diesem Fall wäre es dann möglich, dass CP-Controlled Filtering schneller wäre. Aber sonst geht das nicht.

Mir fällt zumindest keine Möglichkeit ein, da dem Programmierer in diesen Belangen sowieso die Macht fehlt, das zu vermurksen. Mehr als Filter-Level anfordern (also dasselbe wie der Anwender, nur dass der Programmierer das feiner kontrollieren kann, also per Stage) kann der Programmierer nicht.

MikBach

2004-09-02, 08:55:47

John Carmack hat nicht all zu sehr auf NV getweakt, sondern hat generell danach optimiert, nach den Informationen, die allgemein publik zur Verfügung stehen (wie gesagt, auch Entwickler haben keine supergeheimen Dokumente mit "geheimen Tuning-Tipps". Im Allgemeinen stehen John Carmack die selben Informationen zur Verfügung wie jedem von uns). Dass Humus, ein ATI-Mitarbeiter, dann einen alternativen Weg findet, der Performance rausholt, ist kein Beweis, dass JC "zu wenig" auf ATI optimiert hätte, sondern zeigt eher, dass Humus wirklich was von ATI-Karten versteht.

Was ich nicht verstehe ist, dass wenn Doom 3 auf ATI Karten schneller gewesen wäre, hätten viele geschrien "Hah, NV sucks, ihr eigenes gesponsortes Spiel ist schneller auf Konkurrenzhardware". Jetzt wo Doom 3 auf NV schneller ist, ist es natürlich ein Fall von "Hah, NV hat ID bestochen, übermäßig auf NV zu optimieren". Kann man nicht akzeptieren, dass Doom 3 einfach schneller ist auf NV40, und sonst nichts? Ich mein, wenn der ID-NV-Deal so ein Riesenausmaß gehabt haben soll, wieso zieht dann nicht die FX auch davon? Ich mein, wenn schon übermäßig optimieren aufgrund von Sponsoring, wieso nicht auch für die FX?

Meine These ist, dass Doom 3's Engine einfach technisch auf NV40 schneller läuft. Aufgrund dessen, dass der NV40 besonders gewisse Techniken in Doom 3 mag. Und nein, diese Techniken in Doom 3 wurden nicht aufgrund des Sponsoring entwickelt, denn diese Sachen (ZFail und so) gab es schon vorher.
Ich glaube auch nicht, dass es unbedingt Sponsoring sein muss. JC ist auch so ein Technikfreak, deswegen hat er auch viel mit dem NV40 rumgespielt(getweakt).
Und ich will nicht behaupten, dass ATI schneller oder gleich schnell sein sollte. Das wäre wirklich sehr seltsam und du kannst mir glauben, dass wenn es so wäre, ich es auch so zum Ausdruck gebracht hätte.
Der Unterschied ist in den meisten Benchmarks jedoch zu gross. Wenn ich mir aber die Benchmarks von tombman mit einer 6800Ultra und X800XT-PE ansehe, dann relativiert sich das wieder, auch dank dem neuen ATI-Treiber.

MikBach

2004-09-02, 09:06:57

Du hast nie programmiert, richtig?

Oh nein, was soll das beweisen?
Das hört sich für mich an wie Leute, die meinen weil sie paar Jahre in der IT-Branche gearbeitet haben, die IT-Weissheit mit Löffeln gefressen haben und alles was sie sagen stimmen muss.
Deswegen auch mein blödes Argument:
Bei einem Informatikstudium lässt sich das Programmieren nicht vermeiden. Beim mir war es sogar die "Hauptlast".

Zum AF:
So wie du es schreibst hast du natürlich Recht.
Jetzt mal in deiner Sprache: :)
Es lassen sich Fälle konstruiren z.B. andere Shader. Wenn man dann nicht das App-AF teilweise ändert könnte es sein, dass das CP besser funktioniert.
So wird es beim Humus-Tweak sein.

Jesus

2004-09-02, 12:12:33

Oh nein, was soll das beweisen?
Das hört sich für mich an wie Leute, die meinen weil sie paar Jahre in der IT-Branche gearbeitet haben, die IT-Weissheit mit Löffeln gefressen haben und alles was sie sagen stimmen muss.
Deswegen auch mein blödes Argument:
Bei einem Informatikstudium lässt sich das Programmieren nicht vermeiden. Beim mir war es sogar die "Hauptlast".

Doch lässt sich vermeiden ;) Ein Kumpel von mir hat z.b nen besseren Schnitt als ich und kann keine Zeile selbst programmieren. Es kommt immer drauf an wie man sich verkauft und ob man Prüfungen kann, bzw. obs die anderen können ;)

Programmieren lernt man im Informatik Studium sowieso nicht wirklich, sondern eh erst wenn mans mal richtig (im Beruf) gemacht hat.
(OT)

r@w

2004-09-03, 14:20:20

Könnten wir jetzt mal wieder zum Thema zurück kommen?

DANKE!

Um mal wieder auf das Thema (CS:S) zurück zu kommen.

Mit der neuen Version von heute ist mein NV35 im DX9 Pfad (mit Wasser) mit 8xAF (in Game) plötzlich so schnell wie die alte Version mit den Defaul setings (0xAF).

Ohne AF bin ich jetzt bei 32 (FP) bzw 48 (PP).

Leider habe ich mit der alten Version keine Benchs mit AF gemacht.Da hätte ich vielleicht einen 'kleinen' Hinweis...
:D

Razor

r@w

2004-09-03, 15:57:01

Tjo... wie soll ich anfangen?
:confused:

Vielleicht so...

Habe mir nun auch mal die V4 der cs:s beta Engine angetan (das 'deutsch'-Problem nebenbei gelöst ;-) und mich ebenso - wie Demirug wohl auch - gefragt, warum die Performance jetzt so viel besser geworden ist.

Erst einmal habe ich selbstredend ein bissel gebencht und auch ein paar Shader geloggt, um mal zu sehen, ob sich da was verändert hat. Die Situation ist (so ziemlich) noch immer die gleiche... FX5900 hat im DX9-Pfad noch immer kein Wasser und die Shader sind auch alle gleich geblieben... moment... oder doch nicht?

Mit V3 der Engine stellt sich dies folgendermaßen dar:
- FX5900 mit DX9-Pfad = ohne Wasser, keine PP-'Hints' für die Vertex-Shader
- FX5900@6800GT = mit Wasser, keine PP-'Hints' für die Vertex-Shader
- FX5900@X800 = mit Wasser, PP-'Hints' für die Vertex-Shader

Mit V4 der Engine sieht das jetzt so aus:
- FX5900 mit DX9-Pfad = ohne Wasser, keine PP-'Hints' für die Vertex-Shader
- FX5900@6800GT = mit Wasser, PP-'Hints' für die Vertex-Shader
- FX5900@X800 = mit Wasser, PP-'Hints' für die Vertex-Shader

Tjo, offenbar hat sich Valve meine Kritik zu Herzen genommen und füttert nun die 6800'er mit den gleichen Shadern, wie auch die X800'er... schonmal ein Grund zum jubilieren, oder etwa nicht?
;-)

Das reichte mir natürlich nicht, so interessierte mich natürlich, wie denn jetzt dieser 'Sinneswandel' zustande gekommen ist.

So habe ich denn eine sehr interessannte Datei mit dem wunderschönen Namen "Dxsupport.cfg" gefunden.
Äusserst interessant, kann ich Euch sagen... insofern ich da jetzt mal näher darauf eingehen werde...

Hier mal die generelle Deklaration für DX8.1 und DX9.0 in dieser Datei:

CS:S beta V3 "81" "90"
---------------------------------------------------------------------------
"DefaultRes" "1024" "1024"
"DxLevel" "81" "90"
"DefaultMSAA" "0" "0"
"DefaultAnisoLevel" "1" "1"
"UseZPrefill" "1" "1"
"NoUserClipPlanes" "0" "0"
"CentroidHack" "0" "0"
"ReduceFillrate" "0" "0"
"SkipMipLevels" "0" "0"
"SlopeScaleDepthBias_Decal" "-0.5" "-0.5"
"SlopeScaleDepthBias_Normal" "0" "0"
"DepthBias_Decal" "-262144" "-262144"
"DepthBias_Normal" "0" "0"
"ForceTrilinear" "1" "1"
"ForceHWSync" "1" "1"
"DisableSpecular" "0" "0"
"EnableParallaxMapping" "0" "1" !!!
"SupportsEventQuery" "1" "1"
"Windowed" "0" "0"
"RenderToTextureShadows" "1" "1"
"RealtimeWaterReflection" "0" "1" !!!
"WaterReflectEntities" "0" "0"
"ModelLOD" "0" "0"
"NoWaitForVSync" "1" "1"Offenbar dient diese Sektion dazu, bestimmte Grundparameter für D3D einzustellen.

Auffällig ist hier der Unterschied zwischen DX8.1 und DX9.0 (siehe '!!!') :
- ParallaxMapping ist unter DX9 aktiviert
- RealtimeWaterReflection ist unter DX9 aktiviert

Jo... mögen sich unsere Spezialisten dazu äussern...
;-)

Jetzt mal das Ganze für die V3 der Engine:

CS:S beta V4 "81" "90"
---------------------------------------------------------------------------
"DefaultRes" "1024" "1024"
"MaxDxLevel" "81" "90"
"DxLevel" "81" "90"
"CentroidHack" "0" "0"
"NoUserClipPlanes" "0" "0"
"ConVar.mat_antialias" "0" "0"
"ConVar.r_fastzreject" "1" "1"
"ConVar.mat_reducefillrate" "0" "0"
"ConVar.mat_forceaniso" "1" "1"
"ConVar.mat_picmip" "0" "0"
"ConVar.mat_slopescaledepthbias_decal" "-0.5" "-0.5"
"ConVar.mat_slopescaledepthbias_normal" "0" "0"
"ConVar.mat_depthbias_decal" "-262144" "-262144"
"ConVar.mat_depthbias_normal" "0" "0"
"ConVar.mat_trilinear" "1" "1"
"ConVar.mat_forcehardwaresync" "1" "1"
"ConVar.mat_specular" "1" "1"
"ConVar.mat_parallaxmap" "0" "0" !!!
"ConVar.r_shadowrendertotexture" "1" "1"
"ConVar.r_waterforceexpensive" "0" "1" !!!
"ConVar.r_waterforcereflectentities" "0" "0"
"ConVar.r_rootlod" "0" "0"
"ConVar.mat_vsync" "0" "0"
"ConVar.mat_bumpmap" "1" "1"
"ConVar.r_screenfademinsize" "0" "0"
"ConVar.r_screenfademaxsize" "0" "0"
"ConVar.mat_softwarelighting" "0" "0"
"ConVar.dsp_off" "0" "0"
"ConVar.dsp_slow_cpu" "0" "0"
"ConVar.r_shadows" "1" "1"
"ConVar.r_drawdetailprops" "1" "1"
"ConVar.r_drawmodeldecals" "1" "1"
"ConVar.r_drawflecks" "1" "1"
"ConVar.props_break_max_pieces" "-1" "-1"
"ConVar.r_decal_cullsize" "5" "5"Hmmm...
Auf den ersten Blick erst einmal MEHR!
;-)

Aber der Unterschied der beiden DX-Versionen ist hingegen klein:
- ConVar.mat_parallaxmap ist unter DX9 NICHT aktiviert
- r_waterforceexpensive ist unter DX9 aktiviert

Bumm!

Ich gehe mal davon aus, dass "teures Wasser" mit RWR gelichzusetzen ist und "mat_parallaxmap" dann mit PM... aber viel interessanter ist doch die Tatsache, dass man in der V4 nun vollständig auf "ParallaxMapping" verzichtet...

Könnte das nicht den 'Performance-Boost' erklären?
Demirug?
:confused:

Habe mir dann nochmal die weiteren Definitionen angeschaut und festgestellt, dass Valve offenbar doch sehr spezifisch vorgeht, was die unterschiedlichen Grafik-Karten-Generationen der unterschiedlichen IHV's angeht.

So findet sich in der V3 z.Bsp. das hier über ATI:

"ATI Radeon X800 Series" (?/Pro/XTPE)

"VendorID" "0x1002"
"MinDeviceID" "0x4a48"
"MaxDeviceID" "0x4a50"
"DefaultRes" "1024"
"CentroidHack" "1"
"DefaultMSAA" "6"
"DefaultAnisoLevel" "8"

"ATI Radeon 9800 Series"

"VendorID" "0x1002"
"DeviceID" "0x4e45/48/49/4A/68/69"
"DefaultRes" "1024"
"CentroidHack" "1"Wenn ich das hier richtig sehe, dann wird ein sog. 'CentroidHack' bei den ATI's aktiviert...
...könnte das ein Hinweis auf die pp-'Hints' für die vertex-Shader sein?
Wir werden sehen.

Auch interessant ist die Tatsache, dass für X800'er 6xAA und 8°AF per Defualt vorgegeben wird.

Hier jetzt mal das gleiche für die nVidias:

"NVIDIA GeForce 6800 Series" (nU/U/GT)
"VendorID" "0x10de"
"DeviceID" "0x40/41/45"
"DefaultRes" "1024"
"DefaultMSAA" "6"
"DefaultAnisoLevel" "4"
"UseZPrefill" "1"

"NVidia GeForce FX 59x0 Series"
"VendorID" "0x10de"
"MinDeviceID" "0x330"
"MaxDeviceID" "0x333"
"DefaultRes" "1024"
"DxLevel" "81"
"UseZPrefill" "1"
"NoUserClipPlanes" "1"Hmmm...
Kein "CentroidHack"... was ja noch nichts heißen will. Dafür aber "UseZPrefill" und "NoUserClipPlanes", was auch immer das heißen mag. Auch bei den 6800'ern werden 6xAA und 4°AF vorgegeben... moment... 6xAA ? Wie jetzt... und eben der geringere AF-Level.

Aber sehr interessant ist auf jeden Fall, dass hier offenbar das "Geheimnis" der DX8.1-Voreinstellung wiederzufinden ist. Da ja von den Treibern ein DX-Level von 9.0 gemeldet wird, überschreibt der Parameter "dxLevel" in dieser CFG offenbar den von den Treibern gemeldeten Wert und flugs sind die 5900'er nur noch DX8.1-Karten.

Gut zu wissen, gell?
Einfach die CFG ändern und schon macht die Engine das, was 'mann' will...
Hoffentlich.

-

Jetzt nochmal das Ganze für die V4 der Engine...

Erst mal ATI:

"ATI Radeon X800 Series" (?/pro/XTPE)

"VendorID" "0x1002"
"MinDeviceID" "0x4A48"
"MaxDeviceID" "0x4A50"
"m_nDriverVersion_Build" "6467"
"DefaultRes" "1024"
"CentroidHack" "1"
"ConVar.mat_antialias" "6"
"ConVar.mat_forceaniso" "8"

"ATI Radeon X800 Series" (SE/XT/Sonst.)

"min megahertz" "xxx"
"VendorID" "0x1002"
"MinDeviceID" "0x4A4A"
"MaxDeviceID" "0x4A4C"

"ATI Radeon 9800 Series"
"VendorID" "0x1002"
"DeviceID" "0x4145"
"m_nDriverVersion_Build" "6467"
"DefaultRes" "1024"
"CentroidHack" "1"Erst einmal fällt auf, dass mit der V4 der Engine auch eine Treiber-Limitierung einzug gehalten hat. So gehe ich denn mal davon aus, dass mit "m_nDriverVersion_Build" die kleinste, zugelassene Treiber-Version eingestellt wird. Und selbstverständlich ist auch "CentroidHack" wieder mit von der Partie... na ja, fast. Es sind neue X800'er dazu gekommen... offenbar werden diese 'Leichtgewichte' aber weder mit diesem "Hack" bedacht, noch mit Default-Einstellungen für AA/AF. Die 'großen' bekommen wie gewohnt 6xAA und 8°AF.

Jetzt mal wieder für nVidia's 6800'er:

"NVidia GeForce 6800 Series" (nU/U/GT)

"VendorID" "0x10DE"
"DeviceID" "0x0040/41/45"
"m_nDriverVersion_Build" "6177"
"DefaultRes" "1024"
"CentroidHack" "1"
"ConVar.mat_antialias" "6"
"ConVar.mat_forceaniso" "4"
"ConVar.r_fastzreject" "1"

"NVidia NV40/G" (???)

"min megahertz" "xxx"
"VendorID" "0x10DE"
"DeviceID" "0x0043/49"
"m_nDriverVersion_Build" "0"
"CentroidHack" "1"Device-ID 0x43 und 0x49?
Was ist das?

Egal...

Der "CentroidHack" hat nun auch bei nVidia einzug gehalten!
Damit wäre dann nun auch klar, wie die pp-'Hints' für die Vertex-Shader gesteuert werden...

Der Rest scheint 'normal'... so gibt's ein "r_fastzreject", was dem vorherigen Parameter entsprechen dürfte... 6xAA - was soll das eigentlich? - und eben 4°AF... zumindest für die 'Großen' und neu ist der 'kleinste' Treiber in der Version 61.77.

Nun nochmal für die 5900'er:

"NVidia GeForce FX 59x0 Series" (nU/U/XT/5950)

"VendorID" "0x10DE"
"MinDeviceID" "0x0330"
"MaxDeviceID" "0x0333"
"m_nDriverVersion_Build" "6177"
"DefaultRes" "1024"
"MaxDxLevel" "90"
"DxLevel" "81"
"NoUserClipPlanes" "1"
"ConVar.r_fastzreject" "1"

"NVidia GeForce FX 5900ZT" (???)

"min megahertz" "xxx"
"VendorID" "0x10DE"
"MinDeviceID" "0x0334"
"MaxDeviceID" "0x0334"
"m_nDriverVersion_Build" "0"FX5900ZT ?
Also irgendwie...

Wie auch immer... "UserClipPlanes" und "fastZ" sind wieder dabei, wie auch der DX-Level 8.1... aber diesmal gibt's auch einen Max-Level, der doch tatsächlich auf DX9.0 hinweist... muss mal schaun', ob man da jetzt was im Config-Menü einstellen kann.

-

War das jetzt interessant, oder wie?
:D

Vielleicht kann hier ja mal jemand was zu diesem "ParallaxMapping" sagen und ob das für den Performance-Sprung verantwortlich sein könnte... würde mich wirklich brennend interessieren. Und da es ja auch für alle anderen DX9-Karten deaktiviert wurde, müsste es eigentlich auch dort zum Tragen kommen.

Das mit dem AF, was Demirug äusserte, könnte übrigens auch hinkommen, denn das erste mal, als ich den VST in Augenschein genommen habe, dachte ich nur bei mir: "Mann ist das scheußlich!".

Na dann bin ich ja mal auf diesbezügliche Kommentare gespannt!
Und Sorry, für diesen Monster-Post...

Razor

P.S.: die 'code'-Teile sehen in den CFG's natürlich anders aus... so habe ich mich hier bemüht, die relevanten Dinge zusammen zu fassen und den Post nicht mit unnötigen Info's zu 'belasten'...
;-)