search

ValveSoftware / SteamVR-for-Linux

Issue tracker for the Linux port of SteamVR
916 stars 45 forks source link

Tracking not smooth and a little delayed. #21

Open leinardi opened 7 years ago

leinardi commented 7 years ago

Your system information

Please describe your issue in as much detail as possible:

When you move your head around it is noticeable that the tracking of the HMD is somehow delayed and not smooth. This is especially clear if you have tried SteamVR for Windows before. Also the tracking of the Controllers seems to have the same issue: it looks like the position is being interpolated/approximated and the movement isn't smooth and instantaneous like on Windows.

This issue is really annoying for the HMD because it makes the experience really unpleasant and, after a while, nauseating.

This happens with any linear combination of AsyncReprojection and AllowReprojection (both on, both off, only one of them on).

It is most noticeable while playing some game like Destinations or SteamVR Tutorial but, to me, it is also clear inside the SteamVR environment.

Steps for reproducing this issue:

  1. Start SteamVR
  2. Look around and focus your attention on static items like the chaperone bounds
  3. Start Destinations or SteamVR Tutorial
  4. Repeat step 2
odensc commented 7 years ago

Can confirm, the controllers have ghosting as if they're interpolated. Also the headset movement is delayed, which makes me sick after a few minutes. It's like the world moves around you, instead of you moving around the world.

Plagman commented 7 years ago

Performance and latency aren't currently expected to be optimal when a VR application is running, but should be comparable to the Windows version in the default SteamVR environmnent. Is anyone seeing subpar performance when no application is running?

odensc commented 7 years ago

@Plagman The SteamVR environment works great - it's a night and day difference vs the tutorial.

leinardi commented 7 years ago

@Plagman I first noticed the issue in the SteamVR environmnent, from the first time I started it. Isn't obvious as in Destinations or SteamVR Tutorial because is mostly an empty space but, if I turn my head looking at the chaperone or a lighthouse, I feel that something is wrong.

serk7 commented 7 years ago

yes, at steamvr enviorement works correctly, it's when a application is running that delay appear, as more consuming more delay. At serious sam i have a huge delay at tracking, more than tutorial.

aronschatz commented 7 years ago

@Plagman I can confirm this is happening on my system, too. The tracking is noticeably slower (or it is my perception as slower). I've noticed this delay in the SteamVR environment from time to time, too... But it happens in every application, period.

serk7 commented 7 years ago

I tried updating my kernel to last 4.9 and disabling desktop effects on kde, but still the same.

kkriehl commented 7 years ago

@Plagman I can confirm the tracking inertia. It appears in every application (including really simple Unity scenes) except the empty default environment of SteamVR. After loading a custom 3D obj-based SteamVR environment (for example the Rick and Morty garage) the latency get's noticeable there, too. ~Since the delay seems to be the same everywhere, I guess that it is not dependend on the application performance itself and maybe lies somewhere in the tracking data pipeline.~ The latency is not present in the display mirror (Chaperone grid and Unity scenes move synchronously and align perfectly) and only inside the HMD. Also, the Chaperone bounds are never lagging. This feels similar to the the latency problem with UE 4.12.

aronschatz commented 7 years ago

The March 6th build of SteamVR makes this much worse for me. I'm running the .13 Nvidia driver, too. Now, the steamVR environment really shows this much worse.

aronschatz commented 7 years ago

