ATi unter doom3 beschleunigen, bis zu 40%?!

[Cpl. Dwayne Hicks]

hi!

wenns schonmal gepostet wurde dann zeigt mich an, verfolgt meine ip addresse und brennt mein haus nieder... oder schliesst diesen thread einfach ;)

aber was ich im rage3d forum gefunden habe:



http://rage3d.com/board/showthread.php?t=33774485


hier das original:

http://www.beyond3d.com/forum/viewtopic.php?t=14874

Die leute die einem plan von den zeugs haben können es hier ja auch mal testen! Der "erfinder" meint dass es mit AA und AF die größten leistungszuwächse gibt!

[smockdogx]

momment ich suche nur noch das feuerzeug ;D

[Demirug]

Scheint ja leider nicht so ganz unproblematisch zu sein. Inzwischen häufen sich Meldungen über Beleuchtungsfehler.

Das ganze kommt mir wie ein Schnellschuss vor. Bevor man in einem Shader eine Texturanweisung gegen eine Rechenoperation tauscht sollte man zumindestens die entsprechenden Texture dahingehend untersuchen ob sie überhaupt das enthält was man vermutet.

Seit Humus bei ATI ist hat er ja leider etwas fanatische Züge bekommen.

Im Prinzip hat er allerdings bei dieser Sache recht. Wenn die Textur wirklich nur einen Graph für die Pow Funktion enthält wäre es besser diese auch zu benutzten. Was mich allerdings selbst wundert ist die Verwendung einer 2D Textur obwohl eine 1D Textur hier reichen würde.

[Sphinx]

hi!

wenns schonmal gepostet wurde dann zeigt mich an, verfolgt meine ip addresse und brennt mein haus nieder... oder schliesst diesen thread einfach ;)

aber was ich im rage3d forum gefunden habe:



http://rage3d.com/board/showthread.php?t=33774485


hier das original:

http://www.beyond3d.com/forum/viewtopic.php?t=14874

Die leute die einem plan von den zeugs haben können es hier ja auch mal testen! Der "erfinder" meint dass es mit AA und AF die größten leistungszuwächse gibt!


Jep hab die Changes mal an meiner pak000.pk4 durchgeführt die Humus dort bereitgestellt hat was soll ich sagen.

KORRIGIERT 4x TESTDURCHLAUF jeweils pro Setting

R97oo PRO - Timedemo not opt. 1024x768 - AF/AA Dis. - HighQualität = 39.7 FPS

R97oo PRO - Timedemo opt. 1024x768 - AF/AA Dis. - HighQualität = 40.6 FPS

Im schnitt 2 % Performancezuwachs.



@ Demirug : Das wurde nun nicht getestet von mir ~ immo - aber ich schau mal nach ob ich Beleuchtungsfehler finde und mache Shots.

[Cpl. Dwayne Hicks]

Jep hab die Changes mal an meiner pak000.pk4 durchgeführt die Humus dort bereitgestellt hat was soll ich sagen.

R97oo PRO - Timedemo not opt. 1280x1024 - AF/AA Dis. - HighQualität = 29.9 FPS

R97oo PRO - Timedemo opt. 1280x1024 - AF/AA Dis. - HighQualität = 40.5 FPS

Im schnitt 35 % Performancezuwachs.



@ Demirug : Das wurde nun nicht getestet von mir ~ immo - aber ich schau mal nach ob ich Beleuchtungsfehler finde und mache Shots.

Hast du den timedemo benchmark auch mehrmals durchlaufen lassen, vorher und nachher?
Denk dran der erste durchlauf ist meistens langsamer weil die texturen usw.. erstmal gecached werden müssen.


Und hast du unterschiede in der bildqualität bemerkt?

Meine kopie von doom3 ist nämlich immernoch nicht angekommen. :(



Wenn die Textur wirklich nur einen Graph für die Pow Funktion enthält wäre es besser diese auch zu benutzten.

Kannst du das nicht für uns herausfinden? :)

[Sphinx]

Hast du den timedemo benchmark auch mehrmals durchlaufen lassen, vorher und nachher?
Denk dran der erste durchlauf ist meistens langsamer weil die texturen usw.. erstmal gecached werden müssen.


Und hast du unterschiede in der bildqualität bemerkt?

Meine kopie von doom3 ist nämlich immernoch nicht angekommen. :(

Erster Wert not Opt. 2x Mal

Zweiter Wert Opt. 3x Mal

Aber ich muss die Werte wohl korrigieren. Der 29.9 FPS Wert ist nicht Relevant keine Ahnung warum aber nachdem ich die Changes Rückgängig gemacht hatte und 4x Mal Gebenched habe war dieser Wert höher...

Wohl ein Fehler meinerseits.

@ Demi:
Also ein erstes anspielen - brachte bei mir keine "erkennenden Belichtungsfehler" eventuell wenn vorhandene Belichtungsfehler müste mich wohl sonst einer direkt mit der Nase draufstoßen.

[Mark]

also ich konnte bei mir keinerlei positive wirkung feststellen. vorher und nachher waren ungefähr 25fps bei mir

800x600
middle details
shadows off, noaa, noaf

[Quasar]

Also ein erstes anspielen - brachte bei mir keine "erkennenden Belichtungsfehler" eventuell wenn vorhandene Belichtungsfehler müste mich wohl sonst einer direkt mit der Nase draufstoßen.[/size]

Das ist es wohl... Diese Fehler werden gern auch mal (mangels Vergleichsmöglichkeit) als gegeben hingenommen.

Eine Frage: Welchen Treiber nutzt du?

[Sphinx]

Das ist es wohl... Diese Fehler werden gern auch mal (mangels Vergleichsmöglichkeit) als gegeben hingenommen.

Eine Frage: Welchen Treiber nutzt du?

Cat4.9 Beta


EDIT : Ich glaub ich bin noch nicht wach genug ^ DIE ERGEBNISSE NUN SIND REPRÄSENTATIV - Ich kam auf 35% da der erste unoptimierte in 1280x1024 gemacht wurde und der opt. in 1024x768 * Irren ist menschlich + aber sowas auch * Die Werte oben sind nun korrigiert und stimmen mit den Settings + Werten auch 100%

Also 2% Geschwindigkeitsvorteil bei 1024x768 @ HighQualität Settings.


Sphinx - ich gönn mir erstmal nen starken kaffee

[maas]

Also 2% Geschwindigkeitsvorteil bei 1024x768 @ HighQualität Settings.


2% Performanceunterschied sind ja nicht mal spürbar. Dafür patche ich mir nicht mein Doom3 kaputt.

[Madox]

In dem Thread auf beyond3d haben einige x800 User höhere Frames. Bei den "alten" hielt sich der Unterschied in Grenzen. Werde das gleich mal testen ...

[Quasar]

Cat4.9 Beta

Sphinx - ich gönn mir erstmal nen starken kaffee

Danke. So langsam scheint dieser "Wahnsinn" ;) Methode zu bekommen - viele berichten von 10-20% Performancesteigerung und Artefakten.
Andere wiederum nehmen keine (neuen?) Artefakte wahr, bekommen allerdings auch nur marginal Leistung hinzu.

Erstere scheinen vornehmlich bereits den Cat4.9b einzusetzen, letztere hingegen nutzen oftmals den Cat4.7.

(... tbc...)

[Mumins]

Der Tweak bringt so gut wie nichts. In der Timedemo hab ich in 1024x768 High Details 2AA ohne Tweak 37,8 FPS mit dem Tweak 38,3. Habs mehrmals laufen lassen bleibt immer im gleichen Rahmen. Treiber ist Cat. 4.9beta, Karte ist auf 435/375 getaktet.

[Madox]

Also bei mir Radeon x800 xt pe (520/560)
Bei 1280x1024 - 4xAA - 8xAF Tri

Nach jeweils 3 Durchläufen Timedemo1

Ohne tweak - 38,7FPS
Mit tweak - 43,6Fps

Also 12% mehr. Allerdings gibts Artefakte. In dunklen Passagen, dort wo kein Licht hinfällt passiert gelegentlich soetwas

http://bl4de.pyrokar.lima-city.de/egri/beispiel.jpg

schade eigentlich ;)

Edit:

ungefähr die gleiche Stelle ohne Tweak

http://bl4de.pyrokar.lima-city.de/egri/beispiel2.jpg

[Quasar]

Madox - auch an edit: dich die Frage, welchen Treiber du benutzt?

[Madox]

Ups ja klar ... den 4.9beta :)

[Quasar]

Und du hast beide Bilder mit den 4.9erBeta gemacht?

[Demirug]

Eine solche Überbeleuchtung habe ich ja aufgrund der Codeänderung befürchtet. Unter Umständen bekommt man das aber in den Griff wenn man die Zeile wie folgt ändert.

Anstelle von:

POW R1, specular.x, specExp.x;

ein

POW_SAT R1, specular.x, specExp.x;

einfügen.

Ist aber in keiner Form von mir getestet.

[unwissend!]

He danke Demi. Hab zwar immer noch Artefakte aber sie sind nicht mehr so weiß leuchtend. Cata 4.9b auf Radeon 9800Pro.

EDIT: Hab die stelle gerade nochmal kontrolliert mit allen drei Einstellungen(Original, Humus, Demirug) und muß mich korrigieren. Danke Demi es sieht sogar genau wie im Original aus.

cu unwissend!

[DoomDoom]

Irgendwie ist das doch bescheuert. Nur um einen unmerklichen prozentualen Performancezuwachs zu bekommen, versauen sich hier manche die Bildqualität und nehmen Darstellungsfehler in Kauf? Für eine fps-Stelle hinterm Komma?

Da würde ich doch lieber in den Grafikeinstellung ein bisschen runterfahren. Da gibt's mehr Leistungszuwachs und auch keine Fehldarstellungen und Artefakte.

[Madox]

Und du hast beide Bilder mit den 4.9erBeta gemacht?

ja

@Demi

Prima funktioniert. nun siehts so aus wie das untere Bild von mir ... vielleicht eine nuance heller...

@DoomDoom

12% sind "Stellen hinterm Komma" ? Naja nichts für ungut ;)

[MGeee]

Irgendwie ist das doch bescheuert. Nur um einen unmerklichen prozentualen Performancezuwachs zu bekommen, versauen sich hier manche die Bildqualität und nehmen Darstellungsfehler in Kauf? Für eine fps-Stelle hinterm Komma?

Da würde ich doch lieber in den Grafikeinstellung ein bisschen runterfahren. Da gibt's mehr Leistungszuwachs und auch keine Fehldarstellungen und Artefakte.

Die Summe machts, wenn man alle Tweaks nutzt und sein Doom3 optimal auf sein System einstellt (bei so wenig wie möglich Qualitätsverlust), holt man gesamt gesehen ordentlich was raus. Ich für meinen Part habe 1-2 Stunden in die Optimierung gesteckt. Mehr Tweaks gibt es für Doom3 erst, wenns einmal durchgezockt ist. Danach will ich mal eine Speed-Config nutzen und Doom3 schonungslos schnell durchzocken. Danach mal eine Quality-Config und Doom3 nochmal schön langsam mit allen Secrets....macht 60h Spielspass (wenn´s nicht irgendwann langweilig wird).

[Quasar]

@Madox:
Danke, ich hatte schon übelste Befürchtungen. ;)

[Madox]

@Madox:
Danke, ich hatte schon übelste Befürchtungen. ;)

Du Schelm Du ;D

[Radeonator]

Würde vorschlagen den offiziellen Patch abzuwarten, anstatt das Game zu "zerhackstückeln". Wenn euch schlechtere Quali in eurer Balkengeilheit nicht stört dreht einfach die Settings runter :eyes:

[Demirug]

Wenn wir schon am Shaderfummeln sind:

# perform the diffuse bump mapping

#-----------------
TEX light, fragment.texcoord[0], texture[0], CUBE;
MAD light, light, scaleTwo, subOne;

# instead of using the normalization cube map, normalize with math
#DP3 light, fragment.texcoord[0],fragment.texcoord[0];
#RSQ light, light.x;
#MUL light, light.x, fragment.texcoord[0];
#-----------------[Code]

ändern in

[Code]# perform the diffuse bump mapping
#-----------------
#TEX light, fragment.texcoord[0], texture[0], CUBE;
#MAD light, light, scaleTwo, subOne;

# instead of using the normalization cube map, normalize with math
DP3 light, fragment.texcoord[0],fragment.texcoord[0];
RSQ light, light.x;
MUL light, light.x, fragment.texcoord[0];
#-----------------

Könnte bei der Verwendung von AF was bringen wenn die Cubemap auch AF bekommt.

Die Stelle hat Coda entdeckt wenn es also was bringt gehört ihm das Lob. Wenn es nichts bringt dürft ihr aber mich hauen.

[Madox]

Würde vorschlagen den offiziellen Patch abzuwarten, anstatt das Game zu "zerhackstückeln". Wenn euch schlechtere Quali in eurer Balkengeilheit nicht stört dreht einfach die Settings runter :eyes:

Naja Du hast natürlich vollkommen recht. Gute Antwort ... zum falschen Thema. Hier geht es um Änderungen, die mehr Speed bringen ohne die Qualität zu mindern. Eine Balkengeilheit dort hinein zu deuten ist hier wohl mehr als unpassend .

[Demirug]

Würde vorschlagen den offiziellen Patch abzuwarten, anstatt das Game zu "zerhackstückeln". Wenn euch schlechtere Quali in eurer Balkengeilheit nicht stört dreht einfach die Settings runter :eyes:

Spieltrieb. Solange man eine Kopie von der Originaldatei hat macht so ein bischen Hacking doch Spass.

[Madox]

Wenn wir schon am Shaderfummeln sind:

# perform the diffuse bump mapping

#-----------------
TEX light, fragment.texcoord[0], texture[0], CUBE;
MAD light, light, scaleTwo, subOne;

# instead of using the normalization cube map, normalize with math
#DP3 light, fragment.texcoord[0],fragment.texcoord[0];
#RSQ light, light.x;
#MUL light, light.x, fragment.texcoord[0];
#-----------------[Code]

ändern in

[Code]# perform the diffuse bump mapping
#-----------------
#TEX light, fragment.texcoord[0], texture[0], CUBE;
#MAD light, light, scaleTwo, subOne;

# instead of using the normalization cube map, normalize with math
DP3 light, fragment.texcoord[0],fragment.texcoord[0];
RSQ light, light.x;
MUL light, light.x, fragment.texcoord[0];
#-----------------

Könnte bei der Verwendung von AF was bringen wenn die Cubemap auch AF bekommt.

Die Stelle hat Coda entdeckt wenn es also was bringt gehört ihm das Lob. Wenn es nichts bringt dürft ihr aber mich hauen.

teste ich gleich mal :) *peitschezück*

[Oggi]

Ohne Tweak:

9800 Pro - 1024*768 ohne af+aa - 48
9800 Pro - 1024*768 mit 8x af + 4x aa - 22,3

Mit dem Tweak:

9800 Pro - 1024*768 ohne af+aa - 48,4
9800 Pro - 1024*768 mit 8x af + 4x aa - 26


Graka is nit Oced, High Settings im Game ohne VSync versteht sich:D

Jeweils 3 Testdurchläufe in der Timedemo.

[L°°pb4ck]

Spieltrieb. Solange man eine Kopie von der Originaldatei hat macht so ein bischen Hacking doch Spass.

Genau so siehts aus!

Und wo wir beim Thema sind ....

*EDIT* siehe meinen nächsten Post für Screenshot vergleich

mit dem Original von Humus die Anpassungen von Demirug hab ich noch net getestet ... werd ich aber jetzt machen ... immerhin kann ich mit meiner gümmeligen 9700pro (Cat 4.9Beta) jetzt 1024*786 / High / 2*AA mit brauchbaren Frames spielen.

[Madox]

Also alle Tweaks an (Humus + Demi´s Codezeilenänderung + Coda´s part)

1280x1024 4xaa 8xtri af
Cata 4.9beta

Timedemo1 46,2fps

Bei ungefähr der gleichen Stelle wie oben ...

http://bl4de.pyrokar.lima-city.de/egri/beispiel3.jpg

... gibts nichts zu bemängeln.

Alles in Allem haben die Änderungen bei gleichbleibender Qualität einen Satz von anfangs 38,7 auf nun 46,2fps gemacht.

Einen 100% Screenshotvergleich habe ich zwar nicht durchgeführt, aber diese hellen Stellen gibts nicht mehr.

[Demirug]

Einen 100% Screenshotvergleich habe ich zwar nicht durchgeführt, aber diese hellen Stellen gibts nicht mehr.

100% identisch kann es mit der von mir vorgeschlagenen Änderung eigentlich sowieso nicht mehr sein. Es wird nämlich dadurch genauer gerechnet.

[Riipa]

Vielleicht erwähnen welcher Tweak. :-)

Demi wärest Du eventuell so nett eine Datei mit beiden Änderungen fertigzumachen und zur Verfügung zu stellen? Ok, es IST Faulheit, die mich treibt das zu fragen, aber versuchen kann mans ja mal, oder? :-D

[Oggi]

Vielleicht erwähnen welcher Tweak. :-)

Demi wärest Du eventuell so nett eine Datei mit beiden Änderungen fertigzumachen und zur Verfügung zu stellen? Ok, es IST Faulheit, die mich treibt das zu fragen, aber versuchen kann mans ja mal, oder? :-D^


Upsi,sorry *fg*

Der von Humus

[Madox]

Wie gesagt ... einen screenshotvergleich habe ich nicht durchgeführt. Rein subjektiv hat sich zwischen "vorher" und "nacher" nichts geändert. Worauf sollte ich denn achten beider af "optimierung" ? Bei dieser dunklen umgebung gibts eh kaum etwas am af auszusetzen ;)

[Sale]

habe nun den tweak auch vogenommen. habe ca. durchschnittlich 20% mehr leistung. 1280x1024 4xAA 8x AF

[Madox]

Vielleicht erwähnen welcher Tweak. :-)

Demi wärest Du eventuell so nett eine Datei mit beiden Änderungen fertigzumachen und zur Verfügung zu stellen? Ok, es IST Faulheit, die mich treibt das zu fragen, aber versuchen kann mans ja mal, oder? :-D

Rechtsklick/speichern unter (http://bl4de.pyrokar.lima-city.de/egri/interaction.vfp)

Das ist die Komplette Datei mit allen Änderungen :)

[Riipa]

Danke! *knuddel*

Dann werde ich mir das auch mal angucken. Schade, dass man hier niemanden good oder bad voten kann. :D

[Madox]

Aber ich befürchte, dass es bei einer Radeon 9x00 nicht sooo viel bringt. Meine Radeon 9700 np hat zb "nur" 5-6% dadurch gewonnen. Aber immerhin ...

[L°°pb4ck]

So Screenshotvergleich:

Die Stelle befindet sich anfangs des Monorail abschnitts. Rechts an der Wand.

Original von Humus:

1024*768 / High / 2*AA / Anisotrope aus

http://www.l00pb4ck.de/images/stories/Doom3_1.jpg
http://www.l00pb4ck.de/images/stories/Doom3_2.jpg

Anpassung von Demirug:

1024*768 / High / 2*AA / 4*Anisotrope

http://www.l00pb4ck.de/images/stories/Doom3_4.jpg
http://www.l00pb4ck.de/images/stories/Doom3_3.jpg

Die Timedemo ist imho für diesen Fix nicht aussagekräftig. Ich bekomm da nur max 2 FPS mehr. Mein (rein subjektives) Spielempfinden und der Blick auf den permanent mitlaufenden FPS-Counter sagen mir aber das das Game ordentlich zugelegt hat.

Edit: Interaction.txt angehängt

[R300]

Welche Datei muss ich verändern?
das Beyond 3D Forum funzt nicht.

[Madox]

Das kann ich Unterschreiben. Doom3 fühlt sich wirklich schneller an. Ich habe bei grossen Räumen keine grossen Einbrüche mehr.

[Riipa]

Hmpf! 9800 XT (wieder drin), Catalyst 4.7 und es sieht mächtig, mächtig böse aus. Der Speed geht zwar auf 51.5 FPS beim Timedemo hoch, aber die Grafik ist böse zerfleddert, ich versuche mal Screenies zu machen, im Demo ging das nicht.

[Madox]

Welche Datei muss ich verändern?
das Beyond 3D Forum funzt nicht.

Die glprogs\interaction.vfp datei im pak000.pk4

[aorangi]

Hat das mal jemand mit einer Nvidia-Karte getestet? Sind die dann auch nochmal 40% schneller? ;)

[Madox]

War ja klar, dass das wieder kommt ;) Im Beyond3d Forum hat das jemand getestet (nur humus Änderungen Geforce 6800GT) und bei Ihm brachte es nichts

[del_4901]

Hat das mal jemand mit einer Nvidia-Karte getestet? Sind die dann auch nochmal 40% schneller? ;)
Die Coda Änderung könnte durchaus auch auf Nv3x Karten schneller sein, alldieweil der Shader dann eine gerade Anzahl Texturefetches benutzt, das lässt sich besser optimieren.

[Strayed]

Kann man den Code auch ändern, ohne gleich alles zu entpacken? Bei mir geht das irgendwie nicht ;(

[Madox]

Ich nutze Winrar. Damit konnte ich das eine file extrahieren.

[R300]

LOL
Jetzt ist bei mir alles blau und die Bump Maps sind weg.
http://img55.exs.cx/img55/4086/shot4.jpg

(cat 4.9 beta)

[Riipa]

Hier meine Bilder mit der von madox geposteten Config. :(

http://www.riipa.de/pics/doom3/1-original.jpg
http://www.riipa.de/pics/doom3/1-madox.jpg

http://www.riipa.de/pics/doom3/2-original.jpg
http://www.riipa.de/pics/doom3/2-madox.jpg

http://www.riipa.de/pics/doom3/3-original.jpg
http://www.riipa.de/pics/doom3/3-madox.jpg

[Madox]

Hier meine Bilder mit der von madox geposteten Config. :(

http://www.riipa.de/pics/doom3/1-original.jpg
http://www.riipa.de/pics/doom3/1-madox.jpg

http://www.riipa.de/pics/doom3/2-original.jpg
http://www.riipa.de/pics/doom3/2-madox.jpg

http://www.riipa.de/pics/doom3/3-original.jpg
http://www.riipa.de/pics/doom3/3-madox.jpg


lol das is wohl etwas bei dem copy paste durcheinander gelaufen :D muss ich kurz schauen was ich da wieder gemacht habe mom :)

rechtsklick/speichern unter
Hier klicken (http://bl4de.pyrokar.lima-city.de/egri/interaction.vfp)

Das ist die datei die ich nutze

[L°°pb4ck]

Ihr könnt auch die Interaction.txt aus meinem Post anfangs der 3ten Seite nehmen mit der läufts bei mir einwandfrei ... einfach in Interaction.cfg umbenennen und ins pk4 archiv packen.

[R300]

cfg?
Muss die nicht vfp heißen?

[Madox]

cfg?
Muss die nicht vfp heißen?


Ja hast recht ... die Datei muss interaction.vfp heissen ;)

[R300]

Hmmm jetzt ist es langsamer als vorher.
Original: 42,2fps
Madox: 41,4fps

[Riipa]

Dito. 1.5 FPS verloren mit der config, aber dafür sieht es wieder fehlerfrei aus. :)

[Madox]

Ich habe doch schon geschrieben, dass zb meine x800xt mehr profitiert wie meine 9700np. Bei mir gibts einen anstieg ^^ mhhh ist ja sehr komisch.

Edit:

Also gerade noch einmal gemessen.

ohne tweaks

39.1fps

mit tweaks

46.1fps

aber warum profitiert Ihr nicht dsvon ??? Vielleicht können sich die Experten das erklären ?

[betasilie]

Wie lange war D³ in der Entwicklung? :-/

Wieso optimiert JC nicht selber den Code des Spiels? Wieso müssen das Leute rausfinden, die garnicht bei id arbeiten? Ist das normal, dass man soviel Performance auf der Strecke lässt, damit diese hinterher per tweak freigeschaltet wird? O_o

[Riipa]

ICh habe gestern irgendetwas in einem der vielen Threads gelesen, dass die meisten, die profitieren wohl den Cata 4.9b drauf hatten. Da zumindest ich den offiziellen 4.7 drauf habe könnte das ein Ansatz sein.

[tombman]

Ich habe doch schon geschrieben, dass zb meine x800xt mehr profitiert wie meine 9700np. Bei mir gibts einen anstieg ^^ mhhh ist ja sehr komisch.

Edit:

Also gerade noch einmal gemessen.

ohne tweaks

39.1fps

mit tweaks

46.1fps

aber warum profitiert Ihr nicht dsvon ??? Vielleicht können sich die Experten das erklären ?

Hmm, also bei mir gibts maximal 2fps mehr, aber eben mit den bekannten Fehlern.

Ich hab jetzt auch mal in 1280x1024 mit 4xAA/8xAF (ingame) gebenched und
ich hatte mit der original interaction.vfp schon 46.6fps, jetzt mit humus vfp 48.6 (x800xtpe @ default).

Auf 1600x1200 gabs noch viel weniger Unterschied. Immer noch keine Chance gegen die 6800u, besonders bei den so wichtigen minimum fps.
Am besten die Stelle ansehen GANZ zum Schluß wo das Monster langsam auf einen zukommt mit dem Feuerball in der Hand. Da sieht man wunderbar wieviel schneller die 6800u in d3 ist.

Fazit: derzeit nur Hype. Wenn bei einigen mit der original Datei so langsam rennt, dann muß irgendwas daran falsch sein (bug?), aber Humus bringt ned mehr speed bei mir.

[Mark]

ei mir gibt es keine zuwachs aber auch keinen abstrich, sowohl an der bildqualität als auch an der geschwindigkeit

[Mark]

kann nochmal einer die original-datei hochladen? habs die leider gelöscht

[R300]

Hier das Original:
(in vfp umbenennen)

[Demirug]

Wie lange war D³ in der Entwicklung? :-/

Wieso optimiert JC nicht selber den Code des Spiels? Wieso müssen das Leute rausfinden, die garnicht bei id arbeiten? Ist das normal, dass man soviel Performance auf der Strecke lässt, damit diese hinterher per tweak freigeschaltet wird? O_o

Das scheint ja bei ATI eine merkwürdige Sache zu sein weil irgendwie nicht alle davon profitieren. Zudem verursacht der TEX vs POW Trick ja immer noch Fehler auch wenn man das _SAT hinzufügt. Was nun meinen zusätzlichen Vorschlag angeht so könnte der ohne AF auch nach hinten lossgehen. Gerade bei AF lohnt es sich eben schnell TEX Anweisungen gegen Rechenanweisungen auszutauschen. Ohne AF kann das auslesen einer Texture aber schneller sein als das Rechnen.

[Madox]

Hmm, also bei mir gibts maximal 2fps mehr, aber eben mit den bekannten Fehlern.

Ich hab jetzt auch mal in 1280x1024 mit 4xAA/8xAF (ingame) gebenched und
ich hatte mit der original interaction.vfp schon 46.6fps, jetzt mit humus vfp 48.6 (x800xtpe @ default).

Auf 1600x1200 gabs noch viel weniger Unterschied. Immer noch keine Chance gegen die 6800u, besonders bei den so wichtigen minimum fps.
Am besten die Stelle ansehen GANZ zum Schluß wo das Monster langsam auf einen zukommt mit dem Feuerball in der Hand. Da sieht man wunderbar wieviel schneller die 6800u in d3 ist.

Fazit: derzeit nur Hype. Wenn bei einigen mit der original Datei so langsam rennt, dann muß irgendwas daran falsch sein (bug?), aber Humus bringt ned mehr speed bei mir.

Hallo Tombman

danke dass Du das auch noch einmal getestet hast. Aber bei mir ists wirklich so, dass durch den Tausch die fps hochgehen.ich warte noch auf einen Bekannten, der die gleiche config hat wie ich. Da müsste das doch zu reproduzieren sein :)

Edit: Du hast ja auch einen A64 bei gleichem Takt wie mein Athlon Barton :) Deswegen hast du schon "von Haus aus" mehr fps ;) obwohl ... dann wäre es ja cpu limitiert bei mir ... das kann ja auch nicht sein ^^

[betasilie]

Das scheint ja bei ATI eine merkwürdige Sache zu sein weil irgendwie nicht alle davon profitieren. Zudem verursacht der TEX vs POW Trick ja immer noch Fehler auch wenn man das _SAT hinzufügt. Was nun meinen zusätzlichen Vorschlag angeht so könnte der ohne AF auch nach hinten lossgehen. Gerade bei AF lohnt es sich eben schnell TEX Anweisungen gegen Rechenanweisungen auszutauschen. Ohne AF kann das auslesen einer Texture aber schneller sein als das Rechnen.
Ok, dass ist natürlich ein Argument was gegen eine generelle Implementierung spricht.

[pRAyNz]

Moin,
wollte nur mal mitteilen, daß Humus Patch inklusive Demirugs Fix bei mir knapp 26% Mehrleistung gebracht hat (1280x1024@High, mit 2xAF und im jeweils zweiten Timedemo-Durchlauf). :D :love1:
- Ich habe übrigens nur eine R360(256MB) und benutze auch die 4.9 Beta-Treiber, die bei mir im Vergleich zu den 4.8 Betas praktisch nichts gebracht haben.
Die Änderungen von Coda haben diese Mehrleistung bei mir dann allerdings wieder auf leicht unter 17 Prozent gesenkt, sich also negativ ausgewirkt.

Edit:

Oops, eben waren versehendlich die Schatten ausgestellt und nachdem ich das bemerkt und neu gebencht habe (diesmal mit Schatten und 8xAF), lag der Leistungsgewinn nur noch bei etwa 14% (ohne Codas Änderungen - mit ihnen lag er erneut niedriger, nämlich bei leicht über 8%)

[Madox]

dann bin ich aber froh, dass ich nicht der einzige bin, bei dem es etwas gebracht hat :D

[Mark]

ich hab 13%, aber vermutlich würde sich mehr ändern wenn ich schatten eingeschaltet hätte, was aber zu nicht spielbaren frameraten führen würde

[Blacksoul]

Bei mir hat der tweak das Licht im Spiel ausgeknipst ;D

Also keine Beleuchtung mehr.

1280x1024
Ultrahigh settings.

9800Pro @ stock
53fps

X-D

(Ohne Beleuchtung versteht dich ;))

edit: Hat sich erledigt. Bin beim Copy&Paste eine zeile verrutscht.

1280x1024
Ultrahigh settings

9800pro @stock

mit tweak 20.7fps
ohne 21.7 fps.

t.blacksoul.d

ps:

teste gerade 1280x1024 mit Ultra settings, weil mir jemand klar machen will, bei den settings mit einer 9800pro @ stock und einem XP 2500+ (non ocd) 41.5fps in der Timedemo hat X-D.
Hab schon seine cfg getestet, nichts.

[Mark]

dunkeler wurde es, aber das hab ich in den einstellungen halt ausgeglichen. da kann man ja die helligkeit erhöhren

[radi]

ka ob sich da groß was verändert hat... bringt der tweak nur was wenn man den 4.9b verwendet? ich nutze grad den 4.7 wenn ich mich recht erinnere :P

optische veränderungen hab ich auch nicht festgestellt.

[DoomDoom]

Wie lange war D³ in der Entwicklung? :-/

Wieso optimiert JC nicht selber den Code des Spiels? Wieso müssen das Leute rausfinden, die garnicht bei id arbeiten?

Weil dieser Tweak keine "Optimierung", sondern eine Verschrottung der Bildqualität ist. Carmacks Engine muss auf Zuverlässigkeit ausgelegt sein und nicht für ein paar Bastler, die für ein paar Prozent Balkenlänge Grafikfehler in Kauf nehmen.

Würdest Du Dich wohler fühlen, wenn die Benchmarkbalken im Schnitt 2% länger wären, aber dauernd hier Threads entstehen würden wie:

Hilfe! Dauernd Grafikfehler auf ATI-Karten bei Doom3!!!"

;)

[Blacksoul]

Benchs mit normalen settings:

9800Pro @ stock
1024x768
High
ohne 39.9 fps
mit 39.4 fps

Keine Besserung.

[Mark]

Weil dieser Tweak keine "Optimierung", sondern eine Verschrottung der Bildqualität ist. Carmacks Engine muss auf Zuverlässigkeit ausgelegt sein und nicht für ein paar Bastler, die für ein paar Prozent Balkenlänge Grafikfehler in Kauf nehmen.

Würdest Du Dich wohler fühlen, wenn die Benchmarkbalken im Schnitt 2% länger wären, aber dauernd hier Threads entstehen würden wie:

Hilfe! Dauernd Grafikfehler auf ATI-Karten bei Doom3!!!"

;)

naj, dank Coda's verbesserung haben wir jetzt mehr fps und gleiche bildqualität

[aths]

Die Coda Änderung könnte durchaus auch auf Nv3x Karten schneller sein, alldieweil der Shader dann eine gerade Anzahl Texturefetches benutzt, das lässt sich besser optimieren.Eine zusätzliche Texture-Op einzufügen muss, gerade Zahl Textur-Operationen hin oder her, nicht gleich ein Speedup ergeben. Normalerweise ist es besser, so wenig Texture Ops zu nutzen, wie möglich. Manchmal ist es aber doch schneller, mit der TMU einen Lookup zu machen, als einen Wert auszurechnen.

[Demirug]

naj, dank Coda's verbesserung haben wir jetzt mehr fps und gleiche bildqualität

So einfach ist das leider nicht. Der Austausch der Tex anweisung gegen POW scheint kein 100% Ersatz zu sein. Es scheint so als wäre in der Texture doch mehr als nur ein POW hinterlegt.

[radi]

ka ob sich da groß was verändert hat... bringt der tweak nur was wenn man den 4.9b verwendet? ich nutze grad den 4.7 wenn ich mich recht erinnere :P

optische veränderungen hab ich auch nicht festgestellt.

darf ich nomma drauf aufmerksam machen? ! :) danke

[BodyLove]

afaik sollte man den Cat4.9beta installiert haben, um die Volle Leistung zu entfalten.

[Unregistriert1]

afaik sollte man den Cat4.9beta nicht installiert haben, wenn man volle Bildqualität will

[deekey777]

afaik sollte man den Cat4.9beta nicht installiert haben, wenn man volle Bildqualität will


Irgendjemand hat in die Welt ein Gerücht gesetzt, wonach der 4.9 beta D3 Hotfix in Doom 3 16bit Texturen "forcen" würde. Ein anderes Gerücht besagt, dass dies irgendwie eine id Gemeinheit sei, die nur in illegalen Versionen auftauche...

@all: Testet weiter! Wenn ich irgendwann Doom 3 zocke, will ich mt dem Hotfix Nr. 2 keine Fehler sehen. ;D :weg:


Computerbase zum Thema. (http://www.computerbase.de/news/hardware/grafikkarten/ati/2004/august/neues_doom_3hotfix_atikarten/)

[BodyLove]

Zumindest hat CB beim Bildqualivergleich nicht derartiges entdecken können...

[Gast]

Sorry, bin nur Gast, aber wollte mal kurz was zu dem ganzen Thema
loswerden. ;)

Ich verstehe einfach nicht, wie manche "Fans", sei es nVidia oder ATI,
sich so aufregen können. Einmal wird niemand gezwungen, den "Humus"
Tweak oder andere zu benutzen. Schließlich ist es ja nicht so, daß es
sich um irgendwas offizielles handelt.

Genau das gleiche ist ja dieses ganze Texture rumgetune. Es soll sogar Leute geben, die "image_downsize" einstellen und von der verbesserten Bildqualität
und Performance schwärmen. Das das objektiv nicht stimmt, daß ist ja egal,
solgange derjenige es auf seine eigene Verantwortung nimmt und damit
glücklich wird. ;)

Ich für meinen Teil habe z.B. eine 9500 Pro. Und am anfang lief Doom3 nicht
ganz so berauschent. Mittlerweile habe ich allerdings durch diverse Tweaks
(Humus, Cache, Normal Compression aus, OC'ing, 4.9b) mit 4xAF im timedemo
demo1 einen performancegewinn von ca. 25% in 800x600. bei selbsterstellten
timedemos teilweise sogar 45% mehr.

ok, 800x600 mag nicht jedermanns sache sein, und klar sieht der humus
tweak nicht orginal aus. Aber es sieht trotzallem gut aus, und diese "weißen"
Artefakte waren nur anfänglich vorhanden. Wenn man selbst ein bischen
rumtüftelt (was auch Spaß macht) kann man das ja auch selbst nachprüfen.

Also kurz um, mich hat niemand dazu gezwungen alle Tweaks zu benutzen,
da nichts von den Sachen offiziell ist. Ich bin bewußt kleine "Qualiverlußte"
beim Specularmapping eingegangen und für mich sind ca. 40% mehr
performance im schnitt ne feine sache. denn jetzt kann ich das spiel wirklich
ohne jegliche größere performanceeinbrüche spielen. Und so macht es mir
auch wirklich Spaß. Vorher war auf Grund der Performance der Eindruck
ein wenig getrübt. Und 640x480 ist mir auch zu winzig. ;)

just my 2 cents

[nggalai]

Antwort von JC:

I got a response from Carmack:

Quote:
Our specular function isn't a POW function, it matches the bias / scale calculations done on the NV10/NV20/R200 paths.


This of course explains why it doesn't look exactly the same. This is also a good thing. Now we don't even need to use a POW function, but we'll be fine with a MAD_SAT, which make it even faster. 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, but our fellow artifact hunters may want to verify that.
(Von Humus, auf B3D).

Hier sein "endgültiger" Mod:

Well, the full n00b guide (starting from unchanged shader) is to just change this,


# perform a dependent table read for the specular falloff
TEX R1, specular, texture[6], 2D;


into this,

# perform a dependent table read for the specular falloff
# TEX R1, specular, texture[6], 2D;
MAD_SAT R1, specular, 5.0, -4.0;


And that's it.
(Humus hatte gegenüber der Original-Post die MAD_SAT-Zeile noch etwas verändert, die Änderung ist in meiner Quote bereits mit drin.)

Der Reverend hat auch bei Carmack nachgefragt--Grund, weshalb er das im ARB2-Pfad nicht von Anfang an so gemacht hat war "Einheitlichkeit", insbesondere für die Designer. Wenn man sein Model fertig texturiert hat und die verschiedenen Renderpfade z.B. Specular verschieden darstellen, gibt's Schreikrämpfe. ;) Der Original-Code mit der Texture-Lookup ist die "sauberste" Lösung dafür, die Lösung mit MAD_SAT kommt der Original-Qualität jedoch recht nahe. Der Reverend hat genug Material von JC erhalten, um ein Quasi-Interview daraus zu basteln. Sollte heute oder morgen online gehen.

Der Tweak tut übrigens auch auf NV-Karten, allerdings wird's je nach Konfig etwas langsamer. i.e. try it out and see for yourself.

Tweak-Download:
http://esprit.campus.luth.se/~humus/temp/doom3PerformanceTweak.rar

93,
-Sascha.rb

[Demirug]

Antwort von JC:

Der Tweak tut übrigens auch auf NV-Karten, allerdings wird's je nach Konfig etwas langsamer. i.e. try it out and see for yourself.

93,
-Sascha.rb

Für nVidia Karten scheint der original Shader das optimum zu sein. OK wenn man in komplett umschreibt kann man vielleicht noch mehr rausholen aber nur kleine Veränderungen scheinen nichts zu bringen.

[Colin MacLaren]

Ohne Tweak: 63.3 fps
Humus: 65.3 fps
Humus + Coda + Demiurg: 65.5 fps. Ingame subjektiv mehr. Sehr schön :)

XP@2400MHz, 9800Pro, Cat 4.9Beta, 640x480, HighQuality

[radi]

Tweak-Download:
http://esprit.campus.luth.se/~humus/temp/doom3PerformanceTweak.rar

93,
-Sascha.rb

sind da jetzt alle dabei? oder nur der eine?

[Jesus]

Für nVidia Karten scheint der original Shader das optimum zu sein.

wie unerwartet ;)

[nggalai]

wie unerwartet ;)
Was allerdings eher Zufall ist. ;) Warten, bis der Artikel von Anthony online ist. Die Texture-Lookup-Version wie im Spiel per default mit dabei scheint die sauberste Lösung zu sein. Die Lösung oben ist nicht 100% äquivalent.

93,
-Sascha.rb

[reunion]

wie unerwartet ;)

Wollte ich auch gerade loswerden :flöt:
Achja, und wie war das noch schnell mit "Wie wir noch sehen werden, hat John Carmack eine Glanzleistung vollbracht, was die Optimierung auf Radeon-Karten angeht"?

[nggalai]

Wollte ich auch gerade loswerden :flöt:
Achja, und wie war das noch schnell mit "Wie wir noch sehen werden, hat John Carmack eine Glanzleistung vollbracht, was die Optimierung auf Radeon-Karten angeht"?
Lies mein Posting nochmals. Um mit dem "Hack" wirklich äquivalente Bildqualität hinzukriegen, müsste die Engine pro Model noch eine Konstante fürs Specular mitgeben. Das wär auch wieder zusätzlicher Aufwand. Die Lösung über den Texture-Lookup ist einfach eleganter und funktioniert mit weniger Problemen.

Zuerst über PP im ehemaligen NV3x-Pfad motzen, und dann ist was recht Ähnliches plötzlich eine sinnvolle Optimierung? O.o

Meint ihr echt, ATI hätte über die letzten 3 Jahre nicht Vorschläge zu den Shadern gemacht?

93,
-Sascha.rb

[Unregistrier]

Wollte ich auch gerade loswerden :flöt:
Achja, und wie war das noch schnell mit "Wie wir noch sehen werden, hat John Carmack eine Glanzleistung vollbracht, was die Optimierung auf Radeon-Karten angeht"?


Hat er doch auch, oder zählen qualitätsverringernde Tweaks jetzt schon zu Optimierungen??

[Demirug]

nggalai, zudem will ich nicht aussschliessen das der Shadercompiler im Treiber bei dem von D3 verwendeteten Shader optimalen Code erzeugt. Wenn man die Struktur verändert kann das eben suboptimal laufen.

Bevor jetzt wieder jemand anfängt. Ich meine aber kein Shaderreplacement im üblichen Sinn.

[Unregistrier]

Zuerst über PP im ehemaligen NV3x-Pfad motzen, und dann ist was recht Ähnliches plötzlich eine sinnvolle Optimierung? O.o




naja, für fanboys keine unübliche verhaltensweise

[reunion]

Lies mein Posting nochmals. Um mit dem "Hack" wirklich äquivalente Bildqualität hinzukriegen, müsste die Engine pro Model noch eine Konstante fürs Specular mitgeben. Das wär auch wieder zusätzlicher Aufwand. Die Lösung über den Texture-Lookup ist einfach eleganter und funktioniert mit weniger Problemen.

Zuerst über PP im ehemaligen NV3x-Pfad motzen, und dann ist was recht Ähnliches plötzlich eine sinnvolle Optimierung? O.o

Meint ihr echt, ATI hätte über die letzten 3 Jahre nicht Vorschläge zu den Shadern gemacht?

93,
-Sascha.rb

Hat er doch auch, oder zählen qualitätsverringernde Tweaks jetzt schon zu Optimierungen??

Okay, Okay, sry, war da wohl etwas zu voreilig :D
Wenn die BQ verschlechtert wird ist das natürlich nicht zu befürworten...

[ATi]

also ich kann mit dem tweak nirgends mehr connecten ? funktioniert der tweak nur fürn solo ?
ich habe meine "interaction.vfp" selbst editiert u. eine fertige genommen. mit keiner der beiden kann ich im mp connecten. tweak rückgängig gemacht u. es funkt ohne probleme ?

[Hiro Hiroshi]

also ich kann mit dem tweak nirgends mehr connecten ? funktioniert der tweak nur fürn solo ?
ich habe meine "interaction.vfp" selbst editiert u. eine fertige genommen. mit keiner der beiden kann ich im mp connecten. tweak rückgängig gemacht u. es funkt ohne probleme ?

http://members.chello.at/guilty/upload/ati-tweak_fehler.gif

ich glaube das liegt am 4.9 beta Treiber.

[Jesus]

hab den tweak eben mal getestet, bringt mich von 20.8 auf 22.5 fps in 1280x1024 high details 2xAA

BQ scheint gleich geblieben zu sein, zumindest ist mir bisher noch nix aufgefallen.

[nggalai]

nggalai, zudem will ich nicht aussschliessen das der Shadercompiler im Treiber bei dem von D3 verwendeteten Shader optimalen Code erzeugt. Wenn man die Struktur verändert kann das eben suboptimal laufen.

Bevor jetzt wieder jemand anfängt. Ich meine aber kein Shaderreplacement im üblichen Sinn.
Ja. Ausserdem müsste Humus' Ersatz-Shader für "genaueres" Abbild des Gewollten noch z.B. über einen MAD_SAT normalisiert werden -> mehr Anweisungen im Shader -> eventuell Speedreduktion.

Zur Bildqualität: Da gehen die Meinungen auseinander. Manche sehen keine Fehler, andere haben Artefakte wie blöde. Helligkeitsverhältnisse stimmen so oder so nicht, z.B. ist die Lampe zu dunkel. Als Spieledesigner wirst Du kaum eine Engine so zusammenbauen, dass die Hälfte der Leute dann beim Grafikkartenhersteller nach neuen Treibern schreit. ;) Ausserdem kann man mit einer handvoll Screenshots nicht abschätzen, ob's nicht doch mal wo ein Darstellungsproblem gibt. Die Engine soll auch lizenziert werden; nur weil mit den "richtigen" Settings im Ersatz-Shader DooM3 auf den ersten Blick ohne Fehler gerendert wird, muss das bei anderem Content noch lange nicht so sein. Dazu bräuchte man einen echten äquivalenten Shader.

Aber hoffentlich wird das JC-Interview das besser erklären.

Zum Connect-Problem: MP tut nur, wenn die pak-Files unverändert bleiben. Ist als Cheat-Protection drin.

93,
-Sascha.rb

[Jesus]

Als Spieledesigner wirst Du kaum eine Engine so zusammenbauen, dass die Hälfte der Leute dann beim Grafikkartenhersteller nach neuen Treibern schreit. ;)

ist doch schon so. Deshalb gibts ja den Cat 4.9b, wegen den Darstellungsfehlern bei den Schatten.

[nggalai]

... was aber kein Engine-Fehler war, sondern ein einfacher Bug im Treiber. Vorwiegend wurde die Beta des Treibers allerdings wegen der Performance freigegeben. Geplant war eigentlich Mitte September für das Ding.

93,
-Sascha.rb

[Jesus]

also seh ich das richtig ( lt. CB artikel ) ist die Engine zwar auf Radeon Karten optimiert, aber noch auf dem Stand des R200 ? Was dem R3xx / R 420 gar nicht schmeckt ?

Wenn ja, dann sollte 3dc (aths ) mal seinen Artikel "überarbeiten .

[nggalai]

also seh ich das richtig ( lt. CB artikel ) ist die Engine zwar auf Radeon Karten optimiert, aber noch auf dem Stand des R200 ? Was dem R3xx / R 420 gar nicht schmeckt ?
Der ARB2-Pfad wurde allgemein gehalten, auch wegen zukünftiger Grafikchips. Die Engine soll ja ein paar Jahre halten. In Sachen ATI orientiert sich der Pfad an der R3xx; DooM3 hat einen eigenen R200-Pfad.

Schlussendlich ist ARB2 für alle Grafikchips ein "Kompromiss", eben weil er nicht hardcore auf eine Architektur ausgelegt werden kann. Carmack geht zuerst vom Optischen aus, i.e. wie kriege ich das so hin, visuell, wie ich's möchte? OK, so geht's, jetzt in einer Form implementieren, dass alle Karten damit sauber klar kommen und's auch bei anderem Content als DooM3 noch tut. Und jetzt schaun wir mal, wie ich die Performance allgemein verbessern kann, ohne dass die Qualität darunter leidet.

