Tracking not smooth and a little delayed.

[leinardi]

Your system information

• Steam client version (build number or date): 1487812945
• Distribution (e.g. Ubuntu): Ubuntu 16.10 (64 bit)
• Graphics driver version (run nvidia-settings): 4.5.0 NVIDIA 375.27.10
• Gist for SteamVR System Information: https://gist.github.com/leinardi/92f4ce3e986209d752c383791c16ef08
• Gist for Steam System Information: https://gist.github.com/leinardi/7f9cc3f021a3ef546a884260b8a14f78
• Opted into Steam client beta?: Yes
• Opted into SteamVR beta?: Yes
• Have you checked for system updates?: Yes

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

[Vash63]

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.

I'm on Nvidia and can confirm that in games the latency seems OK but the overlay is completely unusable and gives me a headache if I move my head too much with it on. The overlay seems to have many frames of delay. I did not try disabling async reprojection.

[ParzivalWolfram]

Latency issues here as well, not massive but definitely enough to cause nausea. Running an RX 5500XT, latency graph shows ~1.3ms constant in the empty skybox generated when nothing's running, but it still happens. Using Mesa 20.3.5, SteamVR 1.18.7, kernel 5.10.0-8 on Debian. Running PipeWire so that audio out works on the HMD.

[SpookySkeletons]

@questionsdonkey I will try out your patch tonight and let you know how it feels on nvidia. It applied well to a Gentoo 5.10.49-r1 kernel.

[kedodrill]

@questionsdonkey I will try out your patch tonight and let you know how it feels on nvidia. It applied well to a Gentoo 5.10.49-r1 kernel.

I am also very curious in your findings on this!! Thank you for testing it out!

[SpookySkeletons]

The patch seemed to make a difference! The latency is minimal and very usable, pavlov, vrchat, alyx all good. However: The broken motion smoothing still exists and it becomes VERY apparent under 20 fps which makes low FPS hurt just that much more. The timing info being used is clearly incorrect, still.

[kedodrill]

The patch seemed to make a difference! The latency is minimal and very usable, pavlov, vrchat, alyx all good. However: The broken reprojection still exists and it becomes VERY apparent under 20 fps which makes low FPS hurt just that much more. The timing info being used is clearly incorrect, still.

That's mostly good news! Is that broken reprojection relevant to nvidia? I thought I saw something in SteamVR beta about nvidia getting that feature...can't quite remember though. By timing info do you mean the graph in dev tools is off from what you're actually seeing?

[SpookySkeletons]

Nvidia now has async reprojection which helps massively. Both nvidia and amd are having an issue with steam's native motion smoothing. Wrong frames are being used by steam's motion smoothing.

This patch just fixes the massive latency behind tracker movement which makes everything playable as long as you don't drop down too low...

[ParzivalWolfram]

Would the next step be to submit it for addition into the actual kernel, then? That sounds like something they'd want to add to it, if it makes hidraw as a whole work more smoothly?

On Mon, Aug 2, 2021, 12:18 PM SpookySkeletons @.***> wrote:

Nvidia now has async reprojection which helps massively. Both nvidia and amd are having an issue with steam's native motion smoothing. Wrong frames are being used by steam's motion smoothing.

This patch just fixes the massive latency behind tracker movement which makes everything playable as long as you don't drop down too low...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ValveSoftware/SteamVR-for-Linux/issues/21#issuecomment-891196215, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHE6CQKAQNH24LDTZYH3WCLT23HQBANCNFSM4DBO53MQ .

[SpookySkeletons]

Any good way to take a peek into openvr to see why it jitters smoothed frames? Does anyone suppose a vulkan apitrace would give us a clue?

[RainOrigami]

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.

@jessiehildebrandt is this still relevant?

I run the following configuration:

OS: Manjaro Linux x86_64
Kernel: 5.10.53-1-MANJARO
CPU: AMD Ryzen 5 3600 (12) @ 3.600GHz
GPU: NVIDIA GeForce RTX 2080 SUPER
WM/DE: Xfwm4 / Xfce 4.16
GPU Driver: NVIDIA 470.57.02
HMD: Valve Index

I had a real struggle getting SteamVR to run at all on my index but eventually everthing fell into place and it worked.

On SteamVR 1.18.7 I have had the issue with games running fine but the overlay dragging behind and glitching. The linux_v1.14 build does not have this issue, but some game won't run on that version.

Diabling steamvr.vrsettings enableLinuxVulkanAsync did wonders for the overlay issue on 1.18.7, no dragging, lagging or glitching. This is related to https://github.com/ValveSoftware/SteamVR-for-Linux/issues/395 . Other than that I couldn't really notice any significant tracking issues. Only other unrelated issue was the audio popping, but setting the sample rate to 48kHz in pulse solved that.

Sorry if I caused any unnecessary noise.

[ParzivalWolfram]

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

Tested on Debian Sid, 5.10.0-8 kernel, AMD Ryzen 5 2600 CPU, AMD RX 5500XT GPU. This has fixed the tracking latency, my timing graph shows i've gone from 12.8ms per frame to around 4.1, and has fixed a few other unrelated HID bugs in other programs, but... well, SteamVR 1.18.7 in itself is horribly broken after applying this. One of my base stations keeps registering as being 3 feet(!) away from where it should be, tracking is problematic, and most games are now horribly broken. Beat Saber is very, very bugged out, with no text rendering, all blocks I hit are still misses, all bombs that pass me hit no matter what, and the black skybox is around a foot tall. VTOL VR is unplayable, as it thinks i'm spinning around really rapidly when I turn my head even a little. Other games untested as of now.

I don't know if I applied it improperly or if I did something else incorrectly, but i'll go ahead and report this anyway, in case anyone else is experiencing these issues.

[kedodrill]

@SpookySkeletons did you experience any issues like @ParzivalWolfram mentioned when testing out the patch?

[SpookySkeletons]

@kedodrill Nope no issues the patch was completely painless

[ParzivalWolfram]

I'll try recompiling, then. Maybe I screwed something up, or some DKMS module isn't having it, etc.

On Mon, Aug 9, 2021, 12:02 PM SpookySkeletons @.***> wrote:

@kedodrill https://github.com/kedodrill Nope no issues the patch was completely painless

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ValveSoftware/SteamVR-for-Linux/issues/21#issuecomment-895386345, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHE6CQP2AXZ7FWP5LOKLHVDT4ACY5ANCNFSM4DBO53MQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

[SpookySkeletons]

Is there a better hid method for steam to use that doesn't involve this kernel patch? As much as I like having my custom kernel patched, this needs to be upstreamed if sane, or steamvr needs to not use blocking hid methods.

[ChristophHaag]

It is very possible to implement a lighthouse driver with libusb and not go over hid. The question is whether Valve wants to put in that work.

It is quite likely that this hid blocking issue does not affect many users actually, personally I don't believe I have noticed it. One hypothesis is that some other USB peripheral could cause it, for example gaming mice with a high poll rate.

[ParzivalWolfram]

I don't have anything that has an overly high poll rate, and I'm experiencing the issue. Cheap $5 mouse, $5 keyboard, empty USB hub, headset, Bluetooth chip on my Intel chipset 802.11AX card, not much else...

On Tue, Aug 10, 2021, 4:04 PM Christoph Haag @.***> wrote:

It is very possible to implement a lighthouse driver with libusb and not go over hid. The question is whether Valve wants to put in that work.

It is quite likely that this hid blocking issue does not affect many users actually, personally I don't believe I have noticed it. One hypothesis is that some other USB peripheral could cause it, for example gaming mice with a high poll rate.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ValveSoftware/SteamVR-for-Linux/issues/21#issuecomment-896315465, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHE6CQKZJHCBVYNSOM2J32LT4GH6FANCNFSM4DBO53MQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

[Dessix]

I suspect Valve upstreaming a kernel patch to fix blocking would be a better match for their goals than developing a workaround for a single scenario, considering their investments in the platform.

Since high-polling-rate mice are also known to cause performance degradation, is it possible this kernel patch would address that issue? After all, libusb recommends usage of hidapi for devices where applicable, though it does note that one backing implementation is - again - on libusb.

As for whether or not polling from such devices is the root cause of the issue in others, it's fair to say that Parzival's configuration contradicts that scenario.

[ParzivalWolfram]

Replying to #21 (comment)

Tested on Debian Sid, 5.10.0-8 kernel, AMD Ryzen 5 2600 CPU, AMD RX 5500XT GPU. This has fixed the tracking latency, my timing graph shows i've gone from 12.8ms per frame to around 4.1, and has fixed a few other unrelated HID bugs in other programs, but... well, SteamVR 1.18.7 in itself is horribly broken after applying this. One of my base stations keeps registering as being 3 feet(!) away from where it should be, tracking is problematic, and most games are now horribly broken. Beat Saber is very, very bugged out, with no text rendering, all blocks I hit are still misses, all bombs that pass me hit no matter what, and the black skybox is around a foot tall. VTOL VR is unplayable, as it thinks i'm spinning around really rapidly when I turn my head even a little. Other games untested as of now.

I don't know if I applied it improperly or if I did something else incorrectly, but i'll go ahead and report this anyway, in case anyone else is experiencing these issues.

I've reapplied the patch to kernel 5.13, instead of 5.10, and suddenly everything works fine. I'm not sure what the differences are other than that. It's almost entirely eliminated tracking issues and shaved 2-3ms off my latency graph, and nothing's busted this time through. It's even fixed a few other minor things, like DS4 detection.

[Plagman]

@questionsdonkey patch looks very interesting - can you email me? pgriffais at valvesoftware

[kedodrill]

@Plagman did you happen to receive an email from @questionsdonkey about this yet? This seems like it could be a step forward for performance in VR on Linux.

[Pjottos]

I tried the kernel patch but it did not solve the issue for me, not entirely at least. When I start up SteamVR and load into the empty environment I don't notice the delay. Turning on the controllers (Valve Index) sometimes causes the delay, and starting a game usually causes the delay. What I also noticed is that when i changed the background in the empty environment, the delay suddenly got really bad, probably 80+ ms and changing the background back doesn't fix it.

I'm running Fedora 35 (beta) with kernel 5.14.9 (with the hidraw patch and low latency desktop config option) My GPU is a GTX 970 and I'm using the 470.74 proprietary NVIDIA driver.

[duckbytes]

I've tried with the patch a few times and definitely see an improvement with this specific problem and don't see it getting better or worse after doing certain things. I'm using an AMD card instead of Nvidia. Could it be there are graphics card specific problems that are different to what the hidraw patch addresses?

I still experience other performance problems while using VR. https://github.com/ValveSoftware/SteamVR-for-Linux/issues/269 this issue seems to be the best description of what I still get.

[ParzivalWolfram]

I tried the kernel patch but it did not solve the issue for me, not entirely at least. When I start up SteamVR and load into the empty environment I don't notice the delay. Turning on the controllers (Valve Index) sometimes causes the delay, and starting a game usually causes the delay. What I also noticed is that when i changed the background in the empty environment, the delay suddenly got really bad, probably 80+ ms and changing the background back doesn't fix it.

I'm running Fedora 35 (beta) with kernel 5.14.9 (with the hidraw patch and low latency desktop config option) My GPU is a GTX 970 and I'm using the 470.74 proprietary NVIDIA driver.

This is probably just due to the fact that you're using a GTX 970, which is a card from 2014... the background issue is weird, but the game latency issues would be normal for this GPU.

[Pjottos]

No that's not it, I can play many games including Half Life: Alyx just fine on windows. The rendering is still smooth on linux, but it looks like it's using the HMD transform from some amount of frames ago.

[ParzivalWolfram]

That's rather impressive that it's playable, as the card you have doesn't meet minimum requirements for HL:A. This is off-topic, though.

On Mon, Oct 11, 2021, 3:49 AM Pjotr Slooff @.***> wrote:

No that's not it, I can play many games including Half Life: Alyx just fine on windows. The rendering is still smooth on linux, but it looks like it's using the HMD transform from some amount of frames ago.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ValveSoftware/SteamVR-for-Linux/issues/21#issuecomment-939820999, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHE6CQPPN52XWN37RW3FPQLUGKQKBANCNFSM4DBO53MQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[Bitwolfies]

Sad the kernel patch hasn't gone anywhere since emails were exchanged (in theory), I have very strong VR legs but Linux SteamVR in general brings me to my knees.

[ChristophHaag]

This commit in linux git master is supposed to solve the problem in a slightly different way https://github.com/torvalds/linux/commit/8590222e4b021054a7167a4dd35b152a8ed7018e

Mailing list: https://lore.kernel.org/lkml/20211130132957.8480-1-andrealmeid@collabora.com/

[ChristophHaag]

This commit in linux git master is supposed to solve the problem in a slightly different way torvalds/linux@8590222

By the way this is included in 5.17-rc1, in case anyone wants to test and report back.

[duckbytes]

I gave it a try the other day. It seems to be much better 👍 thank you for the work.

[charleslvalve]

