meine Simulation, welche mittlerweile ganzschön riesig ist, verhält sich bei manchen projekten komisch. Kurz nochmal zur Erinnerung, ich verwende Techniken wie Deferred Pipeline & GPU Partikel (transform feedback). Nun hab ich bei manchen Projekten (welche Partikel emitter enthalten) folgendes phenomen: 1. Das Projekt wird geladen 2. Es wird nur die Szene gerendert, da noch alles aus ist > 10-20% CPU Auslastung und Framezeit von ca 10ms 3. Nun schalte ich einmalig einen Partikel emitter ein (nun springt er auch in die Partikelpipeline) > immernoch 10-20% CPU und ca 11ms 4. Nach ca. 30sek springt nun die CPU auslastung auf 110% (also mehr als 1 Thread obwohl ich nur im Mainthread rendere) Framezeit geht auf 15-16ms 5. Nun kann ich machen was ich will, die Auslastung bleibt immer bei über 100%, selbst wenn ich den kompletten Renderpfadabschalte!!
So ganz konnte ich das noch nicht eingrenzen.. mal passiert es mal nicht. Woran könnte sowas liegen?! Habe schon mein ganzes Projekt durchsucht, es läuft von mir kein weiterer Thread. Legt OpenGL hier vielleicht automatisch irgendwo noch Threads an? Selbst wenn ich den kompletten Renderkontext kaputt mache bleibt die Auslastung bei 100%..
Registriert: Do Sep 02, 2004 19:42 Beiträge: 4158
Programmiersprache: FreePascal, C++
Nicht nur libs ist interessant, auch Betriebssystem und Zielprozessorarchitektur selbigens sowie Programmiersprache.
Wenn das geklärt ist: Das ganze erscheint mir merkwürdig. Wie sieht die Speicherlast aus? Könnte es sein, dass dein Programm anfängt zu swappen und das dazu führt, dass mehr CPU-Zeit für I/O verwendet wird? Gerade, dass es erst nach einiger Zeit auftritt klingt schon ziemlich verdächtig nach einem Speicherleck (da kann dann auch mal ein Kernelthread dafür verantwortlich sein, dass du über 100% kommst).
grüße
_________________ 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
Registriert: Mo Nov 08, 2010 18:41 Beiträge: 769
Programmiersprache: Gestern
Das sagt jetzt so ziehmlich nix.... poste doch einfach mal deine makefile (oder was auch immer Delphi da hat). Eventuell noch die LoadLibrary Geschichten usw. dazu... Wenn da nix zu finden ist, dann ists wohl irgendn Zombie den du selber erzeugt hast.
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2622 Wohnort: Berlin
Programmiersprache: Go, C/C++
Ich kann folgendes Empfehlen. Lade CodeXL(http://developer.amd.com/tools/heterogeneous-computing/codexl/) und schick das Binary mal durch den Profiler. Wenn die Performance im Keller ist, dann beende das Profiling oder pausiere es, sofern du eine AMD CPU(CodeXL ist für AMD ausgelegt und für andere CPUs geht nur das normale profiling) hast. Nun kannst du gucken, wieviele Unterprozesse laufen und wo die drin hängen sowie wo die cpu am meisten Zeit verbracht hat. Wenn es z.B. ein Speicherproblem ist, dann sollte ein Thread swappen, also wäre er in einer system bibliothek, bei OGL Sync Problemen wird einer der OGL Calls(begin/end, bind/unbind, enable/disable,...) oben erscheinen.
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2622 Wohnort: Berlin
Programmiersprache: Go, C/C++
Wie gesagt geht das normale Profiling auch mit CodeXL auf anderen CPU's aber nun zu deiner Frage. Ja es gibt ein Konkurrenz Produkt von Intel, welches sich VTune nennt http://software.intel.com/en-us/intel-vtune-amplifier-xe aber leider ist es verdammt teuer und CodeXL ist umsonnst, kann normales Frame sample profiling für alle CPU's und die ganzen kranken, wie z.B. Cache profiling, call profiling, multithread profiling kann es für AMD CPU's
Das Intel und AMD sich da so pissig haben liegt daran, dass man dafür bestimmte Befehle und entsprechend Hardware Designs machen muss und da gibt es wohl kein Standard. Bis vor einiger Zeit hat das frame sample profiling auch so ziemlich aus gereicht aber mit mehrkern CPU's, immer teurer werdenden Cache misses, resource locks und so weiter wird das immer wichtiger.
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
ok das AMD Tool sieht ja fast so aus wie geDEbugger.. So und wie geh ich da jetzt am besten vor? Ich konnte eben noch eines nachvollziehen: Wenn ich im Fehlerfall (CPU > 100% und schlechte Framezeiten) im Taskmanager meinem Prozess nur einem bestimmten CPU Kern zuweise, geht die Auslastung schlagartig auf ~20% runter und ich hab wieder super zeiten..
Sooo jetzt kommt der Knaller!!! In den NVIDIA Systemsteuerungen gibt es eine Option die heißt "Threaded Optimierung".. diese steht default auf "Auto".. nun hab ich die mal auf "Aus" gestellt.. und siehe da.. das Problem ist weg.. Alles läuft super... Was ist diese scheiße?? Kann ich das vielleicht selbst irgendwie im Programm unterbinden?
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2622 Wohnort: Berlin
Programmiersprache: Go, C/C++
D3D war in alten Zeiten nicht Multi Threading fähig, dafür musste erst eine API her, während OpenGL es egal ist, von welchen Thread man aus den Context füllt, der ist Threadübergreifend aber das Befeuern von mehreren Threads aus ist sehr ungünstig, da die sich gegenseitig blockieren können. Zwar produziert das kein Dead-Lock aber das locking an sich kostet Zeit. Interessant wird das ganze, wenn man mehr als eine Grafikkarte hat. Ich hab z.B. eine GF580 und damit hab ich 2 GPU's in einer, damit ich beide nutzen kann, muss natürlich im hintergrund der Treiber die Arbeit aufteilen und damit müssen auch die Ressourcen intern thread safe gehandhabt werden, denn GPU1 muss auf 2 warten, wenn der folgenden Task das Ergebniss von beiden braucht. Damit wird der Treiber zusätzlich multithreading code an knipsen, um beide Karten zu befeuern. Hinter der Option ist nix anderes versteckt als genau dieser Code, wenn du also es deaktivierst wird es auf einer single GPU Karte schneller laufen, weil der multithreading code nicht gebraucht wird und deaktiviert wird. Dies sollte man nicht mit dem Code verwechseln, welcher für multithreading zwischen threads in einem Prozess zuständig ist. Wie gesagt, wäre es mit meiner GF580 schneller, wenn das Feature aktiviert ist und bei einer single Core Karte schneller, es zu deaktivieren.
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Nun, aber warum zerpflückt diese Funktion dann meinen Renderpfad wenn es nur nachteilig ist? Die NVIDIA Treiber sollten schon so intelligent sein um zu unterscheiden ob nun eine Single oder Mehr-Kern GPU verbaut ist...
Registriert: Do Sep 02, 2004 19:42 Beiträge: 4158
Programmiersprache: FreePascal, C++
Eventuell ein Bug im nvidia treiber? Mal versucht, ne ältere Version zu installieren?
grüße
_________________ 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
Eventuell ein Bug im nvidia treiber? Mal versucht, ne ältere Version zu installieren?
grüße
Ich bin leider schon seit ewigkeiten auf der Suche nach diesem Problem.. Doch erst vor kurzen wurde es erst richtig problematisch. Innerhalb dieser zeit gab es min. 3 Treiber updates, welche nix daran geändert haben.
Mitglieder in diesem Forum: 0 Mitglieder und 14 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.