Hi,

das is diesmal nicht direkt eine frage, sondern eher eine feststellung..
Ich habe heute die ganze nacht dannach gesucht warum bei mir eine Scene mit 30.000 Triangles nur mit 20fps rendern wohingegen eine Scene mit 200.000 Triangles mit über 120fps läuft..

Die Hauptunterschiede:

200.000 Tri Scene:
- Wenig Objekte, aber sehr HighPoly
- Wenige Texturen
- Viele dynamische Lichter (7 Stück)
- Animationen (Bone, Vertex etc)

30.000 Tri Scene:
- Sehr sehr viele low poly Objekte (ca. 4000 objekte)
- Sehr viele Texturen
- Nur ein dynamisches licht
- Keine animationen

Zuerst habe ich es auf die extrem vielen Objekte geschoben, weil jedes objekt eine eigenes VBO hatte.. das also kurzerhand umgebastelt so das sie sich alle ein VBO teilen und nurnoch glDrawArrays aufgerufen wird mit entsprechenden bereichen.

Das hat aber genau 0 fps gebracht.. womit schonmal klar wäre, viele kleine VBOs oder ein großes macht nicht wirklich einen unterschied

Als nächstes dachte ich "Okay... evtl sind es die vielen Texturwechsel"..also einfach alle texturen deaktiviert.. etwa 2fpx schneller geworden.. das war es also auchnicht.

Dann hab ich noch ein paar dinge hier und da ausprobiert und war schon am verzweifeln.. zwischenzeitig hab ich mich dann wieder um komplett andere probleme gekümmert um den kopf davon frei zu bekommen. Und jetzt eben ganz zum schluss kam ich auf die idee "Moment mal.. jedes Objekt hat ja ein Transform, welches auch wenn es nicht transformiert ist eine matrix multipliziert", also dachte ich das glMultMatrix macht es langsam.. auskommentiert.. 0fps mehr bekommen

Und dann hab ich da um das glMultMatrix mein glPushMatrix / glPopMatrix block entdeckt und dachte.. "Ob es das ist..?!". Auskommentiert und siehe da: Von 20fps hochgeschossen auf ein paar hundert!

Ich war immer der Meinung das glPushMatrix und glPopMatrix eigentlich recht günstig sind, aber bei 4000x fachem aufruf pro frame ist es da wohl auch zuende mit günstig sein

Warum ich das schreibe? Nur um anderen eine solche suche zu ersparen und zu erwähnen das man mit den beiden funktionen nicht so um sich werfen sollte wie ich es gerne tu

Aya~

Das klingt interessant für mich. Meine JOGL_GUI an der ich arbeite benutzt das sehr oft (Einfach um die abhängigen Transformationen auf den Formularen abzubilden). Ich denke ich werde da ebenfalls mal rumprobieren.

Das es so bremst liegt vermutlich an ... hmmm... Der OpenGL Treiber speichert die Matrizen doch lokal im Arbeitspeicher, oder? Der schickt die doch nicht auf die GraKa um sie beim Pop wiederzuholen, oder?

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich nehm an der fragt beim Push'en die aktuelle matrix ab und setzt sie beim Pop'en wieder.. aber warum das so lange dauert versteh ich eigentlich auch nicht.. evtl liegt es aber auch nur am Mac-Treiber, kann ich aber erst übermorgen testen wenn ich wieder zuhause bin

Aya~

PS: In meiner UI verwende ich es auch excessiv, die alternative wäre eigentlich ja dann nur alles via translate hinschieben und dannach zurückschieben, oder?

Hallo,



naja bei 20 fps sind das auch 4000 x 20 x 16 = 1280000 Werte pro Sekunde, die irgendwo im Speicher verschoben werden müssen, das hat glaub ich schon Auswirkungen auf die Performance

Viele Grüße
dj3hut1

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University

Was anderes Performantes viele mir auch nicht ein.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Aya schrieb:


Danke für die Info bezüglich der kleinen VBOs, das hilft mir viel.

Übrigens kann man das glPush/glPop auch so vermeiden: man bastelt sich seine eigene ModelviewProjection-Matrix und diese wird einfach mit der Matrix des zu zeichnenden Objekts multipliziert und erst dann an OpenGL übergeben. Das heißt, jedes Objekt bringt seine eigene fertige Matrix mit (auch jedes Joint). Sowohl Modelview- als auch Projection-Matrix sind beide dann nur mehr eine Einheitsmatrix. Ob das aber mehr Performance bringt, kann ich jetzt nicht sagen, ist nur so eine Idee. Es sind dann halt mehr Matrix-Multiplikationen in Hauptspeicher durchzuführen.

Man darf ja auch nicht vergessen, dass die üblichen Grafikkarten auf schnelle Spiele zugeschnitten werden, und ob die Pushen und Poppen....?

Bei meinen Fonts hatte ich das ursprünglich auch so. Und zwar die Laufweite von den Buchstaben (Position des nächsten Buchstabens) habe ich mit Translate übertragen. Allerdings ist das unpraktisch für den Entwickler, da die OpenGL verändert wurde, und verhindert die spätere Benutzung von VBOs. Also habe ich es so umgestellt, dass ich die Position auf interne Integer packe und beim Zeichnen die Position der Quads absolut berechne und so zeichne. Und in dem einen Beispiel was in einer Schleife zeichnet und die fps ausgibt erhalte ich Werte die ca 20% höher sind. Was aber auch vollkommen logisch ist. Denn die Werte müssen nicht über den Stack übergeben werden und dann müssen die Werte nur simpelst addiert werden. Die Stelle wo das alles berechnet wird liegt auch viel näher beisammenm, wodurch der Treiber/Pipeline nicht bemüht werden müssen.

In meiner ollen gui (die ich eingestellt habe) habe ich es so gelöst, dass ich für jede komponente absolute Koordinaten berechnet habe. Und zwar nur dann, wenn sich die Position eines Elementes verändert hat. Dann natürlich auch nur sie und die Kindkomponenten. Die absolute Position ist auch nur intern von interesse. Sonst wird immer alles relativ angegeben. Beim Zeichnen kann man sich dann vollkommen auf die berechneten Werte stützen und muss nichts weiter machen. In einem Benchmark erreiche ich damit bei meiner Radeon 3850 knapp 10k fps und 99% GPU Auslastung. Ich kann ja auch alles direkt zeichnen.

Ich hab bei mir mal nachgeguckt und habe festgestellt, dass ich Push/PopMatrix doch nicht so oft benutze.
Beim Eintritt in den GUI Code, sichere ich alle 3 Matrizen, und ansonsten nur an 1 oder 2 Stellen wo eine manuelle Berechnung deutlich unübersichtlich wäre.
Die Positionierung der Componenten erfolgt bereits durch iterierende glTranslates.
Das meine GUI noch nicht so performant ist, liegt vermutlich an anderen Punkten.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Hmm... Das ist interessant. Ich werd dann auch mal gehen und nach meiner GUI schauen... Aya, du hast das Weltbild der OpenGL-GUI-Entwickler zerstört

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Ich hab das mal mit meinem (einfachen) Partikelsystem getestet. Aber bei mir ist Pop und Push ein bischen schneller, als wenn ich die Skalierung und Verschiedung rückgängig mache (820 gegen 720 FPS).
Und ich denke umso mehr die Matrix verändert wird, desto besser wird Pop/Push. Weil man die ganzen Operationen quasi nochmal machen muss, aber die Matrix auf den Stack hauen eine konstante Zeit benötigt.

Wisst ihr an was ich dabei denken muss?

Den DGL Benchmark. Vielleicht schreibt mal jemand ein Anwendungsskelett, wo man ohne größere Probleme einfache Testfälle reincoden kann. Der Benchmark kam ja nicht vorran, weil die herangehensweise Diskutiert wurde. Wenn jemand einfach irgendwas abliefert, ist das schonmal besser, als drüber zu reden.

_________________
Blog: kevin-fleischer.de und fbaingermany.com