Ist zwar D3D aber beschreibt das Problem:

"Accurately Profiling Direct3D API Calls":
http://msdn.microsoft.com/library/defau ... _Calls.asp

Man kann nicht einfach die Zeit der Aufrufe messen.
Zumindest gibt es da eine Tabelle mit CPU Takten für jeden Befehl.

Hab den Artikel mal überflogen und ich denke, dass es doch halbwegs möglich ist. Man muss nur viel mit schleifen und glFinish (oder NVFence) arbeiten, aber das hatten wir a auch schon gesagt. Das ganze über DLLs machen is jetzt auch kein Ding der Unmöglichkeit, aber ich wollte einfach nicht noch viel Zeit in eine GUI stecken (Lars hatte ja einen Baum angesprochen, in den alles eingefügt wird). Das reine Laden der DLLs is kein Aufwand.

_________________
[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

Schwierigkeiten gibts, wenn Windows einem mitten im Rechnen die CPU-Zeit entzieht, was anderes macht und einem dann 500.000 CPU-Schritte später wieder in die Hand drückt, das versaut jede Messung.

Eine Alternative wäre wie oben angesprochen die Befehle so lange auszuführen, bis man eine repräsentative Menge hat, die man dann über eine Median-Mittelwertsbildung auswerten kann, um dann hoffentlich zu den echten Werten zu kommen. Median "filtert" dabei nämlich solche falschen Werte aus.
http://de.wikipedia.org/wiki/Median

@user68:
So ne .dll ist recht schnell gemacht, man nehme GLTrace, modifiziere es ein klein wenig so das die Zeitmessungen etwas genauer und an der richtigen Stelle sind und das wars auch schon. Der Source ist C, wennst das nicht kannst kann ich dir das schon machen.
Das größere Problem daran ist die Interpretation der Daten. Also von GLTrace erhältst du (wennst nicht allzu viel dazu programmieren willst) ein Logfile als Ausgabe, was dann etwa so ausschaut:

Wie gesagt Zeitmessung ist ungenau und auch nur ein Zeitpunkt nicht wie lange ein Befehl braucht.

Dafür bräuchtest dann halt eine Art Parser der dir meinetwegen die Anzahl der Befehle zählt.

Alternativ dazu könntest natürlich das Befehle zählen (und dergleichen) gleich in der .dll machen, würde halt einen Parser ersparen. Das wäre mir für meinen Teil allerdings doch ein klein wenig zu viel Aufwand da etwas ordentlich interpretierbares zu berechnen, also müsstest das wohl selbst machen.

Mir persöhnlich ging es eher darum kleinere Stückchen zu testen um zu sehen wo sich optimierungen lohnen.

Und genau da habe ich auch schon das erste Problem:

Es geht darum, wie viel es bringt, die Meshes nach Texturen zu sortieren, um weniger Texturwechsel zu haben.


Versus



Ergebnis auf meiner NV GF4Ti mit AMD 2800+ 1 Gig Ram und WinXP:



Den Zeitlichen unterschied kann man so gut wie vernachlässign. Ok nun kann man sagen, dass das daher kommt, dass die 2. Methode 3 Schleifen hat (also mehr Jumps, CPU muss öfter flushen, ...) aber meiner Meinung nach braucht man nunmal 3 Schleifen, wenn man das irgendwo implementiert.
Trotzdem habe ich es mal zusammengefasst, also die mit * gekennzeichneten Zeilen rausgenommen und bei ** noch den Faktor 250 dazu und das Ergebnis:



Die kleineren Schwankungen kommen durch Interrupts wie Two sie bereits beschrieben hat, aber wie kommt es, dass es praktisch keinen Geschwindigkeitsunterschied gibt?
Selbst wenn ich die Quads kleiner mache (paar Pixel), so dass die Fillrate keine Rolle mehr spielt, bleibt der Unterschied nach wie vor im 1% Rahmen.

Sind die Treiber mitlerweile so gut optimiert, dass Texturwechsel nicht mehr so schlimm sind, oder spielt es erst ne Rolle wenn man kompliziertere Wechsel (mehrere TextureUnits + Shader) hat?

_________________
[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

In diesem beispiel wird das vermutlich daran liegen, dass das zeichnen CPU- oder an der AGP Schnittstelle Bandbreitenlimitiert ist und dadurch die paar texturwechsel einfach untergehen. Bevor man sich allerdings den Aufwand macht seine Modelle nach Texturen zu sortieren wird man im Anwendungsfall vermutlich eh erstmal Displaylists oder VBOs verwenden um die CPU und Bandbreitenlast zu reduzieren. ( Füllratenlimitation rauszunehmen ist auch ne gute idee .


Ansonsten isses aber wirklich so, dass bei einigermaßen komplexen Modellen es kaum ins gewicht fällt, ob diese nach Texturen sortiert sind.

Eine andere Idee wäre, dass die Grafikkartentreiber erstmal die gl-Befehle sammeln um sie dann optimiert und am Stück an die Grafikkarte zu senden. Denn eigentlich brauch die Grafikkarte vor dem SwapBuffers ja gar nichts erhalten, denn erst dann werden die Befehle relevant.

Ich hab mal ein paar Messungen gemacht indem ich die Anzahl der CPU-Schritte zwischen gl-Befehlen gemessen habe. Das ganze funktioniert mit dem Befehl DW $310F.

Hier erstmal die Messungen, Werte in CPU-Ticks (Mittelwert vom Minimalwert von je 10.000 Durchläufen, nach jedem Durchlauf glFlush), Erläuterungen gleich:


Erläuterung zur Vorgehensweise

Angaben wie v4 bzw. M4x4 bedeutet das ich hier selber gerechnet habe, ohne das OpenGL verwendet wurde (Unit VectorGeometry.pas). Der verwendete CPU kann kein 3dNow, daher kann es durchaus sein das es auf modereneren CPUs noch deutlich schneller geht.

Erstmal wird sich wahrscheinlich die Frage stellen, warum ich den Mittelwert der Minimalwerte von 10.000 Durchläufen genommen habe. Bei meinem ersten Versuch habe ich einfach den Durchschnittswert berechnet, dann aber festgestellt, dass dieser extrem abhängig ist von Dingen wie Festplattenzugriff, Mausbewegung, Fenster die geöffnet sind usw. Ich konnte teilweise durch Mausbewegung den Durchschnittswert verdoppeln. Also habe ich den Minimalwert von 10.000 Durchläufen genommen, nach der Logik das eine Berechnung zwar durch äußere Einflüsse unterschiedlich lang dauern kann, aber niemals weniger als die eigentliche Rechenzeit. Daher muss die minimale Zeit die reine Rechenzeit der Berechnung sein. Mit dieser Methode bekam ich auch sehr stabile Werte, unabhängig davon was ich sonst noch gemacht habe.

Desweiteren sollte man beachten, dass CPU-Takt nicht 1 zu 1 auf Rechenzeit umgerechnet werden kann, da die CPU-Taktrate stark abhängig ist von der Optimierung des jeweiligen CPUs. Beispielsweise würde ein 120 P1 wesentlich mehr Takte brauchen als ein P4 mit paralleler Berechnung von 2 Befehlen. Man sollte die Werte oben als Schätzung +/-100 Takte interpretieren.


Interpretation der Ergebnisse

Interessant ist erstmal, dass Berechnungen von Hand (also ohne OpenGL) immer schneller sind als mit OpenGL. Daraus kann man schließen, dass man wann immer möglich Berechnungen selber durchführen sollte.

Dann ist interessant zu sehen, dass die Berechnung von sin/cos extrem flott geht, selbst auf so einem alten P2 wie der den ich benutzt habe. Und zwar in etwa so schnell wie einen Vektor mit einer Matrix zu multiplizieren. Hier kann man sich also ggf. einige Optimierungen um sin/cos rauszuwerfen sparen.

Berechnungen wie Matrizenmultiplikation sind stark abhängig von den verwendeten Matrizen. Berechne ich M*Mi (Mi = Identitätsmatrix) dann ist das wesentlich flotter als wenn ich 2 andere Matrizen multipliziere, ähnliches gilt für Vektoren. Ist auch logisch wenn man bedenkt das die CPU eine Multiplikation durch wiederholtes Addieren berechnet. Ich habe daher hier immer die Matrix zu Beginn mit zufälligen Werten gefüllt.

Wenn man sich die glEnable/glDisable-Zeiten anschaut, dann ist auffällig, dass die Kombination der beiden Befehle nicht so lange dauert wie jeder einzeln. Allerdings ist hier das Problem von oben zu beachten, hier muss man +/-100 Takte Ungenauigkeit miteinberechnen. Denn erstmal braucht die reine CPU-Count-Abfrage jeweils 59 Ticks, also müsste man zu den 540 eigentlich noch 120 dazu rechnen, und zusätzlich braucht der Funktionsaufruf der gl-Befehle ja auch noch Rechenzeit, so dass letztendlich die Zeit ca. bei vielleicht 650 zu 700 liegt, was dann dank der Ungenauigkeit in etwa das selbe sein dürfte.

Man muss bei den Minimalwerten sehr genau darauf achten, was man messen will. Wenn es wie bei dir einzelne Befehle oder sehr kurze Code-Stücke sind (z.B. Handgeschriebener 3DNow oder SSE Code), dann sollte man tatsächlich aus den von dir genannten Gründen die Minimalwerte nehmen, weil dass dan auch die tatsächlichen Zeiten sind.
Bei größeren Codeblöcken sollte man sich dann jedoch mal Gedanken machen, warum die Durchschnittszeiten höher sind. Wenn dann der Code so ist, dass er halt häufiger Collisionen (Cachemiss, Lock in einer critical region, ...) verursacht, dann sollte sich das in den Messwerten auch wiederspiegeln.




Sowas wäre begrenzt möglich, jedoch kann sie auch nicht zu lange warten, weil sonst die Parallelverarbeitung in CPU und GPU nicht voll ausgenutzt wäre.


Ich werde die Tage mal noch ein paar Tests schreiben und mich dann nochmal mit User absprechen, um den Code zu säubern und zu posten. Vielleicht werde ich ja schlauer daraus...

_________________
[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

Mit solchen Aussagen muss man sehr sehr vorsichtig sein. Es war nie ein allzu großes Problem für Grafikkarten Texturen zu wechseln, ist ja (mehr oder weniger) nur ein State-Change. Die Probleme fangen erst dann an, wenn du mehr Texturen hast als in deinen Grafikkarten-Speicher rein passen. Wenn sie nicht mehr rein passen werden sie im Hauptspeicher ausgelagert wodurch im schlimmsten Fall bei jedem Texturwechsel die Textur über deinen Bus vom Hauptspeicher zur Grafikkarte gelangen muss. Wenn du heutzutage so deine 128MB Grafikkartenspeicher hast treten diese Probleme jedoch erst etwas später auf als früher.

Hab ich im Wiki auch kurz unter Bandbreitenlimitiert angeschnitten. Diesbezüglich möchte ich auch gleich auf die anderen Limitierungen verweisen: Füllrate, Vertexlimitiert und Shaderlimitiert. Vielleicht findet sich hier ja einer der diesen Listen für Ursachen und Problembehebung noch das ein oder andere hinzu fügen möchte :-).

Ja, eigentlich sollte man Minimalwert und Mittelwert angeben bei solchen Messungen. Das Problem ist nur das dank Windows so viele weitere Faktoren in die Mittelwert-Messung mit einfließen, dass der Mittelwert kaum noch Aussage hat. Wenn sich die Rechenzeit im Schnitt verdoppelt, wenn der User bei der Rechnung die Maus bewegt, dann lässt sich daraus schlecht eine Schätzung für den durchschnittlichen Zeitverbrauch abgeben.

Hier stellt sich die Frage wie man einen Mittelwert für die verbrauchte Rechenzeit angibt bei der möglichst alle störenden Faktoren vermieden wurden. Oder ob es sinnvoll ist, bei bestimmten Anwendungen einfach gewisse Faktoren die immer auftreten mit einzuberechnen. Andererseits könnte man auch argumentieren, dass die Rechenzeit ja der minimalen Zeit entspricht, nur dass eben je nach Situation noch weitere Faktoren dazu gerechnet werden müssen. Nur wenn ja, dann welche?

Naja wie dem auch sei, ich denke man sieht das Problem das hier bereits die Definition von "Rechenzeit" extreme Schwierigkeiten bereitet, was das Messen dieser natürlich noch schwerer macht. Stellt sich hier also die Frage, was hier als Zeitmessung als Abschätzung für die allgemeine Verwendung der Funktionen überhaupt sinnvoll ist. Es bringt ja recht wenig wenn da ein Wert steht, der zwar richtig ist, aber in 99% der Anwendungsfällen nicht zutrifft. Genauso wenig hilft es aber, wenn ich von einer Tabelle mit 247283979723 Einträgen erschlagen werde, in der ich mir dann meinen speziellen Fall raussuchen muss, der sich dann aber bei winzigen Programmänderungen schon wieder komplett ändert.

Sry, dass es so lange gedauert hat, aber User69 und ich hatten viel um die Ohren und ham irgendwie vergessen, dass wir das Prog ja Posten wollten. Wo sollte das denn am besten hin? Ins Wiki? Oder in die Projekte-Ecke? Es ist ja so entworfen, dass jeder über DLLs eigene Tests schreiben kann. Wenn also jemand solchen Code auch noch posten will, sollte es auch dafür eine Möglichkeit geben...

_________________
[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

Macht am besten folgendes:
Zuerst macht ihr hier einen Projektthread + Meinungsthread auf. Dann schreibt ihr in den Projektthread ne art Doku, in der beschrieben steht welche tests dabei sind, und wie man eigene schreibt. (Wenns in Java wär könnte man leicht ne schöne Pluginschnittstelle schreiben...aber egal)

Falls dann ein Paar Tests ("Plugins") zusammenkommen, könnt ihr wie Lossy ne Projektseite im Wiki aufmachen.

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

Ich weiß nicht ob es euch helfen wird aber ich hab in X-Dream neben Perfmon noch SysInfos entwickelt, welches sehr viele Systemdaten erfasst egal ob linux/windows. Mit unter ist auch SMBIOS,CPU,RAM und noch ein paar sachen.

Hier mal die Demo aus meinem Repo.



Ergebnis ist dann folgendes

Wie man gut sehen kann hab ich das zählen der Zeit vom Quad Rendern, vor der Übergabe des ersten Quads gestartet.
OpenGL gibt ja die Daten über den Bus und die Graka arbeitet dann auch sofort los und erst wenn der BufferSwap durch ist, ist sie fertig. Wenn man dann auf die Ansicht von Werten Switcht sieht es in meinem Beispiel dann wie folgt aus.


Mehr Infos findet man hier
http://www.linuxprofessionals.org/xdream/
und hier
http://www.linuxprofessionals.org/xdream/wiki/index.php/XD_Perfmon

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004