Hallo,
Ich benütze die Sleepfunktion in OpenGL-Anwendungen, um die CPU zu schonen.
Aber, ist das eigentlich eine vernünftige Lösung, gibt es Alternativen?
Und, unter Windows bekomme ich eine maximale Framerate von ca 60, wenn ich die Anwendung bei unterschreiten einer gewissen Zyklusdauer schlafen lasse, die ohne zu schlafen ca 7000 Frames schafft.
Die Sleep- funktion in Windows nimmt millisekunden an, und somit müsste man doch eigentlich an die 1000 Frames hinbekommen, scheinbar ist die kürzeste Schlafdauer mit der Sleepfunktion auf meinem System aber deutlich über 10ms.
Geht es irgendwie genauer?

Grüße
Vinz

_________________
"Pixel, ich bin dein Vater."
-Darf Shader

Das hatten wir hier schon 999999999mal.

Die Sleepfunktion ist NICHT exakt. Glaube die soll nur auf 16ms genau sein oder so.

Für zeitliche Abstände kannst du die Funktion hier nutzen (bissl "scrollen"):
http://wiki.delphigl.com/index.php/Timebased_Movement

Hey,
die Zeitmessung krieg ich für meine Zwecke gut genug hin.
Mit der sleepfunktion will ich nicht die Zeit messen, sondern die CPU schonen, also für andere Prozesse zur Verfügung stellen (wobei ich nicht sicher bin, ob das so funktioniert).
Und hier wollten tatsächlich schon 999999999 Leute die Sleepfunktion als Timer benützen?

_________________
"Pixel, ich bin dein Vater."
-Darf Shader

Es ging darum wie oft Leute schon bemerkt und angefragt haben wieso sleep nicht genau ist.

Das mit dem Zeitmessen war auch nur als Anregung gedacht die du nutzen könntest um das Problem anders zu lösen. Nicht als komplettlösung.

Je nachdem womit du programmierst kann auch eine OnIdle-Funktion helfen die autom. aufgerufen wird wenn gerade nichts an Arbeit anfällt und somit bei andersweitiger Last eben keine 7000 Bilder pro Sekunde berechnet werden. Möglicherweise kann dir das auch ein wenig weiterhelfen.

Um so etwas vernünftig zu lösen benutzt man normalerweise Vsync.


Für was sollen 1000 Frames gut sein wenn dein Bildschirm sowieso nur 50-70 pro Sekunde anzeigen kann?

_________________
Traue keinem Computer, den du nicht aus dem Fenster werfen kannst -- Steve Wozniak

Bäääh VSync ist doch als unvorhersehbar bekannt, wenn ich mich nicht irre?

Sleep kannst du ruhig verwenden:

http://wiki.delphigl.com/index.php/Frameratenbegrenzung

Wenn du die Begrenzung auf 60 FPS einstellst (oder 30?) solltest du (auf nicht Krücken die maximal gerade so 61 FPS schaffen) damit keine Probleme haben, da dann die Sleepzeit > 10/20 ms sein sollte.

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Ja, da irrst du An VSync gibts nix unvorhersehbares. Einfach via wglSwapIntervalEXT aktivieren (unter Windows) und schon wird max. mit der Wiederholfrequenz des Bildschirms gerendert.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Da muss ich Sascha recht geben. Man merkt den Unterschied sofort, schaltest du jetzt VSnyc aus gehen die FPS auf weit über 1000 und 4-5 Sekunden nach Start deiner OpenGL-Anwendung fangen die Lüfter im PC ordentlich an aufzudrehen um die vollausgelastete CPU/GPU zu kühlen. Mit Vsync bleibt der PC schön leise.

_________________
Ich teile manchmal heimlich durch Null. - Alber Einstein

Mit der von mir empfohlenen Methode aber auch

Außerdem ist meine Plattformunabhängig und braucht kein WGL

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Das gibts für GLX (glXSwapIntervalEXT) auch (und damit Linux und MacOSX), und für andere Plattformen sicher auch.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

