spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich glaube die einmalig pro Frame stattfindende Matrixberechnung für die Kamera sollte wohl Deine geringste Performance-Sorge sein.

Rendergeschwindigkeit beurteilen ist so ziemlich das komplizierteste, womit ich mich bisher beschäftigt habe. Es gibt dutzende Faktoren die man beachten muss, und fast alle beeinflussen sich gegenseitig.

Generell gilt: Mit den neuen OpenGL Versionen wurde vieles als veraltet deklariert - einiges davon, weil es einfach langsam ist (glBegin z.B.). Wenn du also das Core-Profil nutzt, hast du schon einiges gewonnen.
In Shadern sollte man wissen, welche Funktionen schon vordefiniert sind. Es gibt da eine ganze Reihe nützlicher Helfer und du kannst davon ausgehen, dass diese eher optimiert werden, als wenn du sie per Hand nachbaust. Was genau der Shader-Compiler macht, kann sich zwar mit jedem Treiberupdate ändern, vielleicht ist der selbst geschriebene Code hinterher auch genauso schnell, wie die eingebaute Funktion, aber wieso sollte man sich extra Arbeit machen?

AMD CodeXL (der Nachfolger vom gDEBugger) hat mir auch schonmal Performance-Warnungen angezeigt, als ich bestimmte Funktionen benutzt habe, es kann also nicht schaden, den ab und zu zu benutzen.

Ansonsten ist das wichtigstes natürlich immer noch das optimieren im großen Maßstab. Ich habe neulich erst einen Test gemacht, wie viel es ausmacht, das komplette Material mit Texturen und Shader für jedes Objekt zu setzen, oder Objekte nach Material sortiert zu rendern, um so die Shaderwechsel zu minimieren - das Ergebnis war enorm, ich konnte ~10 mal so viele Objekte in der selben Zeit rendern. Dementsprechend kann es sich also auch lohnen, Shadernicht zu spezialisieren, so dass man sie für verschiedene Materialien benutzen kann (Stichwort Supershader). Auch wenn der Shader durch Abfragen langsamer läuft, sparst du beim Shaderwechsel möglicherweise so viel, dass es sich lohnt.

Es ist vermutlich keine schlechte Idee, immer mal wieder aktuelle Artikel über OpenGL oder Grafikprogrammierung im allgemeinen zu lesen. In guten Artikeln wird dann auch erwähnt, warum eine bestimmte Lösung gewählt wurde, so dass man ein Gefühl dafür bekommt, was langsam ist und was schnell.

Zitat von »RenX313«

was ich mich Frage ist, ob es schneller ist z.B. die per Uniform die Kameraposition an den Shader zu geben oder den die Kameraposition im per Matrixinverse im Shader zu berechnen.

Hängt davon ab, kann man so allgemein nicht sagen. Sehr wahrscheinlich ist es in deinem Fall aber besser, die Matrix nur einmal auf der CPU zu invertieren, anstatt auf der GPU für jeden Vertex, da Matrixinversion jetzt nicht unbedingt die billigste Operation ist, die man sich so vorstellen könnte. Es ist aber auch sehr wahrscheinlich, dass du in einem kleinen Testprojekt praktisch keinen Unterschied feststellen wirst...

Zitat von »RenX313«

Frage ich mich außerdem, ob es eine Liste oder ein Guide oder sonst was gibt, was mir erklärt, welche Befehle am Zeitaufwändigsten sind oder welche GLSL Befehle z.B. fest in der Hardware implementiert sind oder so. Gibt es da sowas?

Könnte dich interessieren: http://www.humus.name/Articles/Persson_LowLevelThinking.pdf

Ich denke, da wird man aber besonders im Zusammenspiel mit CPU nur eher grobe Tendenzen festhalten können. Was bei NVidia super klappt muss ja nicht bei ATI oder Intel genausogut sein ...

Zudem hängt die Performance auch stark vom Treiber ab. Es gibt also keine Garantie, dass jede Grafikkarte bei einer bestimmten Funktion immer gleich schnell ist.
Aber wie bereits gesagt, Shaderwechsel, Bufferwechsel, Texturwechsel usw. kosten potentiel am meisten.

Zitat von »DeKugelschieber«

Aber wie bereits gesagt, Shaderwechsel, Bufferwechsel, Texturwechsel usw. kosten am meisten.

"Kosten am meisten" ist natürlich eine gefährliche Aussage...

Generell kommt man bei externen Bibliotheken IMHO sehr weit, wenn man versucht sie so zu benutzen, wie die Autoren es vorsehen. Also nicht gucken ob man irgendwas umgehen kann, zwanghaft deprecrated-Zeug nutzen oder immer den zunächst bequemsten Weg gehen. Die Leute, die so Frameworks/Bibliotheken bauen kennen sich damit im Zweifel deutlich besser aus als man selbst.

Solltest du das wirklich so machen, und trotzdem Geschwindigkeitsprobleme bei OpenGL haben, liegt der Fehler wahrscheinlich nicht in langsamen OpenGL-Befehlen.

Außerdem: Wenn man eine Frage hat, wie z.B. nach einer Liste der Laufzeiten versch. Befehle und keine Antwort findet, kann man sich die Frage stellen, warum. In der Regel liegt das daran, dass sich die Frage nicht beantworten lässt, weil sie von falschen Gegebenheiten ausgeht ("Die Laufzeiten sind immer überall gleich"). Oft sind diese Gegebenheiten von denen man ausgeht einem selbst nicht sofort klar. Nach einer wenig erfolgreichen Suche, deshalb immer darüber nachdenken, ob man nicht selbst einen Denkfehler gemacht hat.