Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: So Dez 22, 2024 09:47

Foren-Übersicht » Programmierung » OpenGL
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 16 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Autor Nachricht
 Betreff des Beitrags: Komsiches verhalten > CPU Auslastung
BeitragVerfasst: Mi Jan 30, 2013 08:48 
Offline
DGL Member

Registriert: Do Apr 22, 2010 17:17
Beiträge: 543
Moinsen,

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%..

Grüße,
Thomas


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jan 30, 2013 09:15 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Nov 08, 2010 18:41
Beiträge: 769
Programmiersprache: Gestern
Welche Libs benutzt du denn?

_________________
Meine Homepage


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jan 30, 2013 11:12 
Offline
DGL Member
Benutzeravatar

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 networkmy 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


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jan 30, 2013 11:24 
Offline
DGL Member

Registriert: Do Apr 22, 2010 17:17
Beiträge: 543
OS: ist Windows 7 64bit
Graka: GTX580
IDE: Delphi XE3

Was meinst ihr für Libs? Der GPU Speicher liegt max bei ca 40%. Die GPU selbst hat bei dem 100%CPU fall auch nicht viel zu tun (10-20%).


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jan 30, 2013 12:17 
Offline
DGL Member
Benutzeravatar

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.

_________________
Meine Homepage


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jan 30, 2013 13:39 
Offline
DGL Member
Benutzeravatar

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jan 30, 2013 14:47 
Offline
DGL Member

Registriert: Do Apr 22, 2010 17:17
Beiträge: 543
mhh gibts so ein tool auch für Intel? Hab ne i7 CPU.


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jan 30, 2013 14:59 
Offline
DGL Member
Benutzeravatar

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jan 30, 2013 15:45 
Offline
DGL Member

Registriert: Do Apr 22, 2010 17:17
Beiträge: 543
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..


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jan 30, 2013 16:35 
Offline
DGL Member

Registriert: Do Apr 22, 2010 17:17
Beiträge: 543
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?


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jan 30, 2013 17:33 
Offline
DGL Member
Benutzeravatar

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jan 30, 2013 18:02 
Offline
DGL Member

Registriert: Do Apr 22, 2010 17:17
Beiträge: 543
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... :roll:

ADD: eine GTX580 ist Singlecore...


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jan 30, 2013 18:40 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2622
Wohnort: Berlin
Programmiersprache: Go, C/C++
Darauf hab ich keine Antwort.
Eine Möglichkeit wäre, dass da noch mehr drin steckt als nur das worüber ich geredet habe.

Ja mein Fehler ist eine gf590 http://www.nvidia.de/object/product-geforce-gtx-590-de.html also genau die da.
Ein kleines lautes Biest aber leiser als die Quadro Karte vorher.

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

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mi Jan 30, 2013 20:06 
Offline
DGL Member
Benutzeravatar

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 networkmy 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


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Do Jan 31, 2013 09:05 
Offline
DGL Member

Registriert: Do Apr 22, 2010 17:17
Beiträge: 543
Lord Horazont hat geschrieben:
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.


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 16 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Foren-Übersicht » Programmierung » OpenGL


Wer ist online?

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.

Suche nach:
Gehe zu:  
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.018s | 17 Queries | GZIP : On ]