Shaderoptimierung bei NVIDIA? (Split aus ATi Project "Loci")

[Demirug]

Originally posted by Richthofen
Und wie Mufu bei rage3d hat verlauten lassen in einem der Threads versucht Nvidia gerade auf der Code Seite sehr viel in nächster Zeit rauszuholen.

Ich zitiere das mal:
"
There's something nV are doing with shader code that is pretty sneaky and gives them a massive boost. I can't go into any more detail because I'll get my balls chopped off, but I'm sure it'll come to light eventually and you die-hard ATi-types will go crazy. Couldn't care less, myself - it's not exactly "cheating", they've just taken game-specific optimisation to a new level. Anyway, we'll see what happens...
"

@Demi hast du eine Ahnung was der hier genau meint?
Riecht nach dem Deto50, der ja angeblich erheblich größer geworden sein soll vom Umfang.

Ich kenne da nur eine Sache die da bei NVIDIA gerade ablaufen soll aber das "game-specific optimisation" von mufu iritiert mich da etwas.

nunja das was ich gehört habe (ist aber nur ein Gerücht) ist das NVIDIA an einem Shaderoptimizer arbeitet. Bisher sollen die Shader sehr direkt umgesetzt werden was dem NV3x Chips nicht wirklich bekommt. Dieser Shaderoptimizer soll nun folgendes machen. Er nimmt den Shadercode und übersetzt in in das interne Zwischenformat das auch der Cg Compiler benutzt und lässt die optimizer darüberlaufen. Zum einen soll dadurch die Anweisungsrheienfolge für den Chip verträglicher gemacht werden und zum zweiten gibt es da noch einen gemeinen Trick bezüglich der Datenformate. Der optimizer soll auch erkennen wann es möglich ist mit geringerer Genauigkeit zu arbeiten ohne das es visuelle Folgen hat.

Möglicherweise ist die Sache aber noch nicht ganz fertig und NVIDIA hat als Zwischenlösung von der Rechnerfarm (mit Handeingriffen) für die wichtigen Spiele für alle Shader den shadermicrocode vorberechnet und fest im Treiber hinterlegt (was ich ja auch schon beim 3dmurks vermutet habe).

[betasilie]

Läuft dieser Optimizer immer oder testet er einmal die neue Software und erstellt dann ein dauerhaftes "Übersetzungsprofil" für das entsprechende Spiel?

[Demirug]

Originally posted by betareverse
Läuft dieser Optimizer immer oder testet er einmal die neue Software und erstellt dann ein dauerhaftes "Übersetzungsprofil" für das entsprechende Spiel?

betareverse, ich weiss noch nicht einmal ob es diesen Optimizer wirklich gibt oder ob sich das jemand nur zusamengereimt hat und es dann angefangen hat die Runde zu machen wozu ich ja jetzt dann auch beigetragen hätte. Wobei etwas in der Art muss laufen da NVIDIA ja auch gegenüber JC entsprechende Andeutungen gemacht hat.

In Abhängigkeit wie schnell dieser Optimizier ist würde ich es grundsätzlich Online machen oder eine Datenbank anlegen. Da ich mich zum Teil ja selber mit solchen optimierungsprobleme rumschlage und weiss das dafür eine menge CPUZeit verbraten werden kann tendiere ich zu der Datenbank in der einmal optimierte Shader hinterlegt werden.

Wobei eine Datenbank mit optimierten Shader natürlich auch noch den Vorteil hätte das man diese bei Treiberupdates mit von Hand noch etwas weiter verbesserten Shadern füttern könnte. Da NVIDIA ja gute Beziehungen zu den Entwicklern hat bekommen sie ja oft die Spiele schon lange vor dem offizielen Release was man dafür natürlich ausnutzen könnte.

Man könnte auch den Treiber ein bischen CPU zeit abzweigen lasse um nebenbei wenn gerade kein Spiel läuft noch ein bischen an den Shadern zu optimieren. Wobei das dann wohl doch etwas zu krass wäre.

[betasilie]

Ich habe da an einen Optimizerrun gedacht, wobei das Spiel eine gewisse Zeit in diesem Modus laufen muss und dann ein Profilerstellt wird.

Das mit der Onlinefunktion hört sich aber auch gut an. Da könnte man sich einfach alle paar Tage via Treiberpannel die neusten Profile downloaden.

