mal eine sehr waage Frage:
Was kosten (in Zeiteinheiten) eigentlich die ganzen State-Changes?
oder anders: Hat irgendwer schon mal eine Tabelle gesehen in der
der Zeitaufwand verschiedener GL-Befehle verglichen wird?
cu
Volker

1. Bitte nen aussagekräftigen Topictitel wählen

2. Die Zeit die Statechanges brauchen sind je nach Implementation verschieden, und es hängt auch davon ab ob diese redundant sind und auch als solche von der Implementation erkannt werden. Eine Tabelle dazu gibts keine, aber während z.B. Texturenwechsel recht äufwendig sind, sind die meisten anderen States (z.B. Shaderwechsel) recht schnell.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Die meisten professionellen SceneGraphs (OpenInventor, Performer, OpenSceneGraph) und *hüstel* in Grenzen auch BaseGraph verwenden Mechanismen, um entweder nach StateChanges zu sortieren (in welchem Fall die Dauer der StateChanges wichtig ist, da man ja ein Sortierkriterium braucht), oder aber die OpenGL States auf einer weiteren Abstraktionsebene zu kapseln.
Das nennt sich dann "lazy state change" und bedeutet im Prinzip nichts anderes, dass man sich merkt, welcher Status welche Ausprägung hat - und eine Anforderung an einen StateChange erst mal mit dem aktuell gecachten vergleicht, ob es überhaupt notwendig ist ein entsprechendes Kommando zu senden. In Zeiten von Gigahertz Rechnern, kann man ja ein paar Vergleiche durchaus verschmerzen.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Also mit OpenGL kenne ich mich zwar noch nicht so toll aus, aber mit Performanceoptimierung schon ganz gut...

Ich hab mal ein paar typische OpenGL-Befehle durch mein übliches Testprogramm gejagt:
(Athlon 1400, Geforce3, Detonator 53.03)

glLoadIdentity: 90 Takte (0,000064ms)
glTranslatef: 115 Takte (0,000082ms)
glRotatef: 640 Takte (0,000470ms)
glPush/PopMatrix 152 Takte
glEn/Disable(GL_TEXTURE_2D): 53 Takte
glBindTexture: 178 Takte
glBegin(GL_TRIANGLES);glEnd: ca. 200 Takte (variiert)
glBlendFunc: 110 Takte

//Kann sein, dass die hier nicht stimmen, da sie nur im richtigen Kontext arbeiten
glColor4f: 109 Takte
glNormal3f: 112 Takte
glTexCoord2f: ca 90 Takte (variiert stark)

Solche Werte sind immer stark mit Vorsicht zu genießen. So führt OpenGL Befehle nicht notwendigerweise sofort aus, sondern cacht sie, bis die Ausführung eines Blocks Sinn macht.
Außerdem kann das Ausführen des Renderns auf der Videokarte parallel zur CPU stattfinden, sodass erst bei einem Flush der Renderkommandos (etwa bei einem Bildwechsel) sichergestellt ist, dass die gesendeten Renderkommandos tatsächlich abgearbeitet wurden.
Was du auf diese Weise also mißt, sind eher die Taktzyklen für einen Call als die tatsächliche Dauer der Kommandos.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

War mir klar... aber is ja auch mal interessant.

Mehr kann man aber glaube ich auch als Privatnutzer nicht rausholen.

Wenn man die Flächen nach dem Shader/Material sortiert, dann hat man ja schon viele wichtige Eigenschaften automatisch zusammen sortiert. Dabei kann man dann noch darauf achten, daß man Texturen nicht doppelt bindet usw. Der Befehl glVertexPointer und die anderen Vertex Array Befehle sollen im Zusammenhang mit VBO's teuer sein. Wenn man Flächen die beieinander liegen im gleichen VBO ablegt, was ja meistens automatisch geschieht, dann kann man das auch einfach optimieren. Je nach Detailgrad und Größe des VBO's kann es sein, daß in einem einzelnen Frame nur weniger VBO's benötigt werden.
Letztlich wird man beim Rendern vermutlich sowieso eher durch andere Faktoren wie z.B. Füllrate begrenzt sein, so daß ein glEnable mehr oder weniger nicht unbedingt ins Gewicht fallen dürfte. Wenn man jetzt direkt weiß, daß dieser Aufruf überflüssig ist, ist das sicherlich schneller, aber der Treiber prüft intern nochmal ob der Wert in der Grafikkarte geändert werden muß.
Auf jeden Fall sollte man von Vorne nach Hinten Rendern, falls das der erste Renderpass ist, auch wenn man dadurch keine unbedingt optimale Sortierung hat, weil das auf neueren Karten viel mehr bringt, also eine Texture einmal oder zweimal zu binden.

Vielen dank für all die Infos!
Hatte das Problem das Ich 9 (in Worten: neun ) glSwap´s pro Durchlauf verwendet hab (4*PBuffer + 4*Preview + Composition) was mir meine Framerate bei primitiv-Scenen schon auf 160 gedrückt hat.
Jetzt zeichne Ich meine Previews nur jedes 4.Mal und komm wieder auf 230fps was aktzeptabel ist.
cu
Volker

glSwap? Meinst du damit SwapBuffers?

Hattest du dich schon mal mit der WGL_ARB_render_texture Extension außeinander gesetzt. Mit ihr und mit der Hilfe von ein paar andere WGL's solltest du sehr schnell zeichnen können. Mit ihnen kannst du verhindern, dass deine PBufferDaten erst über den BUS (zum client) geschickt werden. Das spielt sich also alles in der Grafikkarte ab.
WGL_ARB_make_current_read könnte auch noch ganz interessant sein.

Habe das selber zwar nicht ausprobiert aber wenn man der Spezifikation glauben darf, dann sollte das deine Probleme in Bezug auf Geschwindigkeit ein wenig sehr schmälern.