How to Optimize Arch Linux for Gaming with Steam, Proton, and GPU Drivers

There is a common misconception that gaming on Linux means trading performance for ideology. The reality, if you dig into the numbers and the architecture, is far more interesting. Linux's share on Steam reached 3.20% in November 2025 — a record at the time — then hit 5.33% in March 2026 according to Valve's Steam Hardware and Software Survey, reported by Phoronix as the first time Linux has cleared the 5% mark and more than double macOS for the same month. That March figure deserves a note of precision: the February 2026 survey logged an anomalously low 2.23% due to a well-documented Chinese New Year sampling skew, which Phoronix attributed to a surge in Simplified Chinese usage inflating the denominator; the underlying trend from January (3.38%) to March remains real. Within the Linux segment, SteamOS Holo accounts for 24.48% of reported Linux systems, reflecting the Steam Deck and the early Steam Machine install base — but desktop Linux distributions including Arch, Ubuntu, and Manjaro now make up the majority of the rest, meaning the growth is not solely hardware-driven. Nearly 90% of Windows games now run through Proton according to ProtonDB community data. That is not a niche experiment anymore. That is a platform.

Arch Linux occupies a specific and powerful position within that platform. Unlike Ubuntu, Fedora, or even Manjaro — all valid choices — Arch gives you something fundamentally different: complete transparency and control over every layer of your system. Arch does not install unnecessary background services. This minimalism results in a lower system footprint, leaving more resources available for gaming — and it also reduces your attack surface compared to distros that ship unnecessary daemons and services by default. The Arch User Repository (AUR) provides immediate access to the latest Steam client betas, GPU drivers, and third-party optimization tools like GameMode and MangoHud. If the security implications of running a gaming system interest you, the CompTIA Security+ and cybersecurity training resources at kandibrian.com cover the fundamentals of Linux security in depth.

This guide is not a simple checklist. It is a technical examination of what is happening under the hood when a Windows game runs on your Arch system — and how to make every layer of that process as efficient as possible.

Understanding the Full Stack Before You Touch a Setting

Before you change a single configuration file, you need to understand what you are actually working with. When you launch a Windows game through Steam on Arch Linux, the execution path looks like this: Steam invokes Proton, which is a compatibility layer built on a patched version of Wine. Wine creates a Windows-like environment (called a prefix) in which the game's Windows binary executes. When that game makes DirectX calls — whether DirectX 9, 10, 11, or 12 — those calls do not go directly to your GPU. Instead, they are intercepted by one of two critical translation layers: DXVK or VKD3D-Proton. Those layers translate the DirectX calls into Vulkan API calls, which your GPU driver then handles natively.

Each of these layers — Wine, DXVK, VKD3D-Proton, the GPU driver, the kernel scheduler, the CPU governor — is independently tunable. Understanding where your bottleneck actually lives is the difference between a thoughtful optimization and cargo-culting settings from a forum post.

The GPU Driver Layer: Your Foundation

Nothing else matters if your GPU driver is wrong. This is the absolute foundation of everything.

AMD (Mesa / AMDGPU)

AMD users on Arch have a significant advantage: the open-source Mesa driver stack is fully integrated into the Linux kernel and Mesa library, and it receives updates through pacman directly. The relevant packages are:

$ sudo pacman -S mesa lib32-mesa vulkan-radeon lib32-vulkan-radeon libva-mesa-driver lib32-libva-mesa-driver mesa-vdpau

The vulkan-radeon and lib32-vulkan-radeon packages are non-negotiable. Proton, DXVK, and VKD3D-Proton all require Vulkan support to function. Without the 32-bit variant, many older games running through Proton will fail to launch, because the game binary may be 32-bit even on a 64-bit system.

For AMD users wanting bleeding-edge Mesa before it reaches the official Arch repositories, the mesa-git package from the AUR tracks Mesa's development branch. One critical AMD-specific optimization is enabling the amdgpu.ppfeaturemask parameter, which unlocks power profile management features that CoreCtrl and similar tools rely on:

# Add amdgpu.ppfeaturemask=0xffffffff to GRUB_CMDLINE_LINUX_DEFAULT, e.g.:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash amdgpu.ppfeaturemask=0xffffffff"

# Then regenerate GRUB config:
$ sudo grub-mkconfig -o /boot/grub/grub.cfg

NVIDIA (Proprietary Drivers)

NVIDIA's situation on Linux is more complex and requires careful setup. As of driver version 590 (December 2025), Arch Linux officially switched its main NVIDIA packages to use the open-source kernel modules by default. The nvidia-dkms package was replaced by nvidia-open-dkms. This affects Turing (RTX 20xx / GTX 1650) and newer GPUs. Pascal (GTX 10xx) and older cards are no longer supported by the current driver branch and require the legacy nvidia-580xx-dkms package from the AUR. The current production branch as of April 2026 is driver 595.58.03 (released March 24, 2026), which introduced VK_EXT_descriptor_heap, VK_EXT_present_timing, DRI3 v1.2 support, and better Wayland stability. Driver 595 also enables nvidia-drm.ko modeset=1 by default in the driver itself — meaning the explicit kernel parameter is redundant if you are on 595+, though it remains harmless to include.

# Turing (RTX 20xx / GTX 1650) and newer — open kernel modules (default since driver 590):
$ sudo pacman -S nvidia-open-dkms nvidia-utils lib32-nvidia-utils nvidia-settings

# Pascal (GTX 10xx) and older — legacy driver from AUR (driver 590+ dropped these):
# yay -S nvidia-580xx-dkms nvidia-580xx-utils lib32-nvidia-580xx-utils

The multilib repository must be enabled in /etc/pacman.conf to install the lib32-* variants. After installing the NVIDIA driver, add nvidia-drm.modeset=1 to your kernel parameters for Wayland support and improved frame pacing:

# For driver versions older than 560, set modeset manually.
# From 560 onwards, nvidia-utils enables modeset by default via a udev rule.
# From 595 onwards, modeset=1 is the driver default — this param is redundant but harmless.
# Adding both parameters is always safe and recommended for Wayland on any driver version:
GRUB_CMDLINE_LINUX_DEFAULT="quiet nvidia_drm.modeset=1 nvidia_drm.fbdev=1"

# Then regenerate GRUB config:
$ sudo grub-mkconfig -o /boot/grub/grub.cfg

Intel (Arc / Xe)

Intel Arc discrete GPUs — A-series Alchemist and the Battlemage generation — are a viable gaming option on Linux as of 2025 and 2026, though the driver story is more recent than AMD or NVIDIA. Intel's open-source driver stack is built into the kernel and Mesa. There is no proprietary driver to manage. The Xe kernel driver (replacing the older i915 path for discrete Arc) landed in the mainline kernel as of 6.8 and provides significantly better stability and performance than the early i915 path did for these cards.

The required packages on Arch are:

# Intel Arc discrete GPU (A-series / Battlemage)
$ sudo pacman -S mesa lib32-mesa vulkan-intel lib32-vulkan-intel intel-media-driver

# Verify the ANV Vulkan driver is loading:
$ vulkaninfo --summary | grep driverName

The vulkan-intel package provides the ANV (Anvil) Vulkan driver, which is what DXVK and VKD3D-Proton use on Intel hardware. The intel-media-driver package provides VA-API hardware video decode for in-game cutscene performance and video playback. For integrated Intel graphics on 8th-generation and older hardware, use libva-intel-driver (the legacy i965 driver) instead of intel-media-driver — they conflict and serve different hardware generations.

Kernel Selection: Not All Kernels Are Equal

The stock Arch linux kernel is an excellent general-purpose kernel, but gaming has specific demands: low latency, responsive scheduling, and minimal jitter. The linux-zen kernel is the most widely recommended for gaming on Arch. It includes patches for improved interactivity, low-latency preemption tuning, and optimizations that reduce input latency:

$ sudo pacman -S linux-zen linux-zen-headers

The headers package is required if you are using DKMS modules like nvidia-open-dkms. CachyOS, an Arch-based distribution, has pushed some of the most aggressive kernel work for gaming performance, including the CachyOS-optimized kernels available as AUR packages (linux-cachyos). These include the BORE (Burst-Oriented Response Enhancer) scheduler, which improves responsiveness in interactive workloads like games.

Why does the CPU scheduler matter for gaming? A game's frame loop is a real-time-sensitive workload. Each frame, the game thread needs CPU time in a highly predictable, low-latency window. A scheduler that deprioritizes the game process — even briefly — in favor of a background task can cause frame time spikes that register as stutter, even when average FPS looks fine.

Proton: Understanding the Compatibility Layer

Proton was initially released on 21 August 2018, with a list of 27 games certified to perform like their native Windows counterparts. What began as a small curated list has expanded into something that makes Linux a genuinely compelling gaming platform. The current stable release series is Proton 10, rebased against Wine 10, with Proton 10.0-4 (January 26, 2026) as the latest confirmed stable point release. The standalone latest tagged releases for the translation layer components are DXVK 2.7.1 and VKD3D-Proton 3.0b; Proton 10.0-4 incorporated vkd3d-proton 3.0b into the official build.

The term "compatibility layer" understates what Proton accomplishes. Proton is not an emulator. Your CPU is not emulating x86 Windows instructions. Your game binary runs natively on your hardware. What Proton provides is an implementation of the Windows API surface in Linux. When that game makes DirectX calls, they are intercepted by DXVK or VKD3D-Proton, translated to Vulkan, and forwarded to your driver. The translation cost happens at shader compilation time, not at draw call time — which is why the first time you run a game under Proton often involves stutter. Subsequent runs are smoother because those compiled shaders are read from cache.

"Proton uses a combination of Wine and several other projects to allow Windows titles to run on Linux."

— Proton README, Valve Software, GitHub

Installing and Managing Proton

Steam ships its own version of Proton, updated through the Steam client. You can select the Proton version per game: right-click the game in your Steam library, go to Properties, then Compatibility, check "Force the use of a specific Steam Play compatibility tool," and select your version.

The community-maintained Proton-GE (GloriousEggroll's custom Proton build) often provides better compatibility and performance for specific titles. It also includes media codecs missing from the official build. Install protonup-qt from the AUR to manage Proton-GE versions:

$ yay -S protonup-qt

After installation, launch protonup-qt and install the latest GE-Proton release. It will automatically place files in ~/.steam/root/compatibilitytools.d/. The canonical resource for per-game Proton compatibility data is ProtonDB, where the community documents which Proton versions work for specific titles.

Proton 10 and What Changed

Proton 10, released in November 2025, is a significant update with direct implications for Arch gamers. It is built on Wine 10 — which Wine developers described as representing a year of development effort and over 6,000 individual changes — and brings better high-DPI support and Wayland display protocol handling. The Proton 10 release series has received multiple point releases: Proton 10.0-4, the latest confirmed stable release as of April 2026, shipped January 26, 2026, per the Proton changelog, and brought vkd3d-proton updated to 3.0b — meaning the 3.0 upstream release is now included in Proton's official stable branch. Check the Proton releases page for any subsequent updates. You can verify exactly what component versions your installed Proton build ships by checking the version file at ~/.steam/root/steamapps/common/Proton\ 10.0/version and cross-referencing the changelog linked above.

Games newly playable or fixed with Proton 10 include Microsoft Flight Simulator 2024, Warhammer: Vermintide 2, Resident Evil (1996 and 1998 releases), Dino Crisis, Dino Crisis 2, and METAL GEAR SURVIVE among others, along with an ongoing stream of per-title fixes documented in the changelog. Notable fixes include the Steam Overlay failing to work with many EA games, mouse movement in Call of Duty 2, and DCS World Steam Edition launch issues. If you have been running an older stable Proton version on Arch, updating to Proton 10 via Steam's compatibility settings or installing it through protonup-qt is the single highest-impact change you can make.

DXVK: The DirectX 9/10/11 to Vulkan Bridge

DXVK translates DirectX 8, 9, 10, and 11 to Vulkan. Its main purpose is to be combined with Wine and Proton. The reason Vulkan is a better translation target than OpenGL is architectural: Vulkan is a low-overhead, explicit API that gives applications direct control over GPU command queues, memory allocation, and synchronization. OpenGL is a state machine with an enormous amount of hidden driver-side state. Translating DirectX to OpenGL meant fighting the abstraction; translating to Vulkan means working with a comparable level of abstraction.

DXVK is bundled inside Proton, so you do not need to install it separately for Steam games. For games running through vanilla Wine or Lutris, install it manually from the AUR:

$ yay -S dxvk-bin

DXVK's pipeline caching behavior changed significantly with DXVK 2.7. The legacy .dxvk-cache state cache — which stored compiled pipeline objects and lived at ~/.local/share/Steam/steamapps/shadercache/APPID/DXVK_state_cache/ — was removed entirely in DXVK 2.7, as noted in the DXVK 2.7 release notes. It had been effectively superseded since DXVK 2.0 introduced VK_EXT_graphics_pipeline_library (GPL) support. With GPL, pipelines compile from shader bytecode at load time rather than at first draw, making the cache redundant. If you have old .dxvk-cache files from a previous install, they do nothing on DXVK 2.7 and can be deleted. GPU-side compilation caching now happens at the driver level through the Vulkan pipeline cache mechanism and driver-managed disk caches. You can verify DXVK is active and see real-time stats using its built-in HUD:

# Basic HUD
DXVK_HUD=1 %command%

# Comprehensive HUD with frametimes
DXVK_HUD=devinfo,fps,frametimes %command%

# Real-time shader compiler activity — shows active compilation threads:
DXVK_HUD=compiler %command%

VKD3D-Proton: The DirectX 12 Translation Layer

If DXVK handles the older DirectX stack, VKD3D-Proton handles the modern one. VKD3D-Proton is a fork of the original VKD3D project, focusing specifically on implementing the full Direct3D 12 API on top of Vulkan. Unlike the original project, VKD3D-Proton prioritizes performance and game compatibility, aggressively using modern Vulkan extensions and features unavailable when the original VKD3D was written.

VKD3D-Proton 3.0

In November 2025, VKD3D-Proton 3.0 shipped with several landmark changes. The DXBC shader backend was completely rewritten, replacing the legacy vkd3d-shader path — authored by DXVK developer Philip Rebohle. DXVK and VKD3D-Proton now share the same DXBC frontend, which provides a cleaner intermediate representation. Games that were previously completely broken due to bugs in the legacy shader backend — including Red Dead Redemption 2 in D3D12 mode — now work correctly. The release notes also confirmed resolution of issues in Rise of the Tomb Raider, Port Royale, Marvel's Spider-Man Remastered, Mafia: Definitive Edition, and Final Fantasy Tactics: The Ivalice Chronicles, as documented on the VKD3D-Proton 3.0 releases page. The release notes also note that "some recently released DXBC based games also only work on the new path" — meaning the long-tail of newly broken DX12 titles has shrunk significantly with this rewrite. VKD3D-Proton 3.0b — a bug-fix point release addressing a synchronization regression when VK_KHR_unified_image_layouts is not supported — shipped in December 2025 per the VKD3D-Proton releases page. Proton 10.0-4 (January 26, 2026) updated its bundled vkd3d-proton to 3.0b and is the latest confirmed stable release as of April 2026, as confirmed on the Proton releases page.

"Lots of games which used to be completely broken before due to bugs and missing features in the legacy vkd3d-shader backend are now fixed."

— VKD3D-Proton 3.0 release notes, Hans-Kristian Arntzen, November 2025

VKD3D-Proton 3.0 also adds support for AMD FidelityFX Super Resolution 4 through implementation of AGS WMMA intrinsics via VK_KHR_cooperative_matrix and VK_KHR_shader_float8. In the default official build, FSR4 is only exposed on RDNA4 GPUs (RX 9000 series and newer), where VK_KHR_shader_float8 is natively supported. An emulation path for older AMD hardware (RDNA2 and RDNA3) exists but requires building VKD3D-Proton from source with the appropriate build flags — it is not included in the default Proton build due to a significant performance cost in emulation mode. Hans-Kristian Arntzen stated in the release notes that the aim is to ship FSR4 in a more complete form in a future Proton update. DLSS4 has no equivalent native Proton integration as of April 2026; NVIDIA's Frame Generation and DLSS Super Resolution work through DXVK-NVAPI in supported titles, but the Multi Frame Generation feature in DLSS 4 is not yet exposed through the translation stack.

Also notable is experimental support for Work Graphs, a DirectX 12 feature that allows GPU-driven draw calls without CPU intervention per draw. AMD researchers demonstrated this technology by reducing the required VRAM for a 3D-rendered tree scene from 38 GB to just 52 KB using work graphs with mesh nodes — a reduction factor of over 700,000x, documented by Tom's Hardware. VKD3D-Proton's work graphs implementation uses compute shader emulation, meaning it functions on any GPU — not only those with native hardware support — though emulation carries a performance cost relative to future native implementations. That magnitude of VRAM efficiency illustrates exactly why this technology matters for future game engine design and why keeping VKD3D-Proton updated positions you ahead of the curve.

Esync, Fsync, Ntsync: Synchronization Primitives

This is one of the most underexplained aspects of Linux gaming performance. Windows has a rich set of synchronization primitives — mutexes, semaphores, events — that games use extensively for multi-threading. Wine's original approach implemented these through its own wineserver process, which acted as a broker for all synchronization calls. Every time a game thread needed to signal or wait on an event, it made a round trip through the wineserver. Safe and correct, but catastrophically slow for games making thousands of these calls per second.

Esync replaced the wineserver broker with Linux's eventfd file descriptors. Instead of inter-process communication, sync primitives became direct file descriptor operations. Games with many threads could exhaust the system's open file descriptor limit, so you need to increase it. On PAM-based login (the standard for most Arch desktop setups), edit /etc/security/limits.conf. If Steam is launched via a systemd user service or your session uses systemd for login, you also need to set the limit in /etc/systemd/system.conf and /etc/systemd/user.conf:

* hard nofile 524288
* soft nofile 524288

# Add or uncomment in both files under [Manager]:
DefaultLimitNOFILE=524288

Fsync went further, using shared memory and Linux's futex system call. With fsync, synchronization happens entirely in userspace when there is no contention. Only when a lock is actually contested does a kernel system call get made. Modern Proton on kernels 5.16+ supports fsync natively via the futex_waitv syscall. Verify it is active by checking Proton logs:

# Enable Proton logging
PROTON_LOG=1 %command%

# Then check ~/steam-APPID.log for:
# fsync: up and running.

# Disable fsync for titles that exhibit timing issues:
PROTON_NO_FSYNC=1 %command%

Ntsync: The Kernel 6.14 Successor

Ntsync is the next evolution beyond fsync, and it landed in the mainline Linux kernel with version 6.14, released March 24, 2025. The driver was developed by Elizabeth Figura at CodeWeavers — the same engineer who previously wrote both esync and fsync, making her personally responsible for every major synchronization advance in Wine gaming performance over the last decade. She presented the ntsync work at the Linux Plumbers Conference in 2023. It took multiple patch revisions over several years before the kernel maintainers accepted it. An initial, incomplete version was merged in Linux 6.10 but marked "broken" because not all functionality was wired up; it was not usable for gaming in that state. The completed, fully functional driver landed in 6.14, where it is built as a loadable module (CONFIG_NTSYNC=m) on standard kernels. Where fsync implemented Windows synchronization primitives by mapping them onto Linux futexes — a reasonable approximation — ntsync implements them as first-class kernel objects: actual NT synchronization primitives living inside the kernel, not emulated on top of something else.

The architectural reason this matters is specific. Two Windows NT operations cannot be correctly implemented without direct kernel queue control: NtPulseEvent(), which signals an event and immediately resets it before any waiting thread can observe the signaled state, and NtWaitForMultipleObjects() in "wait-for-all" mode, which must atomically wait until every object in a list is simultaneously signaled. Implementing either of these correctly in user space — where you lack atomic visibility across arbitrary thread wait queues — is not possible. Both esync and fsync approximated these operations with workarounds that were mostly correct but could fail in edge cases. Ntsync handles them correctly because the kernel owns the wait queues.

A note on headline benchmark numbers: the widely cited figures (Dirt 3 at 678% improvement, Resident Evil 2 jumping from 26 to 77 FPS — a 196% gain) compare ntsync against vanilla upstream Wine with neither fsync nor esync enabled. Proton users already have fsync, so the real-world gain from migrating to ntsync is meaningful but more modest than those numbers suggest. The more important point is correctness: ntsync is the first time Wine's synchronization has been semantically correct at the kernel level, which eliminates an entire category of subtle timing bugs that produced intermittent stutter or incorrect behavior rather than outright crashes. You can verify ntsync is actively being used — rather than just loaded — with:

# Check for ntsync kernel module
$ modinfo ntsync

# Should return module info if present. Load it:
$ sudo modprobe ntsync

# Make it persistent across boots:
$ echo ntsync | sudo tee /etc/modules-load.d/ntsync.conf

# Verify the device node exists:
$ ls -la /dev/ntsync

# Verify Wine/Proton processes are actually using /dev/ntsync (run while a game is open):
$ lsof /dev/ntsync

With the module loaded and the device node present, Wine 11 and Proton builds based on Wine 11 (or GE-Proton 10-9 and later) will detect ntsync automatically and prefer it over fsync. Wine 11.0, released January 13, 2026, formally merged ntsync support into mainline Wine — meaning any Wine 11+ build on a 6.14+ kernel activates ntsync without any patches, PPAs, or extra configuration. Official Proton 10 is based on Wine 10 and does not carry Wine 11's ntsync integration; GE-Proton 10-9 was the first Proton build to deliver working ntsync support ahead of mainline. You can verify ntsync is active via PROTON_LOG=1 and search the log for ntsync: up and running. If ntsync is not detected but fsync is available, Proton falls back gracefully. Unlike fsync, ntsync does not require any configuration beyond loading the module — there is no Wine registry key or environment variable to set, and by design there is no disable switch either. If the /dev/ntsync device is present and accessible, ntsync is used; if not, Wine falls back silently.

KERNEL=="ntsync", MODE="0644"

GameMode: CPU Governor Management for Gaming

Feral Interactive's gamemode is a lightweight daemon that adjusts system performance settings automatically when a game launches. It works via D-Bus: the gamemoderun wrapper calls gamemode_request_start() over D-Bus before launching the process, and the gamemoded daemon receives that request and applies the configured changes — setting the CPU governor, adjusting the game process's I/O class and niceness, and optionally running custom scripts. When the game exits, the D-Bus connection drops and the daemon reverts all changes.

$ sudo pacman -S gamemode lib32-gamemode

To use it with Steam games, prepend gamemoderun to the launch options:

Linux's default schedutil governor is responsive but has a non-zero reaction time. Under schedutil, there is a brief moment after a game's frame loop starts a new frame where the CPU may still be at a lower clock from the previous frame's idle time. The performance governor eliminates this entirely. On a desktop with adequate cooling, performance is almost always the right choice for gaming. On a laptop, it can cause thermal throttling — making schedutil with a proper TDP limit more consistent.

GameMode also supports igpu_desiredgov, which switches the integrated GPU to a lower-power governor when it is under heavy load (controlled by the igpu_power_threshold ratio of iGPU watts to CPU watts, defaulting to 0.3). This is relevant on systems where both a CPU iGPU and a discrete GPU are active simultaneously. The reaper thread — which checks for exited game clients, re-reads the config file, and monitors the iGPU power balance — runs every 5 seconds by default (reaper_freq=5 in gamemode.ini).

Configuring gamemode.ini

GameMode supports a configuration file at ~/.config/gamemode.ini (per-user) or /etc/gamemode.ini (system-wide). The most powerful feature most users never touch is the startscript and endscript hooks, which run arbitrary shell commands when a game starts and exits. These hooks run as the user and can disable a compositor, kill background services, adjust GPU power limits, or anything else you want to automate at game launch.

[general]
# Comma-separated list of whitelisted processes (leave empty to allow any)
whitelist=

[gpu]
# AMD: set performance mode via DPM (requires root or polkit rule)
apply_gpu_optimisations=accept-responsibility
gpu_device=0
amd_performance_level=high

[cpu]
# On laptops: override to schedutil to prevent thermal throttling
# governor=schedutil
governor=performance

[custom]
# Run a script when a game starts — disable compositor, stop unnecessary services
startscript=/home/YOURUSER/.config/gamemode-start.sh
# Run a script when the game exits — re-enable compositor, restart services
endscript=/home/YOURUSER/.config/gamemode-end.sh

An example start script for a KDE Plasma Wayland session might disable kwin's compositing effects and stop any background sync services during gameplay:

#!/bin/bash
# Suspend Syncthing during gameplay (reduces disk I/O noise)
systemctl --user stop syncthing.service 2>/dev/null
# Tell KWin to disable expensive desktop effects (not compositor — just effects)
qdbus org.kde.KWin /Compositor suspend 2>/dev/null

#!/bin/bash
systemctl --user start syncthing.service 2>/dev/null
qdbus org.kde.KWin /Compositor resume 2>/dev/null

Make both scripts executable with chmod +x. GameMode calls them directly, not via a shell, so they need the shebang line and the executable bit set.

# Verify current governor
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# Set manually (gamemoderun handles this automatically)
$ echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

# Run GameMode's built-in diagnostic test to verify all features are applying:
$ gamemoded -t

Hybrid GPUs and PRIME Offloading

Laptops with both an integrated GPU and a discrete GPU — the standard configuration for any gaming laptop in the last several years — require an extra step that desktop guides often skip entirely. By default on Linux, many of these systems run everything on the iGPU and do not automatically offload to the discrete GPU. Running a demanding game through Steam on the iGPU will produce baffling performance that has nothing to do with your kernel or Proton configuration.

The mechanism for directing a specific application to the discrete GPU is PRIME offloading. For AMD iGPU plus AMD or NVIDIA dGPU combinations, and for Intel iGPU plus NVIDIA or AMD dGPU combinations, the approach is to set the DRI_PRIME environment variable, or for NVIDIA, use the prime-run wrapper.

# Identify your GPU indices:
$ DRI_PRIME=1 glxinfo | grep "OpenGL renderer"

# For AMD/Intel dGPU — run a single app on the discrete GPU:
$ DRI_PRIME=1 %command%

# For NVIDIA dGPU — use the prime-run wrapper (from nvidia-prime package):
$ sudo pacman -S nvidia-prime
$ prime-run %command%

In Steam launch options for a game, set DRI_PRIME=1 %command% (AMD/Intel discrete) or prime-run %command% (NVIDIA discrete). MangoHud's gpu_name metric will confirm which GPU is actually being used once you launch the game.

MangoHud: Seeing What Is Actually Happening

You cannot optimize what you cannot measure. MangoHud is a Vulkan and OpenGL overlay displaying real-time performance metrics, and it is an essential diagnostic tool.

$ sudo pacman -S mangohud lib32-mangohud

The frametimes graph is particularly revealing. A high average FPS with a spiky frametime graph means your game is stuttering even though it "looks fast" in the average. Spiky frametimes often indicate shader compilation events, CPU-GPU sync points, or memory pressure. Consistently high frametimes indicate a sustained bottleneck. These diagnoses require completely different responses.

fps
frame_timing
frametime
gpu_stats
gpu_temp
cpu_stats
cpu_temp
vram
ram
vulkan_driver
engine_version
winesync
text_outline
dynamic_frame_timing
position=top-left
# Show 1st-percentile frametime (more precise than "1% lows"):
fps_metrics=avg,0.01
# Uncomment to enable CSV log output (required for Shift+F2 logging):
# output_folder=/home/YOURUSERNAME/mangologs

Three of those config lines warrant specific explanation. winesync displays which Wine synchronization primitive is active for the current game — it will show ntsync, fsync, esync, or nothing if only the legacy wineserver path is in use. This is the single fastest way to confirm ntsync is actually running for a specific title without digging through Proton logs. dynamic_frame_timing adjusts the frametime graph's Y-axis scale to match the current session's actual minimum and maximum frametime, rather than using a fixed 0–50ms range — critical for noticing whether a stutter spike is 5ms or 45ms above baseline. fps_metrics=avg,0.01 calculates the true 1st-percentile frametime across the sampling period; this is the technically correct metric for worst-case frame delivery and more meaningful than the informal "1% lows" figure that floating-point rounding can distort.

For Steam games, add to launch options:

A particularly useful MangoHud feature is CSV logging. To enable it, set output_folder=/home/YOURUSERNAME/mangologs in your MangoHud.conf (the folder must exist). Then trigger a log capture with Shift+F2 (the default keybind; configurable via toggle_logging in the config). MangoHud writes a CSV to that folder containing time-series data of all active metrics. This lets you correlate stutters with specific events — a GPU memory spike, a CPU frequency drop — in a way that real-time visual inspection cannot. Load the resulting file into any spreadsheet or into flightlessmango.com for interactive graphs.

Wayland vs X11 for Gaming

Display server choice has real and measurable consequences for gaming in 2026. The short answer is that Wayland is now the recommended choice for most Arch gaming setups — but the nuances matter, particularly for NVIDIA users and anyone using a compositor without explicit gaming support.

Under X11, the display server has a global compositor model where frame delivery is not synchronized to the display's vertical refresh in the way Wayland's frame protocol is. This produces screen tearing unless you enable full-scene compositing, which adds its own latency. Variable refresh rate support (FreeSync/G-Sync) under X11 requires the GPU driver to manage VRR directly, with varying results. Proton games running through XWayland (the X11 compatibility layer inside a Wayland session) work correctly for the vast majority of titles.

Under Wayland, compositors like KDE Plasma 6 (using KWin) and GNOME 47+ provide explicit frame timing, better VRR support, and direct scanout — where a fullscreen game bypasses the compositor entirely and presents directly to the display, eliminating all compositor overhead. This is the ideal path for gaming.

For VRR (variable refresh rate) on Wayland, enable it in your compositor's display settings rather than through the GPU driver directly. In KDE Plasma 6, go to System Settings — Display and Monitor — and enable "Allow Variable Refresh Rate (VRR)" per display. In GNOME, VRR support arrived with GNOME 47 and is enabled per display in Settings — Displays. Your monitor must advertise FreeSync or G-Sync compatibility, and the GPU must support it (all modern AMD, NVIDIA, and Intel Arc GPUs do).

Gamescope: Valve's Nested Compositor

Gamescope is a nested Wayland compositor developed by Valve. It runs your game inside an isolated Wayland session, intercepts the game's output, and handles upscaling, frame pacing, and VRR independently of whether the game itself supports those features. It is the default session layer on SteamOS and Steam Deck, and it is available on Arch for desktop use.

Install gamescope from the official Arch repositories:

$ sudo pacman -S gamescope

Why Gamescope Matters Beyond Simple Upscaling

The primary reason to use gamescope on a desktop Arch system is frame pacing. Many games — including many running through Proton — have inconsistent present timing: they may submit frames to the display at irregular intervals even when the game loop is running at a steady framerate. The compositor then displays those frames as received, making the inconsistency visible as micro-stutter. Gamescope intercepts the game's frames and presents them at precise, display-synchronized intervals using its own scanout path. This is the same technique that console gaming hardware uses to deliver smooth frame delivery even when game engine timing is imperfect.

A secondary benefit is upscaling independence. Games that do not support FSR or DLSS natively can have upscaling applied by gamescope at the compositor level, regardless of engine or anti-cheat constraints. The game renders at a lower internal resolution and gamescope upscales the output before it hits your display.

Basic Usage in Steam Launch Options

# Run game at 1080p inside a 1440p display with FSR upscaling:
gamescope -w 1920 -h 1080 -W 2560 -H 1440 --fsr-upscaling -- %command%

# Run at native resolution, enforce VRR, cap framerate at 144:
gamescope -W 2560 -H 1440 --adaptive-sync -r 144 -- %command%

# Full-screen mode with NIS (NVIDIA Image Scaling) instead of FSR:
gamescope -w 1920 -h 1080 -W 2560 -H 1440 --nis-upscaling -f -- %command%

# Combine with gamemoderun and MangoHud:
gamemoderun gamescope -W 2560 -H 1440 --adaptive-sync -r 165 -f -- MANGOHUD=1 %command%

The flags follow a consistent pattern: lowercase -w and -h are the game's internal render resolution; uppercase -W and -H are the output resolution. When these differ, upscaling is applied. -f requests fullscreen. -r sets a framerate cap enforced by gamescope rather than by the game itself. --adaptive-sync requests VRR on the output display.

Gamescope and HDR

Gamescope is also the primary path for HDR gaming on Linux. HDR support in gamescope requires a kernel with DRM HDR patches (available in linux-cachyos and some AUR kernel builds), a compositor that exposes HDR (KDE Plasma 6.1+ with the experimental HDR toggle enabled), and a display connected over DisplayPort or HDMI 2.0+ with HDR capability advertised in its EDID. Enable it with --hdr-enabled:

gamescope -W 2560 -H 1440 --hdr-enabled --adaptive-sync -f -- %command%

Kernel Parameters: Surgical Tuning

Kernel parameters can have meaningful effects on gaming, but precision matters more than maximalism. The following are well-understood parameters with documented effects relevant to gaming.

vm.swappiness

This controls how aggressively the kernel moves RAM pages to swap. The default is 60. For gaming on a system with sufficient RAM (16 GB+), a lower value keeps game data in RAM longer. Setting it to 0 is aggressive and can cause out-of-memory conditions on memory-constrained systems. A value of 10 is a conservative reduction that avoids excessive swapping while not completely disabling the safety valve.

One important caveat: vm.swappiness only matters if your system is under memory pressure and actually approaching the point of paging. On a machine with 32 GB RAM running a game that uses 14 GB, swap is unlikely to be touched regardless of this setting. If MangoHud's ram metric shows you have several gigabytes of free RAM during gameplay, this parameter is doing nothing for you. It is worth setting as a precaution, but it should not be the first thing you reach for when diagnosing a performance issue.

vm.swappiness=10

CPU Scheduler Granularity

The EEVDF scheduler uses two timing parameters to control how often it switches between tasks: sched_min_granularity_ns and sched_wakeup_granularity_ns. The minimum granularity is the shortest time a task runs before the scheduler considers preempting it. The wakeup granularity controls how much advantage a freshly woken task gets before the scheduler can preempt it in favor of the current task.

For gaming, which generates bursty frame-loop CPU demand, reducing these values makes the scheduler more responsive to wakeup events at the cost of slightly more context switches. The linux-zen kernel already applies tuned defaults here; if you are on the stock linux kernel and cannot switch, setting these values in sysctl provides a portion of the benefit:

vm.swappiness=10
# Reduce scheduler granularity for more responsive CPU wakeups (stock kernel only)
# linux-zen and linux-cachyos already apply tuned defaults; skip these on those kernels
kernel.sched_min_granularity_ns=500000
kernel.sched_wakeup_granularity_ns=250000

threadirqs: Moving Interrupts off Game Threads

By default, hardware interrupt handlers run in hard interrupt context, sharing CPU time with whatever threads happen to be scheduled on those cores. On multi-core systems, network and audio interrupts can land on the same core that your game's render thread occupies, causing brief but measurable latency spikes. The threadirqs kernel boot parameter moves interrupt handlers into kernel threads, making them schedulable entities that the kernel can migrate to less-busy cores.

Add threadirqs to your kernel command line in /etc/default/grub (or the equivalent for your bootloader), then run sudo grub-mkconfig -o /boot/grub/grub.cfg. After rebooting, confirm it is active:

# Verify threadirqs is active: all IRQs should show a thread name
$ cat /proc/interrupts | head -20
# With threadirqs active, most rows will have a thread name in the last column.
# You can also reprioritize specific IRQ threads with chrt or rtkit:
$ ps aux | grep irq

The benefit of threadirqs is most visible in games that are CPU-limited and running on systems with high interrupt load — NVMe-intensive asset streaming, or systems with network-heavy game servers running in the background. On a lightly loaded desktop it may have no measurable effect. Add it and measure with MangoHud's frametime graph before and after a gaming session.

Transparent Hugepages

By default, the kernel uses 4 KB memory pages. With Transparent Hugepages (THP) enabled, the kernel can map large contiguous memory regions — such as those allocated by game engines — with 2 MB pages instead. This reduces TLB (Translation Lookaside Buffer) pressure and improves memory access performance. The madvise setting enables hugepages only for processes that explicitly request them, providing benefit for THP-aware allocators without imposing overhead on processes that do not need it.

Why does TLB pressure matter for gaming? Game engines allocate large arena buffers for mesh data, texture staging, and entity state. Without hugepages, a 64 MB mesh buffer requires 16,384 individual 4 KB page table entries. Every cache miss that falls outside the TLB's coverage triggers an expensive page table walk. With 2 MB hugepages, that same 64 MB buffer needs only 32 entries — two orders of magnitude fewer TLB entries for the same data, reducing the frequency of page table walks during draw call setup.

w /sys/kernel/mm/transparent_hugepage/enabled - - - - madvise

I/O Scheduler

For NVMe SSDs, the optimal I/O scheduler is none (also called noop). NVMe drives have their own sophisticated internal queuing, and the Linux I/O scheduler's queueing and reordering logic just adds latency on top. Add a udev rule to set this at boot for all NVMe devices:

ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/scheduler}="none"

Multilib: Enabling 32-bit Support

Many games, especially those using Proton or Wine, rely on 32-bit libraries. Even when the game itself is 64-bit, its dependencies or the Wine runtime components may require 32-bit libraries. Enable multilib in /etc/pacman.conf:

"The multilib repository allows the user to run and build 32-bit applications on 64-bit installations of Arch Linux."

— Arch Wiki: Official repositories — multilib

[multilib]
Include = /etc/pacman.d/mirrorlist

Then update and install the core 32-bit packages for your GPU:

$ sudo pacman -Syu

# For AMD:
$ sudo pacman -S lib32-mesa lib32-vulkan-radeon lib32-vulkan-icd-loader

# For NVIDIA:
$ sudo pacman -S lib32-nvidia-utils lib32-vulkan-icd-loader

Per-Game Launch Options

The community around Linux gaming has developed a sophisticated understanding of per-game tuning, captured in ProtonDB. A few commonly needed launch options and what they actually do:

PROTON_USE_WINED3D=1 — Forces Proton to use Wine's built-in WineD3D renderer (OpenGL-based) instead of DXVK. Slower in general, but useful for games that have bugs in DXVK's implementation. A narrow set of very old titles (some DirectX 8 games) run more stably through WineD3D than through DXVK's DX8 layer.

DXVK_ASYNC=1 (deprecated — do not use) — This environment variable was removed from upstream DXVK starting with DXVK 2.0 and has been absent from all modern Proton and GE-Proton releases since early 2023. DXVK 2.0 introduced the VK_EXT_graphics_pipeline_library (GPL) extension, which compiles shaders at load time rather than at draw time, achieving better stutter reduction without the visual artifacts or shader cache corruption that plagued the async patch. On NVIDIA drivers 520.56.06 or newer and Mesa 22.2 or newer (AMD/Intel), GPL activates automatically with no configuration needed. If you are on an older driver that does not support GPL, the community fork dxvk-gplasync provides a patched DXVK build that re-enables async compilation for legacy hardware.

RADV_PERFTEST=gpl — For AMD users on Mesa drivers older than 22.2, this environment variable explicitly enables the Graphics Pipeline Library extension in RADV before it was turned on by default. If you are running a current Arch Mesa package (Mesa 22.2+), GPL is already active and this variable does nothing — but it is harmless to include. On Mesa below 22.2, it is the difference between GPL shader pre-compilation and fall-through to slow synchronous compilation.

There is a nuance worth understanding here. GPL changes when shaders compile, not whether they compile. With GPL, DXVK compiles the pipeline library stages (vertex input, pre-rasterization, fragment output) when the game submits its shader bytecode — typically during load screens or asset streaming — rather than when the first draw call using that pipeline fires. The result is that stutter moves from gameplay to load screens. On Unreal Engine games specifically, this benefit is partial: Unreal loads shaders lazily at first draw rather than during loading, so GPL moves some but not all compilation out of gameplay. DXVK_HUD=compiler will show you whether compilation threads are active during the load screen (GPL pre-compilation working) or only appearing during the first minutes of gameplay (late-loading behavior).

PROTON_ENABLE_NVAPI=1 — Enables NVIDIA's NVAPI layer inside Proton, exposing NVIDIA-specific GPU features to the game. This is required for DLSS 2 (Super Resolution) and DLSS 3 (Frame Generation) in supported titles. Without it, the game either cannot detect an NVIDIA GPU at all through its feature query path, or falls back to other upscalers. Note that DLSS 4 (Multi Frame Generation, released with RTX 50 series) requires a more recent dxvk-nvapi build — check the dxvk-nvapi GitHub releases for the minimum version your target game needs. DLSS Super Resolution (DLSS 2 and 3) works broadly with Proton 9+ and dxvk-nvapi 0.7+.

WINE_FULLSCREEN_FSR=1 — Enables AMD's FidelityFX Super Resolution upscaling at the Wine/Proton level. Applies to any game regardless of whether the game itself supports FSR, by intercepting the presentation layer. Pair with WINE_FULLSCREEN_FSR_STRENGTH=2 (values 0–5, lower = sharper) to control the sharpening pass. This works on any GPU — AMD, NVIDIA, Intel — because it operates at the Wine layer, not the hardware layer.

PULSE_LATENCY_MSEC=60 — Increases PulseAudio's buffer size to 60 milliseconds. Useful when game audio crackles during CPU spikes, particularly during shader compilation events. If you have migrated from PulseAudio to PipeWire (which Arch installs by default with pipewire-pulse), the equivalent is PIPEWIRE_LATENCY=60/1000 %command% — PipeWire respects the same variable name through its PulseAudio compatibility layer, but the native variable gives you more precise control over the latency fraction.

PROTON_NO_ESYNC=1 / PROTON_NO_FSYNC=1 — Disables esync or fsync respectively. Useful when a specific game exhibits timing bugs or crashes that are caused by the synchronization implementation rather than fixed by it. A small set of older titles — particularly some using custom anti-cheat or DRM that makes unusual assumptions about thread synchronization timing — run more stably with these disabled.

Controller Support on Arch Linux

Controller support is an area where Linux has improved substantially over the last several years, but there are enough moving parts that it is worth addressing explicitly rather than assuming everything works out of the box. The picture varies significantly by controller family.

Xbox Controllers

Wired Xbox 360 and Xbox One controllers work via the built-in xpad kernel module with no additional setup. Xbox Series X|S controllers over USB also work out of the box. For Xbox Series X|S controllers over wireless (using the Microsoft Xbox Wireless Adapter dongle), the xpad module does not support the newer wireless protocol — install xone-dkms from the AUR instead, which supersedes the older xpadneo and xow approaches for the current wireless dongle:

# Xbox Series wireless adapter support:
$ yay -S xone-dkms

PlayStation Controllers

DualShock 4 and DualSense controllers both work natively on Arch. The kernel's hid-sony module handles DualShock 4 over USB and Bluetooth. DualSense (PS5) is handled by hid-playstation, which is present in the mainline kernel from 5.12 onward. Both support haptics and gyro when accessed through Steam Input on current Proton builds.

DualSense over Bluetooth requires bluez and bluez-utils. After pairing (bluetoothctl), Steam's DualSense support in Proton 10 includes haptic feedback translation for games that implement the Windows DualSense API — the Proton 10 changelog specifically calls out improved DualSense handling.

Steam Input and udev Rules

Without correct udev rules, controllers connected while Steam is not running as root may not be accessible. Steam ships a udev rules file that grants the current user read/write access to known controller devices. Install it from the AUR if it is not already present:

# Install Steam's udev rules for controller access:
$ sudo pacman -S steam-devices

# Reload rules without rebooting:
$ sudo udevadm control --reload-rules && sudo udevadm trigger

Your user must also be a member of the input group for Bluetooth controllers to work correctly when Steam is running:

$ sudo usermod -aG input $USER
# Log out and back in for the group change to take effect.

Steam Input Configuration

Steam's Input subsystem — accessed via Steam Settings — Controller — External Gamepad Settings — provides remapping, gyro support, action-set switching, and per-game profiles. When enabled for a controller, Steam exposes a virtual Xbox 360 controller to games using traditional DirectInput or XInput APIs, while also offering its own Steam Input API layer to games that opt into it. This is what allows, for example, a DualSense to have its touchpad used as a secondary input in games that do not natively support it.

A common issue: if a controller works in Steam's interface but not in-game, Steam Input may be in legacy mode passing raw events that conflict with the game's expectations. Per-game, try toggling "Enable Steam Input" in Properties — Controller — Override for that specific title. The inverse is also possible: if a game requires Steam Input and you have it disabled, the controller will not respond in-game at all — this is a known behavior for Among Us and a handful of other titles on Linux.

hidraw vs joydev: Why DualSense Haptics Require the Right Interface

On Linux, input devices can be accessed through two different kernel interfaces: joydev (the traditional /dev/input/jsN joystick interface) and hidraw (direct HID device access via /dev/hidrawN). Steam Input prefers hidraw because it provides access to the full HID report structure of the device — including output reports used to control haptics, LED color, and trigger resistance on DualSense. The joydev interface exposes only axis and button events.

If DualSense haptic feedback is not working in a Proton game even though the controller is recognized, the likely cause is Steam falling back to the joydev interface rather than hidraw. Verify that the steam-devices package is installed and its udev rules are loaded — these rules grant the input group read/write access to /dev/hidrawN devices for known controllers. Without the write permission on the hidraw node, Steam cannot send output reports and haptics silently fail.

# Identify which hidraw node your DualSense is using:
$ ls -la /dev/hidraw*
$ udevadm info --query=all /dev/hidraw0 | grep -i "sony\|playstation\|dual"

# Verify the input group has write access (mode should be 0660 with steam-devices rules):
$ ls -la /dev/hidraw* | grep -i rw

# Reload udev rules if steam-devices was just installed:
$ sudo udevadm control --reload-rules && sudo udevadm trigger

SDL_GAMECONTROLLERCONFIG: Per-Game Mapping Overrides

For games that use SDL2's controller input (which includes many Proton-wrapped titles and most games using SDL natively on Linux), the SDL_GAMECONTROLLERCONFIG environment variable allows you to inject or override controller mappings without using Steam Input. This is useful when Steam Input is causing conflicts, or for a non-Steam executable where you cannot access Steam's per-game override.

The format follows the SDL2 gamecontroller mapping string: a comma-separated list of fields starting with the controller's GUID, a name, and then axis and button mappings. The community-maintained SDL_GameControllerDB project maintains a comprehensive database of mapping strings for virtually every controller. Copy the appropriate string and pass it as a launch option:

# Find your controller's GUID:
$ sdl2-jstest --list

# Or from the SDL_GameControllerDB file for your controller model:
SDL_GAMECONTROLLERCONFIG="030000004c050000cc09000000000000,PS4 Controller,a:b0,b:b1,..." %command%

Diagnosing Stutter: A Systematic Approach

Stutter on Linux gaming has several distinct causes that require different responses. Applying random launch options from a ProtonDB report without understanding which problem you actually have is the definition of cargo-culting. MangoHud's frametime graph is your primary instrument. Enable it and characterize what you are seeing before changing anything.

Periodic stutter on first play session only, smooth afterward. This is shader compilation. DXVK and VKD3D-Proton are compiling shaders the first time they encounter each draw call configuration, then caching the result. Run through the affected area twice. If the second pass is smoother, this is confirmed. No action needed beyond completing the warm-up pass. Deleting a game's compatdata folder resets the shader cache and forces recompilation.

Random frametime spikes at irregular intervals, GPU utilization briefly drops. This is often a CPU bottleneck or a synchronization issue. Check MangoHud's CPU thread utilization. If any CPU thread is pegged at 100% during the spikes, you are CPU-limited. Verify ntsync is active — the overhead reduction matters in this case. Check whether the game has more threads than your CPU's physical cores; if so, taskset can pin the game to performance cores on hybrid architectures (Intel 12th gen+).

Consistent high frametimes, GPU utilization stuck below 90%. You are CPU-limited, not GPU-limited. GameMode's performance governor matters here. Check whether your CPU is thermally throttling with MangoHud's cpu_temp. If temperatures are high, the problem is thermal, not configurational.

A subtler variant of this diagnosis is CPU frequency scaling mid-frame. If the CPU governor is on schedutil or powersave rather than performance, the CPU may drop its clock frequency during the inter-frame gap (when the game thread is briefly idle after submitting a draw call batch) and then need time to ramp back up when the next frame begins. This produces characteristic frametime variance that looks irregular even at low load. MangoHud does not directly expose CPU frequency, but you can observe it from a terminal with watch -n 0.5 "grep MHz /proc/cpuinfo | head -8" while gaming. If you see the frequency bouncing between 800 MHz and 4500 MHz in a 500ms window, your governor is the source of the variance. GameMode's performance governor fixes this immediately.

Consistent high frametimes, GPU utilization at 99%. You are GPU-limited. Lower in-game resolution or settings. Check VRAM usage with MangoHud's vram — if VRAM is full, the driver is paging to system RAM, which explains the sustained bottleneck. No Proton configuration change will fix a VRAM-limited workload.

DX12 game: frametime spikes at irregular intervals despite adequate GPU and CPU headroom. For games using VKD3D-Proton, a less common but diagnosable source of stutter is descriptor heap exhaustion. DX12 games allocate descriptor heaps (tables describing shader-visible resources) and some games, particularly those with aggressive resource streaming, can exhaust the default heap size. VKD3D-Proton logs a warning when this occurs: enable VKD3D_DEBUG=fixme in your launch options and search the output for descriptor heap references. If you find them, the workaround is to increase the heap size with VKD3D_CONFIG=dxr (which enables the full DXR ray tracing path, implicitly increasing heap allocation budgets) or to set VKD3D_DESCRIPTOR_QA_LOG=heap-overflow.log to capture the overflow events for diagnosis. This is a narrow issue affecting a specific subset of resource-heavy DX12 titles, not a general tuning recommendation.

Audio crackle and stutter correlated with GPU spikes. The audio thread is losing time during heavy GPU work. Set PIPEWIRE_LATENCY=60/1000 (or PULSE_LATENCY_MSEC=60 for PulseAudio) in your Steam launch options. This increases the audio buffer at the cost of a trivial latency increase.

# Add to ~/.config/MangoHud/MangoHud.conf for stutter investigation:
fps
frame_timing
frametime
gpu_stats
gpu_temp
cpu_stats
cpu_temp
vram
ram
gpu_name
cpu_power
gpu_power
# Enable CSV logging to correlate spikes with metrics:
output_folder=/home/YOURUSERNAME/mangologs
log_duration=300

The Anti-Cheat Reality

Easy Anti-Cheat and BattlEye — the two prevalent anti-cheat solutions — both have official support for Linux/Proton, but the decision to enable that support is left to individual game developers. Many competitive shooters still disable it, meaning those titles cannot run under Proton regardless of how well your system is configured.

The resource to consult is areweanticheatyet.com, a crowdsourced database that tracks Linux anti-cheat status per game. Before attempting to run a multiplayer game through Proton, check here first.

It is worth understanding what anti-cheat software actually does at the system level. On Windows, kernel-mode anti-cheat (KMAC) solutions like Easy Anti-Cheat and Vanguard run as kernel drivers, giving them ring-0 access to inspect and control the entire OS. On Linux, EAC and BattlEye operate in userspace through the Proton runtime — they have significantly less system visibility than their Windows kernel-mode equivalents. This is part of why Linux is sometimes perceived as a lower-cheat-risk environment from an operator perspective, but it also means anti-cheat that relies on kernel introspection simply cannot function the same way. For a technical examination of how cheating, DDoS resilience, and anti-cheat infrastructure interact on Linux dedicated servers, see the detailed guide on hardening Linux game servers against cheaters.

How to Set Up and Optimize Arch Linux for Gaming

Step 1: Install GPU Drivers and Enable Multilib

Enable the multilib repository in /etc/pacman.conf and install the correct GPU driver packages including 32-bit variants. For AMD install mesa, lib32-mesa, vulkan-radeon, and lib32-vulkan-radeon. For NVIDIA install nvidia-open-dkms, nvidia-utils, and lib32-nvidia-utils (Turing/RTX 20xx+ only; Pascal/GTX 10xx users need nvidia-580xx-dkms from the AUR). Add the required kernel parameters — nvidia-drm.modeset=1 for NVIDIA or amdgpu.ppfeaturemask=0xffffffff for AMD — and regenerate your bootloader configuration.

Step 2: Select a Gaming-Optimized Kernel and Configure Steam with Proton 10

Install the linux-zen kernel and linux-zen-headers via pacman for lower input latency and improved scheduler responsiveness. In Steam Settings, navigate to Compatibility and enable Steam Play for all titles. Install Proton-GE using protonup-qt from the AUR for improved compatibility on specific titles. For current titles, select Proton 10 per game in Properties under the Compatibility tab. Proton 10.0-4 is the latest stable release; vkd3d-proton 3.0b and vkd3d 1.18 were bundled starting with 10.0-4. Standalone latest releases are DXVK 2.7.1 and VKD3D-Proton 3.0b.

Step 3: Install GameMode and MangoHud

