[LINUX][0.22.2] Framerate drops to 40 while game is running at 60fps in 4K stream

[DistantThunder]

Setup

## Host	## Client
CPU: 5800X GPU: 7900XTX RAM: 64 GB vainfo Trying display: wayland vainfo: VA-API version: 1.21 (libva 2.21.0) >vainfo: Driver version: Mesa Gallium driver 24.0.3-arch1.2 for AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 17.0.6, DRM 3.57, 6.8.1-zen1-1-zen) vainfo: Supported profile and entrypoints * VAProfileH264ConstrainedBaseline: VAEntrypointVLD * VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice * VAProfileH264Main : VAEntrypointVLD * VAProfileH264Main : VAEntrypointEncSlice * VAProfileH264High : VAEntrypointVLD * VAProfileH264High : VAEntrypointEncSlice * VAProfileHEVCMain : VAEntrypointVLD * VAProfileHEVCMain : VAEntrypointEncSlice * VAProfileHEVCMain10 : VAEntrypointVLD * VAProfileHEVCMain10 : VAEntrypointEncSlice * VAProfileJPEGBaseline : VAEntrypointVLD * VAProfileVP9Profile0 : VAEntrypointVLD * VAProfileVP9Profile2 : VAEntrypointVLD * VAProfileAV1Profile0 : VAEntrypointVLD * VAProfileAV1Profile0 : VAEntrypointEncSlice * VAProfileNone : VAEntrypointVideoProc	Valve SteamDeck®
4K60 HDMI Headless + 1440p144	4K60 HDR output via Dock
Sunshine 0.22.2	Moonlight 5.0.1
Plasma Wayland 6	Gamescope

Problem

When streaming to my client, the stream framerate regularly drops to 40/30 fps on the very same scene. If I fiddle with some settings, stay idle on static and visually "poor" scene, the fps has a chance of bumping up again. But then can also drop again.

Illustration

At around 10s:

hzfw.webm
Meanwhile, the game framerate is a solid

99% of the time.

Logs

• sunshine.log

[DistantThunder]

I have tried patching like mentioned here:
#1040 (comment)

However, the VAAPI encoder doesn't support AVBR rc_mode and the software / CPU cannot sustain 4k60 fps encoding.

[DistantThunder]

I just noticed that I cannot reproduce this issue when the performance level is set to high:

cat /sys/class/drm/card1/device/power_dpm_force_performance_level
high

For some reason, the dynamic power management even when during heavy workloads is apparently still finding ways to lower clocks/power usage in ways that destroys encoding performance, while the main workload itself remains fairly stable.

Observing if this is a definitive fix for this problem.

AMD or rather RADEON being the usual enemies with DPM since 10 years I guess.

[gschintgen]

At this point one of the affected users should probably file a detailed report on the upstream Mesa/ Vaapi/Amd bugtracker. (Including the objective findings from the other discussion that I linked to.)

[DistantThunder]

@gschintgen Do we have data points logging facilities in Sunshine to graph the encoding time during a session?

To present and argue our case in Upstream, I was thinking of having 2 sets of data:

• Encoding time
• Game framerate

With power_dpm_force_performance_level set to auto and then with it set to high.

[gschintgen]

I've just filed a PR for logging encoding times: #2415
It's easy to create graphs from the resulting data.

[gschintgen]

Also: the latest Linux builds are sending more data to Moonlight, so that an additional line is shown in the OSD statistics: "Host processing latency". Its values are more or less equal to the durations measured by my PR. (Your video was probably taken with a build that predates that change.) These encoding times are also printed periodically to Sunshine's log. Every 20 seconds IIRC and only for loglevel debug.

[DistantThunder]

Ok, I'll try to put something together when I get time. Another thing I noticed is that when the computer comes from sleep, even though the perf level is "high", I had to switch it back to auto and then back again to high for the lower encoding performance to stop.

Now I experience the stuttering mentioned in the other discussion though. I'll try the fix there.