Skip to main content

10 replies

Inspiring
October 28, 2015
Async timewarp is still being worked on. I don't believe it is available yet, so stay tuned.
AMD Ryzen 7 1800X | MSI X370 Titanium | G.Skill 16GB DDR4 3200 | EVGA SuperNOVA 1000 | Corsair Hydro H110i Gigabyte RX Vega 64 x2 | Samsung 960 Evo M.2 500GB | Seagate FireCuda SSHD 2TB | Phanteks ENTHOO EVOLV
Up and Coming
October 29, 2015
Doesn't flyinside use asynch Tw? Maybe since it was funded on kickstarter and will actually be a product it got early access to the source code but it definitely uses it (its awesome btw and will help a TON with making games with no judder and constant 75 fps. A+ job.)

*edit and I just noticed the new vorpx does as well.
DK2- Works and Developing DK1 no longer works :(
Up and Coming
October 29, 2015
The kind of async timewarp you see in existing games relies on the GPU being completely idle during VSYNC. In other words, the GPU must be able to render frames at more than 75fps, even if the CPU cannot keep up. This is good for older simulators and emulators where the CPU is doing almost all the work, and the GPU burns through the simple geometry and shaders really fast then just waits, but if your GPU is the bottleneck then it just won't work without the new nVidia/AMD GPU preemption features of their VR SDKs (or Directx12/Vulkan, which are not supported yet).
Inspiring
October 30, 2015
To some extend a good emulations of Async-Timewarp can be archived with multiple Threads, one for rendering and one to push the pictures to the Runtime. But it can not guarantee a Timewarped frame if not done with lowlevel GPU-preemption.
Up and Coming
October 30, 2015
@owenwp: At least for vorpX that is not true. It actually disables vsync normally, even if forced. But you are still right that it will be better done in a runtime with better access to effective preemption and high proirity contexts. I for one will happily throw away two months of work the second Oculus implements async timewarp in the runtime, provided they do.
www.vorpx.com
Inspiring
October 31, 2015
"ralfal" wrote:
@owenwp: At least for vorpX that is not true. It actually disables vsync normally, even if forced. But you are still right that it will be better done in a runtime with better access to effective preemption and high proirity contexts. I for one will happily throw away two months of work the second Oculus implements async timewarp in the runtime, provided they do.


How can you do it, since V-Sync is forced by the newer Oculus-Rift Runtimes (what is by the way big PITA for Developers debuging - like taking away extended-Mode was! Oculus VR - Stop being such a "we know it best" Developer-Nanny)?
New Participant
November 9, 2015
0.8.0.0-beta
I've managed to get asynchronous timewarp working quite nicely in OpenGL (a second thread and wglsharelists context calling submitframe, using fences), but so far it's just rotational. Even though I'm using ovrLayerEyeFovDepth and providing the depth texture set I'm not seeing positional interpolation. Is there some extra thing I have to do? Comparing my code to "OculusWorldDemo.cpp" it doesn't look much different, fundamentally.
Inspiring
December 15, 2015
me too :)

afaik: sdk states depth is not even evaluated for layering currenty, so i would stop transferring them to the runtime and the other thread right now :\
Up and Coming
February 4, 2016
Likewise - with OpenGL and 0.8.0.0 I'm seeing no positional timewarp with an ovrLayerEyeFovDepth layer, depth buffer passed in. ovr_SubmitFrame returns ovr_Success.

Has this been confirmed to be broken for GL? Or does the depth buffer have to be in a specific format?

EDIT: Also, within the SDK header ovrLayerEyeFovDepth definition, it states the depthTexture must map 1:1 in size to the colour texture:

/// Depth texture for positional timewarp.
/// Must map 1:1 to the ColorTexture.
ovrSwapTextureSet* DepthTexture[ovrEye_Count];

But the SDK User Guide states (P21 V0.8.0.0)

"DepthTexture" "... It does not have to match the ColorTexture resolution, ..."

Which is it? :|
Inspiring
February 10, 2016
Depth is not evaluated by the current SDK at all!