Re-using old frames (when slow)

That's basically what asynchronous time warp is.

OK. So calling the OVR API at a higher frequency than the renderer can sustain will in no way help the asynchronous time warping undertaking?

To my understanding asynchronous time warp is not yet implemented on the PC because to make it work correct some driver extensions were needed (the thread that rendres at 75 fps needs to have priority over the other thread else it will miss vsync and then async timewarp will fall apart). It only works on gear vr atm. But now that nvidia has added priority context support it should be possible to implement it, i guess we just need to wait till oculus does this.

Timewarp.
http://rifty-business.blogspot.co.uk/2014/08/using-timewarp-on-oculus-rift.html

When your running early.
http://rifty-business.blogspot.co.uk/2014/08/advanced-uses-of-timewarp-i-when-youre.html

When your running late.
http://rifty-business.blogspot.co.uk/2014/08/advanced-uses-of-timewarp-ii-when-youre.html

Worth a read. In fact I'd say its worth a buy as well.

"opamp" wrote:

When your running late.
http://rifty-business.blogspot.co.uk/2014/08/advanced-uses-of-timewarp-ii-when-youre.html

Could you explain a bit more about the concept of dropping frames? If it generally takes a long time between measuring the pose and providing a rendered image, how does dropping a frame help? I especially don't understand how it can "buy you time to get back on top of your rendering load" if the next frame will take a lot of time again.

"B_old" wrote:

"opamp" wrote:

When your running late.
http://rifty-business.blogspot.co.uk/2014/08/advanced-uses-of-timewarp-ii-when-youre.html

Could you explain a bit more about the concept of dropping frames? If it generally takes a long time between measuring the pose and providing a rendered image, how does dropping a frame help? I especially don't understand how it can "buy you time to get back on top of your rendering load" if the next frame will take a lot of time again.

Because the frame you drop gets synthesized by timewarp using a transformation of the render surface based on the now pose, effectively this frame happens for free within microseconds. This transform will cause near camera geometry to appear to stutter and lag behind a little, more apparent the closer to the cam, most apparent on any geometry that exists in camera space (gaze reticule), but say you were viewing just a sky dome at infinity distance it would be as good as the real frame.

So if you know you've missed the 13ms deadline for frame N then there is no point calculating the frame N+1 that timewarp has already synthesised. Next frame you need to render is N+2.

But I think if you're running vsynch then that ( skipping N+1 ) would happen automatically. If running vsynch and you can never do a frame <=13.3ms then I would expect your main render thread to drop back to 26.6ms (37.5Hz) automatically.

"B_old" wrote:
...struggling to maintain (even close to) 75 fps, at least partly due to the data sets which we cannot further optimize...

I would explore methods to optimize further, there is often a way.

What are the "data sets"?

"g4c" wrote:

So if you know you've missed the 13ms deadline for frame N then there is no point calculating the frame N+1 that timewarp has already synthesised. Next frame you need to render is N+2.

But I think if you're running vsynch then that ( skipping N+1 ) would happen automatically. If running vsynch and you can never do a frame <=13.3ms then I would expect your main render thread to drop back to 26.6ms (37.5Hz) automatically.

Yeah, I think that is the problem. We can never do a frame <= 13.3 ms. Therefore the idea to update the oculus at 75Hz to give timewarp a chance to be applied at 75Hz.

Let's make a more extreme example. Suppose I can only generate 1 unique frame per second. Will I get 75Hz timewarp if only call SubmitFrame at 1Hz?

No, the display can only update if you call SubmitFrame. With async timewarp this could change, but that is not implemented by Oculus right now.

"B_old" wrote:
Our application is generally struggling to maintain (even close to) 75 fps, at least partly due to the data sets which we cannot further optimize.
An idea has been proposed to decouple our rendering from feeding the oculus in a different thread and just pretending to hit 75 fps while in reality re-using old frames until a new one is available.

When you mention due to the data sets which we cannot further optimize, are you suggesting that you are currently querying/processing data in the render thread?
If this is the case, you definitely want to put data querying/processing in a separate thread. Assuming your rendering pipeline (without data loading/processing) can maintain 75+hz, then your users will have a more comfortable experience.