Uninitialized right eye mask in SteamVR 1.21.2

[kisak-valve]

Describe the bug
I was doing routine video driver testing for the mesa 21.3.0 update on my VR test box (i7-7700/RX480) and noticed light bleeding into side of the lens of my Vive from outside the field of view. Opting out of SteamVR 1.21.2 on the beta branch to SteamVR 1.20.4 made the issue go away. Also, setting SteamVR's launch options in Steam to RADV_DEBUG=zerovram %command% worked around the issue.

To Reproduce
Steps to reproduce the behavior:

1. Start SteamVR 1.21.2 with SteamVR Home disabled to go to the mostly empty fallback environment. Use a darker background color to make it easier to notice light bleeding into the right lens.

System Information (please complete the following information):

• Distribution: Gentoo
• SteamVR version: 1.21.2
• Steam client version: November 16, 2021
• Opted into Steam client beta?: Yes
• Graphics driver version: Mesa/RADV 21.3.0
• Gist for SteamVR System Information: [See instructions]

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Also tested mesa 21.2.5 under the assumption that this was initially a video driver regression. In case it matters, async reprojection was also disabled during this step of driver testing.

[ChrisJAllan]

RADV_DEBUG=zerovram %command%

Thank you so much for this, I thought my headset was dying!

[KawaneRio]

Just had this exact issue today..! Thank you so much for the workaround!:sob::heart:

[wallcarpet40]

Thank you for this workaround! Fedora just received an update for Mesa 21.3 and this issue is there.

[kisak-valve]

Also seen as edge artifacts with a Valve Index on #500.

[ZarathustraDK]

Workaround succesfully tested on the Index. I can imagine this being a pretty scary bug if you're not following/noticing updates and bugtrackers, as it could easily be perceived as the right lens being a bit off or the display having received a bump to the right.

[caseif]

I actually went through with a headset RMA and only realized it was a software issue when the new headset had the same issue. Thanks for the workaround!

[melvyn2]

Looks like I needed the same fix. Has anyone measured the performance impact of zerovram?

[Goofybud16]

I've been experiencing this issue for a while, and the above fix seems to correct it.

To provide images of what this -might- look like:

