Steam Remote Play drops to 30 fps when running games using Proton.

[lavadrop]

Your system information

• Steam client version: Feb 18 2022
• Distribution (e.g. Ubuntu): openSUSE
• Opted into Steam client beta?: Yes
• Have you checked for system updates?: Yes

Games running with Proton lock Remote Play to 30 fps (+10/-3 interval). Tested on Steam Link for RaspberryPi and AppleTV

Steps for reproducing this issue:

1. Configure Steam Link app to display connection details
2. Open a title that uses Proton. Frame counter drops to 30 fps.
3. Verify by running same title with Proton directly on the computer.
4. Open a title that uses native Vulkan or OpenGL. Frame rate jumps to 59.9 fps.

Both RaspberryPi and AppleTV behave exactly the same.

[lavadrop]

FFXIV reports 59 fps, but Remote Play drops to 30 fps.

No Man's Sky drops to 30 fps in borderless window when the program isn't focused, like when Steam Remote Play is capturing the background window.

No Man's Sky returns to 60+ fps when it gains focus again.

Super Indie Karts has both a Native version and a Windows version to be used through Proton. Native version makes Steam Remote Play encode video at 60 fps, but Proton drops it to 30, wether the program is focused or not.

Native

Proton

[VoodaGod]

i have also noticed remote play capturing at a very low framerate recently. i remember it being a lot better. disabling hardware acceleration gives me a couple more fps but most games are unplayable like this at around 24 fps strangely Halo MCC has great capture performance even though it's running through proton & dxvk, so i'm not sure that's the sole reason...

[willthong]

I am on Arch Linux and have had a similar problem, both at 1080p and 1440p. It worked fine for me in December. I will provide further details later when I've had to test a variety of clients, and will post some logs too.

[Siysrril]

Hi, I'm having the exact same issue. To me it only happens on games that run on Proton, native games can be streamed just fine at 60 fps.

This issue started happening to me since last stable release of steam client.

Things that I've notice:

• No matter which kernel version I install I get locked sub 30 fps while streaming.
• I tried both steam beta and stable, issue still there.
• Tried multiple proton versions, even non official proton versions issue still happens.
• Issue happens on my Steam Link hardware and in Steam Link Android app
• Hardware decoding/encoding enabled/disabled doesn't fix the issue either.

No matter what I try cannot get back to normal 60 FPS.

My pc specs:

OS: Manjaro Linux KERNEL: 5.16.11-2-MANJARO CPU: AMD Ryzen 7 5800X 8-Core GPU: AMD Radeon RX 5700 XT (NAVI10, DRM 3.44.0, 5.16.11-2-MANJARO, LLVM 13.0.1) GPU DRIVER: 4.6 Mesa 21.3.7 RAM: 16 GB

Here are a couple of screenshots I took, one from Dragon's Dogma (Proton) locked at 30 FPS and the other from Don't Starve Together (native) running just fine.

[waffshappen]

The same is happening here.

As long as the game is focused encoding switches from OpenGL NV12+libx264 to "Game Vlukan RGB + libyuv + libx264" Exactly like back in https://github.com/ValveSoftware/steam-for-linux/issues/7185

If i alt-tab out to the desktop it returns to smooth and locked 60fps software encoding.

So clearly libyuv cant handle 1920x1200@60fps - Not even with 8 encoding Threads on a 2700x. (Or the Vulkan Proton Game Capture is broken)

Steam devs please allow me to untick this - i'd much rather have an additional frame of lag but buttery smooth 60fps over this thing. Or fix libyuv to be able to handle 60fps.

Warframe, focused:

Warframe, alt-tabbed to desktop (Forcing opengl NV12 capture):

Also, as expected disabling dxvk and forcing PROTON_USE_WINED3D=1 %command% works around the issue of course.

[Saroumane]

I can confirm the issue : "Game Vulkan RGB + libyuv + libx264" works for 1280x720@60fps,but is limited at 30fps for 1920x1080 Even with 8 encoding threads on Ryzen 3600X. (On Ubuntu 21.10) By the way, I have an AMD RX 5700XT and I can't manage to activate the "hardware encoding".

Anyway, thanks @waffshappen for the workaround with PROTON_USE_WINED3D=1 %command%

[Siysrril]

I can confirm the issue : "Game Vulkan RGB + libyuv + libx264" works for 1280x720@60fps,but is limited at 30fps for 1920x1080 Even with 8 encoding threads on Ryzen 3600X. (On Ubuntu 21.10) By the way, I have an AMD RX 5700XT and I can't manage to activate the "hardware encoding".

Anyway, thanks @waffshappen for the workaround with PROTON_USE_WINED3D=1 %command%

By 1280x720 you mean having the game you are streaming at that resolution or having the client at 720p?

I cannot get 60 fps at 720p either.

Edit: I managed to get 60fps by running my games windowed mode and setting the in-game resolution to 720. Is not ideal, but at least is not 28fps. Hope we get an update soon.

[Saroumane]

I managed to get 60fps by running my games windowed mode and setting the in-game resolution to 720. Is not ideal, but at least is not 28fps.

@Siysrril Yes, that is exactly how I reached 60 fps with dxvk. But it's better to put PROTON_USE_WINED3D=1 %command% in the Launch Options of your game. If your game is not too demanding, you don't need dxvk : you can achieve better result (1920x1080@60fps) with OpenGL.

[loisgomez]

Suffering from the same issue it has something to do with the fact that Encoding is done through Game vulkan RGB + libyuv + [XXXXXX]. Display latency bumps to 100+ms instead of the usual 20ms

OpenGL games work fine when streamed from my Linux host and also the steam UI itself. Because they use Game Delayed OpenGL NV12 + [xxxx]

Its a Vulkan/Proton issue the way the frames are being captured/encoded

[loisgomez]

I think this other issue refers to this same issue. https://github.com/ValveSoftware/steam-for-linux/issues/5591

[lewiji]

Worth noting that in some games forcing opengl mode via the launch parameter above doesn't entirely fix the issue - recently I had this problem with Cloudpunk and got slightly better results using the parameter, but still way worse latency/frame timing than on desktop. Have been having similar issues with Elden Ring, but haven't tried the parameter there yet.

I too seem to remember this not being a problem last year, but the linked issue above has reports going back a long time.

Seems to also be the case for custom proton builds such as TKG. I haven't yet tried using a non-protonified wine build to see the results there. But I've seen reports that windows users have had similar issues so it may be more to do with the steam streaming tech in general than any specific component. It's difficult to pinpoint exactly on what layer this problem is happening.

[Saroumane]

As we can start a bash script from a game's Launch Options , I would like to detect if "remote play" is active so I can put PROTON_USE_WINED3D=1 behind a condition. (Let's be honest, I have some small graphics with OpenGL that are not present with dxvk. So I prefer to use dxvk when I'm not using remote play) And then I can use this basch script as a workaround for every game that has this issue.

Any idea about how to do it ? Is there a variable or a process name to check ?

[lewiji]

Any idea about how to do it ? Is there a variable or a process name to check ?

Off the top of my head, I don't know a process, though there probably is one you can grep out of a process list if you tested it. But one thing that comes to mind if using nvidia hardware is maybe nvidia-smi can be queried to see if NVENC is active or not.

[Saroumane]

So here is my script to manage both local play and remote play. (For DARK SOULS™ II: Scholar of the First Sin, but it can be easily modified for any game) My setup : Local PC is Ubuntu 21.10 + Xorg in 2160p. Remote is Nvidia Shield with 1080p display.

Step 1 : configure your video settings in Dark Souls 2 for remote play, quit the game and go in ~/.steam/debian-installation/steamapps/compatdata/335300/pfx/drive_c/users/steamuser/AppData/Roaming/DarkSoulsII Then manually copy GraphicsConfig_SOFS.xml to GraphicsConfig_SOFS.xml.remoteplay

Step 2 : configure your video settings in Dark Souls 2 for local play, quit the game and go in ~/.steam/debian-installation/steamapps/compatdata/335300/pfx/drive_c/users/steamuser/AppData/Roaming/DarkSoulsII Then manually copy GraphicsConfig_SOFS.xml to GraphicsConfig_SOFS.xml.localplay

Step 3 : create the startup script. For example :

$ nano ~/scripts/DarkSouls2.sh

Inside, write :

#!/bin/bash

DS2FOLDER="$HOME/.steam/debian-installation/steamapps/compatdata/335300/pfx/drive_c/users/steamuser/AppData/Roaming/DarkSoulsII"

#test if remote play is active by checking if the process steam_monitor is present

if pidof "steam_monitor" ;then
   # remote play is active. Use OpenGL and video settings optimized for remote play (1080p. Window mode is not needed for OpenGL. It's only needed for remote playing with Vulkan)
   export PROTON_USE_WINED3D=1
   cp $DS2FOLDER/GraphicsConfig_SOFS.xml.remoteplay $DS2FOLDER/GraphicsConfig_SOFS.xml
else
   # remote play is not active. Use DXVK and video settings optimized for local play (fullscreen + 2160p)
   export PROTON_USE_WINED3D=0
   cp $DS2FOLDER/GraphicsConfig_SOFS.xml.localplay $DS2FOLDER/GraphicsConfig_SOFS.xml
fi

#start Dark Souls 2
"$@"

Make it executable : $ chmod +x ~/scripts/DarkSouls2.sh

Step 4 : Fill the game's Launch Options (Right-clic the game in the Steam Library / Properties) like this :
~/scripts/DarkSouls2.sh %command%

Enjoy local and remote play freely

[Siysrril]

I did some testing after noticing that some games installed through Lutris and added to Steam as "Non-Steam" games didn't have this issue, I noticed that, for those games, the steam overlay did not load properly.

So I disabled the overlay for some Steam games by adding this to the launch options: LD_PRELOAD= %command%

With that argument the "slow convert" issue doesn't happen, of course there are some side effects while adding that argument, like controller configuration in game not accessible.

To work around that I configure the controller for the game before adding the argument to the launch options.

Also, I think that, with that argument in the launch options, most of what makes the Steam Controller so good is also not accessible.

To me this has been the best workaround I've found so far.

I hope is useful for somebody else.

Edit: Forgot to mention, disabling the overlay in Steam settings > In-game section, doesn't have the same effect as adding LD_PRELOAD= %command% in the launch option, so maybe the issue not the Overlay either?

[Saroumane]

So I disabled the overlay for some Steam games by adding this to the launch options: LD_PRELOAD= %command%

With that argument the "slow convert" issue doesn't happen, of course there are some side effects while adding that argument, like controller configuration in game not accessible.

For me, regarding the encoder used, it does the same as PROTON_USE_WINED3D=1 : it forces the OpenGL encoder instead of Vulkan.

[Siysrril]

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/8423#issuecomment-1100921734

PROTON_USE_WINED3D=1 worked for me too, however performance on a lot of my games was really bad, so I had to look for an alternative.

[VoodaGod]

