Context priority

Context priority gives HMD developers the control over GPU scheduling to support important VR features such as asynchronous timewarp. It is a driver feature that lets headset software create a high-priority graphics context: when work is submitted to that context, the GPU preempts whatever else it is rendering, runs the high-priority work, and then returns to the interrupted task.

Context priority is supported by GameWorks VR by Nvidia. It is also part of NVIDIA's VRWorks SDK, whose current developer page describes it as part of Direct Mode for headset manufacturers. The main use is to let a VR compositor re-warp the previous frame for the latest head pose when an application misses a frame, so that head tracking keeps working during short hitches. Other graphics APIs expose comparable controls, including the EGL_IMG_context_priority extension used on mobile GPUs, Vulkan global queue priority and Direct3D 12 command queue priority.

Reviewed 27 September 2026. Every new claim was checked against its cited source, including NVIDIA's Context Priority, VRWorks and GTX 1080 documents, Reed's SIGGRAPH 2015 speaker notes, the Oculus ATW blog and the EGL, Vulkan and Direct3D 12 specifications. About review dates.

Background

In a talk at SIGGRAPH 2015, NVIDIA graphics programmer Nathan Reed explained why VR needed a change in how the GPU shares time between applications. Although the GPU processes vertices and pixels in parallel, its front end, which accepts buffers of rendering commands from applications, is still mostly serial and consumes those commands in order. On Windows, the driver batches each application's API calls into packets of hardware commands, and the Windows GPU scheduler orders the packets from all applications and queues them for the GPU.

Before Windows 10, a command packet could not be interrupted once it had been submitted to the GPU, so a heavy application could starve lighter ones. Windows solved this for the desktop compositor with a second, "low-latency" WDDM node that maps to the same GPU. The GPU time-slices between the two nodes at 1 ms intervals by default, but at the time it could only switch at draw call boundaries, so the effective interval was 1 ms rounded up by the length of the last draw call.

Reed argued that VR applications need the same protection the desktop compositor gets, because they must render reliably at 90 Hz or the headset's native frame rate. A rendering hitch in a headset leaves a frame "stuck to your face", which causes disorientation and, if hitches are frequent or long, physical discomfort. He also noted that Oculus and Valve both use a VR compositor process: applications submit frames to the compositor, which owns the display, much as windowed applications submit frames to the desktop compositor.

How it works

NVIDIA's implementation exposes a DirectX 11 extension that lets an application opt in to the low-latency node by creating a special low-latency DirectX context. Headset vendors with a VR compositor can then give it the same scheduling priority as the Windows desktop compositor. In a guest article for Road to VR, Reed described the result as a special high-priority D3D11 device: "When work is submitted to this device, it preempts whatever else is running on the GPU, switches to the high-priority context, then goes back to what it was originally doing afterward."

In NVIDIA's model, the application's main rendering runs in a normal context and the timewarp rendering runs in the high-priority context. If a frame takes too long and no new frame is delivered at vertical sync, the timewarp work preempts the GPU and re-warps the previous frame. NVIDIA describes the feature as a way for developers to interrupt the GPU's current rendering task and re-task it to perform the timewarp, which adjusts the image to the most recent head tracking data without re-rendering a new frame. UploadVR summarized it as "a low-level feature that NVIDIA provides developers to enable VR platform vendors to implement asynchronous timewarp".

NVIDIA lists the following support for Context Priority:

Item	Support stated by NVIDIA
GPU architectures	Maxwell (specific SKUs) and Pascal
Example products	GeForce GTX 900 series and Quadro M5000 and higher
Graphics APIs	DX11, DX12, OpenGL (through interop)

In the SIGGRAPH 2015 talk, Reed said NVIDIA planned to extend the API to use the GPU scheduling and preemption improvements in Windows 10.

Preemption granularity

How quickly a high-priority context can take over depends on how finely the GPU can be interrupted. NVIDIA's VRWorks technical presentation states that then-current GPUs used draw-level preemption and "can only switch at draw call boundaries", so a long draw call can delay the context switch. Its developer guidance was to keep rendering at the native frame rate (90 Hz) and treat asynchronous timewarp as a safety net, and to split up draws that take more than about 1 ms, for example by dividing heavy postprocessing into screen-space tiles.

NVIDIA states that Maxwell GPUs can be interrupted as soon as a draw call finishes, while Pascal added pixel-level preemption, so the GPU can be interrupted with finer granularity and developers can run the timewarp closer to display scanout. The GeForce GTX 1080 whitepaper describes Pascal as the first GPU architecture to implement pixel level preemption: when a request arrives, the rasterizer, triangle shading and command pushbuffer processor stop and save their position, pixels already rasterized finish shading, and the switch to the new workload can complete in less than 100 microseconds after that pixel shading work is finished. Pascal also supports thread-level preemption for compute workloads.

The whitepaper uses asynchronous timewarp as its example. Without fine-grained preemption, the timewarp work has to be handed to the GPU several milliseconds before the display refresh because the time needed to preempt varies. With pixel-level graphics and thread-level compute preemption, preemption is faster and more deterministic, so the timewarp work can be submitted later and still finish before the refresh deadline.

History

Reed's Road to VR guest article of 29 June 2015 introduced context priorities alongside VR SLI and multi-resolution shading as parts of GameWorks VR. He presented the SDK, including "context priorities and direct mode", at SIGGRAPH on 17 August 2015. UploadVR reported in August 2015 that the GameWorks VR SDK had moved from alpha to beta.

On 19 November 2015 NVIDIA announced version 1.0 of its GameWorks VR and DesignWorks VR SDKs. The announcement listed Context Priority with Direct Mode, Multi-res shading, VR SLI and front buffer rendering, and said it "provides control over GPU scheduling to support advanced VR features such as asynchronous time warp". At the Game Developers Conference in March 2016, NVIDIA promoted its VR SDK as VRWorks and listed HTC and Oculus among the headset makers using it.

Oculus shipped asynchronous timewarp on Windows in its PC SDK 1.3. In a March 2016 developer blog post, Dean Beeler and Anuj Gosalia wrote that ATW "relies on CPU and GPU preemption", that "Modern PC GPU hardware and software are optimized for very high throughput, but not for preemption", and that Oculus worked with Microsoft, NVIDIA and AMD "to change OS GPU scheduling, GPU command processor microcode, and GPU kernel driver design to enable ATW". They named AMD's LiquidVR and NVIDIA's VRWorks as driver extensions developed to support it.

NVIDIA's current VRWorks page no longer lists Context Priority as a separate item. It groups the headset features under Direct Mode, which it says "reduces latency and utilizes Context Priority for fine-grained control over GPU scheduling", and offers those features to manufacturers through its VRWorks HMD developer program.

Comparable mechanisms in other APIs

The idea of a prioritized graphics context predates GameWorks VR. The EGL_IMG_context_priority extension from Imagination Technologies (version 1.1 dated 8 September 2009) lets an EGL context be created with a priority hint of high, medium or low. The implementation may not honor the hint, for example when system policy limits high-priority contexts to privileged processes, so the extension includes a query for the priority actually assigned.

J.M.P. van Waveren's asynchronous timewarp test utility (copyright Oculus VR), published in the Khronos Group's Vulkan samples repository, states that on hardware that cannot run multiple graphics or compute tasks concurrently, keeping the timewarp synchronized with the display refresh requires "Context priorities" and "Fine-grained and low latency priority based task switching". Its OpenGL ES path sets the context priority through EGL_IMG_context_priority, and its to-do list includes implementing WGL, GLX and NSOpenGL equivalents of that extension. In a 2017 Khronos presentation, Oculus's Cass Everitt described the samples as modelling an application and a compositor in one program, with the compositor on a separate thread "with higher graphics priority, if possible".

API	Mechanism	Priority levels	Notes
EGL (OpenGL ES)	EGL_IMG_context_priority	High, medium, low	A hint the implementation may ignore; the assigned level can be queried
Vulkan	VK_EXT_global_priority (promoted to VK_KHR_global_priority and then to Vulkan 1.4)	Low, medium (default), high, realtime	System-wide queue priority; levels above the default may need elevated privileges
Direct3D 12	D3D12_COMMAND_QUEUE_PRIORITY	Normal, high, global realtime	Global realtime needs sufficient privilege and fails rather than silently downgrading
DirectX 11 (NVIDIA driver)	Context Priority (GameWorks VR / VRWorks)	Normal and high-priority contexts	Vendor extension for headset compositors

The Vulkan extension, last modified on 6 October 2017, lists Andres Rodriguez, Pierre-Loup Griffais and Dan Ginsburg of Valve and Mitch Singer of AMD as contributors. Its specification says it lets the driver give preference to higher-priority work, so that such work "may retain similar latency and throughput characteristics even if the system is congested with lower priority work". Microsoft's Direct3D 12 documentation says that a request for a global realtime queue fails if the application lacks privilege or if the adapter or driver cannot provide the necessary preemption, which tells the application whether the queue is guaranteed to execute before any other queue.

See also

• Asynchronous Spacewarp
• Reprojection
• Motion-to-photon latency
• Direct Mode
• VRWorks
• LiquidVR