[BUG] [Regression] Overlay Wobble/Jitter/Artifacting introduced in 1.15.X #395
Comments
mcoffin
changed the title
mcoffin
changed the title
|
New note: This only occurs when asynchronous reprojection is enabled. |
|
Same here. System Information (please complete the following information):
|
|
can reproduce: Distribution: Arch Linux (5.9.2-zen1-1-zen) |
|
I have this problem too and now that the beta has been pushed into the main release branch it can no longer be avoided by opting out of the beta. Distribution Arch Linux Edit: the problem also effects xrdesktop windows. |
|
Can reproduce SteamVR version: 1.15.10 |
|
There is a linux_1.14 branch available in SteamVR as a temporary solution to this problem. |
|
Can reproduce, but not just the overlay. Timing-sensitive games like Beat Saber felt significantly more choppy, which the fps graph confirmed. SteamVR version 1.15.10 |
@lostgoat Could I ask what are the details for the system that Valve uses for testing SteamVR on Linux? It has been awhile since there has been a Linux update, specifically for performance. Are there things specifically preventing Valve from getting SteamVR working with good performance (close to / matching Windows) on Linux? |
|
I'm hitting something that may or may not be related. |
|
@WebFreak001 Nope, different pattern in the specific details for visual corruption, and much different characteristics around how problems emerge. I'm guessing for yours there is an implementation error in Vulkan in your driver. I think for mine it has to do with the memory allocater and/or use before initialization and/or erroneous overwrite of allocated memory. My preview also differs from what I see, where your steam preview matches what you see. I've already fixed a conflicting drivers issues that was amdgpu-PRO related a few weeks ago, which I needed to do to get VR working at all. |
|
Has been stated at the top of the thread. Unfortunately, we are best of sticking around with 1.14 until Valve fixes this. |
Yes, though while mcoffin wrote what caused it, it wasn't explained how to turn it off. The source that I found and linked is also bit old and I was not certain that it would still work. |
|
Because it has not been mentioned: This affects OpenXR quad layers too. |
|
I get this issue too. Initially I created a separate issue for it, but it turns out it's the same as this one.
I also recorded the issue through the lenses of my HMD: https://happysmash27.me/Upload/Screenshots/Videos/Bugs/SteamVR/VID_20210204_050848.webm |
|
Just to chime in on this one guys, in my experience of only about 6months and ~1300hrs of usage, I've seen that the asynchronous reprojection implementation in SteamVR on Linux is mostly unusable, especially when compared to the stability of the performance achievable with some manual resolution tuning and just keeping it disabled. While I originally disabled it to fix this issues, I've seen many other performance benefits to just keeping it off, and I'd recommend other performance-sensitive folks who's hardware isn't going to fall behind do the same for now. There's little reason to stay on |
I'll try that out then, since my hardware is on the low end of VR users (RX 580 8GB, R5 1600X). Thank you for telling us all! |
|
Async Reprojection causes problems because of #269. If you have low end hardware then you're likely gonna be throttling most of time anyways, then disabling it isn't a good idea (I can't have it off in Boneworks or Blade&Sorcery for example, with a 5700XT. They just stutter too much without it). |
|
I too experience a lot of headache inducing stuttering with a 5700XT if async is disabled. I'm not so keen to reduce the resolution because it makes it difficult to read text. Are there other tweaks that can make disabling async usable or is reducing resolution the only way? |
|
I'm currently running a 6900XT, but I spent the last year on the 5700XT @duckbytes and @Zamundaaa. I found a few tricks that DRASTICALLY improved the experience. Even though it may seem like you're throttling, sometimes, what's happening is that during the downtime between frames, the 5700XT will downclock to a lower power state, causing just enough lag on the next frame to temporarily trigger throttling before it clocks back up, does a few frames quickly, and the whole process repeats. By setting the minimum If you want to give it a whirl, here were the settings I was using all year. You may have to tweak some things due to silicon quality and cooler quality (I had a custom liquid loop, so lots of thermal mass to absorb spikey power consumption). sclk_min: 1950
sclk_max: 2210
mclk_min: 700
mclk_max: 903 # my memory sucks. you might be able to do better than this
power_limit: 300000000 # This means 300W - at 300W often other limits are reached before the card hits this limit, which keeps the clocks as stable as they can be so long as your cooler can handle it
voltage_curve:
- 750mV @ 800MHz
- 912mV @ 1450MHz
- 1230mV @ 2210MHzNote that the voltage curve can still have points on the curve below the actual minimum In some titles, I had similar problems on the CPU side, but I'm not as familiar as I didn't write the overclocking support on that side, so for those titles I just settled for setting max all-core frequencies, which worked out... okayish on my 3960X sudo cpupower frequency-set -g performanceSome tools I made throughout this process (in addition to writing the reclocking support for
If you still have issues, please reach out. I spent tons of time on this over the last year, and good performance is possible. The biggest gains I saw were from drastically increasing the minimum shader clock (to prevent the downclocking), so I'd start there if I were you. |
|
Which would be a good way to monitor my GPU clock to see if I may also be having a similar issue on my RX 480? |
|
Never mind; radeon-profile (https://github.com/marazmista/radeon-profile) seems to work pretty well, and was in my distribution's repositories. |
|
Thanks @mcoffin for the ideas. I want to try out these configurations but I'm hesitant because I don't know enough about overclocking to know if these are suitable for my GPU or aren't going to cause damage. Should I look up frequencies for my particular model or reduce some of the values to account for only having air cooling? The specific card I have is MSI Radeon RX 5700 XT MECH OC 8GB. I did find some options in radeon-profile that let me fix the frequency under Overclock > Manual frequency control. I can set that to only use the highest frequency (2100, 875 on there by default) by unchecking the other options. Is that more or less doing the same thing and would help with the downclocking bug you mention? Or is there more to it? Thanks again! |
|
Still happens as of steamvr beta 1.21.6, Using EndeavourOS KDE, along with Nvidia-DKMS 495 |
|
Also having this issue, the "wobbly" overlay/chaperone drives me crazy. Really hope this will be fixed in a future update. |
|
I can confirm this issue as well here. Disabling async does resolve the menu issues, but in turn makes turning your head in VRChat (only game I tested so far, just recently got this headset) very stuttery. Downgrading SteamVR to 1.14 results in VRChat not being able to launch, so I have to chose if I want to disable async or not in the current version. Info: |
|
Mildly off-topic, but if you're testing Proton with the SteamVR Specifically for VRChat, this situation was previously pondered on its compatibility report with comments starting around ValveSoftware/Proton#1199 (comment). |
|
Hello |
|
Since the latest Manjaro upgrade, I do not have this problem anymore ! Kernel 5.17.6-1-MANJARO |
I think something is happening there on steamvr side, some logic does this... I did also test out Monado + libsurvive + OpenComposite, overall not suitable replacement (for vive, tracking is not as good on regular valve drivers) but a good playground for testing out these theories. And aside from shutter, image over-saturation, incomplete bindings and barely any vr game working, it did not have that crazy wobble effect. |
|
Okay not sure if that will help or not people, but: this is very likely related to usb and linkbox kindof adds even more latency. |
|
@kisak-valve It turns out that steamvr saves the last two frames in a buffer or at least feeds them into the encode engine of the GPU and draws out a motion vector field of the framebuffer between the last two frames and then takes this image and smears the very last frame generated to produce a frame for the vsync. The behavior in the case of the motion vector being zero is simply to 50:50 the images as overlayed directly atop one another. This works for UI elements held in hand in the direct foreground that match the rotation of your face even on windows, it does not feel acceptable for background elements and causes split vision. THIS IS A HUGE PROBLEM ON LINUX VAAPI/ VDPAU video APIs have always been pure jank on linux and valve did not bother to implement a solution to properly talk to the GPU to determine this motion vector field so it just feeds zero into everything, the resulting image is full of zero field info and just defaults to a 50:50 fade between the last two frames of the image which is incredibly nauseating. Three solutions: Go into the binary and NOOP or hard disable the function attempting to insert these hallucinated frames. Noticed words such as "halucination" around these function names. This will create a raw ATW simple motion smoothing where the image can look choppy but the viewport is smooth, much preferable. Expose the necessary video API through the task of wiring up (ffmpeg?) an entire video encode/ decode setup to draw out vector fields from these two last images and then feed the vector field back into the hallucination functions to draw the next frame properly. Change the behavior of the 50:50 and CUT OUT A FRAME. At least using the very latest frame will have the effect as solution 1 instead of a transparent blend. 😮💨👃 PLEASE VALVE FIX, WE KNOW THE ISSUE HERE I realize your super secret headset is in development, and will natively ship linux as standalone and will require you to fix this as time permits, but its simply been years and without the necessary transparency this has been a bleeding mess thus far. It would be nice if OpenXR was the standard, Monado was free range, and we didn't have to deal, but OpenVR is here to stay as a matter of the sheer amount of applications run atop it already so we would like some source pls! |
|
As a demonstration: This has been present since version <1.14 and is in dire need of a ifndef(__LINUX) statement to repair it. |
|
Doing more digging, it looks like steamvr may handle this kind of motion interp using a dx shader for windows and a SPIR-V shader for linux! Anybody want to try deleting some of these shaders & more to see if it helps with FPS under half? If all this is handled in shaders it could be most of the shaders are just written incorrectly same as the ones rendering the OBJ files have depth buffer issues that invert the faces. @okawo80085 |
As soon as i get a free minute i'll check it out |
|
@SpookySkeletons I tested running native SteamVR Beta 1.24.3 with asynchronous reprojection enabled and the mentioned files moved elsewhere (and some others on a second attempt). That didn't seem to affect anything. The overlay still works and is wobbly/jittery. I'm willing to do more testing on AMD and Nvidia GPUs if needed (btw there is no depth buffer issues on Nvidia with proprietary drivers as far as my experience goes). Deleted vulkan shaders:
Here are some of my specs:
|
Is there any way to make new proton versions work with 1.14-1.15 correctly? |
|
Found it. SteamVR submits the result from the previous eye if the game uses the same texture to render both eyes sequentially. This can be fixed in the steamVR implementation. Just need to flag down valve for a fix here |
|
@SpookySkeletons Are you saying that SteamVR reprojects frames from the left eye to the right and vice versa under some circumstances? If so that's quite a wild goose chase the reprojection-thread has been on for 1+ years, thinking it had something to do with delayed/premature frames being displayed to the correct eye. But yeah, the particular offset experienced makes sense in that case. Theoretically this would mean that far away objects are less displaced than objects closer to you, no? As in switching between looking with the left/right eye will "move" a finger you're holding up in front of you further than some object you're focusing on on the far wall. If the problem was delayed/premature frames to the correct eye the reprojection offset would be uniform regardless of distance to the object. |
|
Loving the radio silence, guys. Thanks valve. |
|
The artifacts in SteamVR (not overlays specifically) have now been fixed, see #588 I don't have any overlays set up at the moment (not sure how to, haven't used them before), can someone test to see if artifacts are fixed for overlays too? |
|
I can confirm on AMD RX 6700 XT, HTC vive, SteamVR 1.27.5:
|
|
Closing per the last couple comments. |
|
@kisak-valve Underlying issue of the overlay itself actually seems to be much improved, thankyou. However I would like to add: to address other such issues under heavy load, might I make a recommendation that you verify that linux's GPU preemption is functioning as expected? |
and others
Description
Starting with SteamVR
1.15.X, overlays (viaIVROverlayfrom a game client, and the "system" overlay displayed when you hit the "system" button on the index controllers), wobble, as if they are attached to the HMD with a rubber band. If you move around enough, there will also be significant artifacting ocurring in the overlays (though it's a little harder to induce with the system overlays compared to theIVROverlayinstances created by ACC).This only occurs when asynchronous reprojection is enabled.
Reproduction Steps
Steps to reproduce the behavior:
Expected Behavior
The overlay should stay static in space, and not have artifacts, as it did in SteamVR 1.14.16.
System Information
amd-staging-drm-nextkernel -f24cd554aacf4e989a0796c7d30d758115512732rebased off ofv5.9-rc6from Linus' tree with rebased futex patches from mcoffin/linux@mcoffin-5.10-futex-wait-multiple, but this behavior is observed on stable channel kernels as well)Built: Sep 3 2020 at 21:18:20Mesa 20.2.0 (git-663d464366) (ACO),AMD Radeon RX 5700 XT (NAVI10, DRM 3.40.0, 5.9.0-rc6-1-amd-staging-drm-next-git-00457-g3637df487bdb, LLVM 11.0.0). Mesa versions down to 20.1.4 were also tried, with no change in behavior. Regression still occurs between 1.14.X and 1.15.X.Additional Context
A cpu profile with
sysprofshows a significant amount of time being spent inclock_gettimecompared to "working" versions. (~10% of samples for ACC with it open!). This could indicate a busy-wait somewhere that's misbehaving?Mesa 20.2.0 released a whole bunch of RADV features for timeline syncobj's, and I chased down that path for a while, but observing the same behavior with previous mesa releases ruled the timing of this release out as the issue.
Under normal operation, I'm running a pretty hefty GPU overclock, and setting the min frequency to quite close to the max to achieve livable performance, but disabling this (clean boot with no writing to
sysfs), did not affect the observed behavior in any way.perf topduring overlay wobble for ACCScreenshots
Unfortunately, overlays are only displayed in the HMD for me, so I cannot capture this behavior, though I can look in to alternative solutions if upstream developers cannot readily reproduce the issue.
In-progress debugging
amdgpu/mesainteractions with SteamVRThe text was updated successfully, but these errors were encountered: