Vertexskinning-Shader lahm

Für Fragen zu Grafik APIs wie DirectX und OpenGL sowie Shaderprogrammierung.
Eisflamme
Establishment
Beiträge: 412
Registriert: 26.05.2002, 17:42
Wohnort: Köln

Vertexskinning-Shader lahm

Beitrag von Eisflamme »

Hi,

ich versuche gerade meine Engine etwas schneller und schöner zu machen. V.a. erstmal schöner.

Problem ist, mein Shader ist ziemlich langsam. Und bei Shadern gibt es ja immer jede Menge Tücken, sodass selbst ein eigentlich äquivalenter Ausdruck plötzlich performanter wird. Daher hoffe ich auf eure Erfahrung!

Hier mein Shader für einfaches Vertexskinning über BoneMatrices:

Code: Alles auswählen

struct inner
{
	float4	position	: POSITION;
	float4	color		: COLOR;
	float3	normal		: NORMAL;
	float4	texCoords	: TEXCOORD0;
	float3	boneWeights	: TEXCOORD1;
	float4  boneIndices	: TEXCOORD2;
};

struct outer
{
	float4	position	: POSITION;
	float4	color		: COLOR;
	float4	texCoords	: TEXCOORD0;
};

outer main(inner IN,
            uniform float4x4 ModelViewProj,
			uniform float4	 BoneMatrices[120]
            )
{
    outer OUT;
	
    float3 objPos;

	float4 allWeights = float4(IN.boneWeights, 1.0f - IN.boneWeights.x - IN.boneWeights.y - IN.boneWeights.z);
	
	for(float n = 0; n < 4; ++n)
	{	
		float3x4 matrix = float3x4(	BoneMatrices[IN.boneIndices[n] * 3],
									BoneMatrices[IN.boneIndices[n] * 3 + 1],
									BoneMatrices[IN.boneIndices[n] * 3 + 2]);

		objPos+= mul(matrix, IN.position) * allWeights[n];
	}

	OUT.position    = mul(ModelViewProj, float4(objPos, 1));
	OUT.color		= IN.color;
	OUT.texCoords	= IN.texCoords;

	return OUT;
}
Wenn ich jetzt nichts animiere, habe ich eine gewisse Performance. Und wenn ich 5 Objekte gleichzeitig animiere, wird das ganze Programm etwa 2-3x so langsam. Ist das in der Größenordnung vielleicht auch einfach normal? Diese 5 Objekte sind die testWusons von Assimp. Ich habe auch geprüft, ob das Drumherum zu langsam ist, aber allein das Einschalten des Shaders scheint schon die Performance ordentlich zu drücken. Auch die Übertragung der BoneMatrix-Daten scheint vernachlässigbar zu sein.

Ok, also es sind an sich schon nur 50 FPS und die werden bei eingeschalteter Animation dann zu 22. Wenn ich im Vollbild laufen lasse, habe ich um die 200 FPS, aber es geht trotzdem auf 22 oder so runter. =/
Benutzeravatar
Krishty
Establishment
Beiträge: 8267
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Vertexskinning-Shader lahm

Beitrag von Krishty »

Fehler:
float3 objPos wird genutzt, ohne initialisiert worden zu sein und float3x4 matrix ist kein gültiger Bezeichner, da matrix ein Schlüsselwort ist …

Mikrooptimierungen:
Hat es einen Grund, dass inner::boneIndices ein float4 statt int4 ist? Bei mir verbringt der Shader elf von 50 Befehlen ausschließlich mit float-zu-int-Konvertierungen. BoneMatrices statt uniform float4 per Constant Buffer zu übergeben spart nochmal um die zehn Befehle und einen Takt, aus welchem Grund auch immer … und statt x * y + z zu rechnen (bei den Indizes wie auch bei objPos += … * …;) kannst du das mad()-Intrinsic verwenden um einen Befehl zu sparen.

Flaschenhals:
All diese Mikrooptimierungen bringen nur auf Low-End-Karten was, weil der Shader doppelt so viel Zeit damit verbringt, BoneMatrices zu fetchen, wie mit tatsächlichem Rechnen. Du könntest dem Compiler die Arbeit vereinfachen indem du die Zeilen nicht selber rauspfriemelst sondern den Datentyp direkt als 40-elementiges Matrix-Array anlegst, aber zumindest im GPU Shader Analyzer macht das keinen Unterschied in der Gesamtleistung. Wie du die Fetches raus (oder zumindest reduziert) kriegst, muss dir hier irgendein Skinning-Crack erklären.

Das ALU-zu-TEX-Verhältnis auf einer HD 5870 lag bei deinem Quelltext bei 0,65; mit meinen Mikrooptimierungen ist es runter auf 0,45. Angestrebt ist ein Verhältnis von 2, d.h. du müsstest das Fetching bis auf ein Viertel senken und würdest das direkt als Leistungsvervierfachung erfahren. (Das sind theoretische Werte; in der Praxis spielt auch der Cache noch eine große Rolle. Darüber kann ich aber natürlich nichts sagen, weil ich den Shader nicht ausführen kann. Es ist ebenso möglich, dass das Fetching komplett durch den Cache läuft und die Mikrooptimierungen tatsächlich Auswirkung haben.) Auch werden nun nur noch 17 statt 18 Register genutzt – angestrebt sind sieben, aber die wirst du wegen der Matrizenrechnung niemals erreichen. Falls du eine Nvidia-Karte hast, sind die Charakteristika sowieso nochmal anders.

Gruß, Ky

Nachtrag: Quaternions wären ein exzellenter Weg, das Fetching für nur ein Bisschen ALU mehr auf ein Drittel zu reduzieren. Das könnte locker eine Leistungsverdopplung bewirken. Inwiefern das sinnvoll im Sinne der Anwendung (und nicht nur des Shaders) ist, kann ich dir aber nicht sagen.

Noch einer: Habe das mal auf die Schnelle implementiert und komme nun auf 14 Register und ein fast perfektes ALU:TEX von 2,5. Allerdings ist die theoretische Gesamtleistung nur um 30 % gestiegen. Trotzdem beeindruckend, mal einen Shader zu sehen, der die Recheneinheiten tatsächlich zu weit über 90 % ausgelastet kriegt …
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Eisflamme
Establishment
Beiträge: 412
Registriert: 26.05.2002, 17:42
Wohnort: Köln

Re: Vertexskinning-Shader lahm

Beitrag von Eisflamme »

Wow, danke, das ist ja schon Mal ein ganzer Batzen. :) Mich würde natürlich auch interessieren, ob es normal ist, dass mein Laptop derartige Probleme damit hat. Mit so wenig FPS lässt sich ja kaum ein Spiel erzeugen. =/
BoneMatrices statt uniform float4 per Constant Buffer zu übergeben
Wie sieht das genau aus, habe bisher noch nichts von Constant Buffer gehört (oder unter anderem Begriff).
Benutzeravatar
Lynxeye
Establishment
Beiträge: 145
Registriert: 27.02.2009, 16:50
Echter Name: Lucas
Wohnort: Hildesheim
Kontaktdaten:

Re: Vertexskinning-Shader lahm

Beitrag von Lynxeye »

Dazu wäre natürlich interessant, was dein Laptop für Spezifikationen hat. 50 FPS im Normalbetrieb hören sich auch nicht nach so viel an.
Benutzeravatar
Krishty
Establishment
Beiträge: 8267
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Vertexskinning-Shader lahm

Beitrag von Krishty »

Where is my mind -.- Quaternions statt Matrizen gehen natürlich nicht, weil man die Vertices dann nicht mehr verschieben kann …
Eisflamme hat geschrieben:
BoneMatrices statt uniform float4 per Constant Buffer zu übergeben
Wie sieht das genau aus, habe bisher noch nichts von Constant Buffer gehört (oder unter anderem Begriff).
Wie übergibst du denn deine anderen Shader-Konstanten?
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Eisflamme
Establishment
Beiträge: 412
Registriert: 26.05.2002, 17:42
Wohnort: Köln

Re: Vertexskinning-Shader lahm

