This effect is more pronounced on Monado and variable on SteamVR.
Reproduction is simple, run any app which could be as simple as xrgears, on the Monado runtime with a headset like a valve index and the effect will immediate present as a delayed viewport almost like the contents are being double composited. A VR headset MUST be used to visualize the effect.
Make sure to enable the Monado compute compositor and select the proper steamvr_lh driver if using a Valve lighthouse type headset:
STEAMVR_LH_ENABLE=true
XRT_COMPOSITOR_COMPUTE=true
All display managers, all graphics APIs, all apps, any nvidia kernel module, any combination of kernel parameters.
It is most uncomfortable for even short term usage and is only present on Nvidia proprietary userland. Nouveau, AMD, Intel, all feel fine for simple low-load usage in comparison.
Some users have partial success in delaying the composition using U_PACING_COMP_MIN_TIME_MS to reduce the effect but it is quite far from a cure, just improves comfort modestly when set to about 10.
This bug currently runs back as far as the 550 driver as far as we can tell and is present in the latest releases.
options nvidia NVreg_RegistryDwords=RMLockingMode=1 was used in an attempt to resolve the issue alongside setting the CPU gov to performance state.
Some mild stutter under extreme loads was improved but the visual swim or drag was still present with seemingly no effect on it, the sensation like the lease is being double composited.
SteamVR appears to variably swim while monado seems to be fairly consistent in how it wobbles and the U_PACING_COMP_MIN_TIME_MS=10 env var on monado appears to move the sensation from maximally sickening to mildly sickening. Substantial improvement from there reported, when user switched to AMD.
A secondary issue worthy of mentioning is some people with VRR capable monitors enabled and working appear to experience tearing in HMD while VRR is active in kernel or in userspace. Disabling VRR at any of these stages prevents the tearing in the HMD.
After more review of member testing it likely is not a regression in Monado and more likely to be an issue in the Nvidia driver itself.
One member reports that their HMD operates with no visual drag while another reports pretty obvious drag in the view. Included are the display configuration EDID pulled from KDE. The “broken” config presenting the issue is taken after they switched to AMD to alleviate the issue but still wanted to provide their info in case it would help.
Ignore the empty valve index EDID on the working config, it does that on initial boot and a replug of the device solves, unrelated issue.
For the time being I have patched monado to use VK_PRESENT_MODE_IMMEDIATE_KHR which seems to “fix” the latency issue at the cost of having tearing in VR with the tearline staying mostly out of my view (better than getting motion sickness…)
Now the question is why there are latency problems with the other presentation modes but not immediate mode. I can think it’s either one of:
Somehow we get a swapchain that is one frame too long (would be consistent with ~11 ms delay I experience)
It’s not the swapchain something about vblank timestamps from the driver that somehow throws the pacing off significantly.
FWIW my patch is available here.
Start Monado with XRT_PRESENT_MODE=0
Hello, I did some extensive testing and comparison of NVIDIA and AMD regarding latency. I’m observing that VR headset latency on NVIDIA varies slightly between launches, but consistently introduces at least a single frame of delay beyond what should be (try running the headset at 90Hz to notice it more easily by setting the XRT_PRESENT_MODE=0 environment variable in Monado). The best way to test this is to shake your head, which will introduce a “wobble effect”, causing diziness. In the Monado Debug GUI, within the “Timing” card, there’s a “Present to display offset (ms)” slider. I’ve found that setting this to 20ms or 30ms (this value varies between launches) slightly mitigates the issue. Finally, I’ve noticed that there is a screen tearing present only when a second DisplayPort monitor is connected (even with VRR disabled), but not when using HDMI (!).
Renewed issue summary, this issue appears to be unconditional but a few things have masked general awareness of it being:
It presents as less severe the higher the refresh of the HMD, often lowering to 90Hz or below is enough to exacerbate it to see very plainly visible almost every time.
Debug and testing requires you make yourself sick with visuals for testing, few have interest in doing so.
It’s notably random in how much delay gets applied to the HMD, all users were reporting random values being helpful or sometimes none at all because a random amount of offset is needed for comfort each time the XR session is run.
Some users are simply more resistant to poor visuals and self reporting of the issue with these people included made it very hard to identify and some users having a large brick tied to their face would simply move their head less and not see it. Most simply quietly endure the issue.
However the issue remains,
Setting 90Hz on the HMD refresh and shaking your head violently left to right or in a circle should show the wobble plainly. Everything is affected and the wobble degree is randomized each session start but everything, everywhere, is affected.
It’s completely independent of the display surfaces plugged into the GPU doing other things and RMLockingMode is not of help for this.
Best we can tell this started to become an issue on driver 440. Quite a while back now… Old reports that 435 was fine for task.
And yes I believe this is important to the issue it appears as if some kind of double buffering is occurring as using immediate vulkan presentation mode which allows for tearing completely works around the problem, in exchange for the leased display tearing instead of wobbling!
After even further testing, the at runtime latency is variable!
The drag felt in the HMD routinely shifts at runtime and should change after just a few minutes of use-time. Give this a try for reproduction if you do not notice it on first glance wait a few minutes to see it.
I believe that wobble effect is a Monado bug. It’s due to missing distortion compensation for the rolling shutter effect of the Vive Pro. That issue is unrelated to the latency problem, and should be happening on AMD as well. Making sure you're not a bot!
Meanwhile I would expect it to not be present in SteamVR.
Re: screen tearing, it is to be always expected if you use my hack with XRT_PRESENT_MODE=0, since that essentially disables vsync. I only use it because I’d rather have tearing than latency.
There does exist a separate bug though with VRR which will cause tearing in the leased display even when requesting a non-tearing presentation mode such as FIFO.
Anyway this is the wrong thread for both of these bugs, this thread is about the excessive latency when using SteamVR or Monado (the latency problem presents in basically the same way in both).
Yes, this matches my experience too. This is especially noticeable in SteamVR, as opening the SteamVR dashboard tends to reset the latency for whatever reason, so you will be fine for a minute or so before the latency starts becoming really terrible again.