Enabling GSP makes SteamVR unplayable on RTX 3090ti

Graphics / Linux Linux
,
1

Hi!
I am currently experiencing terrible lag in SteamVR on nvidia driver 555.58.02 with GSP enabled.
As soon as I disable it it works flawlessly again.

The lag only happens inside the VR headset - the “mirrored” game on the desktop is completely fine.

GSP Off:
SteamVR no issues GSP Off

GSP On:
SteamVR shenanigans

The purple lines in the performance graph are frames with “Display Error”

Bug report created with GSP On:
nvidia-bug-report.log.gz (904.2 KB)

2 Likes
2

On driver version 560.31.02 the issue still persists when GSP is enabled.
SteamVR is unusable with GSP on.
The only working combination right now is closed source kernel module with GSP off.

3

You might consider to additionally open an issue at Issues · NVIDIA/open-gpu-kernel-modules · GitHub since this is a difference between the open and closed kernel module.

4

I’m also seeing this behavior with version 560.35.03.

5

I don’t think the open kernel module works without GSP, at least on the github it says:
“Note that the kernel modules built here must be used with GSP firmware and user-space NVIDIA GPU driver[…]”

I have only tested

  1. Closed source kernel module + GSP off (works)
  2. Closed source kernel module + GSP on (doesn’t work)
  3. Open source kernel module + GSP on (doesn’t work)
2 Likes
6

This issue still persists with driver 565.57.01 and closed source kernel module + GSP on.
haven’t tested open modules yet.

7

I’m also seeing the same issue with 565.77 and with open source driver is no longer possible to disable GSP :(
Can’t use steamvr on linux anymore until this issue is fixed
Edit:was able to revert to the proprietary driver for now

8

We have filed a bug [5014610] internally for tracking purpose.
Shall keep posted on the update as soon as we get internal repro and update from engineering team.

4 Likes
9

We have root caused the issue and changes will be integrated in future release drivers.

7 Likes
10

Thank you very much for looking into this!
Seeing communication like this restores my hope in the future of Linux+Nvidia bit by bit :)

1 Like
11

Appreciate the response!

I’m looking forward to this change as well. The open kernel drivers have been pretty good otherwise.

1 Like
12 
  Implemented a feature that allows low latency display interrupts to
  be serviced even when the system is under heavy contention. This
  is especially useful for reducing stutter when using virtual reality.

  This feature is experimental and disabled by default.

  This feature can be enabled by loading nvidia.ko with the
  `NVreg_RegistryDwords=RMIntrLockingMode=1` kernel module parameter.

^ from the 570.86.10 changelog that is due to come out soon

2 Likes
13

I just tried with the new 570.86.10 driver and the following config:

#> cat /usr/lib/modprobe.d/nvidia.conf | grep -v '^#'
options nvidia NVreg_UsePageAttributeTable=1 \
    NVreg_InitializeSystemMemoryAllocations=0 \
    NVreg_DynamicPowerManagement=0x02 \
    NVreg_EnableGpuFirmware=1 \
    NVreg_RegistryDwords=RMIntrLockingMode=1
options nvidia_drm modeset=1 fbdev=1

On proprietary and open driver with GSP enabled

 nvidia-smi -q | grep -i GSP
    GSP Firmware Version                  : 570.86.10

With the new 570 driver and the new parameter set, there is less stuttering on both setups with GSP enabled, but (at least in my experience) it’s still not as good as proprietary driver with GSP off, which has no stuttering.
Maybe someone else can confirm if it’s just me or they notice it too.

EDIT: The “stuttering” almost looks like screen tearing and is especially prevalent in the upper part of the VR view in the headset.
As before it is not visible in the mirrored view on the desktop.

14

The “stuttering” almost looks like screen tearing and is especially prevalent in the upper part of the VR view in the headset.

^ I’m seeing the same behavior reported by @joni_999
It’s better than before but still worse than proprietary driver.

1 Like
15

Hi. I have also been testing 570 with
NVreg_RegistryDwords=RMIntrLockingMode=1

I had the tearing in VR when a VRR-capable monitor was attached/active. Disabling the VRR-capable monitor got rid of the tearing. It’s a shame that the announced-to-be-in-the-driver conceal_vrr_caps parameter actually didn’t make it to the driver, as I believe it might perhaps also be useful to disable VRR here?

With this VR runs fairly steadily. There is still a slight amount of latency though (especially as compared with Windows). However I have yet to try the binary module with GSP off to compare (I have had issues getting the binary module with GSP off working on my system)

16

From what I’ve heard, for this to work VRR needs to be off, also the RMIntrLockingMode setting is only available in the open module

17

Yes. I’m using the open kernel module at the moment.

I was referring to testing what OP mentioned that the binary blob kernel module with GSP off still had the best performance. I haven’t been able to reproduce that setup yet, but I would like to try to compare to see if it performs any better.

On the current setup (570, open kernel module, RMIntrLockingMode) I still have issue with sometimes excessive latency (somehow opening and closing the SteamVR dashboard seems to help for a little while).

But it is thus far the best and most stutter-free experience I’ve had with wired VR on nvidia and Linux thus far, unfortunately coming up just short of the goal… (interestingly wireless/streaming VR works with a lot less issues, probably because reprojection is handled locally leading to less issues with nausea-inducing latency)

1 Like