Virtual memory mapping might be too low below is the provided solution

As of right now Source 2 in Proton exceeds Linux's default limit for per process memory mapping which is 65530 memory map areas. This is probably a bug and this fix might become irrelevant soon.
For now the limit is just too low. We can confirm this if we run the command sudo sysctl vm.max_map_count or cat /proc/sys/vm/max_map_count and we should get a value of 65530.
Our goal here is to allow the game to utilize more memory map areas.

For this solution we will use a limit of 1048576 of memory map areas as it's the becoming the new default on many Linux Systems.
To permanently change your memory mapping limit you must edit a system file that you will need escalated privileges for.
We will be editing sysctl.conf but depending on your system's configuration you might need to change a different file.

Open the file via the editor of your choice with sudo. For example sudo nano /etc/sysctl.conf and add the line vm.max_map_count=1048576 to the bottom of the file and reboot your machine. If it doesn't work, check if you have another configuration file that could be causing conflicts. As the higher the number in the config name, the later it makes the change to your system. So sysctl.conf will run before 99-sysctl.conf.

• We can temporarily achieve the same result with the following command sudo sysctl -w vm.max_map_count=1048576.
  
• You can read about max_map_count and memory mapping in the documentation provided in the sources.
  
• As per this message from Yoshi, information about a proper Linux build or further Proton support is unknown at this time.
  
  
• As per this message from Yoshi, the Steam Deck might receive further support.
  

This section of the guide was copied over from the official discord as we wanted the information to be more accessible.

Make sure to have Gamemode[github.com] installed before running:

Steam Deck matchmaking unavailable?? currently you have to use
in the launch options. (Warning: SteamDeck is case sensitive!) It's also best to use the lowest settings possible as the game is still unoptimized in the beta.

As per this message from Yoshi, the Steam Deck might receive further support.

Currently not much is needed to improve the performance on AMD.
Best bet is to use the following launch options:
Advanced and experimental launch options:

• Replace <number of threads> with your CPU's thread count
  
• -nojoy disables your controller and joystick

1. Game not launching on a NVIDIA GPU? try adding this command in the launch options:
2. Advanced, experimental launch options:

• Replace <number of threads> with your CPU's thread count
  
• -nojoy disables your controller and joystick

What's better to use: GE Proton or Valve Proton?
Based of my own research on my all AMD setup and the research of similar Linux users, it seems it's currently better to use GE Proton[github.com] over Valve Proton.

If you have an RTX card, do your own testing between DXVK and VK and please submit.
If you have a GTX card, use VK.
If you have an AMD card, use DXVK.
Findings from one of the Discord community members below (thanks @Miuzu):

Running Arch linux, kernel version 6.10.6-arch1-1 with Wayland + sway as window manager.
CPU: Ryzen 5 1600x, GPU: AMD Radeon RX 6600, RAM: 16GB, game installed on SSD
RADV_FORCE_VRS=2x2 vk_radv gamemoderun mangohud %command% -high -nojoy -threads 12 +engine_low_latency_sleep_after_client_tick true +mat_queue_mode 2 +cl_forcepreload 1 -dx11 for launch commands.
Last option interchanged with -vulkan during tests

@awth13 from discord
From @leibniz2574 on discord
Arch Linux
sched ext kernel (forgor the name Xd)
scheduler: bpfland
DE: KDE Plasma6 (Wayland)

Ryzen 5 3600
Radeon RX6600 (MECH 2X)

custom ingame settings: stretch, 100%
From @_tyke on discord
Running Nobara, kernel version 6.10.6 with KDE on top of X11
CPU: 7800X3D
GPU: NVIDIA 3090 (Founders)
RAM: 32GB DDR5 6000 MT/s
Storage: Game is installed on an SSD (WD Black NVMe)
Launch options:
On the majority of tested devices, the differences in both average performance and performance stability are negligible. The two outliers are the powerful machine with a 3090 and an older machine with a 1650, on both of which VK performed significantly better in terms of frame stability.

