Gaming on Fedora 45: Set Up Steam, Proton, NTSYNC and MangoHud

Installing Steam on Fedora 45 pulls in 195 32-bit packages and a kernel module that stays unloaded until the next boot. On an NVIDIA machine, the driver install can build its module for a kernel you are not running yet, so the driver isn’t loaded when you first look for it. Neither is a bug. Both cost an evening if you don’t know they are coming.

Original content from computingforgeeks.com - post 173123

We set up a Fedora 45 gaming stack on an NVIDIA GPU and measured it. That covers Steam, Proton with NTSYNC, GameMode and MangoHud, plus umu-launcher for Windows games outside Steam. Every number below comes from a captured run, and the setup hit three failures, each shown with its fix.

Tested October 2026 on Fedora 45 (kernel 7.2.9) with Secure Boot off, NVIDIA 615.71.09 on a Tesla T4, GE-Proton11-7.

What we measured, and on what

The lab machine was an AWS g4dn.2xlarge: 8 vCPUs, 32 GB of RAM and an NVIDIA Tesla T4. That is a Turing data center card with no display outputs, so it drove a virtual 1920×1080 Xorg screen. We started from the Fedora Cloud image, upgraded it to Fedora 45, and installed the Workstation package group, so the package set matches a desktop install. A desktop GeForce from the RTX 20 series onward, or any Radeon, runs the same steps, with faster numbers. Older GeForce cards need a different driver package, covered in Step 2.

We did not sign in to Steam, so no Steam game was benchmarked. Instead we ran GravityMark, a free GPU benchmark with both a Linux build and a Windows build. The Linux build runs natively on Vulkan. The Windows build ran through GE-Proton on Vulkan, Direct3D 12 and Direct3D 11. Each run used GravityMark’s default scene at 1920×1080 with temporal antialiasing (-temporal 1) and vsync off.

Run	API	Average FPS	Score
Native Linux build	Vulkan	111.5	18628
Native Linux build with GameMode	Vulkan	110.9	18520
Windows build on GE-Proton	Vulkan	110.9	18522
Windows build on GE-Proton	Direct3D 12	110.1	18397
Windows build on GE-Proton, NTSYNC off	Direct3D 12	109.4	18275
Windows build on GE-Proton	Direct3D 11	87.8	14671

Proton cost about 1% on Vulkan and Direct3D 12. That is close to the noise of a single run. The Direct3D 11 path was 21% slower, but we had no Windows machine to compare against, so we can’t say how much of that is DXVK and how much is GravityMark’s own Direct3D 11 renderer. Turning NTSYNC off and GameMode on changed nothing that matters here. The NTSYNC-off run also had Proton logging on, so its 0.7 FPS gap is not a clean measurement of NTSYNC alone. This benchmark keeps the GPU at 98 to 99% load. NTSYNC helps games that are bound by thread synchronization on the CPU, and GameMode’s main lever, the CPU governor, did not exist inside this VM. Both are covered in their steps below.

Step 1: Enable RPM Fusion

Steam and the NVIDIA driver both come from RPM Fusion. Fedora Workstation offers a filtered Steam repo through its third-party repository switch, and a matching one for the NVIDIA driver. Enabling the full free and nonfree repos instead covers Steam, the driver and multimedia codecs with one repo set:

sudo dnf install -y https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm 2>&1 | tail -6; dnf repolist | grep -i rpmfusion

The release packages install, and four RPM Fusion repos appear. The two testing repos were enabled by RPM Fusion’s Fedora 45 release package on our machine:

[1/4] Verify package files              100% | 250.0   B/s |   2.0   B |  00m00s
[2/4] Prepare transaction               100% |  14.0   B/s |   2.0   B |  00m00s
[3/4] Installing rpmfusion-nonfree-rele 100% | 813.8 KiB/s |   7.3 KiB |  00m00s
[4/4] Installing rpmfusion-free-release 100% |  24.3 KiB/s |   7.1 KiB |  00m00s
Warning: skipped OpenPGP checks for 2 packages from repository: @commandline
Complete!
rpmfusion-free                    RPM Fusion for Fedora 45 - Free
rpmfusion-free-updates-testing    RPM Fusion for Fedora 45 - Free - Test Updates
rpmfusion-nonfree                 RPM Fusion for Fedora 45 - Nonfree
rpmfusion-nonfree-updates-testing RPM Fusion for Fedora 45 - Nonfree - Test Updates