Eine Echtzeitübersetzung/optimierung der Shader stelle ich mir sehr resourcenfressend vor.

[Demirug]

Für eine reine Shaderoptimierung ist ein Profiler in dem Sinn nicht notwendig. Das hängt damit zusammen das bei erzeugen eines Shaders der Shadercode ja komplett übergeben wird und die Zielplatform (der Grafikchip) ja auch bekannt ist. Daher kann ein Shader bereits beim erzeugen komplett optimiert werden. Das Shaderkonzept von DX erlaubt solche Optimierungen ja auch ausdrücklich.

Über das Panel??? Naja ich glaube nicht das NVIDIA so weit gehen würde. Aber möglicherweise telefoniert der Treiber auch von aleine nach Hause. Ich weiss das sowas Böse ist aber für die meisten Anwender die nicht so viel Ahnung haben währe das sicherlich besser wenn der Treiber das alles von aleine machen würde.

[zeckensack]

Ich halte eigentlich die 'just in time'-Optimierung von Shadern am sinnvollsten. Glaubt mir, ich hab's selbst schon gemacht :D

Der Punkt ist einfach, daß es viel zu viele Kombinationen gibt, man kann unmöglich alle denkbaren Shaderprogramme in eine Datenbank schmeißen und voroptimieren. Geht nicht.

Ergo (IMO): Zur Laufzeit, beim ersten Binden des Shaders. Wird der gleiche Shader später erneut benutzt, kann man ihn leicht identifizieren über Hash-Lookup&Vergleich oder gleich über ein Shader-Handle (wenn die API das unterstützt).

Die meisten Shader (meiner Erfahrung nach) werden bereits im ersten Frame oder kurz danach benötigt, es ist für die 'Flüssigkeit' eines Spiels absolut nicht schlimm, wenn die ersten zwei, drei Frames länger dauern. Danach ist dann alles in Butter.

Btw, ich finde dieses Bild würde schön in den Kontext passen:
edit: oder doch lieber gleich dieses:
http://www.tech-report.com/reviews/2003q2/geforcefx-5200/sam4.gif

*jetzt neu*
Deto 43.45
Quelle (http://www.tech-report.com/reviews/2003q2/geforcefx-5200/index.x?pg=1)

[Demirug]

Das man nicht alle möglichen Shader in einer Datenbank speichern kann ist klar. Wenn die optimierung aber sehr aufwendig ist kann man sie einmal vornehmen und diesen Shader dann in einer Datenbank hinterlegen und wenn er beim nächsten Start des Spiels wieder gebraucht wird er einfach aus der Datenbank geholt. Mit einem Hashcode über den Binärcode des Shaders sollte das recht schnell gehen.

Bei DX funktioniert das mit den Shadern wie folgt. Bei erzeugen das Shaders (CreateVertexShader oder CreatePixelshader) bekommt der Treiber den Binärcode des Shaders und ein Handle. Ab diesem Zeitpunkt wird ein Shader nur noch über diese Handle angesprochen.

Da man normalerweise die Shader ausserhalb des Gameloops anlegt hätte eine optimierung zu diesem Zeitpunkt lediglich auswirkungen auf die Startuptime.

Der Test den du da gepostet hast war das OpenGL oder DX?

[zeckensack]

Originally posted by Demirug
Das man nicht alle möglichen Shader in einer Datenbank speichern kann ist klar. Wenn die optimierung aber sehr aufwendig ist kann man sie einmal vornehmen und diesen Shader dann in einer Datenbank hinterlegen und wenn er beim nächsten Start des Spiels wieder gebraucht wird er einfach aus der Datenbank geholt. Mit einem Hashcode über den Binärcode des Shaders sollte das recht schnell gehen.

Bei DX funktioniert das mit den Shadern wie folgt. Bei erzeugen das Shaders (CreateVertexShader oder CreatePixelshader) bekommt der Treiber den Binärcode des Shaders und ein Handle. Ab diesem Zeitpunkt wird ein Shader nur noch über diese Handle angesprochen.OGL kann das allgemein erst ab ARB_fragment_program/ARB_vertex_program (ATI_fragment_shader kann's auch schon).
Wovon ich sprach war Glide2x, was in seiner funzeligen zweistufigen Combiner-Pipe ca 50000 verschiedene zulässige Kombinationen kennt. Was mit 'richtigen' Shadern möglich ist, wage ich mir garnicht erst auszumalen.

Da man normalerweise die Shader ausserhalb des Gameloops anlegt hätte eine optimierung zu diesem Zeitpunkt lediglich auswirkungen auf die Startuptime.Exakt. Unter OpenGL jedoch auf NV-Karten nur ab FX, und auch nur mit speziellem Extension-Support möglich.
Der Test den du da gepostet hast war das OpenGL oder DX? Steht im Test nicht drin, aber TR bencht SeSam AFAIR unter OpenGL:

[Demirug]

ja, bei DX7 fummelt man sich das "Pixelshading" ja auch innerhalb des Gameloops zusammen und bei den RegCombiner unter OpenGL ist es AFAIK ja auch nicht anders.

Ich habe inzwischen den Test bei TR auch angezeigt bekommen. Da diese "merkwürdige" Startverhalten sich aber in abhängigkeit der AA und AF Settings ändert habe ich irgendwie den Eindruck das es was anderes sein muss was da abläuft den eine reine Shaderoptimierung dürfte sich nicht so sehr von AA und AF beeindrucken lassen.

[zeckensack]

Originally posted by Demirug
ja, bei DX7 fummelt man sich das "Pixelshading" ja auch innerhalb des Gameloops zusammen und bei den RegCombiner unter OpenGL ist es AFAIK ja auch nicht anders.Da habe ich oben quasi Unsinn erzählt:
Mit display lists ist es auf jedem Techlevel möglich, aus einzelnen Combiner-Settings monolithische 'Shader-Objekte' zu konstruieren. Display Lists erfassen ja auch state changes.
Ich glaube aber eher weniger, daß gängige Engines und Treiber auf diese Variante ausgelegt sind, wiederum mit der Begründung der kombinatorischen Explosion der Datensätze.

Ich habe inzwischen den Test bei TR auch angezeigt bekommen. Da diese "merkwürdige" Startverhalten sich aber in abhängigkeit der AA und AF Settings ändert habe ich irgendwie den Eindruck das es was anderes sein muss was da abläuft den eine reine Shaderoptimierung dürfte sich nicht so sehr von AA und AF beeindrucken lassen. Ich habe den Verdacht, daß NV da unter Umständen schon ein paar Schritte weiter ist, und ein load balancing betreibt, das unter hoher Last die Optimierung der Shader verzögert.

Vielleicht noch nicht ganz ausgereift, das ganze ;)

[Unregistered]

Mal eine kurze Frage von mir:
Tja, wie formuliere ich das jetzt am besten?

Ist euch da nicht ein bisschen "unwohl", wenn NV (wie ich das jetzt so verstehe) "Game-spezifische" Shader-Optimierungen in die Treiber einbaut?

Ich weiß ja nicht, ob das schon Gang und Gäbe ist (denke mal auf 3DMark wurde schon immer spezifisch optimiert), aber wäre nicht in der Theorie ein Treiber vorzuziehen, der allgemeine Optimierungen aufweist, d. h. mit jedem Spiel gleich gut (oder selbst programmierten 3D-Apps) funktionieren sollte, anstatt ein hochkomplexes Treiber-Konstrukt, dass für spezifischen Games (oder vielleicht sogar nur spezifischen Builds dieser Games) optimierte Pfade/Shaderoptimierungen aufweist?

Kurz gesagt, was ist besser:
Extrem schnell mit spezifischen Engines auf Kosten der Kompatibilität, oder "annehmbar" langsamer, dafür bessere Kompatibilität auch zu nicht so bekannten Anwendungen/Spielen?

Grüße

BW

[Richthofen]

Solange ich keine herben Abstriche bei der BQ hinnehmen muss kann NV seine Treiber auf Spieleengines anpassen wie sie wollen.
Die GF FX Architektur ist nunmal so, dass mit spezieller kompilierung oder CG codierung von Anfang an sehr viel Performance rausgeholt werden kann.
Wenn Nvidia die Ressourcen und auch den Willen dazu hat dass zu machen, dann ist mir das Recht. So bekomm ich halt mehr aus meiner Graka. Find ich ok. Es darf nur nicht so enden, dass überall massiv der BQ gedreht wird um Performance zu gewinnen. Das fände ich dann nicht so gut.
Aber wenn ich es kaum sehe, oder an der BQ gar nichts gedreht werden muss, dann isses mir wurscht.

[Mr. Lolman]

Kann der Hund das Fleisch nicht beissen, dann bekommt ers halt in kleinen Würfelchen vorgesetzt. ;)