for me, disabling the steam overlay via the steam setting (without LD_PRELOAD= in launch options) causes the opengl encoder to be used, which results in 60fps (as long as my gpu isn't at 100%...) capture, thanks @Siysrril ! i restarted steam after disabling the steam overlay globally. maybe that makes a difference, since @Siysrril didn't notice an effect

[arodland]

When playing TUNIC in Proton with Remote Play, if I start the game in Windowed mode, and then go into the settings and change it to Fullscreen, the resolution change somehow bumps the streaming to "Desktop OpenGL" and I get smooth 60fps. (Changing it back to Windowed doesn't hurt anything at that point, and makes it so I can use the trick again on the next launch).

[Goggo66]

@Siysrril @VoodaGod Instead of nuking LD_PRELOAD altogether, you could also use PRESSURE_VESSEL_REMOVE_GAME_OVERLAY=1 ... Seems to have the same effect, albeit with the already listed side effects.

[edenist]

Just wanting to shed some light on this as it is still unsolved and still a pretty huge issue. Any capture of a game rendering with vulkan is limited to ~30 fps. This includes both proton+DXVK and native vulkan. Switching to OpenGL rendering for these titles isn't really viable, nor is disabling the overlay as it renders my controller useless.

I'm trying to investigate where the actual bottleneck is occuring [somewhere in the Vulkan capture or perhaps in libyuv?], hopefully we can make some progress on this issue if any subscribers have some further information they have since discovered.

[lewiji]

No new info from me other than it still happens and tbh it's put me off from using remote play as much as I used to. I would say the "limit" isn't a cap or hard limit like vsync or frame limiting. On my system it can be more like 43 fps or something, but the frame timings are really inconsistent and input latency very high.

If the bottleneck is libyuv and can be identified, I wonder if a patched libyuv could be force loaded over the static linked version to help remedy the issue? Depends on exactly what's going on with it. Maybe a debug build of libyuv could be loaded with an LD_ environment variable and profiled somehow? Not sure how feasible it is to do that.

[lewiji]

Well, I tried, and had precisely zero luck, and I've moved over to Moonlight. The input latency feels slightly worse, and the steam controller integration isn't great, but the video, sound and connection are all excellent.

[FaddishDisc7]

On my Manjaro KDE X11 setup, I don't have to put WINED3D in launch command. Instead I disable steam overlay and put at least gamescope -f -- %command% in launch command (must have gamescope installed) and somehow it works at 1080p 60 fps. Gamescope seems to keep the Desktop OpenGL NV12 encoder, possibly leading to a smoother experience. Tested on Batman Arkham Knight, Megaman Legacy Collection, Cuphead and Spyro Reignited Trilogy, using an AMD RX 580.

[joeknock90]

I was able to force the OpenGL encoder just by disabling the steam overlay even without gamescope.

Unfortunately disabling the steam overlay breaks steam input completely.

[urmamasllama]

I have a theory I'd like to confirm. How many people here are using a monitor that supports 10bit color/HDR? I know Linux doesn't support it but some of the backend code in randr at the very least detects it and I'm wondering if that isn't being accounted for in the encoder.

[lewiji]

I have a theory I'd like to confirm. How many people here are using a monitor that supports 10bit color/HDR? I know Linux doesn't support it but some of the backend code in randr at the very least detects it and I'm wondering if that isn't being accounted for in the encoder.

Hmm, my primary monitor supports it, but I have it disabled in the monitor's settings. I've no idea if disabling it there prevents it detecting support or not though, is there a way to check?

[urmamasllama]

I have a theory I'd like to confirm. How many people here are using a monitor that supports 10bit color/HDR? I know Linux doesn't support it but some of the backend code in randr at the very least detects it and I'm wondering if that isn't being accounted for in the encoder.

Hmm, my primary monitor supports it, but I have it disabled in the monitor's settings. I've no idea if disabling it there prevents it detecting support or not though, is there a way to check?

Try: xwininfo -root | grep Depth If you get 24 that's 8 bit of you get 30 that's 10 bit. Afaik xrandr sets it based on the edid data it's presented

[joeknock90]

I have a theory I'd like to confirm. How many people here are using a monitor that supports 10bit color/HDR? I know Linux doesn't support it but some of the backend code in randr at the very least detects it and I'm wondering if that isn't being accounted for in the encoder.

Both of my monitors do indeed support HDR (however I'm not sure which "standard" they support. I assume 10 bit)

xwininfo -root | grep depth returns Depth: 24 for me. I believe I have HDR disabled on both my monitors as well.

I THINK I see where you're going with this and I like it.

[urmamasllama]

I have a theory I'd like to confirm. How many people here are using a monitor that supports 10bit color/HDR? I know Linux doesn't support it but some of the backend code in randr at the very least detects it and I'm wondering if that isn't being accounted for in the encoder.

Both of my monitors do indeed support HDR (however I'm not sure which "standard" they support. I assume 10 bit)

xwininfo -root | grep depth returns Depth: 24 for me. I believe I have HDR disabled on both my monitors as well.

I THINK I see where you're going with this and I like it.

Hmmm well I had this epiphany sitting at my desk at work. I'm getting off in 15 minutes and I have one monitor that's a TN panel that barely even has display port I'm going to try remote play with my HDR monitor completely unplugged and report back.