amd-pstate is the AMD CPU performance scaling driver that introduces a new CPU frequency control mechanism on modern AMD APU and CPU series in Linux kernel. The new mechanism is based on Collaborative Processor Performance Control (CPPC) which provides finer grain frequency management than legacy ACPI hardware P-States. Current AMD CPU/APU platforms are using the ACPI P-states driver to manage CPU frequency and clocks with switching only in 3 P-states. CPPC replaces the ACPI P-states controls and allows a flexible, low-latency interface for the Linux kernel to directly communicate the performance hints to hardware.

In order to maximize performance with AMD CPUs you should enable the p_state driver:

• Arch amd_pstate docs[wiki.archlinux.org]
  
• Thread on how to use amd_pstate driver[bbs.archlinux.org]

What is Resizable BAR?

All gaming PCs produce an on-screen image by way of the CPU processing data – textures, shaders and the like – from the graphics card’s frame buffer. Usually the CPU can only access this buffer in 256MB read blocks, which obviously isn’t very much when modern GPUs regularly have 8GB of video memory or much, much more.

Resizable BAR essentially makes the entirety of the graphics frame buffer accessible to the CPU at once; where it could once sip, it now guzzles. The idea is that once textures, shaders and geometry are loading in faster, games should run faster with higher frame rates.

To enable AMD REBAR you do have to enable it in your BIOS. Enable the setting named Above 4G Decode or >4GB MMIO in your motherboard settings.
Restart your PC and run this test in the terminal:
Which should return something like this:

• VRAM AND BAR should have the same amount to verify that it's working
  
• We did some testing on low end systems and there is marginal differences (take those with a grain of salt)

Thanks again @Miuzu from the discord

If you are still struggling with FPS, disabling your compositor is worth a shot, it seems to have helped me and some other users (X11/XFCE/X) (note: disabling your wayland compositor will render nothing for you)

For NixOS users, to increase your memory map areas limit, just add the following to your /etc/nixos/configuration.nix:
Fix for gyro mouse in Steam input not working, just add the following to your /etc/nixos/configuration.nix:

• Tia maço
  
• MM2000

The current consensus is to disable shader pre-caching. You can disable it globally on steam settings, under Downloads section.

TLDR: Fossilize is, in theory, a useful tool for preventing stutters during real time gameplay. Especially for older hardware, however for most users pre-cache is not necessary. And, even for the users who it IS beneficial for I still recommend turning it off, and instead just watching a replay or live match.
------
My system should be where it is useful, I am unable to connect to a match if I do not pre-compile shaders as I timeout for taking to long to join. Even still, I have pre-cache disabled. From scratch, it takes my CPU three and a half hours to compile just the deadlock shaders. Everytime valve updates the cache, and everytime my gpu driver updates I have to rebuild the cache.

If I either watch a replay or watch a match live, it takes about 10 minutes of watching for all the non-hero-specific shaders to get built. There is actually a DXVK launch argument `DXVK_HUD=compiler ` that will show you the progress for shaders, that you want to put near the beginning of your launch steam launch arguments. (Before the %command%) You can also go to the heroes tab and cycle through all the heroes to compile shaders in the menu.

There are a few other reasons why Fossilize ins't great: one it's just simply overkill. They render over 1.1 million[github.com] frames for deadlock to build the cache, and two weeks later it grew to 1.4 million[github.com] frames. Two: the progress % is incredibly inaccurate. When it starts compiling it estimates it only has 110 thousand frames, causing it to rapidly progress. Three, It also build cache for every single shader any user encounters, which includes workshop contnet. This doesn't matter for deadlock yet, but for games like Hat in Time with massive workshop content this causes the cache to get massive[github.com]. Valve-kiosk or the dev working on it has not responded to any of these issues.

Pre-loading shaders that keep 0 out of 0

Use the following launch args: 1[forums.playdeadlock.com]
Game gets very laggy after 20-30 minutes

Enabling steam overlay might fix it.

If you don't want the overlay, use the following launch args: 1[forums.playdeadlock.com] 2[forums.playdeadlock.com] 3[forums.playdeadlock.com]

Everyone who was active, and the whole Linux community, from the official discord, if anyone feels like they are left out please reach out to use so we can credit you.