Runtime

Runtime is software that provides an application's execution environment or services while it runs. The meaning depends on the software system: the .NET Common Language Runtime, for example, executes managed code and provides services including memory management and exception handling. In virtual reality and augmented reality, an XR runtime provides the device-facing implementation through which applications obtain tracking and input information and submit images for display. OpenXR standardizes this application interface, while individual runtimes implement it for their supported systems.

An XR runtime can include device drivers, tracking, input processing and a compositor that presents application images. The runtime is distinct from the application's game engine and from the OpenXR loader, which connects API calls to an installed runtime. These distinctions matter when installing software, selecting a runtime, diagnosing compatibility or comparing XR rendering performance.

Reviewed 12 October 2026. XR runtime roles and software layers, OpenXR lifecycle, frame timing, spaces and actions, documented implementation limits, and the original time-warp and ILLIXR research cited below. About review dates.

Related software layers

A language runtime and an XR runtime solve different problems. The Common Language Runtime loads managed types and provides execution services such as garbage collection. An XR runtime handles the application's connection to XR devices and presentation. The term does not imply that every runtime contains a managed-language virtual machine or uses garbage collection.

Layer	Role in an XR application
Application and game engine	Implement the application's scene, game logic, physics and rendering. The ILLIXR research architecture separates these application tasks from the runtime's perception, visual and audio pipelines.
XR runtime	Implements the XR API and supplies device information and presentation services. A compositor receives rendered views and prepares them for the display; device drivers connect the runtime to hardware.
OpenXR loader and API layers	The loader discovers the active runtime and dispatches calls to it. Optional API layers can intercept calls for purposes such as validation and tracing.
Software development kit	Supplies development material such as headers and the OpenXR loader. Installing these components does not by itself install a device runtime.
Graphics API	Performs rendering into images supplied through the runtime's swapchains. The session's graphics binding connects OpenXR to the graphics API, such as Vulkan or Direct3D.
Operating system and graphics driver	Provide the underlying process, scheduling and graphics facilities. ILLIXR's implementation, for example, runs above the Linux kernel and GPU driver, with runtime work distributed among interacting pipelines.

The boundaries need not correspond to separate processes. Monado normally places its compositor and drivers in a service process. It can also be built with the runtime inside the application process, initialized when the application starts and shut down when it exits. A runtime is therefore not necessarily a continuously running background service.

OpenXR application interface

OpenXR exposes functions for obtaining controller state, locating devices at a requested time and submitting frames. The runtime maps these operations to the capabilities of its underlying system. An application still performs its own simulation and rendering; implementing OpenXR does not turn a runtime into a game engine.

Initialization and session lifecycle

An OpenXR application begins by enumerating the API layers and extensions it needs, creating an instance and selecting an XR system. An instance represents the application's OpenXR API context; a system identifies a collection of XR devices; a session establishes the application's interaction with that system and its graphics binding. Runtime properties returned for the instance include the runtime name and version.

Creating a session does not immediately make it active or grant it input focus. The application polls events and responds to session-state changes. Visibility, focus and permission to begin or end the session are distinct parts of this lifecycle.

Session state	Application significance
IDLE	The session is not running. This is its initial state and the state reached after a completed session ends.
READY	The application can call xrBeginSession.
SYNCHRONIZED	The running session participates in the frame loop, although its content is not visible to the user.
VISIBLE	The session's content is visible, but the session does not have XR input focus.
FOCUSED	The session is eligible to receive XR input.
STOPPING	The application should end its frame loop and call xrEndSession.
LOSS_PENDING	The application should destroy the lost session and can optionally initialize a replacement.
EXITING	The application should end its XR experience without automatically restarting it.

Session destruction and instance destruction release the corresponding OpenXR objects. Applications must account for runtime events as well as their own exit path.

Frame timing and image submission

The runtime coordinates image submission with anticipated display timing. A basic application loop obtains timing information, locates the views, renders into available swapchain images and submits composition layers. OpenXR also permits pipelines that distribute simulation and rendering across threads, so the API sequence should not be interpreted as requiring all work to execute on one thread.

Operation	Purpose
xrWaitFrame	Synchronizes and throttles the application's frame loop. It returns the predicted display time used to target simulation and rendering.
xrBeginFrame	Marks the beginning of the frame's rendering work in the OpenXR frame sequence.
xrLocateViews	Returns view poses and fields of view relative to a space at the requested display time. The application uses these to construct its views and projections.
Acquire, wait, render and release swapchain images	The application acquires an image index and waits for the image to become available before writing it. After rendering with its graphics API, it releases the image for runtime use.
xrEndFrame	Submits composition layers for the target display time. Layers use the relevant swapchains' most recently released images.

The returned XrFrameState also includes shouldRender. If it is false, the application should avoid expensive rendering and submit no layers, while continuing the running session's frame sequence. Its predicted display period is not necessarily identical to the hardware's display cycle. Application rendering rate and headset refresh rate therefore cannot be inferred to be equal from this field.

The application should use a consistent target time for the frame's simulation, pose queries and submitted layers. A layer's view pose must describe the pose used to render its image. A prediction can change as the requested display time approaches, even when repeated queries use the same timestamp; the latest pose can consequently differ from the pose used to render the image.

Spaces, tracking and actions

