Since Hotfix #34, Baldur’s Gate 3 has a native Steam Deck build. Larian says the native version uses less CPU processing and memory than the Proton version, targeting more stable frame rate, lower loading times and smoother gameplay. Hotfix #35 then changed the Native default upscaler from FSR 1 to FSR 2.2 and fixed additional loading/controller/crash issues. For a normal current playthrough, start Native. Switch back to Proton only when a specific third-party Windows mod/tool or regression gives you a reason.
Quick answer: Native is the normal starting point now; Proton is the compatibility fallback
The performance goal should be “stable enough in the Lower City,” not “looks perfect in the Act 1 wilderness.” Act 3 remains the stress test because population, streaming and CPU load are much higher.
The native Steam Deck build changed the default recommendation: start with the Deck-native path before reaching for Proton workarounds.
There is no single permanent “best settings” preset for every SteamOS version, mod stack and Act. Use this as a conservative baseline, then validate it in the Lower City with the performance overlay.
Native vs Proton
Swipe horizontally to view all columns.
| Mode | Use it when | Advantages | Costs / caveats |
|---|---|---|---|
Native Steam Deck build | Normal current playthrough; official supported mods; no Windows-only tool requirement | Lower CPU/memory overhead according to Larian; actively tuned by Hotfix #34/#35; current default path. | Third-party Windows scripts/tools can expect Proton paths or Windows DLL behavior. |
Proton / Windows build | A specific mod/tool only supports Windows/Proton, or Native has a specific unresolved regression for your setup | Preserves old Windows file layout and compatibility with some PC-only tooling. | More compatibility-layer overhead; old guides/paths/settings can be stale for the Native build. |
Recommended baseline settings / What performance should you expect?
Swipe horizontally to view all columns.
| Setting | Baseline | Why / when to change |
|---|---|---|
Resolution | 1280 × 800 | Native Deck panel resolution; reduce render scale through FSR rather than dropping the output resolution first. |
Frame target | 30 FPS cap | More useful than chasing an unstable 35–45 FPS peak; evaluate frame pacing. |
Upscaling | FSR 2.2 — Quality to start | Hotfix #35 made FSR 2.2 the Native default for a sharper image than FSR 1. Drop to Balanced only when the heavy area needs it. |
Textures | Medium / High if memory behavior is stable | Texture clarity is often cheaper than CPU-heavy crowd/streaming settings; change after the expensive options. |
Model / detail distance | Low–Medium | Useful lever for dense scenes. |
Shadows / clouds / fog | Low | Reliable GPU savings with limited gameplay impact on the Deck screen. |
Crowd / dynamic-crowd-heavy options Performance overlay | Reduce for Lower City Use during tuning | Act 3 is CPU/streaming constrained; crowd complexity can matter more than Act 1. Test frame-time behavior in a worst-case area, not only the Nautiloid or camp. |
Use the graphics menu as a baseline, then test the result in a CPU-heavy area rather than copying a screenshot forever.
A 30-FPS target is realistic as a baseline rather than a guarantee. The native build improved CPU/memory behavior and model streaming, but Lower City crowds and heavy Act 3 scenes can still dip below 30 depending on SteamOS, party/mod load and exact settings. Older detailed Deck tests often reported high-20s with occasional low-20s in the Lower City; the native build should start from a better position, but a publishable guide should not promise a locked 30 everywhere.
Use the Deck performance overlay to judge frame time and dips in the scene that actually stresses the system.
The Lower City is the performance test that matters; an Act 1 screenshot can hide the CPU/streaming bottleneck.
Battery life changes sharply with LCD vs OLED Deck, brightness, TDP/frame cap, wireless use and scene load. Treat roughly “a couple of hours” as an order-of-magnitude expectation for an untethered session, not a fixed benchmark. If battery matters more than visuals, a 30-FPS cap, reduced brightness and restrained TDP are more honest levers than promising one universal runtime number.
Battery range / Save migration from the old Proton build
Native and Proton use different local directories. If Steam Cloud is enabled, recent saves should sync into the Native location automatically. If Cloud is disabled, or an old local save is missing, copy it manually in Desktop Mode instead of assuming the migration deleted it.
1. Switch the Deck to Desktop Mode.
2. Open the old Proton profile path: ~/.local/share/Steam/steamapps/compatdata/1086940/pfx/drive_c/users/steamuser/AppData/Local/Larian Studios/Baldur's Gate 3/PlayerProfiles/Public
3. Copy the Savegames folder.
4. Open the Native profile path: ~/.local/share/Larian Studios/Baldur's Gate 3/PlayerProfiles/Public
5. Paste Savegames there, then relaunch BG3 and verify the newest manual save before deleting anything from the Proton tree.
The old Proton path lives inside compatdata/1086940; the Native build uses the normal Linux Larian Studios directory instead.
Mod migration
If the Deck is logged into a Larian account connected to mod.io, supported subscribed mods can be downloaded again for the Native setup through the official Mod Manager. If the campaign used manual/third-party PC mods, do not blindly copy every Windows file. Check whether the mod supports the Native build, then either reinstall through the in-game manager or copy only the documented Mods content from the old Proton layout to the Native BG3 data tree.
This is the main reason Proton still matters: a Windows-only Script Extender/native-DLL/tooling workflow can depend on the Windows filesystem/runtime. If that tool is essential and has no Native path, Proton is an intentional compatibility choice — not evidence that the native build is bad.
Hotfix #35 changes worth knowing
Native default upscaling changed from FSR 1 to FSR 2.2.
Fixed external-controller issues after switching Desktop/Gaming Mode.
Improved loading behavior in native scenarios.
Fixed a Native crash involving saving after crafting.
Fixed additional Steam Deck cross-play crashes.
Controller UI and frame-rate behavior should be tested after SteamOS/hotfix updates; Hotfix #35 specifically fixed Deck controller and crash issues.
Troubleshooting matrix / The two stale recommendations to ignore
Swipe horizontally to view all columns.
| Problem | First check / Next step |
|---|---|
Native save missing | Steam Cloud status; Native PlayerProfiles path / Copy Savegames manually from old Proton Public folder; do not delete the source until verified. |
Old guide says Proton path | Guide date / Use Native path unless you intentionally forced Proton. |
Image too soft | FSR mode / Start FSR 2.2 Quality; lower other expensive settings before jumping straight to very aggressive upscaling. |
Lower City under 30 | Crowd/model/detail settings; mod/party load / Test low crowd/detail, close background tools, compare Native vs deliberate Proton only if diagnosing a specific regression. |
Mod missing after migration Controller breaks after mode switch | Official subscription vs manual PC mod / Redownload supported mods; check Native compatibility for third-party mods before copying. Game/hotfix/SteamOS current? / Restart input/game path; Hotfix #35 addressed known external-controller cases. |
FAQ
“BG3 Steam Deck normally runs through Proton.” That was the old architecture; Hotfix #34 added the Native build.
“FSR 1 is the Native default.” Hotfix #35 changed the default to FSR 2.2.
Is BG3 native on Steam Deck now? Yes. Hotfix #34 introduced the native build.; Should I force Proton? Not by default. Use it for a specific compatibility reason.
What upscaler should I start with? FSR 2.2 Quality is a sensible current baseline; Hotfix #35 made FSR 2.2 the Native default.
Can the Deck hold 30 FPS everywhere? Do not assume a locked 30 in dense Lower City scenes; tune for the worst area you actually play.; Where did my Proton saves go? They remain under compatdata/1086940 unless Cloud/manual migration moved/copied them.