bleibt mir wohl nur noch das Argument, dass man mit meiner Methode die Framerate selbst aussuchen kann :/

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Was eine schlechte Idee ist. Denn damit legst du entweder als Programmierer die Framerate fest (ganz miese Idee) oder bietest dem Anwender die Möglichkeit eine schlechte Wahl zu treffen (miese Idee).
All meine OpenGL-Programme erlauben es Vsync zu aktivieren und benutzen dafür wglSwapIntervalEXT bzw. glXSwapIntervalEXT. Warum unbedingt etwas eigenes basteln wenn die optimale Lösung auf jeder modernen Plattform bereits vorhanden ist und nur darauf wartet aktiviert zu werden?

_________________
Traue keinem Computer, den du nicht aus dem Fenster werfen kannst -- Steve Wozniak

Auf einigen meiner Graka's (z.B. eine integrierte SiS und VIA) funktioniert VSync teilweise nicht. Dann flackert es extrem... kein Treiber half bisher (wenn es denn mal Treiberupdates gab...).

Außerdem, wieso sollte der Nutzer nicht sich aussuchen können, ob er auf 30,60,120 oder vollen FPS spielt?

EDIT:

Weiterhin legt man als Programmierer doch die Framerate fest, wenn man VSync benutzt!?

Wenn man sie festlegt, darf man nur trotzdem nicht vergessen Timebased-Movement zu nutzen.

Bsp. Ubisoft (oder die die für sie proggen) hat das bei Assassins Creed nicht gemacht => auf nicht mehr ganz so schnellen Rechnern desynchronisieren die Gespräche.

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Die Wahl der Framerate hat ja keinen Einfluss auf das Spielerlebnis, außer: je mehr desto besser, es sei denn, es wird so viel oder so ungünstig, dass fehlende v-sync probleme macht. Dann macht man VSync an, ansonsten macht man halt so viel wo geht.

VSync ist in jedem Fall eine gute Vorgabe, denn es erhöht die Bildqualität bei (ordentlichen) Grafikkarten um größenordnungen. (Reduzierte) Mobilchips sollten aber nicht als Referenz herangezogen werden. Für ernsthaftes OpenGL kann man die eh kaum verwenden.

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

Ich würde mich hüten über vsync den Prozess zu drosseln.

Wenn du sicher gehen willst, dass deine Prozess schonend und präzise arbeitet, dann benutzt sleep mit 0ms.
Das sorgt dafür, dass das System alle anderen Prozesse vorlauf gibt und dann wieder zurück springt.
Da Windows jeden Thread/Prozess eine gewisse CPU Time zu gesteht, ist diese deine Sleepdauer.
Das ganze packt man in eine do - while schleife und prüft ob die Zeit für den nächsten Frame gekommen ist.
Je nach Anwendungsdesign gibt es mehrere davon, da man Sound, Physik, Grafik, Logik und wer weiß was es noch so gibt mit unterschiedlichen Frequenzen laufen lassen will.
Wenn man so weit optimiert hat, dann hilft VSync nicht mehr.

Ich hab am Wochenende gelernt, dass man für Completion Port API SleepEx(0,true) nehmen sollte, damit die System-Messages verarbeitet werden.
Diese benutzte ich für eine File Watcher API von Windows. Hat also schon 2 Vorteile.

In der Vergangenheit hatte ich mal ein ähnliches Problem und hab das mit der do - while Konstruktion gelöst.
Das Sleep hat als Parameter (NextFrame-Now)/2 genommen.
Damit wurde es je näher es zum Ende kam immer öfter aufgerufen.
Ich weiß nicht ab wann genau die Sleep Genauigkeit mit 16ms(fester Interval mit 16ms -> 0-16ms ungenauigkeit) gelöst wurde aber die ist ab Win7 bei 100ns.Genauigkeit. Das Problem ist aber weniger das Sleep als der Context Switch, welcher nach dem Sleep passiert und der ist lahm.
Alternativ gibt es noch die Timer Queue API http://msdn.microsoft.com/en-us/library/windows/desktop/ms687003%28v=vs.85%29.aspx, welche mit 100ns Prezision läuft.

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

Projekte: https://github.com/tak2004