Profile im Treiber (und Neues beim 66.00 ;-)

[r@h]

Hiho, liebe Leutz!

Habe da was Interessantes heraus gefunden, welches aber nur am Rande etwas mit nVidia's "Neuen", wenn auch inoffiziellem 66.00 zu tun hat... und das hängt mit den vordefnierten Profilen zusammen, welche schon da sind, nachdem der Treiber frisch installiert wurde.

Also dann...

Erst einmal stellte sich mir die Frage, wo denn diese Profile herkommen und wie sich das damit nach der Installation eines Treibers verhält. So wollte ich denn insbesondere beim 66.00 das Profil für "Doom3" los werden, bei dem ich zuerst dachte, dies selber angelegt zu haben (Festlegung des AppAF). Nur konnte ich die Einstellung für das AppAF nicht mehr (zu Testzwecken) deaktivieren....

...so suchte ich also in der Regitery nach allem, was mit "Doom3" und dem Treiber zusammenhing und löschte dies. Aber der Treiber zeigte mir noch immer dieses Profil und in der Registery war nichts mehr dazu zu finden. So 'entdeckte' ich die Datei

nvapps.xml

welche auch Bestandteil der Installation ist. Und siehe da, die Profile sind in dieser Datei definiert!
Also ist auch diese Datei dann die 'Vorlage' für den Treiber diese Profile oder zumindest Abwandlungen daraus in der Registery einzutragen...

Gesagt getan und den Eintrag für "Doom 3" kurzerhand aus der XML-Datei mit einem herkömmlichen Editor gelöscht und schon war auch das Profil aus dem Treiber verschwunden.

-

Soweit, so gut... dachte ich... und schaute mir die Datei 'nvapps.xml' mal näher an und fand da doch sehr interessante Einstellungen, die da für bestimmte 'Programme' (eigentlich ausnahmslos Games ;-) vorgenommen werden... Einstellunge, die 'mann' so in der Oberfläche gar nicht einstellen oder beeinflussen kann.

Hier mal die Einstellungen im einzelnen:

conformant_texture_clamp

Tjo... was auch immer das bedeuten mag...
(ist schon seit uuuuurzeiten als Option in den Treibern zu finden ;-)

Ist wohl so etwas wie eine Kompatibilitätseinstellung... vielleicht können unsere Spezies ja was dazu sagen.
.
multichip_rendering_mode

Seeeehhhhhrrrr interessant.
Ist diese Einstellung doch über die Oberfläche nicht zu erreichen (zumindest bei meiner FX5900 ;-), wird aber bei Aktivierung dieses Profils gesetzt. Dürfte wohl auf die SLI-Fähigkeit von PCIe-Karten hinweisen und findet sich derzeit ebenfalls nur bei einem einzigen OGL-Game.
.
ogl_extension

Ist der Parameter für das OpenGL-Extension-Limit, welches auch über das Panel einstellbar ist. Sonderbar bzw. unklar ist jedoch, was genau hier limitiert wird. Wird dieser Parameter manuell aktiviert, findet sich eine '1' als Zuordnung. Offenbar gibt es jedoch 'Sonderfälle' bei denen eine spezielle Einstellung greift... siehe dazu unten mehr.
.
prevent_cpl_aa

DAS empfinde persönlich als Frechheit!

Besagt dieser Parameter doch nichts anderes, dass CP-AA (im Gegensatz zu App-AA) für die zugeordnete Applikation nicht mehr möglich ist. Und da man ja (auf herkömmlichen Wege) kein Profil löschen kann und dieser Parameter zudem noch dafür 'sorgt' dass dieser nicht einmal deaktiviert werden kann (!!!), hat man dann in der Oberfläche schlicht verloren.

So wird also nun (z.Bsp.) bei SplinterCell 'verhindert', dass AA in den globalen Einstellungen erzwungen werden kann!
.
prevent_cpl_af