Wow, that's awesome. I like that solution.

I won't have time to test for a bit. In about 2 months when I am going back to this, hopefully it'll be in some of the released kernels.

Charles

[edwin-v]

I rebuilt the hid.ko module with this patch in the 5.13 kernel (Ubuntu 21.10) and I had the left controller drop off twice after about half an hour of play. Couldn't get life back into the controller until a SteamVR restart. Has anybody tested else tested this thing patch? It might be something 5.13 related, but I don't see anything specific in this patch that shouldn't work.

[Atemu]

Loading modules from a different kernel ABI is not a good idea and can very well cause issues like yours. You need to rebuild the whole kernel with the patch backported.

[edwin-v]

Loading modules from a different kernel ABI is not a good idea and can very well cause issues like yours. You need to rebuild the whole kernel with the patch backported.

I did an out-of-tree module rebuild. No need to rebuild the whole kernel. No worries there.

[Atemu]

Ah, sorry; I misread.

[ColdIce1605]

This commit in linux git master is supposed to solve the problem in a slightly different way torvalds/linux@8590222

By the way this is included in 5.17-rc1, in case anyone wants to test and report back.

I've been testing that kernel version. Good News: It's a lot better Bad News: It's still not perfect.

Edit: Now to be clear there's a thousand other problems that could exist and just one of those causes it.

[michaelnew]

I've been able to play around with it briefly, and my experience was the same. Better, but not 100%.

[Meister1593]

Yep, new kernel changes things dramatically, but it isn't fixed entirely. In (proton) games theres a lot less latency compared to SteamVR overlay, but both overlay and games have it.

[ImpulseTheFox]

Using the linux_1.14 beta worked for me

[Meister1593]

Using the linux_1.14 beta worked for me

it fixed delayed output? for me it's even worse in previous branches

[ImpulseTheFox]

Yes, it fixed the delayed SteamVR overlay / Chaperone for me.

PLYSHKA @.***> schrieb am Mi., 16. März 2022, 19:14:

Using the linux_1.14 beta worked for me

it fixed delayed output? for me it's even worse in previous branches

— Reply to this email directly, view it on GitHub https://github.com/ValveSoftware/SteamVR-for-Linux/issues/21#issuecomment-1069408321, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALVSZ2LJULE4UDWN6T5JBTVAIQJTANCNFSM4DBO53MQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[duckbytes]

@ImpulseTheFox

You're referring to a different bug. Report is here: https://github.com/ValveSoftware/SteamVR-for-Linux/issues/395

[Meister1593]

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)

Hello, i was really curious on how did you manage to capture this latency? it would really help to determine the cause of the issues and would make testing new fixes much easier.

Edit: it seems like this mailing list has benchmark tool, i will use it as a reference https://lore.kernel.org/lkml/20211130132957.8480-1-andrealmeid@collabora.com/

[Kaelygon]

This might not be solution for your case, but it is worth checking if you have lib32-amdvlk installed on Nvidia GPU.

I had sluggish tracking when moving head around, a lot of the overlay menus didn't work and I had strange flickering in SteamVR. I found out that I had lib32-amdvlk installed event though I am running GTX1080. This had happened because when I installed steam with package manager, it had defaulted to amd dependency instead of nvidia. I had to first install lib32-nvidia-utils and then remove lib32-amdvlk This fixed all the problems I had with SteamVR

[TiagoTiago]

This might not be solution for your case, but it is worth checking if you have lib32-amdvlk installed on Nvidia GPU.

I had sluggish tracking when moving head around, a lot of the overlay menus didn't work and I had strange flickering in SteamVR. I found out that I had lib32-amdvlk installed event though I am running GTX1080. This had happened because when I installed steam with package manager, it had defaulted to amd dependency instead of nvidia. I had to first install lib32-nvidia-utils and then remove lib32-amdvlk This fixed all the problems I had with SteamVR

I'm not seeing either of those packages available to install or uninstall; what's your distro? (I'm on Mint)

[Kaelygon]

Arch linux, I forgot to mention that. I also spoke too early, after reboot I started having SteamVR issues again, although removing amdvlk did fix the menus but the flickering and sluggish head tracking came back.

[kimabjorkede]

Running [linux_1.14] seems to help a lot. It could still be improved.

The SteamVR home-menu seems to not be working on this build, though.

I have nvidia drivers 520.56.06.

"enableLinuxVulkanAsync" : false helped with the flickering that sometimes happened.