It is currently Tue Feb 19, 2019 3:23 pm



Reply to topic  [ 21 posts ] 
 Main loop thread sleep problem 
Author Message
Petrif-Eyed

Joined: Mon Jun 22, 2009 8:36 am
Posts: 2160
Location: Stockholm, Sweden
Reply with quote
We have a little problem that we have been ignoring since day one of FreePIE, and that is the main thread sleep of 1 ms. Well we did talk about it a while back but that was about slowing the engine down to a user selected frequency.

The smallest amount of time that thread will sleep is 16 ms which will give you around 60 hz frequency. That is too low for a immerse VR experience.

What are our options?

Is the System.Timer set to 1 ms faster or is it using the Thread.Sleep as well?

_________________
FreePIE
My blog


Mon Oct 29, 2012 2:18 am
Profile
Two Eyed Hopeful

Joined: Fri Sep 21, 2012 4:46 am
Posts: 74
Reply with quote
It's not possible to make a thread wake up with more resolution than the current system clock resolution, typically 16 ms.

You can use timeBeginPeriod and timeEndPeriod API to set this resolution as low as 1 ms. As far as I know this affects everything, DateTime is more accurate, Thread.Sleep is more accurate, timers are more accurate.

However, this change is system wide so it's probably not something we want to touch.

Our only option to make the performance deterministic is a busy-wait (on Windows). Again, this is as far as I know.


Mon Oct 29, 2012 3:06 am
Profile
Petrif-Eyed

Joined: Mon Jun 22, 2009 8:36 am
Posts: 2160
Location: Stockholm, Sweden
Reply with quote
One solution is that its up to the Plugin to interrupt the Script engine, the problem is that most plugins do not have natural interrupts (Wait for UDP packets etc) etc. And the ones that have taht today are in a seperate thread for that reason.

edit: What about media timers or system timers?

_________________
FreePIE
My blog


Mon Oct 29, 2012 5:33 am
Profile
Petrif-Eyed
User avatar

Joined: Sat Sep 17, 2011 9:23 pm
Posts: 2218
Location: Menlo Park, CA
Reply with quote
I haven't used them, but aren't there special multimedia timers with a higher resolution. Also, 60 Hz is not really that bad.


Mon Oct 29, 2012 6:26 am
Profile
Two Eyed Hopeful

Joined: Fri Sep 21, 2012 4:46 am
Posts: 74
Reply with quote
I've used the multimedia timers in the Win API, they work with the same resolution as the system clock, set by timeBeginPeriod/timeEndPeriod. By the way, the default clock is 64 hz. :)


Mon Oct 29, 2012 9:53 am
Profile
Petrif-Eyed

Joined: Mon Jun 22, 2009 8:36 am
Posts: 2160
Location: Stockholm, Sweden
Reply with quote
Do we really wanna mess witrh that, with a game running in the foreground

_________________
FreePIE
My blog


Mon Oct 29, 2012 10:09 am
Profile
Two Eyed Hopeful

Joined: Fri Sep 21, 2012 4:46 am
Posts: 74
Reply with quote
I'd say no... It's a system-wide setting which I think is persisted between reboots. FreePIE has no business touching the system resolution. Every timer on the system is more responsive - can cause a lot more power consumption for example (think laptops).

I think we either need to accept the delay with sleep, or do something like a spin-wait. Unless anyone else has a better idea.


Mon Oct 29, 2012 3:47 pm
Profile
Petrif-Eyed
User avatar

Joined: Sat Sep 17, 2011 9:23 pm
Posts: 2218
Location: Menlo Park, CA
Reply with quote
I think for tracking and emulation purposes - 60Hz is plenty. The only reason I would encourage higher frequencies is for custom signal processing / fusion algorithms that accepted raw sensor input. But I also think this type of activity oversteps the purpose of FreePIE a bit. It's a better use of resources to perform signal processing natively rather than in an interpreter.


Mon Oct 29, 2012 4:12 pm
Profile
Petrif-Eyed

Joined: Mon Jun 22, 2009 8:36 am
Posts: 2160
Location: Stockholm, Sweden
Reply with quote
brantlew wrote:
I think for tracking and emulation purposes - 60Hz is plenty. The only reason I would encourage higher frequencies is for custom signal processing / fusion algorithms that accepted raw sensor input. But I also think this type of activity oversteps the purpose of FreePIE a bit. It's a better use of resources to perform signal processing natively rather than in an interpreter.



Yeah the android plugin for example gets 300 hz of data but the script engine can only poll it at 60..

_________________
FreePIE
My blog


Mon Oct 29, 2012 4:16 pm
Profile
Petrif-Eyed
User avatar

Joined: Sat Sep 17, 2011 9:23 pm
Posts: 2218
Location: Menlo Park, CA
Reply with quote
So it seems like sensor fusion would best be handled in the plugin code on a dedicated I/O polling thread. And then the script engine can just grab the latest calculated values at a slower frequency.


Mon Oct 29, 2012 4:24 pm
Profile
Petrif-Eyed

Joined: Mon Jun 22, 2009 8:36 am
Posts: 2160
Location: Stockholm, Sweden
Reply with quote
brantlew wrote:
So it seems like sensor fusion would best be handled in the plugin code on a dedicated I/O polling thread. And then the script engine can just grab the latest calculated values at a slower frequency.


Yeah thats how its done, question is if 60 is enough.. I haven't done enough testing my self. Carmack talked about 200hz or so?

edit: Also if you do not have a interupt in the poller thread like udp.Read etc then you need a Sleep in those too not to let that Thread own the Core

_________________
FreePIE
My blog


Mon Oct 29, 2012 4:31 pm
Profile
Petrif-Eyed
User avatar

Joined: Sat Sep 17, 2011 9:23 pm
Posts: 2218
Location: Menlo Park, CA
Reply with quote
CyberVillain wrote:
Carmack talked about 200hz or so?


Those high frequencies are great for signal processing but are not perceptible in-game. 60Hz looks fantastic on monitors, and I've heard talk that the difference between 60 and 120 is noticeable in an HMD but I don't think the Doom demo was even running that high and I don't think Oculus is targeting 120 either.


Mon Oct 29, 2012 4:38 pm
Profile
Sharp Eyed Eagle!
User avatar

Joined: Tue Aug 21, 2012 6:51 am
Posts: 401
Reply with quote
brantlew wrote:
60Hz looks fantastic on monitors, and I've heard talk that the difference between 60 and 120 is noticeable in an HMD but I don't think the Doom demo was even running that high and I don't think Oculus is targeting 120 either.
I think they would jump at the first chance they get to use a 120Hz display, but don't think it's likely they will get it. But my personal experience (especially with high speed games like Quake) I could really notice the difference between 60fps and 120fps in game.

And for TV's there was a genuine benefit to 100Hz CRTs in that they reduced flicker resulting in a more solid image and less eye strain. However, LCDs don't refresh like CRTs do and thus don't flicker so 50Hz isn't a problem on LCDs. It's clear that display manifacturers see the gaming crowd looking for 120fps gaming as a small minority.


Tue Oct 30, 2012 4:39 am
Profile
Petrif-Eyed

Joined: Mon Jun 22, 2009 8:36 am
Posts: 2160
Location: Stockholm, Sweden
Reply with quote
I most of the time play games with vsync off because I think the game feels too sluggish in 60-75 hz. With 150 > 200+ hz the game feels much nicer

_________________
FreePIE
My blog


Tue Oct 30, 2012 5:42 am
Profile
Certif-Eyed!

Joined: Tue Jan 19, 2010 6:38 pm
Posts: 529
Reply with quote
Don't know if it's any help, but what about HPET?

http://en.wikipedia.org/wiki/High_Precision_Event_Timer

Should be fitted to most modern machines. Might be more trouble than its worth though, I had to switch it off to get my floppy drive working, no idea what other problems might be.

_________________
"If you have a diabolical mind, the first thing that probably came to mind is that it will make an excellent trap: how do you get off a functional omni-directional treadmill?"


Wed Oct 31, 2012 4:19 am
Profile
Petrif-Eyed

Joined: Mon Jun 22, 2009 8:36 am
Posts: 2160
Location: Stockholm, Sweden
Reply with quote
bobv5 wrote:
Don't know if it's any help, but what about HPET?

http://en.wikipedia.org/wiki/High_Precision_Event_Timer

Should be fitted to most modern machines. Might be more trouble than its worth though, I had to switch it off to get my floppy drive working, no idea what other problems might be.


Thanks for the input, its the same timer that they are referring to above :D

_________________
FreePIE
My blog


Wed Oct 31, 2012 5:46 am
Profile
Two Eyed Hopeful

Joined: Fri Sep 21, 2012 4:46 am
Posts: 74
Reply with quote
I actually looked at using the HPET, available on many systems but often turned off. (Already here there is a problem)

