-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
vsgvr could not automatically startup steamvr #15
Comments
What happens if you start without the run.sh? I've never used it, or needed to. From the logs steamvr has been detected and initialised as the openxr runtime, it's just giving us an error when initialising vulkan. From the message "error: output device could not be determined." it looks like steamvr can't tell us which vulkan device should be used (Like it's supposed to, according to the openxr spec..) What's your system, gpu, vr headset etc? The eventual reason for the crash is I'm throwing an exception if any OpenXR errors occur. in this case perhaps we can catch it, and just select the first physical device on the system and hope for the best. If this happened on a laptop, or something with 2 GPUs however we risk choosing the wrong one, and then initialisation would fail later. With OpenXR we have to render (or at least present) with the device it chooses, any selection we may want can be wrong. |
The same
Dual NVIDIA GTX 1070, Graphic driver version 525.53, HMD: HTC VIVE and all 3 monitors connected to gpu:0 |
Here is a detailed log xrclient_example_vr.txt |
Okay thanks for testing, if you can it would be interesting to know:
Let's call it a bug, but perhaps it's one in steamvr. The spec is clear that we need to call it, but doesn't provide much on how the runtime may respond. I know in the past steamvr has had issues with vulkan device selection on Linux, having had to disable my integrated GPU completely the last time I ran a desktop system, and plug the dedicated GPUs into specific slots.. A possible (bad psuedocode) fix for OpenXRGraphicsBindingVulkan.cpp would be something like this, ideally with:
As it currently stands though, an application will get an exception (albeit a generic one) and could choose to use a specific device - The user knows where the headset is connected if nothing else.
|
The particular problem with SteamVR on Linux is that it turns off all monitors at startup, so it's hard to debug from the same host :-( For the log I found a few details, when running the application:
|
Another variant is (without XR_ENABLE_API_LAYERS=1):
|
After disabling the second graphics card the problem occurs the same way. I also started SteamVR with null driver turned on, also shows the same problem, which let me think this is not a graphics card issue. You can also reproduce the problem if, for example, the HDMI cable connection is disconnected on the HTC VIVE, which causes SteamVR to switch to null driver mode and open a separate window (monitor mode).
I'm currently not able to run Windows on the same host, but I ran vsgvr from a portable build generated from the https://build.opensuse.org/package/show/home:rhabacker:branches:games:mingw64/mingw64-vsgvr project on Windows 10, which shows the world scene which shows that the included packages (especially OpenXR) and vsgvr basically work with up to date vsg. Doing the same with a 32 bit variant did not work because SteamVR/32bit has no support for OpenXR. |
I looked a little deeper in this stuff and found out that in OpenXRGraphicsBindingVulkan::getVulkanDeviceRequirements()
no physical vulkan device is returned. In a debug session the mentioned variable
which is located in the SteamVR library
|
As this time vsg already detected a valid physical vulkan device, which I used instead as return value:
With this change the next issue happens in
The mentioned symbol is also located in a library of the SteamVR runtime environment:
which suggests that this problem is related to the implementation of OpenXR in the SteamVR runtime environment. |
"which suggests that this problem is related to the implementation of OpenXR in the SteamVR runtime environment." Yes, that tracks with my assumptions / previous issues for SteamVR - It seems like they're not following the specification, or had some other failure internally, that wasn't trapped before the call to xrGetVulkanGraphicsDeviceKHR. It's a case where I'm happy to add a workaround for SteamVR given the caveats mentioned earlier, but if they've got a bug it's really their problem. Using one of the physical devices from VSG/Vulkan is fine, we'd just need to get the correct one (which, it sounds like SteamVR doesn't actually know which device is correct in this case). Thanks for the continued testing, it's all useful information to gather. |
Original issue of steamvr not-starting automatically - I've reproduced that on my laptop, either regular or beta branch of steamvr, rtx3060, vive..A slightly different log perhaps? I'm not sure where to debug from here.
Couldn't reproduce the monitors turning off issue, seems fine for me. Running Xubuntu 20.04, so not-Wayland if that's relevant. A good question would be whether steamvr auto-starts at all on Linux? I don't think I've ever seen it happen for vsgvr, but does it happen for other applications? |
I compiled the binary
example_vr
on Linux withRunning the generated executable with steamVR installed and following the [runtime requirements] (https://github.com/ValveSoftware/SteamVR-for-Linux/blob/master/README.md#runtime-requirements) of steamVR on Linux with
provides:
SteamVR must be started first to avoid this error message. For the variant with
openvr
this is not necessary, SteamVR is started automatically.The text was updated successfully, but these errors were encountered: