Game freeze when headset goes to sleep about godot_openvr HOT 38 OPEN

If this is indeed the problem then there is a simple work around. Instead of turning the main viewports ARVR mode on, create a custom viewport in your scene, make sure the ARVROrigin node and everything underneath is a child and turn this into your ARVR viewport. DO make sure to set this viewport up correctly, it has to have a default size (for some reason the internal logic ignores viewports with the size of 0,0) and that its update mode is set to always.

✔️ We took this approach w/Simula and now HMD freezes appear completely fixed.

Thanks to @beniwtv @BastiaanOlij for your help & patience throughout this bug debug. ❤️

from godot_openvr.

The framebuffer errors were just an artifact of apitrace. The real culprit seems to be whatever triggers all the glDelete*/glGen* (or some consequence thereof)

from godot_openvr.

I did a hacky test workaround just by creating a dummy texture name at the end of each _render_target_clear call, and that fixed the issue [by making each subsequent _render_target_allocate have different texture names]. This confirmed my theory about OpenVR making incorrect assumptions). I've filed an issue with OpenVR, but your solution seems reasonably elegant and doesn't require fiddling with texture name allocations.

from godot_openvr.

Ok, that gives us a valid workaround! We still need to fix the original problem but at least we have an idea of where things are going wrong. Does sound like an upstream issue.

from godot_openvr.

After updating godot_openvr, I've noticed this also occasionally happens when entering and exiting the SteamVR "pause menu".

from godot_openvr.

Were you ever able to replicate this? This seems to be now happening after removing my eyes from the HMD for a few seconds and then returning them. I'm finally able to try updating godot/godot_openvr and will see if the problem still persists.

from godot_openvr.

Compiling godot_openvr with the following branches:

