Ich denke dass hier 2 Sachen den test verfälschen:
bei vielen Aufrufen glEnable mit dem selben Parameter ohne glDisable, wird die Grafikkarte intern wohl nichts mehr ändern, weshalb die Dauer ab dem 2. Aufruf wohl niedriger sein könnte
Wenn du mit gettickcount arbeitest dürfte die Messungenauigkeit um die 15ms liegen

Genau das war ja auch ein Frage der Tests:

Wieviel Zeit benötigen Redundante Aufrufe?
Und wo macht es Sinn zu optimieren?

Genauigkeit: ich Habe sdlticks.pas (aus dem DGL SDK) genutzt.
(wie hoch hier die Ungenauigkeit ist weiß ich nicht, aber egal wie hoch sie ist, der Test gibt Aufschluß wie lange etwas in Relation zu einem anderen Aufruf benötigt).

Güße
User69

Worauf man auch achten sollte: In OGL landet alles in einer Pipe. Also sollte nach den 1,000,000 Aufrufen ein glFlush, oder irgendwas NVFence ähnliches sein, damit man auch sicher ist, dass alles durchgewürgt wurde. Beim Zurücklesen von z.B. glGetFloatv(GL_MODELVIEW_MATRIX, @m); weiß ich auch nicht wies genau läuft. Könnte mir vorstellen, dass das unter normalen Umständen auch blockt bis die Pipe leer ist. In sofern müsste man das noch mit anderen Befehlen, die man vorher gebenchmarkt hat, kombinieren, und das hinterher rausrechnen.
glVertex3f dürfte am schwersten zu testen sein, da es beim Rastern der Dreiecke ganz extrem davon abhängt, ob sie im Viewport sind, ob sie verdeckt sind, wie groß sie auf dem Bildschrim sind, ... aber das sollte nicht so relevant sein, weil ein Aufruf pro Vertex, was will man da einspaaren? ^^

Mich würden zusätzlich noch Statechanges von Shadern, also wechseln von Texturen, VertexProgs, FragmentProgs, RegisterCombinern, ... interessieren. Weil man ja immer hört dass die so viel kosten.

Oh und übrigends, das Ergebnis mit der reinen For-Schleife: Kann es sein, dass die vom Compiler komplett rausoptimiert wurde, weil sie keinen sinnvollen Code - genau genommen gar keinen Code - enthält? Ich meine, das manche Compiler sowas erkennen. Das müsste man mal im Debug-Modus im CPU-Fenster überprüfen, ob der Code noch drin ist.

Also auch wenns nur in 10 mins oder so zusammengekleistert ist, es könnte ein interessantes Tool werden.

_________________
[18:30] tomok: so wie ich das sehe : alles. was nich was anderes ist als nen Essay ist nen Essay

hi, i'm a signature viruz, plz set me as your signature and help me spread

Hallo,

glFlush sollte wohl nicht helfen, da dieser befehl nicht auf den vollständigen Aufruf wartet. Ich habe am Ende der 1.000.000 Loops ein glFinish gesetzt.

glVertex3f: Alternativen Trianglestrips - sicher schneller, aber wieviel? Da gibts sicher ncoh Erweiterungspotential.

reine For-Schleife: Die ist noch drin, jedoch zeitlich unter der Auflösung (oder gerade am Rande), bei 10.000.000 sieht mans dann.

Mich würden zusätzlich noch Statechanges von Shadern, also wechseln von Texturen, VertexProgs, FragmentProgs, RegisterCombinern:
Wenn du interesse hast, das einzuabeiten wäre schön.

Grüße
user69

Anscheinend wird ja hier ein Benchmark gebaut... Gefällt mir... Beim letzten mal wurde er einfach zerredet. Jetzt ist schonmal irgendwas an Code da. Wir hatte ... ich glaub im Wiki ... mal Sachen aufgeschrieben, die wir gern getestet hätten. Könnt ja mal gucken ob ihr das unterbringt. Ne... seh gerade... wurde gelöscht.

Nun ihr könntet z.B. mal messen wieviel Zeit es spart z.B. den Framebuffer zu maskieren, oder den Tiefenpuffer, oder den Tiefentest wegzulassen. Solche Sachen werden z.B. gemacht wenn man irgendwas in den Stecilbuffer rendern will. Uns wurde gesagt, dass derlei maskierungen/deaktivierungen ziemlich effizient sind.

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

Da ich nicht soviel zeit habe das alles umzusetzen war mein plan nicht nur Vorschläge aus der community zu bekommen, was getestet werden kann, sondern auch deren Umsetzung.

Den derzeitigen Code könnte ich zur Verfügung stellen. Er ist z.Z. D4 kompatible und dabei würde ich auch geren beliben, das das doch ncoh recht oft eingesetzt wird (das macht ja auch für höherer Versionen kaum Probleme).
Ich weiß da nur noch nicht, was der beste weg ist, damit viele mitarbeiten können, dann aber alles wieder in ein Programm einfließt und dann nicht 100erte kleiner tests rumliegen (evtl halt nacheinander arbeiten).
Ich will zwar auch selbst gerne daran weiterarbeiten, jedoch kann ich dafür nicht zuviel zeit aufbrigen.

user69

Also so ein richtiger Benchmark wie 3D Mark is denke ich zu viel und am Ziel vorbei. Mir geht es ja nicht darum, wie viele Gummipunkte meine Graka bekommt, sondern wo es sich lohnt zu Optimieren. Also wenns in diese Richtung weiter geht wäre ich auch bereit ein wenig dazu beizusteuern (Hab auch Delphi 4). Mein Vorschlag wäre, dass einer das Framework schreibt (dürfte ja so wie es jetzt ist schon fast ausreichen) und dann kann jeder den Test seiner Wahl in eine eigene Unit packen, die dann nur noch eingebunden und irgendwo aufgerufen werden. Die Units enthalten dann irgend eine Initialisierungsroutine (Texturen oder so laden), was zum Entsorgen des Krams und die eigene Benchmark-Routine die die Anzahl der Iterationen und vllt ein Handle auf diesen Timer übergeben bekommt, und als Rückgabewert n String mit dem Text hat, der dann in die Textdatei geschrieben wird.
Alles in allem würde ich es also so simpel wie möglich halten.
Vielleicht sollte man die gemessenen Zeiten noch auf einen Aufruf zurück rechnen, also durch die Anzahl der Iterationen teilen.

_________________
[18:30] tomok: so wie ich das sehe : alles. was nich was anderes ist als nen Essay ist nen Essay

hi, i'm a signature viruz, plz set me as your signature and help me spread

Sowas hatten wir schonmal mit Modulen in DLL's über interfaces dann weil ja jeder seine eigene Sprache nutzen wollte. Jedes Modul konnte Bilder und Texte als Rückgabewert in einen Baum einfügen.

Wie wärs wenn man so nen Benchmark mal ein bisschen anders angeht und zwar indem man sich eine eigene OGL.dll schreibt die man dazwischen schaltet. Dann kannst du nicht nur die Zeiten von jedem Funktionsaufruf in deiner konkreten Anwendung messen, sondern auch so statistiken im Sinne von:
- Wie oft wurde dieser und jener Befehl aufgerufen.
- Wie oft wurde dieser und jener Befehl sinnlos aufgerufen (zB 2 gleiche glEnable)
- Wie viele Dreieckerl wurden gezeichnet, mit etwas mehr Aufwand kann auch die größe der Dreieckerl in Pixel berechnet werden.
- ...

Ein paar Problemchen bekommt man dabei zwar auch, also beispielsweise wenn man wissen möchte wie lange braucht man um ein Dreieck zu zeichnen bei:
glBegin(...)
einige glVertex(...)
einige beliebige Befehle
glEnd()
Da kann man zwar die Zeit von glBegin bis zum nächsten glEnd messen, und vor der Zeitmessung auch ein glFlush einbauen, aber man hat halt auch die "beliebigen Befehle" drinnen, also zB ein paar cos, sin, ... Aufrufe die nicht wirklich mit OGL zusammen hängen.

Im großen und ganzen würde ich aber so ein Vorgehen viel Sinnvoller finden als nur ne große Tabelle mit Funktionszeiten, da die Werte die dann rauskommen wirklich etwas mit deinem konkreten Programm zu tun haben, und das schönste daran: die Programmiersprache ist auch egal, ist ja ne .dll.

Halte ich führ ziemlich schwer zu realisieren, weil niemand 2x hintereinander glEnable(GL_LIGHTING); macht. Das läuft eher glEnable(GL_LIGHTING); glDisable(GL_LIGHTING); glEnable(GL_LIGHTING); (was Verschwendung wäre) oder glActiveTextureARB(GL_TEXTURE0_ARB); glEnable(GL_TEXTURE_2D); glActiveTextureARB(GL_TEXTURE1_ARB); glEnable(GL_TEXTURE_2D); (was zwar doppelt aber durchaus sinnvoll ist) ... und da dann ne Intelligenz rein zu stecken die von sich aus erkennt, was davon überflüssig ist, dürfte sehr schwer werden. Mal abgesehen davon, dass man am Programm selber schon sehr gut sehen kann was unnötig ist und was nicht. Der eigentliche Aufwand liegt darin es zu ändern ^^. Und wenn man bei jedem glEnable vorher noch den aktuellen State zurückliest um zu überprüfen, obs sinnvol oder unsinnig war, dann kann man auch keine zuverlässigen Zeiten mehr messen. Zumal man einzelne Befehle kaum messen kann, man muss sie schon ein paar tausend mal aufrufen um was zu sehen.

_________________
[18:30] tomok: so wie ich das sehe : alles. was nich was anderes ist als nen Essay ist nen Essay

hi, i'm a signature viruz, plz set me as your signature and help me spread

Die meisten Änderungen werden sich wohl erst vor dem nächsten Zeichnen übertragen. Daher macht es keinen Sinn die OpenGL Befehle einzeln zu testen.

Also ich seh, das ganze stößt doch auf einiges interesse...

@AL: Die deine Idee finde ich Top. Alles als DLLs zu machen ist mir aber zu aufwendig. Als units ist es top (das habe ich mal schnell umgeschrieben). Dann kann man alles zusammen compilieren. Meld dich doch mal mit deiner email bei mir. Dann kann ich dir mal den code schicken. und wir können ein erstes gerüst für das Framework abstimmmen. Dann können wir es hier einstellen, damit jeder seinen Teil zum Testen schreiben kann.

@Lyr: Tolle Idee, leider fehlt mir zu sowas absolut die zeit und power. Falls du sowas auf die beine kriegst wärs toll.

@Ihr seid wilkommen un einzelne test zu schreiben. Der Code wird dann nach ersten Abstimmungen gepostet. Wer Interesse hat am besten Email mit pm an mich.

Grüße
User69

Der Nachteil bei den einzelnen Units ist natürlich, dass man die Module nicht mehr unabhängig kompilieren kann.

Stimmt. Das hält aber die arbeit fürs framework klein. odr hättest du interesse das interface für die dlls zu schreiben?

Das Framework steht ja dann zur Verfügung und man kann damit die eigenen untits testen und kompilieren.

User69

bei der Idee eine eigene OGL.dll dazwischen zu schalten wär es schon möglich auch zu überprüfen, ob Befehle sinnlos aufgerufen werden, auch sowas:

dazu muss lediglich mitgespeichert werden ob zwischen den Aufrufen Zeichenbefehle waren. auch andere Problemfälle kann man so lösen, wenn man nur genug gesamtwissen in der dll ansammelt (Wodurch die allerdings natürlich ne gewisse arbeit bedeutet)