New To The Forum? Click Here To Read The How To Guide. -- Developers Click Here.

Queue-ahead on GearVR

j-lcj-lc Posts: 3
NerveGear
Hi,
I'm developing a GearVR application using Unreal Engine 4.17.1, and I'd like to know the default state of the queue-ahead behaviour between CPU and GPU.
I tried to use the console command vr.oculus.EnableQueueAhead, described in UE4-Oculus.txt as "Enable full-frame queue ahead for rendering on GearVR" but it doesn't seem to do anything. Looking at the source code for the Oculus plugin, it seems that the implementation for this command is missing from OculusHMD_ConsoleCommands.cpp.

Has anybody had any luck with using queue ahead on GearVR?

Thanks,
Julien
Tagged:

Comments

  • imperativityimperativity Posts: 1,625 Oculus Staff
    edited September 11
    Hi,

    I am currently looking into whether or not this is supported yet and will advise you on what I discover.

    Thanks for your patience.

    EDIT: I can confirm that this has been removed from our UE4 integration at this time. This will now be internally managed on both Rift and mobile from now on.
  • j-lcj-lc Posts: 3
    NerveGear
    Hi,
    Thanks a lot for the clarification.
    Can we assume that queue-ahead is disabled by default as of the current version of the Unreal Engine integration, and that a call to Present always throttles the CPU until the GPU is done with the current frame?
    Understanding what is going on under the hood is necessary for us in order to make sense of timing measurements and identify the bottleneck in our application.
  • imperativityimperativity Posts: 1,625 Oculus Staff
    @j-lc

    Can we assume that queue-ahead is disabled by default
    No. It is enabled by default and cannot be disabled in UE4.

    a call to Present always throttles the CPU until the GPU is done with the current frame
    Present returns when our runtime determines it is the right time for UE4 to start the next frame. Typically, that is when the GPU work is done--16ms on Gear VR.

    Understanding what is going on under the hood is necessary for us in order to make sense of timing measurements and identify the bottleneck in our application.
    To help answer this question, it would be great if you could provide more insight into what you are trying to measure here. Unfortunately, GPU drivers do not provide a lot in the way of timing information.



  • j-lcj-lc Posts: 3
    NerveGear
    Ideally, I wanted to determine the maximum time budget for the render thread every frame, and understand what kind of CPU/GPU synchronization is in place on GearVR. I'm used to PC/console APIs where developers get to specify the number of frames that the CPU can queue in advance, if they decide to trade latency for performance.

    There is a very nice writup on the developer blog about what queue-ahead implies for VR, but it does not deal with GearVR explicitely : https://developer.oculus.com/blog/optimizing-vr-graphics-with-late-latching/

    So I'm not sure what the situation is:
    - if queue-ahead is enabled by default on GearVR, then the CPU render thread can use a full 16ms frame to generate graphics command lists, to be consumed by the GPU during the next 16ms slice
    - if queue-ahead is disabled and there is a sync point at the end of every frame, then the CPU render thread should use maybe half the frame, considering that the GPU still has to finish processing these commands with a small delay, and finish in time in order not to be pre-empted by the asynchronous time warp, all that in 16ms.




Sign In or Register to comment.