Aber ohne Grund werden die Shader wohl nicht in Textform beigelegt worden sein. ;) Modding ist hier klar gewollt; JC hat auch nix gegen Humus' Veränderungen. Aber er hat technische Gründe, weshalb er das nicht von vorn herein so gemacht hat. Wieder auf den Patch bezogen wären das die Probleme, welche auch auf ATI einige Leute nach der Änderung haben. Um diese Probleme allgemeingültig aus dem Weg zu schaffen, müsste der augewechselte Shader wohl etwas komplizierter ausfallen -> warscheinlich langsamer als die gewählte Methode. Oder aber Carmack dürfte einen zusätzlichen Render-Pfad einbauen, welcher dann auch gepflegt und dokumentiert werden muss--der NV3x-Pfad ist aus gutem Grund rausgefallen, als NV mit den Treibern so weit war, dass NV3x mit ARB2 gleich schnell war. Einfach weniger Aufwand, auch für die Lizenznehmer.

/edit: Und genau darum geht's ja im 3DCenter-Artikel. NV wird nicht extra-besser unterstützt als ATI, sondern hat einfach die "passendere" Architektur, um die Konzepte hinter DooM3 besser auszuführen. Am Code selbst liegt das nur sekundär.

93,
-Sascha.rb

[q@w]

also seh ich das richtig ( lt. CB artikel ) ist die Engine zwar auf Radeon Karten optimiert, aber noch auf dem Stand des R200 ? Was dem R3xx / R 420 gar nicht schmeckt ?

Welcher CB-Artikel genau?

q@w

[Demirug]

Ja. Ausserdem müsste Humus' Ersatz-Shader für "genaueres" Abbild des Gewollten noch z.B. über einen MAD_SAT normalisiert werden -> mehr Anweisungen im Shader -> eventuell Speedreduktion.

93,
-Sascha.rb

Ein _SAT ist eigentlich meist ohne Performancereduktion zu haben. Wobei ich mir aber immer noch nicht sicher bin ob in der Textur nicht doch was komplizierteres ist. Bisher hat ja niemand den Inhalt dieser Texture öffentlich gemacht.

[Jesus]

Welcher CB-Artikel genau?

q@w

der hier von gestern http://www.computerbase.de/news/hardware/grafikkarten/ati/2004/august/neues_doom_3hotfix_atikarten/

[nggalai]

Ein _SAT ist eigentlich meist ohne Performancereduktion zu haben. Wobei ich mir aber immer noch nicht sicher bin ob in der Textur nicht doch was komplizierteres ist. Bisher hat ja niemand den Inhalt dieser Texture öffentlich gemacht.
Ja, das ist ein Problem.

Der aktuelle Vorschlag ausm B3D-Forum sieht z.Z. so aus:

MUL R1, specular, specular;
MAD_SAT R1, R1, 3.0, -2.0;

Die Werte beim MAD_SAT müssten noch getweakt werden. Humus schlägt 5.0, -4.0 vor.

93,
-Sascha.rb

[Demirug]

Ja, das ist ein Problem.
Die Werte beim MAD_SAT müssten noch getweakt werden. Humus schlägt 5.0, -4.0 vor.

93,
-Sascha.rb

Meine Hervorhebung.

Entweder prüft jetzt mal endlich jemand nach was die texture macht oder man lässt die raterei. Das ist doch kein professioneles arbeiten.

*sorry ist wohl einfach zu heiss*

[q@w]

der hier von gestern http://www.computerbase.de/news/hardware/grafikkarten/ati/2004/august/neues_doom_3hotfix_atikarten/

Tut mir leid, die Stelle muss ich überlesen haben - könntest du mir noch genau sagen, wo es steht, daß:
[...]( lt. CB artikel ) [...]die Engine zwar auf Radeon Karten optimiert [ist], aber noch auf dem Stand des R200 ? Was dem R3xx / R 420 gar nicht schmeckt ?

[FireFrog]

Hi,
ich möchte hier nicht alles lesen, was gibts bisher sachen die echt helfen ?

[del_4901]

Meine Hervorhebung.

Entweder prüft jetzt mal endlich jemand nach was die texture macht oder man lässt die raterei. Das ist doch kein professioneles arbeiten.

*sorry ist wohl einfach zu heiss*


die *.txt is ne *.rar , ich glaube mal das das die Texturen sind, von denen wir sprechen. nen dds viewer wirste ja haben, nehm ich mal an. (PS Plugin gibs bei NV)

[Chris Lux]

Entweder prüft jetzt mal endlich jemand nach was die texture macht oder man lässt die raterei. Das ist doch kein professioneles arbeiten.


hier die LUT, welche für alle shader im kompletten frame genutzt wurde.

http://img9.exs.cx/img9/7273/Image_2D_0007_0044.png

hier nochmal ein direkter link zu dem png:
(http://img9.exs.cx/img9/7273/Image_2D_0007_0044.png)

hier der frame dazu:
http://img9.exs.cx/img9/7612/shot00004.th.jpg (http://img9.exs.cx/my.php?loc=img9&image=shot00004.jpg)

[Chris Lux]

die *.txt is ne *.rar , ich glaube mal das das die Texturen sind, von denen wir sprechen. nen dds viewer wirste ja haben, nehm ich mal an. (PS Plugin gibs bei NV)

sorry, da ist die LUT die verwendet wird ned dabei. in meinem post ist sie direkt beim laufenden betrieb genommen worden.

p.s. ich hoffe nur, dass ich da nix verbotenes getan habe mit der textur, den gl log poste ich ja nicht mit...?

[del_4901]

sorry, da ist die LUT die verwendet wird ned dabei. in meinem post ist sie direkt beim laufenden betrieb genommen worden.

p.s. ich hoffe nur, dass ich da nix verbotenes getan habe mit der textur, den gl log poste ich ja nicht mit...?

Doch ist sie. Es ist die Flashoff.dds ... Bei Doom3 wird Red und Alpha geswappt, ich hab mir mal die Mühe in Photoshop gemacht und mit deinem PNG verglichen -> 100% übereinstimmung über's letze virtel, davor is eh alles nur weiß ;)

[Demirug]

AlphaTier & Chris Lux, danke euch beiden.

Aufgrund des Graphen in der LUT liegt Humus weit daneben. Um genau zu sein hat er sogar den falschen Ansatz gewählt. Den neuen Shader mit der korrekten Implementierung gibt es im Verlauf der nächsten Stunde.

[Chris Lux]

Doch ist sie. Es ist die Flashoff.dds ... Bei Doom3 wird Red und Alpha geswappt, ich hab mir mal die Mühe in Photoshop gemacht und mit deinem PNG verglichen -> 100% übereinstimmung über's letze virtel, davor is eh alles nur weiß ;)

sorry, aber das sehe ich gar nicht so. deines ist eine rampe von weiss nach schwarz (links nach rechts). die LUT aus dem game geht von schwarz nach weiss und dass auch nur ganz kurz am ende. deines ist eine lineare rampe, das aus dem game sieht exponentiell aus. sorry, aber ich habe es auch gerade nochmal verglichen (siehe anhang). vor allem deutet der name flashoff schon darauf hin, dass es sich um den falloff der taschenlampe handelt.

[Cpl. Dwayne Hicks]

AlphaTier & Chris Lux, danke euch beiden.

Aufgrund des Graphen in der LUT liegt Humus weit daneben. Um genau zu sein hat er sogar den falschen Ansatz gewählt. Den neuen Shader mit der korrekten Implementierung gibt es im Verlauf der nächsten Stunde.

hi du!

kannst du wenn du fertig bist einen link zu dem von dir optimierten und endgültigen shader posten?

Weil so langsam blick ich nicht mehr durch welcher shader denn nun schneller ist, welcher schlechter aussieht und welcher langsamer ist.... :(
Weil es gibt auch noch leute die nicht wissen was LUT, SAT und POW lookup usw. bedeuten! ;)

[Chris Lux]

Weil es gibt auch noch leute die nicht wissen was LUT, SAT und POW lookup usw. bedeuten! ;)

LUT - LookUp Table
SAT - saturate (dh der wert wird nicht größer als 1, also ab 1 ist er gesättigt)
POW - power (dh, x hoch y)

[Demirug]

hi du!

kannst du wenn du fertig bist einen link zu dem von dir optimierten und endgültigen shader posten?

Es gibt leider nicht den einen entgültigen Shader.

Es sind zwei Stellen die man ändern kann. Für die eine Stelle davon gibt es dann noch zwei Varianten. Welche Kombination bei welchen Settings auf welcher Karte ob und überhaupt was bringt kann ich nicht vorhersagen.

[Cpl. Dwayne Hicks]

LUT - LookUp Table
SAT - saturate (dh der wert wird nicht größer als 1, also ab 1 ist er gesättigt)
POW - power (dh, x hoch y)

toll....



Wenn du drei wörter Finnisch kennst kannst du dann automatisch Finnisch sprechen?! ;)
das mögen die vokabeln sein... aber ohne grammatik hat man immernoch keine sprache. ;)

EDIT:

ich war zu langsam...

Danke Demirug!

[Chris Lux]

toll....
Wenn du drei wörter Finnisch kennst kannst du dann automatisch Finnisch sprechen?! ;)
das mögen die vokabeln sein... aber ohne grammatik hat man immernoch keine sprache. ;)



hallo? du wolltest wissen was es bedeutet. wenn es um shader und deren replacement geht sollte man sich halt SEHR genau mit deren technik und anwendung auskennen, das ist keine game config wo man mal schnell n script bauen kann. das ist low level grafikprogrammierung, sorry!
edit: vor allem auch mit den mathematischen grundlagen (pow, sat) und grundlegenden techniken der computertechnik (lut)!

you made my day :arsch:

so bitte nochmal, dass ich geholfen habe!

[del_4901]

Mhm, naja lag wohl doch etwas daneben, im Anhang ein psd, der falloff layer ist schon auf difference gestellt in der mitte des schwarzen balkens gibt es unterschiede (mit der Pipette abchecken). Wenn falloff die Lineare Fkt repräsentiert, dann is die Tex aud der LUT bestimmt die Exponentielle zw. -4 und 1 (geschätzt)

[del_4901]

Chris check mal deine PMs

[Cpl. Dwayne Hicks]

so bitte nochmal, dass ich geholfen habe!


nö nix mit bitte, du hast nämlich garnicht geholfen! :arsch:

Ich wollte halt nie wissen was es heisst, das war doch nur rhetorik.... denn wiegesagt was würde es mir ohne weiteres hintergrundwissen bringen wenn ich weiss wofür die einzelnen abkürzungen stehen?!

Gerade weil ich keine ahnung von lowlevel programmieren habe ich hier erstmal nachgefragt und den thread eröffnet.... aus keinem anderen grund.

naja war jedenfalls nicht so gemeint von mir, ich weiss du hast es nur gut gemeint mein kind. :D

[Demirug]

So dann wollen wir mal:

Variante 1:

Original:

# perform a dependent table read for the specular falloff
TEX R1, specular, texture[6], 2D;

Neu:

# perform a dependent table read for the specular falloff
SUB_SAT R1, specular, 0.75;
MUL R1, R1, R1;
MUL_SAT R1, R1, 16.0;

Variante 2:

Original:
# perform a dependent table read for the specular falloff
TEX R1, specular, texture[6], 2D;

# modulate by the constant specular factor
MUL R1, R1, program.env[1];

Neu:
# perform a dependent table read for the specular falloff

SUB_SAT R1.x, specular.x, 0.75;
MUL R1.x, R1.x, R1.x;
MUL_SAT R1.x, R1.x, 16.0;

# modulate by the constant specular factor
MUL R1, R1.x, program.env[1];

Wenn der Shadercompiler im Treiber was taugt könnte Variante 2 schneller sein.

Die Änderung mit dem normalisieren des Vektors kann man optinial auch noch einfügen. Man sollte ausprobieren was am besten für einen selbst funktioniert. Das könnte auch der Originalshader sein.

[Jesus]

Tut mir leid, die Stelle muss ich überlesen haben - könntest du mir noch genau sagen, wo es steht, daß:

Using a dependent texture lookup for POW evaluation makes a lot of sense for R200 level hardware due to instruction set limits, but for R300 and up it's much better to just spend the three cycles it takes to evaluate POW with math instead of risking texture cache trashing with a dependent texture read, ...

John Carmack scheint in diesem Falle also einmal weniger gute Arbeit geleistet zu haben, als wir es von ihm gewohnt sind.

naja eher auf den quote bezogen ;)

[Chris Lux]

@Demirug:

postest du das auch im beyond3D forum? mal schauen was die tester dort dann sagen.

[Quasar]

naja eher auf den quote bezogen ;)

Ahhhhh-so, danke. =)
Ich dachte schon, du meintest das so, wie du es geschrieben hast. ;)

[Demirug]

@Demirug:

postest du das auch im beyond3D forum? mal schauen was die tester dort dann sagen.

Kann ich machen.

[del_4901]

Timedemo _1_/_2_
original: 39.9 / 55.5
varia1: 38.7 / 42.4
varia2: 38.6 / 42.4

Graka: NV35
Im Anhang meine Cfg

@Demi optimier mal pls für den NV35 ;)

[Jesus]

Ahhhhh-so, danke. =)
Ich dachte schon, du meintest das so, wie du es geschrieben hast. ;)

ich habe geschrieben :

also seh ich das richtig ( lt. CB artikel ) ist die Engine zwar auf Radeon ... ? ;)

was, wie man sieht, eine Frage ist...

[Chris Lux]

So dann wollen wir mal:


bei mir (9800pro 256mb omega 4.7) keine verbesserung, aber auch keine verschlechterung in der timedemo. im spiel fühlte sich deine variante langsamer an. visuelle unterschiede konnte ich auf anhieb nicht ausmachen in der testszene.

[Demirug]

bei mir (9800pro 256mb omega 4.7) keine verbesserung, aber auch keine verschlechterung in der timedemo. im spiel fühlte sich deine variante langsamer an. visuelle unterschiede konnte ich auf anhieb nicht ausmachen in der testszene.

Da kann ich leider nichts daran ändern. Die 3 Zeilen sind nun mal ein korrekte Replacement für die LUT.

Es kann aber gerne jemand versuchen sat(16*(sat(specular-0.75))^2) auf anderem Weg in den Shader zu bekommen. Mir ist keine kürzere Möglichkeit eingefallen.

[Mumins]

Mit Variante 2 Cat. 4.9b 1024x768 High Detail 45,2 , ohne Optimierung 43,3.

[Chris Lux]

Da kann ich leider nichts daran ändern. Die 3 Zeilen sind nun mal ein korrekte Replacement für die LUT.

Es kann aber gerne jemand versuchen sat(16*(sat(specular-0.75))^2) auf anderem Weg in den Shader zu bekommen. Mir ist keine kürzere Möglichkeit eingefallen.

;) das war keine kritik. nur jetzt sieht man was sich john carmack bei der LUT gedacht hat. wer weiss ob er im ganzen spiel die selbe lut verwendet...

[del_4901]

also ich hab mal alles durchgebenched, auch die Optis, die carmi selber scho im shader vermerkt hat. Die Orginale ist mit 10fps Abstand die schnellste.

[Demirug]

;) das war keine kritik. nur jetzt sieht man was sich john carmack bei der LUT gedacht hat. wer weiss ob er im ganzen spiel die selbe lut verwendet...

Niemand aber laut der Aussage bei B3d ist die LUT ja dazu da das Verhalten der GF1-4 nachzubilden. Da würde es nicht viel sinn machen mehr als eine zu haben.

[Quasar]

ich habe geschrieben :



was, wie man sieht, eine Frage ist...

Dann liegst du wohl falsch - der CB-Artikel hat nur die Meinung von Humus wiedergegeben - wie durch das "QUOTE" kenntlich gemacht. ;)

[Chris Lux]

Niemand aber laut der Aussage bei B3d ist die LUT ja dazu da das Verhalten der GF1-4 nachzubilden. Da würde es nicht viel sinn machen mehr als eine zu haben.

achja stimmt, hab ich wohl schon wieder vergessen ;)

die hitze, die hitze... oder ich bin einfach zu früh auf heut ;)

[Jesus]

Dann liegst du wohl falsch - der CB-Artikel hat nur die Meinung von Humus wiedergegeben - wie durch das "QUOTE" kenntlich gemacht. ;)

wieso ? ist doch genau das was hier alle tun. Den shader für den r3xx optimieren weil dieser "suboptimal" läuft, bzw. eher für NV optimiert zu sein scheint ( lt. demi ).

btw den Kommentar von CB zu dem Quote nicht vergessen ;)

[VoodooJack]

Mühsam nährt sich das Eichhörnchen, aber ein bisschen was bringt der HumusTweak schon bei mir.

X800 XTPE, beta 4.9 + HumusTweak

timedemo trdemo2 (von TechReport)

1280x1024, Ultra Quality, noAA: 103.1 fps (96.5 fps)
1280x1024, Ultra Quality, 4xAA: 72.2 fps (68.4 fps)

1600x1200, Ultra Quality, 4xAA: 53.7 fps (51.8 fps)

(in Klammern ohne HumusTweak)

[Mr. Lolman]

Hm...

1024x768 High Quality 2xAA 4x App.AF Cat.4.9Beta, demo1:

original 37.3fps
demi1 37.7fps
humus 38.8fps
demi2 38.8fps

AMD XP2400+ @ 2.4GHz / ABIT NF7-S / ATI Radeon 9700 PRO BBA @400/350 / 1GB TwinMos PC3200 CL2.5 @ 2-3-2-11

[r@h]

Also ich habe aus dem B3D-Forum zumindest gelernt, dass man das AF nicht via CP forcen sollte.

Hier mal ein Beispiel meines Rechners:

- 2xAA CP / 4°AF CP = 37,8fps
- 2xAA App / 4°AF CP = 37,8fps
- 2xAA CP / 4°AF App = 40,7fps
- 2xAA App / 4°AF App = 40,7fps

Ergo:

4°AF via CFG und im Treiber auf 'application' bringt satte 7,7%...
...ganz ohne Shader-Replacement!
:D

Und ach ja, hier vielleicht noch was für die NV40-Shader-Modder aus dem B3D-Forum:
http://www.beyond3d.com/forum/viewtopic.php?t=14874&postdays=0&postorder=asc&start=460
(letzter Post ;-)
And for NV30 / NV40 owners, there is another section of interaction.vfp that you may wish to try changing. This code :
# load the specular half angle first, because
# the ATI shader gives a "too many indirections" error
# if this is done right before the texture indirection

#-----------------
#TEX specular, fragment.texcoord[6], texture[0], CUBE;
#MAD specular, specular, scaleTwo, subOne;


# instead of using the normalization cube map, normalize with math
DP3 specular, fragment.texcoord[6],fragment.texcoord[6];
RSQ specular, specular.x;
MUL specular, specular.x, fragment.texcoord[6];
#----------------- .... uses math to do normalization. If you enable the texture-lookup version instead, seeing as how the Nvidia architectures seem to do better with texture ops in Doom 3, there may be an improvement to be found. Indeed, judging by the comment attached to this code it looks like the math version was enabled because of a error/warning on the part of the ATI driver when id Software wrote this shader.

Hab's selber noch nicht ausprobiert...
Na? Wer will mal daran?
;-)

Razor

P.S.: Und nein, es ist kein Versuch, gegen ATI zu flamen...

[del_4901]

Also ich habe aus dem B3D-Forum zumindest gelernt, dass man das AF nicht via CP forcen sollte.

Hier mal ein Beispiel meines Rechners:

- 2xAA CP / 4°AF CP = 37,8fps
- 2xAA App / 4°AF CP = 37,8fps
- 2xAA CP / 4°AF App = 40,7fps
- 2xAA App / 4°AF App = 40,7fps

Ergo:

4°AF via CFG und im Treiber auf 'application' bringt satte 7,7%...
...ganz ohne Shader-Replacement!
:D

Und ach ja, hier vielleicht noch was für die NV40-Shader-Modder aus dem B3D-Forum:
http://www.beyond3d.com/forum/viewtopic.php?t=14874&postdays=0&postorder=asc&start=460
(letzter Post ;-)


Hab's selber noch nicht ausprobiert...
Na? Wer will mal daran?
;-)

Razor

P.S.: Und nein, es ist kein Versuch, gegen ATI zu flamen...

schon ausprobiert, ist 10fps langsamer, und mit der reihenfolge der anweisungen hat's niks zu tun, wenn ich in der originalen nur spec und diffuse calc tausche bleiben die Fps gleich, irgendwas ist da bei der Spec berrechnung, was unter verwendung einer Cubemap den Shader langsamer macht (auf NV35 HW)

[Demirug]

Hm...

1024x768 High Quality 2xAA 4x App.AF Cat.4.9Beta, demo1:

original 37.3fps
demi1 37.7fps
humus 38.8fps
demi2 38.8fps

AMD XP2400+ @ 2.4GHz / ABIT NF7-S / ATI Radeon 9700 PRO BBA @400/350 / 1GB TwinMos PC3200 CL2.5 @ 2-3-2-11

Hat bei dir die zweite Variante einen Rotstich verursacht? Bei b3d hatte damit jemand probleme.

[Demirug]

schon ausprobiert, ist 10fps langsamer, und mit der reihenfolge der anweisungen hat's niks zu tun, wenn ich in der originalen nur spec und diffuse calc tausche bleiben die Fps gleich, irgendwas ist da bei der Spec berrechnung, was unter verwendung einer Cubemap den Shader langsamer macht (auf NV35 HW)

Der Vektor beim spekularen Licht ist nicht sonderlich Texturecachefreundlich. nVidia hat das mal untersucht. Es ist also durchaus möglich das dieses zusätzliche (aufwendige) sample den Shader in ein (stärkeres) Bandbreite/Fillrate Limit treibt.

[Quasar]

wieso ? ist doch genau das was hier alle tun. Den shader für den r3xx optimieren weil dieser "suboptimal" läuft, bzw. eher für NV optimiert zu sein scheint ( lt. demi ).

btw den Kommentar von CB zu dem Quote nicht vergessen ;)
Wenn du den Urheber einer Aussage nicht von einem Kolporteur derselben unterscheiden kannst, lade ich dich herzlich ein, diese Unterscheidung im Off-Topic-Forum weiterzudiskutieren. ;)

[Jesus]

oh mann , es geht mir doch nicht darum wer das geschrieben hat, sondern wo es gepostet wurde. Ich bin kein Forenjunkie der in 100 verschiedenen Foren 24 Stunden am Tag aktiv ist daher hab ich keine andere Quelle ( wie z.b. b3d ) für diese Aussage gefunden ( und auch nicht danach gesucht sondern den erstbesten Link genommen den ich hier gefunden habe).

Aber gut zu wissen dass du weisst dass das alles völlig OT ist ;)

[Korak]

Könnt ihr diese Sticheleien und dieses OT-Geblubber nicht mal lassen?

[Demi ohne Keks]

So langsam ergibt sich ja doch ein Bild.

Könnten bitte mal alle die hier fleissig mitgebencht haben überprüfen ob sie über das CP AF erzwungen haben?

Ich frage aus dem grund weil es langsam offensichtlich wird das DOOM III von sich aus entscheidet welche Texturen AF bekommen sollen und welche nicht. Die LUT welche von Humus (und dann später auch von mir) durch eine mathematische Funktion ersetzt wurde gehört nun mit an Sicherheit grenzender Wahrscheinlichkeit zu der Gruppe welche von DOOM III kein AF bekommt. Für eine LUT ist das ja auch eigentlich nicht notwendig. Wenn man aber nun über das CP das AF erzwingt bekommt auch die LUT AF. Da es ein dependet Read ist der gerne streut kommt es da dann wohl auch gerne zum Einsatz von viel AF. In diesem Fall ist es natürlich günstiger zu rechnen als zu samplen und die Tweaks bringen Mehrleistung. Würde die Texture aber so wie es DOOM III will gar kein AF bekommen ist die Rechnung schnell aufweniger bzw entlastet die Karte kaum. Ergo kein Performancegewinn.

Die ganze Fummelei war daher wohl umsonst. Aus Technischer Sicht hat es mir aber trotzdem ein wenig Spass gemacht.

Also an alle DOOM III Spieler der Tip: Lässt das Game selbst das AF einstellen denn es weiss was es tut. Das CP ist blöd und verteilt die Fillrate an alle texturen.

[nggalai]

wieso ? ist doch genau das was hier alle tun. Den shader für den r3xx optimieren weil dieser "suboptimal" läuft, bzw. eher für NV optimiert zu sein scheint ( lt. demi ).
;)
Nur ist leider der äquivalent-optimierte Shader praktisch gleichschnell wie das Original, manchmal etwas schneller, häufig etwas langsamer. So oder so ist er umständlicher, insbesondere da er im besten Fall nur wenig bringt und andere Hardware, welche den selben Pfad verwendet, ausbremsen könnte.

Nochmals: Das hat mit "eher für NV optimiert" nichts zu tun.

93,
-Sascha.rb

[InsaneDruid]

Also ich kann zumindest bestätigen das AF via APP schneller ist als AF via CP. Selbst höhere Stufen in app angefordert waren (leicht) schneller als niedrigere via CP. Genaue Zahlen hab ich nicht (mehr), aber könnte sie nachliefern.. von ner 9800pro128MB

[nggalai]

Also ich kann zumindest bestätigen das AF via APP schneller ist als AF via CP. Selbst höhere Stufen in app angefordert waren (leicht) schneller als niedrigere via CP. Genaue Zahlen hab ich nicht (mehr), aber könnte sie nachliefern.. von ner 9800pro128MB
Das dürfte selbstverständlich sein. Genau deswegen bin ich seit Jahren kategorisch gegen AF-Settings über den Treiber resp. das Kontrollpanel. Nur der Entwickler / Designer weiss, welche Texturen wie viel AF benötigen.

93,
-Sascha.rb

[advman]

Das dürfte selbstverständlich sein. Genau deswegen bin ich seit Jahren kategorisch gegen AF-Settings über den Treiber resp. das Kontrollpanel. Nur der Entwickler / Designer weiss, welche Texturen wie viel AF benötigen.
Das Problem ist nur, dass die IQ mit per Control Panel forciertem AF deutlich besser ist, zumindest bei meiner 9800pro mit Cat4.9beta.

Siehe http://www.beyond3d.com/forum/viewtopic.php?p=343851#343851

Darum die Frage auch hier: Kann mal jemand mit einer Nvidia nachprüfen, ob es dort auch einen Qualitätsunterschied zwischen applikationsgesteuertem und forciertem AF gibt?

[InsaneDruid]

Forderst du mit Doom3 auch Trilinear an oder nur bi?

(seta image_filter "GL_LINEAR_MIPMAP_LINEAR" oder seta image_filter "GL_LINEAR_MIPMAP_NEAREST" ?)

[Mr. Lolman]

Hat bei dir die zweite Variante einen Rotstich verursacht? Bei b3d hatte damit jemand probleme.

Nö, funzt bei mir wunderbar.

1024 HQ, 2xAA 4xQuality AF(CP) mitsamt dem neuesten Cat. ist mittlerweile so flott wie die selben Einstellungen nur mit Performance AF, nämlich 38.4fps beim Demo1. (und Cat 4.7)

[Mr. Lolman]

Forderst du mit Doom3 auch Trilinear an oder nur bi?

(seta image_filter "GL_LINEAR_MIPMAP_LINEAR" oder seta image_filter "GL_LINEAR_MIPMAP_NEAREST" ?)

"GL_LINEAR_MIPMAP_LINEAR" bringt bei mir TS "optmiertes" AF. D.h. bi-AF auf irgendwelchen Texturstages. Wundert mich, dass das noch niemand bemerkt hat, wo doch ohnehin so viele hochsensibilierte AF Meister sich im 3D Center herumtreiben :D:D:D

Nur mittels, übers Controlpanel geforctes, Quality AF wird auch 'trilinear' anisotrop gefiltert.

[tEd]

Hat bei dir die zweite Variante einen Rotstich verursacht? Bei b3d hatte damit jemand probleme.

ja es tut mir leid ich hab einen copy/paste fehler gemacht darum der rotstich. Es funktionieren jetzt beide versionen bei mir

ich bin der b3d typ mit dem rotstich ;)

[Vulkanette]

Kann diese AF-Geschichte hiermit was zu tun haben ?

---

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

Hallo,

habe mit meiner X800 Pro da eine Beobachtung gemacht, evtl. ist es aber auch eine Eintagsfliege gewesen:

Also bei D3 High einstellen. Dann gibts bekanntlich 0xAA 8xAF.
Im ATI-Tool beides auf 0 gesetzt. Benchmark ~50fps (1280x1024)
Dann per Hand in der Doomdings.cfg den Antisothropic Wert von 8 auf 0 gesetzt. Benchmark 38 fps :(
Wieder zurückgesetzt und schwups ~50 fps.

Ist mir nicht ganz klar warum AF mehr FPS gibt als mit ohne.

[r@h]

Das dürfte selbstverständlich sein. Genau deswegen bin ich seit Jahren kategorisch gegen AF-Settings über den Treiber resp. das Kontrollpanel. Nur der Entwickler / Designer weiss, welche Texturen wie viel AF benötigen.Und ganu deswegen lassen viele, viele Engines die Einstellung des AF-Levels über das Menü (wie übrigens Doom3 auch!) gar nicht erst zu?
Sehr interessant...

Razor

[r@h]

Forderst du mit Doom3 auch Trilinear an oder nur bi?

(seta image_filter "GL_LINEAR_MIPMAP_LINEAR" oder seta image_filter "GL_LINEAR_MIPMAP_NEAREST" ?)Default ist trilinear, wenn man "High-Details" gewähl hat...
Die Frage sollte also anders lauten: "Forcierst Du etwa bi?"
;-)

Razor

[r@h]

"GL_LINEAR_MIPMAP_LINEAR" bringt bei mir TS "optmiertes" AF. D.h. bi-AF auf irgendwelchen Texturstages. Wundert mich, dass das noch niemand bemerkt hat, wo doch ohnehin so viele hochsensibilierte AF Meister sich im 3D Center herumtreiben

Nur mittels, übers Controlpanel geforctes, Quality AF wird auch 'trilinear' anisotrop gefiltert.Tjo... nur ist dies bei mir (umd damit meiner FX) nicht der Fall.
Du solltest also besser schreiben, dass es Dich wundert, warum noch keiner der ATI-User dies bemerkte...
...was mich wiederum überhaupt nicht wundert.
:D

Razor

[Chris Lux]

"GL_LINEAR_MIPMAP_LINEAR" bringt bei mir TS "optmiertes" AF. D.h. bi-AF auf irgendwelchen Texturstages. Wundert mich, dass das noch niemand bemerkt hat, wo doch ohnehin so viele hochsensibilierte AF Meister sich im 3D Center herumtreiben :D:D:D

Nur mittels, übers Controlpanel geforctes, Quality AF wird auch 'trilinear' anisotrop gefiltert.

jap, JAP... genau das rede ich hier seit ich doom3 in den händen halte. mich hat es tierisch gestört diesen mipmapübergang vor mir her zu schieben und hab es auch übers CP geforced um schönere bilder zu bekommen...

[Der Unregistrierte]

jap, JAP... genau das rede ich hier seit ich doom3 in den händen halte. mich hat es tierisch gestört diesen mipmapübergang vor mir her zu schieben und hab es auch übers CP geforced um schönere bilder zu bekommen...

Das liegt wohl daran, dass Doom3 die diffuse Textur von der "falschen" Textureinheit sampled, sprich, nicht von der "0".

[nggalai]

Und ganu deswegen lassen viele, viele Engines die Einstellung des AF-Levels über das Menü (wie übrigens Doom3 auch!) gar nicht erst zu?
Sehr interessant...

Razor
Stellenweise ja, stellenweise haben die Entwickler in der Vergangenheit einfach nicht daran gedacht. Für viele, so kommt's mir bei meinen Gesprächen vor, sind AF und FSAA so was wie "Sekundärfeatures", welche nicht weiter user-relevant sind. Zumindest FSAA hat sich langsam auch in-game durchgesetzt (wenn man mal von so Sachen wie Splinter Cell, wo's gar nicht geht, absieht), AF kommt auch langsam--immerhin schaltet DooM3 auf "High" auch 8°AF zu, aber eben--nur auf den Texturen, die's auch brauchen. Es macht z.B. kaum Sinn, die Normal-map anisotrop zu filtern. Manche Entwickler möchten dem Spieler diese Kontrolle nicht geben, da sie fürchten, dass dann das Geschrei wegen "zu langsam!!" los geht. Bis auf einen kleinen Prozentsatz der Spieler, welche in solchen Boards wie hier posten, dürften die Leute nicht mal wissen, was AF ist. Seh ich oft genug im Freundeskreis--"ich hab' bei Painkiller "anisotropic" angewählt, und das macht das Spiel einfach nur langsam ohne dass es besser aussieht. Was soll das überhaupt? Schaltet ja gar keinen zusätzlichen Special-Effect ein ..."

Das "kategorisch" da oben hätte ich eventuell anders schreiben sollen--für alte Spiele ist's interessant, über den Treiber AF einstellen zu können. Bei neuen Spielen schalte ich AF genau dann zu, wenn's eine Configfile- oder in-game Option gibt. AF fest zu legen ist IMO Sache der Entwickler und Künstler, nicht des Endanwenders.

93,
-Sascha.rb

[Quasar]

"GL_LINEAR_MIPMAP_LINEAR" bringt bei mir TS "optmiertes" AF. D.h. bi-AF auf irgendwelchen Texturstages. Wundert mich, dass das noch niemand bemerkt hat, wo doch ohnehin so viele hochsensibilierte AF Meister sich im 3D Center herumtreiben :D:D:D

Nur mittels, übers Controlpanel geforctes, Quality AF wird auch 'trilinear' anisotrop gefiltert.

GL_LINEAR_MIPMAP_LINEAR ist der Wunsch der APP nach normaler, trilinearer Filterung - wenn du im Control Panel etwas anderes erzwingst, bsw. Performance-AF (bilineares AF), wird dieser Wunsch schlichtweg ignoriert.

[Quasar]

Also ich kann zumindest bestätigen das AF via APP schneller ist als AF via CP. Selbst höhere Stufen in app angefordert waren (leicht) schneller als niedrigere via CP. Genaue Zahlen hab ich nicht (mehr), aber könnte sie nachliefern.. von ner 9800pro128MB

Nicht nur das - HQ scheint auch ansonsten noch eine etwas _genauere_ Einstellung des AF vorzunehmen, als es "image_anistropy" allein vermag. Wenn ich nur HQ auswähle (wobei für wichtige Texturen ja 8xAF aktiv werden soll), bekomme ich mehr FPS heraus, als wenn ich in HQ den Wert von image_anisotropy manuell bsw. auf 4 ändere.

[Mr. Lolman]

GL_LINEAR_MIPMAP_LINEAR ist der Wunsch der APP nach normaler, trilinearer Filterung - wenn du im Control Panel etwas anderes erzwingst, bsw. Performance-AF (bilineares AF), wird dieser Wunsch schlichtweg ignoriert.


Bei mir gibt Ts-Optimiertes AF. Sieht man ganz genau schon im allerersten Raum am Gitterboden. Quality AF übers CP forciert bringt echtes tri-AF.

[Mr. Lolman]

Nicht nur das - HQ scheint auch ansonsten noch eine etwas _genauere_ Einstellung des AF vorzunehmen, als es "image_anistropy" allein vermag. Wenn ich nur HQ auswähle (wobei für wichtige Texturen ja 8xAF aktiv werden soll), bekomme ich mehr FPS heraus, als wenn ich in HQ den Wert von image_anisotropy manuell bsw. auf 4 ändere.


Ist bei mir auch nicht so. Je weniger image_anisotropy, desto schneller wirds. Lustigerweise muss man dafür aber noch ein vid_restart nachschieben, oder alternativ überhaupt DoomIII neustarten.

[Chris Lux]

Bei mir gibt Ts-Optimiertes AF. Sieht man ganz genau schon im allerersten Raum am Gitterboden. Quality AF übers CP forciert bringt echtes tri-AF.

wie der gast schon schrieb... bei doom3 wird die diffuse texture nicht auf 0 gesamplet, weshalb man die stageoptimierung wunderbar sehen kann. da aber die af tester alle beste ergebnisse zeigen ist auch klar, dass der treiber entweder diese oder die doom3 exe erkennt.

dies ist aus dem shadercode:

OPTION ARB_precision_hint_fastest;

# texture 0 is the cube map
# texture 1 is the per-surface bump map
# texture 2 is the light falloff texture
# texture 3 is the light projection texture
# texture 4 is the per-surface diffuse map
# texture 5 is the per-surface specular map
# texture 6 is the specular lookup table


hier sieht man auf welcher textureunit die texturen liegen... tja, nun wünsch ich mir auch im ati treiber die optionen, die nvidia nun schon seit längerem drin hat.

[Jesus]

es sieht aber sogar mit Perf AF imo besser aus als mit APP af, zumindest fällt das Texturband weniger auf ( mglw. weils weiter entfernt ist ).

[Mark]

kann mal einer wieder ne aktuelle interaction.vfp hochladen? dann kann ich mal die veränderungen testen

[Jesus]

hm hab nochmal getestet:

GL_MIPMAP_LINEAR und GL_MIPMAP_LINEAR_NEAREST sehen identisch aus, sprich deutlich sichtbares ( sehr nahes ) texturband.

selbst 2x AF auf Performance im CP sieht wesentlich besser ( kaum mehr sichtbares banding und weniger flimmernde texturen ) aus als APP, obwohl ich auf High spiele und dort in der Cfg. ja image_anisotropy "8" angefordert wird.

dazu mal die benches:

CP APP: 29,3 FPS ( high details, 1280x1024 )
CP 2x perfAF: 29,5 FPS ( high details, 1280x1024 )

( beides zweiter durchgang , timedemo demo 1 )

das besser aussehende ist also auch noch schneller :eek:

[gast]

Das wird mir alles zu Bunt ;)

[r@w]

Das "kategorisch" da oben hätte ich eventuell anders schreiben sollen--für alte Spiele ist's interessant, über den Treiber AF einstellen zu können. Bei neuen Spielen schalte ich AF genau dann zu, wenn's eine Configfile- oder in-game Option gibt. AF fest zu legen ist IMO Sache der Entwickler und Künstler, nicht des Endanwenders.Und Du meinst tatsächlich, dass der Endanwender nicht einmal die Möglichkeit dazu haben sollte?
Ich vermute, dass Du das anders meintest, gell?
:wink:

Klar sollten die Entwickler das tun und nicht der Endanwender... das gibt ihnen aber noch lange nicht das recht, mir den Grad der Bildverbesserung (mal eingedeutscht formuliert) vorzuschreiben. Auch wenn ID der Meinung ist, dass zu ihrem "Quality" eben auch 8°AF dazu gehört, muss ich das als Endanwender doch noch lange nicht akzeptieren. Also ist wieder Handarbeit angesagt, um den Grad selber zu bestimmen (zumal "Quality" + 4°AF bei D3 völlig ausreicht und damit schwächere GraKa's schont).

Ich denke mal, mit der Vorgabe 8°AF will ID einfach nur Industrie-"freundlich" sein und dem Endkunden suggerieren, dass man neue Hardware braucht, um "Quality" genießen zu können. Schließlich war der Unfug - von wegen: für "Quality" braucht's 256MB GraKa's - eben genau dieses...

Zumindest in der Readme hätten Sie auf diesen Umstand hinweisen können (was nicht der Fall war), denn schließlich gibt über dieses Faktum lediglich die Config-Datei auskunft... und das ist wirklich nicht die 'feine Art'.

Razor

[nggalai]

Und Du meinst tatsächlich, dass der Endanwender nicht einmal die Möglichkeit dazu haben sollte?
Ich vermute, dass Du das anders meintest, gell?
:wink:

Nein, da vermutest Du falsch. :wink: Wenn's nach mir ginge, würden in-game settings immer und ohne Ausnahme Control-Panel-Settings übersteuern. Also: Control-Panel tut genau dann, wenn das Game selbst nichts angibt.

93,
-Sascha.rb

[Mr. Lolman]

Nein, da vermutest Du falsch. :wink: Wenn's nach mir ginge, würden in-game settings immer und ohne Ausnahme Control-Panel-Settings übersteuern. Also: Control-Panel tut genau dann, wenn das Game selbst nichts angibt.

93,
-Sascha.rb


IdF müssten ATi User bei DoomIII auf schönes AF verzichten...

[nggalai]

IdF müssten ATi User bei DoomIII auf schönes AF verzichten...
Du siehst den Vorteil "meiner" Methode--ATI wäre gezwungen, das Bilinear-Problem zu lösen. Davon profitiert nicht nur DooM3, sondern jedes Spiel, welches halt die Diffuse-Map nicht auf TS0 hat.

93,
-Sascha.rb

[Mr. Lolman]

Hm, ich dachte mir bisher, dass die App. selbst die Art des AF wählen kann, und das JC bei D3 halt ein bisschen was verbockt hat. Diese TS0 Gschicht, gabs ausserdem ohnehin nur unter D3d, oder ist das jetzt etwa alles falsch?

[Quasar]

GL_MIPMAP_LINEAR und GL_MIPMAP_LINEAR_NEAREST sehen identisch aus,

Wenn du das wirklich so geschrieben hast, funktioniert das auch nicht.
GL_LINEAR_MIPMAP_LINEAR und
GL_LINEAR_MIPMAP_NEAREST
heissen die korrekten Kommandos. :)

[Quasar]

Bei mir gibt Ts-Optimiertes AF. Sieht man ganz genau schon im allerersten Raum am Gitterboden. Quality AF übers CP forciert bringt echtes tri-AF.

Das meinte ich nicht, ich wollte nur ausdrücken, daß GL_LINEAR_MIPMAP_LINEAR nicht direkt mit AF zu tun hat. Das ist, wie gesagt, nur der Wunsch der APP nach dem grundlegenden Texturfilter - wenn der schon durch den Treiber (bsw. durch Performance-AF) nicht berücksichtigt wird, ist klar, daß da komische Dinge passieren.

[Jesus]

Wenn du das wirklich so geschrieben hast, funktioniert das auch nicht.
GL_LINEAR_MIPMAP_LINEAR und
GL_LINEAR_MIPMAP_NEAREST
heissen die korrekten Kommandos. :)

eh nein hab ich nicht ;) copy & paste fehler :biggrin:

[InsaneDruid]

Hm, ich dachte mir bisher, dass die App. selbst die Art des AF wählen kann, und das JC bei D3 halt ein bisschen was verbockt hat. Diese TS0 Gschicht, gabs ausserdem ohnehin nur unter D3d, oder ist das jetzt etwa alles falsch?

Zumindest soweit ich weiss, nein.

Vor allem da die berüchtigte Stageoptimierung (die meines Wissens nur unter D3D auftritt) nur beim CP-forcierten AF, nicht aber beim APP-angeforderten AF auftritt.

Warum sollte ATI dies nun ändern, zumal ja noch die "falsche" Textur tri gefiltert wird. Und dann schiebt man noch nen Hotfix Treiber nach und auch da ändert man das nicht? Nee, also nach Cheat riecht das nicht, IMHO.


PS Der Tweak von Humus bringt bei CP-Af wirklich einiges. Bei mir ca 19%. (1024, 4xAF, R9800pro - 37 vs 44fps) Solange kein Fix (won welcher Stelle auch immer) für den App.AF Mode erscheint, wirklich ne gute Methode um Tri AF ohne allzugroßen Speedloss zu nutzen.

[Jesus]

hm hab nochmal getestet:
CP APP: 29,3 FPS ( high details, 1280x1024 )


hab mir jetzt mal den humus patch geholt hier :

http://esprit.campus.luth.se/~humus/temp/doom3PerformanceTweak.rar

damit hab ich 31,9 fps ( demo1 )mit den selben settings. BQ ist gleich.

[r@w]

Nein, da vermutest Du falsch. :wink: Wenn's nach mir ginge, würden in-game settings immer und ohne Ausnahme Control-Panel-Settings übersteuern. Also: Control-Panel tut genau dann, wenn das Game selbst nichts angibt.Dann soll ich also damit leben, wenn die Engine 'meint', dass 2xAF (oder im schlimmsten Fall gar keines) ausreicht?
Also irgendwie habe ich da momentan leichte Verständnis-Probleme...

Wenn ich eine bessere Quali haben möchte (und mit dem Performance-Verlust leben kann), als es die Engine 'wünscht', warum soll ich diese nicht einstellen können, wenn es die Hardware hergibt.

Insofern finde ich die derzeitige Lösung schlicht ideal:
- wenn's im Panel auf 'App' steht, dann entscheidet die App
- wenn's im Panel 'geforced' wird, dass wird die App übersteuert
(ganz egal, wie sie das findet ;-)

Sorry, aber mir ist es wesentlich lieber, wenn ich die (vermeitliche) Kontrolle habe, als wenn es andere sind, die auf meinem Rechner ansagen, was jetzt geht... mag vielleicht eine etwas egoistische Einstellung sein.

Trotzdem spricht nichts dagegen, dass die Entwickler in der Readme kurz vermerken, dass
a) in den höheren Quali-Stufen AF dazu geschaltet wird und
b) das 'Übersteuern' des InGame-AF mit Performance-Einbußen einher gehen kann.

Tjo... nur meine Meinung dazu.

Razor

[InsaneDruid]

Da muss ich Razor sogar mal rechtgeben.

Wenn man schon im Control Panel zwischen "APP" und "User Setting" wählen kann, dann sollte das user Setting auch wirklich Priorität haben.

Nichtsdestotrotz sollten mehr Devs dazu übergehen, von der "App" Einstellung auch Gebrauch zu machen und somit die für Ihre Engine in ihren Augen besten Werte anzufordern.

Das blöde ist ja das die meisten Devs FSAA und AF fast vollständig "ignorieren" und den User so zum Übersteuern durchs CP zwingen, auch wenn das dank fehlender Flexibilität (aufuf an die Treiberschreiber.. ich will volle Kontrolle!)uU zu stark Performance frisst (manche Texturstages brauchen ja nun wirklich kein oder weniger AF)

Das "Perfekte" Szenario sähe in meinen Augen so aus

Default Setting: APP Control
Die App fordert auf den vom Dev als "sinnvoll" erachteten Stages und in vom Dev als "sinnvoll" erachtetem Modus (bi/tri) AF in einem vom User im Game im begrenzten Maß einstellbaren Grad an. (zb via Regler "wenig<>viel", oder als Simple Checkbox(en) wie andere Ingameoptionen, um es allgemeinverständlich zu halten)

User Setting: für Fälle in denen der Dev gepennt hat, oder de User unbedingt auch auf anderen Stages mehr oder weniger AF haben will (warum auch immer). Hier sollte der User ebenfalls die Kontrolle haben welche Stages mit wieviel AF(und ob bi oder tri oder bri) gefiltert werden.

Damit könnte (und müsste auch, damit es Sinn hat) der Dev AF gezielt dort einsetzen wo es seiner Meinung nach am besten hingehört. Er entscheidet ja auch wo er welche Lichtquelle hinsetzt, wie stark die Textur aufgelöst ist etc. (was der User nomalerweise auch nicht ändern kann/will).

Man hätte also einen Default Mode der optisch und Performance technisch sehr gut dahsteht, und einen Tweakmode für alle die die volle Kontrolle haben wollen. Und "volle Kontrolle" müsste dann auch wirklich "VOLLE" Kontrolle sein. Ich erachte diie diversen Tweaks durchaus für sinvoll, wenn sie als zuschaltbare Option ausgeführt werden. In Grenzfällen ist bri oder sogar bi auf einigen Texturen bei annehmbarem Speed für mich besser als der (sicher hübschere) volltrilineare Mode, wenn dieser geschwindigkeitsmäßig zu starke Einbußen bringt. Speed ist für mich auch ein Qualitätsmerkmal. Und auch bei anderen Qualitätsmerkmalen, wie Auflösung, Sichtweite etc geht man ja hier und da verschiedenste Kompromisse ein, um den Speed annehmbar zu halten.

[gast]

Hi also ich verfolge schon länger diese Diskussion über diesen tweak und wie ich finde hat CruNcher dazu einen sehr schönen test im Beyond3d Forum geliefiert hehe ausser das er demirug falsch schreibt. Er benutzt die timedemo shoot_001 die wie ich finde ideal ist um den tatsächlichen Speed gewinn herauszufinden sieht man auch sehr schön an den FPS in CruNcher seinen Bildern wie schnell die Engine mit den unterschiedlichen interaction.vfp und Einstellungen die Szene Rendert.