Doom3-Benches vom NV30 ... [Archiv]

Quasar

2004-08-08, 09:01:09

Überhitzung und Treiberprobleme habe ich bis auf eines, das ich aber erstmal auf einem zweiten Rechner gegenchecken will, noch nicht gesehen.
Auf meinem System (welches ziemlich CPU-limitiert zu sein scheint) gibt es in 1024 HQ 2xAA nahezu umsonst.

Auf viel mehr als 33fps komme ich allerdings auch in 640 LQ nicht - ohne Schatten immerhin knapp 40. ;)
(Das alles aufm 1,4GHz P3)

deekey777

2004-08-08, 12:21:54

Vielleicht hilft das: nggalai hat doch eine FX 5800...

MikBach

2004-08-08, 13:06:19

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=2102575&postcount=102

in diesem Thread stehen auch Ergebnisse zum NV35 respektive R3xx.

Edit: Das neue Forum zeigt ja nur den Post. :stareup:

Thread: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=159164

Quasar

2004-08-08, 18:49:37

Sodele - da hast du.
Treiber war komplett auf Default (ja, inkl. der bösen reduzierten trilinearen Filterung, AF hatte die Application im Griff) ;)

Und nicht vergessen - die CPU erfüllt nichtmal die Mindestanforderung von Doom3 ;)

MadManniMan

2004-08-08, 19:46:15

Aqualon: Ja diesen "Bench" kannte ich, doch wie gesagt taugt der nicht wirklich was ;) Danke dennoch!

Q: Hm, nice :up: für 30fps in meinen nativen 1280 + medium/high wird meine 475MHz-elnde 5800 ergo reichen!
Die Problem, die du angesprochen hast ... EarlyZ bei 500MHz und 140° ?

Und danke für den Link, Mik! Mal reinschaun...

Immernoch aber warte ich gespannt auf direkte Vergleichsbenches zwischen NV30 und 35 ;)

Quasar

2004-08-08, 20:39:15

Q: Hm, nice :up: für 30fps in meinen nativen 1280 + medium/high wird meine 475MHz-elnde 5800 ergo reichen!
Die Problem, die du angesprochen hast ... EarlyZ bei 500MHz und 140° ?

Nein, das nicht.
Aber jedesmal, wenn ich 2xAA (4x nicht probiert) in 800x600 angeschaltet habe im Game, gab's einen Fehler - 640 und 1024 gingen problemlos.

ironMonkey

2004-08-08, 20:51:19

Hat eigentlich schon jemand mit der agp aperature Size rumgespielt bei NV30/35 R300/350??????

Gruß

Quasar

2004-08-08, 23:07:39

Hier nochmal ein kleiner Nachschlag - nV35 (400/425), leider (oder zum Glück?) jedoch mit 256MB aber ansonsten gleichen Voraussetzungen wie oben.

Wie man sieht, verläuft die Kurve für Low, Medium und High ziemlich ähnlich der des nV30 - Ultra profitiert jedoch z.T. deutlich von den zusätzlichebn 128MB VRAM.

Die restlichen Verbesserungen (256Bit Interface, Ultra-Shadow ;) usw.) scheinen nicht zu genügen, um 20% mehr Füllrate auch nur annähernd zu kompensieren.

Wenn ich morgen Lust und Zeit haben, wiederhole ich das ganze Spielchen vielleicht auf einem schnelleren System.

Abraxaς

2004-08-09, 02:32:49

Bei mir läuft doom mit ner 5800 Ultra,xp 3200+&512mb bei 1024x768 und medium details absolut flüssig,leider wird die karte gerade bei den momentanen außentemperaturen sehr heiß,sodass sich das spiel ab und zu verabschiedet.

Mr. Lolman

2004-08-09, 12:52:03

lt. Hardocp dürfte die 9800pro ja ein ganze Stückchen besser sein als die 5800Ultra.

Quasar

2004-08-09, 18:43:10

lt. Hardocp dürfte die 9800pro ja ein ganze Stückchen besser sein als die 5800Ultra.

Nochmal für den Esel zum mitschreiben: Das machst du genau _woran_ fest?

An den beiden Bildern bei [H], wonach eine 5800u bei Medium-Q mit minFPS von 27 gleichgut spielbar ist, wie eine R9800p bei High-Q mit minFPS von 7? ;)

r@h

2004-08-09, 23:31:54

Hat eigentlich schon jemand mit der agp aperature Size rumgespielt bei NV30/35 R300/350??????Wozu?
(vor allem die vielen Fragezeichen ;-)

Ab 128MB GraKa-RAM mindestens 256MB Aperture-Size (bei mind. 512MB Hauptspeicher)...
..was gibt's da "rumzuspielen"?
:???:

Razor

P.S.: was selbstredend für nVidia gilt... bei ATI sollten es 32-64MB tun.

Ranz0rle

2004-08-10, 21:15:27

Als ich meine 5800U (€ 560/560) drinne hatte und mal angezockt habe, hatte ich meistens bei 1024*768 und Medium Details ~35-40fps wenn ich durch Glas nach draussen auf den Mars geguckt habe ging es teilweise schon stark zurück und auf dem kleinen Zwischenstück wo man draussen ist hat es auch geruckelt. Ansonsten absolut spielbar. CPU limitiert war es nicht (3,75GHz P4C). Aber die jetzige 68U hat sich gelohnt ;)

Mr. Lolman

2004-08-10, 22:22:02

Wozu?
Razor

P.S.: was selbstredend für nVidia gilt... bei ATI sollten es 32-64MB tun.

Neue Spiele laufen mit 256MB etwas besser, bild ich mir zumindest ein.

Radeonator

2004-08-11, 00:10:52

Besonders nice ist der Hinweis, das es mit der 5800er ein wenig heiss wird mit neuen Treibern ;)

Bis auf die 9800Pro laufen alle Karten sehr nice

Denke mal mit ATi Patch wirds gleichstand geben, well done ID!

Benedikt

2004-08-11, 01:43:07

q@w

2004-08-11, 08:20:02

UltraShadow scheint ja laut Carmack auf NV35 nicht aktiv zu sein? :confused:

OT: Und Quasar, macht deine 5800er eigentlich auch irgendwelche Zicken mit den 6x.xx-Forewares oder ist da alles in Ordnung, in punkto Lüfter und so?
Nichts anderes wollte ich damit in Bezug auf 'Ultra-Shadow' andeuten ;)

Meine FX schaltet jetzt ihren Fön offenbar Temperaturabhängig ein und nicht, wie vorher, per se, wenn irgendwas einen D3D- oder OpenGL Kontext erschafft. Am Anfang war ich zwar ziemlich erschrocken und hab flugs das Game beendet.
Als das dann nicht nur mit dem 6800er-Treiber 60.72 sondern auch noch mit späteren und sogar den offiziellen Treibern passiert, habe ich mal mit RivaTuner die Temp mitloggen lassen:
Offenbar scheinen die Heatpipes sehr gut zu funktionieren, denn auch wenn bei 3D-Aktivität ein plötzlicher Anstieg der Temps zu verzeichnen ist, steigen diese nach dem "Sprung" recht moderat und werden dann bei Bedarf vom Fön heruntergekühlt.

nggalai

2004-08-11, 09:06:15

Nein, das nicht.
Aber jedesmal, wenn ich 2xAA (4x nicht probiert) in 800x600 angeschaltet habe im Game, gab's einen Fehler - 640 und 1024 gingen problemlos.
FSAA ist bei mir gar nicht gelaufen auf 800x600, und bei 1024x768 arschlahm--insbesondere, wenn ich mal eins in die Fresse bekommen habe, stand das Spiel mal für 3s still. Die GPU wurde auch deutlich heisser, mit MSAA angeschaltet.