Beitrag von Eisflamme »

Ach, das ist bei CG mit OpenGL kompliziert, da muss man halt diese glVertexAttrib-Befehle usw. benutzen. Also Pointer mit fest spezifizierten Semantiken wie TextureCoordinates usw. Ich hatte auch Mal versucht eigene Pointer zu machen, was in der Theorie auch geht, aber leider nicht mit CG zusammenspielt. =/

Mein Laptop ist ein Dell Studio 15 mit einer ATI Mobility Radeon irgendwas, die OpenGL2.0 unterstützt. Mit dem AssimpView ist die Performance auch bei 60 FPS, aber wenn ich das Testwuson in der Animation starte, senkt das die Performance nicht... Vielleicht ist auch einfach CG zu langsam oder ich mache noch was anderes falsch.
Benutzeravatar
Krishty
Establishment
Beiträge: 8267
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Vertexskinning-Shader lahm

Beitrag von Krishty »

Ach, OpenGL – lustig; ich hatte es die ganze Zeit als HLSL kompiliert. Dann vergiss das mit dem Constant Buffer.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Vertexskinning-Shader lahm

Beitrag von dot »

Nur mal ne rein prinzipielle Frage: Woher genau weißt du eigentlich dass das Problem am Shader liegt?
Krishty hat geschrieben:Ach, OpenGL – lustig; ich hatte es die ganze Zeit als HLSL kompiliert. Dann vergiss das mit dem Constant Buffer.
In OpenGL heißen die halt Uniform Blocks...
Zuletzt geändert von dot am 01.07.2011, 13:18, insgesamt 2-mal geändert.
Benutzeravatar
Schrompf
Moderator
Beiträge: 4878
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Vertexskinning-Shader lahm

Beitrag von Schrompf »

Liegt es denn wirklich am Shader? Ich meine... ATI Mobilities sind quasi die schlimmsten Grafikkarten, die Du kriegen kannst (kurz nach Intel), aber die 3k Vertizes eines Wusons sollten sie allemal schaffen. Evtl. braucht ja auch Dein Skinning-Code auf der CPU so viel Rechenzeit.

Ansonsten hat Krishty ja schon prima aufgedröselt, woran es alles hängen kann. Meine Empfehlung ist es, die Bone-Matrizen direkt als column_major 4x3-Matrix reinzureichen, so dass der cast zu float3x3 für die Normalen und Tangenten nur noch eine aufwandsfreie Uminterpretation ist. Aber ob das was bewirkt, kann ich auch nicht bewerten, dass OpenGL-Treiber ja noch unzuverlässiger als DX-Treiber sind, was die Shader-Compiler angeht.

Abschließend bleibt also zu sagen: saug Dir ein Analyse-Tool und finde es heraus. Oder profile erstmal den CPU-Teil. Vielleicht tuen sich ja da schon spannende neue Erkenntnisse auf.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Eisflamme
Establishment
Beiträge: 412
Registriert: 26.05.2002, 17:42
Wohnort: Köln

Re: Vertexskinning-Shader lahm

Beitrag von Eisflamme »

Wenn ich den Shader ausstelle, läuft es schneller. Ich habe zumindest Mal meine ganzen Bone-Berechnungen rausgeschmissen und einfach nur initiale Bone-Matrizen übergeben, was nichts ändert. Natürlich ist das kein Beweis...

Schrompf:
Wohl wahr. Hast Du gerade noch ne Empfehlung für nen Profiler? Ich dachte ja damals, der MSVC-Profiler wär gut, aber mit dem kann ich nicht umgehen, finde keine Tutorials und vermute auch stark, dass der nur mit managed code klar kommt...
Eisflamme
Establishment
Beiträge: 412
Registriert: 26.05.2002, 17:42
Wohnort: Köln

Re: Vertexskinning-Shader lahm

Beitrag von Eisflamme »

Hm, wenn ich den Shadercode verkürze:

Code: Alles auswählen

outer main(inner IN,
            uniform float4x4 ModelViewProj,
			uniform	float4	 BoneMatrices[120]
            )
{
	

    outer OUT;
	OUT.position    = mul(ModelViewProj, IN.position);
	OUT.color		= IN.color;
	OUT.texCoords	= IN.texCoords;
}
kostet das fast gar keine Performance. Wäre für mich ein klares Indiz dafür, dass es am Shader liegt, oder? Sicherlich spar ich am meisten Performance ein, weil der Shader-Compiler hier die ganze Matrix-Transmission auch rauslässt, weil das eh nicht genutzt wird, aber scheint mir dennoch der Flaschenhals zu sein. =/
Benutzeravatar
eXile
Establishment
Beiträge: 1136
Registriert: 28.02.2009, 13:27

Re: Vertexskinning-Shader lahm

Beitrag von eXile »

Krishty hat geschrieben:Where is my mind -.- Quaternions statt Matrizen gehen natürlich nicht, weil man die Vertices dann nicht mehr verschieben kann …
Meinst du vielleicht Dual Quaternions?
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Vertexskinning-Shader lahm

Beitrag von dot »

AMD CodeAnalyst. Aber so wie dus beschreibst liegts wohl wirklich am Shader, auch wenn mich das irgendwie ziemlich wundert. Wenn das der Fall ist würd ichs wirklich mal mit Quaternions versuchen wie Krishty schon vorgeschlagen hat. Die sorgen für mehr Arithmetik und weniger Speicherbandbreite. Im einfachsten Fall verwendet man eben Quaternion + Translationsvektor, komplexer gings z.B. mit Dual Quaternion Skinning. Ich könnte mir aber vorstellen dass das Problem hier weder das eine noch das andere ist. Ich weiß jetzt zwar nicht wies bei ATI genau aussieht, aber NVIDIA Karten haben verschiedene Arten von Speicherbereichen und Uniforms/Constant Buffer werden sehr wahrscheinlich im sog. Constant Memory abgelegt. Dieser Speicherbereich ist optmiert dafür dass sämtliche Threads (Shaderinstanzen) zu jedem Zeitpunkt auf die selben Speicherstellen zugreifen, was normalerweise bei Uniforms ja der Fall ist. Bei dir aber nicht, du hast ein völlig chaotisches Zugriffsmuster (die Performance nimmt beim Constant Memory prinzipiell linear mit der Anzahl unterschiedlicher Adressen ab). Daher mehrere Vorschläge:
  • Versuch einfach mal deine Vertices nach den Bones die sie benutzen zu sortieren um da vielleicht etwas mehr Lokalität reinzubringen. Ich könnte mir vorstellen dass schon das allein eine kleine Verbesserung bringt.
  • Verwend keinen cbuffer sondern einen tbuffer (frag mich nicht wie das in OpenGL geht)
  • Verwend eine dynamische Textur statt eines uniform Arrays
  • Verwend z.B. einen Structured Buffer (frag mich nicht wie das in OpenGL geht)
Ich prognostiziere mal dass du mit dem tbuffer oder der Textur sehr viel Performance rausholen wirst.
Benutzeravatar
Krishty
Establishment
Beiträge: 8267
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Vertexskinning-Shader lahm

Beitrag von Krishty »

dot hat geschrieben:Dieser Speicherbereich ist optmiert dafür dass sämtliche Threads (Shaderinstanzen) zu jedem Zeitpunkt auf die selben Speicherstellen zugreifen, was normalerweise bei Uniforms ja der Fall ist. Bei dir aber nicht, du hast ein völlig chaotisches Zugriffsmuster (die Performance nimmt beim Constant Memory prinzipiell linear mit der Anzahl unterschiedlicher Adressen ab).
ATI kennt sowas afaik nicht … ich habe auch in Benchmarks noch nie einen Unterschied zwischen cbuffer und tbuffer gesehen. Aber ich habe hier auch keine Low-End-Karten.

Was die Lokalität angeht: Assimp hat einen Nachbearbeitungsschritt, der die Lokalität der Vertices erhöht. Da Bones auch räumlich konzentriert eingesetzt werden, müsste mit der Lokalität der Vertices auch gleichzeitig die der Bones steigen; probier das also mal aus.

(Selbst, wenn sich die Lokalität der Bones nicht erhöhen sollte – ich denke, dass die Zeit, die eine komplette Neuausführung des Vertex Shaders durch niedrige Vertex-Lokalität braucht, die gesparte Zeit durch erhöhte Bone-Lokalität niedermacht. Falls du es nicht wusstest: Wenn du Geometrie mit indizierten Dreiecken renderst, wird jedes Vertex im Schnitt drei- bis viermal von verschiedenen Dreiecken benutzt. Die GPU führt einen Cache mit den letzten transformierten Vertices, und falls ein Index gerade erst vorkam, wird das transformierte Vertex aus dem Cache geladen anstatt den Vertex Shader erneut auszuführen. Von diesem Cache kann umso mehr Gebrauch gemacht werden, je näher die Dreiecke, die durch den Index-Buffer beschrieben werden, in ihrer Reihenfolge räumlich zusammenliegen. Da bei dir der Vertex-Shader der Flaschenhals zu sein scheint und die schnellsten Vertices die sind, die nicht berechnet werden müssen, solltest du möglichst auf Lokalität setzen.)

Du benutzt vier Bones pro Vertex. Falls ein Vertex mal nicht alle diese Bones tatsächlich benötigen sollte, lass die ungenutzten Bone-Indizes nicht uninitialisiert sondern setz sie auf denselben Index wie einen Genutzten, damit die ungenutzten Indizes nur Speicherstellen referenzieren, die sowieso geladen werden müssen.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Vertexskinning-Shader lahm

Beitrag von dot »

Krishty hat geschrieben:ATI kennt sowas afaik nicht … ich habe auch in Benchmarks noch nie einen Unterschied zwischen cbuffer und tbuffer gesehen. Aber ich habe hier auch keine Low-End-Karten.
Also ich hab mal einen schnellen Blick in den ATI Programming Guide geworfen und mir scheint schon dass die da auch was machen, zumindest mit ihrem Cache. Aber gut, ich hab da mit ATI keine Erfahrungswerte. Aber was NVIDIA angeht kann ich dir sagen dass ich bei praktisch dem selben Problem schon Faktor 2.4 beobachtet hab (Texture vs. Constant Memory, nicht in FPS sondern absolute Ausführungszeit (war eine GPGPU Sache)), also jetzt alles Andere als vernachlässigbar...

Er kann ja einfach mal versuchen statt dem Uniform Array eine Textur zu benutzen, das sollte auch in OpenGL jetzt sehr einfach umsetzbar sein und wär interessant obs was bringt...
Eisflamme
Establishment
Beiträge: 412
Registriert: 26.05.2002, 17:42
Wohnort: Köln

Re: Vertexskinning-Shader lahm

Beitrag von Eisflamme »

Okay, aber die Änderungen brauchen alle etwas. Ich hab überhaupt keine Ahnung, wie ich das alles umsetzen muss ^^ Also werde ich wohl Mal googlen und alles, sobald ich mehr Ahnung habe.

Ich bin aber schon bestürzt, dass für ein einfaches Vertexskinning solcher Aufwand betrieben werden muss, damit es auf einer Low-Card-Maschine läuft... Ich hätte gedacht, das ist Pillepalle, fast jedes 3D-Spiel nutzt doch Animationen...

Jedenfalls vielen Dank für die ganzen Informationen, das bringt mich theoretisch schon Mal viel weiter. :)
Eisflamme
Establishment
Beiträge: 412
Registriert: 26.05.2002, 17:42
Wohnort: Köln

Re: Vertexskinning-Shader lahm

Beitrag von Eisflamme »

Hm, hier hat einer exakt dasselbe Problem: http://www.gamedev.net/topic/495799-cg- ... very-slow/

Leider keine Lösung dabei. Ich habe ja wieder CG in Verdacht, das macht nichts als Ärger. Kann es sein, dass der erzeugte GLSL-Code schlecht ist? Den habe ich jetzt auf ner anderen Maschine erstellt, daher sind die int-Casts und Fehler noch drin, aber vll. sieht jemand etwas Auffälliges?

