Hallo,

kennt von euch jemand die Rechenzeiten, die für die verschiedenen OpenGL Operationen benötigt werden?

Für mich gäbe das einen Entscheidungsmatrix, welche Befehle man oft verwenden kann und worauf man besser optimieren sollte. Auch wäre es interessant zu sehen, wieviel überhaupt welche optimierungen bringen würden - wenn etwas kaum verbesserungen bringt wäre unsinnig dort noch zu optinieren.

Interessant wären z.B. Zeiten für:

Statechanges: z.B. glEnable, glDisable (ohne den pos/neg. Auswirkungen der States - einfach durch unnötige/doppelte Aufrufe)
Matrix OPs: glMatrixMode, glMultMatrixf, glTranslatef, glRotatef
allgemein: glGetFloatv
Doppelte/Unnötige Aufrufe von: glNormal3f, clColor
...

Grüße
User69

hmmm ... schon wieder einer ... Such mal hier im Forum nach DGL Benchmark. Du bist im Grunde nicht allein mit dem Wunsch nach Detailwissen. Nur hat das noch niemand hier ausgiebig genug getestet.

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

Kann man auch nicht ausgiebig genug testen. Ist von Grafikkarte zu Grafikkarte, von Treiber zu Treiber und (wenn es nicht gerade um State-Changes geht) von Umgebung zu Umgebung unterschiedlich.

Es gibt diesbezüglich durchschnittliche Zahlen und das wars im allgemeinen Fall. Wenn du wirklich aufs extreme optimieren möchtest, so musst du Benchmarks auf der Platform laufen lassen auf der du optimieren möchtest.

Diesbezüglich ist auch ein Artikel recht interessant zum lesen: http://delphi3d.net/articles/viewarticle.php?article=stateman.htm

Und noch nebenbei bemerkt: für effizientes rendern solltest du nirgends ohne gute Gründe einen glNormal-Aufruf haben.

Generell kann man aber wahrscheinlich sagen: wenn du dir über die Anzahl der State Changes (und welche davon nötig sind) Sorgen machst, dann hast du höchst wahrscheinlich schon mehr daran gedacht als sehr viele andere.

Oder gerade deswegen fing man erst an sich Sorgen zu machen Also ich erinnere mich noch an die Zeiten an denen 50 Polygone einer Grafikkarte das Genick gebrochen haben. In aktuellen Projekten habe ich bislang noch nie geschafft die Rate unter 100 FPS zu bekommen, egal wie herzlos man mit den Ressourcen umgegangen ist (keine Sichtkontrollen, ständige Texturechanges). Führt man dann eine Sichtberechnung durch und sorgt dafür die glBindTexture zu minimieren, so fällt es mir sehr schwer zu glauben, dass ein glEnable(GL_DEPTH_TEST); überhaupt irgendwie lohnt noch berücksichtigt zu werden.

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Danke erst mal für die Antworten.

Mein Projet muß unter Windows laufen, egal welche Hardware(also auf allen).
Demzufolge wird eine Hardware abhängige optimierung eher ausfallen.

In der Darstellung arbeite ich mit Smooth Schattierungen, und auch mit Vertexnormalen (darauf kann ich nicht verzichten - aber evtl. vermeiden die selbe normale nochmal zu zeichen). Dabei werden auch mehrere 100.000 (oder auch Millionen) Dreiecke dargestellt.
Also die fps bekomme ich locker runter - auch unter 1.
Ich will jetzt mal versuchen die Dreiecke in Strips zu packen, was aber aufgrund der verschiedene Vertexnomalen und Farben schwer fällt und evtl. nicht mehr so viel bringt.

Meine Hoffnung war unter neutralen Bdingungen (z.B: ohne HW Acceraration - nur mit Software OpenGL) schleifen (z.B. 100.000 mal den OpenGL Befehl auführen und dann rechenzeit ermitteln) zu rechen und dann einen Wert zu erhalten. Gibt es denn sowas schon?

Ansonten einfach eine Abschätzung was kostet viel Rechenzeit:
glNormal3f ?
clColor3f ?
GlEnable / GlDisable (z.B Clipplane0, DepthTest ...)

user69

Aber auch dann hängt es von der Implementation des Treibers an. Wieviele Takte hat den die CPU bzw. GPU usw. und wie werden Anweisungen umgewandelt für die Pipeline. Eine Aussage wie "Soll auf jedem Windows laufen" halte ich für sehr zweifelhaft und würde ich mir niemals in ein Pflichtenheft kommen lassen. Den wir Du feststellst 100.000 Polygone, dass ist keine Voodoo-Karte mehr, die das packen soll. Mehr Sinn macht es in der Regel eine technische Deadline zu ziehen (z.B. OpenGL-Version) und danach zu entscheiden, was man überhaupt verwenden kann. Ein Blick in die Preislisten offenbart, dass eine Geforce 5200 (128 MB RAM) für teilweise unter 33 € erhältlich ist. Schlägt man noch eine Generation darunter, so wird man sich realativ sicher sein können, dass selbst aktuelle Office-Rechner mit Oboard-Karten entsprechende Features unterstützen. (Zu lasten des RAMS versteht sich). Ich würde also meine technische Deadline min. irgendwo in dieser Region einsetzen und die Anwendung dafür entwickeln.

Bei der Optimierung kommt es dann darauf an, was sie darstellen soll. Wie gesagt, alles was die State-Machine verändert wird man vernachlässigen können. Interessant wird es stets dort, wo Du beginnst die Grafikkarte mit Informationen zu füttern (Geometriedaten, Texturen). Je weniger, je kleiner, desto weniger wird es fressen. Alle States, die sich massiv auf die Rechenleistung auswirken sollten dabei deaktiviert sein (Blending, Lightning, Tiefenpuffer wohl eher nicht). Evtl. mit Weichen arbeiten um die Anzahl der Daten zu minimieren. Dann schnappst Du Dir in regelmäßigen Abständen deine Deadline und schaust, wie es dort läuft. Dort sollte es dann auch leicht sein zu ermitteln, welche Teile (nicht Funktionen) der Maschine das Genick bricht. Bei alten Karten ist dies meist wenn die Kamera sehr nah an eine Textur heran ging).

Aber eine Software die auf allen Windows-Systemen läuft UND 100.000 Polygone über den Jordan schickt, wird es so nicht geben und sollte ggf. dem Auftraggeber auch so erklärt werden. Insbesondere wenn die Investitionskosten so gering sind, wird man dafür auch Verständnis haben (weil 30€ ist nicht vergleichbar mit dem zeitlichen Aufwand für viele Weichen zur Optimierung). Dazu kommt, dass in spätestens zwei Jahren (vista sei dank) wohl sowieso fast nur noch DX9-Karten auf dem Markt wusseln

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Am besten wärs wahrscheinlich du schreibst dir deine eigenen Tests, ist eh schnell gemacht. Aber hier mal etwas ältere Test-Ergebnisse von mir (auf meinem System):

Sehr schnell:
MatrixMode

Ganz grob etwa doppelt so lange:
(zumindest einige) glEnable/Disable, hab nicht alle probiert

Ganz grob etwa 10-15 mal so lange wie MatrixMode:
Push/Popmatrix, Translatef, Loadidentity und Loadmatrix

Multmatrix is mit ~24 mal so lange dabei.

Rotatef war von den Funktionen die ich probiert habe mit 50-60 mal so lange ziemlicher Rekordhalter.


BindTexture war so im Bereich 5-10 mal so lange, kann aber sehr sehr stark abhängig sein von Textur-Art, Größe, liegt sie im Grafikkarten-RAM, ...

Das glNormal und glColor und so dürfte wohl ziemlich das schnellste von dem ganzen Zeug sein, dafür braucht man sie auch am häufigsten. Wie gesagt besser wäre ggf. ein Vertex-Buffer.

Hi,

danke erstmal an Lyr. Etwa solche Aussagen hatte mir erhofft. Vielleicht hat ja auch noch jemand soche Erkenntnisse.
Oder man muß doch mal ein Programm basteln (da ist wieder dieses Probelm, daß der Tag nur 24 Stunden hat ), daß genau das testet und in ein logfile schreibt. Dan kann man ja auch hier in dem Forum die verschiedene Hardware testen und vergleichen (z.B. in einer Übersicht).

