[DX9] States sortieren, aber wonach?

[Zudomon]

Hi!

Man sollte ja diejenigen wechsel, die besonders Zeitraubend sind, minimieren. Z.B. ist es ja sehr langsam, Texturen zu wechseln.
Die Frage ist nur, wie sieht die Prioritätenliste aus, also wonach sollte man am besten sortieren?
Ist ein Effektwechsel oder ein Texturwechsel langsamer?

Gruß
Zudo

[Krishty]

Edit: Ganz unten die CPU-Zyklen pro API-Call: http://msdn.microsoft.com/en-us/library/bb172234.aspx

[Aramis]

Im Zeitalter von Shadern, die jeweils dutzende von Texturen benötigen, halte ich das Sortieren nach Texturen für unsinnig ... Texturen kann man einzig dahingehend optimieren, dass man sie frühzeitig in den Grafikspeicher vorlädt.

Die Situation, dass der Grafikspeicher zu klein ist um alle regelmäßig benötigten Texturen zu fassen bedeutet sowieso ein Ende des Experiments 'Performance' .. insofern lohnt sich auch da ein Sortieren nach Texturen nicht mehr wirklich.

[DeRaaZuul]

Genau das gleiche habe ich auch mal gesucht.Super!

[Schrompf]

Wir sortieren in der Reihenfolge:

Pass - Rendertarget - Vertexdeklaration - Shader - Textur - Buffer - Parameter

Das kommt auch grob hin nach der Performance-Liste, die Krishty verlinkt hat. Details kann man sich streiten... wir sortieren z.B. auch nach Mesh und Parametern, obwohl das NULL Performance-Vorteil gebracht hat. Dafür hat es automatisches Instancing ermöglicht, was dann folgerichtig ebenso NULL Performance-Gewinn gebracht hat.

[Zudomon]

Dafür hat es automatisches Instancing ermöglicht, was dann folgerichtig ebenso NULL Performance-Gewinn gebracht hat.

Was meinst du damit?

[Schrompf]

Damit meine ich: automatisches Instancing hat bei uns mehr Rechenzeit gefressen, als es gebracht hat.

Definition:
Das automatische Zusammenfassen von mehreren Renderjobs, die sich nur in Objektmatrix und evtl. instanziierbaren Parametern unterscheiden, in einen einzelnen Renderjob mit Instancing.

Vorteile:
Man spart die wiederholten Aufrufe an SetVertexConstant() und DrawIndexedPrimitive()

Nachteile:
Man muss einen temporären VertexBuffer locken, mit den Instanzdaten füttern, unlocken.
Man muss die Vertexdeklaration auf die Instancing-Version der vom Mesh verlangten Deklaration setzen.
Man muss den VertexShader evtl. gegen eine Permutation mit Instancing austauschen.

Ergebnis:
Nachteile fressen mehr Performance als die Vorteile bringen. Ich habe dann auch probiert, alle Renderjobs als Einzel-Instanzjobs umzusetzen. Das hat die Anzahl der VertexDekl-Wechsel drastisch reduziert und einiges an Tempo gebracht, aber war *immernoch* langsamer als bei schlichtem linearen Abarbeiten der vorsortierten Renderjob-Liste.

Wobei ich das irgendwann mal mit ShaderConstant-Instancing ausprobieren muss. Dann würde die Aktualisierung des Instanz-VertexBuffers entfallen, man könnte für jeden Auftrag denselben nehmen. Den könnte man dann auch immer angeklemmt lassen und müsste nur die Matrix-Tabelle im VertexShader aktualisieren. Und die Anzahl der VertexDekl-Wechsel wäre auf historischem Tiefpunkt. Hmm.... Ich schreibe Bescheid, wenn ich was rausbekomme.

Bye, Thomas