DOCSEARCHbyAlgolia
Submit Docs

OpenXR SDK

repository·main·Indexed 22 days ago

https://github.com/khronosgroup/openxr-sdk

The OpenXR SDK provides OpenXR headers and the source code and build scripts for the OpenXR loader. It includes instructions for building the loader as a static or dynamic library across Windows, Linux, and macOS, as well as documentation for integrated external dependencies such as JNIPP, JsonCpp, and sanitizers-cmake.

Tokens
12K
Snippets
40
Records
112
Agent score
75%

What's inside openxr-sdk

  1. Understand OpenXR project licensing and compliance

    main

    The OpenXR GitHub projects follow the REUSE 3.0 specification for license compliance. License and copyright information is primarily stored within each file or in an adjacent .license file. For a complete software bill of materials (BOM) in SPDX format, you can use the reuse command line tool, though note that it may exclude generated files. If you require a BOM that includes all generated files, use the OpenXR-SDK repository where these files are pre-generated.

    Key Licensing Summary:

    • OpenXR Specification & Documentation: Licensed under CC-BY-4.0 (Creative Commons Attribution 4.0 International).
    • Tooling & Build Files: Header files, scripts, programs, and XML files used in the build process are generally licensed under Apache-2.0.
    • Core API & Loader (Dual Licensed): To support developers in GPLed projects, the main OpenXR headers, XML registry, and loader source are dual-licensed under Apache-2.0 OR MIT.

  3. Validation Layer improvements in SDK 1.1.47

    main

    The core_validation layer in SDK 1.1.47 received several updates to improve usability and reduce false positives:

    • Chain Validation: Changed from recursive to iterative to allow subsequent structs to validate against the initial set of valid chained structs.
    • Inheritance: Fixed checks for structs that inherit from a base struct; inherited structs now correctly share the same list of valid chained structs as their parent.
    • Error Handling: Fixed null dereference bugs in generated code and added an exception to xrGetRecommendedLayerResolutionMETA to allow XR_NULL_HANDLE to be valid when checking the XrSwapchainSubImage struct.
    • Logging: Added timestamps to log messages and debug messages for when the core_validation layer starts or exits.

  4. Handle single XrInstance limitation in OpenXR 1.0.6

    main

    Starting with OpenXR SDK 1.0.6, the loader has been refactored to support only a single active XrInstance per process. This change improves forward compatibility with newer extensions.

    If your application attempts to create a new instance while an existing one is still active (for example, due to a leaked XrInstance handle), the loader will return the error code XR_ERROR_LIMIT_REACHED.

  5. Re-enable extension function prototypes in OpenXR SDK 1.0.15

    main

    Starting with OpenXR SDK 1.0.15, the OpenXR headers no longer expose extension function prototypes by default. This change was made because extension functions are not exported by the loader, and providing prototypes can lead to confusion and linker errors.

    While the function pointer definitions remain available (which is the correct way to access extensions), if your existing codebase relies on the explicit function prototypes, you can re-enable them by defining the XR_EXTENSION_PROTOTYPES preprocessor macro.

    // Example: Re-enabling extension prototypes via preprocessor define
#define XR_EXTENSION_PROTOTYPES
#include <openxr/openxr.h>

  6. Architecture-specific active runtime manifests

    main
    The OpenXR loader supports using architecture-specific active runtime manifests on Linux, macOS, and Android. This allows for more granular control over which runtime is active based on the specific CPU architecture of the device.

  7. Note on XR_KHR_opengl_enable Wayland support

    main
    In OpenXR SDK 1.1.54, the Wayland part of the XR_KHR_opengl_enable extension has been deprecated and its version has been bumped. Developers should plan to migrate away from Wayland-specific OpenGL enablement via this extension.

  9. Use standard OpenXR style for XrStructureType initialization

    main
    In OpenXR SDK 1.0.27, all XrStructureType initializations have been updated to follow the standard OpenXR style. When writing code that interacts with OpenXR structures, ensure you are initializing the type field according to the standard pattern to maintain compatibility and consistency with the SDK.

  10. Android compatibility for OpenXR API levels 30 and above

    main
    In OpenXR SDK 1.0.28, the loader includes compatibility handling for Android devices with API levels 30 and above. Runtimes may need to be updated to support this compatibility solution. Specifically, the loader's required <queries> elements for Android applications have been updated so that runtime and layer components loaded in the application process can access their own packages in API >29.

  11. Use the Best Practices Validation API Layer

    main
    Starting with OpenXR SDK 1.1.51, a new API layer is available to assist developers in ensuring their OpenXR applications follow industry best practices. This layer checks for application behaviors that are technically valid according to the specification but contradict recommended best practices. This is useful during development to improve application robustness and compatibility.

  12. Understand JsonCpp versioning and C++ compatibility

    main

    JsonCpp uses specific versioning schemes to indicate C++ standard requirements and backward compatibility:

    • 1.y.z versions: Built with C++11.
    • 0.y.z versions: Compatible with older compilers.
    • 00.11.z versions: A special branch designed to balance features and compatibility. It allows using some new features introduced in 1.y.z that are not available in 0.y.z, while remaining usable in both old and new compilers.

    Major versions are designed to maintain binary compatibility.