Moin,
kann mir jemand erklaeren, warum eine so


erzeugte DisplayListe beim rufen 100% CPU-Last erzeugt und ich nur noch 2-3 FPS erreiche? 100000 Dreiecke sind doch nicht sooo viel, oder!?

(Die GraKa ist ne NVIDIA FX5500.)

Dank & Grusz,
Eidechsenlord

Also hier sieht alles so weit normal aus (bis auf das du überall double verwendest).
Ich denke das Pushen und Poppen kannst du dir sparen, wenn du stattdessen
LoadIdentity benutzt (wird ja eh randomisiert).


Gib mal den Codeschnipsel, bei dem du aufrufst.

Hallo,
danke vorweg fuer die Hilfe. Hier die Schnipsel:


Die RenderMethode wird von einem RenderThread wie folgt gerufen:


Dank & Grusz,
Eidechsenlord

Ich würde mal sagen es liegt daran das du ständig glBegin aufrufst nur um ein Dreieck zu rendern. Wahrscheinlich schafft OpenGL es nicht das zu optimieren. Du solltest deine Vertices selbst transformieren.

_________________
Yeah!

Hallo,
Danke fuer den Tip. Hab also mal folgendes probiert:


Bringt leider keine Linderung.

Dank & Grusz,
Eidechsenlord

Etwas, das wahrscheinlich garnichts damit zu tun hat: Du benutzt GL_POLYGON_SMOOTH (und andere Smoother). Die sollten nicht verwendet werden. Es kommt da immer wieder zu Problemen mit Kanten bei Dreiecken und ähnlichem, aber auch nicht auf allen Grafikkarten. Ich würde dir empfehlen, dich mal nach Multisampling umzuschauen. Kann es nicht sogar sein, dass OpenGL in den Softwaremodus rennt, wenn man diese Flags aktiviert und die Grafikkarte das nicht kann?

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Also ich habe noch ein bisschen nachgedacht ^_^

Du sagtest ja, dass die CPU-Last auf 100% geht... d.h. es ist nicht die
Grafikkarte, die an den vielen Dreiecken zerbricht (es sind ja in der Tat gemessen
an dem, was für eine große Scene so normal ist, nicht viel).

D.h. es ist entweder ein Softwaremodus-Problem, weil du irgendeine GL-Funktion
nutzt, die deine Grafikkarte nur schlecht unterstützt (durchprobieren), oder
aber der Treiber optimiert/cached deine Displayliste nicht - was theoretisch
naheliegend ist, da bei dieser Vertexmenge das optimieren recht viel Zeit in Anspruch
nehmen würde. Dies hätte auch zur Folge, dass die CPU die Vertices jedes mal wieder
über den (seeehr langsamen) Bus schaufeln muss - und in der Zeit, während die
CPU auf den langsamen Bus warten muss, ist diese eben blockiert (100% Auslastung).

Lösungsvorschläge:
- Erstmal ein paar glEnables wegmachen (testweise)
- Wenn's nicht hilft: Alle Vertex- und Farbdaten in ein _statisches_ VBO packen.

Hallo,
vielen Dank fuer die Hilfe!


Hm, na viel ist's ja nicht, was benutzt wird. Verzicht auf glColor, glTranslate, glRotate und/oder glScale hat nix gebracht.


Klingt plausibel, aber auch die Aufteilung in 1000 DL mit 100 Dreiecken bzw. 100 DL mit 1000 Dreicken (und anschlieszendes Rendern mit glCallLists) hat nicht geholfen. Kleiner sollten doch DL nicht sein muessen ...



Hab fuer den Testfall mal alles abgestellt. Auch hier: keine Besserung.


An VBOs hab ich mich auch schon gewagt. In Wirklichkeit handelt es sich aber nicht um Dreiecke, die darzustellen sind, sondern um beliebige Polygone (auch konkave und welche mit Loechern). Hab also den StencilBuffer zum Rendern verwendet.
Bei einer entsprechend hohen Polygonmenge (5000 Stueck, glaube ich) waren die VBOs dann 10mal langsamer als das Rendern mit DL (in diesem Test besasz jedes Polygon seine eigene DL).

Was koennte das Cachen der DL verhindern? Hat die Hardware evtl. nen Knall?

Dank & Grusz,
Eidechsenlord

Du benutzt einen Thread zum Rendern? Du weißt, dass ein Kontext an einen Thread gebunden ist. Also um einem Kontext in einem Thread benutzen zu können sollte der auch idealerweise nur dort benutzt werden (auch erstellen und zerstören gehört dazu). Denn ich weiß so direkt nicht ob man einen Kontext so ohne weiteres an einen anderen Thread übergeben kann. Könnte mir gut vorstellen, dass du innerhalb des Threads derzeit tausende von Fehlercodes bekommst (wegen fehlendem aktivem Kontext). Und Fehler wirken mitunter sehr bremsend.

Nichts desto trotz würde ich auf Rendern in einem Thread verzichten. Du kannst alles mögliche innerhalb von Threads laden etc. Das ist in der Regel problemlos machbar. Aber alles was gezeichnet wird sollte besser in einem einzigen Thread (VCLThread) statt finden. Denn sowohl die VCL als auch die GDI ist nicht Threadsicher. Da würde ich eher vorschlagen in einem Timer zu zeichnen oder innerhalb von Application.OnIdle. OnIdle kann man aber auch mit einem kleinen Mechanismus dazu bewegen nur maximal 30Bilder in der Sekunde zu zeichnen. Gepaart mit Timebased Movement vereint man so sparsames rendern und gleichmäßige Bewegungen. Die Anwenundung bleibt trotzdem bestens ansprechbar.

100% CPU Last. Na ja. So pauschal würde ich das nicht sagen wollen. Wenn du nur eine riesen Displayliste oder ein VBO zeichest heißt es nicht, dass die CPU-Last gleich 0 ist. Der Treiber muss spätestens bei SwapBuffers warten bis alles abgearbeitet ist. Und dazu wird er das Ergebniss auf der Grafikkarte dauerhaft pollen. Was sich dann wieder in einer entsprechend CPU-Last äußert. Und das obwohl die Grafikkarte dann vermutlich vollständig ausgelastet ist.

Hallo,


100000 Dreiecke sind normalerweise nicht viel, solange sie nicht allesamt komplett ( und ohne Tiefentest ) im Grossformat gerendert werden.
Ich glaube du hast eher ein Problem mit der Anzahl der Fragmente, die auf den Bildschirm gezeichnet werden...


Viele Grüße
dj3hut1

_________________
Wenn Gauß heute lebte, wäre er ein Hacker.
Peter Sarnak, Professor an der Princeton University

Ist 900 000 x Random in der Schleife aufzurufen nicht sehr heftig ?

Gento

Das passiert aber hoffentlich nur einmal beim Generieren der Displayliste, insofern unproblematisch.

Hallo,
Danke fuer die zahlreichen Tips und fuer Eure Muehen!


Die Sache mit den Threads ist sicherlich nicht einfach zu handeln, aber nicht voellig unmoeglich. Die Kontexte werden im jeweiligen Thread erstellt und zerstoert, FehlerCodes werden regelmaeszig abgefragt (gibt keine). Dennoch habe ich nochmal ne Version ohne Threads angehaengt.
Die Entscheidung fuer Threads fiel, da die Anwendung u.U. mehrere OpenGL-Fenster parallel braucht. Threads stellten sich dabei als wesentlich fluessiger heraus als das Rendern mehrerer Fenster ueber eine Schleife in der Idel-Methode. Zu jeder Form gehoert also nun ein Thread, der lediglich rendert und ueber TEvent-Instanzen mit dem Haupthread (Mouse-Events usw.) kommuniziert.


Ja. :-)

Im Anhang wie gesagt mal das Beispiel. Hier: 4 FPS, 96-100% CPU-Last, die GraKa ist nach wie vor eine NVIDIA GeForce FX 5500. Tiefentest sollte m.E. auch funktionieren. Ueber eine Konstante kann man zw. einer groszen und 101 kleinen DL wechseln.
Vielleicht hat ja noch jemand ne Idee.

Gruesze,
Eidechsenlord

Threads: Bei der dglOpenGL gibt es die Methode ActivateRenderingContext. Mit der wird normal ein Kontext aktiviert. Anstelle von dieser Methode kannst du auch direkt wglMakeCurrent aufrufen. Bzw musst du sonst aber als dritten Parameter ein False übergeben. Denn sonst lädt die Unit alle Funktionspointer neu. Das kostet massiv Zeit. Aber selbst wenn der dritte Parameter False ist werden die Extensionstrings neu geparst. Also versuchs mal mit wglMakeCurrent. Dann kostet das Wechseln zwar auch noch Zeit aber bei weitem nicht mehr so viel. Denn alles zu Synchronisieren ist deutlich umständlicher zu programmieren und kostet auch Zeit. Du solltest aber mindest ein mal ActivateRenderingContext ohne oder mit True als dritten Parameter aufrufen. Aber im Endeffekt liegt die Entscheidung bei dir.

Zu deiner Displayliste:

Das solltest du in einer DL gar nicht machen. Grund: glBegin -> glEnd. Daraus wird eine VBO. Ich weiß nicht ob der Treiber schlau genug ist dort alles in ein VBO zu packen. Allerdings zeichnest du 3 Vertices und anschließend müssen States verändert werden. Selbst ohne den glBegin und glEnd Block sackt die Geschwindigkeit beim Rendern gnadenlos ein. Wenn man dann nur glVertex weglässt liegt die Geschwindigkeit nur kaum unter der kompletten Schleife.


Diese Schleife ist mitunter auch problematisch. Da die Flächen sehr groß werden können. Damit kann es sein, dass die Füllrate der Grafikkarte wieder sehr stark belastest wird.


Etwas besser wäre so etwas. Einzige Unterschied besteht eigentlich darin, dass die Flächen maximal 10x10 Einheiten groß sind. Dadurch läuft es mitunter schon reichlich schneller. Du solltest also bei solchen Datenmengen nach Möglichkeit direkt mit Realistischen Daten arbeiten. Und auch möglichst realistisch an dem bleiben was im Endeffekt auch genutzt wird. Dann kannst du es passend darauf optimieren.

Nur einem am Rande. Die Grafikkarte fühlt sich am Wohlsten, wenn du ihr einen Block an Vertices übergibst und sagst "Hier mach mal". Also so viel wie möglich Vertices an einem Stück übergeben. Wenn es dann immer noch hängt, dann liegt es entweder daran, dass ein grober Fehler begangen wurde oder die Grafikkarte zu wenig Leistung hat oder die benötigte Füllrate die Geschwindigkeit des Speichers übersteigt.

Ich hab' mir das Programm mal runtergeladen und bei mir getestet. Läuft im original Zustand mit 12FPS.
Wenn ich jetzt nur die "glVertex3f" in die Schleife packe und sonst alles raus, sind es 300FPS. Füge ich wieder "glBegin" und "glEnd" ein, nur noch 250FPS. Und bei zusätzlichen Push- und PopMatrix schließlich nur noch 21FPS.
Also schätze ich mal das die beiden Befehle die meiste Zeit verbrauchen.
Deshalb solltest du vielleicht wirklich nicht die Matrix verändern, sondern die Vertex-Koordinaten. Da das ja nur einmal passiert ist das wohl auch die schnellste Variante