[DX9] States sortieren, aber wonach?

Für Fragen zu Grafik APIs wie DirectX und OpenGL sowie Shaderprogrammierung.
Antworten
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

[DX9] States sortieren, aber wonach?

Beitrag von 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
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [DX9] States sortieren, aber wonach?

Beitrag von Krishty »

Edit: Ganz unten die CPU-Zyklen pro API-Call: http://msdn.microsoft.com/en-us/library/bb172234.aspx
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: [DX9] States sortieren, aber wonach?

Beitrag von 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
Beiträge: 15
Registriert: 19.03.2008, 00:25

Re: [DX9] States sortieren, aber wonach?

Beitrag von DeRaaZuul »

Genau das gleiche habe ich auch mal gesucht.Super!
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: [DX9] States sortieren, aber wonach?

Beitrag von 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.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Zudomon
Establishment
Beiträge: 2253
Registriert: 25.03.2009, 07:20
Kontaktdaten:

Re: [DX9] States sortieren, aber wonach?

Beitrag von Zudomon »

Schrompf hat geschrieben:Dafür hat es automatisches Instancing ermöglicht, was dann folgerichtig ebenso NULL Performance-Gewinn gebracht hat.
Was meinst du damit?
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: [DX9] States sortieren, aber wonach?

Beitrag von 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
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Antworten