Shader Warming bei Black Ops

[mapel110]

Added an option to pre-cache all shaders during load time. This fixes hitching related to shader compiling on some video cards when viewing an area of the map for the first time.

Drei technische Fragen dazu.
1. Warum ist diese Option anscheinend unter Windows XP nicht notwendig?

2. Warum kann man diese Shader nicht bereits "berechnet" ablegen? So dauert es bei jedem Mapstart etwa 30 Sekunden.

3. Warum haben die Vorgänger-CODs dieses Problem nicht?

[Gipsel]

1. Warum ist diese Option anscheinend unter Windows XP nicht notwendig?Da fällt mir kein Grund ein.
2. Warum kann man diese Shader nicht bereits "berechnet" ablegen? So dauert es bei jedem Mapstart etwa 30 Sekunden.Weil der Shadercompiler im Grafikkartentreiber für jede GPU im Zweifelsfall einen anderen Code erzeugt. Soll das Spiel bei jedem Erscheinen einer neuen GPU ein Update benötigen?
Alternative wäre nach der Installation beim allerersten Aufruf alle Shader durchzunudeln und auf der Platte abzulegen. Allerdings muß man das Spielchen dann eigentlich bei jedem GPU- oder auch nur Treiberwechsel wiederholen. Da darf die Erkennung eines solchen dann nicht schieflaufen. Das Standardprozedere ist es aber, das eben jedes Mal zur Laufzeit neu zu kompilieren.
3. Warum haben die Vorgänger-CODs dieses Problem nicht?Wahrscheinlich weil deutlich weniger anspruchsvolle Shader benutzt wurden.

[=Floi=]

Alternative wäre nach der Installation beim allerersten Aufruf alle Shader durchzunudeln und auf der Platte abzulegen. Allerdings muß man das Spielchen dann eigentlich bei jedem GPU- oder auch nur Treiberwechsel wiederholen. Da darf die Erkennung eines solchen dann nicht schieflaufen.

das hatte battlefield 2 und darüber gibt es genug problem threads. das ist wohl mit das dümmste was man machen kann.


Wahrscheinlich weil deutlich weniger anspruchsvolle Shader benutzt wurden.

optimierung für die konsolen?

[Coda]

Weil der Shadercompiler im Grafikkartentreiber für jede GPU im Zweifelsfall einen anderen Code erzeugt. Soll das Spiel bei jedem Erscheinen einer neuen GPU ein Update benötigen?
Es geht wenn dann um den Shadercache für das DirectX-Assemblat. Das ist unabhängig von der GPU und dem Treiber. An den tatsächlichen Code für die GPU kommt man in Direct3D doch gar nicht ran.

Allerdings ist das Problem hier ein ganz anderes. Die Treiber laden die Shader erst beim ersten Drawcall auf die GPU, und das kann ohne "Warmup" zu Stuttering führen.

1. Warum ist diese Option anscheinend unter Windows XP nicht notwendig?
Reine Treibersache.

2. Warum kann man diese Shader nicht bereits "berechnet" ablegen? So dauert es bei jedem Mapstart etwa 30 Sekunden.
Es ist bereits vorberechnet, es geht darum dass es vom Treiber in das GPU-Format kompiliert und hochgeladen werden muss.

3. Warum haben die Vorgänger-CODs dieses Problem nicht?
Haben sie wohl.

[mapel110]

Warum dauert alleine das Warmup der Shader bei COD7 etwa 30 Sekunden?! Das ist doch viel zu lang. Hinzu kommt ja noch die Maploadtime. Wüsste nicht, dass andere Spiele ähnliches Verhalten zeigen.

Beispielsweise Crysis2-MP-Demo. Da sollten die Shader ja auch sehr komplex sein, auch kein Warmup nötig, kein Ruckeln ingame, geringe Maploadtime.

[Coda]

Frag die Entwickler. Vielleicht bruteforcen sie einfach alle Möglichkeiten durch und nicht nur das was verwendet wird in der Map.

[Gipsel]

Es geht wenn dann um den Shadercache für das DirectX-Assemblat. Das ist unabhängig von der GPU und dem Treiber. An den tatsächlichen Code für die GPU kommt man in Direct3D doch gar nicht ran.

Allerdings ist das Problem hier ein ganz anderes. Die Treiber laden die Shader erst beim ersten Drawcall auf die GPU, und das kann ohne "Warmup" zu Stuttering führen.Nun, die Beschreibung der Änderung bezieht sich direkt auf die JIT-Kompilierung der Shader für die eingebaute GPU. Das habe ich schon verstanden (und daß das erst beim Drawcall passiert, ist mir auch klar, das ist bei GPGPU-Kram auch nicht anders).
Daß die Möglichkeit zum Speichern/Laden/Ausführen direkt der GPU-abhängigen Binaries für Spiele eher eine theoretische ist (mit CUDA/Stream geht die Erstellung von Binaries und zumindest mit Stream kannst Du welche beliebiger! Shadertypen erstellen und auch mit Direct3D- oder OpenGL-Resourcen verknüpfen), gebe ich gerne zu. Ich denke kein Entwickler wird so einen Hack (der eventuell mit der nächsten GPU oder irgendeiner Treiberversion nicht mehr funktioniert, mal ganz abgesehen davon, daß das ziemlich umständlich werden dürfte) in ein Spiel einbauen, da hast Du vollkommen Recht.

[Coda]

Man kann mit Stream tatsächlich Direct3D-Shader substituieren? How crikey :D

[Gipsel]

Man kann mit Stream tatsächlich Direct3D-Shader substituieren? How crickey :D
Substituieren, hmm. Bequem dürfte das wohl nur gehen, wenn man an die normale Direct3D-Pipeline ein Pre- oder Postprocessing dranbastelt. Das geht relativ problemlos (dafür ist es ja auch gedacht). Alles andere wie gesagt wahrscheinlich eher umständlich.

Aber es ist kein Problem einen binären Vertex, Domain- oder was auch immer -Shader zu erstellen und den mit den entsprechenden Direct3D-Buffern zu verlinken (was alleine vielleicht erstmal nicht viel Sinn macht, keine Ahnung ob das dann auch korrekt ausgeführt wird). Dann müßte man das gegebenenfalls "nur noch" der Direct3D-Pipeline unterjubeln. Wie das gehen würde, bin ich im Moment überfragt. Aber ich glaube, das hat auch noch niemand ausprobiert, was eigentlich passiert, wenn man über die Direct3D-Stream-Interoperabilitätsfunktionen mal z.B. einen neuen Vertexshader an einen Vertexbuffer im Direct3D-Kontext bindet. Vielleicht ist es ja einfacher als man denkt?

[Coda]

Ach so. Ich dachte man kann wirklich mit Stream einen Pixelshader bauen ;(

Das man mit den Buffern rummachen kann ist ja nichts neues. Das können CUDA und OpenCL auch.

[Gipsel]

Ach so. Ich dachte man kann wirklich mit Stream einen Pixelshader bauen ;(

Das man mit den Buffern rummachen kann ist ja nichts neues. Das können CUDA und OpenCL auch.
Du kannst (im Gegensatz zu CUDA oder OpenCL) schon explizit einen Pixelshader erstellen (oder jeden anderen Typ), "nur" die korrekte Einbindung in die Pipeline ist mir unklar.

[Coda]

Hätte ich ne AMD-Karte würde ich das jetzt ausprobieren müssen :)

[Krishty]

Allerdings ist das Problem hier ein ganz anderes. Die Treiber laden die Shader erst beim ersten Drawcall auf die GPU, und das kann ohne "Warmup" zu Stuttering führen.
Es ist bereits vorberechnet, es geht darum dass es vom Treiber in das GPU-Format kompiliert und hochgeladen werden muss.Nochmal der Klarheit halber: Die Kompilierung von Bytecode zu GPU-Maschinentext geschieht während CreateXXXShader(); aber das Übertragen des Maschinentexts vom System- in den GPU-Speicher geschieht erst bei der ersten tatsächlichen Nutzung?

Warum sollte man sowas tun? Andere Ressourcen (Texturen, Geometriepuffer) lädt man doch (afaik!) auch zum Zeitpunkt der Erzeugung hoch und nicht erst bei der ersten Nutzung … um eben genau dieses Ruckelproblem zu vermeiden.

[Coda]

Frag mich nicht was genau der Grund dafür ist, das steht aber regelmäßig in Performance-Guides von AMD und NVIDIA.

[del_4901]

Es koennte mit dem Input Assembler zusammenhaengen, dass danach einfach besser optimiert werden kann. Oder er baut unterschiedliche Shader jeh nach Context (Instancing etc.) Es kann aber auch sein, dass Konstanten wegepatcht werden koennen.... who knows...