Forum Discussion
SDK/Runtime 1.3.0, DK2 low persistence issue
I've been running this past week on runtime/SDK 1.3.0, with everything working peachy. Today, however, I made the mistake of having Blender open at the same time as I started a VR app. This caused the NVIDIA display driver to crash with an OpenGL error, my system to chug, then spontaneously reboot (probably worth passing that along to the NVIDIA guys).
After reboot and making sure nothing system-wise got hosed, I noticed that my HMD VR display is acting very very suspiciously like low persistence has somehow been turned off (i.e. the prototypical dark area ghosting with movement). This is happening in all applications (not just my project, in Lucky's Tale, TinyRoom demo, etc.), and even while hitting a solid 75Hz. I've tried re-installing the latest NVIDIA driver, but the issue persists. I have a feeling my graphics driver crash has somehow corrupted/reset the low persistence mode on the HMD.
Unfortunately, with SDK 1.3.0, since ovr_SetEnabledCaps has been removed, there's no way to programatically (re)set low persistence. I dug around in the registry, but didn't find anything obvious there either.
The obvious next step is to completely uninstall and reinstall the runtime/hardware, but before I go through the pain of the setup download process again (standalone runtime package please!), I wanted to see if anyone else has had this issue.
And, from the Oculus side, any suggestions on how to reset this aside from the full reinstall?
After reboot and making sure nothing system-wise got hosed, I noticed that my HMD VR display is acting very very suspiciously like low persistence has somehow been turned off (i.e. the prototypical dark area ghosting with movement). This is happening in all applications (not just my project, in Lucky's Tale, TinyRoom demo, etc.), and even while hitting a solid 75Hz. I've tried re-installing the latest NVIDIA driver, but the issue persists. I have a feeling my graphics driver crash has somehow corrupted/reset the low persistence mode on the HMD.
Unfortunately, with SDK 1.3.0, since ovr_SetEnabledCaps has been removed, there's no way to programatically (re)set low persistence. I dug around in the registry, but didn't find anything obvious there either.
The obvious next step is to completely uninstall and reinstall the runtime/hardware, but before I go through the pain of the setup download process again (standalone runtime package please!), I wanted to see if anyone else has had this issue.
And, from the Oculus side, any suggestions on how to reset this aside from the full reinstall?
7 Replies
- I went ahead and uninstalled and re-installed the Oculus HW (DK2) and runtime. Unfortunately, the issue persists. I'm...not too sure what to try next.
In addition to the ~2 hours it took for the setup to re-download, uninstalling removes all downloaded apps as well. That is extremely inconvenient. In combination/addition to the standalone runtime installer, it would be great to have an option to reinstall the service/drivers without nuking everything. - Maybe try to reinstall 0.8 or use the runtime switcher and then try ovr_SetEnabledCaps?
- I found a runtime switcher and attempted to use the 0.6.0.1 runtime (the last SDK I have available that allowed changing the persistence cap). Unfortunately, that runtime doesn't seem to recognize the HMD being plugged in (config util says it's not plugged in, check HDMI connection). I suppose that's not completely surprising, as that runtime may not be entirely compatible with the latest NVIDIA driver, given that it had extended mode support and the latest NVIDIA driver/Gameworks VR SDK (which the 0.6 runtime doesn't use, IIRC) removes that usage.
I'm loathe to start reverting my system back a half a year of graphics drivers to try and sort this out, so I suppose I'll go ahead and wait to see what the Oculus folks have to say before I flail any further. Hopefully there's a way we can check and/or reset this without these extreme config contortions. Obviously, the hardware capability for switching on/off the low persistence hasn't gone away (and thus it's conceivable that it somehow got flipped by that driver crash), so here's hoping for a somewhat less painful solution.
Of course, I'm open to other ideas as to what might be causing the issue I described, but it sure behaves like the low persistence got flipped off. - Im thinking of installing the older runtime on a different PC, and using that to set IPD, etc. Perhaps there is more information stored on the DK2 then we realize? Seems unlikely but meh..
- Just refreshing this since I was off the grid these past two weeks. Oculus guys, any thoughts on how to check and/or resolve this without reverting my system to a 0.6.0.1-runtime-capable and graphics driver state?
- I went ahead and bit the bullet and put my system into a 0.6.0.1-capable state. I went the whole nine yards, uninstalling the latest runtime completely, rolled back to an NVIDIA driver from ~9 months ago, then installed the 0.6.0.1 runtime. The older driver did allow me to run again with the older runtime, and I was able to run TinyRoom from the old SDK samples. With the older runtime and SDK available, I was able to use ovr_SetEnabledCaps to try toggling low persistence (simply by modifying TinyRoom).
The good news is that the low persistence toggling definitely had an effect. As expected, disabling low persistence made things something of a (much worse) blurry mess with head movement. The bad news is that with low persistence (re)enabled I saw the same dark area ghosting into light area issue I was previously experiencing. Not anything near as bad as with low persistence explicitly disabled, but it's no improvement on my initially observed issue. So, it would appear that the exposed binary low persistence toggle was not the issue.
Having experimented with that, I uninstalled the 0.6.0.1 runtime, re-installed the current NVIDIA driver, and re-installed the latest Oculus runtime. Unsurprisingly, the issue persists.
So, I'm somewhat back to square one.
Any thoughts on what to check? Is it possible that original graphics driver crash might have actually done some damage to the DK2? - I've finally been able to test my DK2 on another (fully spec compliant) machine, and unfortunately the issue is still present. So, clearly this is not a software or system configuration issue, but rather something that has gone sideways on the HMD itself. I attempted to get a video capture via phone-to-headset to show the problem, but refresh-vs-capture rate + even a little camera movement makes it impossible to see clearly.
So, any thoughts on anything further to try and resolve this (including getting down and dirty interfacing at a lower level with the HMD to do diagnostics, etc.)?
Obviously I can open a normal support ticket, but I'm presuming DK2 support at this point is basically in the realm of "bummer, that sucks".
