Archiv verlassen und diese Seite im Standarddesign anzeigen : nVidias Treiber: Inkonsistenzen und Fehler
Grestorn
2005-07-25, 09:16:30
Ich war die letzten Tage beschäftigt eine neue Version von nHancer zu erstellen. Beim Testen der neuen Features bin ich auf merwürdige Resultate gestoßen, die mich dazu gebracht haben, mal das Verhalten des Treibers genauer zu untersuchen... Dabei musste ich leider feststellen, dass bei weitem nicht alles glänzt im nVidia Treiberland...
Für jede globale Treibereinstellung gibt es einen korrespondierenden Wert in der Registry, z.B. "D3D_QualityEnhancements" für die "Qualtät", "Hohe Qualität" usw. Einstellungen. Immer wenn eine Applikation die Direct3D oder OpenGL DLL öffnet, werden diese Werte vom Treiber aus der Registry ausgelesen.
Zusätzlich können applikationsspezifische Varianten dieser Werte abgelegt werden, in dem der Registryeintrag mit dem Namen des Executables verbunden wird, also z.B. "_farcry.exe:D3D_QualityEnhancements". Wenn dann eine Applikation namens "farcry.exe" die Direct3D DLL öffnet, werden in diesem Beispiel diese Einstellungen gelesen und verwendet.
nVidias eigenes ControlPanel nutzt dieses Feature um applikationsabhängige Profile zu definieren. So weit zur Theorie und nun zur Wirklichkeit...
Das Verhalten der Treiber ist sehr unterschiedlich, abhängig davon ob das Spiel D3D oder OpenGL verwendet. Deswegen beschreibe ich das Verhalten getrennt:
Direct3D
Derzeit funktionieren lediglich die folgenden Einstellungen tatsächlich applikationsabhängig:
Anti-Aliasing, Anisotropic Filter, Farbschema, SLI Optionen (inklusive Dynamische Aufteilung und Stereo mode flags), Systemleistung (Qualität, Hohe Qualität usw.) und VSync.
Die folgenden Einstellungen funktionieren nicht applikationsabhängig, obwohl sie im normalen Control Panel für jede Applikation getrennt eingestellt werden können. Wenn man das tut, wird die Einstellung schlicht ignoriert! Sie funktionieren lediglich als globale Einstellung:
Anisotropic Filter Optimization, Anisotropic Sample Optimization, Trilinear Optimization, Neg. LOD BIAS Clamp, MipMaps erzwingen, LOD BIAS und das neue SLI Anti-Aliasing Feature.
Da diese Einstellungen auch in nVidias "nvapps.xml" gespeichert werden, dem File das nVidia zur Ablage aller Profile nutzt, bin ich mir ziemlich sicher dass dieses Verhalten nicht beabsichtigt und durchaus als schwerer Bug zu bezeichnen ist. Insbesondere der Fakt, dass der neue SLI Anti-Aliasing mode nur als globale Einstellung funktioniert macht diese neue Funktion ziemlich nutzlos...
Außerdem hat nVidia ein Feature eingebaut mit dem der Treiber zwischen verschiedenen Spielen unterscheiden kann, die den selben Namen für das Executable verwenden, da es tatsächlich Spiele gibt die so klevere Namen wie "game.exe" verwenden. Damit der Profilmechanismus auch in diesen Fällen funktioniert, verwendet der Treiber bis zu zwei Teile aus dem Pfad zum Executable. Also wenn das Executable als "c:\Programme\a great game\bin\game.exe" gespeichert ist, sucht der Treiber auch nach Werten in der Registry die mit "game.exe", "bin\game.exe" and "a great game\bin\game.exe" eingeleitet werden.
Dieses Feature ist eigentlich sehr nützlich. Aber jetzt kommt das große ABER: Nur sehr wenige Einstellungen nutzen das Feature auch tatsächlich, eigentlich nur die SLI-Optionen.
Also macht auch dieses Feature das Profil-Management extrem inkonsistent. Man kann zwar SLI-Profile für Spiele mit generischem exe Namen erstellen, aber es ist nicht möglich, in diesem Profilen irgendwelche zusätzlichen Optionen wir Anti-Aliasing oder Anisotropic Filtering zu definieren. Argh!
OpenGL
Die Situation beim OpenGL Treiber ist tatsächlich wesentlich besser. Alle Optionen, die der OpenGL Treiber kennt (was tatsächlich sehr viel sind, da es jede Menge OpenGL-exklusive Optionen gibt) werden grundsätzlich immer auch applikationsabhängig ausgelesen, wie oben beschrieben. So sollte eigentlich alles perfekt sein...
... wenn der OpenGL Treiber auch in der Lage wäre, für Spiele mit generischem Exe Namen auch Teile des Pfads des Exes auszuwerten, was er leider überhaupt nicht macht, nicht mal für SLI Einstellungen. Also wieder eine neue Inkonsistenz hier, die es enorm erschwert, mit Profilen zu arbeiten.
Die meisten dieser Inkonsistenzen könnten sehr einfach korrigiert werden. Ich bin mir sicher, dass jeder einigermaßen fähige Programmierer diese Probleme innerhalb von einem oder zwei Tagen beheben könnte.
Also weiß nVidia entweder von diesen Problemen nichts oder es ist ihnen schlicht egal. Aber Fakt ist dass eben wegen dieser Probleme, das eigentlich geniale und einmalige Feature mit den applikationsabhängigen Profilen immer mehr zur Farce verkommt.
Ich bin kein registrierter Entwickler bei nVidia, und da ich auch kein Spiel oder 3D-Applikation entwickle, glaube ich nicht, dass ich viel Glück mit einer Registrierung hätte oder gar von irgendeiner Person gehört werden würde, die dem Treiberteam zumindest nahe steht.
Aber ich habe den Eindruck gewonnen, dass einige Teilnehme dieses Forums die nötigen Kontakte zum inneren Kreis bei nVidia haben oder zumindest einen Weg wissen, wie man diese Probleme an die richtigen Personen übermitteln kann. Wenn dem so ist, wäre ich sehr dankbar, wenn diese Person(en) diese Probleme weiterleiten könnte...
(del676)
2005-07-25, 09:38:37
Anisotropic Filter Optimization, Anisotropic Sample Optimization, Trilinear Optimization
das war mir schon bekannt, allerdings dachte ich dass es nur bei BF2 so auftritt. (deswegen sehen soviele ein ach so schlimmes flimmern, obwohl es bestenfalls grieseln is ;) )
das mit SLI AA is sehr interessant, das schau ich mir heute bei CSS an.
Grestorn
2005-07-25, 09:41:34
das war mir schon bekannt, allerdings dachte ich dass es nur bei BF2 so auftritt. (deswegen sehen soviele ein ach so schlimmes flimmern, obwohl es bestenfalls grieseln is ;) )
das mit SLI AA is sehr interessant, das schau ich mir heute bei CSS an.
Ja, allgemein bekannt war das schon. Interessant hier ist aber, dass z.B. "High Quality" sehr wohl applikationsabhängig funktioniert, die einzelnen Optimierungen aber nicht. In wie fern die (globalen) Optimierungen in die applikationsabhängige "HQ" Einstellung reinfummeln müsste man genauer untersuchen.
Auf jeden Fall ist es ein furchtbarer Verhau, den nVidia da hat! :mad:
zeckensack
2005-07-25, 09:46:42
<...>
Außerdem hat nVidia ein Feature eingebaut mit dem der Treiber zwischen verschiedenen Spielen unterscheiden kann, die den selben Namen für das Executable verwenden, da es tatsächlich Spiele gibt die so klevere Namen wie "game.exe" verwenden. Damit der Profilmechanismus auch in diesen Fällen funktioniert, verwendet der Treiber bis zu zwei Teile aus dem Pfad zum Executable. Also wenn das Executable als "c:\Programme\a great game\bin\game.exe" gespeichert ist, sucht der Treiber auch nach Werten in der Registry die mit "game.exe", "bin\game.exe" and "a great game\bin\game.exe" eingeleitet werden.
Dieses Feature ist eigentlich sehr nützlich. Aber jetzt kommt das große ABER: Nur sehr wenige Einstellungen nutzen das Feature auch tatsächlich, eigentlich nur die SLI-Optionen.
<...>Kein Verlust IMO. So ein Verfahren ist sowieso extrem shice und unzuverlässig.
Ist zwar hier ein bissel nebenläufig, aber trotzdem ...
*weitaushol*
Mal als Beispiel Diablo 2. Kern-Echse heißt Game.exe und liegt im Stammverzeichnis des Spiels. Dieses ist standardmäßig %ProgramFiles%\Blizzard\Diablo II\
%ProgramFiles% ist sowieso nie verwertbar, da sogar der Default-Wert mindestens mal von der Sprachversion des OS abhängig ist. Und es kann sowieso vom User frei gewählt werden.
Bleibt als verwertbare Information noch \Blizzard\Diablo II\. Kann der User auch komplett wegknipsen. Der Publisher ist in 99% der Fälle keine zur Strukturierung wertvolle Information, also denke ich mal dass die meisten die da überhaupt was ändern auch den Publisher-Namen entfernen. Bleibt noch "Diablo II" als Information. Err ...
Liegt bei mir zB in d:\Zocken\Diablo2\ (allein schon weil ich für solches Gerumpel keinen Platz auf der Systempartition habe, aber auch zwecks Multi-Boot). Ich bevorzuge arabische Ziffern, und mag Leerzeichen in Dateinamen überhaupt nicht. Und schon ist vom Original-Pfad nichts mehr über.
Völlig zum Scheitern verurteilt das ist. Das sollten sie IMO garnicht erst fixen. Lieber gleich wegschmeißen und die Zeit in was sinnvolles investieren. Wie zB im gleichen Verzeichnis nach d2char.mpq suchen.
Marc-
2005-07-25, 09:47:45
...
Nicht das ich jemanden als wichtigtuer abstempeln möchte... aber inwiefern die von dir genannten fehler als "schwerer bug" zu bezeichnen sind weiss ich nicht.
Bis vor nicht allzulanger zeit wurde grundsätzlich mit globalen einstellungen gearbeitet und nicht mit applikationsspezifischen einstellungen. Dies wurde wenn überhaupt über drittanbieter und eigenänderungen durch die grakahersteller (asus etc) angeboten.
Für die allermeisten reichen diese globalen einstellungen zuzüglich der möglichen ingame einstellungen auch vollständig aus.
Lediglich für benchmarkfetischisten mag eine solche mangelhafte übernahme der einstellungen eine wirklich grössere rolle spielen. Ob das nun einen "schweren bug" darstellt, worunter ich verstehe das etwas nur sehr unzulänglich überhaupt nutzbar ist, ist eine frage.
Das es erst bei solchen untersuchungen überhaupt festgestellt wird heisst doch eigentlich, daß den meisten diese genannten nicht immer übernommenen einstellungen im spiel garnicht auffallen. Und sollte dies der fall sein werden wohl 99% der leute in der lage und willens sein, das eben über die globalen einstellungen zu tun.
Ich verstehe also die dramatik nicht wirklich
Grestorn
2005-07-25, 09:52:46
Völlig zum Scheitern verurteilt das ist. Das sollten sie IMO garnicht erst fixen. Lieber gleich wegschmeißen und die Zeit in was sinnvolles investieren. Wie zB im gleichen Verzeichnis nach d2char.mpq suchen.
Grundsätzlich hast Du schon recht. Profile die vom Hersteller geliefert werden, können so natürlich nicht zweifelsfrei funktionieren.
Der Anwender kann aber sehr wohl das Feature nutzen um Profile so eindeutih zu erstellen. Wie das Verzeichnis auf seiner Platte heißt, ist ja eindeutig.
Dein Vorschlag erscheint mir schwierig auf eine allgemeine Weise umsetzbar. Und vorallem: Wie will der Anwender so etwas in eigenen Profilen definieren?
Mir würde da eher so etwas wie ein CRC-Wert über das Exe (Problem: Es muss dann für jeden Patch und jede internationale Version ein eigener Eintrag erstellt werden) oder ähnliches vorschweben. Ganz problemlos wird sich das aber wohl nie lösen lassen...
ShadowXX
2005-07-25, 09:57:23
Grundsätzlich hast Du schon recht. Profile die vom Hersteller geliefert werden, können so natürlich nicht zweifelsfrei funktionieren.
Der Anwender kann aber sehr wohl das Feature nutzen um Profile so eindeutih zu erstellen. Wie das Verzeichnis auf seiner Platte heißt, ist ja eindeutig.
Dein Vorschlag erscheint mir schwierig auf eine allgemeine Weise umsetzbar. Und vorallem: Wie will der Anwender so etwas in eigenen Profilen definieren?
Mir würde da eher so etwas wie ein CRC-Wert über das Exe (Problem: Es muss dann für jeden Patch und jede internationale Version ein eigener Eintrag erstellt werden) oder ähnliches vorschweben. Ganz problemlos wird sich das aber wohl nie lösen lassen...
Könnte man das nicht über die SID des Objektes (in diesem Fall des Files) lösen?
Grestorn
2005-07-25, 10:02:42
Nicht das ich jemanden als wichtigtuer abstempeln möchte... aber inwiefern die von dir genannten fehler als "schwerer bug" zu bezeichnen sind weiss ich nicht.Ein schwerer Bug ist es, wenn das Control Panel ein Feature anbietet, das überhaupt nie in keiner Konstellation jemals funktioniert. Da brauchen wir gar nicht drüber diskutieren und das hat auch nichts mit wichtigmachen zu tun.
Bis vor nicht allzulanger zeit wurde grundsätzlich mit globalen einstellungen gearbeitet und nicht mit applikationsspezifischen einstellungen. Dies wurde wenn überhaupt über drittanbieter und eigenänderungen durch die grakahersteller (asus etc) angeboten.
Für die allermeisten reichen diese globalen einstellungen zuzüglich der möglichen ingame einstellungen auch vollständig aus.
Für mich nicht. So lange nicht jedes Spiel alle Optionen in Game anbietet (was auf absehbare Zeit kaum der Fall sein wird), braucht man Profile.
Ich weiß dass viele das nicht nutzen. Aber gerade im Midrange Bereich, wo man eben nicht jedes Spiel in 1280x1024 mit 16xAA und 16xAF spielen kann (als ob das im High-End Bereich ginge :wink:), ist es durchaus sinnvoll und notwendig, für jedes Spiel die Optimale Einstellung getrennt vornehmen zu können.
Und ich will nicht vor dem Start jedes Spieles die Einstellung manuell anpassen müssen, zumal ich mich auch nicht immer an die optimale Einstellung erinnern kann.
Klar, ein Wald-und-Wiesen Spieler, der keine Ahnung von AA und AF hat, den wird das nicht interessieren. Aber die Enthusiasten, von denen wir hier sehr viele haben und die mit die wichtigste Kundengruppe von nVidia ist (da der High-End Bereich nun mal überproportional Umsatz und Gewinn erzeugt) sollte sich durchaus damit auseinandersetzen und das Feature nutzen, finde ich.
Lediglich für benchmarkfetischisten mag eine solche mangelhafte übernahme der einstellungen eine wirklich grössere rolle spielen. Na, dass verstehe ich nun nicht. Was hat ein Benchmark mit Profilen zu tun? Nichts, würde ich sagen. Cheaten in Benches kann man auch ohne Profile.
Ich verstehe also die dramatik nicht wirklich
So lange es Dich nicht interessiert weil Du nicht betroffen bist, ist es für Dich sicherlich nicht dramatisch.
Dramatisch ist es wohl für keinen, aber durchaus sehr ärgerlich. Und dazu leicht zu beheben. Wenn keiner den Fehler mal als Störend meldet, wird er auch nie behoben. Das kanns ja nun nicht sein.
Grestorn
2005-07-25, 10:03:33
Könnte man das nicht über die SID des Objektes (in diesem Fall des Files) lösen?
Die ist doch nur auf Deiner Platte eindeutig. Wenn der Hersteller aber das Profil ausliefert, hat er keine Ahnung ob (FAT32) und wenn ja, welche SID das File auf Deiner Platte hat.
Um es vorweg zu sagen... das mit der EXE-'Erkennung' sehe ich ganz genauso wie zecki... ein Ding der Unmöglichkeit, wenn sich die Devs nicht mal an grundlegende Techniken halten können... abhaken und vergessen... bei Gelegenheit vielleicht mal die Devs bei Blizzard darauf ansprechen (im Falle von Diabolo2 ;-). Oder aber die EXE einfach umbenennen, wenn das geht...
-
Also wenn ich das richtig sehe, dann regt sich Blaire hier doch über Nicht-Applikation folgender 'Features' auf:
"Anisotropic Filter Optimization, Anisotropic Sample Optimization, Trilinear Optimization, Neg. LOD BIAS Clamp, MipMaps erzwingen, LOD BIAS und das neue SLI Anti-Aliasing Feature."
Da wären dann zum einen die 'Optimierungen'. Klar könnte man meinen, dass die eine oder andere Optimierung in dem einen Fall mehr zum Tragen kommt, oder auch nicht... aber das ist zweitrangig. Ich persönlich schalte alle diese 'Optimierungen' einfach grundsätzlich aus, insofern ist das für mich ein "nonIssue"... für ein paar Benchmark-Fetischisten mag das ja wichtig sein.
Das neg.LOD Bias Clamp steht bei mir IMMER auf 'Clamp', weil negative Werte hier einfach IMMER störend wirken. Ergo: gut, dass es ein uneingeschränkt globales Feature ist. Und auch das "MipMaps erzwingen" werden die meisten Leutz nicht einmal zuordnen können... auch hat es in den meisten Fällen nicht einmal einen Effekt. Das Teil müsste man also erst einmal 'reparieren', um es sinnvoll nutzen zu können.
Bleibt noch das SLI-AA, welches ja bekanntermaßen im neuen Treiber sogar ein Feature ist, welchen nur über Aktivierung via Coolbits zur Verfügung steht. Insofern ist dieses noch absolut Alpha... und hat ganz sicher keinen Anspruch auf 100%'ige Funktionalität. In späteren Treibern, bei welches dieses Feature offiziell wird, wird vermutlich auch die Profil-Zuweisung entsprechend funktionieren.
That's it!
Razor
P.S.: sicher sind das 'Probleme'... aber deswegen so einen Aufriß zu machen? Neee...
Stellt Euch mal vor, es wäre so wie bei ATI, wo es nur ein "Alles-oder-Nicht" Häkchen geben würde... ;)
ShadowXX
2005-07-25, 10:10:50
Die ist doch nur auf Deiner Platte eindeutig. Wenn der Hersteller aber das Profil ausliefert, hat er keine Ahnung ob (FAT32) und wenn ja, welche SID das File auf Deiner Platte hat.
Welcher Hersteller (ausser nV selbst) liefert denn Profile mit?
Klar, mit FAT32 würde das nicht laufen, aber als zusätzliche Alternative zum reinen Dateinamen wäre es nicht schlecht.
(Anders ausgedrückt: nVs mitgelieferte Profile laufen weiter über den Dateinamen, wenn man selber Profile anlegt und NTFS benutzt läufts über die SIDs und wenn man FAT32 benutzt benutzt er wieder die Dateinamen (als Fallback quasi). Diejenigen die FAT32 benutzen sind dann zwar etwas eingeschränkter als die die NTFS benutzen, aber irgendetwas ist ja immer...).
Exxtreme
2005-07-25, 10:18:51
Stellt Euch mal vor, es wäre so wie bei ATI, wo es nur ein "Alles-oder-Nicht" Häkchen geben würde... ;)
:rolleyes:
Was nützt mir ein Feature, welches zwar im CP zur Verfügung steht, es aber nicht funktioniert? Und bei ATi hast du nicht nur die Wahl zwischen alles oder nichts. Du hast die Wahl zwischen alles, ein wenig und nichts. Und es funktioniert wenigstens.
ShadowXX
2005-07-25, 10:26:35
:rolleyes:
Was nützt mir ein Feature, welches zwar im CP zur Verfügung steht, es aber nicht funktioniert? Und bei ATi hast du nicht nur die Wahl zwischen alles oder nichts. Du hast die Wahl zwischen alles, ein wenig und nichts. Und es funktioniert wenigstens.
Es funktioniert ja. Es gibt nur ein paar Ausnahmen, bei denen es keine Wirkung hat (und das dazu bei welchen, die wirklich nicht so wichtig sind, da an den Optimierungseinstellungen sowieso kaum jemand was per Game ändert.)
Und die Erkennung über den exe-Namen, ist nunmal die einzige, die definitiv auf allen Plattformen und unter allen Filesystemen läuft.
warper
2005-07-25, 10:28:07
Wie wärs mit einer MD5 Erkennung der exe Datei?
zeckensack
2005-07-25, 10:30:41
Es funktioniert ja. Es gibt nur ein paar Ausnahmen, bei denen es keine Wirkung hat (und das dazu bei welchen, die wirklich nicht so wichtig sind, da an den Optimierungseinstellungen sowieso kaum jemand was per Game ändert.)
Und die Erkennung über den exe-Namen, ist nunmal die einzige, die definitiv auf allen Plattformen und unter allen Filesystemen läuft.Heh. Scheiße nur dass wenn der Prozess im Kompatibilitätsmodus läuft, nur noch der 8.3-Name geholt werden kann :usad:
Grestorn
2005-07-25, 10:31:43
Ich behaupte nicht, dass man nicht damit leben kann.
Ich finde es nur sehr ärgerlich. Das ganze Thema Einstellungen ist ohnehin schon unübersichtlich genug. Die meisten wollen sich damit deswegen auch nicht abgeben.
Wenn es dann noch so verbuggt ist, und man sich noch nicht mal sicher sein kann, dass die Einstellungen auch so verwendet werden wie man sie vornimmt, dann verlieren die meisten die Lust und lassens ganz bleiben.
Wenn ich ein Profil mache und die AA und AF Einstellungen offensichtlich sichtbar verwendet werden, dann gehe ich auch davon aus, dass alle anderen Einstellungen verwendet werden.
Ich möchte nicht wissen, wieviel schon hier und an andere Stelle über Artefakte, Bildfehler, schlechte Qualität, nicht funktioniernede Features usw. diskutiert wurde, nur weil das Panel und der Treiber die Einstellungen nicht fehlerfrei so wie der Anwender sie vorgenommen hat, in die Praxis umsetzen (das Panel hat nämlich zusätzlich noch äußerst haarsträubende Fehler, je nach Treiberversion, aber davon fang ich lieber gar nicht an).
zeckensack
2005-07-25, 10:32:49
Wie wärs mit einer MD5 Erkennung der exe Datei?Stichwort: Patch.
(del676)
2005-07-25, 10:32:57
Wie wärs mit einer MD5 Erkennung der exe Datei?
patches und 100 verschiedene sprachen ;)
warper
2005-07-25, 10:41:16
errr, k :x
Ich finde Grestorn hat recht, das App-Feature sollte noch verbessert werden. Ich selbst habe es nur einmal ausprobiert (als es neu hinzugekommen ist), musste aber schnell feststellen, dass ich dennoch ins Control-Panel gehen musste um die letzten Einstellungen "von Hand" vorzunehmen. Das sind bei mir z. B. oft Gammacontrol und manchmal Digitale Schwingung (beide sind in App-Profilen nicht berücksichtigt).
Wenn ich mir das rumfummeln am Treiberpanel gänzlich sparen könnte, würde ich Treiber-Profile anlegen, so allerdings bleibt es bei mir gänzlich ungenutzt!
Leute die sich nicht die Optimalen Settings für alle Spiele merken möchten, sind allerdings (wie ich finde) ausreichend bedient mit den Optionen die das App-Profil einschliesst.
Ein Bug ist das für mich jedoch auch nicht, schon gar kein schwerwiegender!
Grestorn
2005-07-25, 12:11:35
Das sind bei mir z. B. oft Gammacontrol und manchmal Digitale Schwingung (beide sind in App-Profilen nicht berücksichtigt).Doch, gerade diese beiden Einstellungen kannst Du in ein Profil aufnehmen. Du musst die gewünschten Einstellungen auf der ControlPanel Seite nur unter einem Namen speichern (Farbschema heißt das glaub ich), und dann kannst Du dieses in jedem Profil als Farbschema eintragen.
Und das funktioniert sogar :)
Hey danke Grestorn, damit gewinnt das Feature für mich gleich wieder an Bedeutung. Also, wenn das schon mit der ersten ForceWare ging (55er ?), wo das eingeführt wurde...
...Gott ist das peinlich...
ich kenn mich mit meinem Treiber-Panel nicht aus... :redface:
Danke nochmal, werde es heute Abend gleich probieren!
tombman
2005-07-25, 19:40:45
grestorn: mach doch einfach nhancer als "watcher" Programm, was eben die global Einstelllungen bei jedem game launch MITÄNDERT und dann bei beenden des games wieder auf die Werte setzt, die vor dem game launch eingestellt waren. So kannst du absolut sicher sein, daß jedes game genauso rennt wie nhancer das will.
Ob das von einem Userspace-Program möglich ist? Naja vielleicht mit einem Fensterhaken ;)
Demirug
2005-07-25, 20:50:23
Ob das von einem Userspace-Program möglich ist? Naja vielleicht mit einem Fensterhaken ;)
Du brauchst eine DLL und einen Global Hook dafür.
Fensterhaken, sagte ich doch ;)
Im NV-Treiber ist einiges im Argen. Beispiel: Ich habe mal für den TFT und den CRT Bildschärfung probiert, und dann beides wieder auf Standard gestellt. Aber nach jedem Reboot ist jetzt beim CRT noch Bildschärfung aktiv. Obwohl der Slider ganz links steht. Ich muss erst in das Treiber-Panel, zur Farbkorrektur, und dann stellt er tatsächlich die Bildschärfung auf Null – kann dann also mit "Abbrechen" wieder raus gehen.
Dann gibt es noch das Verhalten, dass gewisse "Optimierungen" je nach Applikation aktiv sind, ohne dass dem User was davon gesagt wird.
Was auch nervt: Je nach Treiber ist mal diese mal jene "Optimierung" Treiber-Standard.
Vieles am CP ist gut gedacht – und schlecht gemacht. Zu kleine Dialogfenster, zu unübersichtliche Struktur, und zu oft das Verhalten, dass der Treiber nicht das tut, was der User eingestellt hat.
Ich bin kein registrierter Entwickler bei nVidia, und da ich auch kein Spiel oder 3D-Applikation entwickle, glaube ich nicht, dass ich viel Glück mit einer Registrierung hätte oder gar von irgendeiner Person gehört werden würde, die dem Treiberteam zumindest nahe steht.
Probiers mal mit einer Mail an devrelfeedback@nvidia.com. Einem brauchbaren Bugreport ist man dort nicht abgeneigt.
Grestorn
2005-07-26, 08:43:23
grestorn: mach doch einfach nhancer als "watcher" Programm, was eben die global Einstelllungen bei jedem game launch MITÄNDERT und dann bei beenden des games wieder auf die Werte setzt, die vor dem game launch eingestellt waren. So kannst du absolut sicher sein, daß jedes game genauso rennt wie nhancer das will.
Das wäre eine 100%ige Abkehr von der jetzigen Methode.
Zugegeben, sie hat einiges für sich, und ich habe schon länger darüber nachgedacht. Man könnte dadurch einige interessante Dinge machen, wie dynamisches Übertakten und Support anderer Hersteller, wie z.B. ATI.
Allerdings bräuchte ich dafür einiges an Zeit und müsste mir in einigen Dingen erst mal das fehlende Know-How aneignen. Bisher hatte ich weder das Vergnügen mich mit 3D-Applikationen beschäftigen zu können noch das Bedürfnis irgendwelche GlobalHooks zu installieren.
Mal sehen, was ich so in den dunklen Wintermonaten treiben werde...
Marc-
2005-07-26, 09:48:52
Das wäre eine 100%ige Abkehr von der jetzigen Methode.
Zugegeben, sie hat einiges für sich, und ich habe schon länger darüber nachgedacht. Man könnte dadurch einige interessante Dinge machen, wie dynamisches Übertakten und Support anderer Hersteller, wie z.B. ATI.
Allerdings bräuchte ich dafür einiges an Zeit und müsste mir in einigen Dingen erst mal das fehlende Know-How aneignen. Bisher hatte ich weder das Vergnügen mich mit 3D-Applikationen beschäftigen zu können noch das Bedürfnis irgendwelche GlobalHooks zu installieren.
Mal sehen, was ich so in den dunklen Wintermonaten treiben werde...
zumal einige leuts vielleicht derartige hooks garnet gerne hätten. Zumindest ich hätte kein interesse daran.
Hooks sind vor allem extrem schwierig zu debuggen.
Was auch nervt: Je nach Treiber ist mal diese mal jene "Optimierung" Treiber-Standard.
also bei mir war bis jetzt immer quality mit Tri-opt und Sample-opt standard, und das bei jedem treiber.
einzig lod-clamp ist mal standardmäßig ein, meistens aber aus.
Blaire
2005-07-26, 16:54:37
Kann ich bestätigen
also bei mir war bis jetzt immer quality mit Tri-opt und Sample-opt standard, und das bei jedem treiber.
einzig lod-clamp ist mal standardmäßig ein, meistens aber aus.Ich habe in Erinnerung, dass brilineare Filterung in der Regel aktiviert ist, und oft diese MIP-Filter-"Optimierung" (nur bi-AF auf Stages > 0.) Dass die Sample-"Optimierung" (sprich, die Unterfilterung) bei Q aktiv ist, und sich nicht mal abschalten lässt (nur via HQ) sehe ich als Bug, der entsprechende Haken war soweit ich mich daran erinnere beim 77.72 nicht gesetzt.
Ich habe in Erinnerung, dass brilineare Filterung in der Regel aktiviert ist, und oft diese MIP-Filter-"Optimierung" (nur bi-AF auf Stages > 0.) Dass die Sample-"Optimierung" (sprich, die Unterfilterung) bei Q aktiv ist, und sich nicht mal abschalten lässt (nur via HQ) sehe ich als Bug, der entsprechende Haken war soweit ich mich daran erinnere beim 77.72 nicht gesetzt.
die untefilterung bei Q und niedriger ist eine andere optimierung als die extra aniso-sample-optimierung, was imo schon immer so war. ein bug ist das imo nicht (sonst bräuchte man ja kein HQ wenn Q mit deaktivierten optimierungen das gleiche ist)
die mip-filter-optimierung (bi auf stages >0) war bei mir noch nie standardmäßig aktiv, und ist auch ziemlich sinnlos wenn eh schon "brilinear" aktiviert ist.
die untefilterung bei Q und niedriger ist eine andere optimierung als die extra aniso-sample-optimierung, was imo schon immer so war. ein bug ist das imo nicht (sonst bräuchte man ja kein HQ wenn Q mit deaktivierten optimierungen das gleiche ist)
die mip-filter-optimierung (bi auf stages >0) war bei mir noch nie standardmäßig aktiv, und ist auch ziemlich sinnlos wenn eh schon "brilinear" aktiviert ist.Imo ist das schon ein Bug, wenn es für Unterfilterung einen Extra-Schalter gibt, der aber nicht das tut was er vorgibt, zu tun.
Der Unterschied von HQ zu Q alles off könnte "Intellisampling" sein, also die Verringerung des maximalen AF-Grades je nach Texturinhalt.
Wenn man rein bilinear filtert, bringt das gegenüber brilinearer Filterung schon noch einen Geschwindigkeitsvorteil.
Könnt ihr nicht einfach was coden das man einfach allen Mist ausschaltet ^^
Wir wissen doch schon gar nicht mehr was ein "gutes sauberes" Bild ist, da wir nur beschnittene Grafikkarten im Einsatz haben und ältere Hardware kann heutige Grafik nicht darstellen...
Wenn man rein bilinear filtert, bringt das gegenüber brilinearer Filterung schon noch einen Geschwindigkeitsvorteil.
aber nur mehr sehr gering, und kaum messbar, wahrscheinlich limitiert dann immer stärker die bandbreite.
aber nur mehr sehr gering, und kaum messbar, wahrscheinlich limitiert dann immer stärker die bandbreite.Warum sollte dann plötzlich die Bandbreite stärker limitieren? Von brilinear zu bilinear könnte etwa so viel Füllrate sparen wie von tri- zu brilinear. (Ich weiß nicht, wie dick das reine bi-Band aktuell ist.)
Warum sollte dann plötzlich die Bandbreite stärker limitieren? Von brilinear zu bilinear könnte etwa so viel Füllrate sparen wie von tri- zu brilinear. (Ich weiß nicht, wie dick das reine bi-Band aktuell ist.)
naja, die trilineare füllrate ist nur halb so hoch wie die bilineare, ergo ist mehr bandbreite/pixel verfügbar.
mit brilinear spart man ja viel füllrate aber kaum bandbreite, also wandert der flaschenhals logischerweise von füllrate in richtung bandbreite. (bei niederwertiger filterung)
wenn die bandbreite immer gleich limitieren würde, würde ja trilinearer filterung gegenüber bilinearer (bei grakalimitierung) immer 50% performance kosten, was real aber nicht der fall ist.
naja, die trilineare füllrate ist nur halb so hoch wie die bilineare, ergo ist mehr bandbreite/pixel verfügbar.
mit brilinear spart man ja viel füllrate aber kaum bandbreite, also wandert der flaschenhals logischerweise von füllrate in richtung bandbreite. (bei niederwertiger filterung)
wenn die bandbreite immer gleich limitieren würde, würde ja trilinearer filterung gegenüber bilinearer (bei grakalimitierung) immer 50% performance kosten, was real aber nicht der fall ist.Mit brilinearer Filterung spart man auch Bandbreite. Man hat eine leichte Verschiebung, weil der sonstige Bandbreiten-Anteil pro Pixel (Color und Z) ja gleich bleibt. Bei voller Füllratenlimitierung und gesetz dem Fall, dass es nur Texturverkleinerung aber keine Texturvergrößerung gibt, kostet trilinear vs. bilinear tatsächlich ca. 50% Geschwindigkeit – ein Füllratenproblem. Tatsächlich ist trilineare Filterung pro Takt bandbreitenmäßig etwas weniger anspruchsvoll als bilineare, aber bei Texturkomprimierung ist Texturbandbreite kein allzu großes Problem. Ich würde in jedem Fall primär auf die Füllratenersparnis gucken, und da hat man bei bi- vs. brilinear noch einen Vorteil, der im Falle der Füllratenlimitierung was bringt.
Tatsächlich ist trilineare Filterung pro Takt bandbreitenmäßig etwas weniger anspruchsvoll als bilineare, aber bei Texturkomprimierung ist Texturbandbreite kein allzu großes Problem.
aber mit bri/bilinearer filterung erspart man sich gegenüber trilinear ja nur texturbandbreite, was ja wie du sagst kaum ein problem darstellt (komprimierte texturen sind eigentlich standard)
und trilinear kostet real (zumindest ohne AF) ja kaum mehr leistung gegenüber bilinear, außer in irgendwelchen synthies.
ich kann auch kaum performancevorteile mit der mip-optimierung messen, wenn bereits brilinear aktiv ist. (ohne brilinear bringt es noch ein wenig)
aber mit bri/bilinearer filterung erspart man sich gegenüber trilinear ja nur texturbandbreite, was ja wie du sagst kaum ein problem darstellt (komprimierte texturen sind eigentlich standard)Man spart auch Füllrate.
ich kann auch kaum performancevorteile mit der mip-optimierung messen, wenn bereits brilinear aktiv ist. (ohne brilinear bringt es noch ein wenig)Weil die Füllratenlimitierung nicht stark genug ist.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.