Skip to main content
Anonymous
September 8, 2017

Queue-ahead on GearVR

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
This topic has been closed for replies.

2 replies

Anonymous
September 12, 2017
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.
Anonymous
September 18, 2017
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.




Terms & ConditionsAccessibility statement