Generic OpenXR build/loader usage
rpavlik opened this issue · comments
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.
- Gradle: Add dependency, make sure
buildFeatures { prefab true }is set: https://gitlab.freedesktop.org/monado/demos/androidteapots/-/blob/main/classic-teapot/build.gradle?ref_type=heads#L47 - CMake: Thanks to some very precise prefab metadata files in the AAR and the workings of the prefab tool built into the Android Gradle Plugin, this part works exactly as on desktop:
find_package(OpenXR)https://gitlab.freedesktop.org/monado/demos/androidteapots/-/blob/main/classic-teapot/src/main/cpp/CMakeLists.txt?ref_type=heads#L19 followed by - CMake:
target_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#L49
This 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!
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
- Quest3 v64
- Quest2 v62
- MagicLeap2 v1.6
- Lynx-R1 v1.1.10
The ones where it isn't working
- Pico 4/4E
- Huawei HVR
- LenovoA3 (snapdragon spaces)
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...