Main loop thread sleep problem

[CyberVillain]

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?

[CyberRascal]

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.

[CyberVillain]

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?

[brantlew]

I haven't used them, but aren't there special multimedia timers with a higher resolution. Also, 60 Hz is not really that bad.

[CyberRascal]

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.

[CyberVillain]

Do we really wanna mess witrh that, with a game running in the foreground

[CyberRascal]

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.

[brantlew]

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.

[CyberVillain]

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

[brantlew]

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.

[CyberVillain]

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

[brantlew]

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.

[mahler]

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.

[CyberVillain]

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

[bobv5]

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.

[CyberVillain]

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

[CyberRascal]

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.

[CyberVillain]

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

[TheLostBrain]

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

[CyberRascal]

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.

[CyberVillain]

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

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