This is on the desktop: (see #438)

And this is in the headset (The headset is displaying a blue scene from an application):

I've also seen it show up as rapid black and white flashing (which can cause some odd effects in the right lens, such as the lens itself appearing to get brighter and dimmer rapidly-- very unpleasant.)

I thought this was actually a failing LCD or motherboard in my Index originally, glad to see it was just a software bug.

[kisak-valve]

[BUG] vrcompositor doesn't clear the right eye

Issue transferred from #603.
@Coreforge posted on 2023-08-21T16:12:00:

Describe the bug
vrcompositor appears to never clear the part of the swapchain image for the right eye, resulting in noticeable flicker from the side of the lens. It's easier to see when looking at the lenses at an angle, but still noticeable when wearing the headset in darker scenes.

To Reproduce
Steps to reproduce the behavior:

1. Launch SteamVR
2. in a darker scene (like the default aurora sky), put the headset on or look at the lenses at an angle
3. observe the flicker/light bleeding from the side of the right lense
4. Alternatively, look at the swapchain image in renderdoc

Expected behavior
There shouldn't be any random data displayed around the image for the right eye, both should be cleared.

System Information (please complete the following information):

• Distribution: Ubuntu 22.04.2 LTS
• SteamVR version: 1.26.7, also happens on the latest Beta (1.27.2)
• Steam client version: 1690583737
• Opted into Steam client beta?: No
• Graphics driver version: Mesa 22.2.5, the same thing happens with Mesa 23.0.4-0ubuntu1~22.04.1 (LLVM 15.0.7)
• Gist for SteamVR System Information: https://gist.github.com/Coreforge/7c695d44e222d0520f2b61542c80df9b

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Renderdoc capture: https://drive.google.com/file/d/15hgEKLMgdocxYvmQ-imJfBLgL82FFRh0/view?usp=sharing
EID 131 (left eye -> Scene -> Scene / Lens Distortion -> vkCmdBeginRenderPass) clears the area for the left eye in vkCmdBeginRenderPass
EID 277 (right eye -> Scene -> Scene / Lens Distortion -> vkCmdBeginRenderPass) does not clear the area for the right eye, resulting in random data being left in the final image (clearValueCount is 0 in the VkRenderPassBeginInfo)

Note: Commenters who are also experiencing this issue are encouraged to include the "System Information" section in their replies.

[digitalcircuit]

On my system, SteamVR 1.26.7 works fine¹ with no corruption in the right eye, but SteamVR beta (1.27.4 and 1.27.5) has corruption in the right eye and requires the RADV_DEBUG=zerovram %command% launch option to work around it.

It only shows on the headset, not in the headset viewer. I've not yet figured out how to set up RenderDoc to capture the output.

Here's my SteamVR System Report (with beta 1.27.5), zipped to reduce size.

I'm using an AMD Radeon RX 5600 XT on an up-to-date Kubuntu 22.04 LTS install (with HWE stack). If there's any other information that would help, let me know!

---

NOTE 1:

SteamVR 1.26.7 does have stuttering with the SteamVR overlay/guardian boundary, and flickers when moving in the "loading" world, requiring RADV_DEBUG=nodcc %command% to reduce that. However, it does not have the graphical corruption in the right eye.

SteamVR 1.27.4+ is a massive improvement in that sense, with the only issue so far being the right eye not getting cleared. I appreciate the ongoing improvements!

[amini-allight]

This bug seems to still be present in the SteamVR 2.0.1 beta.

[caseif]

As a note, the workaround doesn't seem to be working for me anymore in 2.0.3. I would assume it probably has something to do with the runtime change.

[digitalcircuit]

I've managed to get SteamVR 2.0.6 beta able to launch thanks to an updated vrsetup.sh, and I can confirm the RADV_DEBUG=zerovram %command% workaround no longer works on my system, too.

Considering my HTC Vive uses OLED screens, I imagine this would cause burn-in, so I'll stick to SteamVR stable when actually playing VR longer term.

[digitalcircuit]

Thankfully, with SteamVR 2.0.8 stable released today, the RADV_DEBUG=zerovram %command% workaround has started functioning again for my system.

The underlying bug remains - if I clear the SteamVR Launch Options, the uninitialized graphics memory flickering in the right eye returns.

EDIT 2023-10-26: I've had success with multiple launches on Kubuntu 22.04 LTS, but I did not extensively test. I might have just gotten lucky, as noted in the following comment.

[kisak-valve]

It looks like digitalcircuit's observation was a false negative and at some point in SteamVR's startup, RADV_DEBUG is now getting dropped from the environment.

I've managed to workaround this once again by adding export RADV_DEBUG=zerovram to any sensible line before the last exec line in [Steam library folder]/SteamVR/bin/linux64/vrcompositor-launcher.sh.

[digitalcircuit]

Following up on kisak-valve's remarks, while SteamVR 2.0.10 (stable) consistently properly passes RADV_DEBUG through the environment on my Kubuntu 22.04 system, SteamVR 2.1.1 (beta) drops RADV_DEBUG. Fortunately, the workaround of editing the script succeeds for me, though it's less convenient as it gets overwritten with updates.

If there's anything else that would help in getting this properly resolved (rather than continuing the workaround), let me know!

EDIT 2023-11-18: I decided to automate this workaround since I expect to have to do it for a while:

VRCOMPOSITOR_LAUNCH="$HOME/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrcompositor-launcher.sh"
if [[ ! -f "$VRCOMPOSITOR_LAUNCH" ]]; then
    echo "[!] Can't find 'vrcompositor-launcher.sh', adjust path in variable?" >&2
elif ! grep "RADV_DEBUG=zerovram" >/dev/null "$VRCOMPOSITOR_LAUNCH"; then
    sed --in-place "s@# NOTE: the vrcompositor-launcher stub does a bit of env manipulation and syscap work@# Work around right eye VRAM, see: https://github.com/ValveSoftware/SteamVR-for-Linux/issues/480\nexport RADV_DEBUG=zerovram\n\n# NOTE: the vrcompositor-launcher stub does a bit of env manipulation and syscap work@" "$VRCOMPOSITOR_LAUNCH"
else
    echo "Already patched 'vrcompositor-launcher.sh'"
fi

[caseif]

Interestingly, the issue with the env var being dropped seems to have been fixed as of 2.1.10, only to regress again in 2.2.1.

[digitalcircuit]

@caseif Interesting… The same applies to me - SteamVR stable passes the environment variable, SteamVR beta does not.

Is it possible something differs between the SteamVR stable and SteamVR beta build pipelines, resulting in dropping environment variables in beta? It seems unlikely.

Diffing the SteamVR 2.1.10 folder with the 2.2.1 folder points out some settings, translations, and most of the binary files, which isn't exactly helpful in tracking down the change.

[digitalcircuit]

Quick follow-up - I'm starting to think there's a difference between SteamVR beta and stable releases, since I've had the same behavior with SteamVR 2.2.3 beta vs stable - beta dropped the RADV_DEBUG=zerovram environment variable, stable correctly passed it on.

I noticed this as part of testing a separate, possibly related issue where SteamVR 2.2.3 beta didn't launch VR games, while SteamVR 2.2.3 stable does.

[digitalcircuit]

Affirming that this happened again with the recent SteamVR 2.4 update - RADV_DEBUG=zerovram environment variable lost with beta 2.4.x, but preserved with stable 2.4 release.

[9021007]

This is happening to me on the stable release, workaround works, using Arch. In-game menu is also invisible but i can still interact with it by seeing the hover descriptions, seems unrelated but thought i might as well add it here. Menu not fixed by the workaround.

[misyltoad]

This will be fixed in a future SteamVR release.

[digitalcircuit]

@Joshua-Ashton I can confirm that SteamVR 2.5.3 beta fixes this issue for me, and it also fixes SteamVR Home not launching (as per the changelog).

I can now happily resume daily-driving the SteamVR beta. Thank you to everyone involved!