Ich erwarte aber, daß wie Phobeus schon schrieb gerade doppelte glColor und glNormal aufrufe ne Mege Zeit Kosten.
Was bring den bessere Ergebnisse: Triangle Strips oder Vertex Buffer (under Berücksichtigung einer breiten Hardwarebasis)?

Phoebus:
Auf allen Windows laufen meint ich natürlich auf gängiger Hardware (so ab Geforce oder GF2) Davor sind diese Polygonmengen schon echt zu viel. Zum Glück können aber auch die on Board chips nun schon ein recht annehmbares OpenGl.

Noch ne Frage an Phobeus: Wie meinst du das?
>Dazu kommt, dass in spätestens zwei Jahren (vista sei dank) wohl sowieso fast nur noch DX9-Karten auf dem Markt wusseln
Können die dann kein OpenGl mehr oder OpenGl mehr perfekt? Wie steht es den um die OpenGl zukunft mit Vista?

Grüße
User69

Jein. Der Grafikkarten-Markt ist ein Spielemarkt und dieser wird natürlich von DX dominiert, entsprechend sind die Marketing-Namen auch daran orientiert. Eine DX9-Karte ist also (IMAO) in NVIDIA-Rahmen >GeForce5. Also Karten, die mit Fragment und Vertex Shader umgehen können. Da Aeroglass vermutlich doch vom einen oder anderen "Gamer" verwendet wird, sollte man davon ausgehen, dass dieser Kartentypus bald Standard sein wird. (Bei den Lebenszyklen wahrscheinlich auch schon ohne Aeroglass *sg). Ergo, wenn Du heute beginnst eine Anwendung zu schreiben (z.B. ein Spiel) und Du würdest mit heutigen Minimum-Karten arbeiten, würdest Du in 2 Jahren übers Ziel hinaus schießen und Techniken verwenden, die aus moderner Sicht nicht effzient sind. War ein BSP-Tree früher wichtig um zu Berechnen welches Polygon überhaupt gezeichnet werden muss, würde eine solche Technik ein modernes System ausbremsen, dass ohne Probleme die volle Geometry in wenigen Takten durch die Pipeline pustet. Mehre Rendererpasses, weil man nur mit einer Texture-Unit auskommen wollte? Das wäre schade, da heutige Systeme mächtig davon profitieren würden. Am falschen Ende zu sparen kann dazu führen, dass alle Ergebnisse unterdurchschnittlich sind, selbst dort, wo eine wesentlich bessere Leistung möglich wäre. Der Versuch von MS OpenGL unter Vista einzuschränken wurde (sofern ich aktuell bin) durch heftigen Protest abgewendet. OpenGL wird immer ein Standard bleiben, da er in Industrie und Wissenschaft dominiert.

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Eine Sache die in meinen Tests auf einer 3D-Karte mit sooo nem Bart unglaubliche Geschwindigkeitsvorteile brachte, war die Befehle glMap2f und glEvalMesh2.

Die hohe Geschwindigkeit dieser Befehle liegt darun zugrunde, dass der Grafikkarte keine Tonnen von Vertex-Daten übergeben werden müssen, sondern das die Karte lediglich die "Eckpunkte" des zu zeichnenden Objektes bekommt und die zugehörigen Vertex-Punkte von der Karte selbst berechnet werden. Die Datenmenge die über den Bus geht sinkt also je nachdem dramatisch.

Außerdem hat die Sache noch einen anderen Vorteil: Da ich quasi das Objekt mathematisch beschreibe, kann ich der Grafikkarte sagen, mit wie vielen Quads das Objekt gezeichnet werde soll. Ich kann also über einen einzigen Parameter steuern, wie detailliert das Objekt ist, und so problemlos eine Funktion schreiben, die das Objekt je nach Distanz zur Kamera in den Details reduziert, ohne das der Betrachter davon etwas mitbekommt, was natürlich auch wieder viel Rechenleistung spart.

Schön das du die Befehle ansprichst. Könntest du mal eine kleine Demo schreiben die ein <<beliebiges interessantes Objekt hier einsetzen>> mit diesen Befehlen und dem beschriebenen LOD rendert? Würde sicherlich im Wiki gern gesehen werden. Büdde

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

@Two: hast du auch ein glFlush dahinter gepackt, also bevor du die Zeit misst? Ist ja nicht so das Grafikkarte und CPU 100% synchron arbeiten. Kann mir nicht vorstellen dass glMap jetzt wirklich schneller ist als wenn du entsprechend viele statische 3eckerl zeichnest. Kommt natürlich auf die Zeichenmethode und viele andere Sachen drauf an aber so im Großen und Ganzen halt.

@all:
Hat nicht jemand mal interesse ein keines Projekt zu starten, daß genau diese Zeitmessungen macht. Das kann ja dann hier von der Community weitereintwickelt werden (ich habe zwar einiges mit OpenGl gemacht aber nicht mit den DGL Headern und Templates):

-OpenGl RC erzeugen mit Randbedingungen: Fixe Größe (Wählbar ob Software oder Hardware Beschelunigung, z.B. 800x600 alternativ wählbar Fullscreen; wählbere Farbauflösung: 32/24/16 bit, wählbare Depthbufferauflösung...) - d.h. Pixelfomat gezielt aussuchen
-Logfile erzeugen mit: Windows Version; Prozessor und Speed; Gafikdetails (Hersteller, Treiber, OpenGL Version.. was halt auszulesen geht), Kennwerten des Pixelformates
- Schleifen erzeugen, die verschieden OpenGL Befehle (z.B 1.000.000 mal) duchlaufen und dann die zeit nehmen (evtl den Overhead der Schleifenzeit abziehen) und dann auch loggt (inkl dem entsprechenden Befehl).

Das kann dann später noch beliebig ausgebaut werden (automatischer Ablauf, Extention, LOD, Strips, Vertexbuffer...). Ich denke hier finden sich sicher dann leute, die das mit Aufnhemen würden.

So könnten wir schell Ergebnisse von x usern bekommen und vergleichen was wann welche Zeit braucht.

User69

Ich habe keine Zeit gemessen, ich hab nur festgestellt das das Zeichnen eines Meshes statt einem Vertexarray (mit prinzipiell gleichem Inhalt) die Framezahl verdreifacht hat. Da ich hier mit einer sehr alten AGP 1x Karte arbeite gehe ich mal davon aus, dass die Übertragung von ca. 40.000 Dreieck-Koordinaten halt so seine Zeit frisst.

Ich kann leider nicht das ganze Programm posten, da es doch etwas zu lang ist (es beinhaltet fast alle Tutorials da es mein Testprogramm ist). Ich kann hier aber mal meine Routine posten, mit der ich bei einem Würfel eine Fläche in Abhängigkeit der Distanz zur Kamera in mehrere Einzelteile zerlege.
Die Idee war primär um die Lichtdarstellung auf einer Fläche zu verbessern, aber stellt man beispielsweise mit einer ähnlichen Methode eine Kugel dar, kann man damit auch prima die Anzahl der Dreicke im Bild reduzieren.

Ich empfehle sehr stark vor der Verwendung der Meshes sich mal das Kapitel in der Tutorial-Sektion durchzulesen und einen Blick in das Thema Bézier-Kurven zu werfen, ansonsten wird man sich wundern wie die Controlpoints eigentlich das Ergebnis produzieren.

Hallo,

ich habe mal einen Speedtest programmiert:

Wenn jemand interesse hat dieses mit komplexeren Testcode zu vervollständigen , dann bei mir (oder hier im Tread)melden, wir können das Projekt ja dann ausbauen und ins wiki stellen.

Bis dann
User 69

Hier die Ergebnisse (Hardware Athlon 2.600 - GeForce4 MX Integrated):
- Jeweils 1.000.000 Loops - Bei Triangles 1.000.000 Dreiecke
SwapBuffers - nur ein einzelner Aufruf
(dieser Test ist derzeit nur simpel (einfache Schleifen - Keine Kombinationen))