Ohne MSAA wurde der Chip selbst auf 480MHz nicht heisser als 89°C. In UT2003 hab' ich auf "default"-Takt grössere Hitze.

93,
-Sascha.rb

P.S. @all: Meine Benchmarks stehen im Benchmark-Subforum. -.rb

Corny

2004-08-11, 09:23:42

q@w

2004-08-11, 10:47:19

FSAA ist bei mir gar nicht gelaufen auf 800x600, und bei 1024x768 arschlahm--insbesondere, wenn ich mal eins in die Fresse bekommen habe, stand das Spiel mal für 3s still.
Ja, der Fehler, den ich in 800x600 bekam, war auch derart, daß Doom3 daraufhin ausstieg. Aber wie gesagt, mit der 5800u kann ich noch in 1024, HQ und 2xAA leidlich zocken (35fps im Timedemo auf einem etwas potenteren Rechner als oben).

Die GPU wurde auch deutlich heisser, mit MSAA angeschaltet. Ohne MSAA wurde der Chip selbst auf 480MHz nicht heisser als 89°C. In UT2003 hab' ich auf "default"-Takt grössere Hitze.
Die Wärmeentwicklung habe ich noch nicht protokolliert unter Doom3 - allerdings könnte man zu bedenken geben, daß du einen Self-Made Kühler und ich 'nen Fön drauf habe.
Deine "Stillstände" mit MSAA scheinen mir auf den ersten Blick von Überhitzung herzurühren - konntest du das ausschließen?

q@w

2004-08-11, 10:49:41

ich hätte benchmarks mit einem Celeron @ 1600Mhz, 512MB SD-RAM und einer Geforce FX5900 128MB anzubieten - falls die hier für jemanden interessant wären?
geht ja um NV30 und NV35, aber bisher sind ja nur NV30 benches da.

sagt mir kurz wie ihr gebencht habt und ich werd das heut abend auch mal machen!

Hab' doch oben schon eine FX5900 nachgelegt - aber trotzdem wären deine Werte interessant, da mein Exemplar dummerweise ja 256MB hatte und damit nur bedingt vergleichbar ist (nur bitte bitte deine FX mit standard-Taktung testen!).

Gebencht haben 'wir' hier überlicherweise mit timedemo demo1, den man in der Konsole (STRG+ATL+^) eingibt und dann den zweiten Durchlauf gewertet (ich meist den dritten, weil der wieder etwas absank und dann konstant blieb).

nggalai

2004-08-11, 10:53:24

Deine "Stillstände" mit MSAA scheinen mir auf den ersten Blick von Überhitzung herzurühren - konntest du das ausschließen?
Nicht komplett ausschliessen. Aber die Stillstände hatte ich auch, wenn ich den Chip auf 300MHz untertaktete, und nur bei den "AUA!" Effekten. Bei anderen Shader-intensiven Effekten wie Hitzewellen und Glas passierte nix.

93,
-Sascha.rb

Corny

2004-08-11, 15:13:37

Hab' doch oben schon eine FX5900 nachgelegt - aber trotzdem wären deine Werte interessant, da mein Exemplar dummerweise ja 256MB hatte und damit nur bedingt vergleichbar ist (nur bitte bitte deine FX mit standard-Taktung testen!).

Gebencht haben 'wir' hier überlicherweise mit timedemo demo1, den man in der Konsole (STRG+ATL+^) eingibt und dann den zweiten Durchlauf gewertet (ich meist den dritten, weil der wieder etwas absank und dann konstant blieb).

alles klar! sobald ich heut daheim bin werd ich mal benchen.

je nachdem wie ich zeit hab mach ich dann mehrere Auflösungen, Qualitätseinstellungen usw...
in ca 2Std werd ich die werte liefern können!

Corny

2004-08-11, 17:12:40

so, hier die versprochenen Benchmarks von mir:

Testsystem
Intel Tueleron @ 12*134Mhz -> 1620Mhz
512MB PC133 2-2-2-5-7
ASUS TUSL2-C Board (i815ep Chipsatz)
Leadtek Geforce FX5900 128MB Standardtakt

1024*768 | High Quality | 0x FSAA = 23,4 FPS
1024*768 | High Quality | 2x FSAA = 23,4 FPS
1024*768 | High Quality | 4x FSAA = 20,8 FPS

1024*768 | Low Quality | 0x FSAA = 26,6 FPS

640*480 | Low Quality | 0x FSAA = 34,8 FPS
640*480 | Low Quality | 4x FSAA = 34,1 FPS

jeweils zweiter durchlauf wurde gewertet weil da alle nachlade Ruckler weg waren

wie man sieht alles ganz klar CPU-Limitiert. 2x FSAA ist bei 1024 High komplett ohne Verlust, 4x FSAA bremst jedoch schon. auch Low Quality brachte bei 1024 ohne FSAA nicht viel besserung - die CPU ist einfach zu lahm.

in der 640er wird es zwar ein schönes stück schneller, aber die CPU bremst immer noch brutal. 4x FSAA ist immer noch nahezu gratis!

ich hoffe die benchmarks reichen -> falls nicht bitte schnell genug bescheid sagen dann kann ich noch welche machen! ich muss die Karte heute noch zurückgeben (ist nur ausgeliehen)

Quasar

2004-08-11, 19:31:00

Krass, wie extrem dein Tuleron dich einbremst - ich hätte eigentlich angesichts deines höheren Taktes auf ungefähren Gleichstand zwischen uns getippt.

nggalai

2004-08-11, 19:44:38

Krass, wie extrem dein Tuleron dich einbremst - ich hätte eigentlich angesichts deines höheren Taktes auf ungefähren Gleichstand zwischen uns getippt.
Die Timedemos sind, solange man nicht hohe Auflösungen und AF-Stufen übers CP wählt, ziemlich heftig CPU-limitiert. Resp. skalieren schön mit der CPU mit.

Hab's glaub schon mal erwähnt--Brandon von Firingsquad brauchte Tage, um ein einigermassen VGA-limitiertes Demo in DooM3 aufnehmen zu können. Und selbst das Ding skaliert auf 6800ern bei 1600x1200, 16°AF und 4xMSAA noch stärker mit der CPU mit als mit dem Takt der Grafikkarte.

93,
-Sascha.rb

Corny

2004-08-12, 08:22:03

Krass, wie extrem dein Tuleron dich einbremst - ich hätte eigentlich angesichts deines höheren Taktes auf ungefähren Gleichstand zwischen uns getippt.

naja, in der 640er low quality - da wo die grafikkarte die geringste rolle spielt - haben wir ja gleichstand. ich denke man kann sagen der Tueleron hat in doom3 bei 1,6Ghz den gleichen speed wie der P3-S bei 1,4Ghz.

ist schon ein heftiger unterschied! aber doom3 ist ja ganz schön cache hungrig (hier sinds ja 256kb vs 512kb! )

die grenze deiner CPU sind ja auch die 35fps bei der geringsten auflösung - egal welche graka du hattest.

ein test mit 100% identischer grafikkarte wäre interessant gewesen, aber ich hab ab heute nurnoch eine Radeon8500 - evtl bekomm ich die 5900 nochmal kurz

Quasar

2004-08-12, 08:39:33

Ja, hast recht - in der 640er sind wir ja quasi gleich - das hab' ich völlig übersehen :bonk:

Allerdings wundern mit dann doch deine 1024er Werte - maximal 'dürftest' du ja um die Füllrate langsamer sein, aber nicht um 50%. Hast du eventuell AF und/oder AA nicht im Treiber auf "Anwendungsgesteuert" gelassen, sondern einen bestimmten Wert voreingestellt?

edit:
'ne Radeon8500 habe ich auch - allerdings eine BBA mit 128MB. Keine Ahnung, ob wir da fair vergleichen können, Interesse besteht!

Corny

2004-08-12, 10:49:20

das mit dem starken ein bruch unter 1024 kann ich mir auch schwer erklären.

die einstellungen im treiber waren für AA und AF "anwendungsgesteuert"
und im gleichen fenster gibts auch noch einen qualitätseinstellungen - den regler habe ich ganz nach rechts geschoben.
ich weiß jetzt nicht wie das ding heisst, ich kenne die aktuellen Nvidia treiber kaum da ich normal keine nV karte besitze (GF 2MX war die letzte) und die FX schon zurück gegeben habe.

die Radeon 8500 benches wären schon interessant. ich habe eine hercules mit BBA-Bios, allerdings nur 64MB speicher. ists möglich den speicher zum vergleichen bei dir auf 64MB zu beschränken? ich weiß nicht ob es da ein tool gibt

Quasar

2004-08-12, 10:56:52

Dann hast du auf "High Quality" gebencht, das verbessert die Texturfilter nochmals*, kostet aber auch viel Leistung. Im HQ Modus verlor ich dadurch auf einem wesentlich potenteren System ca. 8fps. Auf dem P3 könnte das noch grob geschätzt etwa die Hälfte dessen ausmachen, also liegen deine und meine Ergebnisse doch noch durchaus in Relation zueinander.

Was die Radeon angeht: Mir ist nicht bekannt, wie ich die auf 64MB begrenzen könnte, sry.

*besser gesagt, stellt ihre künstlichen Verschlechterungen ab

Corny

2004-08-12, 11:05:01

achso, DIESE optimierungen schalte ich damit ein und aus!? soso.... und ich depp hab auf high gestellt.... dabei wäre die qualität anders kaum schlechter gewesen aber der speed wesentlich höher!

kannst du evtl mal mit gleichen einstellungen benchen? ich kanns mangels grafikkarte nicht (ausser die liegt wirklich noch daheim. sollte gestern abgeholt werden aber ich war seit gestern abend nicht zuhause!)

sth

2004-08-12, 11:07:18

com_VideoRAM 64

Ich habe gemerkt, das die Einstellung wohl mehr ins Gewicht fällt als als Low/Medium/High/Ultra bzw. die Einstellungen je nach VideoRAM wohl andere Ergebnisse liefern.

Quasar

2004-08-12, 11:25:57

Ach ja richtig, da war noch was.

Anläßlich des kürzlich erschienenen SPEC ViewPerf8.01 habe ich meine FX mal wieder zur Quadro umfunktioniert und direkt mal Doom3 mit den uralt-Treiber der Workstation-Karte laufen gelassen.

P4-3,0c, 1024MB RAM, WinXP SP1, Det44.90 SQ-Mod, Doom3 1024 MQ

ARB2-Pfad: 12,4fps (sehr gute Bildqualität)
ARB--Pfad: 40,4fps (schlechte BQ, normals und/oder Bumps fehlen )
nV10-Pfad: 27,4fps (Bumps und Normals sind da, aber die Beleuchtung ist kaputt)
nV20-Pfad: 32,4fps (keine Normals, stark kaputte Beleuchtung)

So, jetzt dürft ihr spekulieren. X-D

Corny

2004-08-12, 11:33:09

was willst du uns damit sagen??

das die Geforce karten im gegensatz zu den quaddro karten nur von den optimierungen leben?

r@w

2004-08-12, 14:46:24

Habe ich jetzt auch nicht verstanden...

JC erwähnte doch, dass die 'alten' Treiber noch erhebliche Probleme mit dem ARB2-Pfad hatten und er deswegen einen extra NV30-Pfad integrierte, den er aber - nachdem die Performance mit ARB2 akzeptabel war - wieder geknickt hat.

Auch dürften Quadro-Treiber nicht wirklich zum Spielen geeignet sein, was dann noch erschwerend hinzu gekommen sein dürfte.

Sach' doch mal, Quasar, was wolltest Du uns damit sagen?
:confused:

Razor

r@w

2004-08-12, 14:49:05

Und noch eines...

Auch die Quali stimmt, habe ich doch die Möglichkeit, diese mit einer R9800p zu vergleichen und konnte dort bis dato keinerlei Defizite ausmachen. Wenn nVidia hier also 'optimiert' hat, dann so, dass man es zumindest auf den ersten (auch nicht auf den zweiten ;-) Blick erkennt.

Razor

Mmmmmh

2004-08-12, 17:19:09

Quasar

2004-09-11, 19:52:48

Nochmal ein kleiner Nachtrag:

FX5800u, FW66.13, "Treiber-Default" Optimierungen, P3-S 1,4GHz, 512MB PC133-SDR-SDRAM.

Doom3 in 1280x1024, HQ:

ohne AF (via Konsole): 30,7fps
mit AF (via Konsole): 28,0fps

Mit minimal veränderter interaction.vfp:
ohne AF: 14,4 fps
mit AF: 13,2 fps

strange, very strange indeed... :|

Benedikt

2004-09-12, 00:32:30

Coda

2004-09-12, 05:02:14

Tja der Effekt ist mir auch schon auf der 6800 aufgefallen, nur ist er da weitaus schwächer...
Solang die Bildqualität nicht in Mitleidenschaft gezogen wird, kann uns das aber eigentlich auch egal sein.
Ich denke nicht dass nVidia noch viel am NV3x Shader Compiler drehen wird, und deshalb ist es wohl die beste Lösung.

Coda

2004-09-12, 05:10:00

- bitte löschen -

Coda

2004-09-12, 05:13:20

- bitte löschen -

r@h

2004-09-12, 07:12:58

Mit minimal veränderter interaction.vfp:
strange, very strange indeed... :|Und was wurde da genau "minimal" verändert?
:confused:

Razor

Coda

2004-09-12, 17:10:52

Z.B. kannst du auf NV40 das DP3/RSQ/MUL mit NRM ersetzen, was normal schneller sein _sollte_, aber der Shader wird trotzdem langsamer.

Quasar

2004-09-12, 17:58:54

Und was wurde da genau "minimal" verändert?
:confused:

Razor

Beim Modulieren mit dem konstanten Specular Factor habe ich an Register R1 nur ein ".x" angehängt, was eigentlich keine großen Veränderungen für die Berechnung auslösen dürfte, wie mir gesagt wurde.

edit:
Auf der nV40 passiert ähnliches, wie ich in irgendeinem der vielen anderen Doom3-Threads auch schon schrieb. Allerdings geht da die Leistung nur etwa um 10% zurück.

robbitop

2004-09-12, 18:39:48

naja solang sich die Optimierung nicht auf die BQ auswirkt und im ganzen Spiel nutzbar ist, sollte das nicht als negativ angesehen werden. FPS kann man wunderbar in BQ stecken.

Vieleicht sollte man erstmal auf eine Statement von id/NV warten.
Ich weiss noch wie man damals NV bzgl FarCry des Cheatings bezichtigte (fartcry.exe) dabei war es nötig für das Fixen eines Bugs.

Z.B. kannst du auf NV40 das DP3/RSQ/MUL mit NRM ersetzen, was normal schneller sein _sollte_, aber der Shader wird trotzdem langsamer.

bringt nur bei FP16 ziemlich viel, und ist natürlich nicht immer einsetzbar (sollte mathematisch klar sein).

Quasar

2004-09-12, 19:18:29

"Der" Shader in Doom3 enthält die Erlaubnis, auf PP zu gehen.

edit:
Unter D3D kann der Treiber das allerdings selbst erkennen, ob er DP3/RSQ/MUL vor sich hat und daraus eine NRM_PP machen kann - vermutlich kann er das in OpenGL auch.

r@h

2004-09-12, 19:39:40

Beim Modulieren mit dem konstanten Specular Factor habe ich an Register R1 nur ein ".x" angehängt, was eigentlich keine großen Veränderungen für die Berechnung auslösen dürfte, wie mir gesagt wurde.Gibt's dazu auch was Genaueres?
Was genau bewirkt das "Anhängen eines '.x' an ein Register"?
Irgend einen Sinn wird das je wohl schon haben, oder?

edit:
Auf der nV40 passiert ähnliches, wie ich in irgendeinem der vielen anderen Doom3-Threads auch schon schrieb. Allerdings geht da die Leistung nur etwa um 10% zurück.Würde das gerne mal mit 'ner FX5900 sehen...
Gibt's dazu auch Werte?

Razor

Quasar

2004-09-12, 19:49:38

Gibt's dazu auch was Genaueres?
Was genau bewirkt das "Anhängen eines '.x' an ein Register"?
Irgend einen Sinn wird das je wohl schon haben, oder?

Würde das gerne mal mit 'ner FX5900 sehen...
Gibt's dazu auch Werte?

Razor

In diesem Falle hat es lediglich den Sinn, den Shader minimal zu verändern. Im Allgemeinen kann man damit "ansagen", daß man lediglich mit einer Komponente des Registers weiterrechnen will - Ich meine irgendwo etwas von einem "Skalarselect" gehört zu haben.

Eine 5900 und Doom3 hast du doch auch, oder?

r@h

2004-09-12, 19:55:47

In diesem Falle hat es lediglich den Sinn, den Shader minimal zu verändern. Im Allgemeinen kann man damit "ansagen", daß man lediglich mit einer Komponente des Registers weiterrechnen will - Ich meine irgendwo etwas von einem "Skalarselect" gehört zu haben.Hmmm...
Macht das auch nicht gerade für mich verständlicher, sorry.
(bin halt ein noob ;-)

Da das ja ein Modifyer für ein Register ist, habe ich so bei mir gedacht, dass es ja durchaus die Temp-Register-Optimierung des Shader-Compilers durcheinander bringen könnte und deswegen die geringe Performance heraus kommt (was auch auf den Unterschied zwischen NV30 und NV40 hinweisen würde). Ist aber nur eine Annahme...

Eine 5900 und Doom3 hast du doch auch, oder?Jo, klar.
Nur die modifizierte interaction.vfp fehlt mir...

Razor

Coda

2004-09-12, 20:02:29

Das komische ist nur das jede Änderung, egal in welcher Form, die Performance immer um etwa den gleichen Grad verschlechtert, zumindest ist das bei mir auf der NV40 so.

Auch "Optimierungen" die man laut nVidia anwenden soll bewirken das Gegenteil. Zur Erklärung: Man kann in ARB Shadern per Option NV40 Extensions aktivieren, die normal nicht verfügbar sind.

Demirug

2004-09-12, 20:03:05

Razor,

vom offiziellen 61.77 Shadercompiler sind beide Shadervarianten als gleich schnell eingestuft. Und das bei allen 3 CineFX Varianten.

r@h

2004-09-12, 20:12:32

Die Passage mit Remark aus der VTP als Hinweis würde mir schon reichen...
(also noob würde ich nur ungern 'irgendetwas' ändern)
;)

Razor

Quasar

2004-09-12, 20:14:13

Jo, klar.
Nur die modifizierte interaction.vfp fehlt mir...

Razor

Du nimmst einfach die originale und hängst fast ganz unten beim

# modulate by the constant specular factor
an das zweite "R1" ein ".x" an.

MUL R1, R1.x, program.env[1];

Das ganze ist auf einem nV40 noch langsamer, als der von Humus getweakte Shader - irgendwas muss der also noch zusätzlich vereinfachen ;)

r@h

2004-09-12, 20:14:20

vom offiziellen 61.77 Shadercompiler sind beide Shadervarianten als gleich schnell eingestuft. Und das bei allen 3 CineFX Varianten.Mag ja sein...

Kannst Du mir nicht mal erzählen, was ich da verändern muss, um das nachvollziehen zu können?
Wäre Dir sehr verbunden... OK, bin ich sowieso.
;)

Razor

Jesus

2004-09-12, 20:20:15

Hmm, das könnte doch - ääh naja - also eigentlich - hmm ja was könnte das wohl sein? :whistle:
:sneak:

MFG,
B. W.

sprichs aus ! ;) Shaderreplacement

Ist doch egal, solange die BQ darunter nicht leidet ! ( den Spruch kenn ich irgendwoher, war das nicht genau das was alle Welt verflucht hat als ATI´s AF Optimierungen noch "neu" waren ? ;D )

Allerdings jetzt von genau den selben Leuten jenen Satz zu hören find ich schon etwas komisch, zumal Argumente wie "ich seh keinen Unterschied" in der Vergangenheit auch sofort zu einer gnadenlosen Hexenjagd mit anschliessender Kreuzigung geführt haben...

Aber naja, ich freu mich schon über den "Warum liegt die X800 in Doom 3 zurück (Part 2)" Artikel ;)

aths

2004-09-12, 20:21:57

Aber naja, ich freu mich schon über den "Warum liegt die X800 in Doom 3 zurück (Part 2)" Artikel ;)Ich frage mich, was Leo so lange braucht – schon vor zwei Tagen schickte ich ihm was.

r@h

2004-09-12, 20:24:55

Du nimmst einfach die originale und hängst fast ganz unten beim# modulate by the constant specular factoran das zweite "R1" ein ".x" an.
MUL R1, R1.x, program.env[1];Das ganze ist auf einem nV40 noch langsamer, als der von Humus getweakte Shader - irgendwas muss der also noch zusätzlich vereinfachen ;)Boahhh...
Heftigste Slowdowns und ein ganz erheblicher Performance-Rückgang!

Getestet mit FX5900(BiosModded), XP2700+, 1GigRAM, 2xCPAA, 4°AppAF
- ohne Änderung: 41,0fps
- mit Änderung: 28,2fps

Das sind "mal eben" satte 30% Performance-Verlust!
Oder man könnte auch mutmaßen dass nVidia durchs Shader-Replacemnt noch viel sattere 45% gewinnt...

Dassa ein Hammer.
Werd' mir das mal näher anschaun'...

Thx4Unterstützung@Quasar&Demirug!
:up:

Razor

Quasar

2004-09-12, 20:33:19

sprichs aus ! ;) Shaderreplacement

Bist du dir da ganz sicher? ;)

Coda

2004-09-12, 20:35:20

Aber naja, ich freu mich schon über den "Warum liegt die X800 in Doom 3 zurück (Part 2)" Artikel
Nunja. Bei NV40 ist die Erscheinung bei weitem nicht so krass, außerdem ist der Shadercompiler für NV40 auch noch recht neu. Kann sehr gut sein, dass das in neuren Treiberversionen auch ohne Replacement genausogut geht.

Ich nehme an das bei NV30 der Shader vor allem durch FX12 Berechnungen ersetzt wird, bei der NV40 ist FP16 aber auch schnell.

aths

2004-09-12, 20:37:27

Ich nehme an das bei NV30 der Shader vor allem durch FX12 Berechnungen ersetzt wird, bei der NV40 ist FP16 aber auch schnell.NV40 rechnet ohnehin mindestens in FP16.

Coda

2004-09-12, 20:39:20

Genau das meinte ich auch damit.

Desweiteren möchte ich anmerken, dass man wohl mit einem NV_fragment_program, wo man FX12 benützen kann auf NV30 ähnliche Leistungen erhalten würde als mit dem Shaderreplacement.

Aber Carmack mag es wenn er nur ein Ding schreiben muss und deshalb haben sie sich wohl darauf geeinigt ;)

Benedikt

2004-09-13, 00:23:47

Ist doch egal, solange die BQ darunter nicht leidet ! ( den Spruch kenn ich irgendwoher, war das nicht genau das was alle Welt verflucht hat als ATI´s AF Optimierungen noch "neu" waren ? ;D )

Allerdings jetzt von genau den selben Leuten jenen Satz zu hören find ich schon etwas komisch, zumal Argumente wie "ich seh keinen Unterschied" in der Vergangenheit auch sofort zu einer gnadenlosen Hexenjagd mit anschliessender Kreuzigung geführt haben...

Aber naja, ich freu mich schon über den "Warum liegt die X800 in Doom 3 zurück (Part 2)" Artikel ;)
Was willst du uns damit sagen? :confused:

MFG,
B. W.

r@h

2004-09-13, 08:39:10

Was willst du uns damit sagen? :confused:Dass er hofft, nVidia doch wieder ans Bein pinkeln zu können, nachdem sein 'geliebtes' ATI ja so dermaßen von nVidia 'versägt' wurde (Doom3).

Also irgendwie finde ich das jetzt doch mehr als merkwürdig.

Zuerst fand er es nur gut und recht, dass Humus per Shader-Replacement den ATI's ein bissel Performance verschaffte. Nun vermutet er selbiges bei nVidia und hofft auf einen Flamewar (und versucht ihn entsprechend zu provozieren).

Schon interessant, diesses doppelzüngige Verhalten.

Persönlich muss ich sagen: Gleiches Recht für Alle!
Sollen sie doch optimieren, was das Zeug hält...
...aber bitte nicht zulasten der BQ, wie bei Humus geschehen.

Razor

Tjell

2004-09-13, 09:06:46

...
Persönlich muss ich sagen: Gleiches Recht für Alle!
Sollen sie doch optimieren, was das Zeug hält...
...aber bitte nicht zulasten der BQ, wie bei Humus geschehen.

Razor
Genau das, was ich woanders auch schon schrieb.

Es sollte für beide gelten: "Optimierungen sind okay". Oder eben nicht.

Wobei ich gegen jede "Optimierung" bin, die a) unangekündigt ist, b) nicht abzuschalten geht und c) die Bildqualität verringert.

Abseits des Themas:
Übrigens wurden Hexen gejagt und dann entweder auf dem Scheiterhaufen verbrannt oder beim "Hexentest" ersäuft.
Gekreuzigt dagegen wurde u. a. Jesus...

MikBach

2004-09-13, 09:07:38

Dass er hofft, nVidia doch wieder ans Bein pinkeln zu können, nachdem sein 'geliebtes' ATI ja so dermaßen von nVidia 'versägt' wurde (Doom3).
Keiner will hier jemanden ans Bein pinkeln.
BTW lass die dummen Sprüche. Ist nicht gerade förderlich für eine "saubere" Diskussion. ;)

Persönlich muss ich sagen: Gleiches Recht für Alle!
Sollen sie doch optimieren, was das Zeug hält...
Richtig. Ich würde es aber als wünschenswert ansehen, wenn man im Trieber ein Feld/Häkchen für Shaderreplacement einbauen würde. Dann könnte man sehen welcher IHV mehr Shaderreplacement betreibt und man könnte einfach die BQ gegenchecken. ;)

...aber bitte nicht zulasten der BQ, wie bei Humus geschehen.

Razor
Lol.
Auch schon das statement von JC gelesen?
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=2113634&postcount=86
Wenn JC schreibt "Got 21% boost in the timedemo with this. *Smile* Now I still don't know exactly what exponent he's approximating, or if he's using different lookup tables for different materials, but I've tried this and it seems to look the same", dann wird das schon stimmen. Glaub mir.

r@h

2004-09-13, 09:25:14

Erst einmal: Halt einfach den Rand!
:D

Zum zweiten: "it seems" ist nicht das gleiche "it is".
Denk einfach mal darüber nach!

Razor

MikBach

2004-09-13, 09:36:35

Erst einmal: Halt einfach den Rand!
:D
Das gilt für dich ebenso. :uattack4:

Zum zweiten: "it seems" ist nicht das gleiche "it is".
Denk einfach mal darüber nach!

Razor
Ich brauche da nicht drüber nachzudenken. Wenn JC persönlich da nichts sieht, wird es einem beim SPIELEN auch nicht auffallen, falls es da irgendwelche Unterschiede geben sollte. Was nicht der Fall ist.
:D

r@h

2004-09-13, 09:44:51

Ein 'kleiner' Nachtrag...

Boahhh...
Heftigste Slowdowns und ein ganz erheblicher Performance-Rückgang!

Getestet mit FX5900(BiosModded), XP2700+, 1GigRAM, 2xCPAA, 4°AppAF
- ohne Änderung: 41,0fps
- mit Änderung: 28,2fps

Das sind "mal eben" satte 30% Performance-Verlust!
Oder man könnte auch mutmaßen dass nVidia durchs Shader-Replacemnt noch viel sattere 45% gewinnt...Hab' mir jetzt mal die interaction.vtp von Humus (Quasars Link (http://home.arcor.de/quasat/doom3PerformanceTweak.rar) aus dem anderen Thread von Manni) gekrallt und sie mal mit den gleichen Einstellungen gebencht:

- ohne Änderung: 41,0fps
- mit Humus-Änderungen: 34,8fps - 15,1%
- mit Quasar-Änderung: 28,2fps - 31,2%Oder wenn man davon ausgeht, dass Quasars Änderung aber auch rein gar nichts bewirkt, sondern nun verhindert, dass treiberseitige Optimierungen zum Tragen kommen (was für mich noch lange nicht klar ist), dann würde sich das so verhalten:

- mit Quasar-Änderung: 28,2fps (no Opt)
- mit Humus-Änderungen: 34,8fps + 23,4% (ATI Opt)
- ohne Änderung: 41,0fps + 45,4% (nVidia Opt)Interessant, nicht wahr?

Nach Aussage von JC höchstpersönlich (wenn Mikbach nicht geflunkert hat ;-), hat der Humus-Patch bei ATI 'nur' 21% gebracht, bei mir hingegen zur unoptimierten Variante locker 23,4%. Und das bei einem zu 100% auf ATI optimierten Shader.

Bumm.

Wie ist denn das jetzt bitte zu erklären?
(zumal die Unterschiede der beiden Shader auch recht interessant sind ;-)

-

Wenn ich also das Ganze nun richtig deute, dann hat JC nun also auf überhaupt keine Karte oder GPU hin 'optimiert', sondern ganz im Gegenteil sogar beide Kontrahenten (also ATI uns nVidia) locker um 20% schlechter aussehen lassen, als es möglich wäre.

Sagt mal Leute, irgendetwas 'stinkt' hier doch ganz gewaltig, oder? Und den kursiv geschriebenen Absatz lasse ich jetzt einfach mal so - ohne Kommentar - stehen...

Razor

P.S.: und wenn mir diese Anmerung erlaubst ist... nVidia kann besser 'optimieren'!
:D

