Runtime priority on GPU?

Hi, we are developing a game engine for VR that uses OpenXR. I would like to understand all the timing so that we can make good desicions.
One think I still wondering about: After the rendering we present the result to OpenXR. Open XR needs to do some stuff on the GPU like lens correction. But our game engine will already be busy with the next frame because we do some overlapping. Does OpenXR get highest priority on the GPU so that this can work correctly? Do we have to handle priorities ourself somehow?

Typically the VR compositors will indeed run with higher GPU priority. For example Vulkan based compositors can use VK_EXT_global_priority for this.

The driver implementation will attempt to skew hardware resource allocation in favour of the higher-priority task. Therefore, higher-priority work may retain similar latency and throughput characteristics even if the system is congested with lower priority work.

This is something the VR runtimes will handle internally, no need for the application to care about it. Only it’s a good idea to avoid trying to run VR applications with higher GPU priority too.

Thx for the quick answer. This high prio OpenXR task needs to be done as quick as possible, thus indeed high priority. Does this mean the GPU has to switch all cores to this OpenXR task and back when done? Does this give additional overhead on modern GPUs? Would it be wise to try to not to load the GPU when OpenXR needs it? Or will you not notice the overhead of switching?

How it really works will depend. For example a VR compositor might preempt the GPU work of an OpenXR application to squeeze the processing of its own frame - and there you really get into implementation details of the OpenXR runtime, the implementation of the graphics driver, and the capabilities of the actual GPU hardware. In short: Application developers shouldn’t worry too much about it.

But if you do notice cases where an application that does nothing considered out of the ordinary but still causes the VR compositor to misbehave, you should report it to the runtime developers (and if it were to turn out to be a fundamental problem at the OpenXR-Docs github repository) for further discussion.

Yeah, none of this is specified in the OpenXR spec, so a runtime may do anything it wishes here. The runtime will make sure a frame (reprojected/warped if required) makes it to the headset at almost all costs. You’ll do well by making sure that you’re keeping the GPU fed and it’s not having bubbles. I find this presentation a continuously good reference:

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.