The March 10th build seems to be moving in the right direction. The SteamVR environment still lags (noticeable when moving your head up and down, less so when right to left, but it is much better than before.

ghost commented 7 years ago

I'm noticing this with the March 16 build as well, especially if you stand still and wiggle your head a little -- the delay is considerable enough to generate nausea (in the StemVR environment). In the SteamVR tutorial, the delay is exaggerated even more so. Running Ubuntu 16.10 x64, Nvidia GTX 980ti w/ 375.27.13 Vulkan proprietary drivers, Unity 7.5.0 desktop environment, Linux kernel 4.8.0-39-generic.

thestr4ng3r commented 6 years ago

I still experience this issue. Performance seems fine, but everything is noticeably delayed. Running Linux Mint 18.2 (based on Ubuntu 16.04) with Cinnamon, NVIDIA Driver 384.69 with a GTX 1080.

The delay happens everywhere including chaperone bounds, SteamVR Home and the standard SteamVR environment.

leinardi commented 6 years ago

@Plagman Any news on this issue? it's been 7 months already :'(

VantageVR commented 6 years ago

@Plagman I've recently tried to get SteamVR working on my Linux machine and have been experiencing the same issues as described above: the SteamVR tutorial is nauseating (only the default VR environment is smooth). Some details about my machine: Ubuntu 17.04, Quadro P4000 graphics with NVIDIA 387.34, SteamVR [beta]. I also have a Windows machine running SteamVR which does not have this problem. There I noticed that the GPU frame timing is ~5ms while on my Linux machine it is ~13ms. Maybe this points to the issue.
Any help would be much appreciated! Thanks.

phiresky commented 6 years ago

Same problem here. Nvidia 396.54 (GTX 980 Ti Strix). SteamVR Build Aug. 7, 2018 at 19:52 Version 1533664367 on Arch Linux (kernel 4.18.5-arch1-1-ARCH). Basically unusable without getting a headache within 5 minutes. No issues on the Windows version.

Vash63 commented 5 years ago

I can no longer reproduce this for quite some time now.

thestr4ng3r commented 5 years ago

No, the issue is still present. Since my last comment, I have switched distribution, used many different nvidia driver and SteamVR versions, but not a single time I did not experience a delay in tracking. And since everything is proprietary and closed source I see no way to debug this myself. Here is a system report from SteamVR: SteamVR-2019-01-15-_09_49_59.txt I could imagine many users wouldn't even notice the delay, but it is definitely there and makes SteamVR absolutely unusable.

JustHereForThisOneThing commented 5 years ago

SteamVR user for two years on Windows. Finally took the plunge and installed it on Ubuntu 18.04. I immediately noticed what felt like a full frame of latency vs. the Windows experience I'm very used to.

CPU: Ryzen 7 2700x GPU: RTX 2080 ( 410.57 )

I'm not on the Beta branch, but the entire Ubuntu/Steam/SteamVR/Nvidia installation is entirely new from this weekend. My timing graph stays flat at 6-7ms, with plenty of headroom. It's just a persistent, tiny delay at the beginning and end of every head movement that isn't present in Windows and seems unrelated to actual performance.

Pyrarrows commented 5 years ago

Same issue here as well, after some time head movement will have a slight delay which is extremely uncomfortable. CPU: Ryzen 7 1700 GPU: RX Vega 64 Kernel 5.0.2-steamvr-generic Currently on Steam Beta Branch & SteamVR Beta Branch

Vash63 commented 4 years ago

Update to this, now that the tearing bug is fixed ( #196 ) I can once again reproduce this. It seems whatever was done to fix the tearing (vsync?) brought back the latency. This is with an Nvidia 2080 and the drivers that fixed the gsync tearing, 435.27.07

tizzir commented 4 years ago

I have also noticed this regression, although in my case it appears to be from upgrading from NVIDIA drivers 440.36 to 440.44, which also fixed the gsync/steamvr combo tearing, albeit in a different driver branch, if I understand correctly.

From what I remember, when I was experiencing tearing in the headset with the previous driver, the portion of the screen above the tear seemed to occasionally have the same level of latency as I experience with the newest driver, but the portion below the tear always had latency on the same level of Windows (that is, noticeably lower latency). I'm not sure why this would be though, especially if frames are being rendered from the top of the screen downward...

I have also noticed that I can make the latency go away for a bit by opening the SteamVR dashboard or causing frame drops in the VR application. But every new frame drop has a chance to reintroduce the latency again.

Vash63 commented 4 years ago

I noticed the exact same symptom regarding the tear where the area below the tear was very responsive and fast. I'm also seeing something similar where sometimes the latency is better than others, seems to come and go between SteamVR boots or opening and closing applications, even with the same applications.

edwin-v commented 4 years ago

Any news on this one? It still happens in now with 1.10.21 and the 440.59 driver and it makes VR completely unusable.

Edit: it does still seem to be fixed by turning off gsync.

TreeOnFire commented 4 years ago

Ran into this issue using the following: Pop!_OS 20.04 LTS, SteamVR 1.13.10, GTX 1080Ti (driver 440.100).

Switching to 120Hz has stopped there being a visual delay between movement and display, (original being 90Hz).

tizzir commented 4 years ago

@edwin-v Unfortunately, I don't seem to observe the same behaviour. I get the roughly the same amount of latency increases whether or not I have Allow G-SYNC/G-SYNC Compatible enabled in the Nvidia control panel.

duckbytes commented 3 years ago

Sorry to bump an old topic. Are there any updates at all for this problem? Proton works so well now that I'd be so glad to play VR on Linux but the latency is headache inducing. It appears like any fixes posted in this thread are nvidia specific.

I'm on up to date Arch with kernel 5.9.1-zen2-1-zen #1 ZEN SMP PREEMPT Sun, 18 Oct 2020 02:45:20 +0000 x86_64 GNU/Linux mesa 20.2.1-1 5700XT gpu 3700X cpu

tizzir commented 3 years ago

No updates as far as I'm aware. I'm still hoping for a fix at some point... Or at least a better idea of what's causing the issue. Even with a Nvidia card I haven't had any luck with fixes mentioned here on recent drivers, except for being able to temporarily fix the latency issue by inducing a frame drop (such as by opening the SteamVR menu in-game.)

With this temporary fix, games like Beat Saber become quite playable. I can play multiple levels before I see any latency issues, and when I do, I just open and close the SteamVR menu.

Games like Hot Dogs, Horseshoes, and Hand Grenades have more frequent frame drops on my GTX 1070, however, so I'm required to open and close the SteamVR menu fairly frequently to mitigate latency issues that occur.

Overall, the latency is less of a deal breaker for me, and more of a mild annoyance.

duckbytes commented 3 years ago

That's interesting it can be fixed by opening the menu. For me the latency is there from the beginning and is fairly consistent. It's there in the default SteamVR environment and doesn't seem to change regardless of what I run.

duckbytes commented 3 years ago

I tried out the beta version 1.15.6 today and the problem seems to be a lot worse for overlays. The dashboard or xrdesktop windows seem to lag by half a second behind head movements. It looks very weird with everything seeming to wobble around in your vision. Overlays also stutter a lot when moving your head.

Games however aren't too affected. They still lag only a little like before.

ChristophHaag commented 3 years ago

That sounds like #395

sheepzero51 commented 3 years ago

Query: How is this still a problem. This post was made like 4 years ago and there is still no solution. I'm getting sick of arguing Linux to my friends and them responding with this exact issue. Joking aside I cannot stand windows in the slightest and Im getting tired of looking at the vive in the corner of my room sitting unused for like 3 years. If anyone has any idea in the slightest of how this could be resolved, please come up with an answer.

questionsdonkey commented 3 years ago

Major contributor to this issue seems to be the global lock on hidraw devices in the kernel, specifically this mutex.

Patching this so that the lock is non-global (per-device basis) dropped my latency significantly (~50 - ~15 ms)

Atemu commented 3 years ago

@questionsdonkey do you have a patch you could share?

questionsdonkey commented 3 years ago

@questionsdonkey do you have a patch you could share?

Here's the diff for drivers/hid/hidraw.c.

This is for 5.8.0:

@@ -27,6 +27,7 @@
 #include <linux/mutex.h>
 #include <linux/sched/signal.h>
 #include <linux/string.h>
+#include <linux/mm.h>

 #include <linux/hidraw.h>

@@ -34,7 +35,7 @@
 static struct cdev hidraw_cdev;
 static struct class *hidraw_class;
 static struct hidraw *hidraw_table[HIDRAW_MAX_DEVICES];
-static DEFINE_MUTEX(minors_lock);
+static struct mutex* minors_locks;

 static ssize_t hidraw_read(struct file *file, char __user *buffer, size_t count, loff_t *ppos)
 {
@@ -107,7 +108,7 @@
    __u8 *buf;
    int ret = 0;

-   lockdep_assert_held(&minors_lock);
+   lockdep_assert_held(minors_locks + minor);

    if (!hidraw_table[minor] || !hidraw_table[minor]->exist) {
        ret = -ENODEV;
@@ -159,10 +160,11 @@

 static ssize_t hidraw_write(struct file *file, const char __user *buffer, size_t count, loff_t *ppos)
 {
+   unsigned int minor = iminor(file_inode(file));
    ssize_t ret;
-   mutex_lock(&minors_lock);
+   mutex_lock(minors_locks + minor);
    ret = hidraw_send_report(file, buffer, count, HID_OUTPUT_REPORT);
-   mutex_unlock(&minors_lock);
+   mutex_unlock(minors_locks + minor);
    return ret;
 }

@@ -182,7 +184,7 @@
    int ret = 0, len;
    unsigned char report_number;

-   lockdep_assert_held(&minors_lock);
+   lockdep_assert_held(minors_locks + minor);

    if (!hidraw_table[minor] || !hidraw_table[minor]->exist) {
        ret = -ENODEV;
@@ -272,7 +274,7 @@
        goto out;
    }

-   mutex_lock(&minors_lock);
+   mutex_lock(minors_locks + minor);
    if (!hidraw_table[minor] || !hidraw_table[minor]->exist) {
        err = -ENODEV;
        goto out_unlock;
@@ -301,7 +303,7 @@
    spin_unlock_irqrestore(&hidraw_table[minor]->list_lock, flags);
    file->private_data = list;
 out_unlock:
-   mutex_unlock(&minors_lock);
+   mutex_unlock(minors_locks + minor);
 out:
    if (err < 0)
        kfree(list);
@@ -347,7 +349,7 @@
    struct hidraw_list *list = file->private_data;
    unsigned long flags;

-   mutex_lock(&minors_lock);
+   mutex_lock(minors_locks + minor);

    spin_lock_irqsave(&hidraw_table[minor]->list_lock, flags);
    list_del(&list->node);
@@ -356,7 +358,7 @@

    drop_ref(hidraw_table[minor], 0);

-   mutex_unlock(&minors_lock);
+   mutex_unlock(minors_locks + minor);
    return 0;
 }

@@ -369,7 +371,7 @@
    struct hidraw *dev;
    void __user *user_arg = (void __user*) arg;

-   mutex_lock(&minors_lock);
+   mutex_lock(minors_locks + minor);
    dev = hidraw_table[minor];
    if (!dev || !dev->exist) {
        ret = -ENODEV;
@@ -465,7 +467,7 @@
        ret = -ENOTTY;
    }
 out:
-   mutex_unlock(&minors_lock);
+   mutex_unlock(minors_locks + minor);
    return ret;
 }

@@ -524,18 +526,21 @@

    result = -EINVAL;

-   mutex_lock(&minors_lock);
-
    for (minor = 0; minor < HIDRAW_MAX_DEVICES; minor++) {
+       mutex_lock(minors_locks + minor);
+
        if (hidraw_table[minor])
+       {
+           mutex_unlock(minors_locks + minor);
            continue;
+       }
+
        hidraw_table[minor] = dev;
        result = 0;
        break;
    }

    if (result) {
-       mutex_unlock(&minors_lock);
        kfree(dev);
        goto out;
    }
@@ -545,7 +550,7 @@

    if (IS_ERR(dev->dev)) {
        hidraw_table[minor] = NULL;
-       mutex_unlock(&minors_lock);
+       mutex_unlock(minors_locks + minor);
        result = PTR_ERR(dev->dev);
        kfree(dev);
        goto out;
@@ -561,7 +566,7 @@
    dev->exist = 1;
    hid->hidraw = dev;

-   mutex_unlock(&minors_lock);
+   mutex_unlock(minors_locks + minor);
 out:
    return result;

@@ -572,16 +577,17 @@
 {
    struct hidraw *hidraw = hid->hidraw;

-   mutex_lock(&minors_lock);
+   mutex_lock(minors_locks + hidraw->minor);

    drop_ref(hidraw, 1);

-   mutex_unlock(&minors_lock);
+   mutex_unlock(minors_locks + hidraw->minor);
 }
 EXPORT_SYMBOL_GPL(hidraw_disconnect);

 int __init hidraw_init(void)
 {
+   unsigned i;
    int result;
    dev_t dev_id;

@@ -605,6 +611,13 @@
    if (result < 0)
        goto error_class;

+   minors_locks = kmalloc(sizeof(struct mutex) * HIDRAW_MAX_DEVICES, GFP_KERNEL);
+   if (minors_locks == NULL)
+       goto error_class;
+
+   for (i = 0; i < HIDRAW_MAX_DEVICES; i++)
+       mutex_init(minors_locks + i);
+
    pr_info("raw HID events driver (C) Jiri Kosina\n");
 out:
    return result;
@@ -624,4 +637,5 @@
    class_destroy(hidraw_class);
    unregister_chrdev_region(dev_id, HIDRAW_MAX_DEVICES);

+   kvfree(minors_locks);
 }
charleslvalve commented 3 years ago

This is very interesting. Though many users are having issues unrelated to this, I was unaware of this specific possibility. I am very curious how you came to find this flaw in the kernel. That said - I am curious what we can do to mitigate the issue. @questionsdonkey if you have a good handle on which function call into hidraw is the one that's the primary offender, we can see if we can split that out into a different thread...

That said, it seems that the mutex is not involved in hidraw_read but if you have already done the profiling to identify the entry that would be very helpful. Considering we use hidapi, the issue may be confounded.

dsalt commented 3 years ago

@questionsdonkey – you should use diff -u, and you probably want to use

kmalloc_array(HIDRAW_MAX_DEVICES, sizeof(struct mutex), GFP_KERNEL)

– yes, it's safe as is, but this way has better self-documentation.

questionsdonkey commented 3 years ago

This is very interesting. Though many users are having issues unrelated to this, I was unaware of this specific possibility. I am very curious how you came to find this flaw in the kernel. That said - I am curious what we can do to mitigate the issue. @questionsdonkey if you have a good handle on which function call into hidraw is the one that's the primary offender, we can see if we can split that out into a different thread...

That said, it seems that the mutex is not involved in hidraw_read but if you have already done the profiling to identify the entry that would be very helpful. Considering we use hidapi, the issue may be confounded.

There are two ioctl calls that will block in the kernel while acquiring minors_lock: HIDIOCGFEATURE and HIDIOCSFEATURE

You're likely correct in assuming that hidraw_read uses a separate mutex.

There may also be other locks being held in the underlying HID driver.

@questionsdonkey – you should use diff -u, and you probably want to use

kmalloc_array(HIDRAW_MAX_DEVICES, sizeof(struct mutex), GFP_KERNEL)

– yes, it's safe as is, but this way has better self-documentation.

I've updated my previous comment with a diff in unified format.

charleslvalve commented 3 years ago

Specifically, @questionsdonkey I was wondering what mechanisms I could use to see if there was anything we can do on the SteamVR side to reduce the impact of this mutex. We are unsure what would cause the feature get/set in the same thread as the system which takes on lighthouse, IMU data and input.

Does the HIDIOCGFEATURE and HIDIOCSFEATURE also block the user thread doing hidraw_read

A huge help may be if you can give us the contents of the offending HIDIOCGFEATURE and HIDIOCSFEATURE calls? Also if you can send a system report from a system that's suffering from performance that would be a massive help.

kedodrill commented 3 years ago

@questionsdonkey just wanting to mention you here on this issue, did you end up giving more info to @charleslvalve through somewhere else? I don't understand the specifics beyond you found something beneficial to change in the kernel for steamvr, but if I could help test in some way, I've got a Valve Index along with a Ryzen 5 1600 and an RX 5700.

FlpDaMattress commented 3 years ago

I hope I'm not throwing everyone a red herring but I'm having this same issue on Manjaro with an AMD Radeon RX580 with my HTC Vive.

KDE Plasma version: 5.21.5 Kernal version: 5.12.9-1-MANJARO SteamVR build ID: 6834725 Steam Proton: Proton 6.3-4 (not that it matters, latency was so bad I couldn't even open a game without getting super nauseous after less than a minute)

Also probably worth mentioning the OpenGL 2.0 and 3.1 compositors stopped working until SteamVR was closed. I've tried a few kernels but get the same result.

tizzir commented 3 years ago

Anyone having luck with SteamVR 1.18.2? I played some Beat Saber and some H3VR today and didn't encounter a single case where the latency would noticeably raise (other than the occasional frame drop, unrelated to this issue.) Can anyone reproduce this behavior? I'm not 100% confident that I didn't just have really good luck with SteamVR today.

The changelog for 1.18.2 contain the following line under the Linux subheading:

Enable async-reprojection on compatible nvidia 470 series drivers

It would be funny if this solved the issue considering the 470 series driver isn't even available at the time of writing, but it's possible that this might have had unintended benefits to the current series of NVidia driver as well.

duckbytes commented 3 years ago

@tizzir

I gave it a try but didn't notice any improvement on my side. #395 also seems to still be there.

@questionsdonkey do you have a patch you could share?

Here's the diff for drivers/hid/hidraw.c.

This is for 5.8.0:

...

Is it worth actually submitting this patch to the Linux kernel? Are there any downsides to using this patch?

RinLovesYou commented 3 years ago

I believe i've found a solution from the most unlikely of places. Please excuse me if i get things wrong, i'm still a fairly new linux user.

Earlier today i was trying out steamvr and noticed the mentioned latency issues which became very apparent (and sickening) when moving.

I stopped playing beatsaber as i was dying of heatstroke with this heatwave and went to learn how to use my midi keyboard.

I was following a post about playing with midi devices, and one thing that was mentioned is running the kernel in low latency mode to play in realtime

sudo apt install ubuntustudio-audio linux-lowlatency seemed to have patched my kernel to run in low latency mode, and ever since then my steamvr has been running way smoother.

this seems to be ubuntu-only but i'm sure users of different flavors of linux could research into how to run the kernel in low latency mode

tizzir commented 3 years ago

Interesting find about the low latency kernel, @RinLovesYou. I'm not using Ubuntu, so I can't test that exact kernel, but I can attest that using a kernel I compiled with TKG to have quite a few latency optimization for gaming doesn't help the issue for me.

After doing some more "testing" (IE playing some Beat Saber and No Man's Sky) in VR today, it seems that the occurrence of latency increases has been significantly reduced, with SteamVR 1.18.2 but not completely eliminated. I still ran into a few times where latency would jump up and stay up until I opened the SteamVR overlay.

Speaking of which, now that Nvidia GPUs support asynchronous reprojection using the 470 series dirver, I encountered #395 for the first time. You win some, you lose some I guess :smile:

EDIT: I think the latency issue that I'm encountering might actually be #227. It seems to line up with my experience of a temporary performance blip causing increased latency until there's another performance blip (such as from opening the SteamVR overlay.)

Atemu commented 3 years ago

Something I've noticed with SteamVR on Windows is that async/legacy reprojection seems to have a noticable latency impact. It's subtle but I can immediately feel the difference and I am significantly better at the game when async reprojection on in BS.

If async reprojection isn't working right on Linux (as I suspect is the case for me, probably due to external issues), that could be another factor.

smirgol commented 3 years ago

I'm also experiencing delayed tracking when I started SteamVR (beta) and am in that start screen. I did not have this all the time, but it started a couple of months ago and it is really irritating. Interestingly, yesterday I switched from 90 Hz to 120 Hz just to see if this would improve things, and actually the delay is pretty much gone at that setting. Of course I hardly can render stuff at 120fps, but overall it's a better experience. Not sure why it's so bad at 90 Hz.

atavener commented 3 years ago

Thanks @RinLovesYou! I have been struggling with SteamVR, and mostly avoiding it, for years. One of the major persistent issues has been like a hitching of the view, but not quite. No CPU/GPU spikes (after CPU profile is set to "performance"), yet moving my head gently would always have some subtle perceptual lag and a jarring snap at roughly 1s intervals which seemed to be two frames of overshoot then undershoot. Whether it was a super simple SteamVR Home scene, or HalfLife:Alyx. Smooth rendering, but my head motion was "rough, with jank".

I originally installed Ubuntu 18 on this machine because it was the "recommended"/baseline system people were supposedly testing against. This is the first time I've read mention of installing a lowlatency kernel. And it worked -- my head motion feels smooth now. Still not perfect, but so much better: playable! Maybe the lowlatency configuration is just helping to hide the underlying issue though. And I had a system crash, within about an hour of play... can't remember the last time that happened. Hopefully not related and doesn't recur. I'll see...

Vash63 commented 3 years ago

Replying to https://github.com/ValveSoftware/SteamVR-for-Linux/issues/21#issuecomment-873119408

If you're on Nvidia make sure you are using the 470 series drivers. If you're on AMD make sure it shows Async reprojection enabled. The 470 drivers fixed everything for me except for the in-game overlay latency wise.

duckbytes commented 3 years ago

I decided to compare with linux-rt 5.11.4 but I honestly can't see any improvement. I did notice my framerates were a bit poorer going from linux-zen. For myself I still get the best experience with zen, but this issue still exists on both kernels as far as I can tell.

I tested with async reprojection off because of it being broken currently.

jessiehildebrandt commented 3 years ago

I've recently done some testing with the approaches that people have been sharing for combating this latency issue.

Approaches that I tested:

I ran these tests on a system with a Ryzen 7 1700 (16GB RAM) and RX 480 (8GB), running off of a completely fresh install of Ubuntu 21.04.

Notes from testing:

Refresh Rate SteamVR Home Neos VR
90Hz 90 FPS 45 FPS
120Hz 120 FPS 60 FPS
144Hz 144 FPS 72 FPS

Observations:

The tracking latency on my system seems to be inversely correlated with pre-reprojection frame rate.

I'd be interested in hearing from any of the nVidia users who can now benefit from async reprojection to see if they are also experiencing a broken SteamVR overlay with it enabled.

Misc. Notes:

Leaving these here for anyone else who might be debugging their Linux VR setup in general: