OpenXR late initialization

OpenXR
1

In order to initialize an OpenXR instance properly (in PCVR at least), the headset must be up, running, and connected to the PC. And it also affects our graphics api initialization as well (e.g. Vulkan2). This requires using the headset first and starting the application after.

I was wondering what are some common practices in the case where delayed OpenXR initialization is desired. For example a design application that needs to initialize Vulkan to provide graphics in a conventional way, but when the user wants, could wear a headset and transition into VR.

Could creating 2 Vulkan instances for the same gpu device be the way to go? This sounds pretty rare, is there something else that can be done? Thanks for any insights!

2

That is actually one of the main options, yes, and it’s not particularly rare. There is broad support for sharing things between vulkan instances (this is generally how runtimes themselves do things)

Another option is using vulkan_enable (1) and trying to make sure you enable all extensions and features a runtime might request when you do your own Vulkan init earlier in execution. (all the external memory/fence/semaphore extensions, timeline semaphores, etc.)

We are aware that the “let us do the setup” model of vulkan_enable2 doesn’t work well for a number of use cases, including this one. Thanks for your feedback, I’ll link this post in our ongoing discussions.