[Demirug]

Originally posted by Unregistered
Mal eine kurze Frage von mir:
Tja, wie formuliere ich das jetzt am besten?

Ist euch da nicht ein bisschen "unwohl", wenn NV (wie ich das jetzt so verstehe) "Game-spezifische" Shader-Optimierungen in die Treiber einbaut?

Ich weiß ja nicht, ob das schon Gang und Gäbe ist (denke mal auf 3DMark wurde schon immer spezifisch optimiert), aber wäre nicht in der Theorie ein Treiber vorzuziehen, der allgemeine Optimierungen aufweist, d. h. mit jedem Spiel gleich gut (oder selbst programmierten 3D-Apps) funktionieren sollte, anstatt ein hochkomplexes Treiber-Konstrukt, dass für spezifischen Games (oder vielleicht sogar nur spezifischen Builds dieser Games) optimierte Pfade/Shaderoptimierungen aufweist?

Kurz gesagt, was ist besser:
Extrem schnell mit spezifischen Engines auf Kosten der Kompatibilität, oder "annehmbar" langsamer, dafür bessere Kompatibilität auch zu nicht so bekannten Anwendungen/Spielen?

Grüße

BW

:cop: Gerüchte :cop:

Da die NV3x Architektur sehr stark mit der bisherigen Art des Fragmentshadings bricht ist es erforderlich um die maximale Performances aus dem Chip zu pressen das der über die API angeforderte Effekt auf diese neue Architektur optimiert wird.

In Abhängikeit welche API zum Einsatz kommt wird diese Optimierungsarbeit von unterschiedlichen Teile des Treibercodes erledigt.

Die derzeitigen Treiber sollen dabei eine unterschiedlich gute optimierung vornehmen.

DX7 sowie PS 1.1 - 1.3 sollen bereits sehr weit sein. PS >= 1.4 dagegen laufen gröstenteils in einem Safemodus bei dem zuerst einmal nur darauf geachtet wird das der Shadercode korrekt läuft. Ähnliches gilt für OpenGL.

Das andere "Problem" das NVIDIA derzeit hat ist das ein für den R300 optimierter 2.0 Shader sowie 1.4 Shader allgemein der NV3x Architektur ohne optimierung einfach nicht schmecken. So erzeugt zum Beispiel der HLSL-Compiler von MS PS 2.0 code der NVIDIA gar nicht gefallen dürfte aber ATI findet in gut. NVIDIA muss also optimieren.

Dummerweise brauchen sie dafür wohl Teile des CG-Projekts und da waren leider noch ein Bugs drin so das man das ganze nicht in den Treiber einbauen wollte.


Es ist also nicht wirklich zu befürchten das die Optimierungen dazu führen das die Performance bei Spielen die dabei noch nicht berücksichtigt werden schlimmer wird also sie jetzt schon ist. Im Laufe der Zeit werden die Optimierungen aber sicherlich immer allgemeiner werden.

[Benedikt]

Zuerst mal ein herzliches Dankeschön, so hat das noch keiner vorher erklärt... ;-)

Mal sehen, ein paar Sachen hab ich gefunden, die mich auch noch interessieren..

DX7 sowie PS 1.1 - 1.3 sollen bereits sehr weit sein. PS >= 1.4 dagegen laufen gröstenteils in einem Safemodus bei dem zuerst einmal nur darauf geachtet wird das der Shadercode korrekt läuft. Ähnliches gilt für OpenGL.
Hmm, steh ich da jetzt auf der Leitung oder sollte NV30 gar keine PS1.4 unterstützen (siehe 3DMark 03)????
--> Ist denn NV30 einfach um neue Standards per Treiber erweiterbar?

Dummerweise brauchen sie dafür wohl Teile des CG-Projekts und da waren leider noch ein Bugs drin so das man das ganze nicht in den Treiber einbauen wollte.
Meinst du dass CG Bugs hat oder der Treiber? Ich dachte Cg sei von NVidia und das impliziert doch perfekte Verwendbarkeit und Anpassung an eigene Produkte oder?

