Forum Discussion

🚨 This forum is archived and read-only. To submit a forum post, please visit our new Developer Forum. 🚨

10 Replies

  • Async timewarp is still being worked on. I don't believe it is available yet, so stay tuned.
  • 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.
  • owenwp's avatar
    owenwp
    Expert Protege
    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).
  • 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.
  • ralfal's avatar
    ralfal
    Honored Guest
    @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.
  • "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)?
  • 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.
  • 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 :\
  • 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? :|