I've been meaning to write this down since I finally got a stable 60fps out of GTA V on my laptop, mostly so I stop losing the notes in my own head. Short version: the game runs great now. Long version: it took four separate fixes just to get past the main menu, and then a much longer detour to figure out why it kept hitching every couple of seconds once it was actually playable.
Setup, for context: Pop!_OS 24.04, an ASUS TUF FX505DY (Ryzen 5 3550H, Radeon RX 460/560D with 4GB VRAM), and the game installed the "normal" way — Rockstar Games Launcher running inside a Lutris-managed Wine prefix, on GE-Proton, via umu-launcher. If any of that sounds like a lot of layers, yeah, it is, and that ended up mattering more than once.
First problem: clicking Play in the Rockstar Games Launcher did nothing. No window, no error, nothing new in the logs. Turned out BattlEye under Proton expects two specific Steam packages to already be sitting on disk — the Proton BattlEye Runtime and the Steam Linux Runtime it depends on. Normally Steam fetches these automatically. I didn't have Steam installed at all, so nothing was ever going to appear.
Fix was just installing Steam and letting it grab the BattlEye runtime once. What's worth knowing is that this check is purely filesystem-based — protonfixes (the fixup scripts GE-Proton ships with) just looks for the files on disk, it doesn't care whether you actually launch through Steam afterward. So you can install Steam, let it download that one thing, and go right back to launching everything through Lutris like I do.
Small side quest: I wanted to double check the Proton build Lutris was using, so I went looking for it in Steam's compatibility tools list. Wasn't there. Lutris had definitely downloaded GE-Proton11-6, I could see it sitting in ~/.local/share/Steam/compatibilitytools.d/.
The native Debian Steam package doesn't actually use ~/.local/share/Steam as its real home — that's ~/.steam/debian-installation. Two different paths, and a lot of tools (Lutris included) still write to the old one out of habit. Steam was looking in the right place, just not the place anything had put a build.
ln -s ~/.local/share/Steam/compatibilitytools.d/GE-Proton11-6-x86_64 \
~/.steam/debian-installation/compatibilitytools.d/GE-Proton11-6-x86_64
One symlink and it showed up. While I was in there I also discovered the "GTA V" entry Lutris had added to my Steam library wasn't the game at all — its actual launch command was just flatpak run net.lutris.Lutris lutris:rungameid/1, i.e. it re-opens Lutris. Forcing a compatibility tool onto that entry does exactly nothing useful. If you're chasing something similar, check what a Lutris-generated Steam shortcut actually launches before you spend time on it.
Got further this time — the launcher opened, tried to start the game, and Rockstar's own version check rejected it, claiming I was on an unsupported Windows version. On a prefix that had never run anything else, let alone Windows 7.
Wine decides what Windows version it's pretending to be via a registry key, HKCU\Software\Wine\Version. Nobody had ever set it, so it fell back to some ancient default old enough to trip Rockstar's check. One command fixed it:
wine reg add "HKEY_CURRENT_USER\Software\Wine" /v Version /d win10 /f
This was the annoying one. Everything launched — window opened, assets loaded, then it sat on the "Entering Story Mode" spinner. Not for a bit. I let it run once for almost twenty minutes with zero change.
I chased two wrong leads before finding the real one, and I'll admit both felt very plausible at the time.
First guess: the integrated GPU was choking on shader compilation instead of the actual discrete card doing the work. Worth checking properly rather than assuming — forced DRI_PRIME and checked which /dev/dri render node the game process actually had open via its /proc/<pid>/fd entries. It was using the discrete RX 460/560D the whole time. Not that.
Second guess: ntsync, one of the newer Wine synchronization primitives, has known kernel interaction bugs on some setups. Set PROTON_NO_NTSYNC=1 to force the older esync/fsync path instead. The game ran fine for a few minutes on the retry, then hung again in the exact same spot. Not that either.
What actually worked: I checked the network first, properly, rather than just assuming it was fine — active established connections and real multi-megabyte transfers to Rockstar's servers, confirmed with ss and curl. So the network was healthy. The Social Club online handshake itself was just stalling. GTA V ships an official flag for exactly this situation:
printf -- '-nobattleye -scOfflineOnly' > commandline.txt
Dropped that into the game's commandline.txt and it booted straight into Story Mode on the next launch. Whatever's going wrong with the Social Club handshake under Proton, skipping it entirely turned out to be the fastest way through.
Once it was actually running I wanted an on-screen FPS counter, and specifically asked for MangoHud rather than DXVK's built-in one, which in hindsight cost me an evening.
MANGOHUD=1 reached the game process fine — I could see it in /proc/<pid>/environ — but the overlay never appeared, and the library was never loaded according to /proc/<pid>/maps. Root cause: the game is running inside two sandboxes stacked on top of each other. Lutris runs as a Flatpak, so it's in its own container. Inside that, umu-launcher builds its own Steam Runtime container to actually run the game. That inner container constructs its own Vulkan layer search path and explicitly strips out the environment variables that would normally let an external layer in.
I installed the proper Flatpak extension for MangoHud, confirmed it was correctly mounted inside the outer sandbox, confirmed its Vulkan layer manifest was even in the right merged directory — and the inner container still didn't see it, because its own VK_IMPLICIT_LAYER_PATH override takes priority over everything else regardless of what's technically reachable on disk.
Tried forcing it via LD_PRELOAD directly. Didn't take. Then found that Lutris actually has a documented option for exactly this, prefix_command: mangohud, which is supposed to wrap the whole launch through MangoHud's own script. That one didn't just fail quietly — it broke the launch outright, and the Rockstar Launcher started closing within a couple seconds of clicking Play every time.
Reverted all of it and went back to DXVK's built-in overlay, DXVK_HUD=fps. Zero setup, no sandbox to fight, because it's not an external library at all — it's a feature DXVK already has, reading its own environment variable. Sometimes the fancy tool loses to the boring one that ships in the box.
Game was running, but stuttering every couple of seconds, badly enough to be distracting. I'd seen the exact same behavior on this laptop under Windows previously, which was a useful data point — it meant this almost certainly wasn't a Linux or Proton bug.
Pulled live numbers straight out of /sys/class/drm/card1/device/ while actually playing:
Fully loaded, clocked way below its own maximum, and hot. That's thermal throttling, not a settings problem. I went through the obvious software levers anyway, mostly to rule things out properly instead of guessing:
Lowering every graphics setting to minimum barely helped, which told me VRAM wasn't the main driver. Checked the kernel log for actual GPU faults or resets — nothing, so it wasn't dying. Manually forced a higher clock state; the driver accepted the request but the GPU sat at 559MHz anyway, meaning the chip's own firmware was overriding it for thermal safety regardless of what the OS asked for. Cut the power limit by nearly 30%, from 48W down to 35W, confirmed it actually held this time — temperature and clock didn't move at all.
At that point there was nothing left in software. Both fans were already near max and had actually just been replaced a few weeks earlier, along with a repaste — which meant the one thing none of the above could touch was how well heat was actually getting from the die to the heatsink in the first place.
I redid the thermal paste myself with Honeywell PTM7950, and that was it. Same settings, same everything else, and it's holding a steady 60fps now with none of the stuttering. All that throttling telemetry made a lot more sense in hindsight — the fans were working exactly as hard as they should have been, they just had nothing good to transfer the heat to them in the first place.
For anyone on similar hardware — a 4GB Polaris-class card like the RX 460/560D, paired with a mobile Ryzen chip — this is where I landed for the best tradeoff:
| Setting | Value |
|---|---|
| MSAA | Off |
| FXAA | On |
| Texture Quality | Normal |
| Shader Quality | High |
| Shadow Quality | Normal |
| Reflection Quality / MSAA | Normal / Off |
| Ambient Occlusion | Normal |
| Anisotropic Filtering | 8x–16x |
| Tessellation | Off |
| Water / Particles Quality | Normal |
| Grass Quality | Normal |
| Shadow Distance | Medium |
| Distance Scaling | Low–Medium |
| Population Density / Variety | Medium |
Plus, in the Advanced Graphics tab: long shadows, high-resolution shadows, and ultra shadows all off, soft shadows set to sharp/PCF rather than the higher-end modes, and high-detail streaming while flying off.
The texture quality one is the setting that actually matters most here — a 4GB card will happily let you set it to High, and then stutter constantly as it thrashes textures in and out of VRAM. Everything else on this list is more about not paying for detail you won't notice at typical viewing distance.
Anisotropic filtering is the one free lunch on the list — turn it all the way up, it costs almost nothing on modern hardware and textures at a distance look noticeably better for it.