Und hier ist nun auch der Parameter zu finden, der dafür sorgte, dass ich nunmehr kein AF mehr über das Panel bei Doom3 erzwingen konnte. Sonst selbiges 'Spiel', wie beim Parameter für's AA auch...
Und um dies jetzt mal am Beispiel des 66.00 zu verdeutlichen, habe ich mal die nvapps.xml dechiffriert:


conformant_texture_clamp = 2
- 4x4 Evo 2
- Alice
- Call of Duty
- Call of Duty MultiPlayer
- Diablo II
- Icewind Dale
- Jedi Academy
- Jedi Academy MultiPlayer
- Jedi Knight 2
- Medal of Honor
- Quake3
- RTCW
- RTCW MultiPlayer
- Soldier of Fortune 2
- Soldier of Fortune 2 MultiPlayer
- Wolfenstein Enemy TerritoryUnd hier jetzt mal die 'interessanten':


multichip_rendering_mode = 64444434
- Jedi Academy
- Jedi Academy MultiPlayer

ogl_extension = 4520
- Medal of Honor

ogl_extension = 1
- X29

prevent_cpl_aa = 1
- FarCry
- Halo
- Splinter Cell
- Splinter Cell - Pandora Tomorrow
- Splinter Cell - Pandora Tomorrow MultiPlayer
- The Westerner
- Tomb Raider

prevent_cpl_af = 1
- Doom 3Ist das nicht bemerkenswert?
:D

JK3 nuntzt also Multichip (in einer speziellen weise?), Medal Honor und X29 werden unterschiedlich beim OGL-Ext-Limit beschnitten, Doom3 bekommt keine CP-AF mehr und eine ganze reihe von Apps bekommen kein CP-AA!

Nett... wirklich nett.

Werde wohl dazu übergehen, die nvapps.xml VOR Installation erst einmal zu bearbeiten, oder aber durch eine vorbereitete zu ersetzen... auch und gerade um die Kontrolle darüber zu haben wie sich der Treiber bei welchen Games verhält.

Razor

[doom1]

hui sauber haste fein gemacht!
Was ändere ich den nun,einfach löschen oder die "1" durch eine "0" oder "?" ersetzen?

[Radeonator]

1. Man kann jede Exe einfach umebnennen, was aber etwas umständlich ist
2. AFAIK sind die Profile nicht zwingend enabled oder?

[r@w]

hui sauber haste fein gemacht!
Was ändere ich den nun,einfach löschen oder die "1" durch eine "0" oder "?" ersetzen?Einfach VOR der Installation des Treibers die nvapps.xml editieren...

Bei den "prevent"-Parametern das komplette Profil löschen (wenn Du mit einem Editor in die Datei hinein schaust, wirst Du sehen, wie das gemeint ist ;-). Wenn einem Profil mehrere Parameter zugeordnet sind, dann eben nur den entfernen, der 'stört'.

Wenn man diese Datei VOR der Installation 'bereinigt', dann hat man nicht das lästige Problem, die bei der Installation generierten Registery-Schlüssel manuell zu lokalisieren und dann zu entfernen. Ergo: Treiber deinstallieren, nvapps.xml ändern, Treiber installieren und schon ist's gut.

Razor

[r@w]

1. Man kann jede Exe einfach umebnennen, was aber etwas umständlich istUnd vor allem oft auch nicht funktioniert...

FarCry wäre da ein gutes Beispiel (hatte ich mal seinerzeit probiert ;-). Bei Doom3 oder auch SplinterCell klappt das hingegen hervorragend... auch wenn man die neuen Konfigurations-Dateien dann wieder anpassen muss, so denn sie vorher nicht auch umbenannt werden... allgemeim eine recht lästige Angelegenheit... die spätestens beim nächsten Update wieder zum Problem wird.

Ergo: einfach diesen Murks nicht mit installieren und schon gibt's auch kein diesbezügliches Problem.

2. AFAIK sind die Profile nicht zwingend enabled oder?Falsch!

Selbstverständlich sind die Profile 'enabled'!
Wenn man denn 'darf' kann man einfach alle Parameter eines Profils deaktivieren, aber das Profil selber bleibt trotzdem aktiv und eine Möglichkeit zum Löschen ist ja nicht vorgesehen.

Aktiviert wird ein Profil über das Starten einer EXE. Der Treiber schaut nach, welche Parameter des globalen Profils 'überschrieben' werden sollen und tut dies dann auch. Der Clou ist allerdings, dass man ja die 'predefined' Parameter gar nicht deaktivieren kann... im Falle der 'doom.exe' von Doom3 bedeutet dies dann, dass man nie wieder CP-geforcetes AF benutzen kann... so denn man nicht selber umständlich Hand anlegt.

Razor

[Quasar]

Ich habe den gestrigen NAchmittag/Abend auch mit sehr viel Doom3 zugebracht - allerdings komplett ohne Profile, da ich eine manuelle Kontrolle bevorzuge.

Da sind allerdings auch ein paar kleinere Merkwürdigkeiten passiert:
So wie es momentan ausschaut, wird von dem von mir benutzten 65.62er Treiber in Bezug auf Doom3 kein Unterschied zwischen App- und CP-AF gemacht (ohne Profile, wohlgemerkt).
Auch scheint die Reduzierung des trilinearen Filteranteils die einzige der drei offen verfügbaren Optimierungen zu sein, die in Doom3 meßbar greift.

HQ im Treiber bringt allerdings noch etwas weiteres dazu, nicht mehr genutzt zu werden - die FPS fallen noch ein bißchen mehr.
Worst- vs. Best-Case (interpretierbar), also das max. Performancedelta betrug 7,5 von knapp 60fps - 52,5 vs. 59,9 mit 8xAF (wie gesagt, egal, ob per Applikation eingestellt, über Doom3-HQ-Modus angefordert oder über den Treiber erzwungen).

Sorry für OT, da ich ja den 65.62er benutze...

edit:
In "meiner" nVapps.xml ist der Doom3-Eintrag noch nicht vorhanden... :|

[Gast]

man kann die Datei nVapps.xml jederzeit ändern da sie im windows/system32 liegt.

[r@w]

Öhmmm...

Sorry für OT, da ich ja den 65.62er benutze...Nö, ist überhaupt nicht OT, da es hier allgemein um die Profile geht.
(Ok, das Beispiel, welches ich nannte, bezog sich dann auf die Einstellungen des 66.00)

Ich habe den gestrigen NAchmittag/Abend auch mit sehr viel Doom3 zugebracht - allerdings komplett ohne Profile, da ich eine manuelle Kontrolle bevorzuge.So I do!
:D

Da sind allerdings auch ein paar kleinere Merkwürdigkeiten passiert:
So wie es momentan ausschaut, wird von dem von mir benutzten 65.62er Treiber in Bezug auf Doom3 kein Unterschied zwischen App- und CP-AF gemacht (ohne Profile, wohlgemerkt).
Auch scheint die Reduzierung des trilinearen Filteranteils die einzige der drei offen verfügbaren Optimierungen zu sein, die in Doom3 meßbar greift.Also erst einmal ist Tri-Opt die einzige Optimierung, die generell auch bei OpenGL-Apps greift. Insofern von den beiden anderen Aniso-Opts nur D3D-Apps betroffen sind...

Zum anderen konnte ich sowohl mit dem 65.62, als auch mit dem 66.00 ganz klar Unterschiede zwischen CP- und App-AF feststellen... in beiden Fällen ca. 3 fps, also etwa 10% Differenz zugunsten des App-AF. Ganz wichtig ist es allerdings, die erste 'Messung' generell zu ignorieren, denn diese ist nicht precached (beim Gamen werden beim Laden alle Objekte ge'touched', beim Benchmark merkwürdiger weise nicht).

HQ im Treiber bringt allerdings noch etwas weiteres dazu, nicht mehr genutzt zu werden - die FPS fallen noch ein bißchen mehr.Jo, klar.

Das hast Du doch damals mit Hintergrund gefüllt...
Es gibt einen leichten Unterschied zwischen HQ und Q-noOpt!
(unter beiden API's)

Worst- vs. Best-Case (interpretierbar), also das max. Performancedelta betrug 7,5 von knapp 60fps - 52,5 vs. 59,9 mit 8xAF (wie gesagt, egal, ob per Applikation eingestellt, über Doom3-HQ-Modus angefordert oder über den Treiber erzwungen).Das habe ich jetzt nicht verstanden... oder doch?

Du sagst also damit, dass bei Dir - trotz eliminierten Doom3-Profils (egro: nvapps.xlm VOR Installation entsprechend editiert?) - es keinen Unterschied zwischen App-AF und CP-AF gibt?

Und das wiederum würde darauf hindeuten, dass das erzwungene App-AF bei Dir noch weiterhin aktiv ist.

Insofern meine Frage: wie hast Du das Doom3-Profil entfernt?
War dieses beim 65.62 überhaupt schon vorhanden?
:confused:

Habe mir jetzt ('instant' sozusagen ;-) den 66.52 nochmal herunter geladen...
Mist... Guru3D hat nur wieder nur einen völlig zerranzten Mix-Treiber...
Also doch wieder bei DELL... oh ha, hat jetzt sogar 'nen Setup... ;)
Und.... ? kein Doom3-Profil!

Also irgendwie tu isch dat net verstehe...
Oder war bei Dir nie ein Doom3-Profil vorhanden?
Hmmm...

Razor

[r@w]

man kann die Datei nVapps.xml jederzeit ändern da sie im windows/system32 liegt.Jo, sagte ich ja bereits...

Das ändert dann aber nicht die schon eigefügten Registery-Keys... insofern 'darf' man dann diese auch noch alle manuell löschen... und Vorsicht... die sind i.d.R. gleich 3x vorhanden...

Razor

[Quasar]

a) Nein, bei mir war kein D3-Eintrag in der .xml vorhanden - es ist nicht da und gelöscht habe ich es auch nicht.

b) Ich habe mit einer 6800 probiert - mit meiner 5800u konnte ich auch mit dem 65.62er KEINE andere Optimierung mehr ausmachen, als die Reduzierung des trilinearen Filters (in Direct3D!) - zumindest keine, die sich irgendwie in den Füllratenverläufen niederschlugen.

c) Natürlich habe ich mind. das 2te, manchmal sogar erst das dritte Resultat eines Durchlaufes genommen.

Momentan denke ich, daß die "neueren" Treiber als die offiziellen Referenztreiber nur eine Spielwiese für Optimierungen für den nV4x sind.

[r@w]

edit:
In "meiner" nVapps.xml ist der Doom3-Eintrag noch nicht vorhanden... :|Na klasse... das habe ich ja nun auch gerade feststellen müssen...
:D

Du hast also lediglich das 'Problem', dass Du keinen Unterschied zwischen CP-AF und App-AF feststellen kannst, richtig?
Das wiederspricht allerdings meinen Erfahrungen, wie auch aller anderen, die sich bis dato damit beschäftigten...

Razor

[Quasar]

So ist's - die "anderen" die du ansprichst, haben die auch eine nV4x-Karte oder, wie du, einen nV3x?

Wie gesagt, es scheinen unterschiedliche Optimierungsgrade für die Generationen in dem Treiber integriert zu sein.

[r@w]

Ächts... irgendwie überschneiden wir uns ein wenig... :ugly:
a) Nein, bei mir war kein D3-Eintrag in der .xml vorhanden - es ist nicht da und gelöscht habe ich es auch nicht.Klar, da Du den 65.62 benutzt, bei dem dieser Eintrag noch nicht vorhanden war.
(ist erstmalig mit dem 66.00 gekommen ;-)

b) Ich habe mit einer 6800 probiert - mit meiner 5800u konnte ich auch mit dem 65.62er KEINE andere Optimierung mehr ausmachen, als die Reduzierung des trilinearen Filters (in Direct3D!) - zumindest keine, die sich irgendwie in den Füllratenverläufen niederschlugen.Aniso-Stage-Opt ("mip filter" dingens) und Ansio-Sample-Opt (LOD-Spielerei) waren auch schon mit dem 65.62 verfügbar... sowohl für die 6800'er, wie auch für die FX'en...

Und selbstverständlich konnte man da einen Unterschied bei den einzelnen Optimierungen ausmachen.

Die ImgTech-Benchies sind da immer sehr hilfreich, da dort der Unterschied recht deutlich zutage tritt und der gleiche Bench auch für OGL zur Verfügung steht. Auch hier: Tri-Opt 'wirkt' auf beide APIs, die (beiden) Aniso-Opts lediglich auf D3D.

c) Natürlich habe ich mind. das 2te, manchmal sogar erst das dritte Resultat eines Durchlaufes genommen.Das dachte ich mir schon... wollte es der Vollständigkeit halber aber zumindest erwähnt haben.

Momentan denke ich, daß die "neueren" Treiber als die offiziellen Referenztreiber nur eine Spielwiese für Optimierungen für den nV4x sind.Was allerdings meinen Erfahrungen wiedersprechen würde, da ich diese 'Spielwiese' durchaus mit meiner guten alten FX nachvollziehen konnte...

Razor

[r@w]

So ist's - die "anderen" die du ansprichst, haben die auch eine nV4x-Karte oder, wie du, einen nV3x?

Wie gesagt, es scheinen unterschiedliche Optimierungsgrade für die Generationen in dem Treiber integriert zu sein.Nicht so ganz... wenn ich das richtig sehe...

Schließlich funzen die Optimierungen bei den NV4x, wie auch bei den NV3x.
Lediglich der NV30 scheint da bei Dir eine Ausnahme zu machen...

Razor

[r@w]

Ahhhh.... 'sync' !
:D

Razor

[Quasar]

Naja, im Villagemark konnte ich es teilweise nachvollziehen, in meinem anderen Füllratentester, den ich für etwas genauer halte, eher nicht. Ich habe dort sogar mal ein bißchen mit verschiedenen Texturstages rumgespielt, um zu schauen, ob vielleicht die _drei_ Texturen, die der VM übereinanderlegt, einen Unterschied machen: nada.

Da ich eine nV30 und du eine nV35 benutzt habe (hast), könnte man nun auf zwei Rückschlüsse kommen:

Entweder die "Grenze" liegt zwischen nV30 und nV35 oder die Optimierung versucht, Texturinhalte zu "erkennen" (um nicht "intelligenter Algo" zu sagen ;)).
Auch habe ich meinen Tester nochmal extra mit einer anderen Textur laufen lassen: keine Reaktion.

:|

[r@w]

Hmmm...

Auch habe ich meinen Tester nochmal extra mit einer anderen Textur laufen lassen: keine Reaktion.Mal das Temple-Demo von ImgTech versucht?
IMO gab's aber auch deutliche Unterschied auch bei anderen (nicht CPU-limitierten) D3D-Apps... beim VM ist's aber am deutlichsten gewesen.

Inwieweit dieses 'D3D-Sample-Opt' Real-World eine Performance-Relevanz hat, kann ich derzeit auch nicht sagen. Da der Hintergrund dessen aber offenbar ein kleines LOD-Spielchen ist, schalte ich es einfach kategorisch ab... zumal die Aktivierung dessen teilweise auch Performance gekostet hat... eigentlich klar, wenn der LOD leicht erhöht wurde (wird ja nicht gesenkt, wie bei den ATI-Treibern).

Oder hast Du nähere Info's, was genau da eigentlich bei diesem "Sample-Opt" passiert?
:confused:

Razor

[Quasar]

Das Temple-Demo fing bei mir leider schon an, CPU-Limitiert zu sein - nicht bei der FX, ok, aber wie schon gesagt, im VM konnte ich ja auch (geringe) Unterschiede 'sehen'.

Die AF-Sample-Optimierung 'spart' sehr weit vorn im Sichtfeld einiges an Füllrate durch späteres Einsetzen der Steigerung der verwendeten Textursamples. "Weiter hinten" im Sichtfeld wird durch diese Verschiebung zwar wieder etwas verloren, aber "vorn" ist der Gewinn ungleich gewichtiger, da dort auf jeden Fall etwas zu sehen ist, die Optimierung also fast immer wirkt, weiter hinten kann dagegen in einigen Games schonmal nur selten was zu sehen sein (Doom3 mit seinen engen, verwinkelten Gängen bsw. ;) ).

Ist das genau genug?

[r@w]

Ist das genau genug?Sehr genau...
Thx alot!
:up:

Razor

[r@h]

Ist das genau genug?Eine frage noch, Quasar...
Hast Du auch eine ähnlich präzise Darstellung für das, was im Treiber als

"conformant_texture_clamp"
bezeichnet wird?
Irgendwie kann ich mir so gar nichts darunter vorstellen...
:-(

Razor

[r@h]

Und ein kleiner Nachtrag zu meinem einleitenden Post!

Habe jetzt mal meine Erfahrungen auf den neuen FW 65.73 WHQL von Fujitsu-Siemens angewandt (der übrigens ebenfalls schon ein Profil für Doom3 enthält, damit dann zeitlich der erste ist ;-) und mal folgendes ausprobiert:

- Multi-Language-Dateien gelöscht (mach' ich immer ;-)
- nvapps.xml entfernt (aus dem Install-Verzeichnis verschoben)
- Treiber installiert
- Rechner neu gestartet
- nvapps.xml editiert (das 'prevent'-Zeugs entfernt ;-)
- editierte nvapps.xml ins 'system32'-Verzeichnis kopiert
- Panel aufgerufen

Und... es hat geklappt!

Das WHQL-Logo hat keinen Schaden genommen (der komplette Treiber ist also noch immer WHQL... auch wenn das nicht sooo viel bedeutet ;-), es sind auch nur die Profile im Panel verfügbar, die noch 'übrig' waren und auch in die Registery (unter Software und unter den Hardware-Schlüsseln) wurde nur das eingetragen, was da rein sollte. Bevor ich das Panel aufgerufen habe, war in der Registery noch nichts von irgendwelchen Profil-Einstellungen zu sehen...

Damit hat sich mein 'Problem' mit den bevormundenden Profilen nun endgültig erledigt!

Aber was noch viel besser ist... nun gibt es endlich eine Möglichkeit, eigens eingerichtete Profile über einen Treiberwechsel hinaus zu 'retten' und nicht jedes mal neu einrichten zu müssen.

DAS hat doch mal was, gell?
:D

Razor

[dittohead]

und wie schaut das aus wenn ich die nvapps.xml einfach ganz weg lasse ?
whql is dann sicher weg, aber treiber funzt normal weiter ?

[r@h]

und wie schaut das aus wenn ich die nvapps.xml einfach ganz weg lasse ?
whql is dann sicher weg, aber treiber funzt normal weiter ?Wie ich vorher schon schrieb, hat das mit der WHQL-Zertifizierung aber auch rein gar nichts zu tun. Insofern diese auch nicht erischt, wenn die Datei fehlt...

Und ich würde die Datei nicht einfach weglassen, sondern alle Profile darin löschen. Sonst fehlt Dir u.U. die Möglichkeit, Profile selbst anzulegen. Willst Du hingegen überhaupt keine Profile (außer eben das globale) benutzen, kannst Du nvapps.xml auch ganz weg lassen.

Razor