protonscr

[PERF] Bad frame timings every few seconds on Radeon RX 5700 XT and Valve Index

steamvrclosed perf
ValveSoftware/SteamVR-for-Linux#245 · opened 2019-09-15 by lubosz · updated 2019-09-19 · 3 comments · github
Llubosz 2019-09-15 github

Describe the bug
Beat Saber runs well most of the time, but is unplayable on high levels due to the frequent drops.

While in the Beat Saber main menu WaitGetPoses usually takes ~4.5ms, but regularly drops to ~12.5 (as seen in the beat-saber-main-menu-bad.trace). In the beat-saber-main-menu-onebigdrop.trace the WaitGetPoses took 75ms once.
The problem seems to be hard to trace, since the frame timing improves when gpuviz is tracing.

To Reproduce
Steps to reproduce the behavior:

  1. Start Beat Saber
  2. Performance drops occur as early as the "Safety Warning Screen"

Expected behavior
Constant frame times of under 6.9ms.

System Information (please complete the following information):

  • Distribution: Arch
  • SteamVR version: 1.7.15
  • Steam client version: Sep 10 2019
  • Opted into Steam client beta?: Yes
  • Graphics driver version: Mesa 19.3.0-devel (git-9466e4cfab) (LLVM 10.0.0)
  • Kernel: drm-next at 9a60b2990d6c2b7ab935fe0a5cc274de67d98bed with fsync patches applied.
  • Gist for SteamVR System Information: Gist

Performance Data (optional, but very helpful):

Screenshots

Beat Saber Valve Index

The small frame timings graph in SteamVR settings shows pink and orange frames frequently.

beat-saber-brief-frame-timing

beat-saber-brief-frame-timing2

In ~1200 frames you can clearly see the inhomogeneity of frame times in the advanced timings details view.
beat-saber-timing-detail-all2
The spikes can be tracked down in WaitGetPoses and Application GPU (pre).
beat-saber-timing-detail-filtered2

hellovr_vulkan Valve Index

In hellovr_vulkan the impact of Total GPU comparably low. WaitGetPoses and Compositor Render Start seem to be affected.

hellovr-timing-filtered4

Beat Saber Vive Pro

On the Vive Pro the issue does not seem as impactful as on the Index.
beat-saber-timing-detail-filtered-vive-pro

Additional context
In hellovr_vulkan and hellovr_opengl the problem also occurs, but only when gpuviz is not tracing. It is still visible in the details frame timing graph.

The SteamVR compositor itself runs constantly at 0.9ms, without any drops.

On the Vive Pro the frame time is constantly 3.9 without drastic drops. hellovr_vulkan does not have any noticeable drops on the Vive Pro.

Additional setup information:

  • Valve Index with current firmware.
  • "enableLinuxVulkanAsync": false in steamvr.vrsettings
  • I also ran echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level
  • Proton 4.11-4, fsync: up and running.

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

Llubosz 2019-09-17 github

The situation seems to be better with only occasional frame skips on today's Linux master brach at ad062195731bea1624ce7160e79e0fcdaa25c1b5 with fsync patches applied.

Linux bcube 5.3.0-gdcb8cfbd8fe9 #5 SMP PREEMPT Tue Sep 17 13:09:17 CEST 2019 x86_64 GNU/Linux
Llostgoat 2019-09-18 github

Hey @lubosz ,

It seems like the gpuvis captures don't fully support Navi yet so the data is incomplete. But from what I can piece together from the SteamVR side of the trace I think this is something that might be fixed in 1.8.2

Can you give it a try and let me know if the issue is still present?

Llubosz 2019-09-19 github

Hi @lostgoat ,

thanks for the reply.
The performance improved with updating mesa to commit 05da025f350cb83e1125d6a931ccf9a87223bb69, which added a bunch of radv patches by Samuel Pitoiset.
Updating Proton 4.11-5 also subjectively improved the performance further.
Tested on SteamVR 1.8.2, where I reset to default settings, so with Async Reprojection enabled again.

I didn't measure the impact of each update.

The performance is still not perfect, a bit worse than on Windows with occasional drops, but the game is playable and I was able to finish a game at Expert+.

For now I will close this and wait until the Navi stack matures a bit, and will resubmit an issue if the performance is unsatisfactory with release versions.

To recap, these versions work fine for me, all master branches.
linux @ ad062195731bea1624ce7160e79e0fcdaa25c1b5 with fsync patches applied
mesa @ 05da025f350cb83e1125d6a931ccf9a87223bb69
SteamVR @ Beta 1.8.2
Proton @ 4.11-5

Update:
On SteamVR 1.8.3 the compositor only (without SteamVR Home) runs smoothly at 0.9ms with Beat Saber at ~3.6ms with rare drops.
Screenshot from 2019-09-19 10-12-48

Proton versions