Demirug

2004-09-13, 09:51:46

Oder wenn man davon ausgeht, dass Quasars Änderung aber auch rein gar nichts bewirkt, sondern nun verhindert, dass treiberseitige Optimierungen zum Tragen kommen (was für mich noch lange nicht klar ist), dann würde sich das so verhalten:

Die Shadervariante die Quasar benutzt hat ist funktional identisch mit dem Originalshader. Hatte das schon im Vorfeld für ihn geprüft.

EDIT: Die letzte Humus Variante ersetzt die mathematische Vektornormaliesierung für den Halbvektor durch einen Textureread und das macht schon was aus.

r@h

2004-09-13, 09:54:11

Die Shadervariante die Quasar benutzt hat ist funktional identisch mit dem Originalshader. Hatte das schon im Vorfeld für ihn geprüft.Was das Ganze doch nur umso interessanter macht, gell?
:D

Razor

MikBach

2004-09-13, 09:57:36

@ Razor
Ich glaube du hast da was missverstanden.
1. Der Humustweak ist für ATI-Karten gedacht, deswegen kann es sein, dass man mit einer Nvidia Performance verliert. Steht aber auch schon im Post von nggalai, den ich gepostet habe. Man muss ihn nur lesen und verstehen, was bei dir anscheinend nicht richtig fuktioniert. ;)
2. Es gibt keine fixen "mehr%". Das ist von Karte zu Karte und je nach Einstellungen unterschiedlich. Das sollte dir klar sein, oder?
3. Mit dem "Optimieren" könntest du Recht haben. Ich vermute auch, dass Nvidia im grösseren Umfang Shaderreplacement betreibt als ATI.

Demirug

2004-09-13, 09:59:18

Was das Ganze doch nur umso interessanter macht, gell?
:D

Razor

Warum? Das der nVidia Treiber auf die D3 Shader abgestimmt ist hat JC doch schon im Vorfeld gesagt. Interesant ist lediglich das nVidia keine einfache Checksumme über den Shadercode bildet sondern etwas anderes weniger anfälliges tut.

r@h

2004-09-13, 10:04:17

Der Humustweak ist für ATI-Karten gedacht, deswegen kann es sein, dass man mit einer Nvidia Performance verliert.Falsch.
Die nVidia's verlieren keine Performance, sondern sie gewinnen welche.
Und das in höherem Maße, als es die ATI's tun.

Verlieren tun die nVidia's nur dadurch, dass treiberseitige Optimierungen deaktiviert werden.

Mit dem "Optimieren" könntest du Recht haben. Ich vermute auch, dass Nvidia im grösseren Umfang Shaderreplacement betreibt als ATI.Was Du jetzt genau woraus ableitest?
:confused:

Razor

r@h

2004-09-13, 10:07:06

Warum? Das der nVidia Treiber auf die D3 Shader abgestimmt ist hat JC doch schon im Vorfeld gesagt. Interesant ist lediglich das nVidia keine einfache Checksumme über den Shadercode bildet sondern etwas anderes weniger anfälliges tut.Wus?

Die 'Erkennung' des Shaders scheint doch wohl mehr als simpel, wenn diese durch eine einfache (den Mechanismus nicht beeinflussende) Änderung schon ausgehebelt wird.

Oder habe ich jetzt irgend etwas nicht mitbekommen?

Razor

MikBach

2004-09-13, 10:11:52

Falsch.
Die nVidia's verlieren keine Performance, sondern sie gewinnen welche.
Und das in höherem Maße, als es die ATI's tun.

Verlieren tun die nVidia's nur dadurch, dass treiberseitige Optimierungen deaktiviert werden.

Razor
Und? Was willst du mir jetzt damit sagen?
Was hinten rauskommt, das zählt. Wie ist egal. Mit Humustweak verlieren die Nvidias an performance.

r@h

2004-09-13, 10:13:19

Und? Was willst du mir jetzt damit sagen?
Was hinten rauskommt, das zählt. Wie ist egal. Mit Humustweak verlieren die Nvidias an performance.Du hast es noch immer nicht verstanden, oder?
:confused:

Les einfach nochmal meinen vorherigen Post an Dich und versuche ihn zu verstehen.

Razor

Demirug

2004-09-13, 10:18:56

Wus?

Die 'Erkennung' des Shaders scheint doch wohl mehr als simpel, wenn diese durch eine einfache (den Mechanismus nicht beeinflussende) Änderung schon ausgehebelt wird.

Oder habe ich jetzt irgend etwas nicht mitbekommen?

Razor

Simpel wäre eine Checksumme über den Shadercode. Um das auszuhebeln müsste man allerdings nur den Namen einer Variablen ändern. Darauf reagiert der Treiber aber nicht.

Die Änderung von Quasar ergibt schon einen anderen Shader welcher aber aufgrund der externen Umständen im Kontext von D3 das gleiche Ergebniss produziert. Performancetechnisch ist die Änderung aber irrelevant was sich mit den entsprechenden Tools von nVidia auch nachprüfen lässt.

Die Erkennung der Shader muss also auf der Basis der mathematischen Funktion des Shaders ablaufen. Das ist schon eine Nummer komplizierter und schwer nachzuweisen. In den meisten Fälle wird man nämlich nicht so einfach einen alternativ Shader mit einer anderen mathematischen Funktion finden der performancetechnisch und vom Ergebniss her mit den original identisch ist.

MikBach

2004-09-13, 10:25:25

Du hast es noch immer nicht verstanden, oder?
:confused:

Les einfach nochmal meinen vorherigen Post an Dich und versuche ihn zu verstehen.

Razor
Was soll ich nicht verstanden haben? Klar habe ich das verstanden. Mit Humustweak sinkt effektiv/real die Leistung bei Nvidia. Was soll den daran nicht zu verstehen sein?

Les einfach nochmal meinen vorherigen Post an dich und versuche ihn zu verstehen.

r@h

2004-09-13, 10:28:23

Simpel wäre eine Checksumme über den Shadercode. Um das auszuhebeln müsste man allerdings nur den Namen einer Variablen ändern. Darauf reagiert der Treiber aber nicht.Hmmm...

Wenn ich recht entsinne, dann ist der Shader-Compiler doch in OGL2 integriert, insofern Bezeichnungen im Shader-Source völlig irrelevant sind, da diese im übergebenen Compilat nicht mehr existieren.

Das der Treiber auf solche Änderungen nicht reagiert, ist also mehr als verständlich.

Die Änderung von Quasar ergibt schon einen anderen Shader welcher aber aufgrund der externen Umständen im Kontext von D3 das gleiche Ergebniss produziert. Performancetechnisch ist die Änderung aber irrelevant was sich mit den entsprechenden Tools von nVidia auch nachprüfen lässt.Klar, der Shader ist jetzt ein anderer und kann nicht mehr 'erkannt' werden, wenn die Erkennung mithilfe eine Checksumme über das Compilat relaisiert ist.

Die Erkennung der Shader muss also auf der Basis der mathematischen Funktion des Shaders ablaufen. Das ist schon eine Nummer komplizierter und schwer nachzuweisen. In den meisten Fälle wird man nämlich nicht so einfach einen alternativ Shader mit einer anderen mathematischen Funktion finden der performancetechnisch und vom Ergebniss her mit den original identisch ist.Und genau des sehe ich eben noch nicht so deutlich...
Vielleicht bin ich da aber auch auf einem Holzweg.
(siehe obige Annahmen)

Razor

r@h

2004-09-13, 10:37:26