Step 2: Install the NVIDIA driver

Skip this step on AMD or Intel graphics. Their Vulkan drivers come from Mesa, which Fedora ships and keeps current. On NVIDIA, install the akmod package, which builds the kernel module locally for each new kernel. This is for RTX 20 series and newer, plus GTX 16 series. The current driver branch dropped Maxwell, Pascal and Volta, so a GTX 750, 900 or 10 series card, or a Titan V, needs akmod-nvidia-580xx instead. Kepler and older cards need even older branches that are mostly unsupported on Fedora 45. Our NVIDIA driver guide for Fedora has the full per-generation table:

sudo dnf install -y akmod-nvidia xorg-x11-drv-nvidia-cuda 2>&1 | grep -E "^(Installing|Upgrading):|Transaction Summary|Total size|Complete|akmod-nvidia|xorg-x11-drv-nvidia " | head -12

The driver comes in at about 640 MB of downloads:

Upgrading:
Installing:
 akmod-nvidia                       x86_64 3:615.71.09-3.fc45              rpmfusion-nonfree 100.2 KiB
 xorg-x11-drv-nvidia                x86_64 3:615.71.09-3.fc45              rpmfusion-nonfree 185.0 MiB
Transaction Summary:
Total size of inbound packages is 642 MiB. Need to download 642 MiB.
[ 3/99] akmod-nvidia-3:615.71.09-3.fc45 100% |   3.0 KiB/s |  45.0 KiB |  00m15s
[ 91/107] Installing akmod-nvidia-3:615 100% |   4.9 MiB/s | 100.6 KiB |  00m00s
Complete!

Don’t run nvidia-smi yet. Force the module build and look at what happened:

sudo akmods --force 2>&1 | tail -4; modinfo -F version nvidia; modinfo -F license nvidia; rpm -qa | grep -E "^kmod-nvidia"

The module was built, but not for the running kernel:

Could not find files needed to compile modules for 7.2.8-300.fc45.x86_64
Are the development files for kernel 7.2.8-300.fc45.x86_64 or the appropriate kernel-devel package installed?
Checking kmods exist for 7.2.9-300.fc45.x86_64 [  OK  ]
modinfo: ERROR: Module nvidia not found.
modinfo: ERROR: Module nvidia not found.
kmod-nvidia-7.2.9-300.fc45.x86_64-615.71.09-3.fc45.x86_64

The install pulled in a newer kernel as a dependency, together with its kernel-devel. akmods builds only where headers exist, so the module exists for the new kernel and the running kernel has no driver at all. The installed kernels show it:

rpm -q kernel-core kernel-devel

Headers exist for the newest kernel only:

kernel-core-7.2.8-200.fc44.x86_64
kernel-core-7.2.8-300.fc45.x86_64
kernel-core-7.2.9-300.fc45.x86_64
kernel-devel-7.2.9-300.fc45.x86_64

Reboot into the new kernel. This is normal on Fedora, and the reboot is the fix. After it, the driver loads and sees the card:

RPM Fusion builds NVIDIA’s open kernel modules for Turing and newer cards, and that is what loaded here:

modinfo -F license nvidia; modinfo -F version nvidia; cat /proc/driver/nvidia/version | head -1

The license reads Dual MIT/GPL, and the version string names the open kernel module:

Dual MIT/GPL
615.71.09
NVRM version: NVIDIA UNIX Open Kernel Module for x86_64  615.71.09  Release Build  (dvs-builder@U22-I3-F05-2-4)  Fri Sep  4 22:33:33 UTC 2026

With Secure Boot on, the kernel refuses an unsigned module. akmods signs it with a local key, and you enroll that key once with mokutil and a reboot through MokManager. Our lab ran with Secure Boot off, so that part is untested here. The NVIDIA guide linked above walks through the enrollment screens.

Step 3: Install Steam

Look at what Steam brings with it before you agree to it. A dry run shows the full transaction:

sudo dnf install --assumeno steam 2>&1 | grep -cE "\.i686|i686 " ; sudo dnf install --assumeno steam 2>&1 | grep -E "Transaction Summary|Installing:|Install |Total size|ntsync|steam-devices|^ steam "

There are 195 32-bit lines in a 207-package transaction. The Steam client still needs a 32-bit userland. Fedora kept the i686 packages after the proposal to drop them was withdrawn. The list also includes ntsync-autoload, which matters in Step 4. Steam only recommends it, so it is skipped if you install with weak dependencies turned off:

195
Installing:
 steam                              x86_64 0:1.0.0.87-3.fc45                      rpmfusion-nonfree  19.5 MiB
 steam-devices                      noarch 0:1.0.0.101^git20260625.22ec85e-2.fc45 fedora             15.5 KiB
 ntsync-autoload                    noarch 0:11.0-3.fc44                          fedora              7.0   B
Transaction Summary:
 Installing:       207 packages
Total size of inbound packages is 313 MiB. Need to download 313 MiB.

Install it:

sudo dnf install -y steam 2>&1 | tail -2; rpm -q steam steam-devices ntsync-autoload; rpm -qa | grep -c "\.i686$"

steam-devices adds the udev rules that let Steam use controllers and VR headsets without root:

[213/213] Removing expat-0:2.8.3-1.fc45 100% |   1.0   B/s |  14.0   B |  00m09s
Complete!
steam-1.0.0.87-3.fc45.x86_64
steam-devices-1.0.0.101^git20260625.22ec85e-2.fc45.noarch
ntsync-autoload-11.0-3.fc44.noarch
195

Launch Steam from the app grid. The first start downloads the client runtime, then asks you to sign in:

To run Windows games, open Settings > Compatibility after signing in and turn on Steam Play for all titles, then pick a Proton version. We did not sign in on the lab machine, so that screen is not shown here.

Step 4: Check that NTSYNC is loaded

NTSYNC is a kernel driver that implements Windows synchronization primitives (mutexes, semaphores, events) directly. Without it, Proton falls back to fsync, which builds them on the kernel’s futex calls. Games that hammer those primitives, usually CPU-heavy ones, run smoother with NTSYNC. Fedora’s kernel builds it as a module, and the ntsync-autoload package that Steam pulled in loads it at boot. Right after the Steam install, before any reboot, the module was not there:

cat /usr/lib/modules-load.d/ntsync.conf; lsmod | grep ntsync; ls -l /dev/ntsync; rpm -q xorg-x11-drv-nvidia-libs --qf "%{name}.%{arch} %{version}\n"

The config file exists, but no module is loaded and no device node exists. The output also shows the 32-bit NVIDIA libraries that came in with Steam:

ntsync
ls: cannot access '/dev/ntsync': No such file or directory
xorg-x11-drv-nvidia-libs.x86_64 615.71.09
xorg-x11-drv-nvidia-libs.i686 615.71.09

Load it now without a reboot:

sudo systemctl restart systemd-modules-load; lsmod | grep ntsync; ls -l /dev/ntsync

The device appears, readable and writable by every user. That is by design in the upstream driver, so no group membership is needed:

ntsync                 20480  0
crw-rw-rw-. 1 root root 10, 264 Oct  5 22:54 /dev/ntsync

After a reboot it loaded on its own:

Plain Fedora wine does not pull in ntsync-autoload. If you use Wine without Steam, install it yourself with sudo dnf install ntsync-autoload.

Having the device is only half of it. Valve’s Proton 10 does not use NTSYNC. Proton 11 and current GE-Proton builds use it by default when /dev/ntsync exists. The check that works with any Proton build is lsof /dev/ntsync while the game runs: if the game process holds the device open, it uses NTSYNC. GE-Proton also prints a sync line to its log when launched with PROTON_LOG=1. In Steam, that means PROTON_LOG=1 %command% as the launch option, and the log is ~/steam-<appid>.log. We only saw that log line from GE-Proton. We checked both while the benchmark was running:

export GAMEID=umu-default PROTONPATH=GE-Proton WINEPREFIX=~/Games/gravitymark; rm -f ~/steam-default.log; cd "$WINEPREFIX/drive_c/Program Files/GravityMark/bin" && (PROTON_LOG=1 umu-run ./GravityMark.exe -d3d12 -width 1920 -height 1080 -fullscreen 1 -vsync 0 -benchmark 1 -close 1 >/dev/null 2>&1 &); sleep 45; lsof /dev/ntsync 2>/dev/null | awk "NR==1 || /GravityMa|wineserv/" | head -4; grep -m1 -E "^(ntsync|fsync): up and running" ~/steam-default.log; pkill -f GravityMark.exe; sleep 5

Both the game and wineserver hold /dev/ntsync open, and the log confirms it:

COMMAND    PID  USER FD   TYPE DEVICE SIZE/OFF NODE NAME
wineserve 6539 mercy  9r   CHR 10,264      0t0  738 /dev/ntsync
GravityMa 6610 mercy 10r   CHR 10,264      0t0  738 /dev/ntsync
ntsync: up and running.

If a game misbehaves with NTSYNC, turn it off for that game with PROTON_NO_NTSYNC=1. Proton falls back to fsync, which the same check confirmed:

grep -E "^(ntsync|fsync|esync)|server-side synchronization|WINENTSYNC|WINEFSYNC" ~/steam-default.log | head -5

The fallback line from the run with NTSYNC disabled:

fsync: up and running.

Step 5: Install GameMode and MangoHud

GameMode is a daemon that switches the system into a performance profile while a game runs: CPU governor, I/O priority, and optional process priority and GPU tweaks. MangoHud is the overlay that shows frame rate, frame times and load, and it can log them to CSV. Both are in Fedora’s own repos:

sudo dnf install -y gamemode mangohud 2>&1 | tail -1; rpm -q gamemode mangohud; getent group gamemode

MangoHud comes in both 64-bit and 32-bit builds, and the package creates a gamemode group:

Complete!
gamemode-1.8.2-5.fc45.x86_64
mangohud-0.8.3~rc1-4.fc45.x86_64
mangohud-0.8.3~rc1-4.fc45.i686
gamemode:x:965:

Add your user to that group. Members get the polkit rule that lets GameMode change the governor without a password prompt, and the limits entry that allows raising process priority. Replace mercy with your own username, then log out and back in for it to take effect:

sudo usermod -aG gamemode mercy; id -nG mercy

The user is now in the group:

mercy wheel gamemode

GameMode has a built-in self-test. Run it as your user, not root:

gamemoded -t 2>&1 | tail -25

On our VM, one check failed:

:: Passed

:: Dual client tests
:: Passed

:: Gamemoderun and reaper thread tests
...Waiting for child to quit...
...Waiting for reaper thread (reaper_frequency set to 5 seconds)...
:: Passed

:: Supervisor tests
:: Passed

:: Feature tests
::: Verifying CPU governor setting
::: Failed!
::: Verifying Scripts
::: Passed (no scripts configured to run)
::: Verifying GPU Optimisations
::: Passed (gpu optimisations not configured to run)
::: Verifying renice
::: Passed (no renice configured)
::: Verifying ioprio
::: Passed
: Tests Failed!

The governor test failed because there is no governor to set. This VM exposed no cpufreq interface to the guest:

ls /sys/devices/system/cpu/cpu0/cpufreq 2>&1; cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor 2>&1; systemd-detect-virt

The directory does not exist:

ls: cannot access '/sys/devices/system/cpu/cpu0/cpufreq': No such file or directory
cat: /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor: No such file or directory
amazon

On a laptop or desktop, that directory exists and the test passes. That also explains the flat GameMode result in the table: in this VM, GameMode had nothing to switch.

In Steam, add both tools through a game’s launch options. gamemoderun mangohud %command% wraps the game in both. Outside Steam, put the same two words in front of the command. This run logged 60 seconds of frame data to CSV while showing the overlay:

mkdir -p ~/mangologs; cd ~/GravityMark/bin && (MANGOHUD_CONFIG="cpu_temp,gpu_temp,vram,ram,frame_timing,gamemode,output_folder=$HOME/mangologs,autostart_log=10,log_duration=60" gamemoderun mangohud ./GravityMark.x64 -vk -width 1920 -height 1080 -fullscreen 1 -vsync 0 -benchmark 1 -close 1 >/dev/null 2>&1 &); sleep 50; import -window root /tmp/mangohud.png; sleep 40; ls ~/mangologs

autostart_log=10 starts logging 10 seconds in, and log_duration=60 stops it a minute later. MangoHud writes a full log and a summary:

GravityMark.x64_2026-10-05_23-25-05.csv
GravityMark.x64_2026-10-05_23-25-05_summary.csv

The overlay in a smaller windowed run. The GAMEMODE line confirms the daemon picked the process up:

The summary file holds the numbers you want for comparing settings:

cat ~/mangologs/*_summary.csv; head -4 ~/mangologs/GravityMark.x64_*[0-9].csv | cut -c1-200

Average 112.1 FPS and a 1% low of 42.2 for that window, with the GPU at 98.4% load and the CPU at 7.6%. That load split is why NTSYNC and GameMode had nothing to gain here:

0.1% Min FPS,1% Min FPS,97% Percentile FPS,Average FPS,GPU Load,CPU Load,Average Frame Time,Average GPU Temp,Average CPU Temp,Average VRAM Used,Average RAM Used,Average Swap Used,Peak GPU Load,Peak CPU Load,Peak GPU Temp,Peak CPU Temp,Peak VRAM Used,Peak RAM Used,Peak Swap Used
28.2952,42.1783,269.338,112.1,98.4,7.6,8.9,44.0,0.0,2.8,2.7,0.0,99,18.5,46,0,2.8,2.7,0.0os,cpu,gpu,ram,kernel,driver,cpuscheduler
Fedora Linux 45 (Cloud Edition Prerelease),Intel Xeon Platinum 8259CL CPU @ 2.50GHz,Tesla T4,32469332,7.2.9-300.fc45.x86_64,,
fps,frametime,cpu_load,cpu_power,gpu_load,cpu_temp,gpu_temp,gpu_core_clock,gpu_mem_clock,gpu_vram_used,gpu_power,ram_used,swap_used,process_rss,cpu_mhz,elapsed
120.712,8.2842,8.13397,0,99,0,41,0,0,2.78021,0,2.6772,0,0,0,16627653

The CPU temperature reads 0 because the VM exposes no sensor. Real hardware fills it in. Without the output_folder key, the logs land in your home directory. The summary file has no trailing newline, which is why its last value runs into the next file’s first line in the output above.

Step 6: Run Windows games outside Steam with umu-launcher

umu-launcher runs a Windows program with Proton and the Steam Runtime container, the same way Steam does, without Steam. Heroic and Lutris both launch games through it. It is not packaged in Fedora or RPM Fusion. Upstream publishes RPMs, but the newest is built for Fedora 44, and it fails on Fedora 45:

sudo dnf install -y https://github.com/Open-Wine-Components/umu-launcher/releases/download/1.4.4/umu-launcher-1.4.4.fc44.x86_64.rpm 2>&1 | grep -vE "^\[|Updating|Repositories" | head -12  # pin: the Fedora 44 build, to show why it fails

This pins the Fedora 44 build on purpose, to show the failure. The Fedora 44 build wants Python 3.14, and Fedora 45 moved to 3.15:

 https://github.com/Open-Wine-Component 100% |  15.2 MiB/s | 405.7 KiB |  00m00s
Failed to resolve the transaction:
Problem: conflicting requests
  - nothing provides python(abi) = 3.14 needed by umu-launcher-1.4.4-1.20260725.cf3d1b1.fc44.x86_64 from @commandline
  - nothing provides python3.14dist(python-xlib) >= 0.33 needed by umu-launcher-1.4.4-1.20260725.cf3d1b1.fc44.x86_64 from @commandline
  - nothing provides python3.14dist(urllib3) >= 2 needed by umu-launcher-1.4.4-1.20260725.cf3d1b1.fc44.x86_64 from @commandline
You can try to add to command line:
  --skip-broken to skip uninstallable packages

Use the zipapp build instead. It is a single file that runs on the system Python. This picks up the latest release tag on its own:

python3 --version; UMU_VER=$(curl -s https://api.github.com/repos/Open-Wine-Components/umu-launcher/releases/latest | grep -oP "\"tag_name\": \"\K[^\"]+"); curl -sLO https://github.com/Open-Wine-Components/umu-launcher/releases/download/${UMU_VER}/umu-launcher-${UMU_VER}-zipapp.tar; tar -tf umu-launcher-${UMU_VER}-zipapp.tar; mkdir -p ~/.local/bin; tar -xf umu-launcher-${UMU_VER}-zipapp.tar -C ~/.local/bin --strip-components=1; ls -l ~/.local/bin; umu-run --version

It runs on Python 3.15. Fedora puts ~/.local/bin on your PATH, so umu-run works right away:

Python 3.15.0rc2
umu/
umu/umu-run
umu/umu_run.py
total 416
-rwxr--r--. 1 mercy mercy 419388 Jul 25 00:26 umu-run
lrwxrwxrwx. 1 mercy mercy      7 Jul 25 00:26 umu_run.py -> umu-run
umu-launcher version 1.4.4 (3.15.0rc2 (3.15.0~rc2-1.fc45.x86_64, Sep  3 2026, 00:00:00) [GCC 16.2.1 20260819 (Red Hat 16.2.1-2)])

Three variables drive it. GAMEID selects fixes from the umu database (umu-default means none). PROTONPATH=GE-Proton downloads the latest GE-Proton on first use. WINEPREFIX keeps each game in its own Windows environment. To follow along, fetch both GravityMark builds. The version comes from the download page:

rm -f GravityMark_.*; GM_VER=$(curl -s https://gravitymark.tellusim.com/ | grep -oP "GravityMark_\K[0-9.]+(?=\.run)" | sort -V | tail -1); echo $GM_VER; curl -sLO https://tellusim.com/download/GravityMark_${GM_VER}.run; curl -sLO https://tellusim.com/download/GravityMark_${GM_VER}.msi; ls -lh GravityMark_*

The leading rm only cleared a failed earlier download in our lab. The .run file is the Linux build and the .msi is the Windows one:

1.89
-rw-r--r--. 1 mercy mercy 211M Oct  5 22:56 GravityMark_1.89.msi
-rw-r--r--. 1 mercy mercy 185M Oct  5 22:56 GravityMark_1.89.run

Extract the Linux build with sh GravityMark_*.run --noexec --nox11 --target ~/GravityMark and accept the license. Install the Windows build into its own prefix with its MSI installer. Our command names the file version directly; use GravityMark_${GM_VER}.msi if you downloaded a newer one:

export GAMEID=umu-default PROTONPATH=GE-Proton WINEPREFIX=$HOME/Games/gravitymark; DISPLAY=:0 umu-run msiexec /i GravityMark_1.89.msi /qn > umu-install.txt 2>&1; echo rc=$?; grep -iE "GE-Proton|proton|download|steamrt|runtime" umu-install.txt | head -10; ls ~/.local/share/Steam/compatibilitytools.d/; find $WINEPREFIX/drive_c -name "GravityMark.exe"

The DISPLAY=:0 was only there because we ran it over SSH. On first use umu downloaded GE-Proton and the Steam Linux Runtime. The CRITICAL lines are the runtime check failing because nothing was there yet, and it then downloaded the runtime:

rc=0
INFO: Downloading GE-Proton11-7-x86_64.sha512sum...
INFO: Downloading GE-Proton11-7-x86_64.tar.gz...
INFO: GE-Proton11-7-x86_64.tar.gz: SHA512 is OK
INFO: Extracting GE-Proton11-7-x86_64.tar.gz...
INFO: /home/mercy/.cache/umu/tmpt5jkdkuw/GE-Proton11-7-x86_64 -> /home/mercy/.local/share/Steam/compatibilitytools.d
INFO: Using GE-Proton11-7-x86_64
CRITICAL: steamrt4 validation failed
CRITICAL: Could not find steamrt4_platform_* in '/home/mercy/.local/share/umu/steamrt4'
INFO: Downloading steamrt4 (4.0.20260928.262390), please wait...
INFO: SteamLinuxRuntime_4.tar.xz: SHA256 is OK
GE-Proton11-7-x86_64
/home/mercy/Games/gravitymark/drive_c/Program Files/GravityMark/bin/GravityMark.exe

GE-Proton lands in Steam’s compatibility tools folder, so Steam also lists it as a Proton choice. Running the installed game is the same pattern. This is the Direct3D 12 run from the table, reading the result from GravityMark’s log inside the prefix:

export GAMEID=umu-default PROTONPATH=GE-Proton WINEPREFIX=~/Games/gravitymark; cd "$WINEPREFIX/drive_c/Program Files/GravityMark/bin" && umu-run ./GravityMark.exe -d3d12 -width 1920 -height 1080 -fullscreen 1 -vsync 0 -temporal 1 -benchmark 1 -close 1 >/dev/null 2>&1; grep -E "API:|Platform:|Score:|FPS:" "$WINEPREFIX/drive_c/users/steamuser/.GravityMark/GravityMark.log" | tail -4 | cut -d: -f4-

The Windows build ran at 110.1 FPS through vkd3d-proton:

 API: Direct3D12
 Platform: Windows
 Score: 18397
 FPS: 110.1

The native Linux build of the same benchmark, for comparison:

cd ~/GravityMark/bin && ./GravityMark.x64 -vk -width 1920 -height 1080 -fullscreen 1 -vsync 0 -temporal 1 -benchmark 1 -close 1 2>&1 | grep -E "API:|Platform:|Score:|FPS:"

The native build was ahead by 1.4 FPS:

M:  2:49.950: API: Vulkan
M:  2:49.950: Platform: Linux
M:  2:49.950: Score: 18628
M:  2:49.950: FPS: 111.5

umu runs whatever you point it at, with your user’s full access to your home directory. Only run installers you would trust on Windows.

Flatpak Steam instead of the RPM

Flathub’s com.valvesoftware.Steam keeps the 32-bit libraries inside its runtime instead of on your system, which is the main reason to prefer it. It is a community package, not Valve’s. If you have not added Flathub yet, our Flatpak and Flathub guide for Fedora covers it. We installed it next to the RPM and checked that the sandbox can reach NTSYNC:

sudo flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo; sudo flatpak install -y --noninteractive flathub com.valvesoftware.Steam >/dev/null 2>&1; flatpak info com.valvesoftware.Steam | grep -E "Version|Origin"; flatpak run --command=sh com.valvesoftware.Steam -c "ls -l /dev/ntsync"

The device is visible inside the sandbox, so Proton in Flatpak Steam can use it too. The owner shows as nfsnobody because the sandbox maps host root to an unknown user, and the 0666 mode still allows access:

       Version: 1.0.0.87
        Origin: flathub
crw-rw-rw-. 1 nfsnobody nfsnobody 10, 264 Oct  5 22:54 /dev/ntsync

The module still has to be loaded on the host. Flatpak Steam does not install ntsync-autoload, so install that package from Fedora if you go this way. Pick one Steam. Running both means two libraries, two shader caches and two sets of updates.

Errors we hit, and the fix for each

modinfo: ERROR: Module nvidia not found

The driver install pulled in a newer kernel, and akmods built the module only for that kernel because only its headers were installed. The fix is a reboot. If it persists after the reboot, check rpm -q kernel-devel against uname -r. They must match before akmods can build.

Could not find files needed to compile modules

The same cause, seen from akmods. It is harmless when a newer kernel has its module built. It is a real problem only if the kernel you boot into lacks a matching kernel-devel.

nothing provides python(abi) = 3.14 needed by umu-launcher

The upstream umu RPM targets an older Fedora Python. Use the zipapp build from Step 6, or wait for a Fedora 45 build from upstream.

::: Verifying CPU governor setting ::: Failed!

GameMode found no cpufreq interface. In a VM this is expected. On real hardware, check that /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor exists.

ls: cannot access ‘/dev/ntsync’: No such file or directory

The module is not loaded. Install ntsync-autoload if it is missing, then load it with sudo modprobe ntsync or reboot.

Once the stack works, the rest of a new Fedora install is covered in our list of things to do after installing Fedora 45. If you are still on the previous release, upgrade Fedora 44 to 45 first. The Fedora 45 release overview lists the rest of this cycle’s changes, and the Proton README documents every environment variable Proton reads.