Fellowship (2352620)

[abique]

Compatibility Report

• Name of the game with compatibility issues: Fellowship
• Steam AppID of the game: https://store.steampowered.com/app/2352620/Fellowship/

System Information

• GPU: GeForce RTX 4060
• Video driver version: nvidia-open 580.95.05-3
• Kernel version: 6.17.2-arch1-1

I confirm:

• that I haven't found an existing compatibility report for this game.
• that I have checked whether there are updates for my system available.

[abique]

Some discussions related to this:
https://steamcommunity.com/app/2352620/discussions/0/624436409752910156/

Apparently changing the launch command to this fixes it:

echo "%command%" | sed 's/fellowship/fellowship-launcher/' | sh

[RealPeps]

To add to this multiple users in the linux compatibility thread on their discord are reporting various issues.
I would submit a log but personally the game started running fine for me.
Reported issues range from 100 percent cpu utilization for upwards of 5+ minutes leading to consistent crashes/disconnects, completely random crashes/etc.

I've directed people here since issues seem to be system dependent, r7 5700x and 5800x systems being particularly bad.

[Arceliar]

Some discussions related to this: https://steamcommunity.com/app/2352620/discussions/0/624436409752910156/

Apparently changing the launch command to this fixes it:

echo "%command%" | sed 's/fellowship/fellowship-launcher/' | sh

Just to be clear, that doesn't fix the issue, it bypasses the launcher entirely and directly runs the game. The game currently tolerates bypassing the launcher. That could change, and anything which requires using the launcher (e.g. verifying email and linking accounts for twitch drops) is not possible at this time.

[SolidBrave]

• on startup it takes sometimes over 5mins and get the game running (cpu 100%) entire system basicly useless in the meantime.
• The startup video is broken.

yesterday I was able to play with friends fine, but today I got stuck twice after a dungeon and was forced to restart, killed it for me.

cpu 5800x3d and gpu amd 7800x

[JellyJones]

• on startup it takes sometimes over 5mins and get the game running (cpu 100%) entire system basicly useless in the meantime.

You can workaround this by deleting unreal's shader cache everytime before launch.
steamapps/compdata/2352620/pfx/drive_c/users/steamuser/AppData/Local/fellowship/Saved/fellowship_PCD3D_SM5.upipelinecache
The bigger that cache gets, the longer the cpu usage stays at 100%

[SolidBrave]

@JellyJones Awesome workaround thanks.
after deleting the fellowship_PCD3D_SM5.upipelinecache (3.5MiB) the game startet instant ...
But now the game lags at the start once logged in but definitely more enjoyable :D

edit: After a single game session its again 2.6MiB.

[GammaLyrae]

After a lot of experimenting, I determined it was most likely that somewhere in Windows itself or the GPU drivers, a poor configuration for this game was being overwritten with a more sensible one. With this approach in mind, I started looking at UE5 cvars and discovered this.

In /steamapps/compatdata/2352620/pfx/drive_c/users/steamuser/AppData/Local/fellowship/Saved/Config/Windows/, open Engine.ini and add this to the bottom of it.

[/Script/Engine.RendererSettings]
r.ShaderPipelineCache.StartupMode=2

The game will honor it, but immediately remove it. The end result is that the opening menu sequence works as expected and no longer pegs your CPU usage to 100%. I still get a long series of stutters once loading into the stronghold, suggesting that at some point this cvar changes out of Background mode (2) and into Fast mode (1) again. The recommended behavior according to cursory information I've found (qualifier: I am not a game dev) is to use fast mode (1) for loading screens and background mode (2) at any other time.

I don't think the devs of the game are properly managing the PSO cache threads (titled as PSOPrecompilePool #0 through 11 according to the proton logs, on my 7800x3d processor which has 8 cores / 16 threads).

Further discoveries:

