ELF-SR2 runtime hello_xr sample

OpenXR
1

Hello

I am trying to extend our current OpenGL rendering app (Windows, MFC, OpenGL) via OpenXR to make use of Sony’s spatial reality display (ELF-SR2). To get going, I started with the hello_xr sample from Khronos’ Github ( OpenXR-SDK-Source).

Unfortunately, the sample won’t run due to the following error:

hello_xr.exe -g OpenGL

[16:37:51.807][Info ] Press any key to shutdown…
Error [GENERAL | xrEnumerateInstanceExtensionProperties | OpenXR-Loader] : RuntimeInterface::LoadRuntime skipping manifest file C:\Program Files\Sony\SpatialRealityDisplay\config\srd-openxr-runtime.json, failed to load with message "Failed to open dynamic library C:\Program Files\Sony\SpatialRealityDisplay\config..\lib\xr_runtime.dll with error 126: 0x7e (126): The specified module could not be found.
Error [GENERAL | xrEnumerateInstanceExtensionProperties | OpenXR-Loader] : RuntimeInterface::LoadRuntimes - failed to load a runtime
Error [GENERAL | xrEnumerateInstanceExtensionProperties | OpenXR-Loader] : Failed to find default runtime with RuntimeInterface::LoadRuntime()
Error [GENERAL | xrEnumerateInstanceExtensionProperties | OpenXR-Loader] : Failed querying extension properties
[16:37:51.816][Error ] XrResult failure [XR_ERROR_RUNTIME_UNAVAILABLE]
Origin: xrEnumerateInstanceExtensionProperties(layerName, 0, &instanceExtensionCount, nullptr)
Source: D:\Software\ThirdParty\OpenXR-SDK-Source\src\tests\hello_xr\openxr_program.cpp:132

I am completely new to OpenXR so I am unsure what is wrong.

I verified that the xr_runtime.dll is in the correct place, that the ActiveRuntime regkey is pointing to the correct json-file and that this file is pointing to the correct runtime dll location. According to the conformant products webpage, this device should be compatible with OpenXR 1.0. However, when I analyze the xr_runtime.dll supplied by Sony with DependencyWalker, the functions do not exactly match with the OpenXR specification. For example, xrCreateSession is implemented as srd_xrCreateSession. In addition, many other functions in this DLL are present that are not listed in the OpenXR API. Unfortunately, no documentation or SDK is shipped with the ELF-SR2 and Sony has not yet given any insightful information.

Lastly, I wanted to verify that I had correctly build the hello_xr sample by using a different runtime, in order to prove that something is wrong with the ELF-SR2 runtime version. However, I do not seem to get my hands on any?

Any ideas on how to understand and resolve this problem would be greatly appreciated.
Best regards

2

Are you sure the “bitness” (32-bit vs 64-bit) matches? As in your app is build for x64, and the Sony runtime pointed by the registry is x64 as well? For Win32, the loader looks somewhere else in the registry, and if there is no 32-bit runtime, you’ll just get these errors I think.

3

Wait - second thought. This path looks kinda wrong! See config..\lib? This isn’t a valid Windows path! I think the content of the runtime JSON is malformed.

4

Sony recommends a 64-bit machine and their test application can run, so I guess that’s not issue. Thanks for the reply.

5

Indeed, I thought the path looked funny as well. However, when copying this path in file explorer the correct runtime file is found. Anyway, I tried replacing the path in the JSON file to an absolute one, without success.

6

UPDATE:

I downloaded the setup installer for Oculus Rift, which installed an OpenXR runtime, and replaced the registry key to point to the Oculus JSON file. Then the example CAN load the library correctly (although the test app breaks down further down the line). Hence, there must be something “wrong” with the sony runtime.

7

I found the solution, yet don’t understand it.

Long story short, I had to place a copy of ftd2xx.dll in the application’s folder.

Even though that same dll was right next to the xr_runtime.dll and in the system32 folder, this “missing” dependency caused Windows’ LoadLibrary() function and the subsequent LoadLibraryEx() from the hello_xr sample to fail.
I figured this out by profiling my application with Dependency Walker and comparing the results with the sample applications provided by Sony. In these samples, the same xr_runtime.dll was dynamically loaded with no visible difference to how it is done by hello_xr. Through a desparate guess, where I copied all DLL’s that were in the sample application’s folder to my application’s folder, when things started to work. I then removed each additional dll one by one to figure out it is the ftd2xx.dll that is causing the problem.
Nevertheless, I don’t understand why this additional dependence cannot be resolved.

8

Ah, interesting. Yes, that’s a problem that Monado had to handle (an open source runtime that has some Windows support) though I don’t remember what steps we had to take to make it work. I am surprised that this was not caught by the CTS process. I’ll try to reach out and see what can be done, because you are correct that this should not be a required step.