Was soll ich nicht verstanden haben? Klar habe ich das verstanden. Mit Humustweak sinkt effektiv/real die Leistung bei Nvidia. Was soll den daran nicht zu verstehen sein?Dann noch mal gaaaaaanz langsam für Dich:

1) mit einer Veränderung des Shaders (uns sei sie auch irrelevant für das Ergebnis oder gar den mathematischen Weg) sinkt die Performance bei nVidia-Karten teils dramatisch. So scheint es, dass Quasar offenbar belegt hat, dass hier Treiber-Optimierungen (wie auch immer diese geartet sind) im Spiel sind, die durch irgendeine Änderung des Shaders erst einmal deaktiviert werden.

2) Der Humus-'Hack' verändert den Shader, nVidia-Karten verlieren hier also per se erst einmal ALLE diesbezüglichen Treiber-Optimierungen. Das hat mit der Art der Veränderung erst einmal überhaupt nichts zu tun, denn lediglich die Erkennung des Shaders wird ausgehebelt.

3) Gegenüber der Ausführungsgeschwindigkeit des Shaders ohne treiberseitige Optimierungen, gewinnen die nVidia-Karten durch den Humus-Tweak wieder heftigst an Perfomance... bei mir über 23%. Die ATI's hingegen gewinnen ebenso, wenn auch nicht ganz so viel...

Ich weiß nicht, wie ich es noch anders ausdrücken soll, hege aber doch die Hoffnung, dass Du es nun verstanden hast.

Razor

MikBach

2004-09-13, 10:43:18

Dann noch mal gaaaaaanz langsam für Dich:

1) mit einer Veränderung des Shaders (uns sei sie auch irrelevant für das Ergebnis oder gar den mathematischen Weg) sinkt die Performance bei nVidia-Karten teils dramatisch. So scheint es, dass Quasar offenbar belegt hat, dass hier Treiber-Optimierungen (wie auch immer diese geartet sind) im Spiel sind, die durch irgendeine Änderung des Shaders erst einmal deaktiviert werden.

2) Der Humus-'Hack' verändert den Shader, nVidia-Karten verlieren hier also per se erst einmal ALLE diesbezüglichen Treiber-Optimierungen. Das hat mit der Art der Veränderung erst einmal überhaupt nichts zu tun, denn lediglich die Erkennung des Shaders wird ausgehebelt.

3) Gegenüber der Ausführungsgeschwindigkeit des Shaders ohne treiberseitige Optimierungen, gewinnen die nVidia-Karten durch den Humus-Tweak wieder heftigst an Perfomance... bei mir über 23%. Die ATI's hingegen gewinnen ebenso, wenn auch nicht ganz so viel...

Ich weiß nicht, wie ich es noch anders ausdrücken soll, hege aber doch die Hoffnung, dass Du es nun verstanden hast.

Razor
:D
Das hättest du dir sparen können(bei mir). Ich habe doch geschrieben, dass ich es mit den Optimierungen im Treiber verstanden habe.
Aber umsonst hast du es bestimmt nicht gemacht, denn einige, die diesen Thread lesen, werden es wahrscheinlich nicht auf anhieb verstehen. ;)

Demirug

2004-09-13, 10:51:34

Hmmm...

Wenn ich recht entsinne, dann ist der Shader-Compiler doch in OGL2 integriert, insofern Bezeichnungen im Shader-Source völlig irrelevant sind, da diese im übergebenen Compilat nicht mehr existieren.

Das der Treiber auf solche Änderungen nicht reagiert, ist also mehr als verständlich.

ARB2 Shader liegen in einer Art Assemblercode ähnlich wie DX-Shader vor. Bei DX Shader reichte das tauschen von Registern in der Regel schon aus.

Klar, der Shader ist jetzt ein anderer und kann nicht mehr 'erkannt' werden, wenn die Erkennung mithilfe eine Checksumme über das Compilat relaisiert ist.

Und genau des sehe ich eben noch nicht so deutlich...
Vielleicht bin ich da aber auch auf einem Holzweg.
(siehe obige Annahmen)

Razor

Im Prinzip wollte ich ja auch nur andeuten das die Erkennung viel tiefer im Treiber liegt als bisher und deswegen nicht mehr so einfach wie vorher ausgehebelt werden kann.

r@h

2004-09-13, 11:13:03

ARB2 Shader liegen in einer Art Assemblercode ähnlich wie DX-Shader vor. Bei DX Shader reichte das tauschen von Registern in der Regel schon aus.

Im Prinzip wollte ich ja auch nur andeuten das die Erkennung viel tiefer im Treiber liegt als bisher und deswegen nicht mehr so einfach wie vorher ausgehebelt werden kann.Also ist dieses Schaubild hier falsch?
(nebst den gegebenen Informationen)

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

Das würde doch dem wiedersprechen, was Du gerade gesagt hast, oder?
(insbesonders die letzten beiden Punkte, die den Unterschied zu DX heraus kehren)

Hmmm...

Razor

Demirug

2004-09-13, 11:46:46

Also ist dieses Schaubild hier falsch?
(nebst den gegebenen Informationen)

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

Das würde doch dem wiedersprechen, was Du gerade gesagt hast, oder?
(insbesonders die letzten beiden Punkte, die den Unterschied zu DX heraus kehren)

Hmmm...

Razor

Das Schaubild stimmt. Nur benutzt Doom III gar kein oglsl.

r@h

2004-09-13, 11:59:14

Das Schaubild stimmt. Nur benutzt Doom III gar kein oglsl.Ups.
Thx4investigation!
;)

Razor

Benedikt

2004-09-14, 00:53:48

Die Erkennung der Shader muss also auf der Basis der mathematischen Funktion des Shaders ablaufen. Das ist schon eine Nummer komplizierter und schwer nachzuweisen. In den meisten Fälle wird man nämlich nicht so einfach einen alternativ Shader mit einer anderen mathematischen Funktion finden der performancetechnisch und vom Ergebniss her mit den original identisch ist. und

Im Prinzip wollte ich ja auch nur andeuten das die Erkennung viel tiefer im Treiber liegt als bisher und deswegen nicht mehr so einfach wie vorher ausgehebelt werden kann. Wenn man beachtet, dass
1.) offenbar keine Checksum über die interaction.vfp gebildet wird,
2.) Variablen-Umbenennungen keine Auswirkung haben sowie
3.) offenbar der verwendete Algorithmus/die mathematische Funktion durch einen einfacheren, jedoch mathematisch identen Algorithmus ersetzt wird,
könnte man dann nicht der in der C't veröffentlichten "Gegenbehauptung" von NV zu den Vorwürfen von ATI, dass nämlich rein der Shader-Compiler die Shader vereinfacht, Glauben schenken? D. h. NV optimiert auf mathematischer Basis ohne Checksummenbildung - okay aber deutet das nicht genau auf eine "automatische" Optimierung mittels ShaderCompiler hin?
Und dass die Performanceverluse des Humus-Tweak/Quasar-Mod nur daher kommen, dass dieser besagte Compiler den veränderten Code vielleicht nicht erkennt, d. h. entsprechend optimieren kann?

MFG,
B. W.

/edit: ächz wie lange dauert's wohl, bis die ATI-Fraktion reagiert... *Seufz*

Xmas

2004-09-14, 01:04:41

Benedikt

2004-09-14, 01:16:07

Die Erkennung ist IMO gar nicht so kompliziert. Statt dass eine Checksumme für den reinen textuellen Shadercode gebildet wird, wird dies auf einer niedrigeren Übersetzungsebene getan. Dann spielen auch die Variablennamen keine Rolle mehr.
Hmm, interessant! Mir geht's ja auch eigentlich mehr um die Frage, ob das nicht ein automatischer Optimizer (Shader-Compiler) erledigt haben könnte. Womit ja dann NV's Behauptung stimmen würde. Oder ist das Ergebnis einfach zu gut, d. h. handoptimiert?

MFG,
B. W.

Jesus

2004-09-14, 01:19:01

Hmm, interessant! Mir geht's ja auch eigentlich mehr um die Frage, ob das nicht ein automatischer Optimizer (Shader-Compiler) erledigt haben könnte. Womit ja dann NV's Behauptung stimmen würde. Oder ist das Ergebnis einfach zu gut, d. h. handoptimiert?

MFG,
B. W.

Wenns ein automatischer Optimizer wäre dann würden die KArten nicht bei kleinen funktionell gleichen Änderungen einbrechen.

Benedikt

2004-09-14, 01:20:35

Wenns ein automatischer Optimizer wäre dann würden die KArten nicht bei kleinen funktionell gleichen Änderungen einbrechen. Ich meine mich erinnern zu können, dass Demi mal gesagt hat, der NV-Shadercompiler würde manche Konstrukte nicht richtig erkennen.
Und Jesus, der Humus-Tweak wirkt auf mich eigentlich nicht wie eine "kleine, funktionell gleiche Änderung". Aber darüber, was in diesen Rahmen fällt lässt sich wahrscheinlich streiten... :smile:

MFG,
B. W.

Jesus

2004-09-14, 01:23:23

Ich meine mich erinnern zu können, dass Demi mal gesagt hat, der NV-Shadercompiler würde manche Konstrukte nicht richtig erkennen.
Und Jesus, der Humus-Tweak wirkt auf mich eigentlich nicht wie eine "kleine, funktionell gleiche Änderung". Aber darüber, was in diesen Rahmen fällt lässt sich wahrscheinlich streiten... :smile:

MFG,
B. W.

ich red auch nicht vom Humus Tweak sondern vom anfügen eines einfachen Registerflags ".x" was Quasar gemacht hat.

Benedikt

2004-09-14, 01:36:23

ich red auch nicht vom Humus Tweak sondern vom anfügen eines einfachen Registerflags ".x" was Quasar gemacht hat.
Naja Jesus. Du kannst aber genauso wenig mit Bestimmtheit sagen, dass der NV-Compiler diese Änderung erkennt und korrekt interpretiert, oder? Ich weiß, es ist müßig darüber zu streiten, und ich bin selber frustriert weil ich nix genaueres darüber weiß, was NV da intern für Shader-Süppchen kocht. Aber ich möchte mal wissen, woher du deine Sicherheit nimmst, die aus deinen Postings erkennbar ist (NV betreibt Shader-Replacement). Du beziehst dich immer auf Carmack's Kommentar, aber Beweis ist das noch keiner, oder? Glaubst du denn, dass Carmack weiß was da intern im NV-Treiber abläuft? Wohl kaum ...

MFG,
B. W.

Jesus

2004-09-14, 01:43:28

Naja Jesus. Du kannst aber genauso wenig mit Bestimmtheit sagen, dass der NV-Compiler diese Änderung erkennt und korrekt interpretiert, oder? Ich weiß, es ist müßig darüber zu streiten, und ich bin selber frustriert weil ich nix genaueres darüber weiß, was NV da intern für Shader-Süppchen kocht. Aber ich möchte mal wissen, woher du deine Sicherheit nimmst, die aus deinen Postings erkennbar ist (NV betreibt Shader-Replacement). Du beziehst dich immer auf Carmack's Kommentar, aber Beweis ist das noch keiner, oder? Glaubst du denn, dass Carmack weiß was da intern im NV-Treiber abläuft? Wohl kaum ...

MFG,
B. W.

eh tschuldige, aber hast du schonmal die News gelesen ? Oder die Kommentare von Aths & Co. dazu ? Das ist bestimmt nicht auf meinem Mist gewachsen :|

aths

2004-09-14, 01:52:45

Um meinen Kommentar zu ergänzen: NV40 hat deutlich mehr Transistoren für andere neue Features, als neue Transistoren die speziell Doom3 nützen. Doch damit kann der NV40 offenbar die Taktschere von 25-30% durchaus ausgleichen. (Wird die X800 XT PE nun eigentlich als existent angesehen, oder nicht?) Der Rest ah Leistung kommt wohl durch, äh, "Optimierungen" von NV.

Die Frage ist einerseits, wie stehen die Spitzenmodelle zueinander, und andererseits, wie die real erhältlichen Karten. Auch wenn von NV nicht offiziell vermarktet, kann man den NV40 mit bis zu 450 MHz werkseitiger Taktung kaufen. Zählt das als Quasi-XT PE?

Oder ist die Leistung der Mittelklasse (6600 vs. X700) das Hauptmerkmal?

So oder so, ich erwarte, dass NV im Highend-Segment den Leistungsvorteil in Doom3 halten kann, auch dann wenn ATI mit Shader-Optimierung nachzieht. Glücklich bin ich über derartige Praktiken jedoch nicht.

Benedikt

2004-09-14, 01:56:46

eh tschuldige, aber hast du schonmal die News gelesen ? Oder die Kommentare von Aths & Co. dazu ? Das ist bestimmt nicht auf meinem Mist gewachsen :|
Brauchst mich net so ansteigen, bleib cool. Sicher lese ich die News. Es ist nur manchmal besser, man hinterfragt die Dinge, statt alles sofort bedingungslos zu glauben. :wink:

MFG,
B. W.

zeckensack

2004-09-14, 23:36:03

könnte man dann nicht der in der C't veröffentlichten "Gegenbehauptung" von NV zu den Vorwürfen von ATI, dass nämlich rein der Shader-Compiler die Shader vereinfacht, Glauben schenken?Garnicht.

NVIDIA hat offiziell ein ziemlich perverses Verständnis von den Begriffen "Compiler" und "Optimierer". Man erinnere sich an die sogenannte UCT, "unified compiler technology". Das fiese an dieser Sache ist, dass dies kein technischer Begriff, sondern nur noch ein Marketingkunstwort (wie SmoothVision et al) ist, allerdings mit gefährlicher Suggestivwirkung.

Was NVIDIA mit "UCT" tatsächlich meint ist aber "unter anderem" *hust* Shader-Erkennung und Ersetzung.

Coda

2004-09-15, 00:02:25

Einen richtig guten Compiler zu bauen ist nunmal nicht so einfach, aber vielleicht wird man irgendwann im Stande sein ohne Shaderreplacements auszukommen.

Naja bei der Entwicklung wird das eh passieren, weil es ist wohl nicht mehr so einfach möglich ist Shader mit Flow Control und über 1000 Instructions auszutauschen.

Quasar

2004-09-15, 10:03:24

Seraf

2004-09-15, 10:35:46

Apropos:

Ganz offiziell scheint sich auch die Doom3-Geschichte nicht mit den selbst auferlegten Optimierungsrichtlinien von nV zu beissen... ;)

Allerdings scheint der neue ATi-Treiber auch nicht grad ein Musterknabe darin zu sein, das zu tun, was man von ihm verlangt.

Ich find es schon seltsam das ich mit dem Cat4.9 jetzt keine Pixelfehler mehr auf meiner Waffe habe (löchriges Schachbrett). Mit dem Cat4.8 wars teilweise noch extrem. :D

Irgendwas muß ATI ja abgeändert haben.

Hab ne 9800SE mit ein oder zwei Piplines die nur bei manchen Spielen mit Shadern Pixelfehler zeigt.