Generic OpenXR build/loader usage #1394
Comments
|
Hi @rpavlik! A pleasure to have you around :). Many thanks for your comments. I didn't know that Meta devices were already supporting the standard loader, that's great to hear and definitely unblocks this task that has been in our backlog for a while. We'd still have to double check that things still work in all the supported platforms but it's something that we want to do for sure (we need also to be sure that most of our users are on 62+ for example, wouldn't like to ship a breaking update). It won't be available for the next 1.6.1 release but I really hope to have it ready for 1.7.x Again thanks for knocking the door with these great suggestions. |
|
So I've the patch almost ready. So far the devices I've tried in which it's working
The ones where it isn't working
This last one is really surprising to me. They're using Monado and I'd expect it to work with the downloaded khronos loader, but it looks like I can only make it to work with the loader we currently use extracted from the unreal sdk. Does this list make sense to you @rpavlik ? |
|
yes, that makes sense to me, tbh I'm pretty pleasantly surprised you got it to work on lynx. I am leaning pretty hard on the snapdragon spaces people to support the standard loader sooner rather than later. I'm hoping Pico should also support it soon too. I've literally never seen nor heard of the Huawei thing and they didn't submit conformance for it... |
Most of the platforms used to distribute their own implementations/builds of the OpenXR loader. It was traditionally part of the propietary SDKs distributed by vendors. As they were under an EULA we had to keep them in a private repository only available to core devs (obviously any other external dev could download them on their own). More recently, and driven by the AOSP flavor effort, we started to build the Khronos OpenXR loader from sources. Fortunatelly we got a well documented report explaining how to use the loader directly from the central Maven repository. This greatly simplifies the build process and also improves the open-source feel of the project by reducing our deps with the third-party repo. So far this option is now available for the following flavors: * Meta Quest2, Quest3, QuestPro (requires firmware v62+) * Lynx R1 * Magic Leap 2 It does not work for neither HVR, nor SnapdragonSpaces based devices nor Pico. For these ones we still need to rely on the loader from the SDK. Fixes #1394
Most of the platforms used to distribute their own implementations/builds of the OpenXR loader. It was traditionally part of the propietary SDKs distributed by vendors. As they were under an EULA we had to keep them in a private repository only available to core devs (obviously any other external dev could download them on their own). More recently, and driven by the AOSP flavor effort, we started to build the Khronos OpenXR loader from sources. Fortunatelly we got a well documented report explaining how to use the loader directly from the central Maven repository. This greatly simplifies the build process and also improves the open-source feel of the project by reducing our deps with the third-party repo. So far this option is now available for the following flavors: * Meta Quest2, Quest3, QuestPro (requires firmware v62+) * Lynx R1 * Magic Leap 2 It does not work for neither HVR, nor SnapdragonSpaces based devices nor Pico. For these ones we still need to rely on the loader from the SDK. Fixes #1394
Most of the platforms used to distribute their own implementations/builds of the OpenXR loader. It was traditionally part of the propietary SDKs distributed by vendors. As they were under an EULA we had to keep them in a private repository only available to core devs (obviously any other external dev could download them on their own). More recently, and driven by the AOSP flavor effort, we started to build the Khronos OpenXR loader from sources. Fortunatelly we got a well documented report explaining how to use the loader directly from the central Maven repository. This greatly simplifies the build process and also improves the open-source feel of the project by reducing our deps with the third-party repo. So far this option is now available for the following flavors: * Meta Quest2, Quest3, QuestPro (requires firmware v62+) * Lynx R1 * Magic Leap 2 It does not work for neither HVR, nor SnapdragonSpaces based devices nor Pico. For these ones we still need to rely on the loader from the SDK. Fixes #1394
Most of the platforms used to distribute their own implementations/builds of the OpenXR loader. It was traditionally part of the propietary SDKs distributed by vendors. As they were under an EULA we had to keep them in a private repository only available to core devs (obviously any other external dev could download them on their own). More recently, and driven by the AOSP flavor effort, we started to build the Khronos OpenXR loader from sources. Fortunatelly we got a well documented report explaining how to use the loader directly from the central Maven repository. This greatly simplifies the build process and also improves the open-source feel of the project by reducing our deps with the third-party repo. So far this option is now available for the following flavors: * Meta Quest2, Quest3, QuestPro (requires firmware v62+) * Lynx R1 * Magic Leap 2 It does not work for neither HVR, nor SnapdragonSpaces based devices nor Pico. For these ones we still need to rely on the loader from the SDK. Fixes #1394
Most OpenXR devices (including several you actively support) now support using the standard loader, which is available publicly as an AAR and through Maven Central, as well as through source. (And at the WG level I am applying pressure to make it so that all runtimes support the standard loader.) Right now I have active knowledge that it's the recommended or only path on Magic Leap 2, HTC Vive Focus 3 and XR Elite, and that it works (when using loader 1.0.33 or newer) on Quest 2/3/pro with firmware v62+, not sure if it's official yet there but it is widely known.
I see that the build can use the standard source if building as a part of AOSP, but it is far easier than that to build with the standard loader, see e.g.
buildFeatures { prefab true }is set: https://gitlab.freedesktop.org/monado/demos/androidteapots/-/blob/main/classic-teapot/build.gradle?ref_type=heads#L47find_package(OpenXR)https://gitlab.freedesktop.org/monado/demos/androidteapots/-/blob/main/classic-teapot/src/main/cpp/CMakeLists.txt?ref_type=heads#L19 followed bytarget_link_libraries(${PROJECT_NAME} PRIVATE OpenXR::openxr_loader)https://gitlab.freedesktop.org/monado/demos/androidteapots/-/blob/main/classic-teapot/src/main/cpp/CMakeLists.txt?ref_type=heads#L49This should allow additional usage of the app, as well as simplifying build and test pipelines and improving the open-source feel of the project by reducing dependencies on the private third-party deps repo.
If you want to have optional use of third-party headers for additional unpublished extensions, that is still compatible with the standard loader: the loader is fully forward compatible (somewhat unlike vulkan). This is entirely compatible with enabling functionality where available based on what vendor extensions are present on a system, that's how OpenXR is designed to work.
I thought I had filed an issue about this in the past, but all I could find was my mentions of this.
Thanks for your consideration!
The text was updated successfully, but these errors were encountered: