Since I’m at work, I asked Copilot Premium about this issue, and I’m pasting it’s response here for both documentation, and so I can test what it suggests when I’m home later.
AI Generated Content:
Short answer: It’s (almost certainly) the display pipeline, not raw GPU/CPU load.\ On Linux with hybrid graphics and modern compositors (Wayland/GNOME), the way frames are scheduled, composited, and copied to the output can change dramatically when you drive an external display, especially if your internal and external panels run at different refresh rates or if the compositor is rendering on one GPU and the frame is presented by the other. That can tank real‑world FPS even when utilization looks the same. [bbs.archlinux.org], [gitlab.gnome.org], [skerit.com]
Below is a structured way to diagnose and fix this on your Framework 16 (RX 7700S + 7840HS, Fedora 43).
What’s likely happening
-
Mixed-refresh + compositor synchronization:\ Wayland compositors (GNOME/Mutter, KWin, etc.) often synchronize frame flips across outputs. When one monitor is 60/75 Hz and another is 120/144/165 Hz, the compositor may effectively pace to the slower output or perform extra copies, which reduces the app’s measured FPS (and increases latency) even if the GPU isn’t “busy.” Multiple reports show half rate or lower-than-expected FPS on the external screen in such setups. [discourse.gnome.org], [bbs.archlinux.org], [gitlab.gnome.org]
-
Render on one GPU, output on another (copy path):\ Even with the cable in the rear dGPU port, the desktop environment can choose the iGPU for general compositing, and then copy frames to the dGPU’s output. That extra copy and synchronization can cut performance substantially. There’s a detailed case study with the Framework 16 showing GNOME rendering on one GPU while the outputs come from another, leading to sluggishness until the pipeline is forced differently. [skerit.com]
-
Wayland/XWayland differences for TF2:\ TF2 is still largely an X11/XWayland title. Under Wayland, XWayland’s vsync and presentation timing interact with the compositor. Many users see lower/halved FPS on external monitors until they adjust compositor/driver behavior or run the game in a dedicated gamescope session. [gitlab.gnome.org], [zamundaaa.github.io]
-
Framework 16 port topology:\ Only the rear USB‑C/DP port is directly wired to the RX 7700S; side ports go through the iGPU. That’s good (you did this), but it doesn’t guarantee the compositor renders on the dGPU. There’s no BIOS MUX toggle exposed for manual control today, so software composition paths matter. [community.frame.work]
Quick checks
Run these while reproducing the issue (external monitor active, TF2 rendering there). You can paste commands in a terminal.
-
Which GPU is the compositor using / which GPUs are visible?
glxinfo -B and vulkaninfo | less → look for renderer strings (RADV NAVI33 vs Phoenix/iGPU).\ On hybrid setups, it’s common for the compositor to pick the iGPU even when output is via dGPU. [wiki.gentoo.org]
-
Verify the outputs and refresh rates:
- GNOME Settings → Displays (make sure the external monitor is at its native max refresh). Also try setting both displays to the same refresh for a test. Mixed refresh can trigger half-rate symptoms. [discourse.gnome.org], [bbs.archlinux.org]
-
Measure with MangoHud:
- Launch TF2 with
mangohud enabled and show vsync/frametimes while switching between internal vs external displays to confirm the pacing difference. (This is observational; the underlying cause is compositor timing.) [nerdburglars.net]
Fixes & Workarounds (ordered from easy → deeper)
A. Make the external display the only active output while gaming
- Temporarily turn off the internal panel in GNOME Displays (or close the lid with lid‑close set to “do nothing”) so the compositor only targets the external monitor. This removes mixed‑refresh synchronization and often restores expected FPS. Many reports confirm large improvements when eliminating the second output under Wayland. [gitlab.gnome.org]
B. Match refresh rates across displays
- If you want both displays on, set them to the same refresh (e.g., both 60 Hz or both 120 Hz) and retest. This can avoid the “half refresh on external” issue that several users observe (e.g., 144 Hz → ~72 FPS; 120 Hz → ~60 FPS). [bbs.archlinux.org], [unix.stack…change.com]
C. Run the game in a gamescope session targeting the external output
Gamescope isolates the app from the desktop compositor and lets you control the display mode, vsync, and VRR:
Example Steam Launch Options (adapt names to your output):
gamemoderun gamescope \
–fullscreen \
–prefer-output=DP-1 \
–display-mode=1920x1080@144 \
–adaptive-sync on \
–rt \
– %command%
-
--prefer-output=DP-1 should point to your external monitor’s DRM name; check loginctl session-status or journalctl -b | grep -i DRM to confirm.
-
This often restores high FPS on Wayland because gamescope becomes the “compositor” just for the game. [nerdburglars.net]
D. Try X11 session for comparison
- Log out → choose GNOME on Xorg and retest. Under Xorg, behavior with hybrid GPUs and mixed refresh can be different; some AMD users fix multi‑monitor pacing by enabling certain amdgpu Xorg options (see below). If Xorg brings your FPS back on the external monitor, the issue is Wayland pacing. [lexo.ch]
E. If you use Xorg: enable async flips & VRR for AMDGPU
Create /etc/X11/xorg.conf.d/20-amdgpu.conf:
Section “Device”
Identifier "AMD"
Driver "amdgpu"
Option "AsyncFlipSecondaries" "True"
Option "VariableRefresh" "true"
EndSection
Reboot and retest. This can prevent the “lowest-common-denominator” sync across outputs on multi-monitor AMD setups under Xorg. [lexo.ch]
F. Confirm you’re truly rendering on the dGPU for the game
Even with the DP cable in the rear port, ensure TF2 uses the 7700S:
- In Steam, prepend TF2 with
DRI_PRIME=1 (for Mesa/RADV) so it renders on the dGPU. If it’s already the default in Fedora 43 for discrete GPU sessions, you may not need it—but explicit is safe:\ DRI_PRIME=1 mangohud %command%\ Hybrid graphics guides explain PRIME offload and variables if you run mixed stacks. [wiki.gentoo.org], [tuxedocomputers.com]
G. Avoid fractional scaling & heavy desktop effects during gaming
Blur/translucency effects on the compositor can exacerbate low FPS or tearing on external monitors. Disabling such effects improved external-monitor performance for users on Fedora/KDE; the same principle applies on GNOME (keep scaling simple, e.g., 100% or 200%). [reddit.com]
H. Keep kernel & Mesa current
- Wayland/AMDGPU presentation timing has been improving release‑by‑release. Kernel/Mesa updates can materially change FPS in multi‑monitor scenarios. Users have reported version‑dependent FPS swings (e.g., different Fedora/kernel combos). Make sure Fedora 43 is fully updated. [nerdburglars.net]
Why your numbers look like that
200+ FPS at 1600p on the internal; ~100 FPS at 1080p on external\ That “half” effect matches the well‑documented behavior where the compositor paces to a slower or synchronized cadence on the external path (often half refresh or extra copy cost), not the game’s raw rasterization capability. Multiple threads show 144 Hz → ~72 FPS, 120 Hz → ~60 FPS on external while internal can sustain higher rates. [bbs.archlinux.org], [unix.stack…change.com]
Framework‑specific notes
-
You did the right thing by plugging into the rear dGPU port, since the side ports are wired to the iGPU. However, current Framework guidance indicates there’s no user‑exposed MUX control in BIOS to force the desktop compositor to run entirely on the dGPU; software still decides. That’s why gamescope/Xorg tweaks matter. [community.frame.work]
-
Community posts show oddities if the DE renders on the iGPU while the dGPU presents, even with nothing attached to the iGPU—performance suffers until the rendering path is aligned. [skerit.com]
Practical “recipe” to try right now
-
Single‑display test: Turn off the internal display → run TF2 on the external at its max refresh. If FPS jumps back toward your internal‑panel numbers, it’s mixed‑refresh pacing. [discourse.gnome.org], [bbs.archlinux.org]
-
Gamescope test: Use the gamescope launch options above to run TF2 fullscreen on the external output with VRR on. Check MangoHud frametimes/FPS. [nerdburglars.net]
-
Xorg sanity test: Log into GNOME on Xorg once, apply the amdgpu AsyncFlipSecondaries + VariableRefresh options, and retest TF2 on the external. If FPS normalizes, you’ve isolated a Wayland pacing issue. [lexo.ch]
-
If you keep Wayland: Keep both monitors at the same refresh (or disable the internal while gaming) until Mutter/GNOME deliver smoother multi‑monitor pacing for all hybrid configs. Track GNOME/mutter issues related to low performance on external monitors for ongoing fixes. [gitlab.gnome.org]
If you want, I can help you craft the exact gamescope launch line for your display names and preferred refresh, and we can instrument a couple runs with MangoHud to verify frametime behavior. What refresh rate(s) are your external panel and the internal Framework panel set to when you see the big drop?