Install gamemode, lib32-gamemode, mangohud, and lib32-mangohud via pacman. Add gamemoderun mangohud %command% to Steam launch options for games you want to monitor and optimize. Create a MangoHud config at ~/.config/MangoHud/MangoHud.conf to enable the metrics you want displayed: fps, frametime, gpu_stats, cpu_stats, vram, and vulkan_driver. Optionally create ~/.config/gamemode.ini to configure custom start and end scripts — for example, to suspend background sync services at game launch and resume them on exit.

Step 4: Consider Gamescope for Frame Pacing

Install gamescope via pacman. For games with micro-stutter that persists after shader warm-up, prepend gamescope -W NATIVEW -H NATIVEH --adaptive-sync -f -- to the Steam launch options. Gamescope intercepts the game's frame output and presents frames at display-synchronized intervals, eliminating irregular present timing independent of the game engine. For upscaling on any GPU, use gamescope -w RENDERW -h RENDERH -W NATIVEW -H NATIVEH --fsr-upscaling -f --.

Step 5: Apply Kernel Parameters for Gaming Performance

Create /etc/sysctl.d/99-gaming.conf and set vm.swappiness=10 to reduce swap pressure on systems with adequate RAM. If you are on the stock linux kernel, also set kernel.sched_min_granularity_ns=500000 and kernel.sched_wakeup_granularity_ns=250000 for more responsive CPU wakeups (linux-zen and linux-cachyos already apply tuned defaults). Enable transparent hugepages in madvise mode via /etc/tmpfiles.d/thp.conf. For NVMe SSDs, add a udev rule setting the I/O scheduler to none for all nvme devices. Optionally add the threadirqs kernel boot parameter to move interrupt handlers off game threads on CPU-limited systems.

Frequently Asked Questions

Do I need separate GPU driver packages for 32-bit game support on Arch Linux?

Yes. Many games and Proton runtime components require 32-bit libraries even on 64-bit systems. You must enable the multilib repository in /etc/pacman.conf and install the lib32 variants of your GPU driver packages. For AMD this means lib32-vulkan-radeon; for NVIDIA it means lib32-nvidia-utils. Without these, many games will fail to launch with cryptic missing-library errors.

What is the difference between DXVK and VKD3D-Proton?

DXVK translates DirectX 8, 9, 10, and 11 calls to Vulkan. VKD3D-Proton translates DirectX 12 calls to Vulkan. Both are bundled inside Proton and activate automatically depending on which DirectX version a game uses. VKD3D-Proton is a fork of the original VKD3D project that prioritizes performance and aggressively uses modern Vulkan extensions.

What is gamescope and do I need it?

Gamescope is Valve's nested Wayland compositor, available on Arch via pacman. It runs the game inside an isolated display session and handles frame pacing, upscaling, and VRR independently of the game engine. The main reason to use it on a desktop is frame pacing: it enforces precise, display-synchronized frame delivery even when a game's own present timing is irregular, eliminating a category of micro-stutter that neither kernel tuning nor Proton configuration can fix. It is also the practical path for applying FSR or NIS upscaling to any game regardless of engine support. In Steam launch options: gamescope -W NATIVEW -H NATIVEH --adaptive-sync -f -- %command%. Not every game is compatible — check whether the game launches before committing to it as a permanent setting.

My DualSense haptics are not working in Proton games — how do I fix it?

DualSense haptics require Steam to access the controller via the hidraw kernel interface rather than the legacy joydev interface. The steam-devices package installs udev rules that grant the input group read/write access to /dev/hidrawN devices. Verify the package is installed, run sudo udevadm control --reload-rules && sudo udevadm trigger, and confirm your user is in the input group with groups $USER. Without write access to the hidraw node, Steam cannot send output reports and haptics silently fail even though the controller's buttons are recognized.

Can I override controller mappings without using Steam Input?

Yes. Set the SDL_GAMECONTROLLERCONFIG environment variable in the game's Steam launch options with an SDL2 mapping string for your controller. The SDL_GameControllerDB project maintains mapping strings for nearly every controller. Find your controller's GUID with sdl2-jstest --list, look up the matching string in the database, and pass it as SDL_GAMECONTROLLERCONFIG="GUIDSTRING" %command%. This bypasses Steam Input entirely and works for any SDL2-based game.

Should I use the linux-zen kernel or the stock Arch kernel for gaming?

The linux-zen kernel is the most widely recommended choice for gaming on Arch. It includes patches for improved interactivity, a modified CPU scheduler focused on low-latency bursty workloads, and reduced input latency. The stock Arch kernel is a solid general-purpose kernel but lacks these gaming-specific tuning patches. Install linux-zen and linux-zen-headers via pacman.

How do I verify that fsync is active in Proton?

Add PROTON_LOG=1 to your Steam launch options for the game, then check the generated log file at ~/steam-APPID.log after launch. Search the file for the line "fsync: up and running." If you see it, fsync is active. Modern Proton on kernels 5.16 and later supports fsync natively via the futex_waitv system call.

Is DXVK_ASYNC=1 still a valid launch option?

No. DXVK_ASYNC=1 was removed from upstream DXVK with the 2.0 release and has not been present in modern Proton or GE-Proton builds since early 2023. The feature was superseded by the VK_EXT_graphics_pipeline_library (GPL) extension, which compiles shaders at load time rather than at draw time and activates automatically on supported drivers — NVIDIA 520.56.06 or newer, and Mesa 22.2 or newer for AMD and Intel. No environment variable is needed. If your driver does not support GPL, the dxvk-gplasync community fork provides a patched DXVK build as a fallback.

What changed in Proton 10?

Proton 10, released November 2025, is rebased against Wine 10 — which Wine developers described as representing over 6,000 individual changes. The latest confirmed stable release is Proton 10.0-4 (January 26, 2026); vkd3d-proton 3.0b was bundled starting with 10.0-4. Across the Proton 10 release series, games made newly playable include Microsoft Flight Simulator 2024 and Batman: Arkham Asylum GOTY (added in the initial 10.0-1 beta), and Warhammer: Vermintide 2, Resident Evil (1996), Resident Evil 2 (1998), Dino Crisis, Dino Crisis 2, METAL GEAR SURVIVE, and others added across subsequent point releases — all documented in the Proton changelog. Notable per-game fixes include the Steam Overlay with many EA games, DCS World Steam Edition launch, and improved DualSense controller handling. To use it, right-click any game in Steam, go to Properties, then Compatibility, and select Proton 10 from the dropdown. Note that early 10.0 releases had a first-launch regression that corrupted some prefixes — if saves are missing after upgrading, check your Steam Library folder for directories named corrupted_pfx.

What is ntsync and how does it differ from fsync?

Ntsync landed in the mainline Linux kernel with version 6.14. Where fsync mapped Windows synchronization primitives onto Linux futexes as an approximation, ntsync implements them as first-class kernel objects — actual NT synchronization primitives living in the kernel itself. The result is lower overhead, better behavior under high contention, and a more complete implementation of Windows semantics. Wine 11.0 (January 13, 2026) was the first stable Wine release to fully support ntsync. Official Proton 10 is based on Wine 10 and does not yet include Wine 11's ntsync integration; GE-Proton 10-9 was the first Proton build to ship working ntsync support. To use ntsync today on Arch without waiting for mainline Proton to rebase on Wine 11, install GE-Proton via protonup-qt and select GE-Proton 10-9 or newer in per-game compatibility settings. Load the module with sudo modprobe ntsync, make it persistent by adding ntsync to /etc/modules-load.d/ntsync.conf, and verify with PROTON_LOG=1 that Proton reports ntsync: up and running on next launch.

Can I game on Arch Linux with an Intel Arc GPU?

Yes. Intel Arc (A-series Alchemist and Battlemage) is supported through the open-source Xe kernel driver (mainline since kernel 6.8) and the ANV Vulkan driver in Mesa. Install mesa lib32-mesa vulkan-intel lib32-vulkan-intel intel-media-driver via pacman. DXVK and VKD3D-Proton work through ANV like any other Vulkan driver. The main caveat is that Resizable BAR must be enabled in your BIOS/UEFI — Intel Arc depends on ReBAR for full performance in a way AMD and NVIDIA cards do not. Verify it is active by checking that your full VRAM size appears as a prefetchable BAR in lspci -v output.

Should I use Wayland or X11 for gaming on Arch?

Wayland is the recommended choice for gaming on Arch in 2026, particularly with KDE Plasma 6 or GNOME 47+. Wayland compositors support direct scanout (zero-compositor-overhead fullscreen) and proper VRR (FreeSync/G-Sync), and frame timing is generally better than X11. NVIDIA support on Wayland became reliable with driver 555 (explicit sync) and driver 560 (modeset default). Set nvidia_drm.modeset=1 as a kernel parameter. Proton games run through XWayland with broad compatibility. X11 is still viable if you have a compositor that does not support Wayland-native gaming features, but for new Arch installs in 2026, start with Wayland.

Does Arch Linux gaming work on a laptop?

