Yesterday I wanted to do some gaming (TF2) with my Framework 16 on an external monitor. Regardless of what resolution I set the external monitor to, including less than the Framework’s 2560x1600, my frame rate was drastically lower on the external monitor despite hardware utilization being the same. For example, rendering TF2 at 1600p on the internal display I would get 200+fps, but on the external display at 1080p I got about 100fps. I was plugged into the display port on the back of the dGPU. It’s also not the fact that the external monitor is connected and I thus have an extra desktop rendering because it was connected when I tested the framerate on the internal monitor.
CPU: Ryzen 7 7840HS
GPU: RX 7700s
BIOS: 4.03 beta (I’ve seen this issue on 3.05 as well)
OS: Fedora 43
Games tested: Team Fortress 2, Clair Obscur Expedition 33
Does anyone know why my FPS would dip because it’s being sent to an external monitor?
I searched the forums for anything similar… and came across a forgotten post of my own. Lol.
AMD 7700s dGPU DP issue with 4k@60-144hz (updated title) - Framework Laptop 16 - Framework Community
In that thread I state that I was having performance issues with outputting via the dGPU’s usb-c port (though, in that thread I was outputting 4k, is this new testing I also tested 1440p and 1080p). I’ll test using the mobo connection per my own suggestion tonight, although I had specifically wanted to use the dGPU port for the decreased latency.
If I find that the FPS loss only happens via the dGPU port… that would seem unusual to me.
(This post was long and contained nothing useful. I’ve cleaned it for the sake of the thread. You can see it in the history if you’re curious).
I ran some tests tonight, and found that the FPS drop is not the same across different docks. My JSAUX 11-in-1 see’s the biggest drop, while the Framework DP card has a smaller (but still very noticable) drop. Moving from dGPU to motherboard ports didn’t seem to make much of a difference, and none of the Copilot suggestions fruited anything useful (not surprising, but it was easy enough to check).
I still don’t know why it’s happening, but I learned a little more about it. My best guess is that there is some form of communication bottleneck between the dock/adapter and the processor that doesn’t exist on the more integrated internal display.
Could it be due to the adapter you use, the hdmi expansion card is a super direct adapter for this though you may also need to launch the game with DRI_PRIME=1 (If bash shell though may be different for yours) to force the discrete gpu, I had this issue with an external monitor though it may be related to your monitor having more pixels than your laptop display and is running at that displays native resolution if you use an ultrawide but is could also be due to an older standard of hdmi cable like 2 not 2.1B
I figured it out! After MUCH testing, on both here and my steam deck which was experiencing the same issue here’s what I think is happening:
Devices with internal monitors are optimized for the amount of video bandwidth needed for their internal displays. When going beyond this, there is a performance penalty due to running out of some resource I have not been able to identify beyond measuring it’s impact on frame rate.
Here’s how I finally figured it out: I had a monitor configured as a 4k120 video signal, but the game was only rendering at 720. This FPS was much lower than a 720p signal rendered at 720p. I then went into windowed mode with the game at 720p and the display still at 4k. My framerate was the same as the 720p display signal from before. During this test, I had a youtube video playing in the background but not visble. I then fullscreened the youtube video and put my 720 game window in front. This means I had a 4k video signal but with each pixel changing and a game rendering at 720. My FPS dropped closer to what it was when I tested the 4k fullscreen game!
I’d love to hear anyone’s theories regarding exactly what resource this is taxing, but for now, I know how to tailor my gaming experience for the hardware I choose to use.
@Mario_Limonciello any chance you have some video pipeline insights?
Slight kink in my theory, I was unable to reproduce the issue on Windows. I’m not sure what this means yet, but I’ll see if I can get a Windows install on the Steam Deck and test that as well for 2nd confirmation. I was able to reproduce it on Windows with the Steam Deck, so I’d guess that this is closer to a hardware issue than a software configuration one.
Update:
I’ve come across this documentation and I plan on looking at it in more depth to understand what components may be bottlenecking here: Display Core Next (DCN) — The Linux Kernel documentation
Leaving this note here for me to find later, as it may give me some tools to dig further into the display core:
Display Core Debug tools — The Linux Kernel documentation
drm/amd/display - Display Core (DC) — The Linux Kernel documentation
Ok, so I’ve spent way too much time here at work looking into this and preparing what benchmarks, tools, and data collection I wanted to run… I’m pretty sure what I’ve done is rediscovered the impact of memory bandwidth.
any chance you have some video pipeline insights?
So the biggest bottleneck is going to be the compositor. If it’s compositing a larger frequently changing surface (like a video on one screen and a game on another) yes you can potentially hit bandwidth limitations.
The right solution here is to use direct scan out to bypass the compositor. For example Kwin will do this when applications are full screened.
You want both the video stream doing this as well as the game doing this.
Thanks for the input! I’ll give that a shot 