The game will honor the r.pso.PrecompileThreadPoolSizeMax cvar. I set it to 4, and verified in the proton logs that only 4 threads were spawned (instead of 12, aka 75% of my available threads, the default). Unfortunately I still experience 100% CPU usage for 8-16 seconds once loaded into the stronghold. I suspect some other background process is running away with all the CPU time, or perhaps a vital thread for issuing draw calls is shared with one of the PSO Precache threads. I'm stepping through a proton log to look at what threads are being spawned with the PoolSizeMax set to 4 and will do further testing.

[GammaLyrae]

even though we're running through proton, the game will honor -corelimit=n and -processaffinity=n values as a launch property (replace n with whatever you want. Core limit is a hard cap, process affinity apparently tries to force the use of that many physical cores. Setting them to the same value should ensure the game runs on exclusively on physical cores)

Stepping through the logs again, no single thread or process spawns more than the limit I defined (8), with the exception of TAsyncThread, which spawned 15 threads on my 16 thread processor. I don't know enough about wine, proton, VKD3D, and unreal engine to determine what TASyncThread is associated with. Searching via duckduckgo is not very informative on this one

I did, however, observe that with -corelimit=8 and -processaffinity=8, the amount of time spent stuttering in the stronghold was significantly reduced. Probably a happy accident by ensuring that a misconfigured background thread isn't sharing CPU time with a higher priority thread like the rendering one. I think I'm at the limit of what I can meaningfully discover or troubleshoot without knowing more about proton and the game.

I do know that when launching the game with -dx11, the entire PSO cache system is not used, as that's only used by DX12. Loading into the game is pretty typical, low CPU usage during the splash screens, opening cinematic plays normally, etc. The high CPU usage still occurs once loading into the stronghold, however. So whatever is going wrong once you've loaded into the game is not a result of how the PSO precaching is configured.

[GammaLyrae]

It appears that through updates to the game, trying to play it with zero tweaking has experienced a regression. It is difficult, if not impossible, to make it past the first loading screen and into the stronghold if the game's own shader cache is present while playing in DX12 (the default.). To date, the only two ways to mitigate this are deleting it (location and process described above by Jellyfish) or inserting this cvar I found into Engine.ini:

[/Script/Engine.RendererSettings]
r.ShaderPipelineCache.StartupMode=2

...which the game promptly removes on boot, but does honor the setting. You can automate the insertion of this line on startup with this steam launch property (thanks to Gwen from the discord for cookin this one up. I learned a lot about bash scripting by taking the time to figure out how this works!)

echo -e "[/Script/Engine.RendererSettings]\nr.ShaderPipelineCache.StartupMode=2\n" >> "$STEAM_COMPAT_DATA_PATH/pfx/drive_c/users/steamuser/AppData/Local/fellowship/Saved/Config/Windows/Engine.ini" ; echo "%command%" | sh

Gwen in the Fellowship discord suspected that the game is using sleep commands in a way that the scheduler in Windows is more keen to interrupt when actual work comes, whereas multiple schedulers in Linux (i've tested EEVDF, BORE, scx_rust) seem content to allow the sleep to continue uninterrupted. After weeks of additional experimentation on my end, I am inclined to agree with this assessment.

The following are dead ends:
-corelimit=n and -processaffinity=n launch arguments. They do result in a change, but don't behave correctly on Linux, the game makes no distinction between physical and logical cores, and threads spawned after the game has launched don't obey the overall limit

Manual changes to thread affinity (Unreal Engine perspective), as documented here: https://unrealution.com/optimization/setting-thread-affinity-in-unreal-engine/ (note: their formatting is incorrect. You don't put a period in front of ThreadConfigs). Many of the threads the game uses aren't categorized and wont obey your priority and core affinity settings.

Unlikely to help with stuttering, freezing, long loading, etc: Changing thread affinity with taskset. The game uses hundreds of threads, many of them are created and then destroyed after they've remained idle for a period. Any newly created threads wont use the affinity you assigned in taskset. You can automate applying your affinity of choice to the task group, but it didn't seem to make a meaningful impact on how the game runs for me - only how responsive my system feels while playing. (Reserving two physical cores for my OS prevents the sleep commands the game uses from tanking my entire system. However, it did nothing to alleviate the in-game stuttering and loading issues.)