The event rate of (atleast) 10 mhz is definitely more than enough. In Windows, the HPET is "available" through for example the QueryPerformanceCounter function. I say available in quotes since we really don't need to query the performance counter - we need to generate interrupts.

I googled for a while, but mostly found people wanting to use it for time measurements. Even then, the only info said to use QueryPerformanceCounter.

Even if we can find some generic way of accessing it (irregardless of motherboard / chipset I mean) we'd have to keep the current loop for systems without a HPET.

All in all it's an intriguing idea - it would allow us to fix the refresh rate across systems, and at a higher one than we currently have.


Thu Nov 01, 2012 5:34 am
Profile
Petrif-Eyed

Joined: Mon Jun 22, 2009 8:36 am
Posts: 2160
Location: Stockholm, Sweden
Reply with quote
CyberRascal wrote:
I actually looked at using the HPET, available on many systems but often turned off. (Already here there is a problem)

The event rate of (atleast) 10 mhz is definitely more than enough. In Windows, the HPET is "available" through for example the QueryPerformanceCounter function. I say available in quotes since we really don't need to query the performance counter - we need to generate interrupts.

I googled for a while, but mostly found people wanting to use it for time measurements. Even then, the only info said to use QueryPerformanceCounter.

Even if we can find some generic way of accessing it (irregardless of motherboard / chipset I mean) we'd have to keep the current loop for systems without a HPET.

All in all it's an intriguing idea - it would allow us to fix the refresh rate across systems, and at a higher one than we currently have.


Would it interfere with the games render clock etc? Keepin the game fast is prio #1

_________________
FreePIE
My blog


Thu Nov 01, 2012 6:31 am
Profile
Cross Eyed!
User avatar

Joined: Wed Feb 06, 2008 9:10 pm
Posts: 100
Reply with quote
If you've not run across it already... looks like this could be a good read on the subject:
(Timers, Timer Resolution, and Development of Efficient Code)
http://msdn.microsoft.com/en-us/library ... 63266.aspx

Also found this guy's personal 'trial and error'-based learning experience about timeBeginPeriod pretty entertaining:
(midway down under 'How did this application get created')
http://www.lucashale.com/timer-resolution/

....and some negative experiences with HPET:
http://forums.guru3d.com/showthread.php?t=332395#2

_________________
My Current VR Setup
- N-Vision Datavisor 80 HMD (1280x1024, 80 FOV at 100% Overlap)
- Ascension Technology Flock of Birds 6DOF Magnetic Tracking + Extended Range Transmitter
- Prototype HMD (~100 FOV) - Specs and design to be shared after patent issued.
- IZ3D for non stereo-ready apps
- GlovePie for TrackIR emulation for apps without native Ascension Tech FOB Support
http://www.thelostbrain.com/?tag=/head+mounted+display


Fri Nov 02, 2012 11:48 am
Profile WWW
Two Eyed Hopeful

Joined: Fri Sep 21, 2012 4:46 am
Posts: 74
Reply with quote
Thanks for your input TheLostBrain. Are you currently using FreePIE? Had any issues due to variable loop rates?

I also read that thread about HPET issues, but it's more of a system administrative issue - we could opt to use HPET if available, and default to sleeping with the default schedule interval (typically 64 hz). We could also choose to set the schedule interval to say 1 ms using the multimedia timer functions. I've actually made a tryout library (not incorporated into FreePIE) available at https://github.com/maxmalmgren/Aevum (Aevum means Time). Not very sophisticated.

We could achieve accurate timings up to 1000 hz by setting the scheduling/system tick interval. It will obviously mean that the whole system wakes up about 16 times more often.

Using HPET (if we can even access it generically in Windows) we'd not affect the entirety of the system I think, but there could be other issues associated with it.


Fri Nov 02, 2012 12:14 pm
Profile
Petrif-Eyed

Joined: Mon Jun 22, 2009 8:36 am
Posts: 2160
Location: Stockholm, Sweden
Reply with quote
Another solution could be to use Thread.Yield();

This will let the Thread continue to run but if another thread needs the resources our thread will yield. I tried this and the frequence is offcourse insane :D

The Core will always be at 100% though, I haven't had the time to test how this affects things in game (Where realtime yields are more frequent). Also I dont know if it has any other side effects. If more and more people demand higher frequencies than the current ~60hz then we could maybe add this as an option in FreePIE

_________________
FreePIE
My blog


Thu Mar 14, 2013 2:13 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 21 posts ] 

Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by STSoftware.