Code: Alles auswählen

 // main procedure, the original name was main
void main()
{

    outer _OUT;
    vec3 _objPos;
    vec4 _allWeights;
    vec4 _TMP5[3];

    _allWeights = vec4(gl_MultiTexCoord1.x, gl_MultiTexCoord1.y, gl_MultiTexCoord1.z, ((1.00000000E+000 - gl_MultiTexCoord1.x) - gl_MultiTexCoord1.y) - gl_MultiTexCoord1.z);
    _TMP5[0] = _BoneMatrices1[(int((gl_MultiTexCoord2.x*3.00000000E+000)))];
    _TMP5[1] = _BoneMatrices1[(int((gl_MultiTexCoord2.x*3.00000000E+000 + 1.00000000E+000)))];
    _TMP5[2] = _BoneMatrices1[(int((gl_MultiTexCoord2.x*3.00000000E+000 + 2.00000000E+000)))];
    _r0008.x = dot(_TMP5[0], gl_Vertex);
    _r0008.y = dot(_TMP5[1], gl_Vertex);
    _r0008.z = dot(_TMP5[2], gl_Vertex);
    _objPos = _objPos + _r0008*_allWeights.x;
    _TMP5[0] = _BoneMatrices1[(int((gl_MultiTexCoord2.y*3.00000000E+000)))];
    _TMP5[1] = _BoneMatrices1[(int((gl_MultiTexCoord2.y*3.00000000E+000 + 1.00000000E+000)))];
    _TMP5[2] = _BoneMatrices1[(int((gl_MultiTexCoord2.y*3.00000000E+000 + 2.00000000E+000)))];
    _r0008.x = dot(_TMP5[0], gl_Vertex);
    _r0008.y = dot(_TMP5[1], gl_Vertex);
    _r0008.z = dot(_TMP5[2], gl_Vertex);
    _objPos = _objPos + _r0008*_allWeights.y;
    _TMP5[0] = _BoneMatrices1[(int((gl_MultiTexCoord2.z*3.00000000E+000)))];
    _TMP5[1] = _BoneMatrices1[(int((gl_MultiTexCoord2.z*3.00000000E+000 + 1.00000000E+000)))];
    _TMP5[2] = _BoneMatrices1[(int((gl_MultiTexCoord2.z*3.00000000E+000 + 2.00000000E+000)))];
    _r0008.x = dot(_TMP5[0], gl_Vertex);
    _r0008.y = dot(_TMP5[1], gl_Vertex);
    _r0008.z = dot(_TMP5[2], gl_Vertex);
    _objPos = _objPos + _r0008*_allWeights.z;
    _TMP5[0] = _BoneMatrices1[(int((gl_MultiTexCoord2.w*3.00000000E+000)))];
    _TMP5[1] = _BoneMatrices1[(int((gl_MultiTexCoord2.w*3.00000000E+000 + 1.00000000E+000)))];
    _TMP5[2] = _BoneMatrices1[(int((gl_MultiTexCoord2.w*3.00000000E+000 + 2.00000000E+000)))];
    _r0008.x = dot(_TMP5[0], gl_Vertex);
    _r0008.y = dot(_TMP5[1], gl_Vertex);
    _r0008.z = dot(_TMP5[2], gl_Vertex);
    _objPos = _objPos + _r0008*_allWeights.w;
    _v0016 = vec4(_objPos.x, _objPos.y, _objPos.z, 1.00000000E+000);
    _r0016.x = dot(_ModelViewProj1[0], _v0016);
    _r0016.y = dot(_ModelViewProj1[1], _v0016);
    _r0016.z = dot(_ModelViewProj1[2], _v0016);
    _r0016.w = dot(_ModelViewProj1[3], _v0016);
    _OUT._color1 = gl_Color;
    _OUT._color1.x = 0.00000000E+000;
    _OUT._color1.y = 0.00000000E+000;
    if (gl_MultiTexCoord2.x == 3.10000000E+001) { // if begin
        _OUT._color1.y = 1.00000000E+000;
    } // end if
    _OUT._color1.z = 0.00000000E+000;
    gl_TexCoord[0] = gl_MultiTexCoord0;
    gl_TexCoord[1].xyz = gl_Normal;
    gl_FrontColor = _OUT._color1;
    gl_Position = _r0016;
    return;
} // main end
Aber ich vermute eher, dass der Weg von CG zu der Grafikkarte irgendwie zu langsam ist. Ich sollte das Mal benchmarken, indem ich direkt GLSL verwende, auch wenn das etwas Einarbeitung erfordert...
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Vertexskinning-Shader lahm

Beitrag von dot »

Mir ist nicht klar wo das Problem in dem von dir verlinkten Thread liegen soll. Wenn er die Schleife auskommentiert, also nur 1/4 der Arbeit macht, läuft sein Shader 4x so schnell. Who would have thought...

Die int Casts sind doch wohl notwendig wenn du als Indices floats verwendest. Ich denk jedenfalls nicht dass du mit GLSL da schneller sein wirst.
Zuletzt geändert von dot am 03.07.2011, 21:08, insgesamt 1-mal geändert.
Eisflamme
Establishment
Beiträge: 412
Registriert: 26.05.2002, 17:42
Wohnort: Köln

Re: Vertexskinning-Shader lahm

Beitrag von Eisflamme »

Die kann ich doch auf ints ändern, es sind ja von der Logik her nur ints.

Und im Thread ist 4x so schnell ohne Schleife eben immer noch langsam... Das sollte viel schneller gehen. VertexSkinning über Assimp läuft ja bei mir zB komplett ohne Performanceverluste. Das erwarte ich auch bei einer schlechten Grafikkarte durchaus. Sie ist ja nicht vorsintflutlich, sondern lediglich "nur" eine schwache Laptop-Karte bzw. ein Chip.
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Vertexskinning-Shader lahm

Beitrag von dot »

Was genau heißt "ohne Performanceverluste"? Macht Assimp da auch 4 Weights pro Vertex? Verwendest du vielleicht keine indizierten Vertices?
Eisflamme
Establishment
Beiträge: 412
Registriert: 26.05.2002, 17:42
Wohnort: Köln

Re: Vertexskinning-Shader lahm

Beitrag von Eisflamme »

Doch, Assimp nutzt auch vier Weights und Indices, ich habe extra das gleiche Modell genutzt, dass auch alle 4 Indexpositionen besetzt hat. Indizes nutze ich... Und ohne Performanceverluste, dass im Fenstermodus bei einem gerenderten Modell die FPS vorher und nachher 60 ist. Gut, ich rendere das Modell 6 Mal und ich habe noch kein eigenes Clipping implementiert, aaaaber das sollte trotzdem nicht so viel langsamer sein.
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Vertexskinning-Shader lahm

Beitrag von dot »

Eisflamme hat geschrieben:Gut, ich rendere das Modell 6 Mal [...]
Und wie schnell ist es wenn dus mit Assimp 6 Mal renderst?
Eisflamme
Establishment
Beiträge: 412
Registriert: 26.05.2002, 17:42
Wohnort: Köln

Re: Vertexskinning-Shader lahm

Beitrag von Eisflamme »

Dafür müsst ich den AssimpView-Code ändern... aber es ist egal, auch wenn ich das Modell bei mir nur einmal rendere, nimmt die Performance deutlich mehr als 0 FPS ab, es sind definitiv 10+FPS.
Benutzeravatar
Krishty
Establishment
Beiträge: 8267
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Vertexskinning-Shader lahm

Beitrag von Krishty »

Das sagt uns garnichts. Nur noch 1985 statt 2000 fps? 48 statt 60? -3 statt 7? Du musst messen, wie lange Assimp für einmal rendern braucht (am besten in Milisekunden – 1 ÷ fps × 1000) und wie lange du für einmal rendern brauchst, und dann wissen wir, ob es schnell oder langsam ist (und sogar, wie sehr langsamer als Assimp).

Je geringer dabei die Auflösung, desto geringer der Overhead für Pixel Shading; je aufwändiger das Modell, desto weniger fallen bei der Messung die Unkosten für Anzeige und Pipeline-Setup ins Gewicht. Dann am besten mehrere Durchläufe machen und das Minimum nehmen (nicht den Durchschnitt) – natürlich mit VSync, damit keine Frames verworfen werden und du bei 0 landest. Und, falls möglich, Fullscreen und ohne Aero, damit du die volle Leistung zur Verfügung hast. Vllt auch Flash deaktivieren, das macht bei mir alle Benchmarks unbrauchbar.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
NytroX
Establishment
Beiträge: 367
Registriert: 03.10.2003, 12:47

Re: Vertexskinning-Shader lahm

Beitrag von NytroX »

Ich habe da was von nem Laptop gelesen... läuft das da so langsam?
Wenn ja, was ist das für ein Laptop, auf dem das ganze laufen soll (HP mit Intel-Graka)?

Hast du die Möglichkeit, den Code auch auf nem anderen PC zu testen?

*EDIT: achja, eine Zeitmessung wäre vielleicht auch noch ganz hilfreich, wie schnell oder langsam das ganze wirklich ist
Zuletzt geändert von NytroX am 04.07.2011, 14:53, insgesamt 1-mal geändert.
Eisflamme
Establishment
Beiträge: 412
Registriert: 26.05.2002, 17:42
Wohnort: Köln

Re: Vertexskinning-Shader lahm

Beitrag von Eisflamme »

Hi,

also ich habe noch herausgefunden, dass ich Antialiasing anhatte, was ich ausgestellt habe, ändert aber wenig. Habe jetzt Mal VSync ausgestellt, Flash habe ich nicht gefunden. Ich habe Pixelshading Mal ausgestellt, aber das interessiert die Anwendung nicht, die Vertexshader fallen ins Gewicht.

So und ich habe jetzt 167 FPS im Vollbildmodus bei einem gerenderten Modell.
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.

Achso und gerendert schließt immer auch animiert ein...

Und in AssimpView habe ich natürlich nur den Fenstermodus. Der hat für das gleiche Modell 41-46 FPS, unabhängig davon, ob Shader an oder aus ist. Also wieder kein so toller Vergleich, vll. schau ich Mal, was ich da sonst noch so machen kann.
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Vertexskinning-Shader lahm

Beitrag von dot »

Und wie schnell ist Assimp? FPS sind leider ein absolut ungeeignetes Maß für solche quantitativen Vergleiche, miss lieber die Zeit dies zum Rendern eines Frame braucht.

EDIT: Oh, übersehen, d.h. dein Programm rendert eigentlich eh schon schneller als Assimp? Wenn man sich die Frametimings da oben anschaut ist das ein annähernd linearer Verlauf, also genau was man erwarten würde. Und deine Anwendung rendert ja offenbar schon 3 Modelle in der Zeit in der Assimp eines rendert. Wo genau ist jetzt dein Problem?
Eisflamme
Establishment
Beiträge: 412
Registriert: 26.05.2002, 17:42
Wohnort: Köln

Re: Vertexskinning-Shader lahm

Beitrag von Eisflamme »

AssimpView ist im Fenstermodus, mein Programm im Vollbildmodus. Wenn ich meine Anwendung im Fenstermodus laufen lasse, hat sie 50 FPS und bei 5 gerenderten Modellen 26 FPS.
Benutzeravatar
Schrompf
Moderator
Beiträge: 4878
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Vertexskinning-Shader lahm

Beitrag von Schrompf »

Die Zahlen klingen für mich, als hättest Du einfach nur miserable Hardware.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
dot
Establishment
Beiträge: 1734
Registriert: 06.03.2004, 18:10
Echter Name: Michael Kenzel
Kontaktdaten:

Re: Vertexskinning-Shader lahm

Beitrag von dot »

Eisflamme hat geschrieben:Wenn ich meine Anwendung im Fenstermodus laufen lasse, hat sie 50 FPS und bei 5 gerenderten Modellen 26 FPS.
Also laufen 5 Modelle sogar wesentlich schneller als 5x so langsam wie 1, was genau erwartest du, ein Wunder!?
Antworten