I am able to run Simula (our Godot VR compositor) and the godot_openvr demo as long as there is no controller (see #67); however, I'm still getting HMD freezes in Simula. I am not able to get HMD freezes in the godot_openvr demo. So I have looked for differences between Simula and the godot_openvr demo and I have found some candidates:

Rendering options. Simula uses

[rendering]

quality/driver/driver_name="GLES2"
quality/filters/msaa=8
environment/default_environment="res://default_env.tres"
quality/filters/anisotropic_filter_level=16

vs. the godot_openvr demo (which defaults to GLES3):

[rendering]

quality/filters/msaa=1
environment/default_environment="res://default_env.tres"

I changed to the demo to GLES2, etc and was unable to get freezes in it, so I don't think this is it.

Initialization. Simula essentially uses (which I hope is legible as psuedo-code in case you've never used Haskell):

-- | Initialize the ARVRInterface and return the success/failure
initVR :: GodotNode -> GodotARVRInterface -> IO VRInitResult
initVR node vri =
  G.initialize vri >>= \case
    True  -> initSuccess
    False -> initFailed
 where
  initSuccess :: IO VRInitResult
  initSuccess = do
    G.get_viewport node >>= (`G.set_use_arvr` True)
    G.get_viewport node >>= (`G.set_hdr` False) -- Not needed with GLES2 renderer
    getSingleton Godot_OS "OS" >>= (`G.set_use_vsync` False) -- Vsync must be disabled or we're limited to 60fps
    getSingleton Godot_Engine "Engine" >>= (`G.set_target_fps` 90) -- Boost FPS to 90 without vsync

    InitVRSuccess <$ godotPrint "Initialized VR interface."

  initFailed :: IO VRInitResult
  initFailed = do
    InitVRFailed <$ godotPrint "Failed to initialize VR interface."

while the godot_openvr demo uses

if arvr_interface and arvr_interface.initialize():
  # switch to ARVR mode
  get_viewport().arvr = true

  # keep linear color space, not needed with the GLES2 renderer
  get_viewport().keep_3d_linear = true

  # make sure vsync is disabled or we'll be limited to 60fps
  OS.vsync_enabled = false

  # up our physics to 90fps to get in sync with our rendering
  Engine.target_fps = 90

Environment options. Simula uses

[gd_resource type="Environment" load_steps=2 format=2]

[sub_resource type="ProceduralSky" id=1]
sky_top_color = Color( 0.0470588, 0.454902, 0.976471, 1 )
sky_horizon_color = Color( 0.556863, 0.823529, 0.909804, 1 )
sky_curve = 0.25
ground_bottom_color = Color( 0.101961, 0.145098, 0.188235, 1 )
ground_horizon_color = Color( 0.482353, 0.788235, 0.952941, 1 )
ground_curve = 0.01

[resource]
background_mode = 2
background_sky = SubResource( 1 )

vs the godot_openvr demo:

[gd_resource type="Environment" load_steps=2 format=2]

[sub_resource type="ProceduralSky" id=1]
sky_top_color = Color( 0.0470588, 0.454902, 0.976471, 1 )
sky_horizon_color = Color( 0.556863, 0.823529, 0.909804, 1 )
sky_curve = 0.25
ground_bottom_color = Color( 0.101961, 0.145098, 0.188235, 1 )
ground_horizon_color = Color( 0.482353, 0.788235, 0.952941, 1 )
ground_curve = 0.01
sun_energy = 16.0

[resource]
background_mode = 2
background_sky = SubResource( 1 )
ssao_blur = 1

ssao_blur. Notice that Simula doesn't specify ssao_blur, while the godot_openvr demo sets it to 1. I tried setting ssao_blur = 1 in Simula and, so far, have not duplicated an HMD freeze (crossing my fingers this fixes it). However, I also set ssao_blur = 0 in the godot_openvr demo and am still unable to duplicate an HMD freeze, so this might not be it. Also, according to Google:

Screen space ambient occlusion (SSAO) is the standard solution for approximating ambient occlusion in video games. Ambient occlusion is used to represent how exposed each point is to the indirect lighting from the scene.

It's conceptually unclear to me why turning this on would prevent HMD freezes. Does it make sense that this could be the issue?

from godot_openvr.

The ssao_blur = 1 was a total red herring. I just got another freeze using the new godot-openvr + ssao_blur = 1 in Simula.

I think that having meshes in view significantly increase the chances of an HMD freeze occurring.

from godot_openvr.

I also just verified that setting get_viewport().keep_3d_linear is not the issue (changing its value in Simula doesn't prevent freezes from going away).

from godot_openvr.

I was able to duplicate an HMD freeze in the godot_openvr/demo when stripping the Main.tscn to the following (more minimal) setup (taking the Vive on and off my eyes until it freezed after a few seconds):

[gd_scene load_steps=13 format=2]

[ext_resource path="res://Main.gd" type="Script" id=1]
[ext_resource path="res://Milkyway.png" type="Texture" id=2]
[ext_resource path="res://Table.tscn" type="PackedScene" id=3]
[ext_resource path="res://addons/godot-openvr/scenes/ovr_first_person.tscn" type="PackedScene" id=4]
[ext_resource path="res://addons/vr-common/misc/VR_Common_Shader_Cache.tscn" type="PackedScene" id=5]
[ext_resource path="res://addons/vr-common/functions/Function_Teleport.tscn" type="PackedScene" id=6]
[ext_resource path="res://addons/vr-common/functions/Function_Direct_movement.tscn" type="PackedScene" id=7]

[node name="Main" type="Spatial"]
script = ExtResource( 1 )

[node name="OVRFirstPerson" parent="." instance=ExtResource( 4 )]

[node name="vr_common_shader_cache" parent="OVRFirstPerson/ARVRCamera/shader_cache" index="5" instance=ExtResource( 5 )]

Comparing to the full version of Main.tscn, it is not clear to me what I stripped could be preventing these HMD freezing.

from godot_openvr.

Adding the Milkyway.png sky to Simula seems to (so far) have fixed the HMD freeze issue. That is we now use:

[gd_scene load_steps=2 format=2]

[ext_resource path="res://addons/godot-haskell-plugin/Simula.gdns" type="Script" id=1]
[ext_resource path="res://Milkyway.png" type="Texture" id=2]

[sub_resource type="PanoramaSky" id=1]
panorama = ExtResource( 2 )

[sub_resource type="Environment" id=2]
background_mode = 2
background_sky = SubResource( 1 )
background_color = Color( 0, 0.53833, 0.703125, 1 )
ambient_light_color = Color( 0.328125, 0.328125, 0.328125, 1 )
ssao_blur = 1

[node name="Root" type="Node"]
script = ExtResource( 1 )

[node name="Camera" type="Camera" parent="."]
transform = Transform( -1, 0, -8.74228e-08, 0, 1, 0, 8.74228e-08, 0, -1, 0, 0, -0.62817 )
current = true

[node name="WorldEnvironment" type="WorldEnvironment" parent="."]
environment = SubResource( 2 )

[node name="DirectionalLight" type="DirectionalLight" parent="."]
transform = Transform( 0.623013, -0.733525, 0.271654, 0.321394, 0.55667, 0.766044, -0.713134, -0.389948, 0.582563, 0, 100, 0 )

in our main scene that launches with Simula. It's unclear to me how this stuff could be preventing HMD freezes, but I'm happy nonetheless.

from godot_openvr.

My theory on this is too that when the headset goes to sleep it won't wake up again in Godot's case (check if when you remove the headset from your eyes it starts blinking in the VR monitor and possibly saying "sleeping").

Strange though adding Milkyway would work around the problem. In that case it also could be that Godot just doesn't resume rendering in some cases, and Milkyway somehow triggers it to resume.

I'll have a closer look at how the sleeping is supposed to recover.

from godot_openvr.

I'm still at a loss to explain this either, hasn't been a problem for me so far with the Index which I guess is the closest to the Vive.. .

from godot_openvr.

Strange though adding Milkyway would work around the problem. In that case it also could be that Godot just doesn't resume rendering in some cases, and Milkyway somehow triggers it to resume.

Ugh. It turns out the "Milkyway environment fixes everything" was a total false alarm. I just got another freeze with the Milkyway environment loaded into Simula.

I'm still at a loss to explain this either, hasn't been a problem for me so far with the Index which I guess is the closest to the Vive.. .

@BastiaanOlij BastiaanOlij What distro/GPU are you running? Is it possible/plausible that this could be a Vive only issue?

My theory on this is too that when the headset goes to sleep it won't wake up again in Godot's case (check if when you remove the headset from your eyes it starts blinking in the VR monitor and possibly saying "sleeping").

@beniwtv When removing the headset from my eyes, the HMD turns off. When placing it back on my eyes, it turns back on. Sometimes it works as expected. Sometimes it comes back frozen. I've had a few times where I didn't even take the headset fully off; instead, I just tilted the headset up barely up over my eyes and back so I could check something on my desk, and in that fraction of a second the HMD is frozen.

Overall: let me know if there's anything I can do/look into to figure out what is causing this. This is the main thing making our Linux VR compositor completely unusable right now. 😢

from godot_openvr.

One person using Simula noticed that HMD freezes tend to happen when the Vive goes out of (and returns into) the tracker bounds. I was unable to replicate this myself, but am just flagging it as a possibility.

Also, in case it matters: both of us are only using 1 tracker station.

from godot_openvr.

That gives me a few vectors to to try and reproduce it.

We set the textures in ARVRInterface.cpp:
https://github.com/GodotVR/godot_openvr/blob/master/src/ARVRInterface.cpp#L325

If anything, I'd expect it to fail there.
Also can you let me know which SteamVR version this is on?

from godot_openvr.

Thanks: I'm running SteamVR 1.8.20.

from godot_openvr.

Unfortunately, I have not been able to reproduce this on my Valve Index.

I tried both the regular demo, and the stripped down one, letting it sleep multiple times (and multiple minutes), going out of bounds and coming back in, and using only 1 tracking station.

In every case it resumed rendering in the HMD fine.

It's indeed possible that this is a Vive-only issue, back when I had the Vive I remember some game freezes happening when opening the dasboard, etc...
ValveSoftware/SteamVR-for-Linux#136

However, I just updated the Linux build with the latest godot-cpp and OpenVR libs in master, could you try to reproduce the issue with that and Godot 3.2 beta? Also, can you try to reproduce with SteamVR beta?

My brother now has my Vive, so it might be some time until I can get to it :(

from godot_openvr.

On the off chance it matters: our version of Godot 3.1 messes with SIGUSR1 signals (e.g. here). Is there a chance this has something to do with our freezes?

I'm trying to replicate an HMD freeze with godot 3.1 (without SIGUSR1 modifications) and so far have been unable to replicate a freeze (but I've been fooled in the past into thinking freezes are fixed when they aren't :)

In the meantime: I'll see if I can locate a Valve Index somewhere, and also will test with Godot 3.2 and report back.

from godot_openvr.

SIGUSR1 stuff isn't the issue. I stripped our godot binary of the SIGUSR1 modifications, and was able to still experience an HMD freeze in Simula, so that's not the issue either.

Testing the latest godot_openvr (w/fresh compilation) causes errors in Simula. The following errors seem to oscillate at launch:

1. surface_set_material error.

   0x000000000159652b in godot_method_bind_ptrcall (p_method_bind=0x0, p_instance=0x7123a10, p_args=0x7fffffffdc30, p_ret=0x0) at modules/gdnative/gdnative/gdnative.cpp:69
   69    mb->ptrcall(o, p_args, p_ret);
   (gdb) bt
   #0  0x000000000159652b in godot_method_bind_ptrcall(godot_method_bind*, godot_object*, void const**, void*) (p_method_bind=0x0, p_instance=0x7123a10, p_args=0x7fffffffdc30, p_ret=0x0)
       at modules/gdnative/gdnative/gdnative.cpp:69
   #1  0x00007fffed46600e in godot::___godot_icall_void_int_Object (inst=<optimized out>, arg1=<optimized out>, arg0=<optimized out>, mb=<optimized out>) at include/gen/__icalls.hpp:3362
   #2  0x00007fffed46600e in godot::Mesh::surface_set_material(long, godot::Ref<godot::Material>) (this=this@entry=0x7168a80, surf_idx=surf_idx@entry=0, material=...) at src/gen/Mesh.cpp:83
   #3  0x00007fffed44b4dc in openvr_data::_load_render_model(openvr_data::model_mesh*) (this=0x63ec500, p_model=0x717bed0) at godot-cpp/include/core/Ref.hpp:175
   #4  0x00007fffed44b8ee in openvr_data::process() (this=0x63ec500) at /usr/include/c++/8/bits/stl_vector.h:930
   #5  0x00007fffed44556e in godot_arvr_process(void*) (p_data=0x6472e30) at src/ARVRInterface.cpp:344
   #6  0x00000000015b9864 in ARVRInterfaceGDNative::process() (this=0x64514f0) at modules/gdnative/arvr/arvr_interface_gdnative.cpp:211
   #7  0x0000000002ee599b in ARVRServer::_process() (this=0x5e57e90) at servers/arvr_server.cpp:356
   #8  0x00000000030e212c in VisualServerViewport::draw_viewports() (this=0x5239020) at servers/visual/visual_server_viewport.cpp:250
   #9  0x00000000030b4591 in VisualServerRaster::draw(bool, double) (this=0x52162d0, p_swap_buffers=true, frame_step=1.050428032875061) at servers/visual/visual_server_raster.cpp:106
   #10 0x00000000030e8a68 in VisualServerWrapMT::draw(bool, double) (this=0x53a5060, p_swap_buffers=true, frame_step=1.050428032875061) at servers/visual/visual_server_wrap_mt.cpp:102
   #11 0x00000000011db673 in Main::iteration() () at main/main.cpp:1892
   #12 0x00000000011ad87f in OS_X11::run() (this=0x7fffffffe2e0) at platform/x11/os_x11.cpp:3006
   #13 0x000000000119e63e in main(int, char**) (argc=3, argv=0x7fffffffea58) at platform/x11/godot_x11.cpp:55
   

2. futex error.

   (gdb) bt
   #0  0x00007ffff7647086 in futex_abstimed_wait_cancelable
       (private=0, abstime=0x0, expected=0, futex_word=0x4d885f8) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
   #1  0x00007ffff7647086 in do_futex_wait
       (sem=sem@entry=0x4d885f8, abstime=0x0)
       at sem_waitcommon.c:111
   #2  0x00007ffff7647178 in __new_sem_wait_slow
       (sem=0x4d885f8, abstime=0x0) at sem_waitcommon.c:181
   #3  0x0000000001b48abe in SemaphorePosix::wait()
       (this=0x4d885f0) at drivers/unix/semaphore_posix.cpp:41
   #4  0x00000000030c3af1 in VisualServerScene::_gi_probe_bake_thread() (this=0x52391d0)
       at servers/visual/visual_server_scene.cpp:2519
   #5  0x00000000030c28f6 in VisualServerScene::_gi_probe_bake_threads(void*) (self=0x52391d0)
       at servers/visual/visual_server_scene.cpp:2305
   #6  0x0000000001b48e01 in ThreadPosix::thread_callback(void*) (userdata=0x5351320) at drivers/unix/thread_posix.cpp:81
   #7  0x00007ffff763e182 in start_thread (arg=<optimized out>)
       at pthread_create.c:486
   #8  0x00007ffff7102b1f in clone ()
       at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
   

3. JoyPadLinux error.

   Thread 5 "godot" received signal SIGUSR1, User defined signal 1.
   [Switching to Thread 0x7fffedc22700 (LWP 10207)]
   0x00007ffff70c6670 in __GI___nanosleep (
       requested_time=requested_time@entry=0x7fffedc21b70, remaining=remaining@entry=0x0)
       at ../sysdeps/unix/sysv/linux/nanosleep.c:28
   28  ../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory.
   (gdb) bt
   #0  0x00007ffff70c6670 in __GI___nanosleep (requested_time=requested_time@entry=0x7fffedc21b70, remaining=remaining@entry=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
   #1  0x00007ffff70f9894 in usleep (useconds=<optimized out>) at ../sysdeps/posix/usleep.c:32
   #2  0x00000000011b525f in JoypadLinux::monitor_joypads() (this=0x5e65a80) at platform/x11/joypad_linux.cpp:217
   #3  0x00000000011b5160 in JoypadLinux::run_joypad_thread() (this=0x5e65a80) at platform/x11/joypad_linux.cpp:115
   #4  0x00000000011b5143 in JoypadLinux::joy_thread_func(void*) (p_user=0x5e65a80) at platform/x11/joypad_linux.cpp:102
   #5  0x0000000001b48e01 in ThreadPosix::thread_callback(void*) (userdata=0x5e76b50) at drivers/unix/thread_posix.cpp:81
   #6  0x00007ffff763e182 in start_thread (arg=<optimized out>) at pthread_create.c:486
   #7  0x00007ffff7102b1f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
   

New godot_openvr demo testing: so far so good. On a more positive note: testing the latest godot_openvr (with stripped Main.tscn, as above) with (i) godot 3.1 as well as (ii) godot 3.2 alpha (master branch HEAD) doesn't cause an HMD freeze so far. I tried with and without SteamVR Beta. That said (and I have no idea why): HMD freezes seem to occur much more frequently in Simula (within a few seconds) than in the demo (within minutes to several minutes), so it's still possible I could get a freeze to occur if I tried harder.

from godot_openvr.

@beniwtv

It's indeed possible that this is a Vive-only issue, back when I had the Vive I remember some game freezes happening when opening the dasboard, etc...
ValveSoftware/SteamVR-for-Linux#136

❌ Just tried Simula w/the Valve Index and got a freeze within 30 seconds.

On the bright side: at least it's not a hardware issue (since a lot of people are still using Vives).

from godot_openvr.

Strong hypothesis as to what is causing HMD freezes: maximizing the pancake mode view. Just tried in Simula and in the godot_openvr demo and it replicated.

This is something I regularly do within the first 30 seconds of opening Simula, but not as much with the godot_openvr demo (explaining why freezes are happening so much with Simula). If this turns out to be the issue I will kick myself because it's so obvious in retrospect.

@beniwtv Can you try this at some point with your Linux setup to see if it replicates?

from godot_openvr.

Interesting! Will try and let you know!

from godot_openvr.

@beniwtv

✔️ Reproduced this with godot 3.2 alpha + SteamVR beta (1.9.4) + godot openvr demo.
✔️ Reproduced this countless times with Simula.
❌ Am ALSO still getting freezes in Simula when lots of apps are running (without maximizing the pancake mode viewport).

What I think I'm noticing is that the slightest CPU stutter (or perhaps GPU stutter?) causes a frame stutter, which then seems to cause an HMD freeze. It might be that maximizing the pancake mode viewport is causing a stutter, which then causes an HMD freeze. Is there a way to put a godot_openvr demo through a stress test to see if it induces a freeze? In a nutshell:

from godot_openvr.

Running a gprof test shows that AudioDriverALSA::lock() takes more CPU when a headset freeze is induced than when not.

• gprof output when running the godot_openvr demo normally: https://www.wolframcloud.com/obj/4b321be3-fd28-4f6b-a6bb-34be13a2daac
• gprof output when running the godot_openvr demo with an induced headset freeze: https://www.wolframcloud.com/obj/bcdcc1ed-e5cb-4371-b4f6-572e1eeb46c3

Of note:

george@UbuntuBox:~/godot_openvr/demo$ cat gprof.txt.freeze | grep "AudioDriverALSA::lock"
  3.90      0.10     0.03    16427     0.00     0.00  AudioDriverALSA::lock()
                0.03    0.00   16425/16427       AudioDriverALSA::lock() [32]
[32]     3.9    0.03    0.00   16427         AudioDriverALSA::lock() [32]
                0.00    0.00       2/16427       AudioDriverALSA::lock() [32]
                0.00    0.00   16337/202016      AudioDriverALSA::lock() [32]
 [41933] _GLOBAL__sub_I__ZN16btCollisionWorldC2EP12btDispatcherP21btBroadphaseInterfaceP24btCollisionConfiguration (btCollisionWorld.cpp) [32] AudioDriverALSA::lock() [7265] MethodBind* ClassDB::bind_method<MethodDefinition, bool (XMLParser::*)() const>(MethodDefinition, bool (XMLParser::*)() const)
george@UbuntuBox:~/godot_openvr/demo$ cat gprof.txt.normal | grep "AudioDriverALSA::lock"
  0.00      0.89     0.00    18428     0.00     0.00  AudioDriverALSA::lock()
                0.00    0.00   18426/18428       AudioDriverALSA::lock() [34881]
                0.00    0.00   18356/215892      AudioDriverALSA::lock() [34881]
[34881   0.0    0.00    0.00   18428         AudioDriverALSA::lock() [34881]
                0.00    0.00       2/18428       AudioDriverALSA::lock() [34881]
 [20610] _GLOBAL__sub_I__ZN15Physics2DServer9singletonE (physics_2d_server.cpp) [34881] AudioDriverALSA::lock() [6511] MethodBind* ClassDB::bind_method<MethodDefinition, void (SpringArm::*)(float)>(MethodDefinition, void (SpringArm::*)(float))

3.9% vs. 0.89%

EDIT: ALSA isn't to blame; I tried compiling godot 3.2 w/o support for ALSA, but was still able to induce a headset freeze.

EDIT2: Comments from @KaneTW in Simula chat about the discrepencies between these two gprofs:

kanetwToday at 11:12 PM
i see some discrepancies but nothing major so far
the first discrepancy is
draw_viewports needs more time in rnder_canvas than _draw_3d when it doesn't hang
and more time in _draw_3d when it hangs

kanetwToday at 11:31 PM
huh
i'm seeing really high dropped frames on steamtours when it doesn't freeze
weird
not sure how to interpret that
Fri Nov 22 2019 19:52:29.344760 - Processing message VRMsg_Connect from godot.x11.tools (23834) took 0.0101 seconds
that one doesn't occur when it freezes?


kanetwToday at 11:40 PM
probably nothing
but
frames appear to still be transmitted?

from godot_openvr.

Unfortunately, I still can not reproduce the issue.

I tried maximizing, turning it back to normal, going out of bounds, taking off the headset in between... Nothing go it to freeze.

Then I stressed my CPU to 100% using s-tui, still no freeze using the same method as above. Then even running Unigine Superposition, which caused heavy stutter in the HMD, still no freeze though, no matter how hard I try :(

Can you let me know the CPU & GPU of you and the users experiencing the freezes?
(I have an AMD Ryzen 2700X and a Radeon VII myself)

from godot_openvr.

@beniwtv I'm running nvidia Version 418.56 with a GeForce GTX 1070 video card on Ubuntu 19.04. My CPU: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz.

EDIT: ❌ Just upgraded to Nvidia 440.26 and am still getting the freeze.

from godot_openvr.

Video demonstration of the freeze: https://www.youtube.com/watch?v=7-7kZdK6Lcs&feature=youtu.be

The left window is the Godot pancake viewer (which when maximizes triggers the freeze); the right window is the Valve VR headset preview mode (which demonstrates the freeze). The bottom window is SteamVR's "Advanced Frame Timing" viewer, which shows a lot of spikes after the freeze is induced.

from godot_openvr.

Are the other users noticing the freeze also using Nvidia?
Also, does this happen on other VR games as well or just Godot?

As this seems to be more easily reproduced in Simula, would you be able to send me a precompiled version I can just run?

from godot_openvr.

Are the other users noticing the freeze also using Nvidia?

Yes.

Also, does this happen on other VR games as well or just Godot?

It's never happened in SteamVR Home or Tilt Brush. Right now Tilt Brush doesn't launch on the Valve Index so I can't do a proper test. Also: I suppose I'd need a game with a viewport to maximize?

As this seems to be more easily reproduced in Simula, would you be able to send me a precompiled version I can just run?

Unfortunately not: making standalone binaries isn't easy with Haskell projects :/ The video I sent you though was using the godot_openvr/demo, not Simula.

from godot_openvr.

Apitrace. @KaneTW built the latest version of apitrace and ran it against an induced headset freeze.

The apitrace can be inspected via

qapitrace godot_openvr_freeze.trace # qapitrace must be the latest build

using this godot_openvr_freeze.trace.

Frame 261. We noticed that something weird is happening in frame 261 (about when the freeze is induced):

Specifically, it looks like at this point a bunch of framebuffers are being deleted and regenerated. Here is the chat conversation I had w/@KaneTW for context:

kanetwToday at 11:43 AM i think starting with some frame the framebuffer starts erroring out

georgewsingerToday at 11:43 AM Ok

kanetwToday at 11:44 AM not sure if that's the cause or just an artifact

georgewsingerToday at 11:44 AM What do you mean by "the framebuffer"? Some piece of the GL state machine that stores textures?

kanetwToday at 11:44 AM where things are rendered to basically

georgewsingerToday at 11:44 AM The textures have got to be somewhere since they are showing correctly in pancake mode

kanetwToday at 11:54 AM frame 261 has something weird happen

georgewsingerToday at 11:55 AM 4.35 seconds in That's about when I induced the freeze

kanetwToday at 11:55 AM it deletes a bunch of framebuffers and textures and then regenerates them

from godot_openvr.

That would make sense. If the texture ID in Godot changed for some reason, and somehow the ARVR server would be sending us the old texture ID, which we would send to OpenVR, the head set would no longer update.

Unfortunately, my knowledge of he Godot renderer (or renderers in general) is very limited, so no idea why that could happen.

@BastiaanOlij any ideas what might be going on?

from godot_openvr.

My suspicion:

The framebuffer OpenVR appears to use as the read framebuffer is (in that api trace) 105. FB105 gets established at call 7554 at the start, and assigned texture 152.
Texture 152 is then deleted (call 99005, frame 261) for some reason and remade under the exact same texture id (call 99058, same frame).
By some happenstance it is used for the VR render buffer again, so OpenVR appears to never notice the texture changed. Ergo, it doesn't call glFramebufferTexture2D to reset it, and it keeps addressing an out-of-date texture internally.

from godot_openvr.

Continuing on that thought, the GL call pattern matches the pattern in _render_target_clear exactly. So whenever _render_target_clear is called, this bug appears.

I'm tempted to call this an OpenVR bug. You can't assume the texture is the same just because the ID remains unchanged just because the texture ID is identical.

Edit: This is a known issue: ValveSoftware/openvr#216

from godot_openvr.

From what I know the texture ID always remains the same though, or I am confusing it with texture IDs in Godot. In that case, what makes Godot delete / recreate it, seemingly on Nvidia hardware only?

from godot_openvr.

The OpenGL texture name (i.e. 152 here) is deleted on a _render_target_clear call (and presumably remade afterwards). It's happenstance/implementation detail that it gets assigned the same name every time.

from godot_openvr.

I've made a shitty workaround by alternately generating/deleting a dummy texture name on each _render_target_clear. Going to test it while upstream decides what to do.

from godot_openvr.

Hmm, very strange.

By default Godot will create a render buffer for the main window based on the size of the window, the ARVR server will override this creation and recreate a new texture at the resolution the HMD has asked for.

Now if the window resizes Godots default logic will run again which could indeed delete our render buffer and recreate one at the new required size, which subsequently will be tossed a way and replaced again the next frame the HMD renders. This is a bit of a flip flow between Godot wanting to be a desktop rendered game and us wanting to render on the HMD.

While wasteful it shouldn't lead to an unreliable texture freezing rendering.

If this is indeed the problem then there is a simple work around. Instead of turning the main viewports ARVR mode on, create a custom viewport in your scene, make sure the ARVROrigin node and everything underneath is a child and turn this into your ARVR viewport. DO make sure to set this viewport up correctly, it has to have a default size (for some reason the internal logic ignores viewports with the size of 0,0) and that its update mode is set to always.

You're then free to render whatever you like to the main viewport.
I did do a video on the setup awhile ago: https://youtu.be/07euJhZbeSc

At the very least its worth the exercise to see if it resolves the freeze.

from godot_openvr.