Vertexskinning-Shader lahm

[Krishty]

Bei zwei gerenderten Modellen fällt die FPS auf 125 (bester Durchlauf).
Bei zwei gerenderten Modellen fällt die FPS auf 63.
Bei drei gerenderten Modellen fällt FPS auf 47.
Bei fünf gerenderten Modellen fällt FPS auf 35.

zwei
zwei
drei
fünf

War das ein Flüchtigkeitsfehler?

[Eisflamme]

Ja, war ein Flüchtigkeitsfehler, ist einfach inkrementierend...

Und schlechte Hardware? Gern, wenn nur das das Problem ist. Es ist halt ein Onboard-Grafikchip von einem 15'' Laptop. Sollten die besser sein? Ich meine, das ist einfachstes Vertexskinning, so was lief doch schon vor >10 Jahren oder nicht? Und der Laptop ist zwar kein Spielelaptop, aber nur 3 Jahre alt, da erwarte ich irgendwie schon, dass so Pillepalle flüssig läuft.

[Eisflamme]

Das mit der Texturübergabe klingt doch aber schon Mal sehr gut. Also ich könnte die Matrizen quasi alle in Texturen packen? Aber das extrahieren und so dauert doch dann auch Zeit oder nicht? Gibt es hier ein Stichwort, unter dem ich nachschlagen kann? Shader Data Texture Transmission oder irgendwie so was?

[Krishty]

Die Texel sind doch float4s, wie deine Konstanten auch :) Ob du nun ein Array an Position 3*i, 3*i+1 und 3*i+2 abfragst oder eine 1D-Textur, macht in der Logik keinen Unterschied.

[dot]

Aber eben evtl. für die Hardware weil Texturen für diese Art des Zugriffes besser geeignet sind. Wobei es natürlich sein kann dass es gar nix bringt, vor allem wenn Krishty sagt dass das seiner Erfahrung nach bei ATI keinen wirklichen Unterschied macht (ich hab mit ATI da keine Erfahrungswerte). Auch wenns vielleicht einen kleinen Performanceschub bringt wird jetzt sicher nicht plötzlich alles viermal so schnell laufen. Die Grafikkarte ist wohl eben einfach zu schwach...

[Krishty]

Und noch vergessen: Bloß direkt auf die Texel zugreifen; auf keinen Fall samplen!

[Eisflamme]

Und jetzt wieder die naive Rückfrage: Wie greife ich direkt auf Texel zu?

Ich kenne das jetzt nur so, dass ich so einen sampler reinkriege, da wäre jetzt sampler1D logisch. Und dann nutzt man diese tex1D-Funktion, um Zugriff zu erhalten, aber sampelt das nicht quasi direkt?

Edit: Eigentlich wäre es doch auch gut, wenn ich half statt float nutzen würde. Aber irgendwie verschwinden dann alle Modelle -> alle Werte sind irgendwie falsch...

[Schrompf]

Nach meinem Wissen bietet überhaupt nur NVidia die Half<->Float-Unterscheidung an. Und das war mal eine wichtige Sache zu Zeiten der Geforce5xxx bis 7xxx, seitdem hat sich das auch überholt.

Was Krishty mit "Laden, nicht samplen" meint, sind wahrscheinlich die dedizierten Load()-Befehle, die es seit Shadermodell 4.0 gibt. Es kann sein, dass es die im CG gar nicht oder nur unter anderen Umständen gibt. Und was ich gehört habe, soll der Load-Zugriff sogar drastisch langsamer sein als ein gezieltes Samplen mit Point Filtering.

[Eisflamme]

Puh, okay. Dann fällt ja wieder viel weg.

column_major float4x3 (oder 3x4) hatte ich Mal ausprobiert, aber das hatte auch nichts genützt oder nicht geklappt, ich weiß leider nicht mehr, wieso.

Dann kann ich wohl kaum optimieren. Andererseits reicht ja vielleicht schon Clipping aus, es müssen ja nicht immer parallel 5 Wusons animiert werden. Und die sind ja animationstechnisch auch schon ziemlich fein.

[Krishty]

Und jetzt wieder die naive Rückfrage: Wie greife ich direkt auf Texel zu?

Ich kenne das jetzt nur so, dass ich so einen sampler reinkriege, da wäre jetzt sampler1D logisch. Und dann nutzt man diese tex1D-Funktion, um Zugriff zu erhalten, aber sampelt das nicht quasi direkt?

Ich kenne mich mit CG nicht aus, aber das hier klingt passend.

Was Krishty mit "Laden, nicht samplen" meint, sind wahrscheinlich die dedizierten Load()-Befehle, die es seit Shadermodell 4.0 gibt. Es kann sein, dass es die im CG gar nicht oder nur unter anderen Umständen gibt. Und was ich gehört habe, soll der Load-Zugriff sogar drastisch langsamer sein als ein gezieltes Samplen mit Point Filtering.

Bei Direct3D und AMD laufen die ebenfalls durch die Sampler, sollten also in einer ähnlichen Liga spielen. Für CG hat eine flinke Recherche ergeben, dass das Lesen kleinere Cache Lines nutzt und an ein paar Cache-Stufen vorbeigeht, also für mehr oder weniger zufälle Lesezugriffe optimiert ist – ob wir es hier damit zu tun haben, kommt auf die Lokalität der Vertices an.