OpenXR describes poses relative to spaces. xrLocateSpace locates one space relative to another at a specified time, which can involve estimation of a past pose or prediction of a future pose. Its location flags distinguish a valid estimate from a pose that is actively tracked. During tracking loss, an inferred or last-known component can remain valid without being marked tracked.

OpenXR actions give application meaning to input and output, such as selecting an object, reading an analog value, obtaining an aiming pose or producing haptic feedback. Applications organize actions into action sets and suggest bindings for interaction profiles. This allows a semantic action to be associated with different physical controls. A pose action's state indicates whether it is active; its spatial pose is obtained by locating an associated action space.

xrSyncActions updates the state of active action sets. Queries remain consistent between synchronization calls. When the session lacks input focus, synchronization returns XR_SESSION_NOT_FOCUSED and actions are inactive. An application can therefore be displaying images while its input actions are unavailable.

Runtime selection and compatibility

In the usual loader-based arrangement, multiple runtimes can be installed, but the loader uses one active runtime. Selection is handled outside the loader; creation of the OpenXR instance establishes its runtime association. Discovery differs by platform: Windows uses an active-runtime registry entry pointing to a JSON manifest, Linux uses configuration-file discovery, and Android can use runtime-broker content providers. The manifest identifies the runtime library to load. The specification also accommodates applications that link directly to a runtime.

API compatibility is one part of application compatibility. An application must enumerate its required extensions, obtain a supported system and establish a suitable graphics binding. It must also query supported view configurations and swapchain formats instead of assuming a fixed configuration for every device.

Engine integrations add another layer. Unity's OpenXR plugin connects Unity applications to the OpenXR loader, but its documentation does not guarantee identical behavior or optimal operation on every conformant runtime. Additional capabilities can depend on runtime extensions and engine-side feature integrations. Microsoft's documented OpenXR implementation, for example, includes extensions for hand tracking, eye tracking, spatial anchors and scene understanding; those capabilities are not established for every runtime by the existence of the core OpenXR API.

For diagnosis, the runtime name and version are useful alongside the engine and plugin versions, enabled extensions and graphics API. Unity's OpenXR diagnostic report records these kinds of information. Reporting only the headset model or the presence of an OpenXR SDK can leave the actual runtime unidentified.

Timing and reprojection

An XR runtime's compositor can perform work after the application renders a view. The original research paper on asynchronous time warp describes transforming an already rendered image using a more recent head pose near display refresh. Running this operation separately from scene rendering allows the compositor to use the most recently completed image when a new application frame is late. When completed in time, this can reduce part of the delay between head motion and the displayed view, a component of motion-to-photon latency.

Reprojection has limits. A rotational warp does not correct positional movement or update moving objects in the scene. Depth-based translation can reveal background regions absent from the original image, and view-dependent lighting can become incorrect. The paper also identifies GPU scheduling and preemption as challenges for completing the warp on time. These findings explain implementation tradeoffs; they do not establish that every OpenXR runtime uses the same algorithm or achieves the same latency.

OpenXR specifies frame submission and the poses associated with composition layers. Those API obligations should be distinguished from a runtime's chosen reprojection implementation and its measured performance on particular hardware.

Documented implementations

The following examples illustrate different runtime roles and deployment arrangements. Their documentation establishes the stated capabilities and limits, rather than a complete compatibility list for all devices and applications.

Runtime or implementation	Documented role	Qualification
SteamVR	Provides runtime support for both OpenVR and OpenXR.	An application's OpenXR engine integration and feature requirements still affect compatibility.
Meta's PC OpenXR runtime	Meta documents native OpenXR support in its PC runtime and use of Khronos headers and the loader for development.	The developer headers and loader are separate from the runtime implementation.
Monado	An open-source runtime with device drivers, a compositor and an OpenXR API implementation.	It is not a drop-in replacement for arbitrary vendor SDKs; an application needs OpenXR support or an appropriate translation layer.
VDXR	Implements OpenXR 1.0 and 1.1 for Virtual Desktop on Windows, allowing OpenXR applications to run without SteamVR. UploadVR reported its addition to Virtual Desktop's stable release in November 2023.	The project's documentation explicitly says it is not formally conformant with Khronos.
Meta XR Simulator	A desktop OpenXR runtime that simulates device behavior for development and testing.	Meta describes API-level simulation, not a headset hardware emulator. Features depend on the selected device profile; the simulator does not run a device operating-system image or Android layer.
Microsoft's Windows Mixed Reality OpenXR implementation	Microsoft's development documentation describes support for HoloLens 2 and immersive Windows Mixed Reality devices.	Windows Mixed Reality was removed from Windows 11 version 24H2. Historical runtime documentation should therefore be read with its operating-system context.

Runtime research

ILLIXR is an original academic XR systems research platform. Its runtime coordinates perception, visual and audio pipelines through plugins and event streams. Perception supplies pose information, visual processing includes reprojection and optical correction, and audio processing supports spatial playback. The paper examines the dependencies and resource demands of these interacting components, rather than treating XR as only a scene-rendering workload.

The published system integrates with Monado to run OpenXR applications. Its evaluated configuration assumes local computation and a single user, and excludes offloading and multiuser operation. It is a research testbed with a defined feature set; its architecture and measurements cannot establish the behavior or performance of every commercial runtime.