Yes, with two important additions beyond a desktop setup. First, most gaming laptops have both an integrated GPU and a discrete GPU. You must explicitly route games to the discrete GPU using DRI_PRIME=1 %command% (AMD/Intel discrete) or prime-run %command% (NVIDIA discrete, requires the nvidia-prime package). Without this, games may run on the iGPU and perform poorly regardless of configuration. Second, GameMode's default of pinning the CPU to the performance governor can cause thermal throttling on laptops. Monitor temperatures with MangoHud's cpu_temp and gpu_temp, and if throttling is occurring, override GameMode's governor setting to schedutil in ~/.config/gamemode.ini.

What causes first-session stutter and how do I fix it?

First-session stutter in Proton games is shader compilation. DXVK and VKD3D-Proton must compile GPU-native shaders from DXBC/DXIL the first time each draw call configuration is encountered. The compiled shaders are cached — subsequent sessions are smooth. The fix is simply to run through affected areas a second time. If stutter persists across multiple sessions with no improvement, it is not shader compilation — use MangoHud's frametime graph and CPU/GPU utilization metrics to identify the actual source. Deleting a game's compatdata directory at ~/.local/share/Steam/steamapps/compatdata/APPID/ resets the Proton prefix and shader cache entirely.

Do game controllers work on Arch Linux with Steam and Proton?

Yes, with caveats depending on the controller family. Wired Xbox 360, Xbox One, and Xbox Series X|S controllers work via the built-in xpad kernel module with no extra packages. Xbox Series X|S wireless (dongle) requires xone-dkms from the AUR. DualShock 4 and DualSense both work natively — DualSense via hid-playstation present in kernels 5.12 and later. Nintendo Switch Pro Controllers work via hid-nintendo from kernel 5.16. The critical dependency for all controllers is Steam's udev rules package: install steam-devices via pacman and run sudo udevadm control --reload-rules. Add your user to the input group for Bluetooth controller access. Steam Input in Controller Settings provides remapping and advanced gyro support on top of the hardware driver layer.

My controller works in Steam but not in-game — what is wrong?

This is almost always a Steam Input configuration conflict. When Steam Input is active for a controller, Steam presents a virtual Xbox 360 controller to the game — but if the game also receives raw evdev input from the real device, the two sources can conflict. In the game's Steam Properties, go to Controller, and change the Steam Input override to either "Enable Steam Input" (forces Steam Input mode) or "Disable Steam Input" (lets the game see the raw device directly). Which setting works depends on whether the game expects Steam Input API or raw XInput/DirectInput. Testing both takes thirty seconds and resolves the issue in the vast majority of cases.

Where are Proton game saves stored, and how do I back them up?

Each game running through Proton gets its own prefix directory at ~/.local/share/Steam/steamapps/compatdata/APPID/pfx/, where APPID is the numeric Steam application ID visible in the game's store URL. Windows-style save paths map into this prefix: a save written to C:\Users\steamuser\Documents\My Games\GameName\ will be at ~/.local/share/Steam/steamapps/compatdata/APPID/pfx/drive_c/users/steamuser/Documents/My Games/GameName/. Some games use Steam Cloud sync and saves live in ~/.local/share/Steam/userdata/STEAMID/APPID/remote/. To back up saves, copy either the relevant subdirectory inside the prefix or the userdata directory for that appid. Do not delete the entire compatdata/APPID/ directory unless you intend to reset the Proton prefix and shader cache for that game, as that will remove all local save data as well.

Can I use mods with Proton games on Arch Linux?

Yes, for the large majority of games. Mods that consist of files dropped into the game's data directory work without any special configuration — the mod files live inside the Steam library on your Linux filesystem and Proton reads them normally. For games using mod managers like Vortex, Mod Organizer 2, or the Nexus Mods app, these are Windows applications that you run through Proton as well. Install them by running the installer .exe through Proton — using STEAM_COMPAT_DATA_PATH=~/.local/share/Steam/steamapps/compatdata/APPID proton run ModManager.exe targeting the same Proton prefix as the game — or manage them through Lutris, which handles Wine prefix management for non-Steam executables cleanly. The key constraint is mod managers that require kernel-mode components or anti-cheat hooks will not function; mods relying on those are rare but exist in some games.

Sources and References

Technical details in this guide are drawn from official documentation and verified sources. All claims about version numbers, release dates, and feature behavior are sourced from primary documentation or contemporaneous reporting.

• Proton GitHub Repository — ValveSoftware/Proton — Proton architecture, changelog, and release notes including Proton 10 component versions
• VKD3D-Proton 3.0 Release Notes — GitHub — Primary source for DXBC backend rewrite, FSR4 support details, Work Graphs implementation, and build flag requirements for the FSR4 emulation path
• Arch Wiki: Gaming — Authoritative ongoing reference for gaming on Arch Linux; package names and multilib configuration verified here
• Arch Wiki: multilib — Source for multilib repository description and setup
• Arch Wiki: Ntsync — Module setup, udev rule requirements, and kernel version compatibility
• ProtonDB — Per-game Proton compatibility data and community-sourced launch options
• DXVK GitHub Repository — doitsujin/dxvk — DXVK technical documentation, Graphics Pipeline Library extension adoption, and legacy async patch deprecation history
• Phoronix: VKD3D-Proton 3.0 Released — Michael Larabel, November 17, 2025 — Contemporaneous reporting on the 3.0 release features
• Phoronix: Steam December 2025 Survey — Michael Larabel, January 1, 2026 — Source for December 2025 Linux market share figure (3.19%) and AMD CPU usage data
• Phoronix: Steam on Linux Tops 5% for First Time — Michael Larabel, April 2026 — Phoronix analysis of the March 2026 Steam Hardware Survey showing Linux at 5.33%, a historic first above 5%
• Valve Steam Hardware and Software Survey — Primary source for Linux market share figures; March 2026 shows 5.33%
• DXVK 2.7 Release Notes — Philip Rebohle (doitsujin), July 5, 2025 — Source for descriptor buffer CPU overhead reduction, VK_KHR_maintenance5 requirement, VRAM budget enforcement, and state cache removal details
• DXVK 2.7.1 Release Notes — Philip Rebohle (doitsujin), August 30, 2025 — Maintenance release with D3D9 fixes and MSAA regression correction
• Tom's Hardware: AMD Researchers Reduce VRAM of 3D-Rendered Trees from 38GB to 52KB with Work Graphs — June 2025 — Source for the Work Graphs VRAM efficiency demonstration (34.8 GiB to 51 KiB)
• Are We Anti-Cheat Yet — Crowdsourced database tracking Linux anti-cheat compatibility status per game
• dxvk-gplasync — Ph42oN/dxvk-gplasync on GitLab — Community fork providing async compilation for drivers without Graphics Pipeline Library support
• Arch Wiki: Gamepad — Reference for controller kernel module support, xpad, hid-sony, hid-playstation, hid-nintendo, xone, joycond, and Steam Input udev rules on Arch Linux
• Arch Wiki: Steam — Steam Input — Steam Input Configurator behavior, udev rules via steam-devices, input group requirements, and controller override modes per game
• Gamescope GitHub Repository — ValveSoftware/gamescope — Gamescope nested compositor documentation, command-line flags, HDR support requirements, and known limitations for desktop use
• SDL_GameControllerDB — gabomdq on GitHub — Community-maintained SDL2 controller mapping database used with SDL_GAMECONTROLLERCONFIG overrides
• GameMode GitHub Repository — FeralInteractive/gamemode — GameMode daemon documentation including gamemode.ini configuration options, startscript/endscript hooks, D-Bus API, and platform-specific behavior
• WineHQ: Wine 11.0 Release Notes — January 13, 2026 — Official Wine 11 announcement confirming ntsync mainline support, WoW64 architecture completion, and Wayland driver improvements
• Phoronix: NVIDIA 595.58.03 Linux Driver Debuts as Stable R595 Build — Michael Larabel, March 24, 2026 — Source for VK_EXT_descriptor_heap, VK_EXT_present_timing, DRI3 v1.2 support, and modeset=1 default in driver 595
• GamingOnLinux: NVIDIA Driver 595.58.03 Released — March 2026 — Source for 595 stable release date, VK_EXT_descriptor_heap and VK_EXT_present_timing feature confirmation, and the caveat that VKD3D-Proton work still needed before users should expect a performance bump from descriptor_heap
• XDA Developers: Wine 11 Rewrites How Linux Runs Windows Games — 2026 — Source for ntsync benchmark figures (Dirt 3 678%, RE2 196%, Call of Juarez 124%) and baseline comparison methodology (vanilla Wine without esync/fsync)
• GamingOnLinux: NTSYNC for Proton/Wine Now in Linux Kernel 6.14 — January 2025 — Source for ntsync kernel 6.14 merge confirmation and SteamOS 3.7.20 beta integration
• GE-Proton Releases — GloriousEggroll/proton-ge-custom, GitHub — Source for GE-Proton 10-9 as first ntsync-enabled Proton build (July 2025) and GE-Proton 10-34 as current release (March 2026)
• Arch Linux News: NVIDIA 590 Driver Drops Pascal Support; Main Packages Switch to Open Kernel Modules — December 20, 2025 — Official Arch Linux announcement confirming nvidia-open-dkms as default for Turing+, nvidia-580xx-dkms as legacy AUR path for Pascal