Automated MUX Switch in regular Desktop usage - stutter here and there

Hia all,
wondering if in regular usage (Desktop) I could enforce the integrated GPU instead of letting it automatically switch to the RX 7700S from time to time.

Have the FW16 + RX7700S, 64Gb Ram running KDE Neon(latest plasma Destop) - and everything works very nicely. In games (Steam - “God of War”), it is even smoother than on my gaming rig (probably due to the faster screen on the laptop :wink: ).
But when on regular workstation mode, when switching virtual screens I suppose the RX7700S chimes in and during the switch, it hangs shortly (what I call stutter).

So - when I run it on the laptop screen - everything is fine.
When I connect to the external 4K screen (Display Port), when I switch to another virtual Desktop, it hangs in the middle of the transfer animation a short time, then continues.

IMHO, this happens when it switches from integrated to external GPU.

Anyone knows how to troubleshoot that, and eventually, tell Plasma/Wayland to stick to the integrated GPU and only switch over to the external one when I manually enable it (like for gaming).

Thx for any pointer.

As far as I know, there is no way to use the MUX switch on Framework 16 on Linux. Framework 16 does not have a MUX switch toggle in the BIOS and relies solely on automatic MUX switching using AMD smart access graphic technology, which currently only works on Windows. On Linux, FW16 should behave like a MUXless laptop. So the laptop screen is connected to the iGPU on Linux, and without a working MUX this cannot be changed. Expansion Cards are always connected to the iGPU and a working MUX would not change that. USB C on the back of the laptop is always connected to the dGPU. I don’t think your problem is caused by the MUX, because MUX switching doesn’t happen on Linux. If we had a MUX switch toggle in the BIOS you could select only one gpu and that might help solve your problems, but unfortunately that is not possible. You might find some useful information in this thread.

OpenGL applications should run on the iGPU unless they are started using DRI_PRIME=1 or are configured use an alternate gpu in their .desktop files. Vulkan apps can automatically choose a gpu. You could probably force them to use the iGPU if you started them using DRI_PRIME=0!. (The ! character is part of the command.)
Maybe you could somehow completely disable the dGPU in the operating system. Some people have done this on INTEL+NVIDIA laptops. I’ve never done it so I’m not able to tell you the exact steps.

Thx for the comments. I had read through the [RESPONDED] MUX switch toggle in BIOS? thread, but that didn’t give me an answer - reason I asked again.

Funny thing is, this does not happen on the laptop screen per se, only when connected through external screen (and this one is bigger).
Will see what I can find on the Internet… That’s where the info is :slight_smile:

So - after applying all patches, also KDE Plasma 6.0.2 - all is smooth.
Software after all, somehow :slight_smile:

1 Like

As someone hopefully starting my own FW16 journey
Could you pls provide the exact solution for it?
As simple as it sounds, some guys (probably also me :smiley: ) aren’t as skilled with linux and like to have the command or a small text with the solution for it.

And one question:
How did you connect your external monitor?
Through the dGPU port or one of the 6 IOs?

Actually, all I did was install KDE Neon and made sure all latest updates are applied following the ubuntu 22.04 install instructions from Framework.

KDE Neon is a Ubuntu 22.04.x + Plasma KDE 6.x (Latest KDE - KUbuntu still uses the Plasma KDE 5.x) but for that they make sure to add the latest kernel (oem) by default and all patches for a smooth experience. So - nothing really special.

So - external monitor was first connected through Displayport.
I now found a used Dell WD22TB4 dock which works flawlessly on ebay (received it today).
Connected it through USB-C (USB4) - and can use my 4K screen!

UPDATE: I have applied a new firmware to the Dell Dock today. Maybe that has helped too.

3 Likes

Still going on issue.
What I noticed, is that I see in the kernel ring buffer lots of entries looking like this:

[dim. mars 17 15:32:50 2024] [drm] PCIE GART of 512M enabled (table at 0x00000081FEB00000).
[dim. mars 17 15:32:50 2024] [drm] PSP is resuming...
[dim. mars 17 15:32:50 2024] [drm] reserve 0x1300000 from 0x81fc000000 for PSP TMR
[dim. mars 17 15:32:51 2024] amdgpu 0000:03:00.0: amdgpu: RAS: optional ras ta ucode is not available
[dim. mars 17 15:32:51 2024] amdgpu 0000:03:00.0: amdgpu: RAP: optional rap ta ucode is not available
[dim. mars 17 15:32:51 2024] amdgpu 0000:03:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available
[dim. mars 17 15:32:51 2024] amdgpu 0000:03:00.0: amdgpu: SMU is resuming...
[dim. mars 17 15:32:51 2024] amdgpu 0000:03:00.0: amdgpu: smu driver if version = 0x00000035, smu fw if version = 0x0000003c, smu fw program = 0, smu fw version = 0x00524500 (82.69.0)
[dim. mars 17 15:32:51 2024] amdgpu 0000:03:00.0: amdgpu: SMU driver if version not matched
[dim. mars 17 15:32:51 2024] amdgpu 0000:03:00.0: amdgpu: SMU is resumed successfully!
[dim. mars 17 15:32:51 2024] [drm] DMUB hardware initialized: version=0x07000C00
[dim. mars 17 15:32:52 2024] [drm] kiq ring mec 3 pipe 1 q 0
[dim. mars 17 15:32:52 2024] [drm] VCN decode and encode initialized successfully(under DPG Mode).
[dim. mars 17 15:32:52 2024] amdgpu 0000:03:00.0: [drm:jpeg_v4_0_hw_init [amdgpu]] JPEG decode initialized successfully.
[dim. mars 17 15:32:52 2024] amdgpu 0000:03:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
[dim. mars 17 15:32:52 2024] amdgpu 0000:03:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0
[dim. mars 17 15:32:52 2024] amdgpu 0000:03:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0
[dim. mars 17 15:32:52 2024] amdgpu 0000:03:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 6 on hub 0
[dim. mars 17 15:32:52 2024] amdgpu 0000:03:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 7 on hub 0
[dim. mars 17 15:32:52 2024] amdgpu 0000:03:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 8 on hub 0
[dim. mars 17 15:32:52 2024] amdgpu 0000:03:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 9 on hub 0
[dim. mars 17 15:32:52 2024] amdgpu 0000:03:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 10 on hub 0
[dim. mars 17 15:32:52 2024] amdgpu 0000:03:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 11 on hub 0
[dim. mars 17 15:32:52 2024] amdgpu 0000:03:00.0: amdgpu: ring sdma0 uses VM inv eng 12 on hub 0
[dim. mars 17 15:32:52 2024] amdgpu 0000:03:00.0: amdgpu: ring sdma1 uses VM inv eng 13 on hub 0
[dim. mars 17 15:32:52 2024] amdgpu 0000:03:00.0: amdgpu: ring vcn_unified_0 uses VM inv eng 0 on hub 8
[dim. mars 17 15:32:52 2024] amdgpu 0000:03:00.0: amdgpu: ring jpeg_dec uses VM inv eng 1 on hub 8
[dim. mars 17 15:32:52 2024] amdgpu 0000:03:00.0: amdgpu: ring mes_kiq_3.1.0 uses VM inv eng 14 on hub 0
[dim. mars 17 15:32:52 2024] amdgpu 0000:03:00.0: [drm] Cannot find any crtc or sizes
[dim. mars 17 15:32:52 2024] [drm] ring gfx_32801.1.1 was added
[dim. mars 17 15:32:52 2024] [drm] ring compute_32801.2.2 was added
[dim. mars 17 15:32:52 2024] [drm] ring sdma_32801.3.3 was added
[dim. mars 17 15:32:52 2024] [drm] ring gfx_32801.1.1 ib test pass
[dim. mars 17 15:32:52 2024] [drm] ring compute_32801.2.2 ib test pass
[dim. mars 17 15:32:52 2024] [drm] ring sdma_32801.3.3 ib test pass

Anyone an idea? Could it be that I left the UMA to default and not game mode?

For anyone who hasn’t seen it, I think a fix for this is in the works. There was a detail in the latest email update on the FW 16 shipping that sounded like it was addressing this issue:

Display frozen after smart MUX switching - AMD has shared an updated graphics driver with us that has the fix for this along with some new features and performance improvements. This is also currently in our test process, and it will follow the same release path as the BIOS update.

Edit: I don’t think the above has anything to do with Linux. Probably just a Windows driver.

1 Like

The stutter only happen when using display-port through a WD19TB dock. So could also be linked to the way I have connected my external 4K screen.
Maybe I’ll test using a HDMI link… when I have time.

UPDATE: Rewired to HDMI. Will test it for a while.

So - HDMI will all of a sudden show me a black page - for no apparent reason - randomly.
Logs show nothing, so I don’t think it comes from the laptop but rather the dock.

Switched back to Display Port.
Just had a kernel update applied from Ubuntu - will see if that fixes some things.

1 Like

FYI - I switched UMA settings to game mode in the BIOS, and I no longer have these micro stutters showing up when doing graphically challenging stuff with the windows.

So I guess that deals with it. Was the missing memory on an external 4K screen.