Allgemein lässt sich sagen, dass das was gerade bei NV abläuft, ein agressives Optimieren "ohne Rücksicht auf Verluste" zu sein scheint oder, auch wenn dabei möglicherweise Qualität draufgeht??

Grüße und sorry für das etwas längere Posting... :-)

BW

[Demirug]

Originally posted by Benedikt
Hmm, steh ich da jetzt auf der Leitung oder sollte NV30 gar keine PS1.4 unterstützen (siehe 3DMark 03)????
--> Ist denn NV30 einfach um neue Standards per Treiber erweiterbar?

PS 1.4 liegen vom Technischen Anspruch unterhalb von PS 2.0.

Zum Beispiel:

PS 1.4 6 Texturen, 28 Anweisungen
PS 2.0 16 Texturen, 96 Anweisungen

Der NV30 hat nun keine spezifische PS 1.4 Hardware sondern muss mit den mitteln die er hat die PS 1.4 Funktionalität nachbilden. Der NV30 hat aber in dem Sinn auch keine DX7, PS1.1-1.3, PS 2.0 Hardware. Der NV30 hat seine CineFX Hardware und der Treiber muss nun zwischen den unterschiedlichen Anforderungen (DX7 PS x.y OpenGl Extensions) und der CineFX Hardware als übersetzer auftreten.

Durch den Treiber ist der Chips also auf neue Standards erweiterbar aber nur wenn der Standard nichts verlangt was der Chip nicht nachbilden kann. Das gleiche trift aber auf jeden Chip zu.


Meinst du dass CG Bugs hat oder der Treiber? Ich dachte Cg sei von NVidia und das impliziert doch perfekte Verwendbarkeit und Anpassung an eigene Produkte oder?

Allgemein lässt sich sagen, dass das was gerade bei NV abläuft, ein agressives Optimieren "ohne Rücksicht auf Verluste" zu sein scheint oder, auch wenn dabei möglicherweise Qualität draufgeht??

Grüße und sorry für das etwas längere Posting... :-)

BW

Der Cg-Compiler hatte im Codegenerator ein paar Bugs. Nichts dramatisches. Ja Cg ist von NVIDIA und es ist natürlich für die Produkte des eigenen Hauses optimiert aber da es ja noch ein recht junge Produkt ist gibt es eben noch ein paar Kinderkrankheiten.

Was die Qualität/Performance Sache angeht so muss man abwarten was diese optimierungen den nun genau sind. Ich gehe wie gesagt davon aus das es durchaus möglichkeiten gibt ohne Qualitätsverlust die Performances zu erhöhen.

[robbitop]

das was du sagtest demi, hört sich dem P10 sehr ähnlich an..das gefällt mir ..das ist doch mal eine innovative Basis, die durch neue Treiber richtig aufdreht ;)

apropros P10..wann kommt der P20 und wir er diesmal ein Mainstream Chip?

wenn ja stehen ihnen schlimmer Treiberoptimierungen wie jetzt NVidia bevor. Sowas dauert eben, aber nette Basis :)

[Demirug]

Originally posted by robbitop
das was du sagtest demi, hört sich dem P10 sehr ähnlich an..das gefällt mir ..das ist doch mal eine innovative Basis, die durch neue Treiber richtig aufdreht ;)

apropros P10..wann kommt der P20 und wir er diesmal ein Mainstream Chip?

wenn ja stehen ihnen schlimmer Treiberoptimierungen wie jetzt NVidia bevor. Sowas dauert eben, aber nette Basis :)

Was man mit den Treibern wirklich rausholen kann hängt aber auch von möglichen internen Einschränkungen ab. Generel kann man aber sagen das je flexibler die Hardware wird desto mehr kann/muss der Treiber leisten.

Um ehrlich zu sein ist mir immer noch nicht wirklich ganz klar geworden was 3dlabs mit dem P10/P9 gebaut hat. Ausser dem einen übersichtsbild gibt es da ja eigentlich keine zusätzlichen Informatio nen daher ist es auch nicht ganz einfach zu sagen in wie weit diese Chips wirklich programmierbar sind. Wenn OpenGL 2.0 einmal final ist wird man da unter umständen mehr sagen können.