OpenXR Overview


The OpenXR™ working group – previously known as the Khronos VR Initiative - is creating an open and royalty-free standard for VR and AR applications and devices.

Solving VR/AR Fragmentation

Before OpenXRVR – Market Fragmentation

Before OpenXR fragmentation diagram

The Industry need for a Virtual Reality Standard

Without a cross-platform standard, VR and AR applications, games, engines, and devices must use each VR/AR platform’s proprietary APIs.

In turn, this means that each platform can only use the apps and devices that have been specifically ported. The result is high develop- ment costs, industry fragmentation, and confused customers – limiting market growth.

After OpenXR – Wide interoperability of VR apps and devices

After OpenXR fragmentation diagram

The cross-platform VR standard eliminates industry fragmentation by enabling applications to be written once to run on any VR system, and to access VR devices integrated into those VR systems to be used by applications.

OpenXR Architecture

Note that the design of the OpenXR specification is in progress, and so while the above diagrams represents the design goals of the group - final details may change

Note that the design of the OpenXR specification is in progress, and so while the above diagrams represents the design goals of the group - final details may change

OpenXR defines two levels of API interfaces that a VR platform’s runtime can use to access the OpenXR ecosystem.

Apps and engines use standardized interfaces to interrogate and drive devices. Devices can self-integrate to a standardized driver interface.

Standardized hardware/software interfaces reduce fragmentation while leaving implementation details open to encourage industry innovation.

For areas that are still under active development, OpenXR also supports extensions to allow for the ecosystem to grow itself to meet the evolution happening in the industry.  Just as with Khronos’s other standards, OpenXR supports KHR and EXT extensions to help unify concepts while allowing for growth and innovation.

Unshackling Innovation

OpenXR Input Haptics diagram

A great example of this is input.  Current XR applications are currently largely written to take advantage of a specific set of devices.  For example, an application may associate the trigger on a specific motion controller with the “teleport” action in the application.  Unfortunately, this means if a new type of controller or device is introduced, the application can’t support it.

The OpenXR standard flips this association to make it more future-proof.  Instead of the application associating buttons and actions within itself statically, the application tells the runtime the list of actions it can perform (e.g. “teleport,” “select,” “jump”), as well as what information it needs to perform it (e.g. “button press,” “vector”).  Then, the runtime does the association based on what devices it currently has available. You can associate any action with any device that can provide that type of input. That means as new devices hook into runtimes through the Device Extension, they’re able to directly interface with any compliant application.  This means applications have longer lifetimes across hardware generations, and new hardware can immediately take advantage of a wide variety of existing applications.

OpenXR Viewport Configurations

Another example of this versatility is with OpenXR’s concept of Viewport Configurations.  As you can see in the diagram, OpenXR supports a wide variety of devices, from a “magic window” style handheld AR applications, to head mounted displays, to CAVE-like environments.  While all of these have vastly different requirements, Viewport Configurations help the runtime express what the underlying hardware supports, and what it needs for the application to provide.  For each surface that needs an image generated (one in the case of handheld AR, two in the case of most HMDs, or up to six in the case of CAVE-like environments), the OpenXR runtime provides the application with a description of what needs to be rendered.  Applications can choose to support as many or as few as they want, but the choice is always consistent, and always available to the application through the same API. This means that supporting multiple classes of devices has never been easier!

Camera Passthrough AR Stereoscopic VR / AR Projection CAVE-like
Hand holding smart phone Two headsets Player in room playing a VR game
One Viewport
Two Viewports (one per eye)
Twelve Viewports (six per eye)

Who else is Involved in this initiative?

Here are just some of the companies helping to get this initiative under way. Many more companies are already getting involved. Your company can be one of them!

VR contributing Members


“With VR on the verge of rapid growth across all of the major platform families, this new Khronos open standards initiative is very timely. We at Epic Games will wholeheartedly contribute to the effort, and we'll adopt and support the resulting API in Unreal Engine,” said Tim Sweeney, founder & CEO, Epic Games.

“Open standards which allow developers to more easily create compelling, cross platform experiences will help bring the magic of VR to everyone. We look forward to working with our industry colleagues on this initiative,” said Mike Jazayeri, director product management, Google VR.

“Khronos’ open APIs have been immensely valuable to the industry, balancing the forces of differentiation and innovation against gratuitous vendor incompatibility. As virtual reality matures and the essential capabilities become clear in practice, a cooperatively developed open standard API is a natural and important milestone. Oculus is happy to contribute to this effort,” said John Carmack, CTO, Oculus VR.

“Virtual reality’s success is dependent on a large thriving market of hardware where casual and professional consumers alike can take their pick without worry of fragmentation and incompatibility,” said Christopher Mitchell, OSVR business lead, Razer. “This has been OSVR’s vision from day one and we are thrilled to be a part of the Khronos Group in order to push standardization of interfaces across the industry.”

Future virtual reality platforms that are truly mobile - unencumbered by cables, with full 6 degrees of freedom motion tracking, will deliver the most immersive experiences for consumers” says Avinash Seetharamaiah, VP Graphics and Camera software. “Our team at Qualcomm Technologies is excited to be working with our partners and Khronos to define efficient new APIs for unparalleled mobile VR user experiences.

“The number of VR systems on the market is growing rapidly. Most of these require separate API support from the developer, which is causing huge fragmentation for consumers,” said Gabe Newell of Valve. “Khronos’ work on a standard API to enable applications to target a wide variety of VR devices is an important step to counter that trend.”

How do I get Involved!

Details about joining Khronos.
Khronos members can participate in any Khronos working group.

Contact us with questions